So patents are keeping developers from coming up with a better approach?
The patent prevents developers from stealing somone else's invention, not from orginal thought.
1. That is not true, if I independently come up with a way of doing font hinting that is similar to the patented one, the patent could prevent me from using it. 2. That said, the freetype autohinter is a better approach that basically works--look at a modern distro and you'll see font support better than what Windows has.
Call me a shit head, but that is the exact type of thing I wouldn't want any involvment in. Just what I need, to get involved in someone's drug deal gone bad.
I had him go around to the back of the house (outside) and wait for the paramedics. Up to him if he wants to run or wait. He waited. My understanding is that neither he nor his assailents were ever prosecuted (the cops showed up at our house about a half hour later and asked a few questions, then left).
At least 3 of the examples I gave (homeless seeking shelter, trying to put out a fire, pursuing an animal) could easily involve literal B&E or something like climbing in through a window or other VERY suspicious-looking behavior.
I'm not 100% opposed to using weapons for self defense, but be careful with it.
If someone enters your house without your permission and without announcing themselves, what's the chance they have good motives?
Neither zero nor vanishingly small, and bad motives alone don't justify homicide (if they're going to injure or harm you/your family, or steal anything material, then you can at least start arguing about it).
And that's what matters if you're talking about filling them with lead. * They spotted a fire and are running in trying to put it out * Their dog ran in your front door and they're trying to get it before it hurts someone * They are dead drunk and live next door and stumbled into the wrong house (I've gone into the wrong apartment building in a complex where all the buildings were identical, but realized it when my key didn't fit the lock to "my" apartment--if the door to the apartment had been unlocked I probably would've gone in, realized it was the wrong place, and left). * They are fleeing danger of some sort (I've had someone show up at my doorstep covered in blood, apparently after a drug deal gone bad. * They're a homeless person trying to sleep in your foyer for the night during a blizzard (I've had this happen with a girlfriend's car) etc
Some of these are cause to call the cops and have them hauled off to jail (or at least off your property), but not to shoot at someone.
OTOH, if someone comes through the front door at night unexpectedly and seems to be coming at you, you have a pretty good case that you reasonably expected they were trying to do serious bodily harm--even more if you yell at them to identify themself and get no response (and they don't retreat).
In the real world, be careful--I have a friend whose wife was in bed with him and heard a sound downstairs. He went to get his gun, went out in the hall, and saw a figure coming at him in the dark. He fired 2 shots at it before realizing it was his wife (who had stepped out to investigate)--thank god he missed her. He purposefully leaves the bullet holes unpatched as a reminder.
[That was in Ecuador, where it's much more likely that you'll get armed robbers invading your house, and he had actually had a friend's entire family killed by home invaders the year before--but in his case, the cat had knocked over a chair downstairs.]
Moral: If you're going to shoot someone, make darned sure they deserve it first (and make sure you know where your loved ones are).
Uh, in the real world "moisture vaporator", "R2 unit", "blaster", "make the kessel run in under 12 parsecs", "protocol droid", etc. are all technobabble. It doesn't have to be explanatory (or even sensible--under 12 parsecs?)
Well, in *English* the distinction between sci-fi and fantasy is exactly the background. If you change Star Wars to have magical arrows and flying horses instead of blasters and X-Wings then you just changed the genre.
Any definition of sci-fi that puts Star Wars outside that category is not the same as the common English language definition. If you're looking for more precise or alternative terms, don't overload an already meaningful word; at least use a phrase like "hard sci-fi" (or a broader alternative if required) that doesn't sow confusion and misappropriate a perfectly good word.
You may choose to define it however you want, but to the average English-speaking person it is precisely the technobabble and backdrop that make the difference between sci-fi and fantasy.
There's a genre jargon definition of sci-fi that is along the lines of having a rational explanation for how things work, but in English it means having blinkenlights and cool tech instead of dragons and magic wands. The only real difference between a blaster and a magic wand is a technobabble/backdrop one, but it turns out to most people that's a very large distinction (so much so that most people would consider the first Pern book to be fantasy even though to a hardcore fan there's an argument to be made that it fits the jargon definition of sci-fi).
if NP is found to be P, then it will effectively hose encryption as we know it today. Your private-key/public-key encryption that relies on those big primes you know and love? Well then would be easily broken
Not true at all.
Being inside P doesn't necessarily make a problem fast or easy to solve. If an algorithm is found that can factor an n-bit number in google*(n^google) steps, then factoring is in P. That doesn't make it particularly easy to factor large numbers, though. Being in NP if NP>P implies that a problem is harder for sufficiently large n, but "sufficiently large" may be REALLY large--it might even be "n has to be larger than the total number of atoms in the universe".
Aside 1: The same is true of lower complexity classes as well. As a simple example, for small n, insertion sort is faster than quicksort even though it's abysmal for large n. There are problems that have a solution thats O(n) and a solution that's O(n^2), but the O(n) solution requires someconstant*n time while the O(n^2) solution requires n^2 time. Until n is at least someconstant, the O(n^2) solution is faster.
Aside 2: There's no proof that factoring is outside of P even if P!=NP. It's widely believed to be true but unproven.
As I understand it, this contest is basically "who can turn out the shittiest code that still runs?"
No, the obfuscation is often secondary, or at least the "don't indent, use one-letter names" portion of the obfuscation.
Example of a past winner: The output of the entry was a program that would flip an input text file on a diagonal axis. So e.g.:
ab cd
was turned into:
ac bd
Simple, right? Sure, but the source code itself was such that if it was flipped on the axis, it became compileable source code to another program that flipped the input text on the other diagonal:
ac bd
became
dc ba
And when that was run on the second program, it became compileable source for a program that flipped the input across the horizontal axis, to:
ba dc
And when that was run on the third program, it became compileable source for a program that flipped the input across the vertical axis, to:
ab cd
which was the original source code.
You can't tell me that writing source code that can be flipped on its axes 3 times to generate 4 different legal C programs isn't pretty damned clever. Useless, but clever.
So it's not about shitty code, it's about useless but very elegant code.
Sure. But it's hardly intuitive now is it? The intuitive interface would be the one where you type your name and it appears in the document. The unintuitive one requires you to go mess around in the options and tweak things before you can accomplish as simple a task as writing a letter home to mom.
Word is certainly powerful, but in a lot of ways it's not really all that intuitive.
So technically, it is stable (doesn't crash), has a lot of nice featurs (and a lot of annying ones) and is intuitive to use (for the most part)
I would dispute #3, given that if I type my name and hit space then the document contains something other than my name (unless I grovel around in config options and turn off the "Autocorrect spelling" misfeature). At least that was true last time I used Word.
I don't mean they look and feel the same, I mean they can do the same things. Well, they're all Turing complete so the capability is always the same, right?
Really, it's how quickly, effectively, and maintainably you can get the job done that matters, and while you're right that C# and Java are the same, Java and Python or VB and C are very far apart on the language spectrum, and I actually think there is more diversity and divergence now in maintstream programming languages than there was 10 years ago (though maybe not as much as there was 20 years ago)
The non declarative approach is a matter of taste, but in the end you have to write much more unit tests than with a declarative approach, thus nullifying the loc argument basically to a negative factor.
Do you have any evidence to support this claim? In my experience, it isn't true; the unit tests tend to look much the same whether I'm using a statically typed language or a dynamically typed language.
The other thing is the speed claimed by python. Face it the VM is rather slow (until parrot or another VM takes over), most modern vms including the java one (which is one of the best) runs circles around Python
OTOH, the libraries are extremely fast, especially compared to Java's (especially for file I/O), and in real life the overall benchmarks seems to favor Python over Java for largely I/O driven tasks (e.g. dynamic web page generation or database-driven applications). Java wins over standard CPython for many computational tasks, though Psyco often tips the balance back toward Python.
I would never program a bigger system in Python
Fair enough. I would personally never program a bigger system in C++. On the other hand, the 30,000+ lines of Python we have at work seem to work very well and I would choose the same language if I had to implement the task over again (indeed, this is the third company I've worked for in the past 8 years that has developed successful bigger systems in Python, though at one of those Python was only one of several languages used).
You can't do verification in general if "command()" could mean anything!
You can't do verification in general anyway.
There are some somewhat interesting results about proof-carrying code (e.g. Peter Lee's ELF/ML work at Carnegie Mellon's Fox group, currently being extended to Java by a group at Princeton) that have implemented nontrivial applications in strongly typed languages and proven them "correct" (for certain definitions of "correct").
That said, many of the techniques used in static verification can be implemented in dynamic languages using run-time checks, such that you can know before the program is run that conditions A, B, and C will not be violated. George Necula (formerly of the Fox group) has done this to e.g. implement a system for making your C programs provably memory-safe (ie no buffer overruns, etc) and has plenty of results proving even stronger conditions in weakly typed languages.
And historically, plenty of work has been done on verifying Lisp code as well.
You have to pin down method semantics with types
True, but this doesn't mean that explicit type definitions are needed nor does it mean that static typing is required. Both dynamically typed and statically typed languages can benefit from type inference.
But I'm unconvinced that a verification approach is a good general approach to software engineering, though. For many (most?) projects, the functional specifications are pretty vague at best and subject to change without notice. Addressing that real-world situation is something dynamically typed languages do very well.
I think that the current popular set of languages all share the same set of capabilities because these capabilities are the set that have evolved as the "necessary" set. In other words, there are a certain set of abilities that are demanded by most users; the languages that support them are more successful; and consequently, most of the "big" languages currently are very similar.
Except that the "big" languages are not very similar. I would think that currently C, Java, Perl, and VBscript are near the top of the "big" language heap and they are pretty far apart on most of the major axes. Even within a single small domain like web programming there's a split between page-inline languages (e.g. ASP, PHP, Coldfusion) and server object/template transform solutions (most Python/Java-based solutions. There's a split between static and dynamic typing. There's a split between OO solutions, functional solutions, and procedural solutions.
Really, most languages have agreed to spell conditionals "if" and loops "for" or "while". They agree that there should be some way of defining and calling procedures and returning values from them. They seem to agree that seperating code into multiple files is good. But there isn't all that much consensus outside of that--not even on basic things like "should functions have their own scope?" or "what happens if I add two numbers?"
It's about the market acting as a darwinian laboratory which is spawning useful languages.
A whole ecosystem of them, each very competitive in certain niches and some more widely useful than others.
Actually, I'd say that's one of Java's strengths: it brought useful concepts and features to mainstream coders that used to only be in non-mainstream languages. C++ did the same thing.
Not sure I agree about Java. The only thing I can think of offhand that Java brought in that wasn't in mainstream language implementations was the sandbox.
We managed to drag a lot of them about halfway to Lisp.
I think this is exactly what geeks hate; as I said in the parent post, geeks want the language to support a feature fully or not at all. From that perspective, it's actually worse to have e.g. some support for functional programming (but not complete support) than none at all; it's also better to have them in C than halfway to Lisp even if all the way to Lisp is the ideal.
(and of course comparing a basically statically typed, object oriented language to a primarily non-oo dynamically typed language is a bit suspect...)
Seems odd to the non-geek to penalize something for having a partial feature, but I think it's part of the key to understanding why Java is "considered Un-Cool" (after all, C++ is mostly C PLUS additional features, yet it isn't considered cool either).
ESR did most of his work in C and Perl, and now is a Python advocate
He did a fair amount of Lisp work as well IIRC. His resume now says "My high level languages include C, LISP, Pascal, APL, FORTRAN and several BASICS, Tcl, Expect, Perl, and Python; I am best, and highly expert, at C, LISP, and Python."
JWZ's main projects (correct me if I'm wrong) are Netscape/Mozilla and XEmacs, the former of which is written in C/C++ and the latter of which is pretty much inherently a bastion of Lisp
He also did a lot of work on Lisp machines which is still in the CMU AI repository somewhere under ftp://ftp.cs.cmu.edu/user/ai/lang/lisp/
This is a Good Thing(tm). You want a system that is maintainable. You're not going to get this if two dozen developers each use their pet language du'jour. When you have Java, C#, C++, Python and Ruby advocates all working on the same project, you don't want them deciding what language their individual components will use. That way leads to chaos.
Disagree, strongly. If the system components are well isolated, picking the right tool for each job is going to make the development and maintenance both much less chaotic than trying to shoehorn one tool into attacking each task. And using heterogenous languages can often be helpful to enforce good isolation of independent systems and identify where the actual interdependecies are.
To take one example that is fairly representative in my experience:
The system I wrote at a top-50 web company to do dynamic content generation is written in Java, C, C++, Python, Perl, and sh--and this in a house that uses ASP/VBScript for the web development side of things. It's been running fine for the past 3 years with less than 4 weeks of maintenance/feature-add time allocated to it from the coding side (there were another 5 days of sysadmin time for a server upgrade at one point). Not only have they not had problems with new programmers maintaining it (despite 3 of the 4 programmers who wrote it moving on to new jobs, and the 4th moving into management), it was also delivered on time (meeting an 18-month deadline).
[At last check it's served over 10 billion requests. It's a pretty complex system consisting of 10-15 seperate programs, everything from a GUI interface for the content developers to a publishing system to network server for content delivery to reporting tools and integration with external systems/databases/web servers.]
I would hate to have done most of the data summarization work in Java, or the GUI in C, or the TCP server in Python, or...you get the idea. I firmly believe that a management decision to use exactly one prescribed language would have made the system take longer to develop and be more costly to maintain.
IOW, Pick the right tool for the job. I've even picked VB as the right tool once recently (mainly because the system in question had some VB hooks in place already and the task at hand was manageable even in a basically crufty language).
Neither Lisp nor ML is a full-out functional language:
You miss the point. Lisp and ML have full-out support for functional programming (unlike, say, Python, which is one of the big arguments against it--don't half-ass it, do it right if you're going to do it.
C++ and Java have sort of halfway-there OO implementations by the classic definition, and Java (forget C++) certainly doesn't have anything an ML (or Haskell) programmer would call "strong typing".
It's not that geeks feel a language should only support one feature/programming model, it's that if you're going to support one it should be done "right" and "with elegance" (which terms have somewhat nebulous definitions).
braino: If you're going to be dynamically typed, by really dynamic like Scheme and Lisp. Fine here.
If you're going to be OO, support it fully like Scheme, Python, and Objective C (and geeks tend to support the Scheme-world definition of OO) Replace "Scheme" with "Smalltalk" here. Ugh, typing too fast.
A lot of geeks give Lisp props, but who actually uses it?
Many people. (More than use Ruby, I would venture to guess, simply because of the widespread presence of emacs.)
Those I mentioned above--ESR, JWZ, Stallman--all have significant projects written in lisp, not just papers on "gee whiz, isn't it cool". Not a lot of it is system software, so it often gets overllooked by the Linux crowd, but check out the lisp repositories at CMU, MIT, and Stanford--since implementations aren't widespread, usage tends to congregate where implementations are in the default setup.
The main problem with Lisp is implementation availability, which is why many people writing lisp apps outside of a controlled environment tend to write them for Emacs. A number of those are fairly widespread. There are some serious CL apps out there (e.g. Allegro FTPd) written in lisp as well, not to mention GnuCash and GIMP and a number of other packages with significant functionality written in scheme. (And heck, you can find 4 or 5 different window managers written in lisp, scheme, or guile on freshmeat.)
(BTW, I'm surprised you hold up Python as an example of OO purity. Perhaps you meant Ruby?)
I'm more surprised you didn't notice my smalltalk->scheme braino.
Most developers I know basically slam it for it's reputation for being slow, and frankly, because it's not C, the geek Gold Standard.
That's not it at all. First off, I'd say Lisp (not C) is the geek Gold Standard--most of your top-name geeks, from Mccarthy on through RMS to Jamie Zawinski and ESR have been LISP hackers, with the notable exception of kernel/systems guys. Even GIMP was written by LISP fans. But C is definitely in the running, primarily because it fits a (rather large) niche very well--it's the closest thing to a portable assembly out there when you need to get down to the nuts and bolts and still be kind of portable.
[Note that I am not supporting any of the following arguments, merely enumerating what I think some of the objections to Java are.]
What Java doesn't do, from a geek standpoint, is fill a niche very well. A true hacker wants a language that is committed; if you're going to be strongly typed, be VERY strongly typed and have a decent type inference mechanism a la Haskell or ML. If you're going to be dynamically typed, by really dynamic like Scheme and Lisp. If you're going to be OO, support it fully like Scheme, Python, and Objective C (and geeks tend to support the Scheme-world definition of OO). And if you're going to be functional, do _that_ full-out like Lisp and ML.
Note that these are all language features. Most geeks want to support a language based on the language itself, not on the libraries or the implementation ("those can be fixed" is the somewhat insightful and somewhat naive argument). As a language, Java isn't anything new and doesn't fit any of those areas as well as other languages.
I think it's almost secondary that Java is a B&D language; it's the failure to be pure about how it implements various programming paradigms and type structures that gives it the geek *yawn*. C++ suffers from the same thing.
Slashdot Mirror
The day computers never swap and disk I/O isn't a bottleneck will be the day we can ignore code size in compiler benchmarks.
Only once the L1 cache is the same size as RAM.
Certain versions of the successor (originally text-mode) links browser do display JPG and other image formats. Take a look at: http://atrey.karlin.mff.cuni.cz/~clock/twibright/l inks/features.html
Apparently the above text violates the lameness filter so I have to add some more variety here to allow my post through.
So patents are keeping developers from coming up with a better approach?
The patent prevents developers from stealing somone else's invention, not from orginal thought.
1. That is not true, if I independently come up with a way of doing font hinting that is similar to the patented one, the patent could prevent me from using it.
2. That said, the freetype autohinter is a better approach that basically works--look at a modern distro and you'll see font support better than what Windows has.
Call me a shit head, but that is the exact type of thing I wouldn't want any involvment in. Just what I need, to get involved in someone's drug deal gone bad.
I had him go around to the back of the house (outside) and wait for the paramedics. Up to him if he wants to run or wait. He waited. My understanding is that neither he nor his assailents were ever prosecuted (the cops showed up at our house about a half hour later and asked a few questions, then left).
At least 3 of the examples I gave (homeless seeking shelter, trying to put out a fire, pursuing an animal) could easily involve literal B&E or something like climbing in through a window or other VERY suspicious-looking behavior.
I'm not 100% opposed to using weapons for self defense, but be careful with it.
If someone enters your house without your permission and without announcing themselves, what's the chance they have good motives?
Neither zero nor vanishingly small, and bad motives alone don't justify homicide (if they're going to injure or harm you/your family, or steal anything material, then you can at least start arguing about it).
And that's what matters if you're talking about filling them with lead.
* They spotted a fire and are running in trying to put it out
* Their dog ran in your front door and they're trying to get it before it hurts someone
* They are dead drunk and live next door and stumbled into the wrong house (I've gone into the wrong apartment building in a complex where all the buildings were identical, but realized it when my key didn't fit the lock to "my" apartment--if the door to the apartment had been unlocked I probably would've gone in, realized it was the wrong place, and left).
* They are fleeing danger of some sort (I've had someone show up at my doorstep covered in blood, apparently after a drug deal gone bad.
* They're a homeless person trying to sleep in your foyer for the night during a blizzard (I've had this happen with a girlfriend's car)
etc
Some of these are cause to call the cops and have them hauled off to jail (or at least off your property), but not to shoot at someone.
OTOH, if someone comes through the front door at night unexpectedly and seems to be coming at you, you have a pretty good case that you reasonably expected they were trying to do serious bodily harm--even more if you yell at them to identify themself and get no response (and they don't retreat).
In the real world, be careful--I have a friend whose wife was in bed with him and heard a sound downstairs. He went to get his gun, went out in the hall, and saw a figure coming at him in the dark. He fired 2 shots at it before realizing it was his wife (who had stepped out to investigate)--thank god he missed her. He purposefully leaves the bullet holes unpatched as a reminder.
[That was in Ecuador, where it's much more likely that you'll get armed robbers invading your house, and he had actually had a friend's entire family killed by home invaders the year before--but in his case, the cat had knocked over a chair downstairs.]
Moral: If you're going to shoot someone, make darned sure they deserve it first (and make sure you know where your loved ones are).
Uh, in the real world "moisture vaporator", "R2 unit", "blaster", "make the kessel run in under 12 parsecs", "protocol droid", etc. are all technobabble. It doesn't have to be explanatory (or even sensible--under 12 parsecs?)
It's both (assuming your description is accurate).
Not every movie is in exactly one genre--there are plenty of sci-fi horror movies, or period mysteries, or whatever else.
Well, in *English* the distinction between sci-fi and fantasy is exactly the background. If you change Star Wars to have magical arrows and flying horses instead of blasters and X-Wings then you just changed the genre.
Any definition of sci-fi that puts Star Wars outside that category is not the same as the common English language definition. If you're looking for more precise or alternative terms, don't overload an already meaningful word; at least use a phrase like "hard sci-fi" (or a broader alternative if required) that doesn't sow confusion and misappropriate a perfectly good word.
You may choose to define it however you want, but to the average English-speaking person it is precisely the technobabble and backdrop that make the difference between sci-fi and fantasy.
There's a genre jargon definition of sci-fi that is along the lines of having a rational explanation for how things work, but in English it means having blinkenlights and cool tech instead of dragons and magic wands. The only real difference between a blaster and a magic wand is a technobabble/backdrop one, but it turns out to most people that's a very large distinction (so much so that most people would consider the first Pern book to be fantasy even though to a hardcore fan there's an argument to be made that it fits the jargon definition of sci-fi).
if NP is found to be P, then it will effectively hose encryption as we know it today. Your private-key/public-key encryption that relies on those big primes you know and love? Well then would be easily broken
Not true at all.
Being inside P doesn't necessarily make a problem fast or easy to solve. If an algorithm is found that can factor an n-bit number in google*(n^google) steps, then factoring is in P. That doesn't make it particularly easy to factor large numbers, though. Being in NP if NP>P implies that a problem is harder for sufficiently large n, but "sufficiently large" may be REALLY large--it might even be "n has to be larger than the total number of atoms in the universe".
Aside 1: The same is true of lower complexity classes as well. As a simple example, for small n, insertion sort is faster than quicksort even though it's abysmal for large n. There are problems that have a solution thats O(n) and a solution that's O(n^2), but the O(n) solution requires someconstant*n time while the O(n^2) solution requires n^2 time. Until n is at least someconstant, the O(n^2) solution is faster.
Aside 2: There's no proof that factoring is outside of P even if P!=NP. It's widely believed to be true but unproven.
As I understand it, this contest is basically "who can turn out the shittiest code that still runs?"
No, the obfuscation is often secondary, or at least the "don't indent, use one-letter names" portion of the obfuscation.
Example of a past winner:
The output of the entry was a program that would flip an input text file on a diagonal axis. So e.g.:
ab
cd
was turned into:
ac
bd
Simple, right? Sure, but the source code itself was such that if it was flipped on the axis, it became compileable source code to another program that flipped the input text on the other diagonal:
ac
bd
became
dc
ba
And when that was run on the second program, it became compileable source for a program that flipped the input across the horizontal axis, to:
ba
dc
And when that was run on the third program, it became compileable source for a program that flipped the input across the vertical axis, to:
ab
cd
which was the original source code.
You can't tell me that writing source code that can be flipped on its axes 3 times to generate 4 different legal C programs isn't pretty damned clever. Useless, but clever.
So it's not about shitty code, it's about useless but very elegant code.
Sure. But it's hardly intuitive now is it? The intuitive interface would be the one where you type your name and it appears in the document. The unintuitive one requires you to go mess around in the options and tweak things before you can accomplish as simple a task as writing a letter home to mom.
Word is certainly powerful, but in a lot of ways it's not really all that intuitive.
So technically, it is stable (doesn't crash), has a lot of nice featurs (and a lot of annying ones) and is intuitive to use (for the most part)
I would dispute #3, given that if I type my name and hit space then the document contains something other than my name (unless I grovel around in config options and turn off the "Autocorrect spelling" misfeature). At least that was true last time I used Word.
Sumner
What does Microsoft use to write its OS and applications? From everything I've heard it's all C and Win32.
Very little is written in C, it's mostly C++.
I don't mean they look and feel the same, I mean they can do the same things.
Well, they're all Turing complete so the capability is always the same, right?
Really, it's how quickly, effectively, and maintainably you can get the job done that matters, and while you're right that C# and Java are the same, Java and Python or VB and C are very far apart on the language spectrum, and I actually think there is more diversity and divergence now in maintstream programming languages than there was 10 years ago (though maybe not as much as there was 20 years ago)
The non declarative approach is a matter of taste, but in the end you have to write much more unit tests than with a declarative approach, thus nullifying the loc argument basically to a negative factor.
Do you have any evidence to support this claim? In my experience, it isn't true; the unit tests tend to look much the same whether I'm using a statically typed language or a dynamically typed language.
The other thing is the speed claimed by python. Face it the VM is rather slow (until parrot or another VM takes over), most modern vms including the java one (which is one of the best) runs circles around Python
OTOH, the libraries are extremely fast, especially compared to Java's (especially for file I/O), and in real life the overall benchmarks seems to favor Python over Java for largely I/O driven tasks (e.g. dynamic web page generation or database-driven applications). Java wins over standard CPython for many computational tasks, though Psyco often tips the balance back toward Python.
I would never program a bigger system in Python
Fair enough. I would personally never program a bigger system in C++. On the other hand, the 30,000+ lines of Python we have at work seem to work very well and I would choose the same language if I had to implement the task over again (indeed, this is the third company I've worked for in the past 8 years that has developed successful bigger systems in Python, though at one of those Python was only one of several languages used).
You can't do verification in general if "command()" could mean anything!
You can't do verification in general anyway.
There are some somewhat interesting results about proof-carrying code (e.g. Peter Lee's ELF/ML work at Carnegie Mellon's Fox group, currently being extended to Java by a group at Princeton) that have implemented nontrivial applications in strongly typed languages and proven them "correct" (for certain definitions of "correct").
That said, many of the techniques used in static verification can be implemented in dynamic languages using run-time checks, such that you can know before the program is run that conditions A, B, and C will not be violated. George Necula (formerly of the Fox group) has done this to e.g. implement a system for making your C programs provably memory-safe (ie no buffer overruns, etc) and has plenty of results proving even stronger conditions in weakly typed languages.
And historically, plenty of work has been done on verifying Lisp code as well.
You have to pin down method semantics with types
True, but this doesn't mean that explicit type definitions are needed nor does it mean that static typing is required. Both dynamically typed and statically typed languages can benefit from type inference.
But I'm unconvinced that a verification approach is a good general approach to software engineering, though. For many (most?) projects, the functional specifications are pretty vague at best and subject to change without notice. Addressing that real-world situation is something dynamically typed languages do very well.
I think that the current popular set of languages all share the same set of capabilities because these capabilities are the set that have evolved as the "necessary" set. In other words, there are a certain set of abilities that are demanded by most users; the languages that support them are more successful; and consequently, most of the "big" languages currently are very similar.
Except that the "big" languages are not very similar. I would think that currently C, Java, Perl, and VBscript are near the top of the "big" language heap and they are pretty far apart on most of the major axes. Even within a single small domain like web programming there's a split between page-inline languages (e.g. ASP, PHP, Coldfusion) and server object/template transform solutions (most Python/Java-based solutions. There's a split between static and dynamic typing. There's a split between OO solutions, functional solutions, and procedural solutions.
Really, most languages have agreed to spell conditionals "if" and loops "for" or "while". They agree that there should be some way of defining and calling procedures and returning values from them. They seem to agree that seperating code into multiple files is good. But there isn't all that much consensus outside of that--not even on basic things like "should functions have their own scope?" or "what happens if I add two numbers?"
It's about the market acting as a darwinian laboratory which is spawning useful languages.
A whole ecosystem of them, each very competitive in certain niches and some more widely useful than others.
Actually, I'd say that's one of Java's strengths: it brought useful concepts and features to mainstream coders that used to only be in non-mainstream languages. C++ did the same thing.
Not sure I agree about Java. The only thing I can think of offhand that Java brought in that wasn't in mainstream language implementations was the sandbox.
We managed to drag a lot of them about halfway to Lisp.
I think this is exactly what geeks hate; as I said in the parent post, geeks want the language to support a feature fully or not at all. From that perspective, it's actually worse to have e.g. some support for functional programming (but not complete support) than none at all; it's also better to have them in C than halfway to Lisp even if all the way to Lisp is the ideal.
(and of course comparing a basically statically typed, object oriented language to a primarily non-oo dynamically typed language is a bit suspect...)
Seems odd to the non-geek to penalize something for having a partial feature, but I think it's part of the key to understanding why Java is "considered Un-Cool" (after all, C++ is mostly C PLUS additional features, yet it isn't considered cool either).
ESR did most of his work in C and Perl, and now is a Python advocate
He did a fair amount of Lisp work as well IIRC. His resume now says "My high level languages include C, LISP, Pascal, APL, FORTRAN and several BASICS, Tcl, Expect, Perl, and Python; I am best, and highly expert, at C, LISP, and Python."
JWZ's main projects (correct me if I'm wrong) are Netscape/Mozilla and XEmacs, the former of which is written in C/C++ and the latter of which is pretty much inherently a bastion of Lisp
He also did a lot of work on Lisp machines which is still in the CMU AI repository somewhere under ftp://ftp.cs.cmu.edu/user/ai/lang/lisp/
This is a Good Thing(tm). You want a system that is maintainable. You're not going to get this if two dozen developers each use their pet language du'jour. When you have Java, C#, C++, Python and Ruby advocates all working on the same project, you don't want them deciding what language their individual components will use. That way leads to chaos.
Disagree, strongly. If the system components are well isolated, picking the right tool for each job is going to make the development and maintenance both much less chaotic than trying to shoehorn one tool into attacking each task. And using heterogenous languages can often be helpful to enforce good isolation of independent systems and identify where the actual interdependecies are.
To take one example that is fairly representative in my experience:
The system I wrote at a top-50 web company to do dynamic content generation is written in Java, C, C++, Python, Perl, and sh--and this in a house that uses ASP/VBScript for the web development side of things. It's been running fine for the past 3 years with less than 4 weeks of maintenance/feature-add time allocated to it from the coding side (there were another 5 days of sysadmin time for a server upgrade at one point). Not only have they not had problems with new programmers maintaining it (despite 3 of the 4 programmers who wrote it moving on to new jobs, and the 4th moving into management), it was also delivered on time (meeting an 18-month deadline).
[At last check it's served over 10 billion requests. It's a pretty complex system consisting of 10-15 seperate programs, everything from a GUI interface for the content developers to a publishing system to network server for content delivery to reporting tools and integration with external systems/databases/web servers.]
I would hate to have done most of the data summarization work in Java, or the GUI in C, or the TCP server in Python, or...you get the idea.
I firmly believe that a management decision to use exactly one prescribed language would have made the system take longer to develop and be more costly to maintain.
IOW, Pick the right tool for the job. I've even picked VB as the right tool once recently (mainly because the system in question had some VB hooks in place already and the task at hand was manageable even in a basically crufty language).
Neither Lisp nor ML is a full-out functional language:
You miss the point. Lisp and ML have full-out support for functional programming (unlike, say, Python, which is one of the big arguments against it--don't half-ass it, do it right if you're going to do it.
C++ and Java have sort of halfway-there OO implementations by the classic definition, and Java (forget C++) certainly doesn't have anything an ML (or Haskell) programmer would call "strong typing".
It's not that geeks feel a language should only support one feature/programming model, it's that if you're going to support one it should be done "right" and "with elegance" (which terms have somewhat nebulous definitions).
braino:
If you're going to be dynamically typed, by really dynamic like Scheme and Lisp.
Fine here.
If you're going to be OO, support it fully like Scheme, Python, and Objective C (and geeks tend to support the Scheme-world definition of OO)
Replace "Scheme" with "Smalltalk" here. Ugh, typing too fast.
A lot of geeks give Lisp props, but who actually uses it?
Many people. (More than use Ruby, I would venture to guess, simply because of the widespread presence of emacs.)
Those I mentioned above--ESR, JWZ, Stallman--all have significant projects written in lisp, not just papers on "gee whiz, isn't it cool". Not a lot of it is system software, so it often gets overllooked by the Linux crowd, but check out the lisp repositories at CMU, MIT, and Stanford--since implementations aren't widespread, usage tends to congregate where implementations are in the default setup.
The main problem with Lisp is implementation availability, which is why many people writing lisp apps outside of a controlled environment tend to write them for Emacs. A number of those are fairly widespread. There are some serious CL apps out there (e.g. Allegro FTPd) written in lisp as well, not to mention GnuCash and GIMP and a number of other packages with significant functionality written in scheme. (And heck, you can find 4 or 5 different window managers written in lisp, scheme, or guile on freshmeat.)
(BTW, I'm surprised you hold up Python as an example of OO purity. Perhaps you meant Ruby?)
I'm more surprised you didn't notice my smalltalk->scheme braino.
Most developers I know basically slam it for it's reputation for being slow, and frankly, because it's not C, the geek Gold Standard.
That's not it at all. First off, I'd say Lisp (not C) is the geek Gold Standard--most of your top-name geeks, from Mccarthy on through RMS to Jamie Zawinski and ESR have been LISP hackers, with the notable exception of kernel/systems guys. Even GIMP was written by LISP fans. But C is definitely in the running, primarily because it fits a (rather large) niche very well--it's the closest thing to a portable assembly out there when you need to get down to the nuts and bolts and still be kind of portable.
[Note that I am not supporting any of the following arguments, merely enumerating what I think some of the objections to Java are.]
What Java doesn't do, from a geek standpoint, is fill a niche very well. A true hacker wants a language that is committed; if you're going to be strongly typed, be VERY strongly typed and have a decent type inference mechanism a la Haskell or ML. If you're going to be dynamically typed, by really dynamic like Scheme and Lisp. If you're going to be OO, support it fully like Scheme, Python, and Objective C (and geeks tend to support the Scheme-world definition of OO). And if you're going to be functional, do _that_ full-out like Lisp and ML.
Note that these are all language features. Most geeks want to support a language based on the language itself, not on the libraries or the implementation ("those can be fixed" is the somewhat insightful and somewhat naive argument). As a language, Java isn't anything new and doesn't fit any of those areas as well as other languages.
I think it's almost secondary that Java is a B&D language; it's the failure to be pure about how it implements various programming paradigms and type structures that gives it the geek *yawn*. C++ suffers from the same thing.