There was a guy working on Lisp for Eclipse, and he got a lot of people so interested that he sort of ended up saying, "Never mind. It's nothing really, just a little experiment. Go away and leave me alone!" So, who knows....
The quality of error messages varies widely, but in general, error messages in functional-style programming tend not to be very informative, and though you don't have to use a functional style with Lisp, the error messages in Lisp tend to resemble those of functional languages.
I've never seen the kind of outrageous, mile-long messages you get spewing from C++ templates, though.
As for failing silently, that's not what happens, but a legitimate complaint is that, due to the dynamic nature of Lisp, certain types of errors that would be caught at compile time in C++ may not be caught until runtime in Lisp. Even so, I find C++ to be far more bug prone than Lisp.
I agree with you about the few good souls. Occasionally one of them will come to the defense of a newbie whose questions have implied a less than complete faith in the fundamentalist religion that Common Lisp has become, and who has been insulted, derided, and abused instead of answered.
On such occasions, the good souls themselves usually become the targets of the hostility for daring to defend who expressed a lack of faith. Their own faith is called into question, which often results in a display of groveling and profession of complete devotion to The Cause that is like something from the Spanish Inquisition.
It's so absurd that they frequently congratulate each other for particularly abusive remarks, like gang members urging each other to beat up some guy who accidentally wandered into their neighborhood.
What's most funny of all is to see them brag about how "beneficial" this pathological behavior is. They claim it sets high standards that benefit everyone, avoiding the intellectual pollution that apparently results from from weaknesses as friendliness, politeness, and patience.
Contrast that with a group like comp.lang.python, where the language, IMHO, is a poor shadow of Lisp in so many ways, but the community is so friendly and helpful (even to those who call Python a "poor shadow of Lisp", ahem) that Python just gets better and more attractive every year as people pitch in and create libraries, answer "how do I questions", and generally try to make your Python experience successful.
Since the Lisp emperor will verbally lop off your head if you notice his "wardrobe malfunction", I suspect I'll have to write off Common Lisp as a lost cause. There's little chance of a useful community coalescing around that rotten core, and without the community, Common Lisp has probably gone as far as it can go.
Like so many admirers of so many generic Lisp concepts, I'm left scanning the horizon for a New Lisp to appear--and not just another 1-man Scheme science project--but the odds are heavily stacked against anyone who makes the attempt, unfortunately.
I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages
Wait a minute. I have serious complaints about Lisp, but those are not among them. Let me take those in reverse order:
SLOWER THAN COMPILED LANGUAGES: No, there are compilers for both Lisp and Scheme that generate VERY fast code. There are interpreters that are as fast as Python that are nice to use during development, then you run it thru a compiler and the speed is on a par with C++, when performing similar operations. Of course a small amount of C++ code will often run much faster than a small amount of Lisp code, but that's because a small amount of Lisp code can say so much more than a small amount of C++ source can say. That shouldn't be counted against Lisp.
ILLEGIBLE: Not really, in my experience. I know what you mean, though. After a lot of use, it's still not quite as easy to read (for me) as something like Ruby or Python, which were already pretty clear even before I had written a single line of either. But it's nowhere near as hard to read as Perl still sometimes is for me, and I've been coding in Perl (occasionally) for a decade. Even C++, which I've done a lot of over the last decade, still gets pretty darned hard to read sometimes, such as when using templates to call old-style C APIs.
Lisp is a lot better than that. I've certainly grown to appreciate the way you can build abstractions out of abstractions and the top level is still called the same way as the bottom level. Self similarity at every level of abstraction, so you just have to think about the algorithms and not the syntax.
Trust me that, with practice, Lisp gets much easier to read, though it never seems to get quite as easy as something like Ruby or Python.
UGLY -- of course this is related to legibility. Again, I know what you mean, and I agree in some ways. A simple mathematical expression or loop is quite ugly, I think, compared to the same thing in Ruby or Python.
However, as soon as you leave the simple, built-in stuff and start building your own more complex functionality, you discover that Ruby and Python get uglier and uglier but Lisp still looks the same. As soon as you start trying to express really interesting algorithms (fancy searches, AI stuff, etc.), you'll see the beauty in the simple consistency of the syntax. (Much more true of Scheme than Common Lisp, BTW.)
So, no, I don't have any serious complaints in that regard. There's no speed problem at all and where it is harder to read, it's a small price to pay for the significant power boost that style of syntax gives you when working with really interesting problems.
So, what don't I like? The online community of users, for one. The misanthropes that took over comp.lang.lisp are pathetic. I've never seen a techical discussion group that hostile and defensive. Don't even think of asking them questions that might clear up some of your skepticism about Lisp. The fact that you have any doubts makes you unworthy of being treated with anything other than utter hostility.
They love Common Lisp like a religion, and hate everything, and everyONE else, even natural allies like Scheme. Common Lisp fossilized sometime back in the Reagan Administration and has since lost almost all ability to improve. As a result, the vast majority of former users have abandoned it and those who remain almost have to take a position that there is no further NEED for improvement except in trivial ways (more libraries, more "complete" implementations, etc.) that, if you think about it, are merely restatements of the "nothing needs to be improved" notion.
And that brings me to what I like least: it seems that the fundamental ideas underlying all forms of Lisp (incl. Scheme) are fascinating, and if redone in a way such as Paul Graham's Arc (www.paulgraham.com) could turn out to be a terrific language. Unfortunately, I don't see it happening. Arc is announcementware. It has shown no signs of life since its first few weeks. Com
Now *you* look up what I posted. I never said I couldn't understand why popularity mattered. I said that something like the Great Shootout could serve to bootstrap popularity. In an area like programming languages, which is subject to strong network effects, anything that could get the snowball started for a wider variety of languages would be useful--as I said.
I've actually spent a number of years using Lisp. I've been paid to write software in somewhere between a dozen and two dozen languages, depending on your definition of language, and I assure you that your "acquire complete mastery of a new language in a week" test is completely irrelevant.
If you haven't even started to look at a language until a week before you need to be a master, it's not the fault of the project. You simply aren't qualified for that particular job.
But, unless you never do anything until someone else forces you to do it, you usually have years in which to get to know a new language. Over that time, you will either determine that it is not useful enough to add to your toolbox or you will have added it to the extent you feel it warrants.
So all I'm talking about is the advantages of a site like the Great Language Shootout that gives you a lot of information with which to make your decisions over that period of years that I'm referring to.
As with human language, some people are naturals when it comes to being fluent in multiple programming languages. Unfortunately, I am not one of their number.
That's unfortunate, because the ability to quickly learn to handle new specialty tools has significant competitive advantages--dare I call it "survival value"?
And with all the things one needs to learn to move beyond junior programmer these days (things like XML, DHTML, accessibility, SQL, MS Excel, version management utilities, scripting for metaprogramming tasks, etc., etc.) it just doesn't make sense to turn up your nose at improved programming languages.
I find it quite frustrating that there is such huge inertia in programming languages. Even when languages have some remarkable advantage, programmers won't use it because "nobody uses it."
I don't deny that popularity provides some huge advantages. I just hope that there can be mechanisms to bootstrap popularity, and this Great Language Shootout is (potentially) the sort of thing the could do that.
Some languages, for example, have significant advantages in some specialty area: Erlang in parallelism, Lisp as a language for writing specialty languages, bug minimization approaches taken by Eiffel or the functional languages, etc. They may be awful for other types of work, but the fact that a hammer is a terrible saw doesn't make it any less of a great tool for the right problem.
If there were an active, busy site frequented by developers at which there were a wide variety of benchmarks that allowed uncommon languages to show off their specialty advantages, more developers would do some of their work in those languages, and the increasing popularity would result in better implementations and a flourishing of new languages.
Right now, the popular languages don't come close to taking full advantage of what we have learned about programming, and yet you would have to be either an academic or a fool to put a lot of effort into designing a great new language. The way things are right now, a great language designer probably has a better chance of being hit by lightning than he has of ever making his great new language popular.
Anything that reduces this language inertia (and YES that includes.Net) is a Good Thing.
There's no difference between an interpreter and a compiler in this case. Both take some Turing complete human-ish language (source code) and convert it into Turing complete machine instructions, which is all that the CPU understands. You could do all sorts of crazy things, a C *interpreter* written in Excel macros, for example. It just takes source and turns it into machine code, and the only question being addressed here is which technique results in faster ultimate execution of machine instructions and interactions with memory, the C++ source compiled into a wad of machine code in advance approach or the Java source compiled in advance into a wad of bytecode which is then compiled incrementally and cached by a JIT process approach. Each one allows for a different set of optimizations that convert the intent expressed in the original source into the closest thing to the minimum work the processor needs to do to carry out those intentions.
Many compilers and interpreters are written in themselves. Read the other comments about bootstrapping. And how do you think the first C compilers were written? In C?
When you understand bootstrapping, you'll understand how one would create a JVM written in Java. (IBM did just that.) It's not a question of whether it is possible, but what the pros and cons would be.
I don't deny that the finer granularity of C++, no make that plain C, no make that raw assembly language, allows you to make certain optimizations that are quite valuable in certain circumstances.
But when you are trying to choose the right tool for a particular job, you need to be current on the details of just what advantages, and what degree of advantage, and in what circumstances, comparing current versions of all of the candidate tools.
This benchmark seems to be showing that things don't just remain the same. That, in fact, the circumstances in which C++ is a better choice than Java are becoming fewer and the advantage in those circumstances is becoming less.
The fact that Java VMs are primarily written in C or C++ indicates that at the time they were initially written, it was believed (I think correctly) that the C or C++ at that time would be a better platform for writing JVMs than the Java of that time, and that since then it has been considered better to extend the existing code than to scrap it and do a complete rewrite in Java.
That's all that this argument proves. Nothing more.
What I'm saying, though, should not be interpreted as a belief that today's Java would be a better choice than today's C++ for writing a Java JVM. I don't know what the relative advantages would be today.
But if C++ were STILL the best tool for writing a JVM from scratch today (certainly possible), that wouldn't mean much when trying to choose a tool for your own app, because most apps bear very little resemblance to a JVM.
I think Knoppix is an interesting idea, but I'm not sure that the questioner really needs a whole different operating system that requires shutting down whatever you're doing and rebooting whenever you want to do a little "grep" or "wc" or whatever. (If Knoppix now works as just another application without requiring a reboot, please respond and correct me.)
As an owner of Macs, Windows PCs, and a Linux server who uses Solaris at work, what I find I need on my laptop is the customized drivers and other goodies that come with it in the version of Windows XP that comes with it, plus the ability to run Windows GUI apps that have no acceptable equivalent in the Linux world, plus the array of command line Unix tools that I find so amazingly useful when I'm working on a Unix/Linux box.
Dual booting doesn't work for me. Having to wait for a reboot to use grep or wc is like having to get dressed in the middle of the night to go out to an outhouse in the dead of winter. (And I guess that makes DOS a chamberpot.)
Unless the machine I'm using is a server itself, in which case I need the full Linux (which is what I do with my home server), I find that combo of Cygwin plus the customized Windows that your manufacturer provides with their hardware to be a great solution (for a laptop, for today).
Look, there was a time when a large percentage of nighttime lighting in the "developed" world was provided by lamps that burned whale oil.
The whale population plummeted, prices went up, and people discovered "alternative energy sources" such as kerosine.
Pretty soon, nobody used whale oil anymore, but there were still whales available. The population of whales began to recover, but whale oil prices didn't plummet and return us to whale oil because people had stopped manufacturing it and consumers had stopped demanding it.
If the supply of oil ever gets to the point where there is serious economic pressure, the world will move on to something else, and this will happen before we run out.
I'm in favor of rapid exploration of energy alternatives not because we're going to run out of oil (we're not), but because of the danger that intentional, coordinated terrorist action might take a large percentage of production offline too suddenly for normal economic evolution to cope with.
Would this be better than standard pen & paper plus OCR?
This isn't an argument. I'm actually asking.
I looked at their website and saw that it claims a capacity of 40 pages before a download is required. That could be handy if I came home everyday from traveling and was able to sync it to a computer and then back up what I wrote.
I'm wondering how it would be on the road with a backpack, not wanting to carry much, and definitely not wanting to lug a computer around. I can buy paper anywhere, rain won't hurt it much as long as I use a ballpoint pen, which I can carry around with nobody wanting to steal it. And if I lose my notebook, I lose the data, but most thieves don't hungrily eye a pad of used paper, so the risk of that is low, unless they steal the whole backpack, in which case I can at least buy more paper and pens on the road anywhere....
I'm just wondering out load, because I'm guessing that now it wouldn't be too hard to buy an OCR setup that you would leave at home when you traveled. When you returned, you could just take an evening and scan everything, and the scanner would even let you scan flat souvenirs (tickets, maps, brochures, etc.) in addition to your own journals.
I'm just wondering if, for travelers, putting the cost of the IO into buying a scanner wouldn't be a better approach. And I don't even know what OCR software is capable of or costs these days....
I agree that there are serious problems to both paper (ultimately, I'll want it in electronic form) and electronics (electronic devices have lots of limitations on the road).
How is OCR technology coming along? How realistic is it now to take notes in a paper notebook and then load them into computer via OCR more or less painlessly? I usually print when I write anyway, like most programmers it seems, but I would want to be able to retain little diagrams and things that paper is really good at.
Would current OCR applications support this approach well? Any suggestions?
Hmm. Maybe you could climb back down off of your desk, take a deep breath, and explain how you might react if you actually DID have an inferiority complex.
I've done a lot of work with Japanese developers. They have no more interest in a "Japanese" programming language than they have in a pocket calculator that used kanji digits instead of Western digits.
The 52 letters, 10 digits, and handful of special characters in ASCII are easy for them to both read and type on local keyboards, and keywords like "if" and "while" are already familiar to most Japanese older than about 10 or so.
I'm not saying they speak English well. In general, they don't. I'm saying that writing code in symbols composed of ASCII characters is so much easier than English and so much like other things they do in school that it just isn't a problem.
The same is true for Chinese and Koreans, and if it's barely a challenge for them, it's nothing for most other cultures.
By the way, I *have* seen a Japanese BASIC that used katakana keywords. It was apparently intended for 12 yr olds, but even they rejected it as no easier than ordinary BASIC.
Though there is a much stronger argument for local-language identifier names, the programming language itself doesn't need translated keywords.
Written Chinese served the same role in Asia that Latin was serving in Europe. Pasar Melayu ("market Malay") is a language I learned to get by in places from Thailand to Papua New Guinea.
There have been, and continue to be, lots of linguae francae.
Actually, in my experience, the apps that require any math beyond counting pixels or doing a little algebra or back of the envelope estimates are far less than 10%.
And as for math being handy for optimizations, that's not my experience either. I've done a lot of optimizing, and it involves looking for bottlenecks with tools like profilers, or stubbing out parts of a system and seeing which part is causing the slowdown, or just thinking about your approach (which may at times be an algorithm) and looking for unnecessary repetition.
But I went ahead and learned the math anyway, because I love math. And it has definitely guided me toward certain projects where those skills would be useful, but that's a pretty small percentage of what's out there these days.
These days, I'd have to say that math, for the most part, is just another domain specialty, like finance, or physics, or taxes. It's not fundamental to software development.
Certain types of math are, however, fundamental to hard-core computer science, which is where I learned a lot of it, but it's probably more accurate to say that this type of computer science is mostly a field within applied math, and it has a surprisingly small overlap with the typical world of software development, which is much more heavily concerned with the specific capabilities, strengths, and weaknesses of various current development tools.
Re:Practical or somebody's thesis?
on
Robocones
·
· Score: 1
Seems to me that a better question is the relative risk of human workers moving traffic barriers versus risks of self-moving traffic barriers.
Traffic obstacles that move themselves in front of you sound like a great way to get cars to run into each other, and if you add in the potential for malfunctions... well, as I said, the question is still a statistical one, but not solely one of how many workmen are currently being killed.
Sun insists that they won't sell Java to IBM. IBM is now quite dependant on Java and have all sorts of ideas for how they would like to change it if they didn't have to constantly butt heads with Sun.
So, okay, fine, IBM can just wait a bit and buy Sun for a reasonable price. That way, Java won't have been released into the public domain and IBM won't have to argue (as much) when they want to change it.
IBM has the most to gain from control over Java -- arguably Microsoft has more but for legal reasons they won't bother even trying to buy Sun -- so they'll be willing to pay the most, so they'll get 'em.
Slashdot Mirror
There was a guy working on Lisp for Eclipse, and he got a lot of people so interested that he sort of ended up saying, "Never mind. It's nothing really, just a little experiment. Go away and leave me alone!" So, who knows....
The quality of error messages varies widely, but in general, error messages in functional-style programming tend not to be very informative, and though you don't have to use a functional style with Lisp, the error messages in Lisp tend to resemble those of functional languages.
I've never seen the kind of outrageous, mile-long messages you get spewing from C++ templates, though.
As for failing silently, that's not what happens, but a legitimate complaint is that, due to the dynamic nature of Lisp, certain types of errors that would be caught at compile time in C++ may not be caught until runtime in Lisp. Even so, I find C++ to be far more bug prone than Lisp.
Ah, a comp.lang.lisper wants to personally demonstrate why that group is incapable of forming the core of a thriving community.
I agree with you about the few good souls. Occasionally one of them will come to the defense of a newbie whose questions have implied a less than complete faith in the fundamentalist religion that Common Lisp has become, and who has been insulted, derided, and abused instead of answered.
On such occasions, the good souls themselves usually become the targets of the hostility for daring to defend who expressed a lack of faith. Their own faith is called into question, which often results in a display of groveling and profession of complete devotion to The Cause that is like something from the Spanish Inquisition.
It's so absurd that they frequently congratulate each other for particularly abusive remarks, like gang members urging each other to beat up some guy who accidentally wandered into their neighborhood.
What's most funny of all is to see them brag about how "beneficial" this pathological behavior is. They claim it sets high standards that benefit everyone, avoiding the intellectual pollution that apparently results from from weaknesses as friendliness, politeness, and patience.
Contrast that with a group like comp.lang.python, where the language, IMHO, is a poor shadow of Lisp in so many ways, but the community is so friendly and helpful (even to those who call Python a "poor shadow of Lisp", ahem) that Python just gets better and more attractive every year as people pitch in and create libraries, answer "how do I questions", and generally try to make your Python experience successful.
Since the Lisp emperor will verbally lop off your head if you notice his "wardrobe malfunction", I suspect I'll have to write off Common Lisp as a lost cause. There's little chance of a useful community coalescing around that rotten core, and without the community, Common Lisp has probably gone as far as it can go.
Like so many admirers of so many generic Lisp concepts, I'm left scanning the horizon for a New Lisp to appear--and not just another 1-man Scheme science project--but the odds are heavily stacked against anyone who makes the attempt, unfortunately.
I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages
Wait a minute. I have serious complaints about Lisp, but those are not among them. Let me take those in reverse order:
SLOWER THAN COMPILED LANGUAGES: No, there are compilers for both Lisp and Scheme that generate VERY fast code. There are interpreters that are as fast as Python that are nice to use during development, then you run it thru a compiler and the speed is on a par with C++, when performing similar operations. Of course a small amount of C++ code will often run much faster than a small amount of Lisp code, but that's because a small amount of Lisp code can say so much more than a small amount of C++ source can say. That shouldn't be counted against Lisp.
ILLEGIBLE: Not really, in my experience. I know what you mean, though. After a lot of use, it's still not quite as easy to read (for me) as something like Ruby or Python, which were already pretty clear even before I had written a single line of either. But it's nowhere near as hard to read as Perl still sometimes is for me, and I've been coding in Perl (occasionally) for a decade. Even C++, which I've done a lot of over the last decade, still gets pretty darned hard to read sometimes, such as when using templates to call old-style C APIs.
Lisp is a lot better than that. I've certainly grown to appreciate the way you can build abstractions out of abstractions and the top level is still called the same way as the bottom level. Self similarity at every level of abstraction, so you just have to think about the algorithms and not the syntax.
Trust me that, with practice, Lisp gets much easier to read, though it never seems to get quite as easy as something like Ruby or Python.
UGLY -- of course this is related to legibility. Again, I know what you mean, and I agree in some ways. A simple mathematical expression or loop is quite ugly, I think, compared to the same thing in Ruby or Python.
However, as soon as you leave the simple, built-in stuff and start building your own more complex functionality, you discover that Ruby and Python get uglier and uglier but Lisp still looks the same. As soon as you start trying to express really interesting algorithms (fancy searches, AI stuff, etc.), you'll see the beauty in the simple consistency of the syntax. (Much more true of Scheme than Common Lisp, BTW.)
So, no, I don't have any serious complaints in that regard. There's no speed problem at all and where it is harder to read, it's a small price to pay for the significant power boost that style of syntax gives you when working with really interesting problems.
So, what don't I like? The online community of users, for one. The misanthropes that took over comp.lang.lisp are pathetic. I've never seen a techical discussion group that hostile and defensive. Don't even think of asking them questions that might clear up some of your skepticism about Lisp. The fact that you have any doubts makes you unworthy of being treated with anything other than utter hostility.
They love Common Lisp like a religion, and hate everything, and everyONE else, even natural allies like Scheme. Common Lisp fossilized sometime back in the Reagan Administration and has since lost almost all ability to improve. As a result, the vast majority of former users have abandoned it and those who remain almost have to take a position that there is no further NEED for improvement except in trivial ways (more libraries, more "complete" implementations, etc.) that, if you think about it, are merely restatements of the "nothing needs to be improved" notion.
And that brings me to what I like least: it seems that the fundamental ideas underlying all forms of Lisp (incl. Scheme) are fascinating, and if redone in a way such as Paul Graham's Arc (www.paulgraham.com) could turn out to be a terrific language. Unfortunately, I don't see it happening. Arc is announcementware. It has shown no signs of life since its first few weeks. Com
Now *you* look up what I posted. I never said I couldn't understand why popularity mattered. I said that something like the Great Shootout could serve to bootstrap popularity. In an area like programming languages, which is subject to strong network effects, anything that could get the snowball started for a wider variety of languages would be useful--as I said.
Can YOU become an expert in Lisp in one week?
I've actually spent a number of years using Lisp. I've been paid to write software in somewhere between a dozen and two dozen languages, depending on your definition of language, and I assure you that your "acquire complete mastery of a new language in a week" test is completely irrelevant.
If you haven't even started to look at a language until a week before you need to be a master, it's not the fault of the project. You simply aren't qualified for that particular job.
But, unless you never do anything until someone else forces you to do it, you usually have years in which to get to know a new language. Over that time, you will either determine that it is not useful enough to add to your toolbox or you will have added it to the extent you feel it warrants.
So all I'm talking about is the advantages of a site like the Great Language Shootout that gives you a lot of information with which to make your decisions over that period of years that I'm referring to.
As with human language, some people are naturals when it comes to being fluent in multiple programming languages. Unfortunately, I am not one of their number.
That's unfortunate, because the ability to quickly learn to handle new specialty tools has significant competitive advantages--dare I call it "survival value"?
And with all the things one needs to learn to move beyond junior programmer these days (things like XML, DHTML, accessibility, SQL, MS Excel, version management utilities, scripting for metaprogramming tasks, etc., etc.) it just doesn't make sense to turn up your nose at improved programming languages.
I find it quite frustrating that there is such huge inertia in programming languages. Even when languages have some remarkable advantage, programmers won't use it because "nobody uses it."
.Net) is a Good Thing.
I don't deny that popularity provides some huge advantages. I just hope that there can be mechanisms to bootstrap popularity, and this Great Language Shootout is (potentially) the sort of thing the could do that.
Some languages, for example, have significant advantages in some specialty area: Erlang in parallelism, Lisp as a language for writing specialty languages, bug minimization approaches taken by Eiffel or the functional languages, etc. They may be awful for other types of work, but the fact that a hammer is a terrible saw doesn't make it any less of a great tool for the right problem.
If there were an active, busy site frequented by developers at which there were a wide variety of benchmarks that allowed uncommon languages to show off their specialty advantages, more developers would do some of their work in those languages, and the increasing popularity would result in better implementations and a flourishing of new languages.
Right now, the popular languages don't come close to taking full advantage of what we have learned about programming, and yet you would have to be either an academic or a fool to put a lot of effort into designing a great new language. The way things are right now, a great language designer probably has a better chance of being hit by lightning than he has of ever making his great new language popular.
Anything that reduces this language inertia (and YES that includes
There's no difference between an interpreter and a compiler in this case. Both take some Turing complete human-ish language (source code) and convert it into Turing complete machine instructions, which is all that the CPU understands. You could do all sorts of crazy things, a C *interpreter* written in Excel macros, for example. It just takes source and turns it into machine code, and the only question being addressed here is which technique results in faster ultimate execution of machine instructions and interactions with memory, the C++ source compiled into a wad of machine code in advance approach or the Java source compiled in advance into a wad of bytecode which is then compiled incrementally and cached by a JIT process approach. Each one allows for a different set of optimizations that convert the intent expressed in the original source into the closest thing to the minimum work the processor needs to do to carry out those intentions.
Many compilers and interpreters are written in themselves. Read the other comments about bootstrapping. And how do you think the first C compilers were written? In C?
When you understand bootstrapping, you'll understand how one would create a JVM written in Java. (IBM did just that.) It's not a question of whether it is possible, but what the pros and cons would be.
I don't deny that the finer granularity of C++, no make that plain C, no make that raw assembly language, allows you to make certain optimizations that are quite valuable in certain circumstances.
But when you are trying to choose the right tool for a particular job, you need to be current on the details of just what advantages, and what degree of advantage, and in what circumstances, comparing current versions of all of the candidate tools.
This benchmark seems to be showing that things don't just remain the same. That, in fact, the circumstances in which C++ is a better choice than Java are becoming fewer and the advantage in those circumstances is becoming less.
The fact that Java VMs are primarily written in C or C++ indicates that at the time they were initially written, it was believed (I think correctly) that the C or C++ at that time would be a better platform for writing JVMs than the Java of that time, and that since then it has been considered better to extend the existing code than to scrap it and do a complete rewrite in Java.
That's all that this argument proves. Nothing more.
What I'm saying, though, should not be interpreted as a belief that today's Java would be a better choice than today's C++ for writing a Java JVM. I don't know what the relative advantages would be today.
But if C++ were STILL the best tool for writing a JVM from scratch today (certainly possible), that wouldn't mean much when trying to choose a tool for your own app, because most apps bear very little resemblance to a JVM.
I think Knoppix is an interesting idea, but I'm not sure that the questioner really needs a whole different operating system that requires shutting down whatever you're doing and rebooting whenever you want to do a little "grep" or "wc" or whatever. (If Knoppix now works as just another application without requiring a reboot, please respond and correct me.)
As an owner of Macs, Windows PCs, and a Linux server who uses Solaris at work, what I find I need on my laptop is the customized drivers and other goodies that come with it in the version of Windows XP that comes with it, plus the ability to run Windows GUI apps that have no acceptable equivalent in the Linux world, plus the array of command line Unix tools that I find so amazingly useful when I'm working on a Unix/Linux box.
Dual booting doesn't work for me. Having to wait for a reboot to use grep or wc is like having to get dressed in the middle of the night to go out to an outhouse in the dead of winter. (And I guess that makes DOS a chamberpot.)
Unless the machine I'm using is a server itself, in which case I need the full Linux (which is what I do with my home server), I find that combo of Cygwin plus the customized Windows that your manufacturer provides with their hardware to be a great solution (for a laptop, for today).
Look, there was a time when a large percentage of nighttime lighting in the "developed" world was provided by lamps that burned whale oil.
The whale population plummeted, prices went up, and people discovered "alternative energy sources" such as kerosine.
Pretty soon, nobody used whale oil anymore, but there were still whales available. The population of whales began to recover, but whale oil prices didn't plummet and return us to whale oil because people had stopped manufacturing it and consumers had stopped demanding it.
If the supply of oil ever gets to the point where there is serious economic pressure, the world will move on to something else, and this will happen before we run out.
I'm in favor of rapid exploration of energy alternatives not because we're going to run out of oil (we're not), but because of the danger that intentional, coordinated terrorist action might take a large percentage of production offline too suddenly for normal economic evolution to cope with.
Would this be better than standard pen & paper plus OCR?
This isn't an argument. I'm actually asking.
I looked at their website and saw that it claims a capacity of 40 pages before a download is required. That could be handy if I came home everyday from traveling and was able to sync it to a computer and then back up what I wrote.
I'm wondering how it would be on the road with a backpack, not wanting to carry much, and definitely not wanting to lug a computer around. I can buy paper anywhere, rain won't hurt it much as long as I use a ballpoint pen, which I can carry around with nobody wanting to steal it. And if I lose my notebook, I lose the data, but most thieves don't hungrily eye a pad of used paper, so the risk of that is low, unless they steal the whole backpack, in which case I can at least buy more paper and pens on the road anywhere....
I'm just wondering out load, because I'm guessing that now it wouldn't be too hard to buy an OCR setup that you would leave at home when you traveled. When you returned, you could just take an evening and scan everything, and the scanner would even let you scan flat souvenirs (tickets, maps, brochures, etc.) in addition to your own journals.
I'm just wondering if, for travelers, putting the cost of the IO into buying a scanner wouldn't be a better approach. And I don't even know what OCR software is capable of or costs these days....
Just wondering....
I agree that there are serious problems to both paper (ultimately, I'll want it in electronic form) and electronics (electronic devices have lots of limitations on the road).
How is OCR technology coming along? How realistic is it now to take notes in a paper notebook and then load them into computer via OCR more or less painlessly? I usually print when I write anyway, like most programmers it seems, but I would want to be able to retain little diagrams and things that paper is really good at.
Would current OCR applications support this approach well? Any suggestions?
Hmm. Maybe you could climb back down off of your desk, take a deep breath, and explain how you might react if you actually DID have an inferiority complex.
I've done a lot of work with Japanese developers. They have no more interest in a "Japanese" programming language than they have in a pocket calculator that used kanji digits instead of Western digits.
The 52 letters, 10 digits, and handful of special characters in ASCII are easy for them to both read and type on local keyboards, and keywords like "if" and "while" are already familiar to most Japanese older than about 10 or so.
I'm not saying they speak English well. In general, they don't. I'm saying that writing code in symbols composed of ASCII characters is so much easier than English and so much like other things they do in school that it just isn't a problem.
The same is true for Chinese and Koreans, and if it's barely a challenge for them, it's nothing for most other cultures.
By the way, I *have* seen a Japanese BASIC that used katakana keywords. It was apparently intended for 12 yr olds, but even they rejected it as no easier than ordinary BASIC.
Though there is a much stronger argument for local-language identifier names, the programming language itself doesn't need translated keywords.
Written Chinese served the same role in Asia that Latin was serving in Europe. Pasar Melayu ("market Malay") is a language I learned to get by in places from Thailand to Papua New Guinea.
There have been, and continue to be, lots of linguae francae.
Actually, in my experience, the apps that require any math beyond counting pixels or doing a little algebra or back of the envelope estimates are far less than 10%.
And as for math being handy for optimizations, that's not my experience either. I've done a lot of optimizing, and it involves looking for bottlenecks with tools like profilers, or stubbing out parts of a system and seeing which part is causing the slowdown, or just thinking about your approach (which may at times be an algorithm) and looking for unnecessary repetition.
But I went ahead and learned the math anyway, because I love math. And it has definitely guided me toward certain projects where those skills would be useful, but that's a pretty small percentage of what's out there these days.
These days, I'd have to say that math, for the most part, is just another domain specialty, like finance, or physics, or taxes. It's not fundamental to software development.
Certain types of math are, however, fundamental to hard-core computer science, which is where I learned a lot of it, but it's probably more accurate to say that this type of computer science is mostly a field within applied math, and it has a surprisingly small overlap with the typical world of software development, which is much more heavily concerned with the specific capabilities, strengths, and weaknesses of various current development tools.
Seems to me that a better question is the relative risk of human workers moving traffic barriers versus risks of self-moving traffic barriers.
Traffic obstacles that move themselves in front of you sound like a great way to get cars to run into each other, and if you add in the potential for malfunctions... well, as I said, the question is still a statistical one, but not solely one of how many workmen are currently being killed.
Sun insists that they won't sell Java to IBM. IBM is now quite dependant on Java and have all sorts of ideas for how they would like to change it if they didn't have to constantly butt heads with Sun.
So, okay, fine, IBM can just wait a bit and buy Sun for a reasonable price. That way, Java won't have been released into the public domain and IBM won't have to argue (as much) when they want to change it.
IBM has the most to gain from control over Java -- arguably Microsoft has more but for legal reasons they won't bother even trying to buy Sun -- so they'll be willing to pay the most, so they'll get 'em.
So, you have a Mac, and run a Windows emulator on top of it, then run a unix emulator on top of that....
Do you, by any chance, run a Mac emulator on Cygwin?
Where can you get digital photos printed with equipment like this? Any online service providers that you are aware of?
Ah, I'll answer my own question.
The quick reference is not really a standalone document. It is the summary of the longer PDF that assumes you have already read the longer doc.
What the longer document says is that my cherry-Kool-Aid-smelling Sharpie would be in the "aromatic organic solvent" category that should not be used.
Alcohol substitutes are also a solvent that should probably not be used, but aren't nearly as bad.
The recommendation is for the use of water-based markers.