OK, your're old fashioned. The thing I miss least is the filesystem, and make, and linking, and compiling, and running the debugger separate and using grep etc.:)
As for greping... Don't have VW up and running on this machine right now, but
load the RegExp parcel, and do something along the lines:
2 lines. As for browse all senders... er, that's written in Smalltalk, because if you'd gotten past any initial VW hurdle, you'd know that VW is written and runs in itself. You'd know that all of the code is right there. And that you can extend it, like maybe adding a menu option to do your regex search.
So, when you get done hacking your integrated filesystem/grep/regexp system together, with just a few lines of code that you can send as your buddies that they can just filein to their systems on the fly and improve their lives...
Call me new fashioned I guess.:)
And finally, we'll have to disagree on the organization flaw. Smalltalk is about messaging. Get Alan Kay's OOPSLA'97 KeyNote. It is totally appropriate, that even the everyday stuff, like looping and branching and arithmetic is ALL done via messaging. See, at the heart of most programs, they still do a lot of these sorts of things. And if there is benefit to be had from the messaging paradigm, then wouldn't you want it applied centrally, where it could have the biggest impact, not just the stuff on the edge?
So... have you experienced this personally, or just convenient FUD to back something you want to believe. Just curious.
The whole speed thing is amusing. Ken Auer once gave a tutorial where he pointed out that the big speed gains are usually to be had from new and innovative ways to solve the same problem. While at the same time, compiler writers spend lots of time eeking out funky tricks and getting excited about a few percent here and there on a spec benchmark.
So take a problem that just fundamentally breaks down well as an object solution involving lots of message dispatching. Smalltalk will do well. Very well. As the message dispatch get's more and more dynamic, as the program gets larger and larger, Smalltalk will outperform the same C++ code.
I know, your going to argue that it's just another turing complete language, and you can code it in raw C just as well, and when you finally get done, the C version will be more efficient. I will not argue this. That's if you ever get done. Alan Kay tells of Apple's "Pink" project. This was to be a revolutionary OS design. He wanted them to *at least* use Smalltalk to prototype. They wouldn't; said it was too slow. But development was slow and lots of technical hurdles. And lack of progress ultimately got the project canned. He closes with the punchline, "There's not a lot slower than never done."
Back to the new algorithms thing. It has been *my* experience that for many problems, Smalltalk allows me to think and program at a level that allows me to approach problems in a way that I just wouldn't have thought of/dared implement in C. We had a problem at work which was basically an (N^2)! algorithm. It was a real drag. It was burning over 800 seconds for 1000 inputs. So we worked out a brute force C implementation. It ran faster, like 100+ seconds. It was just a faster brute force version. Then I spent a little time looking at the ST version, began noticing some things. Noticed the problem was separable, could be pipelined and thus take advantage of some intelligent caching. It involved a specialized Dictionary implementation. Reduced the problem to N2 + N, at which point we dropped down to ~30 secs for the ST version. What was cool was how well it scaled. 4000 inputs, the brute force version (in either lang) fell apart. The optimized ST version ran fine (~280 secs). Experienced the same kind of thing with a document matching algorithm. Today we use it in image processing apps. Sure, ST stinks at batch byte bashing. But the lang is extensible, and adding your own primitive types with optimize primitive ops is easy. We're coming up with image processing algorithms that are competitors just can't. They can't abstract fast enough, they can't try new things fast enough.
I do admit, that for people that don't get objects; Smalltalk is totally unforgiving. Your code will be spaghetti, and run like a dog. But once it sinks in...:)
This is arguably good stuff. I could quible some points here and there, ultimately we'd degenerate into a discussion regarding Scott Adams ability to so avidly satire the business world.
But what about outside of the conventional business world (which was the original question)? The open source/hacker/hobbyest/Linux community. Why not there?
I have written thousands of lines of Fortran, embedded C, poured over tons of Java and C++, and done Smalltalk for 9+ years. Anywhere I *can* get Smalltalk to fit, I will use it. Why?
Because it is different. And it's probably these differences that slow its adoption by the hacker/hobbyiest community. Namely:
Everything is an object: It's all about message sending in Smalltalk. This is especially powerful in large/complex/evolutionary systems. It's also very elegant; a real sense of uniformity.
Syntax: Took me a couple of weeks to get used to it. Now I laugh at most of the others. Five reseverved keywords. The majority of the language elements in one method. Approximates natural language very well.
The Image Programing Model and IDE: Once you grok it, very powerful. But again, a hurdle that if approached with a shoehorn just punishes you. The object based browsers. People still insist on browsers that just show flat files and "jump" you to the appropriate code point when you navigate to a method. It's amusing to watch many struggle with (and ultimately reject) VAJ, which attempts to bring code navigation within reach of the 20 year old Smalltalk browsers.
It's too easy: I get a certain rush out of eeking a few percent out of an embedded C program, by playing a number of "tricks". There's a real sense of "I climbed the hill!", even though it is small. It has been fascinating to watch even some members of the Smalltalk community spend the last 5 years in Java work there tails off to come up with shoddy re-implementations of something they did easily in Smalltalk. But in Java (or C++, or whatever), it's more of a challenge. So either be prepared to discover the good ol' problems have been solved, or start solving some new ones.
Problems that have historically hindered, but no longer do:
Vendor Viability: IBM does Smalltalk. Cincom (one of the most succesful privately owned companies in the software industry) does it. The Squeak project has enjoyed quite a swell of momentum; anyone who went to ANY of the last three OOPSLAs would know this.
Speed: For raw number crunching, Smalltalkers cede to C. Most of the Smalltalk's have robust methods of integrating C code for tight/primitives to speed optimize that critical 5% of your code. And when it comes to message dispatch, Smalltalk has won a number of benchmark tests. GC implementations in the 8 major implementations leave other lang GCs behind.
Price: Squeak is open source to the bare bones. And it's extremely portable. It's been ported to a plethora of chips. The high priced vendors have come out with better pricing models (though there is still room for improvement). There are different entry price models.
OS integration: Again much improved. MT allows one to write ST DLLs (very fast too). QKS has a.NET implementation. There are Unix shell implementations. Dolphin has great Win32 integration. ST/X has a plethora of built in Linux tools.
I have watched a number of people take a run at Smalltalk. Seems that most are either wildly succesful; have the "aha" experience and fall in love. Others just never get what it is the rest of us get excited about. I have tried to track why some do and don't. The only distinguishing attribute I have been able to find is "ya gotta wanna." Those who have really had the desire to stick with and find out why a 30 year old language still has such strong advocates, is willing to eventually fall out of their box, and discover that in some cases, different has advantages. But many people can just never get beyond the differences.
It is interesting to note that in a spectrum drawn between Smalltalk and Assembly, languages have spent the last 30 years slowly evolving towards the Smalltalk end. In the end it may not be Smalltalk that we all use. But new languages will continue to be more and more like Smalltalk in spirit. Maybe Smalltalk will continue to innovate and offer these back to the evolution of mainstrema languages; maybe sufficient convergence will finally be achieved, and we'll all jump on whatever bandwagon has really caught up.
I've just been dabbling into the excellent RTL/RTAI work done. I'm using the Lineo (formerly Zentropix) distro. This candidate stuff for 2.5 - would that render these pointless? What's the difference between the two approaches?
Yes, yes! While your at it, I think it's also important to stay in line with the current trend of sticking with a command line interpreter. And that file based program model that's eons old is also a good thing to stick with to. Much better than a Smalltalk system whose syntax actually forces them to think and learn objects. Much better than an interactive image based model like Squeak where the programmer is in amongst and part of the program. These things are bad! By all means, educate them so that they deal with all of the nuances that had to be bolted on to C++ and fighting with preprocessors, etc.
Puh-Leaze! I always love to see the arguments that go along the lines "The mob is doing it, so it's good, right?"
Wondering the same thing! Scrolling down thru the suggestions, I thought I'd find Smalltalk (esp. Squeak) all over the place. I did the Basic thing. Squeak would be much better. Lots of good research gone in over the years about teaching children Smalltalk (esp. Adele Goldberg's work). Many Smalltalkers have taught their kids Smalltalk and reported favorable results. Squeak is especially wonderful because of the Morphic stuff; allows kids quick gratification/feedback.
Slashdot Mirror
My favorite soundbite (paraphrased) is the "The MicroSoft model is anti-Republican"
subject says (er, asks) it all
Firewire today (1394a) supports:
:)
100 Mb/s
200 Mb/s
400 Mb/s
1394b will support:
800 Mb/s
1.6 Gb/s
3.2 Gb/s
Which should soundly spank USB
OK, your're old fashioned. The thing I miss least is the filesystem, and make, and linking, and compiling, and running the debugger separate and using grep etc. :)
:= 'some regex statement' asRegEx.
:)
As for greping... Don't have VW up and running on this machine right now, but
load the RegExp parcel, and do something along the lines:
| exp |
exp
Browser browseMethods: (CompiledMethod allInstances select: [:each | exp match: each source]) asSortedCollection.
2 lines. As for browse all senders... er, that's written in Smalltalk, because if you'd gotten past any initial VW hurdle, you'd know that VW is written and runs in itself. You'd know that all of the code is right there. And that you can extend it, like maybe adding a menu option to do your regex search.
So, when you get done hacking your integrated filesystem/grep/regexp system together, with just a few lines of code that you can send as your buddies that they can just filein to their systems on the fly and improve their lives...
Call me new fashioned I guess.
And finally, we'll have to disagree on the organization flaw. Smalltalk is about messaging. Get Alan Kay's OOPSLA'97 KeyNote. It is totally appropriate, that even the everyday stuff, like looping and branching and arithmetic is ALL done via messaging. See, at the heart of most programs, they still do a lot of these sorts of things. And if there is benefit to be had from the messaging paradigm, then wouldn't you want it applied centrally, where it could have the biggest impact, not just the stuff on the edge?
So... have you experienced this personally, or just convenient FUD to back something you want to believe. Just curious.
:)
The whole speed thing is amusing. Ken Auer once gave a tutorial where he pointed out that the big speed gains are usually to be had from new and innovative ways to solve the same problem. While at the same time, compiler writers spend lots of time eeking out funky tricks and getting excited about a few percent here and there on a spec benchmark.
So take a problem that just fundamentally breaks down well as an object solution involving lots of message dispatching. Smalltalk will do well. Very well. As the message dispatch get's more and more dynamic, as the program gets larger and larger, Smalltalk will outperform the same C++ code.
I know, your going to argue that it's just another turing complete language, and you can code it in raw C just as well, and when you finally get done, the C version will be more efficient. I will not argue this. That's if you ever get done. Alan Kay tells of Apple's "Pink" project. This was to be a revolutionary OS design. He wanted them to *at least* use Smalltalk to prototype. They wouldn't; said it was too slow. But development was slow and lots of technical hurdles. And lack of progress ultimately got the project canned. He closes with the punchline, "There's not a lot slower than never done."
Back to the new algorithms thing. It has been *my* experience that for many problems, Smalltalk allows me to think and program at a level that allows me to approach problems in a way that I just wouldn't have thought of/dared implement in C. We had a problem at work which was basically an (N^2)! algorithm. It was a real drag. It was burning over 800 seconds for 1000 inputs. So we worked out a brute force C implementation. It ran faster, like 100+ seconds. It was just a faster brute force version. Then I spent a little time looking at the ST version, began noticing some things. Noticed the problem was separable, could be pipelined and thus take advantage of some intelligent caching. It involved a specialized Dictionary implementation. Reduced the problem to N2 + N, at which point we dropped down to ~30 secs for the ST version. What was cool was how well it scaled. 4000 inputs, the brute force version (in either lang) fell apart. The optimized ST version ran fine (~280 secs). Experienced the same kind of thing with a document matching algorithm. Today we use it in image processing apps. Sure, ST stinks at batch byte bashing. But the lang is extensible, and adding your own primitive types with optimize primitive ops is easy. We're coming up with image processing algorithms that are competitors just can't. They can't abstract fast enough, they can't try new things fast enough.
I do admit, that for people that don't get objects; Smalltalk is totally unforgiving. Your code will be spaghetti, and run like a dog. But once it sinks in...
This is arguably good stuff. I could quible some points here and there, ultimately we'd degenerate into a discussion regarding Scott Adams ability to so avidly satire the business world.
But what about outside of the conventional business world (which was the original question)? The open source/hacker/hobbyest/Linux community. Why not there?
I have written thousands of lines of Fortran, embedded C, poured over tons of Java and C++, and done Smalltalk for 9+ years. Anywhere I *can* get Smalltalk to fit, I will use it. Why? Because it is different. And it's probably these differences that slow its adoption by the hacker/hobbyiest community. Namely: Everything is an object: It's all about message sending in Smalltalk. This is especially powerful in large/complex/evolutionary systems. It's also very elegant; a real sense of uniformity. Syntax: Took me a couple of weeks to get used to it. Now I laugh at most of the others. Five reseverved keywords. The majority of the language elements in one method. Approximates natural language very well. The Image Programing Model and IDE: Once you grok it, very powerful. But again, a hurdle that if approached with a shoehorn just punishes you. The object based browsers. People still insist on browsers that just show flat files and "jump" you to the appropriate code point when you navigate to a method. It's amusing to watch many struggle with (and ultimately reject) VAJ, which attempts to bring code navigation within reach of the 20 year old Smalltalk browsers. It's too easy: I get a certain rush out of eeking a few percent out of an embedded C program, by playing a number of "tricks". There's a real sense of "I climbed the hill!", even though it is small. It has been fascinating to watch even some members of the Smalltalk community spend the last 5 years in Java work there tails off to come up with shoddy re-implementations of something they did easily in Smalltalk. But in Java (or C++, or whatever), it's more of a challenge. So either be prepared to discover the good ol' problems have been solved, or start solving some new ones. Problems that have historically hindered, but no longer do: Vendor Viability: IBM does Smalltalk. Cincom (one of the most succesful privately owned companies in the software industry) does it. The Squeak project has enjoyed quite a swell of momentum; anyone who went to ANY of the last three OOPSLAs would know this. Speed: For raw number crunching, Smalltalkers cede to C. Most of the Smalltalk's have robust methods of integrating C code for tight/primitives to speed optimize that critical 5% of your code. And when it comes to message dispatch, Smalltalk has won a number of benchmark tests. GC implementations in the 8 major implementations leave other lang GCs behind. Price: Squeak is open source to the bare bones. And it's extremely portable. It's been ported to a plethora of chips. The high priced vendors have come out with better pricing models (though there is still room for improvement). There are different entry price models. OS integration: Again much improved. MT allows one to write ST DLLs (very fast too). QKS has a .NET implementation. There are Unix shell implementations. Dolphin has great Win32 integration. ST/X has a plethora of built in Linux tools.
I have watched a number of people take a run at Smalltalk. Seems that most are either wildly succesful; have the "aha" experience and fall in love. Others just never get what it is the rest of us get excited about. I have tried to track why some do and don't. The only distinguishing attribute I have been able to find is "ya gotta wanna." Those who have really had the desire to stick with and find out why a 30 year old language still has such strong advocates, is willing to eventually fall out of their box, and discover that in some cases, different has advantages. But many people can just never get beyond the differences.
It is interesting to note that in a spectrum drawn between Smalltalk and Assembly, languages have spent the last 30 years slowly evolving towards the Smalltalk end. In the end it may not be Smalltalk that we all use. But new languages will continue to be more and more like Smalltalk in spirit. Maybe Smalltalk will continue to innovate and offer these back to the evolution of mainstrema languages; maybe sufficient convergence will finally be achieved, and we'll all jump on whatever bandwagon has really caught up.
I've just been dabbling into the excellent RTL/RTAI work done. I'm using the Lineo (formerly Zentropix) distro. This candidate stuff for 2.5 - would that render these pointless? What's the difference between the two approaches?
Yes, yes! While your at it, I think it's also important to stay in line with the current trend of sticking with a command line interpreter. And that file based program model that's eons old is also a good thing to stick with to. Much better than a Smalltalk system whose syntax actually forces them to think and learn objects. Much better than an interactive image based model like Squeak where the programmer is in amongst and part of the program. These things are bad! By all means, educate them so that they deal with all of the nuances that had to be bolted on to C++ and fighting with preprocessors, etc.
Puh-Leaze! I always love to see the arguments that go along the lines "The mob is doing it, so it's good, right?"
Wondering the same thing! Scrolling down thru the suggestions, I thought I'd find Smalltalk (esp. Squeak) all over the place. I did the Basic thing. Squeak would be much better. Lots of good research gone in over the years about teaching children Smalltalk (esp. Adele Goldberg's work). Many Smalltalkers have taught their kids Smalltalk and reported favorable results. Squeak is especially wonderful because of the Morphic stuff; allows kids quick gratification/feedback.