The sourceforge.net wordlist page should be useful for anyone working in English on a lexicon with a text-oriented language such as Rebol 2, Red, Icon, UNICON, Converge or Object Icon.
I will be using a wordlist with Curl (the Curl web content language has a wrapper for zlib and has async loading so that a wordlist divided across zip files can be loaded astutely.)
Showing posts with label UNICON. Show all posts
Showing posts with label UNICON. Show all posts
Tuesday, January 3, 2012
Wednesday, June 1, 2011
Converge 1.2
A new version of the "alpha" stage or phase of the Converge programming language is available: version 1.2 at convergepl.org from Laurie Tratt.
Converge is a pythonic version of Icon (or UNICON or ObjectIcon) if you will - which is curious as Python generators probably come from Ralph Griswold and others' Icon programming language. It is prototype-based with goal-directed evaluation and generators.
Converge shares with its predecessors more than generators: it is something of a logic language almost in the way that Erlang is almost an LP. Converge uses success/failure instead of true/false and unlike the processes of Erlang, uses co-routines which can be reset.
These Icon-ic languages could be called string-oriented (and ObjectIcon is also UNICODE compliant) and descend from the efforts to replace SNOBOL4 - itself perhaps the first unintended "free" language for processing text as string data.
Converge provides an alternative to macros in the form of compile-time meta-programming. As with macros in other languages, a substitution occurs, but these CTMP substitutions are specific to this language (relying on the AST) but are called with an explicit splicing notation (in this regard I prefer Curl from www.curl.com) - they are documented with both the binary downloads and in the GIT codebase. Note: the substitutions occur before the VM has generated instructions.
In the years since the GOTO of SNOBOL was rejected by academics, layers of goto have crept into the mainstream languages first as exception handling jumps and then as aspects or as labeled break statements.
An ICON language continues to be used by one large USA agency (if one can infer from budget disclosures.)
At this time there are two mature ICON variants: Icon 9.5 and Unicon 11.7 (both freeware.)
My own preference at the moment is ObjectIcon 2.4 but if you like prototype-based over class-based then you may want to stay close to the Converge project - I know I will.
Converge is a pythonic version of Icon (or UNICON or ObjectIcon) if you will - which is curious as Python generators probably come from Ralph Griswold and others' Icon programming language. It is prototype-based with goal-directed evaluation and generators.
Converge shares with its predecessors more than generators: it is something of a logic language almost in the way that Erlang is almost an LP. Converge uses success/failure instead of true/false and unlike the processes of Erlang, uses co-routines which can be reset.
These Icon-ic languages could be called string-oriented (and ObjectIcon is also UNICODE compliant) and descend from the efforts to replace SNOBOL4 - itself perhaps the first unintended "free" language for processing text as string data.
Converge provides an alternative to macros in the form of compile-time meta-programming. As with macros in other languages, a substitution occurs, but these CTMP substitutions are specific to this language (relying on the AST) but are called with an explicit splicing notation (in this regard I prefer Curl from www.curl.com) - they are documented with both the binary downloads and in the GIT codebase. Note: the substitutions occur before the VM has generated instructions.
In the years since the GOTO of SNOBOL was rejected by academics, layers of goto have crept into the mainstream languages first as exception handling jumps and then as aspects or as labeled break statements.
An ICON language continues to be used by one large USA agency (if one can infer from budget disclosures.)
At this time there are two mature ICON variants: Icon 9.5 and Unicon 11.7 (both freeware.)
My own preference at the moment is ObjectIcon 2.4 but if you like prototype-based over class-based then you may want to stay close to the Converge project - I know I will.
Friday, February 25, 2011
Object Icon
Object Icon 2.5 is now available at code.google.com as source code.
An internet search will reveal that the choice of name for this Icon language variant may be regettable.
Ralph Griswold had wanted to keep the name of the language intact, i.e., which precluded "Icon2".
'ICONUO' might have captured ICON+Objects+UNICODE but misses the key role of succeed/fail/retry logic and the role of co-expressions in Icon.
'ICOEXP' (pronounced Eye-Ko-eX-Pea ) appears an option for internet search.
The single word 'ObjectIcon' appears to be precluded legally already. In addition, a Google search must quote, as in
"Object Icon" programming language
in order to obtain a result.
An internet search will reveal that the choice of name for this Icon language variant may be regettable.
Ralph Griswold had wanted to keep the name of the language intact, i.e., which precluded "Icon2".
'ICONUO' might have captured ICON+Objects+UNICODE but misses the key role of succeed/fail/retry logic and the role of co-expressions in Icon.
'ICOEXP' (pronounced Eye-Ko-eX-Pea ) appears an option for internet search.
The single word 'ObjectIcon' appears to be precluded legally already. In addition, a Google search must quote, as in
"Object Icon" programming language
in order to obtain a result.
Saturday, December 19, 2009
while ( write( read(resource) ) ) # no ;
#pragmatic programming
while(write(read())) may not be as succinct as the equivalent expression in Rebol, but this Icon expression - which composes correctly in ObjectIcon, UNICON, Converge and ICON itself - has an important property: it can fail and its failure is neither an exception nor an error. And until it fails, it succeeds.
Yet for all the pragmatic programmer interest in languages such as Erlang and Clojure, Icon seems to attract no interest at all (judging from activity at the code.google pages for ObjectIcon.)
Indeed, the apparent disappearance of goto as a reserved word in JavaScript-family languages (except DMDScript, where goto is implemented) would seem to indicate that the Algol-like syntax of the replacement for SNOBOL may never get the attention it deserved. GOTO is now masked as throw and try/catch and break-to-tag and the "resume-elsewhere-as-resume-next" of Icon failure may remain unknown to another generation of programmers.
When I last looked, goto remained an unused reserved word of Java, just as it was of JavaScript. For programmers who never worked with Prolog back-tracking, the idea that boolean expressions evaluate to TRUE or FALSE may seem a truism. But it remains the case that a great deal of the internet, for one striking example, depends on all manner of objects deemed "empty" to default in boolean expressions to an evaluation as FALSE.
Just as it was false that SNOBOL would never be performant (SPITBOL put that to rest but too late), so it was false that GOTO is always dangerous (and useful long jumps in C are still with us.)
There is a useful word in German, Aufhebung, which does not always translate cleanly into English: but it might be the one word to capture the response of Icon to the challenges laid before SNOBOL by Algol, Fortran, Pascal and C.
You need only consider that recent languages as advanced as Java, C#, Curl, ECMAScript, Python and Scala continue to use Regular Expressions as if there had never been a programmers' tool which was an alternative to Perl. PCRE is now an acronym if not also a shibboleth.
Icon was intended for non-computer scientists to use just as was SNOBOL before it, but even an MIT language intended for visual artists, Processing of proceessing.org, continues to advise its users to learn regexp.
Perhaps the release of ICON 9.5 (under the guidance of an award-winning CS teacher and mentor) will attract some attention. Or the future release of pythonic Converge 2.0
But I have my doubts. Perhaps it will come when an HP innovator looks at available languages for new help center software for help desks in Africa. Perhaps the interest will come from Latvia or western China. In any other area of applied science, the likes of regexp would have been gone. But we have yet to fall under the spell of some great offering us the dictum "RegExp considered harmful".
while ( write( read( responseStream ) ) )
# idiom, semi-colon terminator optional
PS
Icon: generators, iterators, practical co-routines, goal-directed evaluation, expression-based language (Carl Sturtivant, G. Townsend with others)
ObjectIcon: UNICODE Icon with classes (Robert Parlett)
Converge: pythonic Icon (Laurie Tratt)
Rebol: www.rebol.net, www.rebol.org, www.rebol.com (from Carl Sassenrath and team; now in alpha for REBOL 3 with closures and modules)
Curl: Clojure-like homiconic web content language with macros, closures, optional types and permiting scoped tags within iteration macros to facilitate expressions such as the macro {for tag=outer permitting {break tag=outer}
Yet for all the pragmatic programmer interest in languages such as Erlang and Clojure, Icon seems to attract no interest at all (judging from activity at the code.google pages for ObjectIcon.)
Indeed, the apparent disappearance of goto as a reserved word in JavaScript-family languages (except DMDScript, where goto is implemented) would seem to indicate that the Algol-like syntax of the replacement for SNOBOL may never get the attention it deserved. GOTO is now masked as throw and try/catch and break-to-tag and the "resume-elsewhere-as-resume-next" of Icon failure may remain unknown to another generation of programmers.
When I last looked, goto remained an unused reserved word of Java, just as it was of JavaScript. For programmers who never worked with Prolog back-tracking, the idea that boolean expressions evaluate to TRUE or FALSE may seem a truism. But it remains the case that a great deal of the internet, for one striking example, depends on all manner of objects deemed "empty" to default in boolean expressions to an evaluation as FALSE.
Just as it was false that SNOBOL would never be performant (SPITBOL put that to rest but too late), so it was false that GOTO is always dangerous (and useful long jumps in C are still with us.)
There is a useful word in German, Aufhebung, which does not always translate cleanly into English: but it might be the one word to capture the response of Icon to the challenges laid before SNOBOL by Algol, Fortran, Pascal and C.
You need only consider that recent languages as advanced as Java, C#, Curl, ECMAScript, Python and Scala continue to use Regular Expressions as if there had never been a programmers' tool which was an alternative to Perl. PCRE is now an acronym if not also a shibboleth.
Icon was intended for non-computer scientists to use just as was SNOBOL before it, but even an MIT language intended for visual artists, Processing of proceessing.org, continues to advise its users to learn regexp.
Perhaps the release of ICON 9.5 (under the guidance of an award-winning CS teacher and mentor) will attract some attention. Or the future release of pythonic Converge 2.0
But I have my doubts. Perhaps it will come when an HP innovator looks at available languages for new help center software for help desks in Africa. Perhaps the interest will come from Latvia or western China. In any other area of applied science, the likes of regexp would have been gone. But we have yet to fall under the spell of some great offering us the dictum "RegExp considered harmful".
while ( write( read( responseStream ) ) )
# idiom, semi-colon terminator optional
PS
Icon: generators, iterators, practical co-routines, goal-directed evaluation, expression-based language (Carl Sturtivant, G. Townsend with others)
ObjectIcon: UNICODE Icon with classes (Robert Parlett)
Converge: pythonic Icon (Laurie Tratt)
Rebol: www.rebol.net, www.rebol.org, www.rebol.com (from Carl Sassenrath and team; now in alpha for REBOL 3 with closures and modules)
Curl: Clojure-like homiconic web content language with macros, closures, optional types and permiting scoped tags within iteration macros to facilitate expressions such as the macro {for tag=outer permitting {break tag=outer}
Friday, October 23, 2009
ObjectIcon 2.0 UNICODE ICON programming language
The latest release of ObjectIcon is now at code.google which brings oit and oix up to 2.0
This release built without incident on my Ubuntu box and is running behind some scripts on my shared host site.
I have posted a request to Robert Parlett to comment on what features distinguish 2.0 from 1.4
The ICON language itself remains at 9.4.3
Other ICON variants include OOP UNICON and the more-pythonic Converge with its meta-programming features (Converge implements a complete Compile-Time Meta-Programming facility.)
Ralph Griswold and other ICON originators brought us iterators, generators, associative arrays and an alterntive logic-programming facility (Erlang is another language with a restricted or limited logic programming feature set.) ICON language features are now common in Python and Ruby but its style of logic as success-or-failure rather than true and false goes far beyond non-zero evaluating to a Boolean value as found in many other programming languages. ICON is an expression-based language (other such languages include Curl and REBOL) which leads to idioms unlike those typical of procedural languages working with a command/statement paradigm in which expression evaluation is secondary. ICON is nonetheless procedural: each program begins with
procedure main()
ICON and its follow-on variants are arguably the most neglected languages which were ever aimed to interest non-programmers.
This release built without incident on my Ubuntu box and is running behind some scripts on my shared host site.
I have posted a request to Robert Parlett to comment on what features distinguish 2.0 from 1.4
The ICON language itself remains at 9.4.3
Other ICON variants include OOP UNICON and the more-pythonic Converge with its meta-programming features (Converge implements a complete Compile-Time Meta-Programming facility.)
Ralph Griswold and other ICON originators brought us iterators, generators, associative arrays and an alterntive logic-programming facility (Erlang is another language with a restricted or limited logic programming feature set.) ICON language features are now common in Python and Ruby but its style of logic as success-or-failure rather than true and false goes far beyond non-zero evaluating to a Boolean value as found in many other programming languages. ICON is an expression-based language (other such languages include Curl and REBOL) which leads to idioms unlike those typical of procedural languages working with a command/statement paradigm in which expression evaluation is secondary. ICON is nonetheless procedural: each program begins with
procedure main()
ICON and its follow-on variants are arguably the most neglected languages which were ever aimed to interest non-programmers.
Monday, June 22, 2009
ObjectIcon is UNICODE ICON
There are recent updates to code and wiki by Robert Parlett over at the google code ObjectIcon project including UNICODE in ICON.
ucs (standing for Unicode character string) is a new builtin type, whose behaviour closely mirrors that of the conventional Icon string. It operates by providing a wrapper around a conventional [...] Icon string, which must be in utf-8 format
For SVN, you might want to use
svn checkout http://objecticon.googlecode.com/svn/trunk/ objecticon-read-only
The lack of UNICODE in UNICON has been a worry: now there is an ICON + OOP alternative. UNICODE arrived recently in swi-prolog and is now in the alpha of REBOL3.
Languages which parse strings but are not UNICODE by 2010 cannot be of much interest in their intended niche in China, India, Malaysia, Indonesia ...
Sunday, May 10, 2009
Curl RIA news
Work on a Curl refactoring project has kept me from having any time to blog, but the May 7 release of Curl 7.0 prompted me to get a bit long-winded over at www.eclectic-pencil.com
I had recently been to a Smalltalk presentation of Seaside where I thought we needed to show serious app's and not the typical "toy" applets (even if they illustrate important technical points.)
Recently I have begun to wonder how much working with developers who reject evolution as a biological fact and perhaps as a cosmological construct has also meant that I have been working with developers who reject evolution in software.
The other day we watched a large river otter crossing our path in a nature refuge: it moved rather like a sea lion. And sure enough, scientists think they have found the link between an otter ancestor and today's marine mammals. Evolution of species is not a theory. Our planet is not 5000 years old. These are the facts, but they are facts not accepted by a great many software developers here in America. I would say that if you want to hear some absurd views, spend some time in a room with a random selection of software developers ( I mean corporate employees, not independent-minded consultants.) The percentage of extremist views to be heard on any team is not representative of American society. Nor the percentage of Americans of color or of female gender. And why so few openly homosexual software developers? In testing and QA, yes. Documentation, yes. But not development. Straight and, in my experience, oddly skewed to the political and religious right. The sad truth is that corporate employment in software development, for all its "professional" trappings, is better understood as a curious form of servitude. Historically, did not the servants become the clerks and then, once again, servants? Servitude is the corporate norm. Deferential servitude and most often in the service of office politicians with little science or technology under their belts. Let alone engineering or business savvy. It is just social evolution. If you work in software development in an American corporation, these appear to be the facts. ( The first effective managing and reporting bureaucrat may have been Samuel Pepys, whose London diary remains a very revealing document. He may have been the first secretary of the British Navy to know the multiplication tables (need I remind that computing owes a great deal to the needs of naval gunnery.) The first corporations were viewed as something on the order of conspiracies to defraud the Crown, if memory serves ... gifts were the norm in doing business with government officials; Pepys borrowed large sums from his boss. I could go on ...)
But what could evolution mean in software development as an engineering practice? In aviation we have seen significant change with Cockpit Resource Management and "fly-by-wire". If you look back at Fred Brooks on teams and software, you may know that surgical teams have also evolved to where we sometimes have two or three teams in procedures that may exceed 24 hours. And we also have sobering data on surgical outcomes and post-op complications. Choose your surgeon well. But also hope that he or she operates with the assistance of a surgical specialist (thoracic, abdominal, orthopedic) and with some of the lessons learned from cockpit voice recorders on how to communicate when things start to go wrong or the unexpected happens. What is the software equivalent of a trauma team bent on stabilizing without repairing? Has software development seen a comparable revolution in securing a desired outcome?
I recently mentioned to a software development manager that one of our finest musical teams, a famous touring string quartet, is composed of individual professional musicians who avoid even staying in the same hotel. But what does the typical corporate software manager mean by "team player"? Surely they can't mean the game of candor and statistics, baseball. What do they mean? Get on board? Never second guess? And is the typical co-located software team really conducive to evolution in the design and implementation of a software product? How much of the time spent in meetings is time spent thinking about the product? And what explains the high turn-over in staff?
Over the past months I have had some contact with a very dynamic team working in an expression-based language other than Curl and I have been very impressed by their openness and their lack of "group-think". And that in a little over a year I believe their application has gone through 3 versions of a UI. And the developers are not co-located or even on the same continents.
Suppose you have a small Curl team. It should be possible to produce quickly 2 or 3 prototypes for any new web software proposal. One of those prototypes may then evolve. By which I mean that we will take the maleable "proto-product" into a few dead-ends before we find a viable implementation with a suitable memory footprint and adequate performance. And maybe in version 1.x we are still parsing XML and we have no business rules and no customizable UI templates. Version 1.x may itself be a dead-end. Better to own up to it before it is your version 2.x or even worse, your version 3.x
Taking evolution seriously may mean that the product is ready only when it is ready and not when someone in marketing said it would be ready. It may mean taking a different view of "failures" and of time over-runs. It may mean taking the long-view and not the quarterly review. And a little more candor.
If it now may make sense to talk about galactic evolution or of evolution on a cosmic scale, might it not be useful to take seriously how a rather simple prototype can evolve into a multi-faceted software suite? And more often not?
Software projects do not set out to fail, but so very many do. Perhaps one way to thrive is to be able to accept failures, but failures in shorter cycles. I think that in the case of web applications, Curl can offer something unusual in this regard. Rather like a multi-paradigm language such as Oz, Curl permits starting in a declarative mode ( and with very few type restrictions ) and then trying to tighten things up by adding restrictive directives while also decoupling classes into components and into layers. And getting it wrong, stepping back, re-assessing, and making another pass. And then seeing unexpected, unanticipated possibilities. And then flourishing as a product within your market niche or corporate division.
Curl only aims to be a secure enterprise platform. But it has worried me that its many practitioners in Japan and Korea have not insisted on obtaining a refactoring browser for the Curl IDE. It seems to me to be an essential tool for working on software that is permitted to evolve ( a great deal of Smalltalk product was not permitted to evolve: group-think dictated Java. I even once watched a PROLOG expert system for underwriters replaced by the work of DBase "Clipper" developers in need of a project. Nothing is too irrational to occur in software engineering/software management. We have Scott Adams. We need a Samuel Clemens.)
It seems time now for the Curl IDE to move into open-source. And even then it may not evolve in viable directions. But it deserves a chance at a refactoring browser and closer integration with a testing framework.
It should be clear that Smalltalk is evolving whether with traits in Squeak or with Seaside in VisualWorks as "Web Velocity" or the other directions taken in Slate and Io. Curl, on the other hand, only has one dialect and aside from emacs, has only its own IDE or an Eclipse plugin. Even if Curl the language does not evolve in the ways in which SNOBOL evolved into ICON and UNICON or in which Tcl evolved into XOTcl, Curl remains an environment in which there is an almost unique capacity to produce software which evolves: from prototype to product or from web applet to the desktop or to a unique browser variant. Most recently we see the addition of SQL on the client side. I am hopeful that we will see soon a "main-memory DB" package for Curl applets on the desktop.
More importantly it needs to emerge from the "unknown" rather as Smalltalk is emerging from the "once known".
PS
If you do not think programming languages evolve, take the time to explore the emergence of PROLOG III and PROLOG IV or the return of SNOBOL-style string processing as an option for ICON or look at what became of Smalltalk as Self and then as JavaScript and now again as Slate or IO, or Ruby or ActionScript. Examples abound.
Some languages not only seem to evolve, they transform as corporate and community assets: the two major Prolog sites almost ceased to even mention the language by name. The corporate marketing proposals to replace the name of Smalltalk or the name of Curl must recur annually if not more often. Smalltalk is a set of dialects saved from extinction by a happy mutation called Seaside. Curl is becoming a platform. Did I say the other post grew long-winded?
PPS over at James Robertson's Smalltalk blog I see his comments on time spent in the debugger and think, Ah-Hah! Time spent in the debugger in exploratory mode could be seen as accepting that software evolves ... what emerges is not always from some documents or designs but from doing the task. Murray Gell-Mann has said something similar about those who believe design certainly came first. It ain't necessarily so. So I may be wrong about the lack of attention in Curl to XUnit and an RB. Develope. Emege. Evolve. In the battle of TLA's that would be DEE versus TDD. ( I was also looking at some Frank Gehry sketches for the Waisman Museum and the ensuing maquettes, blueprint details while standing in that building.)
I had recently been to a Smalltalk presentation of Seaside where I thought we needed to show serious app's and not the typical "toy" applets (even if they illustrate important technical points.)
Recently I have begun to wonder how much working with developers who reject evolution as a biological fact and perhaps as a cosmological construct has also meant that I have been working with developers who reject evolution in software.
The other day we watched a large river otter crossing our path in a nature refuge: it moved rather like a sea lion. And sure enough, scientists think they have found the link between an otter ancestor and today's marine mammals. Evolution of species is not a theory. Our planet is not 5000 years old. These are the facts, but they are facts not accepted by a great many software developers here in America. I would say that if you want to hear some absurd views, spend some time in a room with a random selection of software developers ( I mean corporate employees, not independent-minded consultants.) The percentage of extremist views to be heard on any team is not representative of American society. Nor the percentage of Americans of color or of female gender. And why so few openly homosexual software developers? In testing and QA, yes. Documentation, yes. But not development. Straight and, in my experience, oddly skewed to the political and religious right. The sad truth is that corporate employment in software development, for all its "professional" trappings, is better understood as a curious form of servitude. Historically, did not the servants become the clerks and then, once again, servants? Servitude is the corporate norm. Deferential servitude and most often in the service of office politicians with little science or technology under their belts. Let alone engineering or business savvy. It is just social evolution. If you work in software development in an American corporation, these appear to be the facts. ( The first effective managing and reporting bureaucrat may have been Samuel Pepys, whose London diary remains a very revealing document. He may have been the first secretary of the British Navy to know the multiplication tables (need I remind that computing owes a great deal to the needs of naval gunnery.) The first corporations were viewed as something on the order of conspiracies to defraud the Crown, if memory serves ... gifts were the norm in doing business with government officials; Pepys borrowed large sums from his boss. I could go on ...)
But what could evolution mean in software development as an engineering practice? In aviation we have seen significant change with Cockpit Resource Management and "fly-by-wire". If you look back at Fred Brooks on teams and software, you may know that surgical teams have also evolved to where we sometimes have two or three teams in procedures that may exceed 24 hours. And we also have sobering data on surgical outcomes and post-op complications. Choose your surgeon well. But also hope that he or she operates with the assistance of a surgical specialist (thoracic, abdominal, orthopedic) and with some of the lessons learned from cockpit voice recorders on how to communicate when things start to go wrong or the unexpected happens. What is the software equivalent of a trauma team bent on stabilizing without repairing? Has software development seen a comparable revolution in securing a desired outcome?
I recently mentioned to a software development manager that one of our finest musical teams, a famous touring string quartet, is composed of individual professional musicians who avoid even staying in the same hotel. But what does the typical corporate software manager mean by "team player"? Surely they can't mean the game of candor and statistics, baseball. What do they mean? Get on board? Never second guess? And is the typical co-located software team really conducive to evolution in the design and implementation of a software product? How much of the time spent in meetings is time spent thinking about the product? And what explains the high turn-over in staff?
Over the past months I have had some contact with a very dynamic team working in an expression-based language other than Curl and I have been very impressed by their openness and their lack of "group-think". And that in a little over a year I believe their application has gone through 3 versions of a UI. And the developers are not co-located or even on the same continents.
Suppose you have a small Curl team. It should be possible to produce quickly 2 or 3 prototypes for any new web software proposal. One of those prototypes may then evolve. By which I mean that we will take the maleable "proto-product" into a few dead-ends before we find a viable implementation with a suitable memory footprint and adequate performance. And maybe in version 1.x we are still parsing XML and we have no business rules and no customizable UI templates. Version 1.x may itself be a dead-end. Better to own up to it before it is your version 2.x or even worse, your version 3.x
Taking evolution seriously may mean that the product is ready only when it is ready and not when someone in marketing said it would be ready. It may mean taking a different view of "failures" and of time over-runs. It may mean taking the long-view and not the quarterly review. And a little more candor.
If it now may make sense to talk about galactic evolution or of evolution on a cosmic scale, might it not be useful to take seriously how a rather simple prototype can evolve into a multi-faceted software suite? And more often not?
Software projects do not set out to fail, but so very many do. Perhaps one way to thrive is to be able to accept failures, but failures in shorter cycles. I think that in the case of web applications, Curl can offer something unusual in this regard. Rather like a multi-paradigm language such as Oz, Curl permits starting in a declarative mode ( and with very few type restrictions ) and then trying to tighten things up by adding restrictive directives while also decoupling classes into components and into layers. And getting it wrong, stepping back, re-assessing, and making another pass. And then seeing unexpected, unanticipated possibilities. And then flourishing as a product within your market niche or corporate division.
Curl only aims to be a secure enterprise platform. But it has worried me that its many practitioners in Japan and Korea have not insisted on obtaining a refactoring browser for the Curl IDE. It seems to me to be an essential tool for working on software that is permitted to evolve ( a great deal of Smalltalk product was not permitted to evolve: group-think dictated Java. I even once watched a PROLOG expert system for underwriters replaced by the work of DBase "Clipper" developers in need of a project. Nothing is too irrational to occur in software engineering/software management. We have Scott Adams. We need a Samuel Clemens.)
It seems time now for the Curl IDE to move into open-source. And even then it may not evolve in viable directions. But it deserves a chance at a refactoring browser and closer integration with a testing framework.
It should be clear that Smalltalk is evolving whether with traits in Squeak or with Seaside in VisualWorks as "Web Velocity" or the other directions taken in Slate and Io. Curl, on the other hand, only has one dialect and aside from emacs, has only its own IDE or an Eclipse plugin. Even if Curl the language does not evolve in the ways in which SNOBOL evolved into ICON and UNICON or in which Tcl evolved into XOTcl, Curl remains an environment in which there is an almost unique capacity to produce software which evolves: from prototype to product or from web applet to the desktop or to a unique browser variant. Most recently we see the addition of SQL on the client side. I am hopeful that we will see soon a "main-memory DB" package for Curl applets on the desktop.
More importantly it needs to emerge from the "unknown" rather as Smalltalk is emerging from the "once known".
PS
If you do not think programming languages evolve, take the time to explore the emergence of PROLOG III and PROLOG IV or the return of SNOBOL-style string processing as an option for ICON or look at what became of Smalltalk as Self and then as JavaScript and now again as Slate or IO, or Ruby or ActionScript. Examples abound.
Some languages not only seem to evolve, they transform as corporate and community assets: the two major Prolog sites almost ceased to even mention the language by name. The corporate marketing proposals to replace the name of Smalltalk or the name of Curl must recur annually if not more often. Smalltalk is a set of dialects saved from extinction by a happy mutation called Seaside. Curl is becoming a platform. Did I say the other post grew long-winded?
PPS over at James Robertson's Smalltalk blog I see his comments on time spent in the debugger and think, Ah-Hah! Time spent in the debugger in exploratory mode could be seen as accepting that software evolves ... what emerges is not always from some documents or designs but from doing the task. Murray Gell-Mann has said something similar about those who believe design certainly came first. It ain't necessarily so. So I may be wrong about the lack of attention in Curl to XUnit and an RB. Develope. Emege. Evolve. In the battle of TLA's that would be DEE versus TDD. ( I was also looking at some Frank Gehry sketches for the Waisman Museum and the ensuing maquettes, blueprint details while standing in that building.)
Saturday, October 25, 2008
The Future of Curl
Over at Curl I have added some comments to an invitation by Richard Monson-Haefel to weigh-in on improving Curl.
Divining the future of Curl means thinking outside the box. Here's a few attempts.
Pair up Curl as a client-side to Gemstone as has been done by Seaside.
Beef-up Curl on the client-side by getting serious about the future of expression-based languages: if there is not room in the marketplace for ICON, UNICON, REBOL and Curl then look to partner with the remnant of the ICON team at U. of Arizona.
If the Curl team cannot partner-up, then look to go beyond one of those languages by having more effective goal-oriented programming than UNICON or more user-friendly parsing than REBOL.
The option of viewing Curl as a platform and not a language seems to close off many avenues unless Curl, the platform, is able to embrace languages such as ICON which appear to be in need of a new home.
Or is there a niche for Curl in the future of Perl with Parrot, or Ruby with an industrial-quality VM, or distributed OZ?
One interesting place to look is GROK and what they are looking to do with Python ZOPE. That project alone might ensure the future of ZOPE.
Then there is RDF. Somehow RDF has become tied to clunky XML implementations or worse. Even now that W3C has embraced "sparkle" for RDF Data Access, we need not ignore the prospects for Curl as a potentially RDF-friendly language. Prima facie, ICON back-tracking and REBOL paths make either look more promising as a language. But Curl, the platform, could be a powerful starting point for a more language-neutral approach to RDF triples. Mozilla XUL has moved away from RDF (blame XML there, where the 'X' is for 'Xtra-heavy' rather than eXtensible.) The real-issue is how to effectively provide metadata. As more people look to HTML and XHTML itself as the answer, Curl appears to be a natural: Curl has always been metadata-friendly.
Curl CSPD could even be used to help ensure that meta-data that would disclose too much would be suppressed where privacy is an issue (think blogging in China and i-journalism most anywhere.)
Divining the future of Curl means thinking outside the box. Here's a few attempts.
Pair up Curl as a client-side to Gemstone as has been done by Seaside.
Beef-up Curl on the client-side by getting serious about the future of expression-based languages: if there is not room in the marketplace for ICON, UNICON, REBOL and Curl then look to partner with the remnant of the ICON team at U. of Arizona.
If the Curl team cannot partner-up, then look to go beyond one of those languages by having more effective goal-oriented programming than UNICON or more user-friendly parsing than REBOL.
The option of viewing Curl as a platform and not a language seems to close off many avenues unless Curl, the platform, is able to embrace languages such as ICON which appear to be in need of a new home.
Or is there a niche for Curl in the future of Perl with Parrot, or Ruby with an industrial-quality VM, or distributed OZ?
One interesting place to look is GROK and what they are looking to do with Python ZOPE. That project alone might ensure the future of ZOPE.
Then there is RDF. Somehow RDF has become tied to clunky XML implementations or worse. Even now that W3C has embraced "sparkle" for RDF Data Access, we need not ignore the prospects for Curl as a potentially RDF-friendly language. Prima facie, ICON back-tracking and REBOL paths make either look more promising as a language. But Curl, the platform, could be a powerful starting point for a more language-neutral approach to RDF triples. Mozilla XUL has moved away from RDF (blame XML there, where the 'X' is for 'Xtra-heavy' rather than eXtensible.) The real-issue is how to effectively provide metadata. As more people look to HTML and XHTML itself as the answer, Curl appears to be a natural: Curl has always been metadata-friendly.
Curl CSPD could even be used to help ensure that meta-data that would disclose too much would be suppressed where privacy is an issue (think blogging in China and i-journalism most anywhere.)
Subscribe to:
Posts (Atom)
