I don't understand your point at all. C or C++ is easier to just pound code in? Goodness, where do you get that idea? Smalltalk has support for incremental development, fixing in the debugger, overriding base classes where you need to - C or C++ have none of this.
Hmm - Have you taken a look at the code to see why it's slow? Most likely, the implementation is bad.
Just ponder your post: Fast enough to serve web pages, but not fast enough to render them.
So you apparently think that handling > 4 million hits per day doesn't require speed...
>Now it's one thing for people to nitpick about >the differences between C and C++, but has anyone >ever seen any implementation of Smalltalk that could be described as fast?
Sure. If you base your eval on older versions of Squeak, you'll see slow. But modern versions (i.e., all versions that sell commercially) use a JIT - just like Java. VisualWorks and VisualAge are fast - faster than Java for most operations (with the exception of primitive mathematical functions). Since most apps are database driven that's not much of an issue.
>One of my favorite stories of Squeak inefficiency >came from a conversation I overheard about one >student having a problem with Squeak running out >of memory trying to create a PostScript file. The >problem was that each time you appended to the >object, it made a copy of the original object and >then appended to the copy. These huge copies were >being passed around in memory over and over again >until the VM simply ran out of room. This >ridiculous waste of memory and CPU cycles comes >from fundamental design problems with the >language. It's wonderful but way too
>abstract to get real-world performance.
Fundamental design flaw in the language? Heck, I can find poorly written code in any language. Shall I condemn C++ based on Windows system code, or condemn Java based on early implementations of Swing? Sheesh, if that's what you think of as a language design flaw, then please stop programming now - you're dangerous;-)
James Robertson
jarober@mail.com
Slashdot Mirror
I don't understand your point at all. C or C++ is easier to just pound code in? Goodness, where do you get that idea? Smalltalk has support for incremental development, fixing in the debugger, overriding base classes where you need to - C or C++ have none of this.
Hmm - Have you taken a look at the code to see why it's slow? Most likely, the implementation is bad. Just ponder your post: Fast enough to serve web pages, but not fast enough to render them. So you apparently think that handling > 4 million hits per day doesn't require speed...
>Now it's one thing for people to nitpick about >the differences between C and C++, but has anyone >ever seen any implementation of Smalltalk that could be described as fast? Sure. If you base your eval on older versions of Squeak, you'll see slow. But modern versions (i.e., all versions that sell commercially) use a JIT - just like Java. VisualWorks and VisualAge are fast - faster than Java for most operations (with the exception of primitive mathematical functions). Since most apps are database driven that's not much of an issue. >One of my favorite stories of Squeak inefficiency >came from a conversation I overheard about one >student having a problem with Squeak running out >of memory trying to create a PostScript file. The >problem was that each time you appended to the >object, it made a copy of the original object and >then appended to the copy. These huge copies were >being passed around in memory over and over again >until the VM simply ran out of room. This >ridiculous waste of memory and CPU cycles comes >from fundamental design problems with the >language. It's wonderful but way too >abstract to get real-world performance. Fundamental design flaw in the language? Heck, I can find poorly written code in any language. Shall I condemn C++ based on Windows system code, or condemn Java based on early implementations of Swing? Sheesh, if that's what you think of as a language design flaw, then please stop programming now - you're dangerous ;-)
James Robertson
jarober@mail.com