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 | » ]
Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Programming in the Mid-Future Posted: Mar 12, 2010 3:31 PM
Reply to this message Reply
Advertisement
> > I have a hard time thinking of one
>
> Carson, how about the very browser you've posted this
> comment with? :-)
>
> I mean browser scripting. Is there a scarier nightmare
> than doing this kind of stuff in a strictly typed,
> compiled language?
>
I believe a Java applet has access to the objects of its containing page and can 'script' that page. While I've not tried it, it doesn't seem all that scary to me.

Roger Turnau

Posts: 4
Nickname: 70060
Registered: Jan, 2010

Re: Programming in the Mid-Future Posted: Mar 12, 2010 10:54 PM
Reply to this message Reply
> Haskell Curry died almost 30 years ago, he can't solve
> problems anymore.
>
> As about Haskell programming language -- it can't solve
> problems either because it can't think, regardless of how
> ridiculous its type system is.

That's just obtuse, especially since I was responding to the following claim: "There is a significant and growing class of programming problems that static languages can't solve."

> Problems are solved by alive (and sane) people, not by
> programming languages.

I completely agree. However, I was not the one claiming that there are certain problems that certain classes of languages can't solve.

> Now, would *you* dare to choose
> Haskell as a main tool for a 50+ developer team?

No, I wouldn't, not unless I could be promised a cadre of PhDs, and even then I'd think twice. But again, this is irrelevant to the issue. The argument presented was that static languages can't do certain things. I'll be generous, and interpret the phrase as "can't do certain things well."

I would argue that any claim about strong typing that does not at least consider Haskell is broken from the get-go.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Programming in the Mid-Future Posted: Mar 13, 2010 11:33 AM
Reply to this message Reply
>> There is a significant and growing class of programming problems that static languages can't solve.

I suspect that much of the discussion engendered by this sentence could have been avoided if it had been presented thus:

There is a significant and growing class of programming problems that static languages can't solve within the time and staffing constraints of our growingly abusive development regimes; dynamic languages support the production of working systems in shorter wall clock time and lower resource counts.

Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Programming in the Mid-Future Posted: Mar 13, 2010 12:11 PM
Reply to this message Reply
> >> There is a significant and growing class of
> programming problems that static languages can't solve.
>
> I suspect that much of the discussion engendered by this
> sentence could have been avoided if it had been presented
> thus:
>
> There is a significant and growing class of programming
> problems that static languages can't solve within the time
> and staffing constraints of our growingly abusive
> development regimes; dynamic languages support the
> production of working systems in shorter wall clock time
> and lower resource counts.

That might help a bit against the pedantic smart-asses, but does nothing to stop it being an extraordinary claim with no backing evidence (which probably contributed somewhat to people considering smart-assery to be the most appropriate response).

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Programming in the Mid-Future Posted: Mar 14, 2010 4:49 AM
Reply to this message Reply
> That might help a bit against the pedantic smart-asses,
> but does nothing to stop it being an extraordinary claim

On the other hand, if you're trying to sell ($900) tickets to a conference that you're organising and presenting at:

"I plan to hold a session on this topic at next week's Java Posse Roundup"

...then making extraordinary claims is one of the oldest tricks in the book.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Programming in the Mid-Future Posted: Mar 14, 2010 4:53 AM
Reply to this message Reply
>
> On the other hand, if you're trying to sell ($900) tickets
> to a conference that you're organising and presenting at:
>
> "I plan to hold a session on this topic at next week's
> Java Posse Roundup"
>
> ...then making extraordinary claims is one of the oldest
> tricks in the book.

I'm not sure that it works so well if you make trivially refutable claims. Next he'll be predicting that the halting problem will be solved ...

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Programming in the Mid-Future Posted: Mar 14, 2010 5:55 AM
Reply to this message Reply
> > Haskell Curry died almost 30 years ago, he can't solve
> > problems anymore.
> >
> > As about Haskell programming language -- it can't solve
> > problems either because it can't think, regardless of
> how
> > ridiculous its type system is.
>
> That's just obtuse, especially since I was responding to
> the following claim: "There is a significant and growing
> class of programming problems that static languages can't
> solve."

Even type systems guru and author of TaPL, Benjamin Pierce, admits in his work about lenses that static type checking is not enough and he moves along with Waha, Siek and Wadler for a middle ground.

About real world examples. Just yesterday I dealt with a collection of classes {A1, ..., An} which derive from another collection of classes {P1, ..., Pn}. The bases depend on a parameter config.parent which can be set in a config file. So either one applies a code generator very carefully and advances refactoring tools to groups of classes and so on or one creates a function which loads base classes dynamically. In Python this reads like this

import loader
import config
XBase = loader.load_base_class(config.parent, "X")

class X(XBase):
pass

config.parent is fully opaque to the application code defining X just like the custom loader mechanism, which is both intentional.

One could argue that some super-duper type system with dependent types could check this as well but I suspect this is a hare and hedgehog game. Since the type system grows in complexity and with it also the mental load I wonder what is so bad about seeing constructions like the one above failing just when the module loads which usually takes a few miliseconds. CPython provides good error messages and a readable stack trace. This is not self-evident.

Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Programming in the Mid-Future Posted: Mar 14, 2010 1:31 PM
Reply to this message Reply
> About real world examples. Just yesterday I dealt with a collection
> of classes {A1, ..., An} which derive from another collection of
> classes {P1, ..., Pn}. The bases depend on a parameter config.parent
> which can be set in a config file.

I have written something somewhat similar in C++, where the child class is chosen after instantiation time. It works like this:


DerivedBase
/ \
Derived1 Derived2

ParentBase
/ \
Parent1 Parent2

class DerivedBase {
public:
void Foo();
void Bar();
...
};
class ParentBase {
DerivedBase * _sub;
public: // or protected
void Foo() { _sub->Foo(); }
void Bar() { _sub->Bar(); }
...
void SetChild(DerivedBase *s) { _sub = s; }
};


(Code at http://mtn-host.prjek.net/viewmtn/monotone/revision/browse/8b4a59140395ae1ffd2f54e53aa2ffa79c1457fa/network , the files with "session" in the name.)

I see no reason that it wouldn't work to just swap the relationship between DerivedBase and ParentBase and put the SetChild (now SetBase) call in the constructor to get the effect you have.

Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Programming in the Mid-Future Posted: Mar 14, 2010 1:58 PM
Reply to this message Reply
(Oh, and supposedly D has a way to forward functions from members without needing to manually wrap them like I had to in ParentBase. So that particular minor annoyance is a language artifact.)

Kit Davies

Posts: 9
Nickname: kitd
Registered: Sep, 2003

Re: Programming in the Mid-Future Posted: Mar 15, 2010 10:30 AM
Reply to this message Reply
I would like to see more work in the semantic description of objects. By that I mean description of objects and their behaviour according to some widely accepted ontologies.

I could see much benefit from this in composing systems in a service-oriented way. Sort of like 'meta-interfaces' that allow service searching and auto-wiring. This could be applied to both local and distributed systems.

Oh and preferably, with minimal XML.

Roger Turnau

Posts: 4
Nickname: 70060
Registered: Jan, 2010

Re: Programming in the Mid-Future Posted: Mar 15, 2010 12:13 PM
Reply to this message Reply
> Even type systems guru and author of TaPL, Benjamin
> Pierce, admits in his work about lenses that static type
> checking is not enough and he moves along with Waha, Siek
> and Wadler for a middle ground.

I've only been able to give these articles a quick skim, but thank you for a precise answer to the question. I suspected that the "growing class of programming problems" was related to data-in-the-cloud, but these papers are clarifying the issue for me.

I was also amused by Pierce's provocatively-titled "Types Considered Harmful" talk. Pierce hasn't abandoned types (the way Eckel seems to have done), but he does highlight the trade-offs.

> I suspect
> this is a hare and hedgehog game. Since the type system
> grows in complexity and with it also the mental load I
> wonder what is so bad about seeing constructions like the
> one above failing just when the module loads which usually
> takes a few miliseconds.

Therein lies the trade-off, I think, between strong and weak typing. Having an ancestor type fail out from under your application might be a harmless, recoverable error. Alternately, it might represent the transactional failure of a bond trade valued at tens of millions of dollars, whereupon the stress-puppy banker at the other end of the phone will let you know exactly what is so bad about it, until his ulcer becomes your own.

Proponents of weak typing argue that rigorous unit testing makes a type system's guarantee of safety irrelevant. I say the jury's still out on this one, and scale remains an issue. Where weak typing helps you at massive scale is generally when you don't require ACID-type transactional safety (e.g., Facebook status updates, or any time Reddit tells you "There doesn't seem to be anything here," in spite of there having been something there a minute ago). Once you start caring about data delivery, strong typing looks a lot better in practice.

Or, to quote Pierce: "[Typing] Precision can be useful and even necessary, but we need to stay awake to some serious pragmatic issues. More research is needed."

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming in the Mid-Future Posted: Mar 15, 2010 12:19 PM
Reply to this message Reply
>Proponents of weak typing argue that rigorous unit
> testing makes a type system's guarantee of safety
> irrelevant. I say the jury's still out on this one,
> and scale remains an issue

My problem with dynamically typed languages is much less correctness (which I agree can be made up for with thorough unit testing) than it is about code readability and poorer tool support.

You don't really realize this until you have to take over or fix code that's even moderately big (several thousands of lines) and written without a single type in sight. It's pure nightmare and you end up learning how the code works by breaking it, which is a terrible waste of time.

--
Cedric

Eivind Eklund

Posts: 49
Nickname: eeklund2
Registered: Jan, 2006

Re: Programming in the Mid-Future Posted: Mar 15, 2010 5:27 PM
Reply to this message Reply
> > > I have a hard time thinking of one
> >
> > Carson, how about the very browser you've posted this
> > comment with? :-)
> >
> > I mean browser scripting. Is there a scarier nightmare
> > than doing this kind of stuff in a strictly typed,
> > compiled language?
>
> Mike, you keep missing the point.
>
> We're not debating whether it's easy or hard but whether
> it's possible.
>
> Actually, we're not even debating any more: the initial
> claim ("can't solve") is clearly incorrect.

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."

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.


I suspect that this isn't as important to you - because you've had about 15 years of working (according to your CV) exclusively with the C++/Java family of languages - which I presume means that you've only worked a little bit with the dynamic languages. Your working habits and mind are almost certainly optimized for this environment, making the most of the functionality you get there, and unconsciously working around the deficiencies, just like mine are optimized for the dynamic language space and I work around the deficiencies in that. And neither of us fully exploit the benefits available in the opposite environment - I probably don't mentally rely on types enough when doing Java programming, and say you look for types when you start trying to read dynamic code.


When I switched from static to dynamic programming, it took me probably at least five years to learn to properly exploit the benefits of the dynamic environment, to get rid of my static ways of thinking, and to change my habits of design to work well with the dynamic languages - both avoiding constructs that would have been fine in static languages, and using constructs that would have been impossible in static languages.


As for the popularity argument: If I replaced your statement
> Maybe you mean that certain problems can be solved more
> elegantly with DTL than statically typed languages, but
> even such a statement is extremely subjective and I find
> no evidence to support it in the current trends, where
> the most active and popular languages (Java, C# and C++)
> are all statically typed and DTL continue to occupy a
> niche, despite being in existence for several decades...

with
> Maybe you mean that certain problems can be solved more
> elegantly with Unix than Windows, but even such a
> statement is extremely subjective and I find
> no evidence to support it in the current trends, where
> the most active and popular operating systems (Windows
> XP, Windows Vista and Windows 7) are all variants of
> Windows and Unix continue to occupy a niche, despite
> being in existence for several decades...

it may become more obvious that the argument has little information in it.

Many people use statically typed languages in part because they are afraid of type errors and feel safer with them than with dynamically typed languages, without regard for or deep investigation of actual merit, just as many people use Windows because they are afraid of using "something supported by random hackers", without regard for or deep investigation of actual merit.

John Zabroski

Posts: 272
Nickname: zbo
Registered: Jan, 2007

Re: Programming in the Mid-Future Posted: Mar 15, 2010 5:29 PM
Reply to this message Reply
> <div class="section">
> <h1><a id="stupidly-parallel-objects"
> name="stupidly-parallel-objects">Stupidly parallel
> objects</a></h1>
> <p>Objects will manage their own processes; right now we
> call these "active objects" but in the future
> this idea will be incorporated into the basic idea of an
> object (you can't really say that an object models reality
> unless it has its own process).</p>

In embedded systems, they are not called active objects. In embedded systems, there is no such thing as "passive objects". How coined the term "active objects", anyway? Wasn't it Robert Cecil Martin? Didn't Bill Venners then follow suit? What a comedy of misunderstanding.

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. Also, getting two objects' state machines to interact well with one another is not easy, and most people will give up early and fall back to designs that get killed performance-wise. - We have the same situation today with people who are surprised by "scaling problems" when they never soak tested their system from day one.


> <div class="section">
> <h1><a id="persistent-diskless-environment"
> name="persistent-diskless-environment">Persistent diskless
> environment</a></h1>
> <p>Eventually the idea that we have to "store
> something to disk" will go away; the difference
> between memory and disk will be seen as an arbitrary
> artifact of the past. You'll just have data, and the data
> will be accessible for as long as you need it. 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.</p>

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 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.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Programming in the Mid-Future Posted: Mar 15, 2010 5:43 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.

Flat View: This topic has 88 replies on 6 pages [ « | 1  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