Much more smoke. On Tue, Dec 1, 2009 at 3:57 PM, Randall Reetz <[email protected]>wrote:
> 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. > > randall > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
