All you then need to use OO.o for is presentation (which can kind of be hacked inelegantly with Inkscape and Evince), which makes it a lot less painful, especially if you rarely need to do a presentation.
My preferred approach for presentations is to use Inkscape to make templates, and then just write the presentation in LaTeX. I understand that this doesn't suit everyone, but it is surprisingly easy to generate good looking PDF presentations efficiently this way. Better than Inkscape alone - at least until it gets multi-page support.
As a Republican, I'm far more interested in keeping government as small as possible...
As a Republican supporter you are far more interested in keeping the government as small as possible. As an actual elected Republican I think it's been pretty clearly demonstrated that you really wouldn't give a crap about the size of government, and would be happy to grow it if it suits your needs. This gaping difference between rhetoric used to rally support and actual actions taken is, of course, hardly a Republican only thing. The Democrats are just as keen to fly the "social justice" flag, and rally support from people who are ardently in favour of that, yet seem to have little or no real interest in that issue (besides some token gestures - as the Republicans occasionally do with "small government") once elected. What this really means is that Republican supporters don't really have that much to fear from Democrats - they aren't going to grow the government any more than Republicans actually will. Likewise Democrat supporters don't really have too much to fear from Republicans, they aren't going to ignore social justice issues any more than the Democrats actually will. Still, it's important to at least have some rhetorical differences to keep the supporters revved up and deathly afraid of the distaster that, in theory, would befall the country should "the other party" get elected.
Indeed, further to the point of the relative hospitableness of the areas of Greenland settled by the Norse, it seems Google maps and satellite photos can come to out aid. Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
Hmmmm. Just thinking about it, I would guess that the snow and ice has probably preserved that era quit nicely. This may be an excellent opportunity to study our relatives. I would guess that we will find a few icemen (and women) if we watch carefully.
Unforunately no, the Norse settlements were never under ice (snow in the winters at times, but not under ice). The particular areas settled were in fjords where there was no ice, indeed the area was actually quite green. Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
So Greenland used to be green. Then it froze. Now it's turning green again. It's almost like it's a natural cycle.
Greenland used to be covered in ice with a few small areas in fjords that were habitable. What evidence we have of the Norse settlements (and there is a reasonable amount) shows that they were a farily marginal colony. For instance their cows were the smallest known, due to such a short period when they could be outside in pasture. There is evidence that while kept inside barns in the winter they had to be forcefed kelp to help fatten them up/keep them alive. Doesn't sound like a lush paradise.
And on the other hand, its not as if today the Norse settlements are just starting to melt out from under the ice. The areas of Greenland that were settled by the Norse are and have been since they were rediscovered) quite green and habitable. Try looking at photos of the ruins: Hvalsey ruins, another shot of Hvalsey, ruins at Gardar, another shot of the Gardar ruins, ruins at Brattahlid, a general shot (I can't identify the location), and to round things out, a couple shots of modern day Greenlandin summer. Things have looked that way for a while - the ice was always inland from these fjords. It didn't take anything special for the Norse to be able to settle there - just a little determination to survive the winters.
My point in comparing Fortress to Eiffel was pointing out that Fortress may be closer to Eiffel than to Fortran, and the press release from Sun mentions Fortran alone.
And I think that's reasonable, given that the role that Fortress is intended to play is far more important (especially given that it is a niche role) than what Fortresses ancestor languages are. It owes as much to Scala (at least it looks that way - I have no idea whether Scala was actually an influence) as it does to Eiffel. What counts is what it is intended to be used for - which is scientific computing and HPC where parallelisation counts: that is to say the niche currently filled by Fortran.
I do hope Sun finds a way to keep the GUI/OS-interaction code in some other language (Java is reasonable), making it possible to build applications from Fortress and non-Fortress parts. Treating mouse and other UI events with that math notation won't be fun, even for the most devout Mathematician.
I honestly have no idea what you mean here. I expect GUI/OS-interaction code would most likely look an awful lot like Scala, which is hardly a problem. The math formatting onlycomes in when actually doing mathematics. The rest of the time it's essentially just an OO language like any other, and won't look any different to any other language. Treating UI events will be straightforward.
I didn't see in the specs (I skimmed through it quickly, could be my fault) how Fortress is meant to parallelize computations more efficiently. From all I saw, I assume each method runs atomically in a single thread and parallelization of methods is be based on the contracts.
There are a number of things that Fortress does to make parallelisation work. For instance for loops are parallel by default, as are vector operations. Try looking at the "atomic" keyword to see more on how control of serial and parallel operation is handled. If you want easy parallelisation via each method working in a separate thread and contracts determining wait conditions then look at Eiffel and SCOOP: it introduces a single new keyword (separate) and allows you to do just that.
I am a Perl programmer, and I don't think Perl is that unreadable. In fact, I agree with most of its design. I am happy that now we can point the finger at something else when someone complains about "weird syntax" and "too many operators".
I think what you need to consider is how many operator symbols are defined by default in Fortress: it actually isn't that many. Fortress simply supports unicode and the ability to define new operators using classical math symbols - it doesn't have them all defined in the base language. Almost everything is farmed out to libraries. You may think it looks ugly and complicated compared to Perl but I (who have done a fair bit of Perl programming, and have spent time looking at Fortress as it developed) think you're being premature. See it in action or actually try using it yourself and I think you'll quickly find it is, in fact, a lot more readable than Perl.
Because as programmers, we'd rather not have what essentially is a whole new edit-compile-debug cycle just to type the damn code. IDEs are great, and they vastly improve productivity, but they start to hurt productivity if they are required to do something with your code.
I was rather expecting the IDE to render it on the fly as you enter it, which, really, makes it no harder to deal with that mistyping a variable name (easier, in fact, given that if mistyped it won't render to the appropriate symbol). You can even expect automatic completion of symbols if you want. I would also expect a simple view toggle to let you see and edit the raw ASCII if that's what floats your boat.
It seems that the only Fortran-esque side of Fortress is that it is aimed at scientific computing and number-crunching.
Which is to say, its aimed at the niche that Fortran, despite how old and creaky it is, still rules. The world of programming has come a long way since Fortran, but nothing matches it for scientific computing and number crunching. To be honest that's about the only aspect of Fortran worth keeping...
Other than that, the programming paradigm of Fortress is based on object orientation and programming-by-contract. If Java smelled like Smalltalk, Fortress smells like Eiffel.
You say that like it's a bad thing! Eiffel is, surprisingly enough, a very nice language to work in. I'd be very happy with a language targetted toward numerics (And with real math style notation to boot!) that was as pleasant to work with as Eiffel. Design by contract is a good thing, and importantly it is optional. You can specify a contract or property for a function, but you don't have to. The ability to flesh out an API with contracts and properties is a damn good thing - something far too many languages lack.
means that people will write more to achieve the same thing with some guarantee of correctness.
Contracts and properties are optional. If you don't want correctness guarantees then don't use them. On the other hand if you would like a little more insurance... well then they're very useful indeed.
means that Sun bothered to include kelvin, Pascal, meter, second, Newton and every Physical unit you can think of as language keywords, that all parameters should specify what unit they're in, and that the language will do some effort to prevent errors arising from adding oranges and bananas, or precision errors from summing milligrams to some hundreds of kilograms.
Again, specification of units is optional. If you don't want to worry about units then don't use them. Then again if you're writing some physics code then having the sanity check of unit analysis to make sure everything is working properly is a damn useful thing to have available. Having dimensions and units as not more onerous than having types - it is simply another level of checking available; the benefit here is that the units are optional: if you don't want the extra checks, don't use them.
means that Fortress will make Perl look readable. Good part of the language specification deals on how the editor should render the source code onscreen. The logical AND operator is the upward-pointing wedge symbol of math. The logical OR operator is the downward-poiting wedge symbol. The Integer type is that special-font Z, and a real is that special-font R. The specification deals on how to represent these in an ASCII file, using a meta-language similar to TeX (but incompatible with).
Well that depends on who you are really: Fortress looks incredibly readable to me. Then again I am a mathematician and look at math, formatted in exactly that way, all the time. If you spend all day looking at Java and C code then sure, it's going to look unfamiliar to you. Then again, you probably aren't in the target market for a language aimed specifically at scientific computing. To me a lot of C looks awful and can be hard to read because of its requirement that you pound everything into basic ASCII. It really all depends on what you're used to. As to how easy it is to enter - sure it would be nice if it was straight TeX - but then it is so similar that there is really no problem learning it. If you actually do a lot of math then you can name all those symbols straight away, and what you have to type in to get the symbol is simply it's name. Again, not ideal for people who don't do a lot of math, but then that isn't the target audience. If you do much math then the symbols look right instead of being the ugly ASCII kluges of other languages, and
I'm not sure that's a good idea, either, since reals and floats are different things. Reals have infinite precision, whereas precision is finite for floats.
In Fortress the basic types ZZ and RR provide arbitrary preceision integers and floats. If you want a specfied precision then you need, say, ZZ32 or RR64 etc. So in fact it is the correct notation.
Yes, that's what I imagined it would be like. I also imagine actually _typing_ something that looks a lot more like regular program code, so that you still have to learn an alternative to math notation.
Yes, but it is well documented and, if you are at all familiar with mathematics, straightforward to learn (indeed, you almost don't need to learn - instinctually typing in whatever you would say works for most symbols. It is no harder to learn than TeX - easier if you already know TeX in fact.
Also, the result will look like what one would see printed in a math textbook, as you said which is (1) not what the programmer typed, and (2) horribly obfuscated to me (which is a personal thing, but applies to many people).
Sure, it applies to many people. None of them are in the target market for Fortess though. Fortress is aimed at mathematicians and scientists - the sort of people who are still using Fortran - and for them the math notation makes the whole thing much, much easier to read. It all depends on what you're used to. If you're a programmer who reads C and Java all day then that probably looks good to you. If you spend much of your time reading math papers, however, then mathematical syntax looks far more natural the the elaborate and obfuscated look of C. Congratulations, you're not the target market for the language - that doesn't mean it isn't a great idea that will be of great value to many other people.
And most keyboards will pitifully fail to type, in any straightforward and reliable way.
They did think of that you know. They provide ASCII equivalents, akin to TeX, that let you type stuff in, and then it gets rendered to the appropriate symbol.
Programming should be based on mathematics, not written in it -- and that's from someone who writes specialist mathematical libraries for a living. Seriously, if TeX is the least friendly programming environment I have ever encountered in serious use, and the average programming font has trouble distinguishing (, Well that's really up to the IDE, and to be honest entering mathematics in TeX is straightforward if you have much practice with it at all. As a mathematician who needs to do programming this language looks fantastic. It isn't a language designed for general purpose programming, it's a language designed for mathematicians and scientists to code high performance software with. I expect most people in the target demographic (you, apparently, are an exception) would welcome decent mathematical typesetting when coding, especially if it is similar to TeX. As to the display issue - surely that's a matter for the IDE rendering the code. Presumably it isn't that hard to provide something that actually displays things properly (just include appropriate fonts in the package).
I am wondering, as a college student who is beginning to get into a financial profession typically dealing with immense datasets, how much value will this be to scientists/mathematicians/statisticians? Wouldn't it make more sense to prototype something in Maple, PERL, etc... and hand it off to programmers to implement a full model at top speed?
The aim is that mathematicians can simply write it in Fortress and get a full model at top speed. Fortress is designed to be able top do high performance computing. For loops are inherently parallel and so are array operations etc. Try actually skimming through bthe spec to see what it is and what it can do - it looks like a fantastic language to me (real math notation, design by contract, traits and properties, type inference etc.)
So they're going to include, what, a LaTeX implementation so programmers can make their symbols look right? In a sense, yes. The real question, however, is why this wasn't done earlier? Sure we have to type in code in ASCII because we're stuck with keyboards to enter it with, but that doesn't mean the default view has to be ASCII. Really, why not let your IDE render it into proper mathematical symbols for you? As a mathematician it looks damn appealing to me.
I heard his talk at OOPSLA 2006 on the language design decisions they made for Fortress, and although my Fortran (and math) experience is too shallow to fully appreciate it, I found it fascinating nonetheless.
I lack the fortran experience (I've only done the bare minimum of fortran programming), but I do have the math, and from my perspective, having read through the fortress spec (PDF) (okay, I skimmed it - it's huge) it looks like an excellent language for any mathematics intensive work (and indeed physics too, with its support for dimension and unit annotations). There's a great deal to like about the language. I hope it is successful.
Personally, I find functional notation and names much easier to understand than mathematical notation and symbols. Of course, I'm not a mathematician, so I guess I'm not the target audience for this project. However, I still think this is a really bad idea.
I think that depends on what you mean by mathematical notation and symbols. In the case of Fortress that means Unicode input and the ability to actually render code, thus x^2 gets rendered with a proper superscript 2, array indexes a[i] get rendered to appropriate subscripts, and you have access to other nice symbols - for instance the floating point type is denoted by a blackboard bold R (as in the usual symbol mathematicians use to denote the reals) which you can enter as RR in ascii. The result is that you can enter mathematics via the keyboard and have it rendered in code with captial sigma for sums, standard arrows and cartesian product symbols to denote function signatures, actual square root symbols etc. Think of it as enriching the symbols available to be closer to the full set symbols mathematicians expect: it doesn't result in the horribly obfuscated look of APL, but is more akin to what one would see printed in a math textbook. Read through section 2.4 of the spec (PDF) to get the idea.
I would suggest it is worth the time to have a look at the Fortress spec - it actually looks like a very interesting language, and is actually a worthy fortran replacement. Of course being worthy and actually managing to overcome the inertia and actually replace fortran is another thing. Still, I would gladly use Fortress.
On the contrary, string theory is very interesting, and has a great deal of interesting things to say. The issue is more that it is mathematics not physics. There is, of course, nothing wrong with mathematics for its own sake. Indeed, many physics theories were preceeded by the development of purely mathematical work - where would general relativity be without Riemann's work on manifolds for instance? In many ways string theory could be classified in a similar sort of category - it is a lot of very interesting mathematics that could, one day, be applied to the development of a physical theory. The dilemma comes when people act as if it is physics instead of mathematics.
Am I the only one who is hearing the same 4 chords and the same basic beat? What exactly was stolen? Everyone was playing the same god-damn chords and the beat for the last 20 years.
I must admit I was a little curious after watching the Youtube version - but then the sound quality on that is so poor anyway. Going to the forum and listening to original mp3s it becomes a little more clear - what you should be listening for is in the background of the Furtado song; if you listen you can actually hear precisely the original.mod track; it's quiet, and they've layers extra drums and vocals on top, but if you listen for it it is pretty clear.
It's simply a matter of being used to it. Having grown up in a country that used nothing but celsius I really have no problems determing the temperature outside - the units really aren't that "big" and work just fine if you're used to it.
If you really want a good TV show about "major war", get the networks to reboot Space: Above and Beyond.
Good to see someone else remembers that show. It started so poorly (the pilot was cheese plus), but it ended so well. I'd be very happy to see a decently done reboot of Space Above and Beyond, especially now that the BSG reboot (which drew heavily on SAaB) has given extra credibility to more dark gritty SF. The only other SF TV series I'd ever want to see rebooted is Blake's 7. I guess, in some ways, you could almost claim that Firefly was almost that - still, Blake's 7 with production values would be interesting to see.
Retraining costs only apply if your staff are trained in the first place. In the world where *everyone* puts "Office expert" on their CV almost no one is trained
Heh, I don't. I can get by with office applications but I can only barely use a spreadsheet - I'm a mathematician so computers I work on tend to come equipped with rather more interesting power toys for any calculation/plotting needs and I simply never learned how to use spreadsheets. Likewise, due to my profession, I tended to use LaTeX for documents. Sure, I can bash out a letter or a simple document in a word processor, but anything fancy like tables, headers and footers and the like are things I would have to look up, or muddle through - I honestly don't know. Luckily for me, however, office application skills aren't that highly prized in the sorts of jobs I apply for. I do sometimes wonder how much of an odd one out I am though - I mean, am I alone in having "basic competence" in office apps, or is it common and everyone else just lies?
It would be interesting, then, to see a comparison of training costs between switching to an OSS solution and upgrading to Vista and Office 2007. Certainly a pure OSS solution is going to require more training because there are more changes involved, and some of the differences are significant. Still given the easier incremental transitions you're likely to get on the OSS upgrade treadmill (which tends to have more regular, smaller, upgrades) compared to MS, you might be able to claim an offset in future training costs. At the very least it would be interesting to see how such costs stack up in a variety of cases. If training to the only really significant cost for OSS then this next upgrade round from MS might see a few more companies deciding to do an OSS roll out when they finally get around to upgrading.
Does some CEO grabbing obscene bonuses (deserved or not) fuel social unrest? Historically, the answer is yes, but only if the bulk of the population is suffering. Then such things become flashpoints, ie "let them eat cake". However, that is not really the case for the bulk of the US population.
I think the point of the article is that, aside from a downtrodden populace, a populace that feels disenfranchised can be just as likely to turn to desperation. In terms of perception wealth turns out to be a relative thing (as noted in the article): if you're surrounded by people who have a lot more than you, and constantly presented with images of people who are better off than you, then, regardless of how well off you might actually be, you feel poor. More importantly when you feel there is a disconnect between you and those around you who re much wealthier - that's when problems start to occur. Capitalism works by providing the promise that even if you are poor now you could rise up to be sucessful and wealthy. It placates the losers with the potential and hope that they can become winners. If they lose that hope, if the potential no longer seems to exist, they start to get unruly. And that's where income inequality starts to come in - if it gets wide enough then the disparity becomes so great that people simply cannot imagine how to get from where they are to there. Crossing the gap starts to become inconceivable for some. At that point they become rather more desperate, and that can, indeed, fuel social unrest. That's the concern.
If you're not good enough to sanitize, error check, bounds check, mem check, fault check, and whatever the hell else could go wrong, you have no business coding.
I think the point is that we're all human and we all make occasional mistakes even with the best of intentions. There's plenty of code out there written by very experienced C programmers that still has buffer overflows and other glitches. That means that having a language that has the facility to make such errors easier to catch and correct early is a good thing. That means that having a language that pushes you toward secure practice by not having sloppy easy ways to do things is a good. Yes, we could all, in theory, write perfectly secure error free code in C or PHP or whatever, but in practice we don't - no one does. Languages that encourage best practice by default and provide the tools to catch errors earlier (with, say, design by contract) are a good thing if security is important. We're all human, and can use all the help we can get.
Slashdot Mirror
My preferred approach for presentations is to use Inkscape to make templates, and then just write the presentation in LaTeX. I understand that this doesn't suit everyone, but it is surprisingly easy to generate good looking PDF presentations efficiently this way. Better than Inkscape alone - at least until it gets multi-page support.
And how well would it render in W3?...
As a Republican supporter you are far more interested in keeping the government as small as possible. As an actual elected Republican I think it's been pretty clearly demonstrated that you really wouldn't give a crap about the size of government, and would be happy to grow it if it suits your needs. This gaping difference between rhetoric used to rally support and actual actions taken is, of course, hardly a Republican only thing. The Democrats are just as keen to fly the "social justice" flag, and rally support from people who are ardently in favour of that, yet seem to have little or no real interest in that issue (besides some token gestures - as the Republicans occasionally do with "small government") once elected. What this really means is that Republican supporters don't really have that much to fear from Democrats - they aren't going to grow the government any more than Republicans actually will. Likewise Democrat supporters don't really have too much to fear from Republicans, they aren't going to ignore social justice issues any more than the Democrats actually will. Still, it's important to at least have some rhetorical differences to keep the supporters revved up and deathly afraid of the distaster that, in theory, would befall the country should "the other party" get elected.
Indeed, further to the point of the relative hospitableness of the areas of Greenland settled by the Norse, it seems Google maps and satellite photos can come to out aid. Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
Eastern settlment area, and Eastern settlment map
Western settlment area, and Western settlement map.
Just for reference, here is a zoom of the area of the Brattahlid and Gardar farms (two of the largest/richest farms), and a zoom of the Sandnes farm area from the Western settlment.
Unforunately no, the Norse settlements were never under ice (snow in the winters at times, but not under ice). The particular areas settled were in fjords where there was no ice, indeed the area was actually quite green. Consider these Googlemaps images of the sites for the Western and Eastern Settlements:
Eastern settlment area, and Eastern settlment map
Western settlment area, and Western settlement map.
Just for reference, here is a zoom of the area of the Brattahlid and Gardar farms (two of the largest/richest farms), and a zoom of the Sadnes farm area from the Western settlment.
Greenland used to be covered in ice with a few small areas in fjords that were habitable. What evidence we have of the Norse settlements (and there is a reasonable amount) shows that they were a farily marginal colony. For instance their cows were the smallest known, due to such a short period when they could be outside in pasture. There is evidence that while kept inside barns in the winter they had to be forcefed kelp to help fatten them up/keep them alive. Doesn't sound like a lush paradise.
And on the other hand, its not as if today the Norse settlements are just starting to melt out from under the ice. The areas of Greenland that were settled by the Norse are and have been since they were rediscovered) quite green and habitable. Try looking at photos of the ruins: Hvalsey ruins, another shot of Hvalsey, ruins at Gardar, another shot of the Gardar ruins, ruins at Brattahlid, a general shot (I can't identify the location), and to round things out, a couple shots of modern day Greenland in summer. Things have looked that way for a while - the ice was always inland from these fjords. It didn't take anything special for the Norse to be able to settle there - just a little determination to survive the winters.
And I think that's reasonable, given that the role that Fortress is intended to play is far more important (especially given that it is a niche role) than what Fortresses ancestor languages are. It owes as much to Scala (at least it looks that way - I have no idea whether Scala was actually an influence) as it does to Eiffel. What counts is what it is intended to be used for - which is scientific computing and HPC where parallelisation counts: that is to say the niche currently filled by Fortran.
I honestly have no idea what you mean here. I expect GUI/OS-interaction code would most likely look an awful lot like Scala, which is hardly a problem. The math formatting onlycomes in when actually doing mathematics. The rest of the time it's essentially just an OO language like any other, and won't look any different to any other language. Treating UI events will be straightforward.
There are a number of things that Fortress does to make parallelisation work. For instance for loops are parallel by default, as are vector operations. Try looking at the "atomic" keyword to see more on how control of serial and parallel operation is handled. If you want easy parallelisation via each method working in a separate thread and contracts determining wait conditions then look at Eiffel and SCOOP: it introduces a single new keyword (separate) and allows you to do just that.
I think what you need to consider is how many operator symbols are defined by default in Fortress: it actually isn't that many. Fortress simply supports unicode and the ability to define new operators using classical math symbols - it doesn't have them all defined in the base language. Almost everything is farmed out to libraries. You may think it looks ugly and complicated compared to Perl but I (who have done a fair bit of Perl programming, and have spent time looking at Fortress as it developed) think you're being premature. See it in action or actually try using it yourself and I think you'll quickly find it is, in fact, a lot more readable than Perl.
I was rather expecting the IDE to render it on the fly as you enter it, which, really, makes it no harder to deal with that mistyping a variable name (easier, in fact, given that if mistyped it won't render to the appropriate symbol). You can even expect automatic completion of symbols if you want. I would also expect a simple view toggle to let you see and edit the raw ASCII if that's what floats your boat.
Which is to say, its aimed at the niche that Fortran, despite how old and creaky it is, still rules. The world of programming has come a long way since Fortran, but nothing matches it for scientific computing and number crunching. To be honest that's about the only aspect of Fortran worth keeping...
You say that like it's a bad thing! Eiffel is, surprisingly enough, a very nice language to work in. I'd be very happy with a language targetted toward numerics (And with real math style notation to boot!) that was as pleasant to work with as Eiffel. Design by contract is a good thing, and importantly it is optional. You can specify a contract or property for a function, but you don't have to. The ability to flesh out an API with contracts and properties is a damn good thing - something far too many languages lack.
Contracts and properties are optional. If you don't want correctness guarantees then don't use them. On the other hand if you would like a little more insurance... well then they're very useful indeed.
Again, specification of units is optional. If you don't want to worry about units then don't use them. Then again if you're writing some physics code then having the sanity check of unit analysis to make sure everything is working properly is a damn useful thing to have available. Having dimensions and units as not more onerous than having types - it is simply another level of checking available; the benefit here is that the units are optional: if you don't want the extra checks, don't use them.
Well that depends on who you are really: Fortress looks incredibly readable to me. Then again I am a mathematician and look at math, formatted in exactly that way, all the time. If you spend all day looking at Java and C code then sure, it's going to look unfamiliar to you. Then again, you probably aren't in the target market for a language aimed specifically at scientific computing. To me a lot of C looks awful and can be hard to read because of its requirement that you pound everything into basic ASCII. It really all depends on what you're used to. As to how easy it is to enter - sure it would be nice if it was straight TeX - but then it is so similar that there is really no problem learning it. If you actually do a lot of math then you can name all those symbols straight away, and what you have to type in to get the symbol is simply it's name. Again, not ideal for people who don't do a lot of math, but then that isn't the target audience. If you do much math then the symbols look right instead of being the ugly ASCII kluges of other languages, and
In Fortress the basic types ZZ and RR provide arbitrary preceision integers and floats. If you want a specfied precision then you need, say, ZZ32 or RR64 etc. So in fact it is the correct notation.
Yes, but it is well documented and, if you are at all familiar with mathematics, straightforward to learn (indeed, you almost don't need to learn - instinctually typing in whatever you would say works for most symbols. It is no harder to learn than TeX - easier if you already know TeX in fact.
Sure, it applies to many people. None of them are in the target market for Fortess though. Fortress is aimed at mathematicians and scientists - the sort of people who are still using Fortran - and for them the math notation makes the whole thing much, much easier to read. It all depends on what you're used to. If you're a programmer who reads C and Java all day then that probably looks good to you. If you spend much of your time reading math papers, however, then mathematical syntax looks far more natural the the elaborate and obfuscated look of C. Congratulations, you're not the target market for the language - that doesn't mean it isn't a great idea that will be of great value to many other people.
They did think of that you know. They provide ASCII equivalents, akin to TeX, that let you type stuff in, and then it gets rendered to the appropriate symbol.
The aim is that mathematicians can simply write it in Fortress and get a full model at top speed. Fortress is designed to be able top do high performance computing. For loops are inherently parallel and so are array operations etc. Try actually skimming through bthe spec to see what it is and what it can do - it looks like a fantastic language to me (real math notation, design by contract, traits and properties, type inference etc.)
So they're going to include, what, a LaTeX implementation so programmers can make their symbols look right?
In a sense, yes. The real question, however, is why this wasn't done earlier? Sure we have to type in code in ASCII because we're stuck with keyboards to enter it with, but that doesn't mean the default view has to be ASCII. Really, why not let your IDE render it into proper mathematical symbols for you? As a mathematician it looks damn appealing to me.
I lack the fortran experience (I've only done the bare minimum of fortran programming), but I do have the math, and from my perspective, having read through the fortress spec (PDF) (okay, I skimmed it - it's huge) it looks like an excellent language for any mathematics intensive work (and indeed physics too, with its support for dimension and unit annotations). There's a great deal to like about the language. I hope it is successful.
I think that depends on what you mean by mathematical notation and symbols. In the case of Fortress that means Unicode input and the ability to actually render code, thus x^2 gets rendered with a proper superscript 2, array indexes a[i] get rendered to appropriate subscripts, and you have access to other nice symbols - for instance the floating point type is denoted by a blackboard bold R (as in the usual symbol mathematicians use to denote the reals) which you can enter as RR in ascii. The result is that you can enter mathematics via the keyboard and have it rendered in code with captial sigma for sums, standard arrows and cartesian product symbols to denote function signatures, actual square root symbols etc. Think of it as enriching the symbols available to be closer to the full set symbols mathematicians expect: it doesn't result in the horribly obfuscated look of APL, but is more akin to what one would see printed in a math textbook. Read through section 2.4 of the spec (PDF) to get the idea.
I would suggest it is worth the time to have a look at the Fortress spec - it actually looks like a very interesting language, and is actually a worthy fortran replacement. Of course being worthy and actually managing to overcome the inertia and actually replace fortran is another thing. Still, I would gladly use Fortress.
On the contrary, string theory is very interesting, and has a great deal of interesting things to say. The issue is more that it is mathematics not physics. There is, of course, nothing wrong with mathematics for its own sake. Indeed, many physics theories were preceeded by the development of purely mathematical work - where would general relativity be without Riemann's work on manifolds for instance? In many ways string theory could be classified in a similar sort of category - it is a lot of very interesting mathematics that could, one day, be applied to the development of a physical theory. The dilemma comes when people act as if it is physics instead of mathematics.
I must admit I was a little curious after watching the Youtube version - but then the sound quality on that is so poor anyway. Going to the forum and listening to original mp3s it becomes a little more clear - what you should be listening for is in the background of the Furtado song; if you listen you can actually hear precisely the original
Hmm, that would certainly be interesting. I'm not sure the Avon/Servalan relationship would go down quite so well in the US though...
It's simply a matter of being used to it. Having grown up in a country that used nothing but celsius I really have no problems determing the temperature outside - the units really aren't that "big" and work just fine if you're used to it.
Good to see someone else remembers that show. It started so poorly (the pilot was cheese plus), but it ended so well. I'd be very happy to see a decently done reboot of Space Above and Beyond, especially now that the BSG reboot (which drew heavily on SAaB) has given extra credibility to more dark gritty SF. The only other SF TV series I'd ever want to see rebooted is Blake's 7. I guess, in some ways, you could almost claim that Firefly was almost that - still, Blake's 7 with production values would be interesting to see.
Heh, I don't. I can get by with office applications but I can only barely use a spreadsheet - I'm a mathematician so computers I work on tend to come equipped with rather more interesting power toys for any calculation/plotting needs and I simply never learned how to use spreadsheets. Likewise, due to my profession, I tended to use LaTeX for documents. Sure, I can bash out a letter or a simple document in a word processor, but anything fancy like tables, headers and footers and the like are things I would have to look up, or muddle through - I honestly don't know. Luckily for me, however, office application skills aren't that highly prized in the sorts of jobs I apply for. I do sometimes wonder how much of an odd one out I am though - I mean, am I alone in having "basic competence" in office apps, or is it common and everyone else just lies?
It would be interesting, then, to see a comparison of training costs between switching to an OSS solution and upgrading to Vista and Office 2007. Certainly a pure OSS solution is going to require more training because there are more changes involved, and some of the differences are significant. Still given the easier incremental transitions you're likely to get on the OSS upgrade treadmill (which tends to have more regular, smaller, upgrades) compared to MS, you might be able to claim an offset in future training costs. At the very least it would be interesting to see how such costs stack up in a variety of cases. If training to the only really significant cost for OSS then this next upgrade round from MS might see a few more companies deciding to do an OSS roll out when they finally get around to upgrading.
I think the point of the article is that, aside from a downtrodden populace, a populace that feels disenfranchised can be just as likely to turn to desperation. In terms of perception wealth turns out to be a relative thing (as noted in the article): if you're surrounded by people who have a lot more than you, and constantly presented with images of people who are better off than you, then, regardless of how well off you might actually be, you feel poor. More importantly when you feel there is a disconnect between you and those around you who re much wealthier - that's when problems start to occur. Capitalism works by providing the promise that even if you are poor now you could rise up to be sucessful and wealthy. It placates the losers with the potential and hope that they can become winners. If they lose that hope, if the potential no longer seems to exist, they start to get unruly. And that's where income inequality starts to come in - if it gets wide enough then the disparity becomes so great that people simply cannot imagine how to get from where they are to there. Crossing the gap starts to become inconceivable for some. At that point they become rather more desperate, and that can, indeed, fuel social unrest. That's the concern.
I think the point is that we're all human and we all make occasional mistakes even with the best of intentions. There's plenty of code out there written by very experienced C programmers that still has buffer overflows and other glitches. That means that having a language that has the facility to make such errors easier to catch and correct early is a good thing. That means that having a language that pushes you toward secure practice by not having sloppy easy ways to do things is a good. Yes, we could all, in theory, write perfectly secure error free code in C or PHP or whatever, but in practice we don't - no one does. Languages that encourage best practice by default and provide the tools to catch errors earlier (with, say, design by contract) are a good thing if security is important. We're all human, and can use all the help we can get.