I'm a "real coder" who started in assembly years ago, and there's no way I would start my son that way now.
Assembly used to be for general purpose programming. Today it is a small niche tool. Back when it was for general purpose programming, higher-level languages could often reasonably be thought of as shortcuts for writing assembly. The shortcuts weren't as good as the real thing, but they were quicker and often good enough. Still, it made sense to keep in mind the assembly that you were "really writing", to make sure it was what you wanted.
Today that is a very poor programming practice because the constraints and tools have changed so much.
These days it makes sense to direct most of your attention to a higher level of abstraction and to treat lower levels as advanced topics, not as fundamentals on which to build.
UTF-8 is the default encoding for XML. If you want to store default XML in a database, or create a database that can handle any text your customers submit without corrupting it, or that can handle all of your major markets without requiring a different DB (but with the same functionality) for each region...you'll have to use PostgreSQL, because though MySQL has been promising UTF-8 for years, they just don't seem to understand it well enough to ever deliver.
As long as time has any monetary value above zero, something that requires time can not be free.
People can have more surplus time than money and still consider their time worth something. Only in the case where you consider your time worth nothing (for whatever reason) can Linux be truly free.
Of course everything else requires time, too, and they don't just have costs, they have benefits presumably, so that's where total cost (and value) of ownership calculations need to begin.
And make the default text encoding UTF-8. The Linux Standards Base will soon make UTF-8 the default system encoding for Linux (well, the major ones that follow the LSB). Win & Mac are now Unicode-based. XML is UTF-8 by default.
Having the full character set in use by the OS (Unicode/ISO 10646) includable in a default email with no corruption or additional processing would certainly be a great feature.
This would allow even English speakers to have an enormously increased range of characters they can include in their text: math symbols, musical symbols, the full text of a Time Magazine article (professional publishers go way beyond Latin-1 in the characters they include in an article, and an email version these days usually corrupts the original to some extent), as well as mixtures of any other languages of interest.
XML in default form (UTF-8) could be included as simple text without corruption and without requiring that it be converted to an attachment.
If it's the default, UTF-8 will be quickly adopted by modern (non-abandoned) email clients and servers, meaning that they can all talk to each other in any language without reconfiguration.
I agree with a lot of what you say. And as a non-religious person, even I will agree that the anti-religious bias on Slashdot is both real and annoying.
I think you're a little bit loose with some of your thinking about science, though. People who claim some sort of proof that there is no God have nothing to do with science, whether they realize that or not.
You can't, in general, prove that something doesn't exist. It might just not be where you're looking.
So science can only approach it from the other direction and try to prove that he *does* exist, thereby falsifying the theory that he doesn't.
I don't know of any phenomenon that can only be explained by the existence of God, no matter who performs the test. So I think that science has to say at this point that there can be no proof that God doesn't exist and there is not yet any proof that he does.
Any scientist who incorporates an untestable factor in a hypothesis is certainly engaging in junk science, but that doesn't mean he's wrong. He's just being unscientific, which is not the same thing. Science doesn't allow you to add in an undetectable cause to cover unexplained effects.
But if there is a God, I wouldn't expect him to sit still while unbelievers performed experiments on him, so it's unlikely that science will prove his existence and impossible for it to prove his non-existence, so scientists had better not include either his existence or non-existence as a requirement in one of their theories or it's junk science.
There wasn't a single thing in my post about "cool" or "hip".
It was about a single underlying communications infrastructure that would have all the value of today's cell phones, plus today's TV medium, plus the Web, plus individual needs such as a baby monitor or "help button" for the elderly....
With all of those services delivered via the same underlying transport, the need to remain in touch with that transport ("the Net"), will be the sum of the need for all of those services. Even though every person will value some of the services highly, some other services just a little, and most services not at all, the value of the Net connection that makes them all possible will be huge for almost everyone.
Therefore, maintaining an always on connection to the Net will become enormously important.
What about that idea -- essentially a discussion of a new utility like running water or electricity -- sent you off on a rant about being "hip"? Is having electricity and running water too hip for you, too?
I'm not religious, but I certainly agree with your point that there are lots of ways for scientists to derive benefit. The same is true of religious people trying to convert people to their religion, even when they believe it wholeheartedly and genuinely believe they will help others if they can convince them.
I don't automatically dismiss arguments from people who have something to gain by convincing me. I just have to be a little more skeptical.
The part I can't accept is your "Science is great, but please don't put it ahead of common sense" nonsense.
If science can't be ahead of common sense then nothing could ever be believed if it contradicted existing beliefs. Things like relativity and quantum mechanics massively violate common sense, but in all cases where common sense and science make different predictions regarding the outcome of an experiment in these areas, it is the science prediction that turns out to be correct.
It's not the scale, it's the distribution that matters. I agree with your central point, but with just a small note that this is one population/distribution for which I would expect average to essentially equal the median. I wouldn't expect actual IQs to keep going up forever and there are probably more people with a zero IQ (in a coma or whatever) that those with an IQ of 10, and there are very few of these exception relative to the overall population, so I would still expect (just my guess, that's all) that the median and average would be essentially the same. And if they're not, it's because of the details of the actual distribution, not the fact that the scale is capped at one end.
Yes, this lets you have different versions of *global* DLLs, but most developers from now on won't be creating global DLLs, they'll just make their own DLLs local.
The design of.Net from version 1.0 allowed you to just put all of your own.exe's and.dll's in your own app directory and forget about the registry and other apps and.dll's and their versions, etc.
Put everything your app needs (other than the.Net platform itself) in your own app directory and run it. To install it on another machine, just drag the folder over and it's installed. To delete it, just drag the folder into the trash. It's independent of anybody else's app. It's a trip back to the 1980s.
Some people have taken this approach for years, using static linking or other techniques, but the "official right way" to do it was to use DLLs that you registered in the registry, etc.
With.Net, they've changed it so that the default way is to forget the registry, forget sharing to save disk and memory space, and encapsulate for reliability, portability, and scalability.
I think what's next will be an always on connection to the Net, the medium thru which all electronic information ("phone" calls, "TV" and "radio" shows, live chat with your different social groups [family, office, etc.], the Web, traffic cams, baby monitors, etc.) will eventually be transported.
Make it so you have, and maintain, a high bandwidth Net connection no matter where you go (some places might incur a surcharge, of course), and then deliver everything else thru it, and it will be more important to daily life than electricity is now.
"Technology isn't supposed to change. It's supposed to *optimize.*"
Yes, it's supposed to. Like the federal tax code. The good ideas replace bad ideas, better ideas replace good ideas, the best ideas emerge and merge into a consistent, elegant, powerful whole.
Yeah, right.
I think most of what I see can be explained better by inertia than optimization. Those who eventually optimized *themselves* to the old system, don't want it changed in any major way. Extended maybe, with chunks of new worked into the old matrix, bound together with lots of spaghetti for handling exceptions and workarounds and compromises....
If this really is "optimal", I guess that's even sadder.
I'm pretty sure it's not, but the people best equipped to create the new are also those with the greatest personal investment in the old, and that's a recipe for inertia.
A free knockoff of a 30-yr-old OS is the "latest thing from the 'bazaar' of great ideas". I think it's really Unix that is exceeding expectations, in its Linux avatar.
I just find it depressing that, as good as the ideas embodied in Unix were 30 years ago, they haven't been dramatically surpassed, perhaps two or three times, over a time span in which hardware performance has offered four or five *orders of magnitude* increase in power.
The GUI probably counts as one, but it's not as if the CLI itself has improved dramatically (except in performance), or the GUI and CLI have joined forces to dramatically increase the power of the combination. The closest you get is running a GUI to do GUI-only things and to open several simultaneous windows in which you can do 30-yr-old CLI-only things.
I guess a technology can exceed expectations by virtue of the fact that no significant improvement has occurred in years.
Sorry for not checking back sooner, but maybe you (JamesOfTheDesert) will see this.
I can't quote an exact source from memory, but I think I encountered both of these while Googling a Ruby mailing list. There was a long thread in Aug 2002 where a guy named "Curt" was making some very well-informed points about Unicode and Matz was arguing with him. The quote about "whatever doesn't interfere with Japanese" wasn't said by Matz during that thread, but was linked to, as I recall, and I came across that quote twice. Curt didn't mention it, though. It was somebody more familiar with Ruby history who linked to it, again if I recall correctly.
You can probably find everything I found by Googling for the two terms Ruby and Unicode, then following the threads you encounter and the links included therein. That's how I found everything I found. (And I Googled both Web pages and Usenet ("Google Groups")).
I believe "scripting" originated as a way to automate the functions of an app. Instead of manually calling the functions, you could write a little script and have the program save it and run it for you on demand.
So for this reason, it tended to be higher-level, specialized, and slow compared to a "real program" but faster than manually entering the commands.
Some scripting languages, such as the pseudo shell scripting language that Perl started out as, called lots of outside utilities, then gradually internalized them, then added libraries of its own, then spread across platforms and, as far as I'm concerned, just morphed into general-purpose programming languages.
For the most part, though, I would stick with defining scripting as high-level automation of features that are implemented in a lower-level language and programming as using a lower level language to create new things, and *yes* I can see that it's a spectrum.
I can't believe that even the defenders of Java are missing this point.
Java *is* compiled. You don't run the bytecode anymore (except in a very few very small implementations).
Most compiled languages (like C) are compiled once by the programmer, then the resulting binary is executed many times. In the case of Java today, the source is compiled to bytecode by the programmer, but then the bytecode is compiled to binary -- not each time it's run, but just the first time it's run on a given machine. After that first, slow run, it is essentially the same binary as if it had been compiled to binary by the programmer, but with some advantages of being optimized for the specific runtime.
It's also true that modules that aren't called don't get compiled until the first time they are called, but then they're cached and they don't get recompiled.
Java is so fast these days because it has abandoned the "execute the bytecode" ways of its early days. These days, it just does a late compilation to native.
And for benchmarks like the QuickSort mentioned in this thread, you can't measure it reasonably by doing one run, you have to run the same algorithm several times, then measure one iteration to judge the speed.
In other words, when running Java servlets serving customer after customer, the first run is really slow because that's when it compiles, but then you get another 100,000 runs of the same object code with no recompilation, and to judge the speed you should look at one of those 100,000 and not just the startup run.
Perl is a difficult example because it started off before it was reasonable to base it on Unicode, and "linguist Larry" went years after Java showed the way thumbing his nose at Unicode, then becoming a convert so fast that the rest of his flock got pretty confused by the sudden switch. His conversion, he says, was not because the Unicode idea of working in sequences of universal characters was better than arbitrary byte sequences, but because XML was based on Unicode, and he felt he needed to catch the XML wave.
I remember the last time I heard Dan Sugalski give a talk, he listed some absurd reasons why Parrot wouldn't be Unicode based, e.g.: "Because not everybody collates in the same order", as if the encoding determined collation order. One wonders how the Europeans, with so many different national collation orders, could possibly share a single Latin-1 encoding. But no, that was one reason why "they had decided" that Parrot wasn't going to "impose Unicode" on anyone.
In the meantime, Larry keeps announcing more Unicode-related goodies, so who knows what the attitude will be by Perl 6.0. Maybe Dan has changed his mind, too. I haven't heard.
I use 5.8 for manipulating existing bytes because I have to untangle the bugs caused by people using non-Unicode tools (like traditional Perl), but for new systems I go with something like Java, where there isn't more than one way to do it. There's just one: Unicode.
I wasn't aware that in 5.8 the default had changed from "use bytes" to "use utf-8", though, so I'll remove those "use utf-8" lines and see what happens. If so, it sounds as though Perl is aiming to stop simply processing other systems' data and to become a full platform in its own right, like Java or C#. A switch to being all-Unicode (even with legacy and I/O exceptions) is something I would expect of a language trying to move up to running its own show. I hope Larry can convert the flock, if he hasn't already.
I don't blame Matz for not basing Ruby on Unicode ten years ago. It *was* immature then, but it's not now.
But even now, ten years later, Matz has made it quite clear that support for legacy Japanese encodings comes before internationalization. His repeated comments about "EUC-JP is good enough for me" and "Ruby's i18n strategy is simply whatever doesn't interfere with my work in Japanese [which is legacy EUC-JP-based]" make it clear that he is a guy who spends his time on non-globalized Japanese systems, because EUC-JP isn't good enough for anybody except that kind of developer. Anyone else who can use it, fine, but he built it as his wrench for working on legacy Japanese engines, not for non-Japanese to build new, global engines.
He's the Japanese equivalent of all the Western developers who kick and scream about giving up their byte==char architectures for the sake of non-Western text. They don't want to give up the efficiency of byte==char, that works fine for their own personal "itch", for the sake of a bunch of foreigners who should go build their own languages instead of messing up *mine*. Well, Matz did, and with the same attitude.
"Unicode compliance" to the extent that it doesn't get in the way of legacy Japanese encodings and utterly absurd systems such as Mojikyo is not what I'm talking about. (There must be 10,000 developers who want to do custom memory management for every one who wants to use Mojikyo, yet Matz thinks making everyone use the same GC is okay (it is), but can't tolerate using a single universal internal string format because -- he always uses it as an example -- what about developers who might want to use Mojikyo instead? Yeah, all 7 of them. Absurd argument.)
Any language can add "Unicode compliance to the extent it doesn't interfere with the important stuff" as an awkward afterthought.
I'm talking about languages like Java and C# that are actually Unicode based, Unicode only, not "well, in some future version you'll have the option of doing some things with Unicode if you need to." Languages that take the stance that, although Unicode may not be as good at dealing with EUC-JP data as EUC-JP itself, it is by far the best for creating new large-scale, globalized systems and new data in all major languages. Java and C# have their sights set on the creation of new systems of this magnitude, while Matz seems to see Ruby as a utility for his own smaller-scale, geographically-limited chores.
I have no argument with a guy building his own itch scratcher, and I wouldn't even have taken notice if he hadn't done such an amazing job in lots of other ways. But the original article is about scripting languages not getting the same respect, and my point is that they seem to have their sights set a lot lower than Java or C# -- not focused on building new worlds but on tinkering with a few existing ones -- and that probably has a lot to do with it.
C/C++ is sort of an exception because it was meant as a jack-of-all-trades before more focused tools were created, but...
A language like Java or C# is designed with an attitude that it will be used as the foundation for building software systems. It is for creating new systems and new data, and it is at the center of those new systems.
In contrast, I often hear Larry Wall (Perl) or Matz (Ruby) make comments that sound as though their tools are designed to accommodate themselves to legacy data and legacy systems.
Java and C# tend to say, "this is the new way to do things", while Perl and Ruby say, "we're doing our best to accommodate the legacy ways your systems do things".
I'll give you a concrete example: Unicode. Both Java and C# did the smart thing (for a foundation for new things) and said, "in our universe, all text is Unicode. Period. No messing around with old, crippled text encodings. We work only in Unicode, all of our APIs are pure Unicode, we only need one deep set of global APIs (instead of many alternative, shallow sets of regional APIs), and if you're smart, you'll set up your auxiliary systems (the database, for ex.) as Unicode systems, too, because that's what we use here." They can convert from legacy encodings to bring old data "into the system" and convert to legacy encoding if necessary to spoon feed some older "outside" system, but the real system is a Java or.Net world in which there is one canonical, universal, modern format for text data.
In Perl and Ruby, the idea is, "well our job is to slice and dice other system's data, that's what we do, and we have to accommodate the many text encodings out there. We don't do anything really deep. We do basic, solid byte-pattern matching and processing without any real deeper understanding of language, because the encoding could be anything. We can't assume everybody uses Unicode". Meaning, in essence, we can't make rules of our own, we have to conform to whatever the real system wants.
It's as if some scripting language designers see their tool as a wrench for tinkering with engines, while the designers of Java and C# see their languages as tools for building engines.
This is an overstatement of the difference, of course, just for illustration of my point. Certainly Java is sometimes used as no more than "glue", while Perl is used to build whole systems, so there's a spectrum here. And Perl is trying to retrofit fancier linguistic features onto a scripting base as it grows into a "big language".
But I see the difference that leads to the bias referred to in the article as coming, at least in part, from the original language designer's concept of the centrality of his language's role.
I completely agree. We have 30 years of research and many orders of magnitude increase in computing power and yet the Open Source movement's claim to fame is the creation of cheap knockoffs of 1970s software.
I use Linux for many things because it's the best tool we have for those things, but I think that's a pretty sad statement frankly....
I realize that's sort of a flamebaity thing to say in this audience, but there's just no comparison between the quality of text on a Mac or Windows and on Linux.
I use Linux for work and for fun, but I always set it up so that most of my interaction with it is via a terminal program running on Windows. Many of my coworkers use Macs to access their Linux (and other Unix) machines, and I'll have to admit that the text on their Macs looks a little better than on my Windows machines.
None of us can put up with the ugliness of text in current Linux GUIs, which looks like the Mac of almost 20 years ago.
I expect Linux to catch up in the next five years or so (I sure hope so, because I'm using it more and more), but it's pretty hard to look at currently. I don't want to have to keep relying on some other OS to provide a tolerable window into my own Linux box.
The article says that the result is that there are no more than 20 commercial quality albums per year produced in a country with more than four times the population of the US.
Maybe musicians will still find another reason to play, but unless you're in the audience when they do you'll have to satisfy yourself with recordings made by someone with a smuggled in walkman recorder who was.
Slashdot Mirror
I'm a "real coder" who started in assembly years ago, and there's no way I would start my son that way now.
Assembly used to be for general purpose programming. Today it is a small niche tool. Back when it was for general purpose programming, higher-level languages could often reasonably be thought of as shortcuts for writing assembly. The shortcuts weren't as good as the real thing, but they were quicker and often good enough. Still, it made sense to keep in mind the assembly that you were "really writing", to make sure it was what you wanted.
Today that is a very poor programming practice because the constraints and tools have changed so much.
These days it makes sense to direct most of your attention to a higher level of abstraction and to treat lower levels as advanced topics, not as fundamentals on which to build.
Computing in Hell:
The security of Windows, the ease of use of Linux, and a Macintosh mouse!
some kind of microprocessor or something?
Sounds fun...
UTF-8 is the default encoding for XML. If you want to store default XML in a database, or create a database that can handle any text your customers submit without corrupting it, or that can handle all of your major markets without requiring a different DB (but with the same functionality) for each region...you'll have to use PostgreSQL, because though MySQL has been promising UTF-8 for years, they just don't seem to understand it well enough to ever deliver.
As long as time has any monetary value above zero, something that requires time can not be free.
People can have more surplus time than money and still consider their time worth something. Only in the case where you consider your time worth nothing (for whatever reason) can Linux be truly free.
Of course everything else requires time, too, and they don't just have costs, they have benefits presumably, so that's where total cost (and value) of ownership calculations need to begin.
And make the default text encoding UTF-8. The Linux Standards Base will soon make UTF-8 the default system encoding for Linux (well, the major ones that follow the LSB). Win & Mac are now Unicode-based. XML is UTF-8 by default.
Having the full character set in use by the OS (Unicode/ISO 10646) includable in a default email with no corruption or additional processing would certainly be a great feature.
This would allow even English speakers to have an enormously increased range of characters they can include in their text: math symbols, musical symbols, the full text of a Time Magazine article (professional publishers go way beyond Latin-1 in the characters they include in an article, and an email version these days usually corrupts the original to some extent), as well as mixtures of any other languages of interest.
XML in default form (UTF-8) could be included as simple text without corruption and without requiring that it be converted to an attachment.
If it's the default, UTF-8 will be quickly adopted by modern (non-abandoned) email clients and servers, meaning that they can all talk to each other in any language without reconfiguration.
I think this would be a major win.
Yes, in fact I suspect that any trend this strong will provoke a strong backlash, creating a market for "unplugged vacations" and that sort of thing.
I agree with a lot of what you say. And as a non-religious person, even I will agree that the anti-religious bias on Slashdot is both real and annoying.
I think you're a little bit loose with some of your thinking about science, though. People who claim some sort of proof that there is no God have nothing to do with science, whether they realize that or not.
You can't, in general, prove that something doesn't exist. It might just not be where you're looking.
So science can only approach it from the other direction and try to prove that he *does* exist, thereby falsifying the theory that he doesn't.
I don't know of any phenomenon that can only be explained by the existence of God, no matter who performs the test. So I think that science has to say at this point that there can be no proof that God doesn't exist and there is not yet any proof that he does.
Any scientist who incorporates an untestable factor in a hypothesis is certainly engaging in junk science, but that doesn't mean he's wrong. He's just being unscientific, which is not the same thing. Science doesn't allow you to add in an undetectable cause to cover unexplained effects.
But if there is a God, I wouldn't expect him to sit still while unbelievers performed experiments on him, so it's unlikely that science will prove his existence and impossible for it to prove his non-existence, so scientists had better not include either his existence or non-existence as a requirement in one of their theories or it's junk science.
There wasn't a single thing in my post about "cool" or "hip".
It was about a single underlying communications infrastructure that would have all the value of today's cell phones, plus today's TV medium, plus the Web, plus individual needs such as a baby monitor or "help button" for the elderly....
With all of those services delivered via the same underlying transport, the need to remain in touch with that transport ("the Net"), will be the sum of the need for all of those services. Even though every person will value some of the services highly, some other services just a little, and most services not at all, the value of the Net connection that makes them all possible will be huge for almost everyone.
Therefore, maintaining an always on connection to the Net will become enormously important.
What about that idea -- essentially a discussion of a new utility like running water or electricity -- sent you off on a rant about being "hip"? Is having electricity and running water too hip for you, too?
I'm not religious, but I certainly agree with your point that there are lots of ways for scientists to derive benefit. The same is true of religious people trying to convert people to their religion, even when they believe it wholeheartedly and genuinely believe they will help others if they can convince them.
I don't automatically dismiss arguments from people who have something to gain by convincing me. I just have to be a little more skeptical.
The part I can't accept is your "Science is great, but please don't put it ahead of common sense" nonsense.
If science can't be ahead of common sense then nothing could ever be believed if it contradicted existing beliefs. Things like relativity and quantum mechanics massively violate common sense, but in all cases where common sense and science make different predictions regarding the outcome of an experiment in these areas, it is the science prediction that turns out to be correct.
It's not the scale, it's the distribution that matters. I agree with your central point, but with just a small note that this is one population/distribution for which I would expect average to essentially equal the median. I wouldn't expect actual IQs to keep going up forever and there are probably more people with a zero IQ (in a coma or whatever) that those with an IQ of 10, and there are very few of these exception relative to the overall population, so I would still expect (just my guess, that's all) that the median and average would be essentially the same. And if they're not, it's because of the details of the actual distribution, not the fact that the scale is capped at one end.
virtual mod point to you!
Yes, this lets you have different versions of *global* DLLs, but most developers from now on won't be creating global DLLs, they'll just make their own DLLs local.
.Net from version 1.0 allowed you to just put all of your own .exe's and .dll's in your own app directory and forget about the registry and other apps and .dll's and their versions, etc.
.Net platform itself) in your own app directory and run it. To install it on another machine, just drag the folder over and it's installed. To delete it, just drag the folder into the trash. It's independent of anybody else's app. It's a trip back to the 1980s.
.Net, they've changed it so that the default way is to forget the registry, forget sharing to save disk and memory space, and encapsulate for reliability, portability, and scalability.
The design of
Put everything your app needs (other than the
Some people have taken this approach for years, using static linking or other techniques, but the "official right way" to do it was to use DLLs that you registered in the registry, etc.
With
I think what's next will be an always on connection to the Net, the medium thru which all electronic information ("phone" calls, "TV" and "radio" shows, live chat with your different social groups [family, office, etc.], the Web, traffic cams, baby monitors, etc.) will eventually be transported.
Make it so you have, and maintain, a high bandwidth Net connection no matter where you go (some places might incur a surcharge, of course), and then deliver everything else thru it, and it will be more important to daily life than electricity is now.
"Technology isn't supposed to change. It's supposed to *optimize.*"
Yes, it's supposed to. Like the federal tax code. The good ideas replace bad ideas, better ideas replace good ideas, the best ideas emerge and merge into a consistent, elegant, powerful whole.
Yeah, right.
I think most of what I see can be explained better by inertia than optimization. Those who eventually optimized *themselves* to the old system, don't want it changed in any major way. Extended maybe, with chunks of new worked into the old matrix, bound together with lots of spaghetti for handling exceptions and workarounds and compromises....
If this really is "optimal", I guess that's even sadder.
I'm pretty sure it's not, but the people best equipped to create the new are also those with the greatest personal investment in the old, and that's a recipe for inertia.
A free knockoff of a 30-yr-old OS is the "latest thing from the 'bazaar' of great ideas". I think it's really Unix that is exceeding expectations, in its Linux avatar.
I just find it depressing that, as good as the ideas embodied in Unix were 30 years ago, they haven't been dramatically surpassed, perhaps two or three times, over a time span in which hardware performance has offered four or five *orders of magnitude* increase in power.
The GUI probably counts as one, but it's not as if the CLI itself has improved dramatically (except in performance), or the GUI and CLI have joined forces to dramatically increase the power of the combination. The closest you get is running a GUI to do GUI-only things and to open several simultaneous windows in which you can do 30-yr-old CLI-only things.
I guess a technology can exceed expectations by virtue of the fact that no significant improvement has occurred in years.
Sorry for not checking back sooner, but maybe you (JamesOfTheDesert) will see this.
I can't quote an exact source from memory, but I think I encountered both of these while Googling a Ruby mailing list. There was a long thread in Aug 2002 where a guy named "Curt" was making some very well-informed points about Unicode and Matz was arguing with him. The quote about "whatever doesn't interfere with Japanese" wasn't said by Matz during that thread, but was linked to, as I recall, and I came across that quote twice. Curt didn't mention it, though. It was somebody more familiar with Ruby history who linked to it, again if I recall correctly.
You can probably find everything I found by Googling for the two terms Ruby and Unicode, then following the threads you encounter and the links included therein. That's how I found everything I found. (And I Googled both Web pages and Usenet ("Google Groups")).
Hope this helps.
I believe "scripting" originated as a way to automate the functions of an app. Instead of manually calling the functions, you could write a little script and have the program save it and run it for you on demand.
So for this reason, it tended to be higher-level, specialized, and slow compared to a "real program" but faster than manually entering the commands.
Some scripting languages, such as the pseudo shell scripting language that Perl started out as, called lots of outside utilities, then gradually internalized them, then added libraries of its own, then spread across platforms and, as far as I'm concerned, just morphed into general-purpose programming languages.
For the most part, though, I would stick with defining scripting as high-level automation of features that are implemented in a lower-level language and programming as using a lower level language to create new things, and *yes* I can see that it's a spectrum.
I can't believe that even the defenders of Java are missing this point.
Java *is* compiled. You don't run the bytecode anymore (except in a very few very small implementations).
Most compiled languages (like C) are compiled once by the programmer, then the resulting binary is executed many times. In the case of Java today, the source is compiled to bytecode by the programmer, but then the bytecode is compiled to binary -- not each time it's run, but just the first time it's run on a given machine. After that first, slow run, it is essentially the same binary as if it had been compiled to binary by the programmer, but with some advantages of being optimized for the specific runtime.
It's also true that modules that aren't called don't get compiled until the first time they are called, but then they're cached and they don't get recompiled.
Java is so fast these days because it has abandoned the "execute the bytecode" ways of its early days. These days, it just does a late compilation to native.
And for benchmarks like the QuickSort mentioned in this thread, you can't measure it reasonably by doing one run, you have to run the same algorithm several times, then measure one iteration to judge the speed.
In other words, when running Java servlets serving customer after customer, the first run is really slow because that's when it compiles, but then you get another 100,000 runs of the same object code with no recompilation, and to judge the speed you should look at one of those 100,000 and not just the startup run.
Perl is a difficult example because it started off before it was reasonable to base it on Unicode, and "linguist Larry" went years after Java showed the way thumbing his nose at Unicode, then becoming a convert so fast that the rest of his flock got pretty confused by the sudden switch. His conversion, he says, was not because the Unicode idea of working in sequences of universal characters was better than arbitrary byte sequences, but because XML was based on Unicode, and he felt he needed to catch the XML wave.
I remember the last time I heard Dan Sugalski give a talk, he listed some absurd reasons why Parrot wouldn't be Unicode based, e.g.: "Because not everybody collates in the same order", as if the encoding determined collation order. One wonders how the Europeans, with so many different national collation orders, could possibly share a single Latin-1 encoding. But no, that was one reason why "they had decided" that Parrot wasn't going to "impose Unicode" on anyone.
In the meantime, Larry keeps announcing more Unicode-related goodies, so who knows what the attitude will be by Perl 6.0. Maybe Dan has changed his mind, too. I haven't heard.
I use 5.8 for manipulating existing bytes because I have to untangle the bugs caused by people using non-Unicode tools (like traditional Perl), but for new systems I go with something like Java, where there isn't more than one way to do it. There's just one: Unicode.
I wasn't aware that in 5.8 the default had changed from "use bytes" to "use utf-8", though, so I'll remove those "use utf-8" lines and see what happens. If so, it sounds as though Perl is aiming to stop simply processing other systems' data and to become a full platform in its own right, like Java or C#. A switch to being all-Unicode (even with legacy and I/O exceptions) is something I would expect of a language trying to move up to running its own show. I hope Larry can convert the flock, if he hasn't already.
I don't blame Matz for not basing Ruby on Unicode ten years ago. It *was* immature then, but it's not now.
But even now, ten years later, Matz has made it quite clear that support for legacy Japanese encodings comes before internationalization. His repeated comments about "EUC-JP is good enough for me" and "Ruby's i18n strategy is simply whatever doesn't interfere with my work in Japanese [which is legacy EUC-JP-based]" make it clear that he is a guy who spends his time on non-globalized Japanese systems, because EUC-JP isn't good enough for anybody except that kind of developer. Anyone else who can use it, fine, but he built it as his wrench for working on legacy Japanese engines, not for non-Japanese to build new, global engines.
He's the Japanese equivalent of all the Western developers who kick and scream about giving up their byte==char architectures for the sake of non-Western text. They don't want to give up the efficiency of byte==char, that works fine for their own personal "itch", for the sake of a bunch of foreigners who should go build their own languages instead of messing up *mine*. Well, Matz did, and with the same attitude.
"Unicode compliance" to the extent that it doesn't get in the way of legacy Japanese encodings and utterly absurd systems such as Mojikyo is not what I'm talking about. (There must be 10,000 developers who want to do custom memory management for every one who wants to use Mojikyo, yet Matz thinks making everyone use the same GC is okay (it is), but can't tolerate using a single universal internal string format because -- he always uses it as an example -- what about developers who might want to use Mojikyo instead? Yeah, all 7 of them. Absurd argument.)
Any language can add "Unicode compliance to the extent it doesn't interfere with the important stuff" as an awkward afterthought.
I'm talking about languages like Java and C# that are actually Unicode based, Unicode only, not "well, in some future version you'll have the option of doing some things with Unicode if you need to." Languages that take the stance that, although Unicode may not be as good at dealing with EUC-JP data as EUC-JP itself, it is by far the best for creating new large-scale, globalized systems and new data in all major languages. Java and C# have their sights set on the creation of new systems of this magnitude, while Matz seems to see Ruby as a utility for his own smaller-scale, geographically-limited chores.
I have no argument with a guy building his own itch scratcher, and I wouldn't even have taken notice if he hadn't done such an amazing job in lots of other ways. But the original article is about scripting languages not getting the same respect, and my point is that they seem to have their sights set a lot lower than Java or C# -- not focused on building new worlds but on tinkering with a few existing ones -- and that probably has a lot to do with it.
C/C++ is sort of an exception because it was meant as a jack-of-all-trades before more focused tools were created, but...
.Net world in which there is one canonical, universal, modern format for text data.
A language like Java or C# is designed with an attitude that it will be used as the foundation for building software systems. It is for creating new systems and new data, and it is at the center of those new systems.
In contrast, I often hear Larry Wall (Perl) or Matz (Ruby) make comments that sound as though their tools are designed to accommodate themselves to legacy data and legacy systems.
Java and C# tend to say, "this is the new way to do things", while Perl and Ruby say, "we're doing our best to accommodate the legacy ways your systems do things".
I'll give you a concrete example: Unicode. Both Java and C# did the smart thing (for a foundation for new things) and said, "in our universe, all text is Unicode. Period. No messing around with old, crippled text encodings. We work only in Unicode, all of our APIs are pure Unicode, we only need one deep set of global APIs (instead of many alternative, shallow sets of regional APIs), and if you're smart, you'll set up your auxiliary systems (the database, for ex.) as Unicode systems, too, because that's what we use here." They can convert from legacy encodings to bring old data "into the system" and convert to legacy encoding if necessary to spoon feed some older "outside" system, but the real system is a Java or
In Perl and Ruby, the idea is, "well our job is to slice and dice other system's data, that's what we do, and we have to accommodate the many text encodings out there. We don't do anything really deep. We do basic, solid byte-pattern matching and processing without any real deeper understanding of language, because the encoding could be anything. We can't assume everybody uses Unicode". Meaning, in essence, we can't make rules of our own, we have to conform to whatever the real system wants.
It's as if some scripting language designers see their tool as a wrench for tinkering with engines, while the designers of Java and C# see their languages as tools for building engines.
This is an overstatement of the difference, of course, just for illustration of my point. Certainly Java is sometimes used as no more than "glue", while Perl is used to build whole systems, so there's a spectrum here. And Perl is trying to retrofit fancier linguistic features onto a scripting base as it grows into a "big language".
But I see the difference that leads to the bias referred to in the article as coming, at least in part, from the original language designer's concept of the centrality of his language's role.
I completely agree. We have 30 years of research and many orders of magnitude increase in computing power and yet the Open Source movement's claim to fame is the creation of cheap knockoffs of 1970s software.
I use Linux for many things because it's the best tool we have for those things, but I think that's a pretty sad statement frankly....
I realize that's sort of a flamebaity thing to say in this audience, but there's just no comparison between the quality of text on a Mac or Windows and on Linux.
I use Linux for work and for fun, but I always set it up so that most of my interaction with it is via a terminal program running on Windows. Many of my coworkers use Macs to access their Linux (and other Unix) machines, and I'll have to admit that the text on their Macs looks a little better than on my Windows machines.
None of us can put up with the ugliness of text in current Linux GUIs, which looks like the Mac of almost 20 years ago.
I expect Linux to catch up in the next five years or so (I sure hope so, because I'm using it more and more), but it's pretty hard to look at currently. I don't want to have to keep relying on some other OS to provide a tolerable window into my own Linux box.
The article says that the result is that there are no more than 20 commercial quality albums per year produced in a country with more than four times the population of the US.
Maybe musicians will still find another reason to play, but unless you're in the audience when they do you'll have to satisfy yourself with recordings made by someone with a smuggled in walkman recorder who was.