Showing posts with label Pharo Smalltalk. Show all posts
Showing posts with label Pharo Smalltalk. Show all posts
Thursday, February 23, 2012
Lively TclTk
Lively-Kernel meets Tcl/Tk?
My latest install of Tcl/Tk 8.5 from Activestate left a link in Windows to Tk demos. One is named "A Celebration of Rube Goldberg" and should impress Self-as-JavaScript fans of Sun LivelyKernel or Avocado.
Regardless of the grief in getting Tcl with OO out of 8.6 beta, the demos are a great presentation. I continue to use Html Viewer 3 (Tcl/Tk's hv3 browser) as a light-weight browser when my laptop's sole-core is over-loaded with a few of today's greedy app's wildly swapping in and out (and no, the worst offender happens not to be from Microsoft.)
Btw, Squeak Smalltalk is working to get their base image down to about 10Mb. Remember when shared DLL's were to keep us all happy below 640K ? Gates' Hades, Hades' Gates.
PS: I have added a label/tag for Pharo Smalltalk - now the preferred ST for Seaside?
PPS: here is the Avocado blog: there.
Monday, March 14, 2011
Pharo Smalltalk 1.2RC2
Over at pharo-project.org the next release of Pharo is almost ready.
I had some issues today trying to load a MetaCello configuration of O2 - the traits-compatible version of OmniBrowser - perhaps the build already has the latest O2 ?
I did manage to load Aida/Web into the Pharo image (a separate Aida image is also available as part of the continuous build process).
This comes after a few days of freeing my PC from an attack which appears to have come through having Java enabled in default IE (although the attack began in a new Google Chrome while I was in that browser.) AVG, Ad-Aware and SpyBot were of no more help than Microsoft's Malicious Software Removal Tool. The real target appears to have been Firefox - but because I don't use it, that tampering was easier to detect in explorer alone. A few bogus DLL's and many hidden files later I appear to have survived. One casualty was my recent Google bookmarks. Browser Helper Objects. Yeah, right.
Rather than rant, this much was funny: Ad-Aware made some suggestions but also had a high-lighted "read more" which I clicked on in their application window - but it did not open a dialog - it opened IE with add-on's running! Gee, thanks, folks ....
Monday, December 20, 2010
Seaside versus Aida
The Aida 6 web framework is rather different in objectives than Seaside 3 as a Smalltalk application server. My specific interest was to determine to what extent the services for web applications were orthogonal to any given web markup. Both default to HTML but I am looking at frameworks suitable for emitting declarative Curl markup using the Curl web content language (originally MIT and now Sumisho.)
Both frameworks loaded fine into Pharo as Metacello configured packages and both had gotchas which required some experience in Smalltalk - unlike the Gofer and Metacello tools themselves.
What was distinctive in Aida was the need to make changes across many framework classes - and in Pharo Smalltalk, I can see no way to move new methods for base classes into my packages other than the *extensions mechanism.
The worst problem was an >>initialize method which started with super initialize and then failed to call a private method - the one mechanism that permits a subclass to override initialize properly ( I will submit my change as a fix.)
A serious problem was the lack of critical cleanup and reset methods ( I only needed to add one to Seaside for WAKom.) I will submit these to the Aida team.
You will not want to try to prototype anything in Aida without using the process browser tool and without running a set of >>allInstances sanity-check mthods.
The proliferation of objects comes from inadequate cleanup - but in a Version 6 of Aida may reflect the reliance on loading packages into base images. This is terrific for PITL but Smalltalk was always great for prototyping and that almost means maintaining a 'working' image - which is one way to spot objects that hang around.
In the early days of Seaside my rule was to discard any image in which Seaside had launched. For anything other than prototyping, Aida would mean working from a close-to core base image. That's just my take on what I saw after running two subclasses of SwazooSite in the same image, stopping, saving, quitting, launching ST.
And all bets are off until I have seen what a production image looks like - in the old days this was a matter of "stripping" images down - but we should now be in the age of building core images up.
I say that with a clear awareness of just how tiny servers can be in other alternative languages - such as Rebol - aside from any issues of code getting reused, code being understood and code being maintainable.
In the positive column: Aida has achieved a dialect for composing web pages which I think is on a par with Seaside. But Rebol is also great at dialecting ... so dialecting is not enough.
In secure corporate environments where Curl shines, I remain concerned with the use of a pharo.st file at startup. On the other side of that coin, the Aida tag method looks as if it should be reading from a resource file as adding a new tag should not always be a matter of changing framework level code.
At this time I have more of Curl running under Seaside but neither have the equivalent of 'halos' in Curl yet - so the jury is still out on a Smalltalk web framework for Curl markup.
Curl has great prospects in Asia, the subcontinent and Africa (most professional Curl developers are in India and Japan) wherever security is paramount.
My current work has moved from "eyes-only" document browsing* to "dark documents" on analogy with "dark matter": shedding light on a file directory or a DB table does not reveal them. The key is to make "dark documents" run light in collaborative environments. Both Smalltalk and Curl come with such excellent programmer facilities that they make a terrific match for prototyping a dark objects source and viewers. And Curl has an exisiting inheritance mechanism near to Traits and no barrier to evolution away from classic OOP (having been designed and implemented by MIT Lisp and Scheme experts at curl.com)
More to follow ...
* a early prototype for which there are links at logiquewerks.com and at aule-browser.com - both required the Curl runtime for the browser or the Curl REPL with scripted variants.
Both frameworks loaded fine into Pharo as Metacello configured packages and both had gotchas which required some experience in Smalltalk - unlike the Gofer and Metacello tools themselves.
What was distinctive in Aida was the need to make changes across many framework classes - and in Pharo Smalltalk, I can see no way to move new methods for base classes into my packages other than the *extensions mechanism.
The worst problem was an >>initialize method which started with super initialize and then failed to call a private method - the one mechanism that permits a subclass to override initialize properly ( I will submit my change as a fix.)
A serious problem was the lack of critical cleanup and reset methods ( I only needed to add one to Seaside for WAKom.) I will submit these to the Aida team.
You will not want to try to prototype anything in Aida without using the process browser tool and without running a set of >>allInstances sanity-check mthods.
The proliferation of objects comes from inadequate cleanup - but in a Version 6 of Aida may reflect the reliance on loading packages into base images. This is terrific for PITL but Smalltalk was always great for prototyping and that almost means maintaining a 'working' image - which is one way to spot objects that hang around.
In the early days of Seaside my rule was to discard any image in which Seaside had launched. For anything other than prototyping, Aida would mean working from a close-to core base image. That's just my take on what I saw after running two subclasses of SwazooSite in the same image, stopping, saving, quitting, launching ST.
And all bets are off until I have seen what a production image looks like - in the old days this was a matter of "stripping" images down - but we should now be in the age of building core images up.
I say that with a clear awareness of just how tiny servers can be in other alternative languages - such as Rebol - aside from any issues of code getting reused, code being understood and code being maintainable.
In the positive column: Aida has achieved a dialect for composing web pages which I think is on a par with Seaside. But Rebol is also great at dialecting ... so dialecting is not enough.
In secure corporate environments where Curl shines, I remain concerned with the use of a pharo.st file at startup. On the other side of that coin, the Aida tag method looks as if it should be reading from a resource file as adding a new tag should not always be a matter of changing framework level code.
At this time I have more of Curl running under Seaside but neither have the equivalent of 'halos' in Curl yet - so the jury is still out on a Smalltalk web framework for Curl markup.
Curl has great prospects in Asia, the subcontinent and Africa (most professional Curl developers are in India and Japan) wherever security is paramount.
My current work has moved from "eyes-only" document browsing* to "dark documents" on analogy with "dark matter": shedding light on a file directory or a DB table does not reveal them. The key is to make "dark documents" run light in collaborative environments. Both Smalltalk and Curl come with such excellent programmer facilities that they make a terrific match for prototyping a dark objects source and viewers. And Curl has an exisiting inheritance mechanism near to Traits and no barrier to evolution away from classic OOP (having been designed and implemented by MIT Lisp and Scheme experts at curl.com)
More to follow ...
* a early prototype for which there are links at logiquewerks.com and at aule-browser.com - both required the Curl runtime for the browser or the Curl REPL with scripted variants.
Sunday, December 19, 2010
Pharo Curl
It took some effort again to get Curl markup running as an alternative to HTML+JavaScript on Seaside 3.0 on Pharo 1.1.1 Smalltalk.
The worst nuisance was Seaside using a method named text: for the equivalent of stream nextPutAll: or document print
This is because text is a common declarative identifier in Curl markup. But it is only an annoyance and without examing available selectors at runtime or usinf perform: I can't see a workaround while leaving Seaside intact.
What was vexing was to still have to modifiy the WAAdmin class to defeat HTML-bias built into the framework. And one or two other known quirks.
If only Seaside would embrace Traits on Pharo Smalltalk! Traits would make it so clear that the choice of markup can be separated from the choice to use continuations, to use halos ...
Traits might also reduce the reliance on the Decorator pattern. In a language with late binding, this leads to odd code, such as assigning a stream to an object whose class name and instance identifier clearly mean that it is not a stream ( but of course it is a decorator of a stream.)
Traits might reduce the reliance on the visitor pattern whcih I think reduces the understandability of code far more than double-dispatch itself because of the proliferation of visitor classes. It is no longer necessary to ake a virtue of that necessity ( dare we now say, 'limitation' ?)
Many things are improved in Seaside 3.0 so that overall flipping from HTML markup to Curl goes well in the details - especially in a reduced need to subclass where closed tags happen to be identical across HTML and Curl.
It was amusing to me this time to add crlf so as to get better formatted Curl markup to inspect using the Curl source inspector - and spc to put spaces into the markup layout itself (Curl ignores whitespace the same an HTML client.)
The one concession was to use txt: to dump plain text - but super was not enough to preserve a Curl text: tag - for that I had to look at the runtime class so blocks go to text: and strings go to the canvas encoder for printing.
Curl 'attributes' (properties and options) are laid out the same as Seaside HtmlAttributes so anyone who can layout HTML for Seaside can layout Curl while remaining on 'the gentle slope' of the Curl language when used for declarative web content markup.
It still may be that Aida will be a better home for Curl poetry markup on a Pharo Smalltalk web server.
The worst nuisance was Seaside using a method named text: for the equivalent of stream nextPutAll: or document print
This is because text is a common declarative identifier in Curl markup. But it is only an annoyance and without examing available selectors at runtime or usinf perform: I can't see a workaround while leaving Seaside intact.
What was vexing was to still have to modifiy the WAAdmin class to defeat HTML-bias built into the framework. And one or two other known quirks.
If only Seaside would embrace Traits on Pharo Smalltalk! Traits would make it so clear that the choice of markup can be separated from the choice to use continuations, to use halos ...
Traits might also reduce the reliance on the Decorator pattern. In a language with late binding, this leads to odd code, such as assigning a stream to an object whose class name and instance identifier clearly mean that it is not a stream ( but of course it is a decorator of a stream.)
Traits might reduce the reliance on the visitor pattern whcih I think reduces the understandability of code far more than double-dispatch itself because of the proliferation of visitor classes. It is no longer necessary to ake a virtue of that necessity ( dare we now say, 'limitation' ?)
Many things are improved in Seaside 3.0 so that overall flipping from HTML markup to Curl goes well in the details - especially in a reduced need to subclass where closed tags happen to be identical across HTML and Curl.
It was amusing to me this time to add crlf so as to get better formatted Curl markup to inspect using the Curl source inspector - and spc to put spaces into the markup layout itself (Curl ignores whitespace the same an HTML client.)
The one concession was to use txt: to dump plain text - but super was not enough to preserve a Curl text: tag - for that I had to look at the runtime class so blocks go to text: and strings go to the canvas encoder for printing.
Curl 'attributes' (properties and options) are laid out the same as Seaside HtmlAttributes so anyone who can layout HTML for Seaside can layout Curl while remaining on 'the gentle slope' of the Curl language when used for declarative web content markup.
It still may be that Aida will be a better home for Curl poetry markup on a Pharo Smalltalk web server.
Tuesday, December 14, 2010
Pharo Smalltalk linux config
This would seem to be essential to working with Pharo Smalltalk on a daily basis on linux: pharo.st
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
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
- 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)
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
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
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.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
Programmer says: we didn't learn Smalltalk ... is that still used anywhere? It's kinda-like Prolog, but with objects, right?
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
Subscribe to:
Posts (Atom)
