Smalltalk is already everything this guy thinks needs to be invented. It's extensible, flexible - and at least in VisualWorks, the sources are, in fact, stored in XML.
The move to Linux may or may not have made sense; what's clear is that the city did not actually examine the project first - they made a political decision without ever looking (seriously) at the technical issues.
Has Gosling not ever looked at Smalltalk or Lisp? Heck, even if he's got Java tunnel vision, he wouldn't need to look further than Eclipse or IntelliJ.
Closed? Which part of Open Source didn't you follow? you can get full sources to the image and VM, and change whatever you want. Heck, even for commercial systems like VisualWorks, customers or educational users can get full source - including VM sources - and make whatever changes they want.
I don't think you read the same article I did.
Smalltalk misconceptions
on
Opencroquet
·
· Score: 5, Informative
It's cool to see Smalltalk getting noticed, but the misconceptions continue to run amok. Smalltalk is not typically interpreted - like Java, it's a JIT'ed language. The major commercial versions all use a JIT, and there's an experimental one for Squeak around - check the Squeak home page at
http://www.squeak.org
If you are curious about the commercial implementations - all of which have free downloads - check out this site:
http://www.whysmalltalk.com
One interesting tidbit is that the FAB plant is what kind of software runs the FAB. Not C, not Java - Smalltalk.
For those who didn't think Smalltalk was capable of real time operations (the TI fab plants also run on Smalltalk).
I'm utterly baffled by people who are 'proud' that they haven't used the debugger.
That's write, muddle along there with the second rate tools, complacently unaware that better things exist.
No, Smallalk is not interpreted. Like Java (which copied the idea from Smalltalk and Lisp), Smalltalk is implemented on a VM, and runs with a JIT (Just in Time Compiler). This has been the case for well over a decade. It seems to be another area of widespread misunderstanding of Smalltalk.
And btw, Smalltalk runs on a JIT in both development and deployment, so there are no runtime surprises.
It all depends on the tools you use. I've been using Smalltalk for 10 years now. I've not once had to whip out paper and pencil to ponder application state; it's right there. In fact, the application isn't dead, it's still running. can change code, either in the debugger or in the code browsers, back up, and start over from any point in the stack. I can set breakpoints, watchpoints, or just interrupt the code.
In Smallalk, debugging is actuallt part of development. It's quite common to execute code you know will break in order to get into the debugger and examine running state.
Perhaps if the C language designers actually tried to learn from things Lisp and Smalltalk systems did 20 years ago, you wouldn't have o complain.
In the meantime, I'll simply enjoy the higher level of productivity...
Slashdot Mirror
Smalltalk is most certainly in use. There are multiple vendors, and two open source implementations. See:
http://www.cincomsmalltalk.com/blog/blogView
http://smalltalk.cincom.com
http://squeak.org
http://www.stic.org
for some initial pointers.Smalltalk is already everything this guy thinks needs to be invented. It's extensible, flexible - and at least in VisualWorks, the sources are, in fact, stored in XML.
http://www.cincomsmalltalk.com/blog/blogView?showC omments=true&entry=3255420977
The move to Linux may or may not have made sense; what's clear is that the city did not actually examine the project first - they made a political decision without ever looking (seriously) at the technical issues.
Has Gosling not ever looked at Smalltalk or Lisp? Heck, even if he's got Java tunnel vision, he wouldn't need to look further than Eclipse or IntelliJ.
Closed? Which part of Open Source didn't you follow? you can get full sources to the image and VM, and change whatever you want. Heck, even for commercial systems like VisualWorks, customers or educational users can get full source - including VM sources - and make whatever changes they want. I don't think you read the same article I did.
It's cool to see Smalltalk getting noticed, but the misconceptions continue to run amok. Smalltalk is not typically interpreted - like Java, it's a JIT'ed language. The major commercial versions all use a JIT, and there's an experimental one for Squeak around - check the Squeak home page at http://www.squeak.org If you are curious about the commercial implementations - all of which have free downloads - check out this site: http://www.whysmalltalk.com
One interesting tidbit is that the FAB plant is what kind of software runs the FAB. Not C, not Java - Smalltalk. For those who didn't think Smalltalk was capable of real time operations (the TI fab plants also run on Smalltalk).
Sigh. JIT = Just In Time Compiler. A JIT != an Interpreter. This is basic stuff....
I'm utterly baffled by people who are 'proud' that they haven't used the debugger. That's write, muddle along there with the second rate tools, complacently unaware that better things exist.
No, Smallalk is not interpreted. Like Java (which copied the idea from Smalltalk and Lisp), Smalltalk is implemented on a VM, and runs with a JIT (Just in Time Compiler). This has been the case for well over a decade. It seems to be another area of widespread misunderstanding of Smalltalk. And btw, Smalltalk runs on a JIT in both development and deployment, so there are no runtime surprises.
It all depends on the tools you use. I've been using Smalltalk for 10 years now. I've not once had to whip out paper and pencil to ponder application state; it's right there. In fact, the application isn't dead, it's still running. can change code, either in the debugger or in the code browsers, back up, and start over from any point in the stack. I can set breakpoints, watchpoints, or just interrupt the code. In Smallalk, debugging is actuallt part of development. It's quite common to execute code you know will break in order to get into the debugger and examine running state. Perhaps if the C language designers actually tried to learn from things Lisp and Smalltalk systems did 20 years ago, you wouldn't have o complain. In the meantime, I'll simply enjoy the higher level of productivity...
Sounds like most of the author's complaints have been addressed 20 years ago, in Smalltalk. Now maybe if Gosling had done his reading.....