Showing posts with label Rebol. Show all posts
Showing posts with label Rebol. Show all posts
Thursday, February 7, 2013
red PL
An improved video presentation is now on YouTube for the current state of the Red programming language.
Red is an alternative implementation of an expression-based PL, Rebol.
Red is one-level above the Red/System language that can be used for performance at a lower level.
Programming in Red does not require C or C++ or D expertise and Red retains the strengths of Rebol.
Monday, January 28, 2013
rebol r3 builds
Here are two links for current rebol r3 activity:
builds (but no 64-bit Windows)
wiki (to some extent incomplete as compared to rebol.com)
Rebol2 言語 at Rebol DocBase ( for プログラミング言語 see ja.wikipedia.org)
Labels:
opensource,
r3,
Rebol
Sunday, January 2, 2011
Rebol 2.7.8
Looks like one year after Rebol 2.7.7 here comes 2.7.8 according to Carl Sassenrath's blog.
Monday, December 13, 2010
Rebol Altme
As soon as IE hits this blogspot blogger site this PM (ADT) today, ProcessExplorer shows IE consuming almost all CPU cycles - and with no end in sight, I keep killing it. But Opera just opened on the site fine. So I won't try Chrome. No point in acting paranoid ...
And then there's Rebol. It seemed today from an announcement in the altme.com Rebol3 'world' that a testable combo of runtime+DLL+gui-code was available. But it fails immediately on any test I tried. OK - it's based on code that is not even in the R3 alpha yet, so no big deal. I'll tinker with it and someone may post something on the style issue involved (some essential path type is finding a none! value.)
But altme. This is the public face of Rebol these days. Oh vey. Not that I am so crazy about the curl.com developer site at developers.curl.com not being written in Curl ... but at least that site is largely useable and searches well with things such as google site:curl.com
Imagine (as I hop in and back out of the HTML editor in the WYSIWYG editor) - oh hang it, I give up on editing this post.
Of course what is far worse is this Google-owned blog editor in which I find myself at the moment. It repeatedly traps a user in a blockquote element or in an em element - and it is not just a problem with some one browser. It is all but impossible to post a simply formatted text without spending time in the HTML edit page. Okay. HTML is markup ...
And facebook - suddenly putting a url in a status makes it impossible to get rid of a web snippet that it shovels into the status update. Give me twitter's fewer characters any day ...
And this blog's edit interface just screwed up two "carriage returns" in a row ...
Then there is the Rebol showcase web site which is not smart enough to set the background in CSS ... such very smart and capable and inventive people but a result that looks so dumb it doesn't matter how smart it is.
But there is always Microsoft OneNote: a software pkg that by-and-large works and it mostly adequate to the task.
Question: how many x100 megabytes must an editor be so that it can format a short latin-encoded text [non-technical English] in simple paragraphs and emit it in a DOC format? It must be a Monday. And I'm north of 45 deg LAT and its both warm and raining on Dec 13. Something's not right ...
There is hope for Rebol3 GUI: I see what style code did for Curl GUI's and such chrome will do the same for Rebol GUI''s. What would be worthwhile would be for an historian of technology to document just how difficult it has been to move from Rebol2 to Rebol3 - difficult for such very bright and dedicated people.
But what explains why an altme/safeworld is so dismal: no simple reply metaphor (topics, not threads), no tagging (which is now all but universal) and no one able to step up to the plate and make a signature app outa that thing. What vexes me most is the notion that there was some advantage to be had in writing the darn thing in Rebol at the very point when it had been acknowledged that Rebol had to be significantly re-thought in order to be used for PITL.
On the positive side is the web bug tracking - but that has also become near universal.
In a sad parallel, Smalltalk is only now arriving at Metacello for a sane approach to loading Metacello packages. For years loading open-source Smalltalk packages has been a near total crap-shoot. And that from the folks who gave us class browsers, refactoring browsers, unittest frameworks, the wiki, eXtreme programming ... but Metacello configurations appears to be a strategy that is working - both for Squeak Smalltalk and for Pharo Smalltalk. Is there hope for Cincom VisualWorks Smalltalk ? Their public code repository is those nightmare in which those use it to commit code are used to it and continue to use it ("Isn't it great?") but they also wonder that Smalltalk does not catch on. Just compare Ruby gems any day. Python virtualenv may be an embarrassment that is less than a kludge, but at least it works as intended.
And then there's Rebol. It seemed today from an announcement in the altme.com Rebol3 'world' that a testable combo of runtime+DLL+gui-code was available. But it fails immediately on any test I tried. OK - it's based on code that is not even in the R3 alpha yet, so no big deal. I'll tinker with it and someone may post something on the style issue involved (some essential path type is finding a none! value.)
But altme. This is the public face of Rebol these days. Oh vey. Not that I am so crazy about the curl.com developer site at developers.curl.com not being written in Curl ... but at least that site is largely useable and searches well with things such as google site:curl.com
Imagine (as I hop in and back out of the HTML editor in the WYSIWYG editor) - oh hang it, I give up on editing this post.
Of course what is far worse is this Google-owned blog editor in which I find myself at the moment. It repeatedly traps a user in a blockquote element or in an em element - and it is not just a problem with some one browser. It is all but impossible to post a simply formatted text without spending time in the HTML edit page. Okay. HTML is markup ...
And facebook - suddenly putting a url in a status makes it impossible to get rid of a web snippet that it shovels into the status update. Give me twitter's fewer characters any day ...
And this blog's edit interface just screwed up two "carriage returns" in a row ...
Then there is the Rebol showcase web site which is not smart enough to set the background in CSS ... such very smart and capable and inventive people but a result that looks so dumb it doesn't matter how smart it is.
But there is always Microsoft OneNote: a software pkg that by-and-large works and it mostly adequate to the task.
Question: how many x100 megabytes must an editor be so that it can format a short latin-encoded text [non-technical English] in simple paragraphs and emit it in a DOC format? It must be a Monday. And I'm north of 45 deg LAT and its both warm and raining on Dec 13. Something's not right ...
There is hope for Rebol3 GUI: I see what style code did for Curl GUI's and such chrome will do the same for Rebol GUI''s. What would be worthwhile would be for an historian of technology to document just how difficult it has been to move from Rebol2 to Rebol3 - difficult for such very bright and dedicated people.
But what explains why an altme/safeworld is so dismal: no simple reply metaphor (topics, not threads), no tagging (which is now all but universal) and no one able to step up to the plate and make a signature app outa that thing. What vexes me most is the notion that there was some advantage to be had in writing the darn thing in Rebol at the very point when it had been acknowledged that Rebol had to be significantly re-thought in order to be used for PITL.
On the positive side is the web bug tracking - but that has also become near universal.
In a sad parallel, Smalltalk is only now arriving at Metacello for a sane approach to loading Metacello packages. For years loading open-source Smalltalk packages has been a near total crap-shoot. And that from the folks who gave us class browsers, refactoring browsers, unittest frameworks, the wiki, eXtreme programming ... but Metacello configurations appears to be a strategy that is working - both for Squeak Smalltalk and for Pharo Smalltalk. Is there hope for Cincom VisualWorks Smalltalk ? Their public code repository is those nightmare in which those use it to commit code are used to it and continue to use it ("Isn't it great?") but they also wonder that Smalltalk does not catch on. Just compare Ruby gems any day. Python virtualenv may be an embarrassment that is less than a kludge, but at least it works as intended.
Friday, December 10, 2010
Inspecting Global Variables in Pharo Smalltalk 1.1.1
I cannot resist posting this: it creates an interable collection of associations of all current global identifiers and their current types:
"A recipe from Squeak wiki at http://wiki.squeak.org/squeak/1824
Smalltalk keys select:
[:k | ((Smalltalk at: k) isKindOf: Class) not]
thenCollect:
[:k | k -> (Smalltalk at: k) class]
"The code is in SystemDictionary's class comment."
Smalltalk implementations and VM's are evolving - but just compare what has to be done today in other dynamic languages to achieve the same ...
One notable exception is the Io Lobby object. With a little care, the same result can be very succinct in Rebol 2.7.6. and even simpler in Rebol3.
Here is a node.js shell result on startup:
Python does have dir(obj) which is hardly a Smalltalk inspection widget ...
in JavaScript there had been access to the Arguments object for a top-level function callee/caller to get into the activation/call object - But what will that kludge's fate be now that ECMAScript5 is here and Mozilla JavaScript 2.0 is coming?
In all fairness, in Smalltalk and Rebol the unwary traditionally can clobber anything. But in Smalltalk you can inspect almost anything non-primitive - even during startup. And a bootstrapping JavaScript interpreter written in JavaScript achieves almost the same transparency. See also: The avocado variant of Lively-Kernel.
see: JavaScript Function.call and Function.apply and ECMAScrip5 Function.prototype.bind
"A recipe from Squeak wiki at http://wiki.squeak.org/squeak/1824
Smalltalk keys select:
[:k | ((Smalltalk at: k) isKindOf: Class) not]
thenCollect:
[:k | k -> (Smalltalk at: k) class]
"The code is in SystemDictionary's class comment."
Smalltalk implementations and VM's are evolving - but just compare what has to be done today in other dynamic languages to achieve the same ...
One notable exception is the Io Lobby object. With a little care, the same result can be very succinct in Rebol 2.7.6. and even simpler in Rebol3.
Here is a node.js shell result on startup:
for (var s in process) { s}In a Pharo One-Click I get an Array of 127 assocs.
'listeners'
Python does have dir(obj) which is hardly a Smalltalk inspection widget ...
in JavaScript there had been access to the Arguments object for a top-level function callee/caller to get into the activation/call object - But what will that kludge's fate be now that ECMAScript5 is here and Mozilla JavaScript 2.0 is coming?
In all fairness, in Smalltalk and Rebol the unwary traditionally can clobber anything. But in Smalltalk you can inspect almost anything non-primitive - even during startup. And a bootstrapping JavaScript interpreter written in JavaScript achieves almost the same transparency. See also: The avocado variant of Lively-Kernel.
see: JavaScript Function.call and Function.apply and ECMAScrip5 Function.prototype.bind
Friday, November 5, 2010
Seven Languages and a few questions
Pragmatic Programmer has published Bruce Tate's Seven Languages. I have some reservations.
The languages are Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Looks cool. But look again.
Clojure is something of a Lisp reincarnate. Io and Ruby are botrh Smalltalk in another guise: Ruby is Smalltalk in files à la Perl; Dekorte's Io is Smalltalk-2 (Self) + actor (but not morphic - for which see one brand of Squeak Smalltalk.)
Erlang is best understood as Prolog reduced. So what would have been beyond 1974 Prolog? Oz. Or Mercury. Or XSB. Or think outside the box with a chapter on Logtalk instead.
Scala Traits come from Squeak Smalltalk, btw.
I have no quarrel with Haskell being there, though some would argue for OCaml.
But if LISP is not there, what is Prolog doing there? Why not JESS or Drools instead? And not a single expression-based language (Rebol, ICON/UNICON ( and now ObjectIcon and Converge) or MIT Curl, the language (ww.curl.com.)
With Ruby there, we at least have a reminder that performance matters - so maybe it should have been JRuby. But I can imagine how Pythonists might feel incensed.
I would suggest 12 languages in 12 months or 3 languages in 3 months.
Take a moment to look at the comments on the Prolog N-Queens code. Is Tate claiming that the two files in question are his copyrighted code? Compare the ICON code for N-Queens and ask whether you wouldn't be better looking there for an alternative language on your shelf. And Rebol 3 is really starting to take shape over at Rebol.net, Rebol.org and Rebol.com
Most CS folks recall the course in which they were required to do some Prolog. But would they skip a chapter on JESS or Logtalk?
The real story in Prolog in the past 25 years is constraint resolution, and that can be seen best in Oz. But the reader will have to use emacs. Oops.
I don't mean to knock Amzi! Prolog for Eclipse or many of the excellent Prolog projects such as swi-prolog.org (now with UNICODE and constraint-handling rules) but I would argue that what makes SWI interesting is Logtalk - and if there is RDF in the picture, that points to XSB.
Clojure, Haskell, Io, XSB, Scala, Erlang, JESS and JRuby in 8 weeks. Ok, now I'm more likely to recommend a book.
"Clojure, F#, Io, Oz, Scala, Erlang, and JRuby in 7 months". Call it "between vacations reading-and-testing-and-coding-and-designing". And you would have my attention.
And whatever became of Tcl ( it only gave us Tk, Expect, Sqlite and now TclOO.) Oops.
Oh, and Mercury now generates Erlang in addition to C or Java.
PS
Isn't concurrency coming to UNICON? Isn't Oz now distributed Oz? Isn't ObjectIcon at code.google.com/p/objecticon
Oh - right. The cool factor. And Smalltalk itself - after giving us so much and then the RefactoringBrowser and then UnitTest and pair-programming and eXtreme Programming and the wiki at c2.com ... is not yet cool again. Might as well wait for Hermes2 on a non-Linux OS.
Oh - and Rebol is already PEG-equivalent at 300+ Kb core running with a claim to a whole 15 Mb of working memory. Hmmm.
The languages are Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby. Looks cool. But look again.
Clojure is something of a Lisp reincarnate. Io and Ruby are botrh Smalltalk in another guise: Ruby is Smalltalk in files à la Perl; Dekorte's Io is Smalltalk-2 (Self) + actor (but not morphic - for which see one brand of Squeak Smalltalk.)
Erlang is best understood as Prolog reduced. So what would have been beyond 1974 Prolog? Oz. Or Mercury. Or XSB. Or think outside the box with a chapter on Logtalk instead.
Scala Traits come from Squeak Smalltalk, btw.
I have no quarrel with Haskell being there, though some would argue for OCaml.
But if LISP is not there, what is Prolog doing there? Why not JESS or Drools instead? And not a single expression-based language (Rebol, ICON/UNICON ( and now ObjectIcon and Converge) or MIT Curl, the language (ww.curl.com.)
With Ruby there, we at least have a reminder that performance matters - so maybe it should have been JRuby. But I can imagine how Pythonists might feel incensed.
I would suggest 12 languages in 12 months or 3 languages in 3 months.
Take a moment to look at the comments on the Prolog N-Queens code. Is Tate claiming that the two files in question are his copyrighted code? Compare the ICON code for N-Queens and ask whether you wouldn't be better looking there for an alternative language on your shelf. And Rebol 3 is really starting to take shape over at Rebol.net, Rebol.org and Rebol.com
Most CS folks recall the course in which they were required to do some Prolog. But would they skip a chapter on JESS or Logtalk?
The real story in Prolog in the past 25 years is constraint resolution, and that can be seen best in Oz. But the reader will have to use emacs. Oops.
I don't mean to knock Amzi! Prolog for Eclipse or many of the excellent Prolog projects such as swi-prolog.org (now with UNICODE and constraint-handling rules) but I would argue that what makes SWI interesting is Logtalk - and if there is RDF in the picture, that points to XSB.
Clojure, Haskell, Io, XSB, Scala, Erlang, JESS and JRuby in 8 weeks. Ok, now I'm more likely to recommend a book.
"Clojure, F#, Io, Oz, Scala, Erlang, and JRuby in 7 months". Call it "between vacations reading-and-testing-and-coding-and-designing". And you would have my attention.
And whatever became of Tcl ( it only gave us Tk, Expect, Sqlite and now TclOO.) Oops.
Oh, and Mercury now generates Erlang in addition to C or Java.
PS
Isn't concurrency coming to UNICON? Isn't Oz now distributed Oz? Isn't ObjectIcon at code.google.com/p/objecticon
Oh - right. The cool factor. And Smalltalk itself - after giving us so much and then the RefactoringBrowser and then UnitTest and pair-programming and eXtreme Programming and the wiki at c2.com ... is not yet cool again. Might as well wait for Hermes2 on a non-Linux OS.
Oh - and Rebol is already PEG-equivalent at 300+ Kb core running with a claim to a whole 15 Mb of working memory. Hmmm.
Friday, September 17, 2010
Aules evolve
Over at my Aule blog I have a post on evolving an Aule as a "home page" - but one that it is with me and not at Yahoo or Google or AOL.
For some time it has been my habit to set the browser home page to a file on my PC or netbook by using an address bar entry of
Two largely ignored programming options still hold my interest: the Logtalk framework for Prolog (swi-prolog is both constraint and RDF-friendly) and Oz (rules, constraints, dataflows ... )
As Smalltalkers know, it is not just the language, it is the environment, the established patterns - and the ease of testing and debugging. I will still keep an eye on Seaside for Pharo Smalltalk and watch for Dolphin+Lesser's NG Smalltalk. But an Aule layout keeps coming back to being a structured String specification to be parsed, persisted and built. Rebol3 looks to be mired-down (the latest distraction for Carl Sassenrath is running his alpha on an Amiga before that alpha has stumbled into a first beta. Oh vey ... ) and don't hold your breath for an environment.
Parsing in Icon is almost as fine as in Rebol - and there remains in my back pocket the Qtk for Oz.
No option will be as elegant as a declarative Curl UI in a web page - so they will continue - but as an option. My next iterations are for Tcl and Ruby links over at logiquewerks.com because the Tcl aule (entry point, home page, portal, mashup) must itself evolve as Tcl 8.6 and TclOO become old-hat. And Ruby may yet get cleaned up. And then Java 7 and a VisualWorks 8. And oh yes - a Rebol 3.
For some time it has been my habit to set the browser home page to a file on my PC or netbook by using an address bar entry of
file:///c:/webpages/home.htmlor
file:///home/grs/websites/home.htmlbut those should soon go to being
aule.htmlor
aule.curlor
aule.dcurlas Aules evolve towards being user-defined entry points with access to
remote-astronomy_aule.htmland such. I had hoped to use a variant of Seaside for Smalltalk to generate these "pages" and another Squeak Smalltalk framework to make them both portable and persistent. I am now leading more towards using Robert Parlett's new variation on the Icon language and its libraries as ObjectIcon. And in time there may be Laurie Tratt's Converge.
Two largely ignored programming options still hold my interest: the Logtalk framework for Prolog (swi-prolog is both constraint and RDF-friendly) and Oz (rules, constraints, dataflows ... )
As Smalltalkers know, it is not just the language, it is the environment, the established patterns - and the ease of testing and debugging. I will still keep an eye on Seaside for Pharo Smalltalk and watch for Dolphin+Lesser's NG Smalltalk. But an Aule layout keeps coming back to being a structured String specification to be parsed, persisted and built. Rebol3 looks to be mired-down (the latest distraction for Carl Sassenrath is running his alpha on an Amiga before that alpha has stumbled into a first beta. Oh vey ... ) and don't hold your breath for an environment.
Parsing in Icon is almost as fine as in Rebol - and there remains in my back pocket the Qtk for Oz.
No option will be as elegant as a declarative Curl UI in a web page - so they will continue - but as an option. My next iterations are for Tcl and Ruby links over at logiquewerks.com because the Tcl aule (entry point, home page, portal, mashup) must itself evolve as Tcl 8.6 and TclOO become old-hat. And Ruby may yet get cleaned up. And then Java 7 and a VisualWorks 8. And oh yes - a Rebol 3.
Labels:
Aule,
Aule Browser,
aule-browser,
home page,
mashup,
ObjectIcon,
Oz,
portal,
Rebol,
RIA,
Seaside 3.0
Tuesday, August 3, 2010
Rebol Quick Reference Card
Over at rebol.com Carl Sassenrath has posted a Quick Reference Card for Rebol3. If you only use Rebol occasionally, this could be handy.
Monday, July 26, 2010
Rebol reverence and followership
I noted to the Rebol3 group at the http://www.altme.com/ Rebol world that
>> test: 42A tolerated bug in R2 becomes a revered feature in R3, no? If that is not a bug, then I may be the pope. Or is it "the caprice of the colon", otherwise known as 'the big C" ? You must excuse me, Jon Stewart just explained that science is faith and I am still in awe. Ohmmmmmmm.
== 42
>> test:none
== test:none
>> testnone
** Script error: testnone has no value
comment {test remains 42 but no error unlike, say, simple undefined testnone That missing space looks nasty when test:none should have been test: none Is this a bug in R3? test:none does not return none but instead returns test:none}
Thursday, June 17, 2010
PLT Scheme becomes Racket
PLT Scheme is not only alive and well but has a new name and home: Racket at racket-lang.org
Think hack-a-rocket or the planet-scheme.
Racket is intended to foster experimentation and innovation with domain-specific languages.
I am a big fan of the Curl programming language from curl.com because it has DSL-friendly macros and is both expression-based and functional and declarative and class-oriented.
At en.wikipedia.org you will see Racket in the multi-paradigm category when I get a moment - for now they have some discussion of this at wp.
Meanwhile Rebol3 works its way towards beta ...
Think hack-a-rocket or the planet-scheme.
Racket is intended to foster experimentation and innovation with domain-specific languages.
I am a big fan of the Curl programming language from curl.com because it has DSL-friendly macros and is both expression-based and functional and declarative and class-oriented.
At en.wikipedia.org you will see Racket in the multi-paradigm category when I get a moment - for now they have some discussion of this at wp.
Meanwhile Rebol3 works its way towards beta ...
Monday, February 22, 2010
Rebol 3, still alpha
Many mornings I begin in EeeBuntu linux on an Asus netbook and do
cd rebol3
./r3
upgrade
chat
n
first to see if there is another release of the alpha and then to check for new posts to the Rebol3 chat server.
It is not easy to form an opinion. A rebol wiki, web pages and a text chat server appear to have become an immense anchor dragging in mud, impeding the entry of a beta from being cleared into a safe harbour.
Perhaps the core of the Rebol code will see changes from struggles with a server, with multitasking issues, TCP/IP issues. Perhaps an opinion could be informed by following the new rebol3 exchanges in the R3 world at altme.com
Maybe with economies so depressed, it is possible to imagine that there is no real urgency. But the iPad is released an there is no Rebol option to Objective-C.
I am biased. My interest is held more by ObjectIcon and Curl web content for poetry and poetry translation and for the last phases of adult foreign language learning.
There are other new languages of great interest: Io and Converge among others. But as a web language, Rebol has always seemed to me to be an alternative to even Seaside in Smalltalk - and certainly an alternative to any language relying on regex.
It is not just that there is the imprint of one inventor over a group: that is the case with Io and with Falcon (the case of Icon after the death of Ralph Griswold is such a difficulty with at least three talented individuals on separate forks.) In the case of Smalltalk, there was no standard and Self, Strongtalk or Slate were promising new directions - and now there is Io.
It may be that a beta with a graphical library is closer at hand than I am aware now that so many more developers are active in building modules for the R3 core.
And doubtless a Rebol 3.1 would be the version to await for any major commercial project.
And in fairness, we are sure to see a Rebol 2.7.8 before Icon 9.5 - but still this has been a sobering story for anyone interested in the sociology of invention, if that is how best to understand such innovations as computer programming languages on the edges or margins of science. Not quite Esperanto and not the decoding of genomes. An apposite analogy escapes me.
cd rebol3
./r3
upgrade
chat
n
first to see if there is another release of the alpha and then to check for new posts to the Rebol3 chat server.
It is not easy to form an opinion. A rebol wiki, web pages and a text chat server appear to have become an immense anchor dragging in mud, impeding the entry of a beta from being cleared into a safe harbour.
Perhaps the core of the Rebol code will see changes from struggles with a server, with multitasking issues, TCP/IP issues. Perhaps an opinion could be informed by following the new rebol3 exchanges in the R3 world at altme.com
Maybe with economies so depressed, it is possible to imagine that there is no real urgency. But the iPad is released an there is no Rebol option to Objective-C.
I am biased. My interest is held more by ObjectIcon and Curl web content for poetry and poetry translation and for the last phases of adult foreign language learning.
There are other new languages of great interest: Io and Converge among others. But as a web language, Rebol has always seemed to me to be an alternative to even Seaside in Smalltalk - and certainly an alternative to any language relying on regex.
It is not just that there is the imprint of one inventor over a group: that is the case with Io and with Falcon (the case of Icon after the death of Ralph Griswold is such a difficulty with at least three talented individuals on separate forks.) In the case of Smalltalk, there was no standard and Self, Strongtalk or Slate were promising new directions - and now there is Io.
It may be that a beta with a graphical library is closer at hand than I am aware now that so many more developers are active in building modules for the R3 core.
And doubtless a Rebol 3.1 would be the version to await for any major commercial project.
And in fairness, we are sure to see a Rebol 2.7.8 before Icon 9.5 - but still this has been a sobering story for anyone interested in the sociology of invention, if that is how best to understand such innovations as computer programming languages on the edges or margins of science. Not quite Esperanto and not the decoding of genomes. An apposite analogy escapes me.
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}
Monday, October 12, 2009
curlgen using Rebol QuarterMaster
Over at aule-browser.com I have the 3.11 version of Rebol QuarterMaster generating some Curl web content.
Two minor changes were required to tweak the qm.r source for the Content-Type to be "text/vnd.curl" and to share Apache with other web frameworks. As with Django, you will need the final forward slash on the URL paths such as /qm/ or /macros/.
The QuarterMaster file structure is quite plain by the time you are 2 levels deep and it lies outside my web container. The lower level is the expected ./controllers and ./models and ./views that you would expect with a web-style MVC framework. Compared to Django on the same host, there was minimal configuration required.
The Curl code that you see at aule-browser.com/qm/ resides in an RSP file within the views/pages folder which reflects this QM install being configured to use a pages controller. That code resides in ./controllers/pages.r and is simply:
Like ICON and Curl, Rebol is a reflective expression-based object language but without ICON's keywords.
While recently ObjectIcon has brought a ICON dialect up to UNICODE, Rebol will be UNICODE with version 3.0 and will have modular facilities suited to PITL. Curl, of course, has had both since its inception almost a decade ago.
Rebol3 will see various extensions to parse which is how Rebol scans a string or series datatype. And like ICON, Rebol has many data types: I count 58 at this point of the Rebol3 alpha. In Rebol, the values have the data types and an effort has been made to provide useful types for web development, such as tag! and url!
When Rebol3 goes to beta, the author of QuarterMaster can be expected to release a new version.
When all was said and done, less effort was required to get QuarterMaster generating Curl than was required to get the same result from Django at www.aule-browser/macros/ (which is intended eventually to showcase Curl macros).
If you would like to try QuarterMaster on a localhost, I would sugggest either Jetty or the Cheyenne Rebol server. I should note that Syllable Server's documentation states that it includes the "QuarterMaster web application framework, configured to run on Cheyenne." and, at a glance, I would guess that http://www.syllable.org/ is itself running on QuarterMaster.
Two minor changes were required to tweak the qm.r source for the Content-Type to be "text/vnd.curl" and to share Apache with other web frameworks. As with Django, you will need the final forward slash on the URL paths such as /qm/ or /macros/.
The QuarterMaster file structure is quite plain by the time you are 2 levels deep and it lies outside my web container. The lower level is the expected ./controllers and ./models and ./views that you would expect with a web-style MVC framework. Compared to Django on the same host, there was minimal configuration required.
The Curl code that you see at aule-browser.com/qm/ resides in an RSP file within the views/pages folder which reflects this QM install being configured to use a pages controller. That code resides in ./controllers/pages.r and is simply:
REBOL [ title: "Pages Controller"If you are not familiar with Rebol, it is (among other uses) the scripting language of the Syllable operating system and is currently in alpha-88 and moving towards a beta for version 3.0 at http://www.rebol.net/
type: 'controller
default: "index"
]
action "index" does [
render %welcome.rsp]
Like ICON and Curl, Rebol is a reflective expression-based object language but without ICON's keywords.
While recently ObjectIcon has brought a ICON dialect up to UNICODE, Rebol will be UNICODE with version 3.0 and will have modular facilities suited to PITL. Curl, of course, has had both since its inception almost a decade ago.
Rebol3 will see various extensions to parse which is how Rebol scans a string or series datatype. And like ICON, Rebol has many data types: I count 58 at this point of the Rebol3 alpha. In Rebol, the values have the data types and an effort has been made to provide useful types for web development, such as tag! and url!
When Rebol3 goes to beta, the author of QuarterMaster can be expected to release a new version.
When all was said and done, less effort was required to get QuarterMaster generating Curl than was required to get the same result from Django at www.aule-browser/macros/ (which is intended eventually to showcase Curl macros).
If you would like to try QuarterMaster on a localhost, I would sugggest either Jetty or the Cheyenne Rebol server. I should note that Syllable Server's documentation states that it includes the "QuarterMaster web application framework, configured to run on Cheyenne." and, at a glance, I would guess that http://www.syllable.org/ is itself running on QuarterMaster.
Sunday, June 14, 2009
Curl and string-scanning
Over at the Curl Developer Center I added a comment to a post on string-scanning. I keep meaning to post on my efforts with RDF in REBOL and in Curl. But I have a few other TODO's on my GTD paths blocking my way ... now off to the first wedding of one of my own children's school friends ... tempus fugit.
Labels:
calais,
Curl,
DSL,
eRDF,
microformat,
OpenCalais,
parse,
RDF,
RDFa,
Rebol,
SearchMonkey,
TR
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.)
Saturday, February 9, 2008
CURL6 in the RIA news
There has been good news lately at the CURL.com site with Curl winning the InfoWorld 2008 RIA development platform award and with Richard Monson-Haefel coming on-board to replace the late Marc Orchant.
I continue to try to create the urban legend that CURL stands for {url
My latest enthusiasm is to see features of ICON and UNICON appear in CURL 7 as an alternative to regexp - an extension which would also see back-tracking added to CURL. There must be a way to start that rumor ...
Some other sites seem noticably quiet, such as VistaScript.net but I continue to watch the DLR site of IronPython.
It was also great to see a new Win32 package for IO available at iolanguage.com
And of course there is a lot of activity via the ALTME link of REBOL.net with the alpha-release of REBOL3 ... and that page has a link to Carl Sassenrath's Rebol3 Frontline blog.
I continue to try to create the urban legend that CURL stands for {url
My latest enthusiasm is to see features of ICON and UNICON appear in CURL 7 as an alternative to regexp - an extension which would also see back-tracking added to CURL. There must be a way to start that rumor ...
Some other sites seem noticably quiet, such as VistaScript.net but I continue to watch the DLR site of IronPython.
It was also great to see a new Win32 package for IO available at iolanguage.com
And of course there is a lot of activity via the ALTME link of REBOL.net with the alpha-release of REBOL3 ... and that page has a link to Carl Sassenrath's Rebol3 Frontline blog.
Thursday, September 13, 2007
Cool Curl 'live' code widget
Over at eclectic-pencil I have a post on a very cool Curl widget that rivals almost anything I have ever seen expand and collapse on a web page.
What I neglect to mention is that in the example, the only code to create the XMl tree is this:
Which you would be hard-pressed to beat in Seaside for Smalltalk or in Groovy. Concise.
TiScript also has an alternative DOM and some nice features as a JavaScript alternative, but Curl 5.0 is a mature, full RIA product with 'live' code for inspection and a focus on the client-side. It is almost Smalltalk but it was also built for the web (in fairness, Curl goes about as far back as Smalltalk VisualWave.)
The only cool but alive technologies as neglected as Curl 5.0 must be Gemstone/S and Rebol 2.6.3 ... and the latter is soon to be 2.7.x with 3.0 in the wings ...
Watch for a Seaside for Gemstone/S beta in the news soon ...
PS For people living on AIR and FLASH, Rebol/FLASH went 2.0 today ...
What I neglect to mention is that in the example, the only code to create the XMl tree is this:
let xmldoc:XDMDocument = {build-xml preserve-whitespace? = false, loc} || ... {XDMTreeControl open? = true, xmldoc.root}
Which you would be hard-pressed to beat in Seaside for Smalltalk or in Groovy. Concise.
TiScript also has an alternative DOM and some nice features as a JavaScript alternative, but Curl 5.0 is a mature, full RIA product with 'live' code for inspection and a focus on the client-side. It is almost Smalltalk but it was also built for the web (in fairness, Curl goes about as far back as Smalltalk VisualWave.)
The only cool but alive technologies as neglected as Curl 5.0 must be Gemstone/S and Rebol 2.6.3 ... and the latter is soon to be 2.7.x with 3.0 in the wings ...
Watch for a Seaside for Gemstone/S beta in the news soon ...
PS For people living on AIR and FLASH, Rebol/FLASH went 2.0 today ...
Labels:
client-side,
Curl,
eclectic-pencil,
GemStone,
Groovy,
Rebol,
RIA,
Seaside,
Smaltalk,
VisualWave,
XDM
Friday, August 24, 2007
Rebol dialects and Groovy builders
I am working on a blog post over at eclectic-pencil on DSL (domain-specific languages) in Rebol and Groovy. It is an area that the folks at PDC Prolog got into a few years back and that I first explored using Java + Amzi! Prolog with DCG's in Eclipse. I hope to get a piece up on Groovy and categories as mix-ins in comparison to exploring categories and protocols in Logtalk. In the meantime there is a great deal of activity on the SWI-Prolog mailing list often relating to their Java programming interface. And Plone has a new release just as I wait for Rebol3. And I have a new version of the Curl 5.0 Web SDK to check out. And the MindTouch Deki-Wiki up on VMWare as I watch for the Gemstone/S + Seaside beta. Too much!
My opinion of the out-of-print 'Official Guide' to Rebol 2.3 keeps improving: I wish I could say the same of Manning's 'Groovy In Action' or the APress 'Grails' book. Neither of my favorite bookstores had 'Programming Groovy' on the shelves, which might have been a better choice than the former. Of course there is no book on Logtalk to recommend ... yet.
My opinion of the out-of-print 'Official Guide' to Rebol 2.3 keeps improving: I wish I could say the same of Manning's 'Groovy In Action' or the APress 'Grails' book. Neither of my favorite bookstores had 'Programming Groovy' on the shelves, which might have been a better choice than the former. Of course there is no book on Logtalk to recommend ... yet.
Sunday, July 15, 2007
a note on Polymorphism in Rebol and Oz
I have put a page on Polymorphism in Rebol and Oz with some mention of Strongtalk at eclectic-pencil
It really does not do justice to the richness of Rebol and may presuppose some familiarity with Smalltalk. All are available as freeware on the web.
If you work in JavaScript or C# there will be a lot to interest you in the trio of Oz, Strongtalk and Rebol. TiScript, for example, is a JavaScript variant which rejects prototype-based in favor of simple modules.
If you are looking at the new languages coming available for .NET and VisualStudio and want to see multi-paradigm programming then Oz is the place to start.
If you find you don't quite get Oz and the whole Emacs thing, start with Rebol.
If you don't want another way to think about web programming, just an alternative to JavaScript+CSS+HTML+whatever, download the Curl RTE and IDE.
I had been almost sold on XUL + JavaScript or XAML + C# and then I took a look at both Rebol and Curl.
In the next few days I will post something on the beauty of "Quick" Tk in Oz. If you were ever taken with Logtalk+Prolog or Datalog+RDF you will appreciate td(...) and lr( ...) as td( lr( ... )) i.e. layout of widgets is top-down and left-right...
It really does not do justice to the richness of Rebol and may presuppose some familiarity with Smalltalk. All are available as freeware on the web.
If you work in JavaScript or C# there will be a lot to interest you in the trio of Oz, Strongtalk and Rebol. TiScript, for example, is a JavaScript variant which rejects prototype-based in favor of simple modules.
If you are looking at the new languages coming available for .NET and VisualStudio and want to see multi-paradigm programming then Oz is the place to start.
If you find you don't quite get Oz and the whole Emacs thing, start with Rebol.
If you don't want another way to think about web programming, just an alternative to JavaScript+CSS+HTML+whatever, download the Curl RTE and IDE.
I had been almost sold on XUL + JavaScript or XAML + C# and then I took a look at both Rebol and Curl.
In the next few days I will post something on the beauty of "Quick" Tk in Oz. If you were ever taken with Logtalk+Prolog or Datalog+RDF you will appreciate td(...) and lr( ...) as td( lr( ... )) i.e. layout of widgets is top-down and left-right...
Labels:
.NET,
AJAX,
Curl,
Javascript,
Oz,
polymorphism,
Rebol,
Smalltalk,
strongtalk,
Surge RTE,
XAML,
XUL
Subscribe to:
Posts (Atom)