The Artima Developer Community
Sponsored Link

Weblogs Forum
Programming in the Mid-Future

88 replies on 6 pages. Most recent reply: Apr 11, 2010 8:47 PM by Charles McKnight

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 88 replies on 6 pages [ « | 1 ... 2 3 4 5 6 | » ]
Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Programming in the Mid-Future Posted: Mar 15, 2010 9:49 PM
Reply to this message Reply
Advertisement
> I don't want the overhead of having to fill in all virtual
> methods and making sure that all @Override specs are
> correct etc.

At least in Java/Eclipse, this is laughably trivial. You type

class Foo implements SomeInterface {}


wait a second or two for red stuff to appear, click on "Add unimplemented methods", and all the stubs appear, complete with a nice reminder

// TODO Auto-generated method stub

I'm sure most other languages and IDEs do similar. (I'm not even a big Eclipse fan) Come on, dynamic language fans - surely you can come up with a better argument than this!

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming in the Mid-Future Posted: Mar 15, 2010 10:31 PM
Reply to this message Reply
Actually, both java (the interpreter) and Eclipse are fine running code that has missing methods as long as these methods are not invoked, so yes, really not a problem in practice.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Programming in the Mid-Future Posted: Mar 16, 2010 2:19 AM
Reply to this message Reply
> Actually, both java (the interpreter) and Eclipse are fine
> running code that has missing methods as long as these
> methods are not invoked, so yes, really not a problem in
> practice.

Good point.

Seriously, I'm very willing to look at new dynamic or functional stuff. Java does have a lot of boilerplate and typing. Duck typing has advantages.

But most all of the arguments for dynamic/FP stuff on Artima range from sad to absurd. For example, this thread where there are sad claims about the non-existent toil of filling in missing virtual methods, and absurd claims that "it can't be done in a static language".

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming in the Mid-Future Posted: Mar 16, 2010 9:05 AM
Reply to this message Reply
> Here's a problem that I regularly want to solve and that
> works perfectly well in a fully run-time-checked language
> and don't work in any statically typed language I've come
> across (and more or less by definition can't work): Start
> executing a program with missing methods and invalid
> "types."

If types are invalid and you know it, and the compiler can know it, there is nothing to test.

>
> I don't want the overhead of having to fill in all virtual
> methods and making sure that all @Override specs are
> correct etc. I just want the part of the program that
> I've written to start running, so I can go on debugging
> and see how that single test I'm focused on in the moment
> is faring.

So don't write the virtual methods then. Run the test, and then complete the code.

Wow, this discussion has been turned to a 'dynamic vs static' debate!

Roger Turnau

Posts: 4
Nickname: 70060
Registered: Jan, 2010

Re: Programming in the Mid-Future Posted: Mar 16, 2010 12:39 PM
Reply to this message Reply
> Seriously, I'm very willing to look at new dynamic or
> functional stuff. Java does have a lot of boilerplate and
> typing. Duck typing has advantages.

I thoroughly agree, but as a budding Haskell enthusiast, it bothers me when people conflate FP and dynamic typing as if they were the same thing. I'm not saying you're doing this, but a lot of the discussion on this thread has suffered from this confusion -- including, I suspect, Eckel's original article.

There is a growing set of problems that functional languages are believed to solve better than imperative languages -- namely concurrency. A strictly functional language will enforce immutability on your data, which does help parallelize your algorithms. This benefit is absolutely unrelated to typing, but because a lot of the more popular functional languages (Scheme, Lisp, Javascript) are weakly typed, a lot of programmers wrongly believe that weak typing and FP go hand in hand.

Haskell, on the other hand, is both strictly functional and strongly typed. In fact, if Java and C++ are considered strongly typed, then Haskell needs a category of its own. Its type system is brutal, if not bullying. You will rarely get through ten lines of code without some bizarre compiler error complaining that your types don't line up. Its type inference system seems at times like it was put there to mess you up until you know what you're doing.

The strange benefit to this is that once your code compiles, you have a pretty solid guarantee that it will work as you intended it to. You have fewer bizarre runtime errors like you see with duck typing.

This makes Haskell is the perfect counter-example to people who think that you need Scheme-like typelessness in order to program functionally.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Programming in the Mid-Future Posted: Mar 16, 2010 2:42 PM
Reply to this message Reply
> How coined the term "active objects", anyway?
> Wasn't it Robert Cecil Martin? Didn't Bill Venners then
> n follow suit? What a comedy of misunderstanding.

No recollection who, but the java webserver/framework folks, deciding to send only data over the wire rather than objects (method/data thingees) just like PHP, took the active/passive paradigm and spread it through all of java. Their bad.


>
> I disagree that "stupidly parallel" objects come naturally
> to students. In my experience, most adults have a hard
> time thinking about system designs which are (a) clockless
> (b) concurrent. -- (a) and (b) togother is the definition
> of "stupidly parallel", since there is no synchronization
> marshaling code and everything uses handshaking protocols
> behind the scenes.

Let's find some client side problems which are inherently parallel, first. Servers are inherently parallel, of course.


> It will
> > live on your machine and in the cloud, as necessary,
> and
> > you won't have to think about whether it's being
> garbage
> > collected or swapped.
>
> This is so completely wrong. The "cloud" is not the
> future. Highly clustered, highly available systems are.
> Nobody is going to trust their core data to Rackspace or
> r Microsoft or Amazon or Google or whoever else comes
> along! All it takes is the FBI seizing one server that
> just so happens to simultaneously be storing child
> pornography on it, and you are screwed as a company.
>
> Only somebody with a reckless passion for success at all
> costs would do what you are suggesting as the future.

A voice of sanity. Alas, just as the OO folk re-invented procedural code with the active/passive paradigm (read Holub's series on the Bank of Allen on how one might design an ATM in an OO fashion to see the difference), they will make another lemming-like dive over yet another cliff; all the while congratulating themselves on their collective cleverness.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Programming in the Mid-Future Posted: Mar 16, 2010 3:38 PM
Reply to this message Reply
> I thoroughly agree, but as a budding Haskell enthusiast,
> it bothers me when people conflate FP and dynamic typing

Didn't mean to do that (I know the diff).

> There is a growing set of problems that functional
> languages are believed to solve better than imperative
> languages -- namely concurrency.

Somewhat agreed. My Java style always had more immutable objects and/or fields that the "norm", and, having worked a lot in concurrency the past couple of years, now it has even more.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: Programming in the Mid-Future Posted: Mar 16, 2010 4:24 PM
Reply to this message Reply
> > along! All it takes is the FBI seizing one server that
> > just so happens to simultaneously be storing child
> > pornography on it, and you are screwed as a company.
>
> I would expect data to be replicated across servers on
> multiple sites and perhaps multiple jurisdictions before I
> trusted the cloud.

I'm confused. Are you agreeing with me, or are you saying that the cloud is your last resort?

I am saying that before the cloud becomes a last resort, you should have a highly clustered, highly available network internally.

Google is spinning this a different way. They are adding a utilities company to complement their advertising business. The reason for this is that they can horde expertise in building highly clustered, highly available systems. Christophe Bisciglia was told by Eric Schmidt to evangelize MapReduce at college universities, "gettin' 'em while they're young" - after all, you need programmers who know how to screw in light bulbs in order to sell light bulbs - As if Map Reduce was somehow important to Computer Science!!! Computer Science departments like U. Washington won't say no, because Map Reduce courses mean funding to have a free Google-paid-for super computer on campus... side-stepping traditional NSF funding challenges to get such resources.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming in the Mid-Future Posted: Mar 16, 2010 4:27 PM
Reply to this message Reply
> Only somebody with a reckless passion for success at all
> costs would do what you are suggesting as the future.

I think people are taking this way too seriously. You read a blogs of some wild-eyed 'futurists' take a few tokes and voila! Out pops this article. I mean some of these things may come to pass in one way or another but does this list have any useful purpose? I don't think so. It might blow the minds of some psychonauts at "Burning Man", I guess.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: Programming in the Mid-Future Posted: Mar 16, 2010 5:20 PM
Reply to this message Reply
I'm not taking it seriously, because it is obviously an article where the author has taken the latest buzzwords and put them into a stream of thought conciousness.

Fads projected into the future never predict the future.

Highly clustered, highly available systems are not a fad.

Clouds are.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Programming in the Mid-Future Posted: Mar 16, 2010 5:34 PM
Reply to this message Reply
> >
> > I would expect data to be replicated across servers on
> > multiple sites and perhaps multiple jurisdictions before
> I
> > trusted the cloud.
>
> I'm confused. Are you agreeing with me, or are you saying
> that the cloud is your last resort?

If the cloud's data was replicated across servers and jurisdictions, then the seizure or other loss of a single server (or even more) would not cause loss or inaccessibility of your data. Some cloud type systems do offer data replication of this type and I think they could be reasonably used for important business functions.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: Programming in the Mid-Future Posted: Mar 16, 2010 5:42 PM
Reply to this message Reply
Mark,

I understand now and am no longer confused.

See my point above about Google trying to make it difficult for smaller businesses to set-up mini-utilities.

For what it is worth, there are fast-growing businesses that could eventually compete with Google by occupying an ever-expanding small business IT market: companies like LAN Associates have grown about a 1000fold since they started about a decade ago.

Actually, VMWare should buy LAN Associates and compete for the small business market. I've said this to a VMWare employee. It's the future of business real estate.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming in the Mid-Future Posted: Mar 17, 2010 10:54 AM
Reply to this message Reply
> I'm not taking it seriously, because it is obviously an
> article where the author has taken the latest buzzwords
> and put them into a stream of thought conciousness.
>
> Fads projected into the future never predict the future.
>
> Highly clustered, highly available systems are not a fad.
>
> Clouds are.

A lot of people would say that 'clouds' and 'highly clustered, highly available systems' are the same thing. I agree with you if you are saying that the term 'cloud' is overused and poorly defined.

My personal feeling is that the infrastructure is inadequate for a business to push everything to the cloud. Consider a call center where their CRM software is hosted on the cloud. Any outage anywhere between the call center and the host will bring the call center to a grinding halt. For example, if the call center's connection to the internet is interrupted, they are screwed. Even if the host keeps it's SLA (as e.g. Amazon has failed to do several instances) they are still at risk.

More concerning to me is that major cloud service providers don't really seem to take things very seriously. I've worked with a huge SaaS vendor who flat told me without apology that they had no record locking strategy in their web services.

Having said that, I think in the long term there will be more movement toward distributed external hosting of data and applications. Whether there will ever be complete death to the local data center isn't clear to me. There are some inherent disadvantages to that approach that will not be overcome without major breakthroughs in physics.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Programming in the Mid-Future Posted: Mar 17, 2010 11:55 AM
Reply to this message Reply
> Having said that, I think in the long term there will be
> more movement toward distributed external hosting of data
> and applications. Whether there will ever be complete
> death to the local data center isn't clear to me. There
> are some inherent disadvantages to that approach that will
> not be overcome without major breakthroughs in physics.

When he was asked how it was that his machines were so much faster than anyone else's (IBM particularly), Seymour Cray replied: "shorter wires". The web-cloud will always be "longer wires"; the young-uns haven't figured that part out yet.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: Programming in the Mid-Future Posted: Mar 17, 2010 3:51 PM
Reply to this message Reply
> > Effortless data stores
>
> We already have "objects where you can store data and
> later ask for it". The difficulty lies in *how* you ask
> for it, and what it *means* to store and ask for it.
>
> ACID compliance provides certain meanings, and comes with
> certain costs. Eventual consistency provides a different
> set of meanings, and comes with lower costs. Asking for
> objects by name has certain (low) costs when you store the
> data, being able to ask for objects by their attributes
> has different (higher) costs when you store the data. You
> can ignore these differences for very small data sets, but
> as you scale up you *need* to care. Possibly the storage
> features dependent on "how you ask for it" can be
> determined automatically by analysis of your api usage,
> but "what it means" needs to be specified by the
> programmer.
>
> > Query-based data
>
> This ties in to the previous point, it's one particular
> combination of "how you ask for it" and "what it means to
> ask for it".


http://waterken.sourceforge.net/upgrade/#engine

Flat View: This topic has 88 replies on 6 pages [ « | 2  3  4  5  6 | » ]
Topic: Things to Know About Python Super [3 of 3] Previous Topic   Next Topic Topic: Rapid Hiring & Firing to Build the Best Teams


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us