Sunday, December 12, 2010

notes for an open letter to Crockford on Curl

I am working on a response To Douglas Crockford's comment concerning the case for server-side JavaScript (beyond Yahoo and YUI3) for my blog at developers.curl.com

This is just a first pass: open letter to Crockford
  0) mea culpa.  Sorry about that.  I do apologize. Crockford on Rebol. That was simple ignorance on my part: I thought "I knew my Crockford."  I was wrong to think that I have paid close enough attention to your work. I was wrong not to research that.  I have known for a few years that there was a Rebol link on the JSON page.

  1) But. We should try not to misrepresent/understate/elide the salient facts in history of science - even an applied science. SUN and the fate of Self and Strongtalk is almost as wicked a tale as RCA and FM (see the story of super-heterodyne and the 9/11 broadcast mast.) The history is about the team that Sun provided Netscape, is it not?  Or is it me who has substituted myth for history (the human bent) ?

     a) from Self to Javascript
     b) Google V8 inlining [ no puns: see inline-8 engines ]

 Setting the facts straight: (i.e., setting me straight)

    Dates: (timelines)
      JavaScript and Java are 1995 releases
      Strongtalk dates from 1993 and ideas put to work in 1994 but completed only in 1996 and for a company acquired by Sun in 1997.  So that team did not work on getting LiveScript up to JavaScript as I was told one evening in L.A.
So much for hearsay; history is most often based on the available documents but tempered by documents unavailable or suspected to exist (when there are documents;  see below: transparency vs dark-documents; recent case: Katyn)

BRB: Blog Readers Beware of 'web' documents: Frank and Stein Java's history interview at javaperformancetuning.com on April 1st 2003 by Jack Shirazi
See: Frank Yellin and James Gosling.
See: the Ralph Griswold papers at UMN (Icon and SNOBOL)
NTMR NoteToMyReaders: not be confused are Ralph, Bill and Dave Griswold as identity matters for more than just objects.

      Self -
         GC paper 1984
         Self starts at Xerox PARC in 1986
         the critical paper dates from 1987
         first release in 1990
         acquired by Sun in 1991 [inlining paper is Sun 1991 ?]
      Java - work began in 1991

      Q: who worked on second gen-JS and second-gen Java ?
      Q: who from Sun worked on JS at Netscape with Brendan Eich ?
              - prior to and in 1995
              - 1995 and later
          what were their roles and what were their contribution
      Curl
         - work began in 19__
        SIGPLAN 1986
David Kranz. ORBIT: An Optimizing Compiler for Scheme. Ph.D. dissertation, Yale University, February 1988. Research Report 632, Department of Computer Science.
                 DARPA grant details:
        whitepaper 'the gentle slope' or 'The Curl Project' authors:
              M. Hostetter, D. Kranz, C. Seed, C. Terman, S. Ward
              Organization:  MIT Laboratory for Computer Science
                                      545 Technology Square, Cambr. MA
The Curl project is supported by the Information Technology Office of the Defense Advanced Research Projects Agency as part of its Intelligent Collaboration and Visualization program. 

         - free software movement at MIT
         Q: is 1998 a correct release year ?
         - Michael Dertouzos dies unexpectedly in Aug., 2001
               a note and the Dertouzos Lecture Series at MIT
         - PDF  Morgan McGuire "The Curl Graphics2d Immediate Mode Rendering API" supervised by Steve Ward [thesis date May 17, 2000]
         - decision to 'spin-off' from MIT in
         - low point of dot.com crash: 2002
         - the major Curl programmer's book: 2002
         - decision to participate in open-source in
     Scheme
         Guy Steele and Oak/Java (James Gosling, Bill Joy, Guy Steele) [see Java and closures]
         Steve Ward et al and Curl ?
         Brendan Eich and Mocha/LiveScript/JavaScript
     Python
        Python and Java in the MIT CS curriculum

    LISP & Curl
       On T at paulgraham

 
  2) Curl is swell - not so very swell as it has a big unknown and a few gotchas, too.
 
       Let's take Pharo Smalltalk as a really 'swell' language (and yes, Pharo is both server-side and in the browser.)
      
         Classic Smalltalk 80 got many things right, but tended for years to reject composition in favor of inheritance. Smalltalk implementor's pride was the Collection hierarchy with its list comprehensions exploiting blocks.  Smalltalk's weakness was a lack of interfaces (implemented using inheritance as abstract classes relying on
             >> subclassResponsibility
          In hindsight, given the work of Ducasse (the 'Crockford' of Smalltalk) we can see that both the perceived strength and weakness were neither. This is what Traits bring to Smalltalk: insight and results.
          The strength of Smalltalk can be seen in the ease with which both Traits and Seaside continuations could be introduced into a 'transparent' boot-strapped language [and SOUL and Backtalk and ...]

   Truly Swell: Pharo moves onto Eliot Miranda's Cog VM from Teleplace.com
         
       Now Curl
          Curl uses Regex.  In an expression-based language this is something of a travesty [not to use it or to offer it but to offer it only and solely.]  I call it  'the manager says use Perl' fallacy.  That fallacy applies to JavaScript: in my experience the manager says to use JavaScript in our custom site-specific intranet collaboration browser because we can tell the  CIO or CTO that HR can always find us JavaScript programmers cheap. [ I heard for years how expensive Smalltalk  developers were even after we had proven the value of offering Smalltalk training to non-CS employees with domain expertise in telecom].  Until Crockford (or without Flanagan) HR were hiring JS programmers who often had not learned their language.  Python programmers argue for python in the browser and python on the server so that they will be able to think in only one language. This is folly.  But python out-performs ruby so appears unstoppable. virtualenv is lauded although virtualenv offers something of a reductio ad absurdum for python-in-the-large.

          The libraries: arguing for JavaScript without looking at the Curl package documentation in the live-Curl IDE help applications is less than responsible.  Nothing in Prototype or Dojo comes close.  [ so, in faireness, I must segue here to YUI3 ].  In comparison, Smalltalk packaging of libraries is a nightmare. And ObjectIcon has a long ways to go and Rebol3 is only getting there now [only now do we have a UNICODE Icon and Rebol - there Curl shone and JS now shines.]

    Curl has not fostered the use of explicit constraint resolution or constraint handling  Curl for open-source still sees key, essential-to-grok code libraries unavailable even though they are not compiler or runtime engine specific.
         
    But.  A Curl developer who learns Curl syntax has a much better chance of understanding the strength of the language if she also learns and uses the macro facilities with which her daily coding expressions are built.
         
    So what is the history of Curl?  There is no need to compare JavaScript for serious server-side  to 'wild cowboy python' and its dynamic objects.  Every flaw in the JavaScript of 1999 was not a flaw in the Curl of 1999.  Curl is the foil.
         
    It is true but trivial that Curl is not on the server-side (in public).
         
   Rebol.  It is just not relevant that Rebol is not in wide use.  Monitoring the rebol-based  altme.com 'rebol world' reveals where rebol is in use.  Rebol2 has issues, but in practice, JS proves to tbe the problem child, not Rebol.
         
   The truly great language that is only used on one important funded project: ICON.  Ditto for Oz.
         
   Ditto for Caml (almost)
   Programmer says: we had to learn Prolog in a 300 class.
   Programmer says: we didn't learn Smalltalk ... is that still used anywhere?  It's kinda-like Prolog, but with objects, right?
          Where Curl was wrong in 1999.  The Curl pay-for-use came about 10 years ahead of GoogleAppEngine  and came at a bad economic juncture.  Curl faled to protect its name ( cURL horror: if I type curl  on my linux box I run cURL and not /opt/curl/surge/8/bin/curl
          Curl failed in not separating content from presentation. This has been addressed.
         
          If Curl had been free the way in which ICON was free ... (see the history of SNOBOL.)

          Economies of scale:        
         
         [ The MIT-trained Chief Technology Officer and Python: the case of the summer intern and the folly of dynamic objects in mission-critical code. A sad but true story.]
         
Why is there no lint ( Crlint ? ) for Curl ?

   It could be just a grep for pragmas and directives.
   It could be a grep for [ my const story ]
  
The missed 'killer app' was a Microsoft OneNote written in Curl or in ICON.

Rebol
  p: 42 q: 65535 lst: [p q] what: first lst
 
  GoogleTechTalk question: "What is the value of  :what  ??"
 
  But ICON and Curl are also expression-based languages - is this an issue in both of them? See: Rebol and denotational logic.
 
  And this is the issue of get words and set words being types in rebol.
 
  But wait a minute: look at {define-syntax} in Curl - such as
 
  {define-syntax public {first  ?item:identifer in
     ?list:expression where ?cond:expression}


  This is a conditional {first} macro declaration head suggested by Chris Barber at http://developers.curl.com
   
Another useful comparison of Curl as a web content language in 2010 and JavaScript 5: the Arguments object

And then there is the Curl documentation and the Curl IDE with the interactive debugger.  Now those are swell.

At the Michael Miller et al JS5 talk just before the release of the spec, a Google manager cautions that the talk is public when a minify issue is raised.  Why is minify not a Curl issue?  Answer: the pcurl file format.

To experiment with Curl:

  /opt/curl/surge/8/bin/curl --shell
 
NOTE: Scripting with Curl on the server:
  running an xcurl script does not launch the Curl 'applet manager'.

A current Curl weakness: the web docs remain 6.0 when Curl is 7.0

The Curl strength:  live code in the {example} macro and the documentation macros and 'text-procs'

Where to see good Curl code?  http://code.google.com/p/zuzu-curl and various at sourceforge.net

A great strength of Curl: the packaging and the packaging macros.
BUT commonjs.org

Great strengths of JavaScript: JSLint, JSON, traits.js, node.js  jQuery "use strict";

A weakness of JavaScript: the actual JSlint code.  Compare how this would be packaged in Curl. This remains a weakness of ICON and even ObjectIcon and is only addressed in Rebol3.
    
And I like the Crockford .create for new and the Crockford 'in closure find your privacy'

The manager for Perl also said not to use JSON because HR can always find XML programmers.

Here is my private constant story.  I cannot tell you the many,many global 200 organizations using this Curl codebase or a customized variant.

Suppose you ran grep on a src directory of source files for a modern language which provided encapsulation and a const declaration.  Suppose that in that large codebase maintained by a large off-shore coding firm you could not find a file with either
  private
  const
 
So it is true that people will not learn their language; so it is true that a prototype can get shoveled-and-shoe-horned out into production.

Python has the author of straits.py and JavaScript has Crockford.  Curl has Chris Barber, who really should be giving a Yahoo talk and a GoogleTechTalk.

Curl's release began with an unforeseeable tragedy for the CS dept at MIT - and an unforeseen economic crisis.  But evolution teaches us about a small furry niche-only mouse-like creature which we call a mammal and of which the larger dinosaurs took no notice.

Evolution's good ideas can start with few numbers.  Applied science should not be a popularity contest: not for bridges, not for Bose-Eintein condensates, not for creating, marking-up and transforming web content.

And like Pharo Smalltalk, Rebol, ICON, UNICON, ObjectIcon and Converge, Curl is evolving: a recent example is the access modifier named 'library' and 'library' as a languge primitive.

Q: has Steve Dekorte given a talk at Yahoo on his Io ? Would Ducasse come from Lille to show what his work in Berne has meant for Smalltalk ?  Or Robert Parlett for ObjectIcon ?

What Curl has rejected: continuations, coroutines, SNOBOL/ICON text strategies ...

A useful antidote: the paper on the Oz resizeable clock.  Also of note: the use of logic and constraints in Smalltalk: SOUL (Roel Wuyts), Backtalk and lisp.

Of note in Smalltalk beyond Traits: Cog VM and multi-core Squeak.

Question: should Curl be rejected over being based on an Object class?
   Note: Object has 3 public methods

Question: should Curl be rejected for using multiple inheritance?
   Note: some classes are declared as shared and implement secondary constructors
  Note: MI is used in Curl for abstract classes which serve as Mixins due to the simple rule that a single abstract method renders a class abstract.
  But: mixins ain't Traits.

Question: is Curl too-strongly typed for the server-side?

Question: should a server-side language be both distributed and offer co-routines?
Compare distributed Oz and ICON 9.5 as UNICON presses forward for concurrency changes.

Question: by the time JavaScript is as robust as Curl, will Curl still exist?  Will it have been forced merely to take a new name?

CSail refs: Curl at MIT
  with other items (PDF)
other refs: PDF at curl.com  · the first book at Amazon
On Michael Dertouzos at wikipedia.org and his book.
Other perspectives: see David Kranz, Steve Ward (2010), Ternan
The old MIT page.
Curl today (Japan) and USA.
What the Strongtalk site has as a history page.
Strongtalk at code.google.com/p/strongtalk
Eliot Miranda post.
Optimizing dynamically-typed object-oriented languages with polymorphic inline caches [1991]
David Ungar Sun patents.

What I think I 'know' about this history was told to me by a German PhD Xerox PARC researcher but I did not take notes or check facts later - so I have only hear-say from a non-participant.

Out-of-date DMOZ page for Self [ see Avocado and Lively-Kernel ] and blog.
c2.com Self page. Io page.  Pythonic Iconesque language: Converge.

See: inlining and Google V8: the history of a strategy cf: PDF and a Scientific Commons page. Many materials are Wiley, Springer or other for-pay resources.
Type Inference in Self (pdf).

Urs Hoelzle in papers at Gilad Bracha site.

Squeak Smalltalk bibliography.

Missing: a history of CSail Curl in terms of concepts, strategies, trade-offs, optimizations, performance, evolution, understandability, maintainability, limitations, regrets, bias, mistakes, economics [spin-off, acquisition, marketing]
   Web Document David Kranz and Bert Halstead
      note the history warning at its close
Kranz' diss is a Yale Computer Science Dept. tech report. I would say it is required reading for anyone interested in serious compiler technology for functional programming languages.
   see: Bert Halstead's parallel lisp

   2001 Slashdot.com 

   Kranz is named as an inventor on many issued and pending patents on the Curl technology.

See: Deirdre Blake, Dr. Dobb's Journal Jul 01, 2008 'The Architect's Role'
David Kranz is Vice President of Engineering and CTO at Curl (www.curl.com). Previously, David was a principal research scientist at MIT where he was a leader in parallel computing technology. David holds a B.A. in Mathematics and Physics from Swarthmore College, and an M.S. and Ph.D. in Computer Science from Yale University

Curl and security: http://www.dcs.bbk.ac.uk/~geoff/ForresterSecuringRIA.pdf
see also: http://www.curl.com/riasecurity/

Question: Yahoo in corporate Asia, the subcontinent and Africa: why not Curl?

Curl in public-sphere computing: the challenge of transparency while respecting genuine needs for security and privacy.

Curl and the anti-document/dark-documents in eyes-only SSB browsing.

Constraints: Alan Borning, Prologia IV, Oz clock, Backtalk

No comments: