some of us don't care about all this free/nonfree fight.
then why don't you use windows?
honest question. if you don't care about the one thing that's actually different about free software, why put up with its admittedly inferior hardware support? windows is everywhere, you don't need to be all that smart a shopper to get it on the damn cheap, and there's nothing at all (in your philosophy) worsening its support for new hardware. seriously, what's keeping you from using that over linux?
I see no reason why the drivers cannot be binary just like on Windows
you want windows, you use windows. if i wanted to put up with binary-closed-source proprietary-everything, well, i know where i could get windows, too.
some of us actually don't use free software just because we're cheapskates. some of us actually do care about the freedom part of it all. just sayin'.
why is autoboxing so darn important to some people??
because it makes compilers smarter. that in turn matters because it takes a load off of human optimizers, letting developers use higher-level languages with more impunity because getting decent performance out of them won't be quite so much work any longer.
really, it's about machines learning (being taught to) do things humans get tired and bored doing - about automating more of the development process. that's good.
if i want a hash-table of integers or a binary-tree of doubles, i will write it myself with the native types. it is faster,
if that's actually true, you're either using a really shitty language or you're not very good at using it. higher-level features should be faster and easier to use, read, learn, and maintain; that's their whole point.
and eats less memory.
only if your compiler is too shitty to optimize the higher-level constructs properly. that's what autoboxing (among other things) is meant to fix.
The two button mice are in another section of their store, and must be bought seperately.
Which is to say no one is making you use a one-button mouse.
no, just that apple's forcing me to pay for one, whether i want it or not.
Besides, all Macs ship with a two-button mouse--the second button is on the keyboard
by that standard, why don't you praise apple for shipping with a 101-button mouse by default?
wasn't that long ago i heard some mac fanatic claim the one-button mouse was so that users wouldn't get confused about which mouse button to press. clearly pressing ctrl+mousebutton must not be confusing at all to them, nor can there be anything the least bit unintuitive about combining input actions from two separate devices simultaneously. apple users must be so smart, they don't need to use their brains to use their computers, i take it.
me? all i want is for apple to ship a pointing device with a scroll wheel as standard. i refuse to use one without such a thing; i've become hopelessly addicted. preferably a scroll wheel with side-scrolling tilt ability. why should i pay a dime for a mouse that doesn't have such a basic, essential feature? mice without wheels disappeared from the market (the sensible part of the market) years ago - do let apple know they're behind the times.
Heterosexual couples are necessary for the propogation of the species. Homosexual couples are not.
In other words, parents eventually having to teach their kids about heterosexuality is a requirement. Parents teaching their kids about homosexuality is optional. Not saying that justifies the latter being banned. But an argument based on equality of access to information about the two just doesn't work.
eating is necessary for survival. eating anything but bugs and roots is not. let's cut school cafeterias, the kids can catch worms and dig up tubers on their lunch hours on their own.
the equity of access argument is based on the assumption that homosexuality, just like heterosexuality, is innate in whichever individuals it affects; and that kids are equally entitled to information about their own selves regardless of what they're growing up to become. unless you'd like to dispute either of these two assumptions - and i believe i could make a decent, if very lengthy, defense of either one - it's pretty hard to say it "just doesn't work".
talk to me like i'm stupid - how is your example any different at all from structured exception handling anywhere else? what, in your description, is the "checked" part, and why's it so damn great?
because, in case you weren't aware, even.NET applications can try/catch/throw/finally these days. there's nothing to stop them from logging their errors and continuing on, either.
java is verbose for pretty much anything interesting precisely because of those fancy-ass libraries of its.
because everything requires library calls in java, whether or not that makes sense. want to use a list? use this library. want to use a dictionary? import that library. want to add or delete items from your collection-like data type? do tedious method calls on objects created using those tediously imported libraries.
meanwhile, in sensible languages, i'm trivially iterating over the members returned from the list comprehension i used to eliminate the irrelevant items from my collection. one line, no inherent method calls, perfectly succinct and - in any sensible language - perfectly readable. in java i already gave up long ago, because i had a real problem to solve that didn't involve learning the various APIs of umpteen jillion libraries, no matter how standard. it didn't have to involve butt-ugly syntax using method calls to do what should have been done with operators, either.
creating basic structured data types and assigning them some initial data should be pretty much a one-liner. decent languages have built-in syntax to make this easy, natural, readable and even good-looking. it's a personal litmus test of languages for me; if creating a dictionary and populating it involves jumping through hoops, the language is too low-level and obtuse to bother with.
i've used java. i have also, i will shamefully admit, studied COBOL. it's a toss-up which of the two is more verbose, and if java is any more powerful, it certainly doesn't present its power any more succinctly or aesthetically - java code just seems naturally butt ugly for some weird reason, to an extent that even COBOL doesn't necessarily approach. weird, that last, but true.
It's like when some time ago on this site somebody said Java could be faster than C due to JIT and all that. I replied that no way, Java could never be faster than an optimal implementation in machine code, and C is only a bit above it.
that's correct, but useless. it's useless because, for this to do you any good, you need to have an optimal implementation in machine code at hand. such beasts are very hard to even recognize, never mind write.
your friend was at least potentially right, because JIT compiling (and other recompile-at-runtime schemes) all have access to more info than a static compiler does: the code to be compiled is running, so a lot of knowledge about what it's actually doing right then and how it's been dynamically behaving since started up is at hand. optimizations can be based on this that static compilers can't perform.
consider byte-compiling at runtime from one processor's native machine code to another one's (Crusoe), or -- as a degenerate case -- to the same processor's machine code. HP have done a lot of research on this; their Dynamo project byte-compiles PA8000 code to PA8000 at run-time. the weird thing is that programs so interpreted occasionally run up to 20% faster than "native" machine code... because the system could micro-optimize the running program as it ran, focusing automatically on the pieces that needed optimization the most, and performing optimizations that no static compiler could do at all for lack of knowledge of how the code behaved dynamically.
To this what I say is: If you really needed it, you could use C to write your own bytecode interpreter in it, with its own JIT, that would be faster than Java's because you could make it optimal for your application.
yeah, you could. but Phil Greenspun would just shake his head at hearing of it and, perhaps, mildly pity you for your wasted effort. if you're going to go down that route, at least you could reimplement Common Lisp...
I have always thought that perfect code readability relied on the felxibility to format certain sections of code differently than others
i could've written that, a few years ago before i learned python...
seriously: how much of your code (and i'm talking only about that part of your code which you would consider readable and well-formatted; i'll be generous and ignore any ugly spaghetti code you might have written) is not indented by nesting level? what is it indented by, then?
i thought the whitespace thing would be a huge problem for me when i started learning the language... then after a couple hours, i noticed i was actually programming exactly as i normally would have been, i just left out the braces. the way i formatted my code in practice never needed to change at all.
(i also hate Java, by the way, but that's for other reasons entirely. i do think its syntax suck-starts entire biker gangs' worths of harleys, but even that's only part of it.)
dell's lowest end dimension 2400, and next in line 4600, and next in line, 8400 uses a standard ATX power supply. The only catch is that it has a couple extra pins on the power connector so you are forced to buy it from dell
lemme run this by you again: a "standard ATX power supply" that has a couple extra pins which mean you are forced to buy it from dell is still a "standard" anything because... ?
After all, complexity theory tells us that constant factors and offsets are irrelevant - so shouldn't you be choosing the language that'll make you most productive after, say, 5 years of learning it?
that would have us all coding in Common Lisp, wouldn't it?
Supersonic jets using afterburners use ungodly amounts of fuel.
correct, but the Concorde didn't ordinarily use afterburners; it had them only for the greater thrust demands at take-off and during acceleration, not for cruise. it was an expensive plane to run largely because of its low seating capacity and short range, which barred it from many of the lucrative trans-Pacific routes.
(some have also argued that the low-to-nil bypass ratio of the Concorde's Olympus engines made it more expensive to run. that may be true; i don't have any really convincing evidence either way.)
I've heard the Concorde made slightly less noise than a 747-400 or something like that.
that would have had to depend on what the plane was doing. during landing, i can well believe the difference might have been small; during take-off (under afterburners, natch!) that would very much surprise me; and while supersonic, absolutely not.
Concordes were politically acceptable so long as they stayed subsonic over land, so nobody would complain about the boom. they were also hideously expensive to run, which in a more rational world might have shut them down all by itself, but apparently there were enough eccentric ultra-rich people to keep them flying for decades in spite of that fault. no amount of money, however, would let them reamin at their designed cruise speed above anyplace people lived, and that was as much a political shortcoming as a technical one.
this could make intercontinental travel anything up to twice as fast, through making civilian supersonic jets politically acceptable. the greatest gains would be had in overland transcontinental travel, where no airliner has yet been allowed to remain supersonic because of their booms.
This won't solve anything.
well, if you believe there are no problems hinging on air travel speeds, then maybe it won't. myself, i'm not quite ready to swallow that line.
if you don't want anybody to use a field, you tell everybody that you don't want it fiddled with. that's what underscores do.
if somebody is dead set on fiddling with it any damn way, there's nothing you or the compiler can do to stop them, because humans can be smarter than compilers and stubborner than language designers. it might be the dumbest thing they'll ever do, and it might be shooting themselves in the foot with an anti-aircraft gun, but if they really want to do it - they'll do it. no matter what you do to prevent them.
annotations like the underscore are simultaneously the weakest and the strongest method you can use to keep fields private. weakest, because the computer doesn't even really try to enforce it and a determined user can easily override it; and strongest, because it puts the onus on the humans who use your classes not to be bloody stupid. it brings in the weight of social conditioning and peer pressure within the group of people who use, know, and teach the language, all saying that "touching that field is stupid and bad". if such pressure and such a lesson aren't enough to stop somebody, nothing ever would be.
python's underscores is telling other programmers that they're humans, not machines, so you'll talk to them as people, not computers. it takes protection out of the domain of mechanics and puts it into the domain of sociology. that's a profound move, and the same philosophy underlies python's use of "magic" naming like __dict__ and __cmp__.
sure it can be abused. so can any other damn thing. if somebody does that, they can't really blame you for what happens to them - they were warned, weren't they? do you really think a slightly more severe warning would have stopped them, or even stopped them from blaming you anyway...?
For example, in most languages you compile regular expressions and get back a handle, then you use the handle for searches. But in Perl the compiler takes care of this for you. You don't worry about it. You don't have to import an "re" library either.
that's a bit of a two-edged sword though. the more i work with slicing syntax on strings and splitting/joining/exact-matching on substrings, the more i understand JWZ's old gripe about having a problem, using a regex on it, then finding yourself with two problems.
and perl 6 will give us regexes powerful enough to parse HTML. i am very much of two minds on that one; it could go very horribly indeed, or it might - just might - turn out to be simply a convenient shorthand notation for programming general state machines. that might not be too bad if the syntax doesn't end up too grotty, but i'm not betting on either of those things quite yet...
Then the splash screen would disappear without a trace.
sounds like a feature to me. or did you mean the rest of the application disappeared also?
Re:Not quite, but OpenAFS would be a good option
on
Red Hat announces GFS
·
· Score: 1
AFS is for distributed computing, GFS is for fault-tolerant cluster computing
ah. if you're right about that, then this is probably still not quite what i want.
i've been wanting a distributed, fault-tolerant filesystem to play with for a while now; NFS is getting old and clunky. i want something i can share between several machines, that would keep a local copy on each machine involved, and that could seamlessly tolerate disconnects/reconnects of machines in the cluster. ideally, i'd also like it to do security, authentication and encryption decently.
i haven't found anything. Intermezzo and Coda seem to come closest, but they're both more research project than solid product. OpenAFS seems stuck in the same niche, and all three of them are almost-but-not-quite POSIX compliant. (i'm not really sure if non-POSIX semantics would be a problem or not, but i'm a pessimist; i'd like to take on as few problems at a time as i can.)
GFS seems to hold a lot of promise, and its Sistina heritage is a good sign, but if it can't (easily) replicate files across a network for me, then it's not quite what i'm looking for. ah well, maybe that Unison thingy i heard about can be a poor man's substitute...
We don't want to buy an $18,000 car that can only drive 40 miles. That's ludicruous. What if there's an accident and you get stuck in a traffic jam for an hour with a quickly exhausting battery?
i agree that a 40-mile range is ridiculously underspecced, but... how do you plan on exhausting the battery if you're stuck in traffic and not moving?
what i wanna know about an electric car is, (1) how well does it heat up in a Michigan winter (and will i exhaust the battery doing that), and (2) how does the AC perform in a summer heat wave, and would that suck my battery empty. it's worries like these that have me ogling more in the gas-electric hybrid direction, myself.
No country we are fighting these days, or are likely to fight in the forseeable future, can hope to hurt a battleship
i wouldn't be so sure about that. the big gunboats were designed to stand up to the equivalent of their own weapons; artillery shells of a couple metric tons apiece, loaded with (oh, i dunno, at a wild guess) maybe a couple hundred kilograms of explosive charge each, coming in ballistically and relatively slowly, without active guidance.
the problem is, there are three major threats to surface vessels today, and none of them look like a big-gun barrage. surface-to-surface missiles come in at supersonic speeds, skimming the sea, and carrying much larger warheads than any arty shell would, with excellent guidance and accuracy - plus they can much more easily use shaped charges.
aerial attack is similar except usually from a higher angle; aerial bombs come in slower than missiles or shells, but again carry more explosives, and are also usually more accurate than arty. (well, okay, the U.S. navy doesn't have to worry about this one, but still.)
torpedoes are still slow (well, except for the supercavitating ones, but there's only one of those in service and the russkis aren't much up to attacking anybody anytime soon). however, they have evolved better guidance, better independent target-seeking, and better warheads than their ancient WW2 predecessors - which were already enough to sink a gunboat, with a couple good hits and some luck. good submarines are expensive, but the smaller littoral subs are plenty effective enough, and have seen at least some proliferation - maybe not to the miserable third-world ends of the earth the U.S. is likely to be attacking, but you never know.
yeah, if you're shooting artillery shells at your opponent's water line, a battlewagon is the thing to have. but modern-day navies, armies, air forces and submariners don't play that game any longer. a big sea-going artillery platform might still be nice to have for supporting amphibious operations and coastal assaults, just as the B-52 is still a very handy bomber even though its original nuclear mission is long obsolete. but it wouldn't necessarily have to be a WW2-era battleship just to lob shells towards land. they might well be just the wrong thing for that use, even, for reasons that might be as simple as economics. how many crewmembers did you need to run one of those things, again...?
we're talking about performance, yes, and you bring up one particular language implementation in support of your point. it's true i'm not familiar with it, and so can't say that its particulars are performance relevant; but by the same token, i have no reason to believe that the conclusions you're drawing from the performance of this one implementation are a good example of some general rule about all dynamic languages.
your reference (1) doesn't resolve. reference (2) doesn't seem to discuss dynamic languages specifically; it either talks about the overhead of Python's OO system, or about some implementation overhead incurred by Python's regexp module in storing some intermediate results, as far as i can tell. i'm not sure how relevant that is to language dynamism, but it does imply that interpreter overhead can go as high as 30-40 percent; if this is true, it would mesh nicely with my contention that compiling a language makes more of an immediate difference than static typing. reference (3) goes to an admittedly very interesting paper that flat-out states Python is slow because of its dynamism, but then goes on to describing the author's own hobby project. the paper doesn't really support this blatant assertion much; it makes it a bit more detailed, the author lays out a few of the reasons he believes the assertion to be true, but he only lists these, with no supporting evidence. that's okay, the paper isn't about supporting this claim, but by that measure, you can't very well use it to support that claim then.
i'll check back on the first reference in a day or two in the hopes the server comes back online. thanks for the two i could get at; particularly the Salib paper is fascinating, this is teaching me quite a lot.
not according to the language overview i found on its website it isn't. it's a compiler for something quite a bit like Python, but - again, according to the website - it's meant for doing something different from what Python is meant to do.
don't get me wrong; Pyrex looks like a very interesting project, and i'm glad you pointed me to it (i really hadn't known it existed), but a Python compiler it ain't. Psyco comes much closer to being a Python compiler, but still falls short.
if this is really "very well studied", as you claim, how about just dropping me a few references to the studies? that'd be more convincing, and might actually teach me something.
python and lisp are too different beasts to even compare them,
the original claim was that dynamic typing made programs slow. lisp is dynamic yet not particularly slow. i wasn't arguing for python as such; it's a nice language, but it is slow - i just don't believe that it's necessarily its dynamic typing that makes it so.
Slashdot Mirror
i bet you wonder why people think mac fanatics are weird, too, don't you?
honest question. if you don't care about the one thing that's actually different about free software, why put up with its admittedly inferior hardware support? windows is everywhere, you don't need to be all that smart a shopper to get it on the damn cheap, and there's nothing at all (in your philosophy) worsening its support for new hardware. seriously, what's keeping you from using that over linux?
some of us actually don't use free software just because we're cheapskates. some of us actually do care about the freedom part of it all. just sayin'.
really, it's about machines learning (being taught to) do things humans get tired and bored doing - about automating more of the development process. that's good.
if that's actually true, you're either using a really shitty language or you're not very good at using it. higher-level features should be faster and easier to use, read, learn, and maintain; that's their whole point. only if your compiler is too shitty to optimize the higher-level constructs properly. that's what autoboxing (among other things) is meant to fix.wasn't that long ago i heard some mac fanatic claim the one-button mouse was so that users wouldn't get confused about which mouse button to press. clearly pressing ctrl+mousebutton must not be confusing at all to them, nor can there be anything the least bit unintuitive about combining input actions from two separate devices simultaneously. apple users must be so smart, they don't need to use their brains to use their computers, i take it.
me? all i want is for apple to ship a pointing device with a scroll wheel as standard. i refuse to use one without such a thing; i've become hopelessly addicted. preferably a scroll wheel with side-scrolling tilt ability. why should i pay a dime for a mouse that doesn't have such a basic, essential feature? mice without wheels disappeared from the market (the sensible part of the market) years ago - do let apple know they're behind the times.
the equity of access argument is based on the assumption that homosexuality, just like heterosexuality, is innate in whichever individuals it affects; and that kids are equally entitled to information about their own selves regardless of what they're growing up to become. unless you'd like to dispute either of these two assumptions - and i believe i could make a decent, if very lengthy, defense of either one - it's pretty hard to say it "just doesn't work".
because, in case you weren't aware, even .NET applications can try/catch/throw/finally these days. there's nothing to stop them from logging their errors and continuing on, either.
because everything requires library calls in java, whether or not that makes sense. want to use a list? use this library. want to use a dictionary? import that library. want to add or delete items from your collection-like data type? do tedious method calls on objects created using those tediously imported libraries.
meanwhile, in sensible languages, i'm trivially iterating over the members returned from the list comprehension i used to eliminate the irrelevant items from my collection. one line, no inherent method calls, perfectly succinct and - in any sensible language - perfectly readable. in java i already gave up long ago, because i had a real problem to solve that didn't involve learning the various APIs of umpteen jillion libraries, no matter how standard. it didn't have to involve butt-ugly syntax using method calls to do what should have been done with operators, either.
creating basic structured data types and assigning them some initial data should be pretty much a one-liner. decent languages have built-in syntax to make this easy, natural, readable and even good-looking. it's a personal litmus test of languages for me; if creating a dictionary and populating it involves jumping through hoops, the language is too low-level and obtuse to bother with.
i've used java. i have also, i will shamefully admit, studied COBOL. it's a toss-up which of the two is more verbose, and if java is any more powerful, it certainly doesn't present its power any more succinctly or aesthetically - java code just seems naturally butt ugly for some weird reason, to an extent that even COBOL doesn't necessarily approach. weird, that last, but true.
that's correct, but useless. it's useless because, for this to do you any good, you need to have an optimal implementation in machine code at hand. such beasts are very hard to even recognize, never mind write.
your friend was at least potentially right, because JIT compiling (and other recompile-at-runtime schemes) all have access to more info than a static compiler does: the code to be compiled is running, so a lot of knowledge about what it's actually doing right then and how it's been dynamically behaving since started up is at hand. optimizations can be based on this that static compilers can't perform.
consider byte-compiling at runtime from one processor's native machine code to another one's (Crusoe), or -- as a degenerate case -- to the same processor's machine code. HP have done a lot of research on this; their Dynamo project byte-compiles PA8000 code to PA8000 at run-time. the weird thing is that programs so interpreted occasionally run up to 20% faster than "native" machine code... because the system could micro-optimize the running program as it ran, focusing automatically on the pieces that needed optimization the most, and performing optimizations that no static compiler could do at all for lack of knowledge of how the code behaved dynamically.
yeah, you could. but Phil Greenspun would just shake his head at hearing of it and, perhaps, mildly pity you for your wasted effort. if you're going to go down that route, at least you could reimplement Common Lisp...
i could've written that, a few years ago before i learned python...
seriously: how much of your code (and i'm talking only about that part of your code which you would consider readable and well-formatted; i'll be generous and ignore any ugly spaghetti code you might have written) is not indented by nesting level? what is it indented by, then?
i thought the whitespace thing would be a huge problem for me when i started learning the language... then after a couple hours, i noticed i was actually programming exactly as i normally would have been, i just left out the braces. the way i formatted my code in practice never needed to change at all.
(i also hate Java, by the way, but that's for other reasons entirely. i do think its syntax suck-starts entire biker gangs' worths of harleys, but even that's only part of it.)
lemme run this by you again: a "standard ATX power supply" that has a couple extra pins which mean you are forced to buy it from dell is still a "standard" anything because ... ?
that would have us all coding in Common Lisp, wouldn't it?
correct, but the Concorde didn't ordinarily use afterburners; it had them only for the greater thrust demands at take-off and during acceleration, not for cruise. it was an expensive plane to run largely because of its low seating capacity and short range, which barred it from many of the lucrative trans-Pacific routes.
(some have also argued that the low-to-nil bypass ratio of the Concorde's Olympus engines made it more expensive to run. that may be true; i don't have any really convincing evidence either way.)
that would have had to depend on what the plane was doing. during landing, i can well believe the difference might have been small; during take-off (under afterburners, natch!) that would very much surprise me; and while supersonic, absolutely not.
Concordes were politically acceptable so long as they stayed subsonic over land, so nobody would complain about the boom. they were also hideously expensive to run, which in a more rational world might have shut them down all by itself, but apparently there were enough eccentric ultra-rich people to keep them flying for decades in spite of that fault. no amount of money, however, would let them reamin at their designed cruise speed above anyplace people lived, and that was as much a political shortcoming as a technical one.
this could make intercontinental travel anything up to twice as fast, through making civilian supersonic jets politically acceptable. the greatest gains would be had in overland transcontinental travel, where no airliner has yet been allowed to remain supersonic because of their booms.
well, if you believe there are no problems hinging on air travel speeds, then maybe it won't. myself, i'm not quite ready to swallow that line.
if somebody is dead set on fiddling with it any damn way, there's nothing you or the compiler can do to stop them, because humans can be smarter than compilers and stubborner than language designers. it might be the dumbest thing they'll ever do, and it might be shooting themselves in the foot with an anti-aircraft gun, but if they really want to do it - they'll do it. no matter what you do to prevent them.
annotations like the underscore are simultaneously the weakest and the strongest method you can use to keep fields private. weakest, because the computer doesn't even really try to enforce it and a determined user can easily override it; and strongest, because it puts the onus on the humans who use your classes not to be bloody stupid. it brings in the weight of social conditioning and peer pressure within the group of people who use, know, and teach the language, all saying that "touching that field is stupid and bad". if such pressure and such a lesson aren't enough to stop somebody, nothing ever would be.
python's underscores is telling other programmers that they're humans, not machines, so you'll talk to them as people, not computers. it takes protection out of the domain of mechanics and puts it into the domain of sociology. that's a profound move, and the same philosophy underlies python's use of "magic" naming like __dict__ and __cmp__.
sure it can be abused. so can any other damn thing. if somebody does that, they can't really blame you for what happens to them - they were warned, weren't they? do you really think a slightly more severe warning would have stopped them, or even stopped them from blaming you anyway...?
that's a bit of a two-edged sword though. the more i work with slicing syntax on strings and splitting/joining/exact-matching on substrings, the more i understand JWZ's old gripe about having a problem, using a regex on it, then finding yourself with two problems.
and perl 6 will give us regexes powerful enough to parse HTML. i am very much of two minds on that one; it could go very horribly indeed, or it might - just might - turn out to be simply a convenient shorthand notation for programming general state machines. that might not be too bad if the syntax doesn't end up too grotty, but i'm not betting on either of those things quite yet...
sounds like a feature to me. or did you mean the rest of the application disappeared also?
ah. if you're right about that, then this is probably still not quite what i want.
i've been wanting a distributed, fault-tolerant filesystem to play with for a while now; NFS is getting old and clunky. i want something i can share between several machines, that would keep a local copy on each machine involved, and that could seamlessly tolerate disconnects/reconnects of machines in the cluster. ideally, i'd also like it to do security, authentication and encryption decently.
i haven't found anything. Intermezzo and Coda seem to come closest, but they're both more research project than solid product. OpenAFS seems stuck in the same niche, and all three of them are almost-but-not-quite POSIX compliant. (i'm not really sure if non-POSIX semantics would be a problem or not, but i'm a pessimist; i'd like to take on as few problems at a time as i can.)
GFS seems to hold a lot of promise, and its Sistina heritage is a good sign, but if it can't (easily) replicate files across a network for me, then it's not quite what i'm looking for. ah well, maybe that Unison thingy i heard about can be a poor man's substitute...
i agree that a 40-mile range is ridiculously underspecced, but... how do you plan on exhausting the battery if you're stuck in traffic and not moving?
what i wanna know about an electric car is, (1) how well does it heat up in a Michigan winter (and will i exhaust the battery doing that), and (2) how does the AC perform in a summer heat wave, and would that suck my battery empty. it's worries like these that have me ogling more in the gas-electric hybrid direction, myself.
being able to survive AP hits would be neat, but why would anybody even be firing incendiary shells at a tank in the first place...?
i wouldn't be so sure about that. the big gunboats were designed to stand up to the equivalent of their own weapons; artillery shells of a couple metric tons apiece, loaded with (oh, i dunno, at a wild guess) maybe a couple hundred kilograms of explosive charge each, coming in ballistically and relatively slowly, without active guidance.
the problem is, there are three major threats to surface vessels today, and none of them look like a big-gun barrage. surface-to-surface missiles come in at supersonic speeds, skimming the sea, and carrying much larger warheads than any arty shell would, with excellent guidance and accuracy - plus they can much more easily use shaped charges.
aerial attack is similar except usually from a higher angle; aerial bombs come in slower than missiles or shells, but again carry more explosives, and are also usually more accurate than arty. (well, okay, the U.S. navy doesn't have to worry about this one, but still.)
torpedoes are still slow (well, except for the supercavitating ones, but there's only one of those in service and the russkis aren't much up to attacking anybody anytime soon). however, they have evolved better guidance, better independent target-seeking, and better warheads than their ancient WW2 predecessors - which were already enough to sink a gunboat, with a couple good hits and some luck. good submarines are expensive, but the smaller littoral subs are plenty effective enough, and have seen at least some proliferation - maybe not to the miserable third-world ends of the earth the U.S. is likely to be attacking, but you never know.
yeah, if you're shooting artillery shells at your opponent's water line, a battlewagon is the thing to have. but modern-day navies, armies, air forces and submariners don't play that game any longer. a big sea-going artillery platform might still be nice to have for supporting amphibious operations and coastal assaults, just as the B-52 is still a very handy bomber even though its original nuclear mission is long obsolete. but it wouldn't necessarily have to be a WW2-era battleship just to lob shells towards land. they might well be just the wrong thing for that use, even, for reasons that might be as simple as economics. how many crewmembers did you need to run one of those things, again...?
your reference (1) doesn't resolve. reference (2) doesn't seem to discuss dynamic languages specifically; it either talks about the overhead of Python's OO system, or about some implementation overhead incurred by Python's regexp module in storing some intermediate results, as far as i can tell. i'm not sure how relevant that is to language dynamism, but it does imply that interpreter overhead can go as high as 30-40 percent; if this is true, it would mesh nicely with my contention that compiling a language makes more of an immediate difference than static typing. reference (3) goes to an admittedly very interesting paper that flat-out states Python is slow because of its dynamism, but then goes on to describing the author's own hobby project. the paper doesn't really support this blatant assertion much; it makes it a bit more detailed, the author lays out a few of the reasons he believes the assertion to be true, but he only lists these, with no supporting evidence. that's okay, the paper isn't about supporting this claim, but by that measure, you can't very well use it to support that claim then.
i'll check back on the first reference in a day or two in the hopes the server comes back online. thanks for the two i could get at; particularly the Salib paper is fascinating, this is teaching me quite a lot.
not according to the language overview i found on its website it isn't. it's a compiler for something quite a bit like Python, but - again, according to the website - it's meant for doing something different from what Python is meant to do.
don't get me wrong; Pyrex looks like a very interesting project, and i'm glad you pointed me to it (i really hadn't known it existed), but a Python compiler it ain't. Psyco comes much closer to being a Python compiler, but still falls short.
if this is really "very well studied", as you claim, how about just dropping me a few references to the studies? that'd be more convincing, and might actually teach me something.
the original claim was that dynamic typing made programs slow. lisp is dynamic yet not particularly slow. i wasn't arguing for python as such; it's a nice language, but it is slow - i just don't believe that it's necessarily its dynamic typing that makes it so.