Gnome is the closest living relative to NeXT/OpenStep or OS/2 Warp...
Can't say I follow this. OS X is the closest living relative to OpenStep. OS/2 Warp... Perhaps eCommStation? But that's barely alive, admittedly. Either way, I wouldn't liken GNOME to either of them. GNOME is a pretty close relative to Windows, as far as how the UI works.
That's not a troll or a dis. It's not my style (I prefer NeXTSTEP and the Newton OS as models of good UI), but a lot of people have grown up with Windows 9x/NT, so it's no surprise that the majority of the users who like GNOME share this background with the majority of GNOME developers. Having actually used OS/2, NeXTSTEP, OpenStep, Rhapsody, OS X 10.x, Windows and Linux+{GNOME, KDE} extensively, I think it's safe to say that GNOME works the most like Windows. I could go on and on why, but that probably be over kill.
That said, I must say I'm pretty impressed with GNOME in RedHat 8. A lot of people hate RH for it, but I think it's quite brilliant. As a person who switched from Linux to OpenStep four years ago and then to OS X in the last few years, I became pampered with the ease of use, and most importantly, the consistency provided in OpenStep and OS X. Not to mention the great feature that things usually "just work." I left Linux because it was so bloody consistent, from a GUI user's point of view.
I've had my fill of other modern distros as well. RH8 is far from perfect, but at the very least, it provides a taste of what potential GNOME and KDE holds, a pointer to the kind of consistency that distros, GNOME, and KDE should be working towards. I fear it won't get much better, considering that all too many Linux developers seems to think that appearance is what is worth copying from OS X, while the way things work- how they feel, seems to come from Windows or CDE. Bah.
Perhaps, but that would depend on doing a bit of thinking before working on your app, rather than taking the write-code-now-think-later attitude, assuming that anyone who is worthy of running your crappy app would go to all the trouble of installing X11 in OS X just for this app.
Sure, some people will do this for some apps that are either very important, or that they're foaming at the mouth over. Most of those "some people" being ex-Linux users who find xchat 1337er than any of the irc clients available for OS X (including X-Chat Aqua!). But it seems you already know this, so why the hell am I ranting about it?:P
X11 has been available for OS X for a helluva lot longer than a year. The one-app, double-clickable OroborOSX maybe a year, but XFree86 has been around for OS X and OS X Server for two and a half years, perhaps even a bit more. It was only a few months after OS X 10.0 was released that Carmack was working on a port of XFree to OS X and Darwin in general.
Oh, come off it. Why was this marked a troll? Because I said that GNU Smalltalk isn't as good as the other options out there? Do your research- GST is really in need of a lot of work. It has potential, but most Linux users not wise enough to see the worth in having a decent Smalltalk implementation that is Free and integrated well with the Unix environment, it's no surprise it is stuck where it is.
Or was something else even more silly to made some little Lenucks haxor upset?
As someone else noted, there are Smalltalk systems which let you make apps that look and feel more like traditional WIMP apps.
As far as open source, there is GNU Smalltalk which in many ways isn't great. Mostly because it's a lot slower than the other options and it's relatively unfinished. But it has access to Tk and Gtk+, although they're a bit of a pain to get working even on a vanilla x86 system.
All the main commercial Smalltalk systems exist in seperate host windows with regular windows, including IBM VisualAge for Smalltalk, Cincom VisualWorks (there's a free non-commercial version for download running on OS X, OS 9, Linux, a bunch of Unices, and all the Windoze > 3.1), Smalltalk/X (Unices and Windoze), Smalltalk/MT and Dolphin Smalltalk. The last two have very good Windows integration, and only run on Windows.
The dialect I use, Squeak Smalltalk, runs in its own one window by default. In the case of my app, there was only one main window, along with various dialogs, so it wasn't so unnatural for my users, who are all scientists.
There has been versions of Squeak which use native widgets and seperate windows, including bindings to Qt, GTK+ and OS/2. Due to the authors falling off the 'net, they are no longer maintained. In my case for this app and my general use, I'd prefer using the Morphic GUI system than native widgets because of the enormous flexibility provided. This is imortant to me both as a developer and as an end-user. That is, I'd personally prefer all of the non-Squeak apps I used conformed to Squeak's look, feel and working-style than vise versa. But I'm a minority in that.
My use of the word "few" is misleading in and of itself. The initial prototypes and evaluation was done 1.5 years ago, summer of 2001. We looked at it again last summer (for another, but very similar project) and came to similar conclusions. Java has matured a little more between those summers, but still wouldn't be the best thing for our application.
I do computational ecology work, undergrad research assistant type stuff. A couple summers ago, I was hired to create an application for the visualization and analyzation of a few hundred MB of data- ecological, environmental and meteorlogical. While the pressure wasn't as firm as would be if I were doing work for a corporation, there was still some to use a language and toolkit that was relatively known to programmers at large.
Since we wanted the ability for this app to be worked on under a number of platforms and run on even more, we looked at a few different options. Something like {Perl,Python} + {wxWindows,Tkinter} wasn't an option at the time (and still isn't), as it doesn't run on Mac OS 9/X. With those removed, Java and Squeak Smalltalk (with the Morphic GUI environment) were the options I was considering. I did some prototyping in both Java and Squeak to test performance and ease of development for an app that was definately not run of the mill. We had to be able to exert a lot of control on the way things worked, without writing out own widgets from scratch in the areas in which we needed this. At the time, I had about the same amount of experience writing GUI apps in Java+Swing as I did with Squeak+Morphic- perhaps a bit less in Squeak.
Well, Java blew in my tests. That's not to say it doesn't work well for some things, but in the case of this client-side app, it just wouldn't have worked out. It was slow and a pain to develop for. This was a few years ago, and things haven't gotten much better, unfortunately. For the stuff we were doing- Smalltalk was working out pretty well. And it was working for us, whereas the Java prototype was wasting more and more of my time. This was supposed to be a pretty simple prototype. The last straw was when a new build of the Java version stopped working on Windows 2000, but still worked under OS X and Linux, even though it built fine under Windows and worked 30 lines of code before this build.
Being in science, not business, I luckily had the freedom to be able to dump Java for Squeak Smalltalk even though Java was a much bigger player with millions of dollars of hype behind it (as opposed to Squeak's $0). Unfortunately, most people aren't as fortunate as I, but I'm glad I did it. I learned a lot in how to build apps in Squeak, and build them pretty quickly. The flexibility of the environment and the programming system is unparalleled. Well, a good Common Lisp system may go beyond it, but that wasn't an for us.
Squeak provided an identically working app and a homogonous development environment across all the platforms I used and worked on it under, mostly Mac OS X, Mac OS 9, Linux/x86, Linux/PPC, Windows 2k and Win98. For an app like this, I preferred having a consistent L&F rather than some emulated widgets that never quite fit into the host environment, but close enough to make the situation confusing for my users. While this may be a drawback for certain types of apps, it was good in this case.
The outcome may have been different if I was just building a form-based business app, no doubt.
Learning two languages (natural or artificial) at the same time can be tricky. You have a few things going for you though, including that COBOL and VB.NET are pretty different languages, especially considering the specific features and library aspects which will be stressed in each of the classes. VB.NET will likely be app development, basic OOP,.NET library, GUI building; and COBOL likely text-interfaces, business forms, financial processing. Two relatively different problem domains.
In general, if you don't take to a learning languages well (e.g., you're not a big lang nerd!), the best thing is to study a lot. Write a lot of example code. Don't skimp on reading. The more you learn, and the firmer it is learned the better you'll be able to seperate the knowledge between languages and be able to apply it better.
Alphas with a high MIPS/Watt ratio? Nah- it might be lower than the ugliest of the x86 line, but Alphas suck energy and emit more heat than my gas water heater does... Got any numbers?
I've never ran into stability issues on OS X myself. Granted, that was under 10.0 and 10.1- I've not touched RB since upgrading to 10.2. I've made some wee apps with huge executables, due to big resources, and not run into problems even with that. *shrug*
After the PC-3, I got a second hand XT for free. Running Minix no less. That was pretty badass, I must admit. When we got the 486, I was hardc0re D0S boy, and refused to upgrade the 486 to Win95 or use Win 3.1. Until I discovered Slack and UMS-DOS, that is.:)
I know people won't be into this, considering the crowd here, but all the same:
I use Squeak Smalltalk as my cross-platform toolkit of choice. Squeak includes a cross-platform GUI toolkit, as well as a cross-platform language, IDE, runtime and configurable world of libraries. Once you get out of the rut of Tk, GTK+, etc and get used to the programming style, it makes so much sense, it's almost scary. I was doing Python+(Tkinter or wxPython) before Squeak.
What most people here will gripe about is that Squeak's GUI system, Morphic can't be called from C, C++ or Perl at this point. It's possible, but so far our users have been happy enough with Smalltalk not to move away from it. Squeak also has it's own UI look and feel- it's not Windows, Mac OS, or GTK+ in appearance. I may be in the minority, but I prefer a clean look to poorly emulated widgets. By default, the look and colors are a bit kidsy, but like everything in a Smalltalk system (ala emacs, but easier!), it's very configurable.
Squeak supports a lot more platforms that most of the combos mentioned here. Right now, Squeak supports: Mac OS X, Mac OS Classic (System 7 - OS 9; m68k and PPC), Windows >= 95, DOS, WinCE (StrongARM, XScale, MIPS, SH4), X11 on any modern Unix-like, Linux framebuffer (Linux PDAs and kiosks), SDL (lending support to PicoGUI and others), OS/2, and the Acorn RiscOS. It also runs on bare hardware on stock x86 machines, complete with drivers written in Smalltalk. There might be more, but that's should be most of them.
No, I would reccoment it to people who are wanting to create a business app for a homogonized work environment, but it has many uses.
I totally identify with your statement. I, like many got started on BASIC; in my case, it was on a really awesome Radio Shack PC-3, handheld computer with 4k of RAM.
I've used RB for whipping together Mac apps where my primary development environment, Squeak, didn't make much sense.
Worth note is that RB targets OS X, OS 9 and Windows without extra work. Coming out soon is the IDE for Windows; currently you can make Windoze apps, but not develop under Windows.
There isn't support for Linux outside of Wine thus far. I imagine RB apps work pretty swell within Wine, considering its non-reliance on many of the fancier "features" of the Windows system.
REBOL always looked pretty cool to me. Well, not always. At first, it seemed pretty ugly and special-case centrik, but when I took the time to read a bit, it was apparent that it is very much so a Scheme interpreter with some pretty darn interesting (and novel) features and a syntax that is more digestable for people coming from shitty languages. I've used it some at work solely out of pragmatism- I've been able to write little GUI apps with less code than Tk and a helluva lot less than with Perl/Tk.
That said, it is hardly without flaws. It has plenty. It's completely closed, and while I'm not the kind of purpose who bitches about that (like some of us here!), it impedes REBOL's adoption and use. I ended up more or less ditching it for my personal and work use because I can't develop for it on my Mac OS X machine, at least not with a GUI app. Sure, there's an X11 version, but because it's completely closed and they haven't recompiled it for OS X + X11, I can even run that under OS X. There's an OS 9 version, but I not starting up Classic just for REBOL.
Anyone else here looked at REBOL for more than a tiny acursory glance?
Because when Tcl first came out, it was pretty darn original. Sure, there were languages like Common Lisp and Smalltalk, but Tcl is embeddeble and works pretty well as a part of a larger system. Now a days, Smalltalks and Lisps can do that as well, and there are at least a hundred embeddeble scripting languages. But when it came out, it was original and pretty easy to write.
I mean, going from "function(param1, param2)" to "function param1 param2" can't be all *that* hard.:)
Most folks would consider Smalltalk more than just a scripting language, but it can do that easily out of the box. Heck, on my 500 MHz G3 (fast enough for me, but "lowly" to plenty of people these days), Squeak Smalltalk (a relatively slower Smalltalk compared to the commercial implementations) it only takes one second to compute 4 raisedTo: 2000, that is, 4 ** 2000. "1000 factorial" takes a couple of seconds though- but that's not all that bad considering most languages can't support such large numbers out of the box.:)
Can Rexx do that? Just out of curiousity. Smalltalk can, a lot of Lisps can, but I'd love to add other languages to the list.
Well, I think MS sees a lot of it's ASP+VBScript developers to jump to ASP.NET using COBOL as soon as they realize that C# and J# aren't the only options for coding in ASP.NET. COBOL for web apps- who has the strength not to jump ship to Microsoft's platform?:P
I agree, Lua is a pretty fun language. It's pretty darn fast, too, considering what it is. And it's small- the default binary installation is only about 200k! WOWZA! Sure, not all the libraries as Perl or Python by default, but strip anything else in the same class else down to the same functionality and it's sure to be bigger.
Then again, I'm got a big soft-spot in my heart for NewtonScript, after which Lua was modeled.:)
Am I the only one who is amused by the fact that Zope looks a lot like an attempt to make Python into a new version of Smalltalk? Except this new monster is more bloated, not as consistent or simple, and no where near as mature as a regular Smalltalk setup.
There was a time when Python was used because it was different than the other options- different than perl and Smalltalk. But so many people are just kind of hacking onto Python all the great features of Smalltalk that have been polished and matured over the last 30 years... Object databases, persistency, an actually object-based system, cutting edge virtual machine/bytecode/cross-platform technology among other things. I guess Python's syntax resembles C/C++/Java quite a bit more than Smalltalk does, and that backwards comabilitibility of mind does make a big difference to a lot of people.:)
I know about how it's full of more "real" OO than Python, but what else that is practical?
DISCLAIMER: I'm a Smalltalk programmer, and also use Perl when it's applicable. Ruby, which is referred to as (Smalltalk + Perl) / 2 in a number of places, doesn't really rub me right. Python isn't really what I want to use usually either, but it just seems a bit more... cohesive to me in the work I've done. To each her own.
PHP is the ugly sister. ASP is more like the house all those ugly sisters live in- you can have any particular sister do the work for you. (that is, you can write ASP in more than one language) Hell, with ASP.NET, at least you can use the ASP.NET/.NET API with real languages, without being restricted to the likes of JavaScript, VBScript, or PHP. Blech. You could even use COBOL with ASP.NET! WOOT! OR FORTRAN!
I do work in what could be considered bioinformatics [1]. My boss still uses awk for scripting and processing our ecological and metereological data. Hell, he even writes CGI scripts in it. When he wants to visualize what does he do? Write an AWK script that outputs a POVray file... heh. No wonder everyone was impressed when I wrote the cool Squeak app for browsing and comparing multiple plots along a transcect all in one screen and all in a couple seconds.:P
[1] Although it's not genomics or anything, rather informatics and computer science applied to ecology.
Sure, Smalltalk does rule. But it's not usually put in the category of a "scripting language." It's more than that, or at least people usually consider it as being such. I don't really see much of a difference than most modern "scripting" languages and general purpose languages, but Smalltalk is definately a general purpose language, for creating operating environments, end user apps, and web apps, rather than just scripts.
That said, you can sure use Perl and its friends for real apps, even though it can get a bit awkward compared to using a language designed for being general purpose like Smalltalk, Common Lisp or even (eww) Java.
Where can I find a package for Mac OS X 10.2 for Python+wxPython? Until then, it still won't be actually cross-platform, at least to me. Sure, it supports desktop systems running Window (93%?) and Unix (3%?) but that4% of the Mac OS is what I usually use, so as a user (and a developer), it's worth about as much as MFC until it supports my platform.:)
Slashdot Mirror
Gnome is the closest living relative to NeXT/OpenStep or OS/2 Warp...
Can't say I follow this. OS X is the closest living relative to OpenStep. OS/2 Warp... Perhaps eCommStation? But that's barely alive, admittedly. Either way, I wouldn't liken GNOME to either of them. GNOME is a pretty close relative to Windows, as far as how the UI works.
That's not a troll or a dis. It's not my style (I prefer NeXTSTEP and the Newton OS as models of good UI), but a lot of people have grown up with Windows 9x/NT, so it's no surprise that the majority of the users who like GNOME share this background with the majority of GNOME developers. Having actually used OS/2, NeXTSTEP, OpenStep, Rhapsody, OS X 10.x, Windows and Linux+{GNOME, KDE} extensively, I think it's safe to say that GNOME works the most like Windows. I could go on and on why, but that probably be over kill.
That said, I must say I'm pretty impressed with GNOME in RedHat 8. A lot of people hate RH for it, but I think it's quite brilliant. As a person who switched from Linux to OpenStep four years ago and then to OS X in the last few years, I became pampered with the ease of use, and most importantly, the consistency provided in OpenStep and OS X. Not to mention the great feature that things usually "just work." I left Linux because it was so bloody consistent, from a GUI user's point of view.
I've had my fill of other modern distros as well. RH8 is far from perfect, but at the very least, it provides a taste of what potential GNOME and KDE holds, a pointer to the kind of consistency that distros, GNOME, and KDE should be working towards. I fear it won't get much better, considering that all too many Linux developers seems to think that appearance is what is worth copying from OS X, while the way things work- how they feel, seems to come from Windows or CDE. Bah.
Read about this at this fine overview page. Yes, non-profit corporations do exist.
Perhaps, but that would depend on doing a bit of thinking before working on your app, rather than taking the write-code-now-think-later attitude, assuming that anyone who is worthy of running your crappy app would go to all the trouble of installing X11 in OS X just for this app.
:P
Sure, some people will do this for some apps that are either very important, or that they're foaming at the mouth over. Most of those "some people" being ex-Linux users who find xchat 1337er than any of the irc clients available for OS X (including X-Chat Aqua!). But it seems you already know this, so why the hell am I ranting about it?
X11 has been available for OS X for a helluva lot longer than a year. The one-app, double-clickable OroborOSX maybe a year, but XFree86 has been around for OS X and OS X Server for two and a half years, perhaps even a bit more. It was only a few months after OS X 10.0 was released that Carmack was working on a port of XFree to OS X and Darwin in general.
Oh, come off it. Why was this marked a troll? Because I said that GNU Smalltalk isn't as good as the other options out there? Do your research- GST is really in need of a lot of work. It has potential, but most Linux users not wise enough to see the worth in having a decent Smalltalk implementation that is Free and integrated well with the Unix environment, it's no surprise it is stuck where it is.
Or was something else even more silly to made some little Lenucks haxor upset?
As someone else noted, there are Smalltalk systems which let you make apps that look and feel more like traditional WIMP apps.
As far as open source, there is GNU Smalltalk which in many ways isn't great. Mostly because it's a lot slower than the other options and it's relatively unfinished. But it has access to Tk and Gtk+, although they're a bit of a pain to get working even on a vanilla x86 system.
All the main commercial Smalltalk systems exist in seperate host windows with regular windows, including IBM VisualAge for Smalltalk, Cincom VisualWorks (there's a free non-commercial version for download running on OS X, OS 9, Linux, a bunch of Unices, and all the Windoze > 3.1), Smalltalk/X (Unices and Windoze), Smalltalk/MT and Dolphin Smalltalk. The last two have very good Windows integration, and only run on Windows.
The dialect I use, Squeak Smalltalk, runs in its own one window by default. In the case of my app, there was only one main window, along with various dialogs, so it wasn't so unnatural for my users, who are all scientists.
There has been versions of Squeak which use native widgets and seperate windows, including bindings to Qt, GTK+ and OS/2. Due to the authors falling off the 'net, they are no longer maintained. In my case for this app and my general use, I'd prefer using the Morphic GUI system than native widgets because of the enormous flexibility provided. This is imortant to me both as a developer and as an end-user. That is, I'd personally prefer all of the non-Squeak apps I used conformed to Squeak's look, feel and working-style than vise versa. But I'm a minority in that.
My use of the word "few" is misleading in and of itself. The initial prototypes and evaluation was done 1.5 years ago, summer of 2001. We looked at it again last summer (for another, but very similar project) and came to similar conclusions. Java has matured a little more between those summers, but still wouldn't be the best thing for our application.
I do computational ecology work, undergrad research assistant type stuff. A couple summers ago, I was hired to create an application for the visualization and analyzation of a few hundred MB of data- ecological, environmental and meteorlogical. While the pressure wasn't as firm as would be if I were doing work for a corporation, there was still some to use a language and toolkit that was relatively known to programmers at large.
Since we wanted the ability for this app to be worked on under a number of platforms and run on even more, we looked at a few different options. Something like {Perl,Python} + {wxWindows,Tkinter} wasn't an option at the time (and still isn't), as it doesn't run on Mac OS 9/X. With those removed, Java and Squeak Smalltalk (with the Morphic GUI environment) were the options I was considering. I did some prototyping in both Java and Squeak to test performance and ease of development for an app that was definately not run of the mill. We had to be able to exert a lot of control on the way things worked, without writing out own widgets from scratch in the areas in which we needed this. At the time, I had about the same amount of experience writing GUI apps in Java+Swing as I did with Squeak+Morphic- perhaps a bit less in Squeak.
Well, Java blew in my tests. That's not to say it doesn't work well for some things, but in the case of this client-side app, it just wouldn't have worked out. It was slow and a pain to develop for. This was a few years ago, and things haven't gotten much better, unfortunately. For the stuff we were doing- Smalltalk was working out pretty well. And it was working for us, whereas the Java prototype was wasting more and more of my time. This was supposed to be a pretty simple prototype. The last straw was when a new build of the Java version stopped working on Windows 2000, but still worked under OS X and Linux, even though it built fine under Windows and worked 30 lines of code before this build.
Being in science, not business, I luckily had the freedom to be able to dump Java for Squeak Smalltalk even though Java was a much bigger player with millions of dollars of hype behind it (as opposed to Squeak's $0). Unfortunately, most people aren't as fortunate as I, but I'm glad I did it. I learned a lot in how to build apps in Squeak, and build them pretty quickly. The flexibility of the environment and the programming system is unparalleled. Well, a good Common Lisp system may go beyond it, but that wasn't an for us.
Squeak provided an identically working app and a homogonous development environment across all the platforms I used and worked on it under, mostly Mac OS X, Mac OS 9, Linux/x86, Linux/PPC, Windows 2k and Win98. For an app like this, I preferred having a consistent L&F rather than some emulated widgets that never quite fit into the host environment, but close enough to make the situation confusing for my users. While this may be a drawback for certain types of apps, it was good in this case.
The outcome may have been different if I was just building a form-based business app, no doubt.
Learning two languages (natural or artificial) at the same time can be tricky. You have a few things going for you though, including that COBOL and VB.NET are pretty different languages, especially considering the specific features and library aspects which will be stressed in each of the classes. VB.NET will likely be app development, basic OOP, .NET library, GUI building; and COBOL likely text-interfaces, business forms, financial processing. Two relatively different problem domains.
In general, if you don't take to a learning languages well (e.g., you're not a big lang nerd!), the best thing is to study a lot. Write a lot of example code. Don't skimp on reading. The more you learn, and the firmer it is learned the better you'll be able to seperate the knowledge between languages and be able to apply it better.
Alphas with a high MIPS/Watt ratio? Nah- it might be lower than the ugliest of the x86 line, but Alphas suck energy and emit more heat than my gas water heater does... Got any numbers?
I can't speak about the VIAs, but the Transmeta uses a lot more power than a StrongARM/XScale or one of these 450LPs.
I've never ran into stability issues on OS X myself. Granted, that was under 10.0 and 10.1- I've not touched RB since upgrading to 10.2. I've made some wee apps with huge executables, due to big resources, and not run into problems even with that. *shrug*
:)
After the PC-3, I got a second hand XT for free. Running Minix no less. That was pretty badass, I must admit. When we got the 486, I was hardc0re D0S boy, and refused to upgrade the 486 to Win95 or use Win 3.1. Until I discovered Slack and UMS-DOS, that is.
I know people won't be into this, considering the crowd here, but all the same:
I use Squeak Smalltalk as my cross-platform toolkit of choice. Squeak includes a cross-platform GUI toolkit, as well as a cross-platform language, IDE, runtime and configurable world of libraries. Once you get out of the rut of Tk, GTK+, etc and get used to the programming style, it makes so much sense, it's almost scary. I was doing Python+(Tkinter or wxPython) before Squeak.
What most people here will gripe about is that Squeak's GUI system, Morphic can't be called from C, C++ or Perl at this point. It's possible, but so far our users have been happy enough with Smalltalk not to move away from it. Squeak also has it's own UI look and feel- it's not Windows, Mac OS, or GTK+ in appearance. I may be in the minority, but I prefer a clean look to poorly emulated widgets. By default, the look and colors are a bit kidsy, but like everything in a Smalltalk system (ala emacs, but easier!), it's very configurable.
Squeak supports a lot more platforms that most of the combos mentioned here. Right now, Squeak supports: Mac OS X, Mac OS Classic (System 7 - OS 9; m68k and PPC), Windows >= 95, DOS, WinCE (StrongARM, XScale, MIPS, SH4), X11 on any modern Unix-like, Linux framebuffer (Linux PDAs and kiosks), SDL (lending support to PicoGUI and others), OS/2, and the Acorn RiscOS. It also runs on bare hardware on stock x86 machines, complete with drivers written in Smalltalk. There might be more, but that's should be most of them.
No, I would reccoment it to people who are wanting to create a business app for a homogonized work environment, but it has many uses.
I totally identify with your statement. I, like many got started on BASIC; in my case, it was on a really awesome Radio Shack PC-3, handheld computer with 4k of RAM.
I've used RB for whipping together Mac apps where my primary development environment, Squeak, didn't make much sense.
Worth note is that RB targets OS X, OS 9 and Windows without extra work. Coming out soon is the IDE for Windows; currently you can make Windoze apps, but not develop under Windows.
There isn't support for Linux outside of Wine thus far. I imagine RB apps work pretty swell within Wine, considering its non-reliance on many of the fancier "features" of the Windows system.
I know this could get me killed here, but ....
REBOL always looked pretty cool to me. Well, not always. At first, it seemed pretty ugly and special-case centrik, but when I took the time to read a bit, it was apparent that it is very much so a Scheme interpreter with some pretty darn interesting (and novel) features and a syntax that is more digestable for people coming from shitty languages. I've used it some at work solely out of pragmatism- I've been able to write little GUI apps with less code than Tk and a helluva lot less than with Perl/Tk.
That said, it is hardly without flaws. It has plenty. It's completely closed, and while I'm not the kind of purpose who bitches about that (like some of us here!), it impedes REBOL's adoption and use. I ended up more or less ditching it for my personal and work use because I can't develop for it on my Mac OS X machine, at least not with a GUI app. Sure, there's an X11 version, but because it's completely closed and they haven't recompiled it for OS X + X11, I can even run that under OS X. There's an OS 9 version, but I not starting up Classic just for REBOL.
Anyone else here looked at REBOL for more than a tiny acursory glance?
Because when Tcl first came out, it was pretty darn original. Sure, there were languages like Common Lisp and Smalltalk, but Tcl is embeddeble and works pretty well as a part of a larger system. Now a days, Smalltalks and Lisps can do that as well, and there are at least a hundred embeddeble scripting languages. But when it came out, it was original and pretty easy to write.
:)
I mean, going from "function(param1, param2)" to "function param1 param2" can't be all *that* hard.
Most folks would consider Smalltalk more than just a scripting language, but it can do that easily out of the box. Heck, on my 500 MHz G3 (fast enough for me, but "lowly" to plenty of people these days), Squeak Smalltalk (a relatively slower Smalltalk compared to the commercial implementations) it only takes one second to compute 4 raisedTo: 2000, that is, 4 ** 2000. "1000 factorial" takes a couple of seconds though- but that's not all that bad considering most languages can't support such large numbers out of the box. :)
Can Rexx do that? Just out of curiousity. Smalltalk can, a lot of Lisps can, but I'd love to add other languages to the list.
Well, I think MS sees a lot of it's ASP+VBScript developers to jump to ASP.NET using COBOL as soon as they realize that C# and J# aren't the only options for coding in ASP.NET. COBOL for web apps- who has the strength not to jump ship to Microsoft's platform? :P
I agree, Lua is a pretty fun language. It's pretty darn fast, too, considering what it is. And it's small- the default binary installation is only about 200k! WOWZA! Sure, not all the libraries as Perl or Python by default, but strip anything else in the same class else down to the same functionality and it's sure to be bigger.
:)
Then again, I'm got a big soft-spot in my heart for NewtonScript, after which Lua was modeled.
Am I the only one who is amused by the fact that Zope looks a lot like an attempt to make Python into a new version of Smalltalk? Except this new monster is more bloated, not as consistent or simple, and no where near as mature as a regular Smalltalk setup.
:)
There was a time when Python was used because it was different than the other options- different than perl and Smalltalk. But so many people are just kind of hacking onto Python all the great features of Smalltalk that have been polished and matured over the last 30 years... Object databases, persistency, an actually object-based system, cutting edge virtual machine/bytecode/cross-platform technology among other things. I guess Python's syntax resembles C/C++/Java quite a bit more than Smalltalk does, and that backwards comabilitibility of mind does make a big difference to a lot of people.
What do you see as being better about Ruby?
I know about how it's full of more "real" OO than Python, but what else that is practical?
DISCLAIMER: I'm a Smalltalk programmer, and also use Perl when it's applicable. Ruby, which is referred to as (Smalltalk + Perl) / 2 in a number of places, doesn't really rub me right. Python isn't really what I want to use usually either, but it just seems a bit more... cohesive to me in the work I've done. To each her own.
PHP is the ugly sister. ASP is more like the house all those ugly sisters live in- you can have any particular sister do the work for you. (that is, you can write ASP in more than one language) Hell, with ASP.NET, at least you can use the ASP.NET/.NET API with real languages, without being restricted to the likes of JavaScript, VBScript, or PHP. Blech. You could even use COBOL with ASP.NET! WOOT! OR FORTRAN!
I do work in what could be considered bioinformatics [1]. My boss still uses awk for scripting and processing our ecological and metereological data. Hell, he even writes CGI scripts in it. When he wants to visualize what does he do? Write an AWK script that outputs a POVray file... heh. No wonder everyone was impressed when I wrote the cool Squeak app for browsing and comparing multiple plots along a transcect all in one screen and all in a couple seconds. :P
[1] Although it's not genomics or anything, rather informatics and computer science applied to ecology.
Sure, Smalltalk does rule. But it's not usually put in the category of a "scripting language." It's more than that, or at least people usually consider it as being such. I don't really see much of a difference than most modern "scripting" languages and general purpose languages, but Smalltalk is definately a general purpose language, for creating operating environments, end user apps, and web apps, rather than just scripts.
That said, you can sure use Perl and its friends for real apps, even though it can get a bit awkward compared to using a language designed for being general purpose like Smalltalk, Common Lisp or even (eww) Java.
Where can I find a package for Mac OS X 10.2 for Python+wxPython? Until then, it still won't be actually cross-platform, at least to me. Sure, it supports desktop systems running Window (93%?) and Unix (3%?) but that4% of the Mac OS is what I usually use, so as a user (and a developer), it's worth about as much as MFC until it supports my platform. :)