Can you show a real example instead of timing the amount of nanoseconds it takes to add two numbers together?
Well, with some basic benchmarks Ruby is indeed slower than javascript, though it uses massively less memory. Compared to Perl it does very well in one test, but is notably slower for everything else. Compared to Python it is occasionally slightly better in terms of memory, but consistently significantly slower. Compared to Psyco Python it simply gets its ass handed to it.
None of which says that Ruby is a bad language, nor inappropriate for the uses you are putting it to. It does say that it is quantatively slower than many of the alternatives that the OP mentioned.
The problem in Canada is that, despite having a reasonable array of parties, you're still stuck with the archaic First Past the Post voting system which sees the two major parties (the Liberals and the Conservatives), and especially Bloc Quebecois, win far more seats in parliament than is realistic given the amount of support they have. Once you get a decent system like MMP, giving the smaller parties (and the NDP) like the Greens more representative political clout things will seriously improve.
Taco is accepting designs that use other colours. I quite like this design in blue by Lukasz Lukasiewicz. Taco just favour thins that have more links with the original design, and thus better continuity for Slashdot in general.
3. What version of Nautilus do you use? I use 2.10 and when I rightclick on a bunch of selected items, the selection doesn't disappear AND the Copy item is enabled. This has been the case since Nautilus 2.0.
4. What are you talking about? It works fine here.
I did some experimenting and it seems that his problem is that he's extremely inaccurate with his mouse. If you select a group of files and then right click on some other file not in the selected group then it cancels the selection, selects the file you right clicked on, and brings up the appropriate menu. Similarly, if you right click on the background of the window paste indeed does work fine. If, for some reason you manage to hold your mouse over an icon instead then yes naturally it selects that file and brings up the right click menu for it which doesn't have a paste option. In other words, if you wave your mouse wildly while right clicking then yes, you can experience the described behaviour.
That Emacs is a huge memory hog is somewhat overrated, and based on days of yore when computing resources were a lot tighter: both Kate and Gedit use more resources than Emacs, let alone something like Eclipse. I agree if all you're doing is simple editing of lots of little text files which requires no signficant extra functionality then vim would probably be good, but so would joe or nano for that matter.
You do know that Emacs is at version 1.21.4. They stopped using the major version number because it hasn't changed in the last couple of decades...
I had heard they dropped the major version number, but I always presumed it was 0.21.4, with the expectation that Emacs would finally hit 1.0.0 once it was feature complete.
Jedidiah.
Re:slightly different paradigm
on
Vim 7 Released
·
· Score: 3, Interesting
I have _never_ met an emacs user that knew how to use it. Its sad.
That's sad, because someone who truly knows how to get the most out of Emacs can be very impressive. Most of the people I know don't really know how to use vi. Sure they can do i for insert, and dd for delete line and so forth, but they hardly use the full feature set. Of course I have witnessed a few people who really know how to use vi, and that is something to behold. A real Emacs user is no different. Just because you haven't met one doesn't mean they don't exist (I've met many myself).
Jedidiah.
Re:Ahhhhh....
on
Vim 7 Released
·
· Score: 2, Interesting
This feature (ctrl-n auto-complete)...You press ctrl-x ctrl-o to invoke it.
Now forgive my ignorance because I'm not a Vim user, but I thought (and what I keep hearing) is that vim is supposed to be better than emacs because it doesn't use complicated multi-key shortcuts using the control key etc. What happened? At this rate why not just use emacs with gnuclient (for fast access) and viper mode (for your basic vi keybindings)?
Jedidiah.
Re:slightly different paradigm
on
Vim 7 Released
·
· Score: 1
Which is why I switched from emacs. Ever tried coding in emacs with a broken wrist? It's hard enough with two functional hands.
I broke my thumb (my whole hand was swollen and immobile) and had to work in Emacs. 10 minutes after arriving at work I had successfully rebound the keymap (doing so one handed, changing keybindings as they came up) so that I could operate it efficiently one handed. I'm not sure how easy that would be with vim (not being a vi person), but the ability to quickly dynamically rebind any keys I needed as I went certainly made things easy in Emacs.
As much of a silly storm in a teacup as this is...
Apple is not trying to delete the thread, just remove an image from one of their service manuals. How is posting sections of a service manual fair use?
According to the definition of fair use in US law it potentially falls under fair use if it is "for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research", with a certain amount of fuzziness regarding the actual details with regard the purpose and character of the use, the amount excerpted, the impact on the potential market for the copyrighted work etc.
Now, in this case we have approximately a third of a page excerpted, most of which is an image, so it wuold seem to be a legitimately small excerpt. The excerpt was very clearly being used for criticism and comment - read the actual post. I don't see it as at all likely that having this small third of a page excerpt available on some forum online having any significant impact on sales of Apple repair manuals. It seems that this very much falls almost directly into the category of fair use. I think, really, the burden of proof is for you to explain exactly why this isn't an example of fair use.
Time couldn't have had a beginning, by its very nature. So of course there was stuff happening before the Big Bang... a chain of Big Bangs is what I always assumed happened, or if not that, at least something.
It works something like this: according to relativity, space and time are really linked together as 4 dimensional spacetime. Just as 2- and 3-dimensional objects can have shape, so can 4-dimensional objects like spacetime. When physicists try and get some idea of the shape of spacetime they find that it "narrows to a point in the time direction" - the big bang.
Perhaps an analogy is the best way to think about it. A sphere is a two dimensional surface in a particular shape - at any point of the surface of the sphere you can parameterise direction in terms of 2 perpendicular base vectors. We do exactly that with directions about the surface of the earth (though we call "negative east" west, and "negative north" south), so if you like you can think of north and east as the dimensions/directions on the surface of the earth. If you keep heading north, however, you find that the sphere narrows to a point in that directions - the north pole. You can't really talk about what is north of the north pole - the question doesn't really make sense. Of course you can only really see that by stepping outside and observing the 2-dimensional surface of the earth as it is embedded into 3-dimensional space; if we look at things in terms of a more easy to picture map projection into 2-dimensions (just as the surface is 2-dimensional) you might think "can't we just keep going up? Surely there's more north?"
In practice spacetime works roughly the same way except the "surface" is 4-dimensional instead of 2-dimensional. The key point is that heading back in the time direction is just like heading in the north direction of the sphere - eventually you reach a point, like the north pole, where "before" or "further back in time" doesn't make sense, in just the same way that "further north of the north pole" doesn't make sense. From our perspective inside spacetime that's harder to imagine, similar to the way the map projection tends to skew your thinking. It is made worse by the fact that we usually tend to think of time as something very separate to space rather than just another direction. The concept of time beginning with the big bang does make sense, it just requires you to break out of the standard intuitions about how space and time fit together.
There really needn't be any clash between proper requirements specification and agile methods. As you point out, a lot of the time agile development offers a productive way to explore and refine a set of requirements. And providing you have a decent means for properly (hopefully formally) expressing requirements it shouldn't be too much effort to use an agile process to start with a very loose high level set of requirements and refine it into something detailed. Simply having requirements and checking against them (potentially using theorem provers if you have suitable tool support) during agile development can help elucidate how requirements need to be refined by helping to highlight unanticipated corner cases or inaccessible functionality. In many ways formal requirements specification with static checking via theorem proving goes hand in hand with agile development and the usual unit testing. It's an extra power tool for your toolbox.
I never said proving theorems about your code was easy, and I agree, for a lot of projects it isn't going to be the cost effective way of doing things. On the other hand there is a reasonable amount of middle ground, and increasing tool support for actually doing some degree of theorem proving. ESC/Java2 is a great example of this - it's not about completely proving your code correct, its about using extra specification to run a theorem prover over parts of your code and provide warnings about all the possible corner cases and implicit assumptions made - essentially it is just extremely powerful static checking, made all the stronger by actually using a theorem prover. Certainly that level of checking is reasonably cost effective for any Java solution where bugs are going to be costly (like security or financial software), and because of the way it works it can scale down to projects where assurance isn't that important: putting less explicit annotations in simply means the static checking provides less assurance, but it still does a good job... and running ESC/Java2 over your code generally takes no longer than compiling it, so it can definitely be worth doing.
I've worked in industry as a mathematician. When we say we're going to prove something we actually prove it, rather than just tossing out a few random examples for demonstration. Given that a piece of software is, at its heart, just a lot of mathematics, and the fact that it really is possible to prove things about code in the real sense of the word, I would be very careful about saying you "prove" your software works.
Also, back on topic, try writing financial software some time. It's like a different world. Everything is unit tested, and the unit tests don't so much check for bugs as prove that your code works.
Unit tests don't prove your code works any more than drawing a few right angled triangles and measuring the sides proves Pythagoras' theorem. If you want to prove your ode works you use a theorem prover. To do tht you usually need to provide more detailed specification (beyond just type signatures) about how your code is intended to function. That tends to be more work, though if you really need to know your code is going to work it can often save time in the long run (over ridculously long and exhaustive testing). There are things out there that provide toold support for theorem proving aout your code: SPARK Ada along with the SPARK tools provides a powerful theorem prover, and HasCASL with CASL tools (including the HOL theorem prover) provides string theorem proving for Haskell. Even ESC/Java2 utilises a theorem prover (called Simplify) to provide extended static checking of Java code. I'm sure there are more examples.
My point is not that Unit testing is bad (it's very good), but that you shouldn't overstate its effectiveness. Unit tests are a great way to provide a reasonable degree of assurance that your code will hopefully ork as intended. It isn't a substitute for actual assurance however. It really depends on exactly how sure you need to be - how much an error will cost, and whether that can be tolerated.
If you want a truly powerful Java static analysis tool consider ESC/Java2 which includes not just the usual extra static checking you would expect, but also includes a theorem prover which can provide warnings for all kinds of deep and subtle errors. Read through this presentation (warning PDF) to get an idea of exactly how many things ESC/Java2 can catch, including warnings about race conditions and deadlocks. If you want powerful statsic analysis of Java code ESC/Java2 is definitely the way to go.
People from New Zealand and Australia have much further to travel than people from the US, particularly if they want to see Europe. Yet oddly enough you'll find Aussies and Kiwis in surprisingly high numbers travelling all over the place. Often the travel is done when they have just finished high school or university while still poor, so obviously money isn't the obstacle. The real answer, a far as I can tell, is that it is a significant cultural difference: in general US people are far more insular, nationalistic, and (willfully) ignorant of the world, and as such they are far less interested in seeing any of it.
Maybe I'm getting this the wrong way, but if the object "absorbs" the light coming to it through the lens, wouldn't that object be perceived as black?
No more so than your blindspots are perceived as black. Your brain simply isn't getting any visual information from that area so you don't perceive anything in particlar about it and it would appear "normal" with no percieved difference to any other area.
There are people who, after strokes or other brain damage, have part of their visual perception destroyed - they end up with, effectively, huge blindspots, potentally half their field of vision of more. They don't percieve this spot, about which their brain is not getting any information, as black, they simply don't perceive any particualar information about it at all. The brain just makes up the best story about what it is "seeing" given the available information, just as it does with the normal blindspots you or I have.
For the purposes of human perception it would indeed work as invisibility. What something like a camera would make of it, on the other hand, would be quite different (indeed, a camera would perceive it as a white/black/undeveloped spot). Thus it would not be all that hard to circumvent the invisibility I imagine.
This makes unfamiliar code easier to read. I've done Delphi/C/C++/perl/PHP programming, and none of them have as easy to read code as Java. I value that a lot.
Try Ada or Eiffel if you want code that's easy to read and maintain. The langauges have downsides in that they aren't as flexible as things like Perl or Python (there often is only one way to do it), but then that pays back in terms of readability - no bizarre little idiomatic tricks, or idiosyncratic code from a 1337 coder trying to show off how compactly he can write straighforward things. Honestly, if you value readability, take the time to look at either or both seriously. You might be surprised.
So Java gets features essentially as soon as C++ has made all the mistakes related to those features.
The depressing part is that there are languages like Eiffel that had multiple inheritance, generics, and more, for a long time, and they were done better way back then than Java's implementation now (honestly, compare generics in Java to how Eiffel handles such things, or look at how clean and simple multiple inheritance can be when done right). And then there are all those extra features that Eiffel picked up over time like agents (first class functions and closures) that fit very naturally into the language but Java is yet to pick up. The latest thing I ran into was concurrency in Eiffel which is achieved by adding a single keyword and instantly provides incredibly natural concurrency that integrates perfectly with the language and is remarkably easy to reason about.
Sure you can compare Java to C++ and say they are learning from the mistakes that C++ makes. On the other hand you could compare yourself to a well designed and language that has a knack of adding features that seem perfectly natural and work well right from the outset and find that Java looks a lot like C++ in comparison.
who'd install `real crap` on their unix machine anyway ?
Given the quality of RealPlayer for Linux (basically just HelixPlayer packaged with proprietary codecs) I certainly would. I seen the Windows RealPlayer, so I certainly understand your reservations... but HelixPlayer and RealPlayer are remarkably simple clean multimedia players. Well worth the effort.
It kills me how on the one hand you guys got absolutely nuts about web standards, document standards, etc. -- "just code to the standard and it'll magically work!" is the mantra around here. But as soon someone says that the Linux desktop or Linux distributions need to standardize on this or that the tired old "but that would stifle choice!" line gets trotted out.
Oh I'm all for standards for Linux, it's just that, given the development model, its going to have to be standards for protocols, communication, etc. and not standards for implementation. Have a look at Freedesktop.org standards, or LSB, or Portland from OSDL, ar even things like Tango icon themes - they all make sense because they sketch how interaction should work, without prescribing too many details of how to implement it. What you are asking for is standards in the sense of "there shall be only one toolkit used, and all implementation must follow these strict rules". If we were to apply that sort of standardisation ot the internet then rather than having standards for HTML and CSS and leavinbg it up to the browser makers to decide how to implement them we'd have one mandated browser and all other browser development would be barred.
Standards are nice. Let's use them - where they make sense. If you want truly rigid standards then there are perfectly good options for you: OS X for example. Trying to enforce the same top down control over the open source development world is like herding cats - it just won't work. So if you don't like OS X then take your lumps because OS X is what Jobs has mandated it to be and if you don't like that tough. If you do like OS X... then why are you complaining, you already have what you want?
Having 921034 options to choose from is sometimes a good thing, but sometimes you have the feeling: why don't they just work all on 1 fantastic piece of software?
Because the worlds open source developers are not a giant slave pool designed to do your bidding.
Open source will always be chaotic and involve a great deal of duplication because that's that nature of the beast. The gain you get from that cost is much more open software that's developed rapidly and tends to work as a free market for ideas: the better ideas eventually win out (though that may take some time). If you want something different then you want Apple or Micrsoft with their rigid top down control structure which ensures that everyone is working toward a single unified goal (as much as is possible), and all the work is directed. The upside is consistency and a unified vision, but the downside is that the whole thing is more locked up, an often slower development cycle, and a tendency to get hit with the same stupid mistakes release after release after release just because it appeals to the guy at the top.
It's a choice and you can pick the software ecology that suits your needs. Just don't go expecting one to behave like the other on your whim - there are deep fundamental philosophical divisions about how to develop software (to let it evolve from the bottom up, or direct it from the top down) that are largely irreconcilable.
Slashdot Mirror
Can you show a real example instead of timing the amount of nanoseconds it takes to add two numbers together?
Well, with some basic benchmarks Ruby is indeed slower than javascript, though it uses massively less memory. Compared to Perl it does very well in one test, but is notably slower for everything else. Compared to Python it is occasionally slightly better in terms of memory, but consistently significantly slower. Compared to Psyco Python it simply gets its ass handed to it.
None of which says that Ruby is a bad language, nor inappropriate for the uses you are putting it to. It does say that it is quantatively slower than many of the alternatives that the OP mentioned.
Jedidiah.
The problem in Canada is that, despite having a reasonable array of parties, you're still stuck with the archaic First Past the Post voting system which sees the two major parties (the Liberals and the Conservatives), and especially Bloc Quebecois, win far more seats in parliament than is realistic given the amount of support they have. Once you get a decent system like MMP, giving the smaller parties (and the NDP) like the Greens more representative political clout things will seriously improve.
Jedidiah.
Taco is accepting designs that use other colours. I quite like this design in blue by Lukasz Lukasiewicz. Taco just favour thins that have more links with the original design, and thus better continuity for Slashdot in general.
Jedidiah.
3. What version of Nautilus do you use? I use 2.10 and when I rightclick on a bunch of selected items, the selection doesn't disappear AND the Copy item is enabled. This has been the case since Nautilus 2.0.
4. What are you talking about? It works fine here.
I did some experimenting and it seems that his problem is that he's extremely inaccurate with his mouse. If you select a group of files and then right click on some other file not in the selected group then it cancels the selection, selects the file you right clicked on, and brings up the appropriate menu. Similarly, if you right click on the background of the window paste indeed does work fine. If, for some reason you manage to hold your mouse over an icon instead then yes naturally it selects that file and brings up the right click menu for it which doesn't have a paste option. In other words, if you wave your mouse wildly while right clicking then yes, you can experience the described behaviour.
Jedidiah.
That Emacs is a huge memory hog is somewhat overrated, and based on days of yore when computing resources were a lot tighter: both Kate and Gedit use more resources than Emacs, let alone something like Eclipse. I agree if all you're doing is simple editing of lots of little text files which requires no signficant extra functionality then vim would probably be good, but so would joe or nano for that matter.
You do know that Emacs is at version 1.21.4. They stopped using the major version number because it hasn't changed in the last couple of decades...
I had heard they dropped the major version number, but I always presumed it was 0.21.4, with the expectation that Emacs would finally hit 1.0.0 once it was feature complete.
Jedidiah.
I have _never_ met an emacs user that knew how to use it. Its sad.
That's sad, because someone who truly knows how to get the most out of Emacs can be very impressive. Most of the people I know don't really know how to use vi. Sure they can do i for insert, and dd for delete line and so forth, but they hardly use the full feature set. Of course I have witnessed a few people who really know how to use vi, and that is something to behold. A real Emacs user is no different. Just because you haven't met one doesn't mean they don't exist (I've met many myself).
Jedidiah.
This feature (ctrl-n auto-complete)...You press ctrl-x ctrl-o to invoke it.
Now forgive my ignorance because I'm not a Vim user, but I thought (and what I keep hearing) is that vim is supposed to be better than emacs because it doesn't use complicated multi-key shortcuts using the control key etc. What happened? At this rate why not just use emacs with gnuclient (for fast access) and viper mode (for your basic vi keybindings)?
Jedidiah.
Which is why I switched from emacs. Ever tried coding in emacs with a broken wrist? It's hard enough with two functional hands.
I broke my thumb (my whole hand was swollen and immobile) and had to work in Emacs. 10 minutes after arriving at work I had successfully rebound the keymap (doing so one handed, changing keybindings as they came up) so that I could operate it efficiently one handed. I'm not sure how easy that would be with vim (not being a vi person), but the ability to quickly dynamically rebind any keys I needed as I went certainly made things easy in Emacs.
Jedidiah.
As much of a silly storm in a teacup as this is...
Apple is not trying to delete the thread, just remove an image from one of their service manuals. How is posting sections of a service manual fair use?
According to the definition of fair use in US law it potentially falls under fair use if it is "for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research", with a certain amount of fuzziness regarding the actual details with regard the purpose and character of the use, the amount excerpted, the impact on the potential market for the copyrighted work etc.
Now, in this case we have approximately a third of a page excerpted, most of which is an image, so it wuold seem to be a legitimately small excerpt. The excerpt was very clearly being used for criticism and comment - read the actual post. I don't see it as at all likely that having this small third of a page excerpt available on some forum online having any significant impact on sales of Apple repair manuals. It seems that this very much falls almost directly into the category of fair use. I think, really, the burden of proof is for you to explain exactly why this isn't an example of fair use.
Jedidiah.
Time couldn't have had a beginning, by its very nature. So of course there was stuff happening before the Big Bang... a chain of Big Bangs is what I always assumed happened, or if not that, at least something.
It works something like this: according to relativity, space and time are really linked together as 4 dimensional spacetime. Just as 2- and 3-dimensional objects can have shape, so can 4-dimensional objects like spacetime. When physicists try and get some idea of the shape of spacetime they find that it "narrows to a point in the time direction" - the big bang.
Perhaps an analogy is the best way to think about it. A sphere is a two dimensional surface in a particular shape - at any point of the surface of the sphere you can parameterise direction in terms of 2 perpendicular base vectors. We do exactly that with directions about the surface of the earth (though we call "negative east" west, and "negative north" south), so if you like you can think of north and east as the dimensions/directions on the surface of the earth. If you keep heading north, however, you find that the sphere narrows to a point in that directions - the north pole. You can't really talk about what is north of the north pole - the question doesn't really make sense. Of course you can only really see that by stepping outside and observing the 2-dimensional surface of the earth as it is embedded into 3-dimensional space; if we look at things in terms of a more easy to picture map projection into 2-dimensions (just as the surface is 2-dimensional) you might think "can't we just keep going up? Surely there's more north?"
In practice spacetime works roughly the same way except the "surface" is 4-dimensional instead of 2-dimensional. The key point is that heading back in the time direction is just like heading in the north direction of the sphere - eventually you reach a point, like the north pole, where "before" or "further back in time" doesn't make sense, in just the same way that "further north of the north pole" doesn't make sense. From our perspective inside spacetime that's harder to imagine, similar to the way the map projection tends to skew your thinking. It is made worse by the fact that we usually tend to think of time as something very separate to space rather than just another direction. The concept of time beginning with the big bang does make sense, it just requires you to break out of the standard intuitions about how space and time fit together.
Jedidiah.
There really needn't be any clash between proper requirements specification and agile methods. As you point out, a lot of the time agile development offers a productive way to explore and refine a set of requirements. And providing you have a decent means for properly (hopefully formally) expressing requirements it shouldn't be too much effort to use an agile process to start with a very loose high level set of requirements and refine it into something detailed. Simply having requirements and checking against them (potentially using theorem provers if you have suitable tool support) during agile development can help elucidate how requirements need to be refined by helping to highlight unanticipated corner cases or inaccessible functionality. In many ways formal requirements specification with static checking via theorem proving goes hand in hand with agile development and the usual unit testing. It's an extra power tool for your toolbox.
Jedidiah.
http://us2.metamath.org:8888/mpegif/mmset.html
What really makes it troubling for software is this: What is the "average out of court settlement" per discovered bug in a piece of software?
Jedidiah.
I never said proving theorems about your code was easy, and I agree, for a lot of projects it isn't going to be the cost effective way of doing things. On the other hand there is a reasonable amount of middle ground, and increasing tool support for actually doing some degree of theorem proving. ESC/Java2 is a great example of this - it's not about completely proving your code correct, its about using extra specification to run a theorem prover over parts of your code and provide warnings about all the possible corner cases and implicit assumptions made - essentially it is just extremely powerful static checking, made all the stronger by actually using a theorem prover. Certainly that level of checking is reasonably cost effective for any Java solution where bugs are going to be costly (like security or financial software), and because of the way it works it can scale down to projects where assurance isn't that important: putting less explicit annotations in simply means the static checking provides less assurance, but it still does a good job... and running ESC/Java2 over your code generally takes no longer than compiling it, so it can definitely be worth doing.
Jedidiah.
I've worked in industry as a mathematician. When we say we're going to prove something we actually prove it, rather than just tossing out a few random examples for demonstration. Given that a piece of software is, at its heart, just a lot of mathematics, and the fact that it really is possible to prove things about code in the real sense of the word, I would be very careful about saying you "prove" your software works.
Jedidiah.
Also, back on topic, try writing financial software some time. It's like a different world. Everything is unit tested, and the unit tests don't so much check for bugs as prove that your code works.
Unit tests don't prove your code works any more than drawing a few right angled triangles and measuring the sides proves Pythagoras' theorem. If you want to prove your ode works you use a theorem prover. To do tht you usually need to provide more detailed specification (beyond just type signatures) about how your code is intended to function. That tends to be more work, though if you really need to know your code is going to work it can often save time in the long run (over ridculously long and exhaustive testing). There are things out there that provide toold support for theorem proving aout your code: SPARK Ada along with the SPARK tools provides a powerful theorem prover, and HasCASL with CASL tools (including the HOL theorem prover) provides string theorem proving for Haskell. Even ESC/Java2 utilises a theorem prover (called Simplify) to provide extended static checking of Java code. I'm sure there are more examples.
My point is not that Unit testing is bad (it's very good), but that you shouldn't overstate its effectiveness. Unit tests are a great way to provide a reasonable degree of assurance that your code will hopefully ork as intended. It isn't a substitute for actual assurance however. It really depends on exactly how sure you need to be - how much an error will cost, and whether that can be tolerated.
Jedidiah,
If you want a truly powerful Java static analysis tool consider ESC/Java2 which includes not just the usual extra static checking you would expect, but also includes a theorem prover which can provide warnings for all kinds of deep and subtle errors. Read through this presentation (warning PDF) to get an idea of exactly how many things ESC/Java2 can catch, including warnings about race conditions and deadlocks. If you want powerful statsic analysis of Java code ESC/Java2 is definitely the way to go.
Jedidiah.
People from New Zealand and Australia have much further to travel than people from the US, particularly if they want to see Europe. Yet oddly enough you'll find Aussies and Kiwis in surprisingly high numbers travelling all over the place. Often the travel is done when they have just finished high school or university while still poor, so obviously money isn't the obstacle. The real answer, a far as I can tell, is that it is a significant cultural difference: in general US people are far more insular, nationalistic, and (willfully) ignorant of the world, and as such they are far less interested in seeing any of it.
Jedidiah.
Maybe I'm getting this the wrong way, but if the object "absorbs" the light coming to it through the lens, wouldn't that object be perceived as black?
No more so than your blindspots are perceived as black. Your brain simply isn't getting any visual information from that area so you don't perceive anything in particlar about it and it would appear "normal" with no percieved difference to any other area.
There are people who, after strokes or other brain damage, have part of their visual perception destroyed - they end up with, effectively, huge blindspots, potentally half their field of vision of more. They don't percieve this spot, about which their brain is not getting any information, as black, they simply don't perceive any particualar information about it at all. The brain just makes up the best story about what it is "seeing" given the available information, just as it does with the normal blindspots you or I have.
For the purposes of human perception it would indeed work as invisibility. What something like a camera would make of it, on the other hand, would be quite different (indeed, a camera would perceive it as a white/black/undeveloped spot). Thus it would not be all that hard to circumvent the invisibility I imagine.
Jedidiah.
This makes unfamiliar code easier to read. I've done Delphi/C/C++/perl/PHP programming, and none of them have as easy to read code as Java. I value that a lot.
Try Ada or Eiffel if you want code that's easy to read and maintain. The langauges have downsides in that they aren't as flexible as things like Perl or Python (there often is only one way to do it), but then that pays back in terms of readability - no bizarre little idiomatic tricks, or idiosyncratic code from a 1337 coder trying to show off how compactly he can write straighforward things. Honestly, if you value readability, take the time to look at either or both seriously. You might be surprised.
Jedidiah.
So Java gets features essentially as soon as C++ has made all the mistakes related to those features.
The depressing part is that there are languages like Eiffel that had multiple inheritance, generics, and more, for a long time, and they were done better way back then than Java's implementation now (honestly, compare generics in Java to how Eiffel handles such things, or look at how clean and simple multiple inheritance can be when done right). And then there are all those extra features that Eiffel picked up over time like agents (first class functions and closures) that fit very naturally into the language but Java is yet to pick up. The latest thing I ran into was concurrency in Eiffel which is achieved by adding a single keyword and instantly provides incredibly natural concurrency that integrates perfectly with the language and is remarkably easy to reason about.
Sure you can compare Java to C++ and say they are learning from the mistakes that C++ makes. On the other hand you could compare yourself to a well designed and language that has a knack of adding features that seem perfectly natural and work well right from the outset and find that Java looks a lot like C++ in comparison.
Jedidiah.
who'd install `real crap` on their unix machine anyway ?
Given the quality of RealPlayer for Linux (basically just HelixPlayer packaged with proprietary codecs) I certainly would. I seen the Windows RealPlayer, so I certainly understand your reservations... but HelixPlayer and RealPlayer are remarkably simple clean multimedia players. Well worth the effort.
Jedidiah.
It kills me how on the one hand you guys got absolutely nuts about web standards, document standards, etc. -- "just code to the standard and it'll magically work!" is the mantra around here. But as soon someone says that the Linux desktop or Linux distributions need to standardize on this or that the tired old "but that would stifle choice!" line gets trotted out.
... then why are you complaining, you already have what you want?
Oh I'm all for standards for Linux, it's just that, given the development model, its going to have to be standards for protocols, communication, etc. and not standards for implementation. Have a look at Freedesktop.org standards, or LSB, or Portland from OSDL, ar even things like Tango icon themes - they all make sense because they sketch how interaction should work, without prescribing too many details of how to implement it. What you are asking for is standards in the sense of "there shall be only one toolkit used, and all implementation must follow these strict rules". If we were to apply that sort of standardisation ot the internet then rather than having standards for HTML and CSS and leavinbg it up to the browser makers to decide how to implement them we'd have one mandated browser and all other browser development would be barred.
Standards are nice. Let's use them - where they make sense. If you want truly rigid standards then there are perfectly good options for you: OS X for example. Trying to enforce the same top down control over the open source development world is like herding cats - it just won't work. So if you don't like OS X then take your lumps because OS X is what Jobs has mandated it to be and if you don't like that tough. If you do like OS X
Jedidiah.
Having 921034 options to choose from is sometimes a good thing, but sometimes you have the feeling: why don't they just work all on 1 fantastic piece of software?
Because the worlds open source developers are not a giant slave pool designed to do your bidding.
Open source will always be chaotic and involve a great deal of duplication because that's that nature of the beast. The gain you get from that cost is much more open software that's developed rapidly and tends to work as a free market for ideas: the better ideas eventually win out (though that may take some time). If you want something different then you want Apple or Micrsoft with their rigid top down control structure which ensures that everyone is working toward a single unified goal (as much as is possible), and all the work is directed. The upside is consistency and a unified vision, but the downside is that the whole thing is more locked up, an often slower development cycle, and a tendency to get hit with the same stupid mistakes release after release after release just because it appeals to the guy at the top.
It's a choice and you can pick the software ecology that suits your needs. Just don't go expecting one to behave like the other on your whim - there are deep fundamental philosophical divisions about how to develop software (to let it evolve from the bottom up, or direct it from the top down) that are largely irreconcilable.
Jedidiah.