(n.b. Peter responded to me privately. I'm assuming he meant to cc
the list in his reply to me. Accordingly I have not removed any part
of his response, and replied inline below.)
On Aug 13, 2008, at 9:57 PM, Peter Michaux wrote:
> On Wed, Aug 13, 2008 at 8:45 PM, Neil Mix <[EMAIL PROTECTED]> wrote:
>>
>> On Aug 13, 2008, at 8:02 PM, Peter Michaux wrote:
>>
>>> Are these
>>> type-related features what the community of ECMAScript 3 programmers
>>> were really asking for emphatically years ago? Is the community
>>> really
>>> asking for now with the surge of functional programming?
>>
>> One hacker's opinion: Yes, absolutely. The big pain point for me
>> has been
>> scaling an app out from a team of 1 with <10K LOC to a team of many
>> with
>> 100K+ LOC. Even with an incredibly rigorous testing infrastructure
>> (comparable in code size to the product itself), development on the
>> application just hasn't scaled well. Many JS hackers don't build
>> apps at a
>> large scale, but JS-based apps will only get bigger in scope over
>> time, so
>> this pain point will get more acute.
>
> I do deal with a large code base (somewhere around 100K of JavaScript)
> but never 100K lines in a single web page. Even for the heavy pages
> the call stacks are usually quite shallow. I actually have never found
> it very difficult to debug a type error. I've found my other mistakes
> far more painful. :-)
Pandora uses OpenLaszlo, ES3 compiled to Flash, thus our application
is substantially bigger that what you'd find on a typical page. What
actually runs in-page isn't 100K LOC, but when you add in offline
supporting functions such as test infrastructure (i.e. end-to-end
pieces that need to have knowledge of each other's parts) we're on the
order of 100K.
I agree that debugging such errors isn't difficult. But my
observations are about productivity rather than difficulty. The time
consumed in debugging such errors is costly, if not mind-busting.
Especially relative to static type checking.
>
>
> I do get the idea that a consumer of an API is helped with some good
> error messages. Sometimes I have public API functions of a library
> that start something like
>
> function(a, b) {
> /* begin debug */
> isInt(a); // throws
> isStr(b); // throws
> /* end debug */
> ...
>
> The debugging code is stripped when deploying for production for
> better download and runtime performance.
>
>
>> It's all about time spent. A large app is impossible for a new-hire
>> programmer to comprehend end-to-end. We mitigate this by using
>> unit tests
>> as a safety barrier, but over time our tests have grown to take
>> about 10
>> minutes or so to run. That's way too long to wait for a pesky
>> misspelling
>> bug.
>
> Does type checking catch misspelling bugs?
>
>> To the extent that there's static type checking available to catch
>> errors early on, it's a huge productivity gain.
>
> Is Harmony type checking even going to be static?
These are great questions that I don't know the answer to. Clearly
this needs time to sort out in committee. But I'll weigh in with an
early opinion that the option to do static type checking in JavaScript
would, IMO, be a very good thing.
>
>
> [snip]
>
>> Your statement above implies that types and functional programming
>> are
>> mutually exclusive. Are they? I don't see it that way.
>
> No they aren't and I didn't mean to imply that. I intending to compare
> the interest in class-based OOP that was all the rage many years ago
> when ES4 first started and now where there is more emphasis on a
> functional style which can, and often do, still have types.
I see. To which I say, why not both? First class functions may be
all the rage with the kids these days, but I don't take that to mean
OO is dead in the water. It's just not new and exciting -- you simply
depend on it without thinking about it. ;)
I've been deep into Objective-C lately. I sorely miss the closures,
but the "bendable" static typing sure works out elegantly. I've
already gotten through some pretty intense refactorings that "just
worked" once they compiled without warning. That *never* happens to
me in JavaScript. Do that a few times, suddenly I'm gaining
confidence in my ability to refactor, and before I know it the code
doesn't feel so big and complicated anymore. I'm not fearing the dark
corners. It's a nice feeling.
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
