Interesting blog post - comments anyone?

Randall Reetz randall at
Tue Dec 1 02:57:44 EST 2009

All decent IDEs have a robust set of programming support, and resource and project management affordances.  What matters, beyond the obvious differences defined by the language an IDE supports, and what therefore sets one IDE above another, is how well an IDE matches the personality of its language and target customer's use style.  This,  customer support, and staying contemporary with the changing world, is the arena in which rev competes and the sphere of influence about which it can rightfully brag.  Does run-rev out xtalk other xtalk IDEs?  But the question of whether xtalk is, as a category, a worthy development choice, well that is a categorical debate and has little to do with run-rev specifically.  An interpreted script-based language is a fundamentally different animal than a compiled language.  I have always been a big fan of natural language syntax programming.  I don't program for the complexity of the process.  I program for aptitude of the finished product.  I bicycle for the pain cause pain on my bicycle equals physical fitness.  But I program towards an end, and that end isn't some sort of macho need for pain.  Ultimately, I hope to find a product I can have a gentlemans conversation with and it does the heavy lifting, building the logic while we talk in broad poetic terms.  Until then, there is xtalk.  Has any xtalk support company really kept up with the potential of the pioneering direction initiated by smalltalk and hypercard?  I don't think anyone has come close.  But, the other languages are even further behind.  Have you tried C or java or lisp or how about a functional language???? Holy crap!  I don't hate "real" programmers, sometimes they dial in my intent after I have sketched it out in xtalk.  That is how I see xtalk.  As a rapid prototyping tool.  Maybe the prototype is enough to run mission critical tasks for years.  Sometimes it helps me see what not to do tomorrow.  But mostly it lowers the pain bar exposing a far larger set of solutions for the same input of time and effort.

As for the effort needed to build and maintain an interpreted execution environment... Well it is nothing less than what a compiler does except that it has to work line by line in real time at rates indistinguishable from machine binary.  Almost impossible.  And none of that comes free from apple or xerox (none legally anyway).  But at this level again there is plenty of competition.  Javascript, perl, python, visual basic.  Hell, many compiled languages now come in IDEs which allow an interpreted interactive development mode.  What sets xtalk apart is the pre-built widget objects and high level functions that can be called and controlled through intuitive english like phrases.  That and the program shell (stack) which handles the arcane and mundane so that the author can get down to the creation of domain solutions and not computer science.  In my case, the domain is computer science, and xtalk works just fine.


More information about the Use-livecode mailing list