ImageJ also uses AWT, not Swing. They are different UI toolkits. Swing is supposed to be nice and fancy, but it's huge, bloated, slow and uses even more memory than your little ImageJ program.
Actually, there was a successor to Forth called Fifth. Forth with OO extensions, IIRC. I've not been able to find a reference on the web, but I played around with it in the early nineties, when I was downloading every language I could find off of local BBSes.
And calling it Fifth fits more so than Further- Forth comes from the word "Fourth," as in the cardinal number. The mythology goes, the filesystem where Forth was first implemented couldn't handle a filename as long as Fourth.;) Hence, forth.
Those who are suffeciently annoyed with the cornecopia of evil known as C++ will use another language. Then there are those that think the many gotchas that make up C and C++ are fun. Those are the people that are still C++ programmers today, and have no use for this D language.
The first time I touched Smalltalk, I have immediately placed it in the category of academic curiosity (just like Prolog) because it is an interpreted language.
Smalltalk isn't interpreted. It's incrementally compiled run on top of a VM. What does that mean? Methods are compiled into bytecode and then interpreted or JITered. This is similar to Java, with the exception that there is no explicit "compile" command.
In a Smalltalk browser, when you save the method you're working on, the method is compiled, and you're alerted to any errors in your code. Now, this compilation takes a fraction of a second, even on 486. It may not feel like it's compiling, but that's only because you're used to having to take the explicit step and running gcc/g++/javac or what have you.
Considering it productive was nearly the same, IMHO, as considering QuickBASIC to be productive.
It shows you've not done more with Smalltalk than "Hello, World" examples. For application level programming, in my experience, Smalltalk is more productive than C++ and Java, given both the Smalltalk and C++/Java programmers are somewhat experienced (at least 6mos). I've been using Smalltalk for a little over a year, and am quite a bit more productive than I am with Java (3mos use), C (4 years, on and off), and C++ (2 years).
For one, there are simply not the same amount and magnitude of "gotchas" as the above listed languages/systems.
Frankly, I see C++ as mostly worthless, especially as an application's level language. The STL and other libraries don't let you escape from C++ and it's many annoyances, they just complicate things. I'd much rather be using Smalltalk (or another high-level language like Common Lisp, Ruby, Python) and writing extensions in C when neccesary.
In most Smalltalks and Lisps, there is a call-out interface, such that lib-extensions like those found in Perl, Python, and Ruby don't have to be written. You just tell the system the function signature and the name of the library.
You don't need a 1+GHz machine to run a Smalltalk system for development, or to run a Smalltalk-based app. You're too used to Java, which is still largely impractical for real-world apps.
GUI builders have been a part of Smalltalk for a while. Don't know a date though. Check out Dolphin Smalltalk for an implementation tightly integrated with Windows.
As far as there not being a place in the world for Smalltalk- bah. If you don't want to use it, don't. But please don't spread misinformation because your 20 minutes worth of experience was confusing. I understand some people are set in their ways, and prefer the way they've been doing for years- a contrived, BCPL-based syntax, and a very static, compilation based way of life. That's fine- but I'll continue using Smalltalk and getting my stuff done.
However, I mispelt Smalltalk as "Smalltlak," which is a typo, and would be taken as such by a member of the Smalltalk community. When you mispelled it, it was as SmallTalk, often taken as a sign of ignorance, rather than a simply typo. Why is that? The "proper" way is Smalltalk, but it's pretty usual for people that don't know what they're talking about, who have maybe only read about St on/. will spell it SmallTalk. No one knows why.
So, if it was a typo, my apologies, but that is my reasoning.
Smalltalk didn't come before C. C was created in 1972. There was an early version of Smalltalk called Smalltalk-72 back then (written in BCPL, IIRC), but it's not much like the version most implementations today resemble- Smalltalk-80, which was created in, 1980.
Why didn't Smalltlak take off? There are a lot of reasons, including:
Horrible business management. In some ways, it's a surprise ParcPlace didn't totally kill it. Now a days there a a few actually-free implementations as well as non-commercial versions of others that can be used for no charge.
Smalltalk (not SmallTalk) came out in 1980, and required more resources than most PCs had at the time-1 MB of RAM and a bitmapped display. By the time those were available on a good many PCs, people were already used to C and Pascal.
In what sense would you say Smalltalk "didn't grow up as much?" Smalltalk is incredibly mature and stable- so, I doubt that's what you mean.
Smalltalk is productive, in my experience. Putting Smalltalk and C in the same league is silly- at the very least, C++ and the STL would be a better comparison.
Smalltalk isn't the best for kernel-hacking or serious number crunching (F90 anyone?), but I don't claim it to be. It's a great language, a great system- one with which a person can be incredibly productive, especially in comparison to C++/STL and Java.
Not being able to spell the language's name correctly is a sign you've never actually had any experience with it.
Perhaps more demand, but when your supply is huge, more than needed, that higher demand is worthless. Smalltalk is far from as popular as Java, and there definately aren't as many Smalltalk jobs out there. But there also aren't as many Smalltalkers- so it's definately not impossible to get a job doing Smalltalk. Incidentally, Smalltalkers tend to make more money than Java and C++ coders, which are a dime a dozen now-a-days.
As a follow up mentioned, GNU Smalltalk fits in with the usual Unix environment fairly well. Squeak can run headless and run a Smalltalk text file and has a package called OSProcess that allows you to do piping and such. Furthermore, I believe VisualAge/Smalltalk and/or VisualWorks has facilities for this.
I don't use Smalltalk to script in the old-fashioned way, however. I spend a lot of my time with an image (meaning, a Smalltalk environment) open, and write, run, and debug my scripts directly out of it, rather than using an external editor.
You can look at this in the way some people spend a goodly amount of time in nothing but (X)Emacs, writing scripts in elisp.
Regardless, no where in the definition of "script" is it specified you have to be working with pipes.
I'm not sure how importing 'frederick' other than 'freddy' shows how Ruby is dynamic, but I'll assume you meant something that you didn' ttotally illustrate.
Smalltalk is just as (and more) dynamic. I work on an IRC client that's part of Squeak. Without restarting the client once, I added an a plug-in system and wrote a few sample bots. Pretty amazing. Change a method, and the next time it's called, it's using the new version. That's kind of difficult to do using Ruby, without an interactive environment, but I suppose it can be done with a TkListener or a thread taking irb-like evals on a socket.
...I personally find the "hack languages" to allow a much more natural flow between my brain and the screen, so I'd be interested in seeing how that conclusion was reached.
Different strokes for different folks, I suppose. While you seems to say that the simplicity and elegance of Lisp and Smalltalk isn't practical, it is for me- my brain thinks in such terms. Perl is, for me, in many ways almost a big of a pain in the ass as C++, because it tries way too hard to fit what Larry Wall said is the "natural flow."
One could call C++ hacked - it's "features on top of features". But than- it's the most widely use language, so I guess it _MUST_ have is strengts...
C++ is almost nothing else but a huge hack. It's only strength over other languages is backwards compatibility of a way of thinking with C. Nothing more.
Oh no! I've been writing scripts in Smalltalk! I should've been Ruby, it's "script-world equivalent" all along!
That's bunk. There's nothing other than what is "acceptable usage" in a coder's mind that makes something a "normal" or "scripting" language. Smalltalk is equpped with the tools to build large systems more so than most scripting languages like Perl, Ruby, and Python- but out of the box, I'd say it's also more equipped than C++ and Java.:)
It is simply a matter of historical fact that Python was not based upon C++. If it shares features with C++, those would probably be traced back to Simula through Modula-3. Smalltalk is also based upon Simula.
No, Smalltalk borrowed ideas from Simula. Other than the idea of classes, Smalltalk derived very little else from Simula. Most everything else came from Lisp.
If Ruby were clearly the next level, you'd be right. But Ruby has as many weaknesses relative to Python as it has strengths
No, the next level isn't Ruby. It's Smalltalk. It's Lisp. That's the point your post's parent is saying- if you can move from Perl to Python, why not go all the way to the source, to the acme of elegance and simplicity- Smalltalk or Lisp?
I'm wondering if people are afraid to learn a new way of speaking?
You bet they are! Ruby, Perl and Python are putting in terms of a contrived BCPL derived syntax Lisp and Smalltalk. They don't quite embody the semantics fully (Ruby seems about the closest), but as people are too lazy to learn a fully new way, they have to give people training syntactical wheels.
Have you ever considered that maybe these languages ARE the evolution of Lisp and Smalltalk? With all due respect to Lisp and Smalltalk, their creators didn't have the benefit of Lisp and Smalltalk when creating their languages.
I would definately agree that it's evolution, however, it's not a controlled evolution pointed forwards, like the evolutions that created Lisp and Smalltalk.
Python, Ruby, and others are adaptations of Lisp and Smalltalk to a way of thinking that people used to C and Unix can handle. Smalltalk and Lisp are too advanced and forward thinking that languages like Python and Ruby have to take a forced step backwards to accomodate those who cannot advance. It's kind of sad in a way, but I suppose it's still a step in the right direction, as there's a better chance of converting C++, Java and Perl people to Ruby than converting them to Smalltalk or Lisp, unfortunately. Better part way than none!
If Python was the result of Lisp and C++ having a baby, Ruby is the result of Perl and Smalltalk having a baby.
Which is funny, as Smalltalk itself is really a child of a Lisp mommy getting some unknown, alien artificial insemination. Some put Smalltalk in the LISP family of languages, but those who don't just avoid classifying it. Fascinating, it's family tree.
Some stupidities though -- the whole notion of making variable types case-sensitive reeks of Fortran.
That's because they're not types, they're classes. And why does that matter? Because all you reference a class by it's name- as a VARIABLE. If all Ruby variables were case-insensitive, then classes, or types as you refer to them, would also be case-insensitive.
It's simple, beautifful elegance. This is unlike other languages, where types and/or classes are an exception, aren't normal variables. There lie's power in Ruby's approach.
With appologies to Heinlein, it takes longer than a day to grok a new language.
Not always. IMO, Java built on my existing C++ and Smalltalk knowledge that it didn't really provide anything that Smalltalk (and to a lesser extent, C++) could provide- it was merely a new syntax and was a part of a different business model. For those unexposed to Smalltalk, Ruby has some aspects which may take a while to grok, but for the most part, it builds on my existing knowledge, leaving almost nothing to grok. But in many cases, it's more convenient.
I'm stil trying to get to know how to use Perl, but not just to grok it- it seems there are so many rules for every tiny thing you'd want to do that I've had to keep docs open for anything that departs from print "hello world...";
Slashdot Mirror
Even better- I was browsing the Simtel archives, and was quite amused to find a language called B-flat. :)
ImageJ also uses AWT, not Swing. They are different UI toolkits. Swing is supposed to be nice and fancy, but it's huge, bloated, slow and uses even more memory than your little ImageJ program.
And calling it Fifth fits more so than Further- Forth comes from the word "Fourth," as in the cardinal number. The mythology goes, the filesystem where Forth was first implemented couldn't handle a filename as long as Fourth. ;) Hence, forth.
After using C++ how can someone still want to use it???
Those who are suffeciently annoyed with the cornecopia of evil known as C++ will use another language. Then there are those that think the many gotchas that make up C and C++ are fun. Those are the people that are still C++ programmers today, and have no use for this D language.
Smalltalk isn't interpreted. It's incrementally compiled run on top of a VM. What does that mean? Methods are compiled into bytecode and then interpreted or JITered. This is similar to Java, with the exception that there is no explicit "compile" command.
In a Smalltalk browser, when you save the method you're working on, the method is compiled, and you're alerted to any errors in your code. Now, this compilation takes a fraction of a second, even on 486. It may not feel like it's compiling, but that's only because you're used to having to take the explicit step and running gcc/g++/javac or what have you.
Considering it productive was nearly the same, IMHO, as considering QuickBASIC to be productive.
It shows you've not done more with Smalltalk than "Hello, World" examples. For application level programming, in my experience, Smalltalk is more productive than C++ and Java, given both the Smalltalk and C++/Java programmers are somewhat experienced (at least 6mos). I've been using Smalltalk for a little over a year, and am quite a bit more productive than I am with Java (3mos use), C (4 years, on and off), and C++ (2 years). For one, there are simply not the same amount and magnitude of "gotchas" as the above listed languages/systems.
Frankly, I see C++ as mostly worthless, especially as an application's level language. The STL and other libraries don't let you escape from C++ and it's many annoyances, they just complicate things. I'd much rather be using Smalltalk (or another high-level language like Common Lisp, Ruby, Python) and writing extensions in C when neccesary.
In most Smalltalks and Lisps, there is a call-out interface, such that lib-extensions like those found in Perl, Python, and Ruby don't have to be written. You just tell the system the function signature and the name of the library.
You don't need a 1+GHz machine to run a Smalltalk system for development, or to run a Smalltalk-based app. You're too used to Java, which is still largely impractical for real-world apps.
GUI builders have been a part of Smalltalk for a while. Don't know a date though. Check out Dolphin Smalltalk for an implementation tightly integrated with Windows.
As far as there not being a place in the world for Smalltalk- bah. If you don't want to use it, don't. But please don't spread misinformation because your 20 minutes worth of experience was confusing. I understand some people are set in their ways, and prefer the way they've been doing for years- a contrived, BCPL-based syntax, and a very static, compilation based way of life. That's fine- but I'll continue using Smalltalk and getting my stuff done.
However, I mispelt Smalltalk as "Smalltlak," which is a typo, and would be taken as such by a member of the Smalltalk community. When you mispelled it, it was as SmallTalk, often taken as a sign of ignorance, rather than a simply typo. Why is that? The "proper" way is Smalltalk, but it's pretty usual for people that don't know what they're talking about, who have maybe only read about St on /. will spell it SmallTalk. No one knows why.
So, if it was a typo, my apologies, but that is my reasoning.
Amen!
Why didn't Smalltlak take off? There are a lot of reasons, including:
In what sense would you say Smalltalk "didn't grow up as much?" Smalltalk is incredibly mature and stable- so, I doubt that's what you mean.
Smalltalk is productive, in my experience. Putting Smalltalk and C in the same league is silly- at the very least, C++ and the STL would be a better comparison.
Smalltalk isn't the best for kernel-hacking or serious number crunching (F90 anyone?), but I don't claim it to be. It's a great language, a great system- one with which a person can be incredibly productive, especially in comparison to C++/STL and Java.
Not being able to spell the language's name correctly is a sign you've never actually had any experience with it.
Huh. Linux stable? Where? If it were stable, everybody would be using it instead of Windows.
Man, don't be so bitter- it's just Slashdot.
Perhaps more demand, but when your supply is huge, more than needed, that higher demand is worthless. Smalltalk is far from as popular as Java, and there definately aren't as many Smalltalk jobs out there. But there also aren't as many Smalltalkers- so it's definately not impossible to get a job doing Smalltalk. Incidentally, Smalltalkers tend to make more money than Java and C++ coders, which are a dime a dozen now-a-days.
I don't use Smalltalk to script in the old-fashioned way, however. I spend a lot of my time with an image (meaning, a Smalltalk environment) open, and write, run, and debug my scripts directly out of it, rather than using an external editor.
You can look at this in the way some people spend a goodly amount of time in nothing but (X)Emacs, writing scripts in elisp.
Regardless, no where in the definition of "script" is it specified you have to be working with pipes.
Never underestimate the power of backwards compatibility. It worked for C++, and it worked for WinDOS.
Smalltalk is just as (and more) dynamic. I work on an IRC client that's part of Squeak. Without restarting the client once, I added an a plug-in system and wrote a few sample bots. Pretty amazing. Change a method, and the next time it's called, it's using the new version. That's kind of difficult to do using Ruby, without an interactive environment, but I suppose it can be done with a TkListener or a thread taking irb-like evals on a socket.
Different strokes for different folks, I suppose. While you seems to say that the simplicity and elegance of Lisp and Smalltalk isn't practical, it is for me- my brain thinks in such terms. Perl is, for me, in many ways almost a big of a pain in the ass as C++, because it tries way too hard to fit what Larry Wall said is the "natural flow."
Jujst another perspective...
C++ is almost nothing else but a huge hack. It's only strength over other languages is backwards compatibility of a way of thinking with C. Nothing more.
That's bunk. There's nothing other than what is "acceptable usage" in a coder's mind that makes something a "normal" or "scripting" language. Smalltalk is equpped with the tools to build large systems more so than most scripting languages like Perl, Ruby, and Python- but out of the box, I'd say it's also more equipped than C++ and Java. :)
No, Smalltalk borrowed ideas from Simula. Other than the idea of classes, Smalltalk derived very little else from Simula. Most everything else came from Lisp.
No, the next level isn't Ruby. It's Smalltalk. It's Lisp. That's the point your post's parent is saying- if you can move from Perl to Python, why not go all the way to the source, to the acme of elegance and simplicity- Smalltalk or Lisp?
You bet they are! Ruby, Perl and Python are putting in terms of a contrived BCPL derived syntax Lisp and Smalltalk. They don't quite embody the semantics fully (Ruby seems about the closest), but as people are too lazy to learn a fully new way, they have to give people training syntactical wheels.
I would definately agree that it's evolution, however, it's not a controlled evolution pointed forwards, like the evolutions that created Lisp and Smalltalk.
Python, Ruby, and others are adaptations of Lisp and Smalltalk to a way of thinking that people used to C and Unix can handle. Smalltalk and Lisp are too advanced and forward thinking that languages like Python and Ruby have to take a forced step backwards to accomodate those who cannot advance. It's kind of sad in a way, but I suppose it's still a step in the right direction, as there's a better chance of converting C++, Java and Perl people to Ruby than converting them to Smalltalk or Lisp, unfortunately. Better part way than none!
Which is funny, as Smalltalk itself is really a child of a Lisp mommy getting some unknown, alien artificial insemination. Some put Smalltalk in the LISP family of languages, but those who don't just avoid classifying it. Fascinating, it's family tree.
That's because they're not types, they're classes. And why does that matter? Because all you reference a class by it's name- as a VARIABLE. If all Ruby variables were case-insensitive, then classes, or types as you refer to them, would also be case-insensitive.
It's simple, beautifful elegance. This is unlike other languages, where types and/or classes are an exception, aren't normal variables. There lie's power in Ruby's approach.
Not always. IMO, Java built on my existing C++ and Smalltalk knowledge that it didn't really provide anything that Smalltalk (and to a lesser extent, C++) could provide- it was merely a new syntax and was a part of a different business model. For those unexposed to Smalltalk, Ruby has some aspects which may take a while to grok, but for the most part, it builds on my existing knowledge, leaving almost nothing to grok. But in many cases, it's more convenient.
I'm stil trying to get to know how to use Perl, but not just to grok it- it seems there are so many rules for every tiny thing you'd want to do that I've had to keep docs open for anything that departs from print "hello world...";