Re: Smalltalk w/o IDE, etc.?

Brian Adkins escreveu:
Cesar Rabak wrote:
[snipped]


The reason I picked on that example was because the line from the Java crowd (of which I was recently a full participant!) was sometimes along the line of, "sure there's a lot of verbosity in Java, but the IDE will generate all that infrastructure for you". This is somewhat true, but it was a nice change for me to switch to a language that didn't have the extra step of having to generate boilerplate code. The difference between that and the Ruby example above is somewhat subtle but quite significant.

Again, I feel the comparison is apples with oranges. Java is a compiled language and Ruby is an interpreted scripting language (although very influenced by Smalltalk).

I fail to see what you're driving at here. Java is compiled to bytecode which is then interpreted and typically just-in-time-compiled. What does this have to do with anything? If you're familiar with Eclipse, you'd realize that the programmer is shielded from this fact - compilation is transparent and happens on the fly as you modify the program.

Because compiled languages do not give you access to the live objects. There is a lot of automagically things done behind the scenes that makes the life of the developer easier but is not the same thing.

The 'transparent' compilation is still this, compilation, your system has to be redeployed to reflect changes, whereas in Smalltalk you do it in the live system. Big productivity difference.


I plan on doing that. Because of reasons I explained earlier about the relative differences between { Ruby, Smalltalk, Lisp }, I think I'll pursue Lisp first, and then learn Smalltalk afterward. In addition to Lisp being "more different" than Ruby, it's a little easier transition since the development style is more similar.

Sorry, but no! Lisp has also the idea of a living system and the first cultural difference is the idea of the REPL (Read Evaluate Print Loop). You can have Lisp compiled as well, but REPL is the way of going Lisp!

I disagree. I've only programmed in Lisp for about a week now, but it is very similar to how I develop in Ruby. Ruby also has a REPL, it's called irb.

The irb is an interpreter, is not a live system. It may be that you still do not feel the difference because you still lack the first hand experience on that (working with the live objects) ;-)
.

Relevant Pages

  • Re: Java FACT ?
    ... used Lisp *and* Java on major projects? ... Lisp which has an Object system which in my opinion is better(more ... He also mentions Ruby which is a completely OO ... like any proper OO language would. ...
    (comp.lang.java.advocacy)
  • Re: Fwd: Lisp macros
    ... > Maybe I missed something in the discussion but I still wonder what would> be gained by having Lisp macro like capabilities in Ruby? ... Lisp macros are essentially a technique for metaprogramming. ... by making the full power of the language available at compile time. ... can have a Lisp interpreter that does no compilation (you wouldn't want it ...
    (comp.lang.ruby)
  • Re: LISP
    ... Java should generally be faster than Common ... fortunately for Common Lisp your statement is nonsense. ... compilation into assembly language (where the ahead of time compilation ... > Other language communities simply don't have the manpower to achieve the ...
    (comp.lang.lisp)
  • Re: Lisp article at IBM
    ... Apple is still providing new Java versions on Mac OS X. ... early 90's - after huge amounts of investment, ... There does seem to be some growing support for Lisp, ... lisp gains any real traction and thats mainly because of the fact ruby doesn't ...
    (comp.lang.lisp)
  • Re: JSR 270 oder was Mustang alles enthalten soll
    ... wie bei Smalltalk oder Lisp fehlt. ... Klammern usw.) und mit Java kann man in sehr kurzer Zeit auch als ... würde sich Lisp auch mehr verbreiten, wie es bei Ruby on Rails ja der Fall ...
    (de.comp.lang.java)
Loading