And in fact I dont see how they can have both white space multiplication and white space delimiting in function args. IN fact from what i have read there will not be white space delimiting in functions. All the example I saw used commas. So I suspect you are mistaken.
Recent Linpack benchmarks have shown Java can match C/C++ in terms of math performance in many benchmarks. There is no speed disadvantage for this kind of work.
Do we really, really have to go over this well-trodden ground again?
OK, here's the short version:
If you write your Java like C, restricting the functionality you use to almost entirely low-level operations on primitives, then you'll probably get comparable performance, modulo a bit of range-checking on arrays and the like. That's not surprising, and should be true in most programming languages; any language that doesn't ultimately generate basically the same machine code to execute in this case is seriously deficient in performance terms.
Now try writing anything beyond a relatively contrived and self-contained benchmark in Java -- something that uses more involved data types than built-in doubles and arrays where bounds checking can mostly be optimised away, for example -- and see how far you get.
Sorry, JIT really helps and modern Java implementations do have some pretty good optimisations, but the design of Java fundamentally means that it will only ever approach the performance of elementary C or C++ as a limit, and there will always be a certain amount of overhead at some stage in the proceedings. You simply cannot avoid this, while still having the bounds checking, still missing value types, etc.
You could encounter an exceptionally fortunate set of conditions, such that Java has a chance of outperforming C or C++ code. You'd probably need code that ran often enough with similar enough data for dynamic optimisation by the VM to make up for the overhead of monitoring run-time performance in the first place, and then to generate better performing code on that sort of data than C or C++ code run through a good optimiser/profiler combination to produce generic output. Yes, it's theoretically possible. No, I've never, ever seen it.
I find the API for Swing is really cool. Cooler than GTK+, cooler than Qt, cooler than Cocoa, cooler than Windows.
I'm sorry to be the one to tell you this, but you, my friend, are profoundly disturbed. I'm afraid there's nothing for it but psychiatric treatment as an immediate priority, followed by an intensive course in how not to design a library...
Btw, your attempt to divide programming into categories of "serious" and not is laughable.
That claim might be laughable (though I don't think it is; there's a world of difference between how you code a quick and dirty prototype and how you write production code, and only fools allow one to become the other under pressure) but in any case, that's not what I said.
My argument is that programmers working on maths projects tend to prefer programming languages, and that a large part of the reason for this is that most applications aren't purely computational even for scientific and engineering applications. Many other data structures and algorithms can be useful in manipulating your data before you perform whatever calculations you need on it and/or processing the results afterwards. Matlab simply doesn't have what it takes to do this sort of data manipulation, regardless of its mathematical abilities.
FWIW, I don't personally agree with your performance claims, either. IIUC, your argument is basically that any code you don't hand-optimise to use only a subset of the available functionality that is efficient is slow. I'd counter that if you need to understand your implementation that deeply and hand-optimise the code to use an efficient feature set, you've already lost most of the benefits of working with a tool like Matlab and might as well use a real programming language anyway.
However, as I tried to point out before, this whole discussion is comparing apples to oranges anyway. Matlab is a great tool for some jobs in some users' hands, and general programming languages are a different tool that have different advantages for different people. It's not like they're really in competition; they're basically aimed at very different markets, which happen to have some overlap.
Boy it looks like not a single poster actually read the desgin documents. Sheesh... slashdot!
Thanks for the knee jerk, but if you'd read a little further into the discussion, you'd have found that I not only read the material but also submitted an article on this subject several days ago.
In any case, using whitespace for multiplication is all very nice, until you start using it for function calling/composition as well. Then, suddenly, you see f g h 2, and you have no idea what this represents until you know what f, g and h are. That does not improve readability, and it sure as hell isn't going to improve your maintainability and/or bug count.
Please see other people's replies in the discussion for realistic mathematics-based examples where it requires contextual knowledge for a human reader to disambiguate the syntax.
They use a series of identifiers separated by spaces to represent either function calls or multiplication, depending on context. The dependence is relatively subtle, too: uses of () for function calls seem to depend on how many parameters the function takes, for example...
Unlike the April Fool proposal for C++, this is actually, serious BTW.
Based upon my experiences, within universities, ONLY in CS departments Matlab is NOT (yet ?) the de facto standard
I've worked on several mathematical and scientific projects, from high performance libraries to manipulate geometry (applications to CAD/CAM/graphics/etc.) to analysing results from metrology hardware. To date, I've never seen a serious project where the programmers use Matlab; writing custom code in any number of serious programming languages is a better option (mostly because there is more to almost any program than maths, even a mathematical one).
Tools like Matlab are great for working scientists who need to get the job done by don't have access to real programming. For those who do, the latter appears to be a much more popular choice.
Why do pipe stress freaks and crystalography weenies prefer Fortran?
I suspect it's mostly because FORTRAN has a lot of things built right into the language, rather than added in libraries and such. That means code can be reasonably tidy, but still leave a lot of scope for optimisation. This is particularly true when compared with the state of the art in optimising for difficult languages like C, where even today relatively simple optimisations can be difficult because of aliasing issues and the like.
It's also worth noting that when most of a serious community use the same tool(s), a lot of new work will be done using those tools simply because of familiarity, community and support issues.
Hardly. In fact, as I read the introductory sections of the spec, I found a lot of it was exactly the ideas I would have designed into a language myself, as someone who writes mathematical code for a living.
I took a bit of a sideswipe at the whitespace rules in a post below, but aside from those (which I think will die long before the final language is released, "natural" notation or not) a lot of the features look good. Things like first order functions and multiple dispatch suggest much stronger handling of functions than any mainstream language today, which is always good for a language that's going to talk about maths seriously. The consideration given to issues of parallel processing is also well beyond anything else in common usage at present, and that's surely one of the key directions serious programming languages are going to go in over the next decade as hardware becomes more and more about multi-processing rather than just Bigger And Faster(TM).
I must admit, though, that I did start to get bogged down towards the end of the section on the basics, and found it difficult to get stuck into the more advanced stuff at all, even with my CS language theory hat on.
Fortress has a number of interesting features, including support for Unicode characters in code, enabling code to look more like formal mathematical expressions.
Also at least one whitespace rule that will make Python's syntax look uncontroversial.;-)
<Obligatory> Don't you just hate getting a story rejected and then seeing it posted from an AC several days later?:-( </Obligatory>
Unless of course one day someone figures out how to "break" "into" a "computer" and "steal" "data".
And as a second side of the same problem, if anyone does achieve this particular magic trick (not that they could, of course;-)) then lack of a proper paper record will conveniently mean that you have no obvious way of challenging it...
Eivind is definitely on the right side of this argument.
Of course the stock market does some apparently bizarre things, simply due to the complex interactions between those investing in it and the companies they invest in. However, I find it telling that the most successful trader I've ever met worked almost entirely from solid, common sense investments. He didn't go for the big hype (and as a result he didn't lose money during the tech bust a few years back). He did go for solid investments, based on asset values, good P/E, and such metrics, not based on vastly inflated market cap. One of his best investments was the kind of "bad" choice Moraelin's been describing: he found a company whose share value was actually below the value of its assets. He invested a large sum of money, and promptly made a large sum of money when the rest of the market noticed this anomaly and the share price corrected.
This is a guy who has consistently outperformed the market, by upwards of 50% most years, and who has never lost money even in the major tech bust years. That puts him ahead of almost all of the clever private traders, professional fund managers, etc. who go for hype. Go figure.:-)
After an assert()==programmer_error all your preconceptions are invalidated, there is nothing left to rely in your quest for a more effective response.
What a load of rubbish. I might have any number of emergency data saving procedures, diagnostic output routines, other threads running completely unaffected, and more going on elsewhere in my program. The fact that something has triggered an assertion failure means that something has gone wrong, but it doesn't mean that my whole system has suddenly become some unstable nuclear device about to annihilate the world!
I appreciate the point you're getting at, but I wonder whether you're being a little defensive rather than fully considering some alternatives to what you're used to?
For example:
Eventually, a bug pops up with the first change I made. I CANNOT simply ROLLBACK and LOSE all of the other work I did.
Diffing between two historical versions of the code to extract (and potentially undo) only those changes is almost a one-liner with a decent version control system. If that's not sufficient, just having old, commented out code there won't help you either.
I don't understand the big deal of leaving commented-out code in a source base, there really is no better place to put it.
Of course there is: that's what the archive's for. Code in the archive doesn't confuse tools, doesn't increase the time to run your tools over a large code base several-fold, and can't accidentally be uncommented or misinterpreted later on.
Speaking as someone who's also worked on developments of the scale you describe, managed with CVS in the largest case, I've never found leaving commented-out code lying around to be an advantage for anything.
Why do you need to repeat the name of the function? It's right there in the code. IME, this is one of the most common times when comments get out of sync with reality. Duplicating function names, parameter names, etc. adds no value, and can be misleading.
5. Put in a '?' comment for code that you do not understand (good for function headers)
Code with personal annotations should never be released. If you don't understand it, you shouldn't be working with it; go find someone who does understand it instead, or stop and work it out. In any case, the whole project dev team doesn't need to know that someone, somewhere didn't understand something.
8. Tag your bug fixes, code enhancements with a comment followed by a dash, date, and your initials. This is essential for large projects or for anything you will be working on for more than 6 months.
Once again, nothing with personal annotations should ever be released into source control. Not only should I not need to know who wrote or changed a particular snippet of code to fix a bug, I shouldn't even be able to tell by looking at the code. If I can, then whoever wrote it probably didn't fit it into the surrounding code and/or follow coding standards properly.
Obviously, comments that cite a particular bug reference can be useful. Also, you can always look up who changed something and when using source control if you really need to ask them something, and that will get you information guaranteed to be accurate without the need for potentially misleading comments.
But... programmers don't scribble production code into the margins of books.
Ironically, we do quite often scribble over program listings, as we try to convert the "helpful" long variable names used by some "clever" programmer a few years ago into a recognisable form using the same standard and concise notation that everyone else uses. It's amazing how many errors become obvious when you convert the implementation of a well-known equation into a recognisable form on one or two carefully laid out lines of code, rather than either writing a six-line monster full of cumbersome long names, or creating numerous temporary variables that introduce new symbols into the mix.
Mathematicians will spend an inordinate amount of time and space defining what all the compact symbols they use mean. [...] Yes the equations are dense. That's acfter a lot of effort has been put in (usually immediately before, but occasionally immediately after) to carefully explicitly define what the symbols used mean.
Absolutely. And if you're programming maths, then you'd better hope there's some decent reference documentation that does that detailed defintion, because no variable naming scheme is likely to be sufficient in isolation: if a function maintained by several people has 30 different variables being used in complex calculations without that, then it won't matter one iota whether they're called "firstQuantity" and "secondQuantity" or "a" and "b". All you'll get is indecipherable gibberish and a lot of bugs either way. Hence the longer variable names add no value, and just serve to make the code verbose and therefore harder to scan once you have read the docs.
By the way, not aimed at this parent post particularly but just to head off any more knee-jerk responses, I write heavily mathematical code for a living. My work colleagues and I have heavy academic backgrounds, mostly PhDs, and our company has written and maintained well-regarded maths libraries for more than a decade. So, we do know a little about how to code math effectively. If you showed some of the AC replies around the office, you'd have to install sound-proofing to contain the combination of laughter and "Well, duh"s.:-)
Why do we need an intarweb fraud law as well? Especially when it can't possibly be enforced?
The fact that regular laws can't readily be enforced against illegal activity on the Internet is exactly why some basic regulation of the Internet is needed. You just destroyed your own arguments.
I guess it's so they fighters have an inital velocity in the general direction of the enemy, or perhaps the ship designers for the show didn't think about that.
I'm guessing the latter; as you say, if they're thinking deeply enough to launch the fighters from B5 using the rotation, I'm sure they'd also have considered that your fighters probably wouldn't want to be heading directly for your enemy in combat. Maybe they should go watch a few episodes of Andromeda to learn about how tactics in spacefights work?;-)
FWIW, I'm no great fan of ActiveX; I don't miss it at all when I'm browsing with Firefox at home. Unfortunately, I don't get to set the rules used by the office intranet...
Slashdot Mirror
Blockquoth the AC:
Hmm... Section 2.3.6, "Function applications", says (emphasis added):
I'm guessing this is where the example someone mentioned (2 sin x log log x) comes from.
Nah, you just missed the memo. This is 2005, and you can copyright anything. Mwahahahaha!
Do we really, really have to go over this well-trodden ground again?
OK, here's the short version:
If you write your Java like C, restricting the functionality you use to almost entirely low-level operations on primitives, then you'll probably get comparable performance, modulo a bit of range-checking on arrays and the like. That's not surprising, and should be true in most programming languages; any language that doesn't ultimately generate basically the same machine code to execute in this case is seriously deficient in performance terms.
Now try writing anything beyond a relatively contrived and self-contained benchmark in Java -- something that uses more involved data types than built-in doubles and arrays where bounds checking can mostly be optimised away, for example -- and see how far you get.
Sorry, JIT really helps and modern Java implementations do have some pretty good optimisations, but the design of Java fundamentally means that it will only ever approach the performance of elementary C or C++ as a limit, and there will always be a certain amount of overhead at some stage in the proceedings. You simply cannot avoid this, while still having the bounds checking, still missing value types, etc.
You could encounter an exceptionally fortunate set of conditions, such that Java has a chance of outperforming C or C++ code. You'd probably need code that ran often enough with similar enough data for dynamic optimisation by the VM to make up for the overhead of monitoring run-time performance in the first place, and then to generate better performing code on that sort of data than C or C++ code run through a good optimiser/profiler combination to produce generic output. Yes, it's theoretically possible. No, I've never, ever seen it.
I'm sorry to be the one to tell you this, but you, my friend, are profoundly disturbed. I'm afraid there's nothing for it but psychiatric treatment as an immediate priority, followed by an intensive course in how not to design a library...
That claim might be laughable (though I don't think it is; there's a world of difference between how you code a quick and dirty prototype and how you write production code, and only fools allow one to become the other under pressure) but in any case, that's not what I said.
My argument is that programmers working on maths projects tend to prefer programming languages, and that a large part of the reason for this is that most applications aren't purely computational even for scientific and engineering applications. Many other data structures and algorithms can be useful in manipulating your data before you perform whatever calculations you need on it and/or processing the results afterwards. Matlab simply doesn't have what it takes to do this sort of data manipulation, regardless of its mathematical abilities.
FWIW, I don't personally agree with your performance claims, either. IIUC, your argument is basically that any code you don't hand-optimise to use only a subset of the available functionality that is efficient is slow. I'd counter that if you need to understand your implementation that deeply and hand-optimise the code to use an efficient feature set, you've already lost most of the benefits of working with a tool like Matlab and might as well use a real programming language anyway.
However, as I tried to point out before, this whole discussion is comparing apples to oranges anyway. Matlab is a great tool for some jobs in some users' hands, and general programming languages are a different tool that have different advantages for different people. It's not like they're really in competition; they're basically aimed at very different markets, which happen to have some overlap.
Thanks for the knee jerk, but if you'd read a little further into the discussion, you'd have found that I not only read the material but also submitted an article on this subject several days ago.
In any case, using whitespace for multiplication is all very nice, until you start using it for function calling/composition as well. Then, suddenly, you see f g h 2, and you have no idea what this represents until you know what f, g and h are. That does not improve readability, and it sure as hell isn't going to improve your maintainability and/or bug count.
Please see other people's replies in the discussion for realistic mathematics-based examples where it requires contextual knowledge for a human reader to disambiguate the syntax.
No, I'm afraid it's worse than that.
They use a series of identifiers separated by spaces to represent either function calls or multiplication, depending on context. The dependence is relatively subtle, too: uses of () for function calls seem to depend on how many parameters the function takes, for example...
Unlike the April Fool proposal for C++, this is actually, serious BTW.
I've worked on several mathematical and scientific projects, from high performance libraries to manipulate geometry (applications to CAD/CAM/graphics/etc.) to analysing results from metrology hardware. To date, I've never seen a serious project where the programmers use Matlab; writing custom code in any number of serious programming languages is a better option (mostly because there is more to almost any program than maths, even a mathematical one).
Tools like Matlab are great for working scientists who need to get the job done by don't have access to real programming. For those who do, the latter appears to be a much more popular choice.
I suspect it's mostly because FORTRAN has a lot of things built right into the language, rather than added in libraries and such. That means code can be reasonably tidy, but still leave a lot of scope for optimisation. This is particularly true when compared with the state of the art in optimising for difficult languages like C, where even today relatively simple optimisations can be difficult because of aliasing issues and the like.
It's also worth noting that when most of a serious community use the same tool(s), a lot of new work will be done using those tools simply because of familiarity, community and support issues.
Hardly. In fact, as I read the introductory sections of the spec, I found a lot of it was exactly the ideas I would have designed into a language myself, as someone who writes mathematical code for a living.
I took a bit of a sideswipe at the whitespace rules in a post below, but aside from those (which I think will die long before the final language is released, "natural" notation or not) a lot of the features look good. Things like first order functions and multiple dispatch suggest much stronger handling of functions than any mainstream language today, which is always good for a language that's going to talk about maths seriously. The consideration given to issues of parallel processing is also well beyond anything else in common usage at present, and that's surely one of the key directions serious programming languages are going to go in over the next decade as hardware becomes more and more about multi-processing rather than just Bigger And Faster(TM).
I must admit, though, that I did start to get bogged down towards the end of the section on the basics, and found it difficult to get stuck into the more advanced stuff at all, even with my CS language theory hat on.
Also at least one whitespace rule that will make Python's syntax look uncontroversial. ;-)
<Obligatory> Don't you just hate getting a story rejected and then seeing it posted from an AC several days later? :-( </Obligatory>
And as a second side of the same problem, if anyone does achieve this particular magic trick (not that they could, of course ;-)) then lack of a proper paper record will conveniently mean that you have no obvious way of challenging it...
Eivind is definitely on the right side of this argument.
Of course the stock market does some apparently bizarre things, simply due to the complex interactions between those investing in it and the companies they invest in. However, I find it telling that the most successful trader I've ever met worked almost entirely from solid, common sense investments. He didn't go for the big hype (and as a result he didn't lose money during the tech bust a few years back). He did go for solid investments, based on asset values, good P/E, and such metrics, not based on vastly inflated market cap. One of his best investments was the kind of "bad" choice Moraelin's been describing: he found a company whose share value was actually below the value of its assets. He invested a large sum of money, and promptly made a large sum of money when the rest of the market noticed this anomaly and the share price corrected.
This is a guy who has consistently outperformed the market, by upwards of 50% most years, and who has never lost money even in the major tech bust years. That puts him ahead of almost all of the clever private traders, professional fund managers, etc. who go for hype. Go figure. :-)
What a load of rubbish. I might have any number of emergency data saving procedures, diagnostic output routines, other threads running completely unaffected, and more going on elsewhere in my program. The fact that something has triggered an assertion failure means that something has gone wrong, but it doesn't mean that my whole system has suddenly become some unstable nuclear device about to annihilate the world!
Which may still not be the most effective response to the error...
I appreciate the point you're getting at, but I wonder whether you're being a little defensive rather than fully considering some alternatives to what you're used to?
For example:
Diffing between two historical versions of the code to extract (and potentially undo) only those changes is almost a one-liner with a decent version control system. If that's not sufficient, just having old, commented out code there won't help you either.
Of course there is: that's what the archive's for. Code in the archive doesn't confuse tools, doesn't increase the time to run your tools over a large code base several-fold, and can't accidentally be uncommented or misinterpreted later on.
Speaking as someone who's also worked on developments of the scale you describe, managed with CVS in the largest case, I've never found leaving commented-out code lying around to be an advantage for anything.
Blockquoth the AC:
Yes, it will. That's exactly the point.
Some of those are on my top ten don't list.
Why do you need to repeat the name of the function? It's right there in the code. IME, this is one of the most common times when comments get out of sync with reality. Duplicating function names, parameter names, etc. adds no value, and can be misleading.
Code with personal annotations should never be released. If you don't understand it, you shouldn't be working with it; go find someone who does understand it instead, or stop and work it out. In any case, the whole project dev team doesn't need to know that someone, somewhere didn't understand something.
Once again, nothing with personal annotations should ever be released into source control. Not only should I not need to know who wrote or changed a particular snippet of code to fix a bug, I shouldn't even be able to tell by looking at the code. If I can, then whoever wrote it probably didn't fit it into the surrounding code and/or follow coding standards properly.
Obviously, comments that cite a particular bug reference can be useful. Also, you can always look up who changed something and when using source control if you really need to ask them something, and that will get you information guaranteed to be accurate without the need for potentially misleading comments.
Ironically, we do quite often scribble over program listings, as we try to convert the "helpful" long variable names used by some "clever" programmer a few years ago into a recognisable form using the same standard and concise notation that everyone else uses. It's amazing how many errors become obvious when you convert the implementation of a well-known equation into a recognisable form on one or two carefully laid out lines of code, rather than either writing a six-line monster full of cumbersome long names, or creating numerous temporary variables that introduce new symbols into the mix.
Absolutely. And if you're programming maths, then you'd better hope there's some decent reference documentation that does that detailed defintion, because no variable naming scheme is likely to be sufficient in isolation: if a function maintained by several people has 30 different variables being used in complex calculations without that, then it won't matter one iota whether they're called "firstQuantity" and "secondQuantity" or "a" and "b". All you'll get is indecipherable gibberish and a lot of bugs either way. Hence the longer variable names add no value, and just serve to make the code verbose and therefore harder to scan once you have read the docs.
By the way, not aimed at this parent post particularly but just to head off any more knee-jerk responses, I write heavily mathematical code for a living. My work colleagues and I have heavy academic backgrounds, mostly PhDs, and our company has written and maintained well-regarded maths libraries for more than a decade. So, we do know a little about how to code math effectively. If you showed some of the AC replies around the office, you'd have to install sound-proofing to contain the combination of laughter and "Well, duh"s. :-)
I take it you don't write much maths code, then? ;-)
There's a reason mathematicians don't write this:
and they write this instead:
The same reasoning is just as applicable when writing code.
Blockquoth the AC:
That was modded (+1, Funny), but I think it was a serious comment. It wasn't a bad rule of thumb, either.
Blockquoth the AC:
The fact that regular laws can't readily be enforced against illegal activity on the Internet is exactly why some basic regulation of the Internet is needed. You just destroyed your own arguments.
I'm guessing the latter; as you say, if they're thinking deeply enough to launch the fighters from B5 using the rotation, I'm sure they'd also have considered that your fighters probably wouldn't want to be heading directly for your enemy in combat. Maybe they should go watch a few episodes of Andromeda to learn about how tactics in spacefights work? ;-)
FWIW, I'm no great fan of ActiveX; I don't miss it at all when I'm browsing with Firefox at home. Unfortunately, I don't get to set the rules used by the office intranet...
Thanks for the link, BTW.