I have noticed an alarming trend in build tools -- they assume that you are using basically one language for your whole project. One of the reasons Make and co have so much more to specify is that they work for a much wider range of application. I looked into CMake just long enough to see that it would not work to make something that's written in five or six languages.
It's obvious that you can buy simplicity by special casing. What's hard is keeping a bit of it when you generalize. I had the same experience lately with testing frameworks, and I came to realise why dejagnu is cool and is still used even when there are much more polished frameworks available for specific workflows.
Actually, my experience has always been that starting with a known working implementation in some dynamic language (in my case used to be Matlab, now Python), makes it a heck of a lot easier to rewrite in a more fussy (but faster) compiled language (Fortran for numerics C++ for some other stuff like file handling).
Assuming that:
Language expressiveness differs, and dynamic/interpreted languages tend to get more stuff done in less lines than static/compiled ones.
There is good evidence that suggests the number of lines you produce per hour is insensitive of language
Data suggests you can do about twice the number of lines on a known problem than an unknown one
The bottlenecks in large programs are not as easy to predict as one may think -- profiling is often necessary to avoid premature optimization.
we conclude that it makes sense to take the knock on execution speed while developing a new algorithm or routine while the data size is small so that we can get more done in less time. We should then come out positive if we can just optimize the parts that are really slowing the program down, because even though we need more lines to do the same thing, we're in the more lines per hour area because we've solved the problem already.
From the gpeerreview page: "If the author likes the review, he/she will include it with his/her list of published works."
I honestly believe that the future of scientific publication is in a system where everyone publishes whatever they like and generate a hash of the article (or register some kind of unique ID). People then review these articles when they read them, with researchers in the field having unique IDs of their own. The score of the paper then works using something like the pagerank eigeinvector approach. Someone whos own work is rated highly adds more to your paper's score than a nobody. This allows people to post negative reviews (not just the positive ones you like).
For extra credit, there should be a window during which the paper and reviewers are anonymous, allowing the paper's merit to be assessed objectively.
Ideally, though, the reviewers wouldn't know who the authors are. This stops well-known researchers from slipping in bum papers and stops people from unknown institutions getting kicked without regard for their work. This would be the review equivalent of a double blind study, and if the goal of the process was to find valid research, it would already be like this. Unfortunately getting published these days is way more about being known and shaking hands than actually doing good work, because you know the guy you're sucking up to now is going to see your name on a paper he's reviewing and that will shift his opinion in your favour.
The ruby 1.9 is to python roughly as Java -server is to c using gcc (ratio of about 1.5). This is not "totally unusable" when comparing Java to C. The interpreted languages are all within one order of magnitude slower than the compiled languages. This does not change much, and people are still happy to use interpreted/dynamic languages because of the increase in development agility and lower time to solution.
The whole distinction between creativity and "sweat of the brow" is a bit strange to me. How is a photograph of an arrangement of fruit different in creativity from a good still-life? I think people should just get over themselves and admit that "creativity" is just uncommon skill.
I think that at least some applications work on a different kind of metaphor -- the "tool room" or "workshop" metaphor. When I want to edit photos I open (say) Gimp/Photoshop. Maybe I didn't have a particular photo in mind, but I know I want to spend some time working on my photos, so I go to the place that has the tools I need, just like I go to my desk when I want to write or go to my workbench when I want to do some woodwork.
The sad thing about.pkg installers is that although it's a pretty efficient way to get stuff onto the system, there's no clear way to get the stuff off (at least not as clear as dragging the icon from Applications to Trash). I yearn for a package manager (a la Linux distros) in OS X.
I fail to find any reference for the delimiter-based argument for making print a function (I looked for reasons for a print function here, and that PEP has some references too). Note that they didn't just add brackets, they actually changed print's semantics from being a statement to being a function.
I am sorry about the C thing -- I suppose I meant C-like languages as I hear this argument from users of such languages the most.
As for "pushing it [significant whitespace] so forcefully", I think you will find that most of the "python fanbois" are just saying that they tried it and it works, while the delimiter guys are far more belligerent about the stupidness of not having delimiters.
Actually, the reason for the brackets in print() is that it is now a function where it used to be a statement. All the other statements are still there (like return or def, etc). The decision had nothing to do with delimiters. The point the GP was trying to make is that most people who have coded for any amount of time indent consistently as part of their routine. I have been tripped up many times by code that was indented to look different from the actual flow of control. But then I prefer begin end to {}, too.
It is flawed to hold up C as the only language that got things right just because it's popular, and I would hold out on the "more absurd" comments until you have given python a fighting chance (and this means not using whatever brace language you are used to for about 3 months to retrain -- before then you'll just be fighting habits from the other language).
You make it seem that there is this thing called 'creativity' that really creates new ideas out of nothing. It could be argued that the human brain is a computing device and that creating a new song, piece of art or game is just as much the result of an algorithm (or deterministic computation of some kind) as the process in the paper. Of course, the process described here may be vastly simpler, but it is not inherently different. I challenge you to find anything in modern culture that is entirely removed from it so that it is not in some way a combination, albeit an interesting one, of what had come before.
I fail to see how you are going to unify the thinking about things that are inherently different. On the filesystem level, all things are just files with data, it's the different representations of this data that makes it useful. Now, I can buy the idea of some kind of abstraction framework that allows you to hook up different formats to do queries and such, but there are some very hard problems in there, that have been solved in different ways.
For instance, let's say three people have used different software to build the list of people coming to their party, with contact details and some notes. One has used Word and just laid out everything so that it "looks right", using spaces and tabs. Much of the semantic linking between items is now totally in the human's mind and not captured in the data at all. The second has used Excel, but has used a different sheet for every person. The third has used Access and has built a nice view to see the list. Given that there are users that will naturally gravitate to each of these approaches, how can you provide a unified method to access the list? Heck, I've seen some approaches that I couldn't understand until the person explained what they were trying to do, and my pattern recognition and contextual systems are a lot more advanced than the projected AI for the next couple of years.
I think 'meaningless' is quite a stretch. The Intel compilers are definitely better on Intel chips, but GCC is accessible and generates good code for other chips too. It is more of a known quantity for the kind of person who reads Slashdot. The reality is that C++ is _not_ the gold standard for speed any more than GCC (or Intel's compiler) is a standard for compilers. I think that what we are seeing is the convergence of compiler tech. No language is inherently slower than any other language -- compilers are more or less efficient, languages may make their job easier or harder. In the end, language is not all that important, compilers are.
Culture is a pretty pervasive thing. Gender roles are portrayed everywhere, from the home to TV to billboards to advertising in shops. It is very hard to raise a child with no cultural influence. My biggest hint that at least the color-gender link is not innate is that it has changed in the last 100 years
"It is counterintuitive because nature does not execute equations to do its thing. The human brain is orders of magnitude more complex than any program in existence and it does not perform equations. Nobody should be forced to use an unnatural notation for computer programming just because mathematicians are enamored with it. A computer is not a function evaluator. The proper context for computing is behavior and it comes from psychology, not mathematics."
The idea that any notation for computer programming is "natural" is quite funny to me, especially given the amount of time I've spent trying to grok oo. "Natural" is not an absolute -- people differ in their preference for expression. Some sing, some talk, some like music and some like programming. Pretending that the approach that has aligned best with your intuition is the only sensible way of programming a computer is nearsighted at best and pompous at worst. How do you explain the interest in functional programming? Are all these people just "unnaturally" attracted to these bizarre concepts, or have they also found a metaphor that aligns with their preference?
When you rail against someone with preferences expressed as truths, you are bound to tick off some people.
Also, when you talk about 'nature not executing equations' -- one of the most interesting things about most of the behaviours we have identified in nature is that they are best modelled using many simultaneous equations. Languages that are designed to model 'the real world' inevitably contain methods of specifying things that should happen simultaneously (have a look at for example Modelica). Almost all the advances we have made in predicting what happens around us to any degree of accuracy has gone via equations or sets of equations. I cannot see how I would get anything done without them. Definitely I cannot think of anything in nature as 'behaviours' in a way that enables calculations. Of course, if this is how it works for you, that's fine, just don't tell me the way I approach the world is totally wrong and unnatural when it works for me.
I use Python (and scipy) extensively for gluing all my stuff together. That said, the Fortran syntax for handling matrices is infinitely superior.
For instance: "forall (i=1:3,j=4:5) x(i,j) = i+j" as opposed to (perhaps) x = array([[i+j for j in [4,5]] for i in [1,2,3]]). And the forall automatically parallelizes. The where statement is also really cool, and I can have arrays with any indexing scheme I choose. Functions with the elemental property automatically apply to all elements of an array, and parallelize. All of this of course doesn't work so well for non-sparse matrices and so forth, but for the stuff I do (and many engineers do), it rocks.
I know python and sciypy and the built-in support for vectors and matrices that Fortan supplies is better because there is good syntax. To top it all off, the compilers for Fortran are pretty damn efficient, so many low-level algorithms code almost the same in Fortran and Python, they just run about 10 times faster.
My strategy at the moment is to use Python for the high-level stuff and Forrtan for the heavy lifting, using f2py. Python will no sooner replace Fortran than replacing C -- they play in different arenas. My real point in the previous post was that for languages that have efficient compilers, none come close to Fortran for ease of use with my kind of scientific computation. Python and other scripting languages (even Matlab or octave or similar) offer more interaction, but then it comes to the speed, Fortran is better than C, C++ or Java (the most common proposed alternatives).
Most of the engineers I know couldn't be bothered to really learn something as vast as Java or C++. Fortran is simple enough that you can start doing productive work in a day. In the 'hot' languages of today, you need to get the language, then do tons of research about how to handle matrices and vectors, download them, get them installed. With Fortran you download gfortran (or just get it with your package manager) and start writing productive code. Then you compile it and it runs really, really fast with little effort from your side.
If you can point me to a set of tools for the language you propose is squeezing fortran out that makes it as easy to work with vectors and matrices as Fortran, I would be thankful, but I haven't found it yet. I think the major problem is that the average researcher is writing small (1000 lines) programs, while stuff like c++ only starts paying dividends when you are writing big programs.
There's an old joke: "What will the language of scientific computing look like in 10 year's time?" -- "I don't know, but it will be called Fortran".
Fortran has been reinvented many times. Fortran2003 is not your daddy's Fortran. Free-form formatting, implicit matrix and vector operations, smart support for parallel operations. If you like Matlab or Python with NumPy, you will probably like Fortran 2003. The thing is, that Fortran has been around for so long that Fortran compilers are typically crazily efficient. Of course, there's nothing there that can't be done in C, but Fortran makes a lot of it easy as part of the standard language, while in C/C++ you are left wondering which of the (many) matrix libraries you should use.
I think Fortran gets a bad rap because students like you talk to their profs, who remember 'old' fortran (77). A lot has happened since then.
"Engineers and scientists today try to do everything in matlab or excel, except for those that do postgraduate courses, who often try to do things in fortran."
And I suppose we should be using c++ instead of languages that were designed explicitly with our needs in mind? In Matlab (and Fortran) I get out-of-the-box support for imaginary numbers and vectorised operations, even varying levels of support for matrix math. Matlab and Fortran are homeomorphic, so there's little that stops me from porting my Matlab routines to Fortran when I need more speed. Every single test I have done with Fortran vs c++ has shown me that I need to jump through a lot of loops to get the same amount of speed out of c++ as I get with very little effort from Fortran.
I will grant that the object systems in both those languages are limited (in Forrtan's case at least they have chosen to restric the object stuff to things they can expect efficient compiler support for), and I will grant that Excel is not the best tool for large-scale numeric work, but I think there is no real reason to avoid purpose-made tools in favour of generic tools when you just want to get the job done (Excel for instance is great for 'playing' with a problem interactively).
As an aside: I know many languages, have programmed significant programs using several paradigms, and I have learned that one language is never going to solve all your problems. It's better to know many and use the right tool for the job. So I use grep, sed, awk, bash, python, fortran, matlab and a bit of haskell and lisp for the problems they solve well, and I advise people to find out what problems languages solve well before writing them off. If that was your point (the try to do everything part), then I agree with you, otherwise you might want to look into the tools you seem to be dissing again.
I suppose it's all down to what you know. I learned C++ and Pascal in school, then did a lot of Matlab for my Masters, which really got me into the dynamic typing thing, so Python seemed natural to me. Every time I try to do something in C++ now, I feel like I'm spending more time on defining types than on solving the problem. And the braces irritate the hell out of me.
The reality is that one's history with programming affects the way one thinks about programming. If I had a dime for each time I've seen languages that I like being redone with "more natural syntax" where this basically means c-like syntax, I would be a rich man.
By the way -- for solid typing, haskell is better than c++ any day. Type inference means you only have to define types where it is useful and strong typing with proper type handling in the standard prologue means you don't get the undebuggable mess that results from heavy use of the STL.
I will give you this: there are well developed IDEs for the 'big program' languages that make it easier to develop a large program. For my needs as a researcher, there is no upside to c++. I've gone to Python with Fortran for the heavy lifting.
Full disclaimer: This was posted from a mac.
I have been using Linux exclusively at work for about 8 years. 3 years ago I bought a mac laptop and found stuff worked pretty much as I thought it should or better. However, when I am faced with a Windows computer these days (especially Vista) I have no clue. At least I am aware of the fact that my experience with one environment makes it hard to use another, instead of just ranting about how unintuitive Windows is.
That being said, I am still irked by the need to download programs from their website instead of just using my package manager and keeping my system up to date (including all my installed apps) seems like a chore. But my mother-in-law has next no no experience with computers and couldn't find her way around the windows machine they had -- I had to do constant tech support. Since they got a mac she figures it out herself. I don't know if she struggles any less, but she certainly bothers me less.
I would love to see a proper long term study on productivity with common OSs - not just 'sit down, do this' type stuff, but 'live with this computer for a couple of weeks, there will be several tasks you need to complete after week 2'.
Fine, but remember the original thread started with comments about the high-res screens being hard to read. All other things being equal, I would choose a high resolution screen. Unfortunately, as you point out, there are drawbacks to more pixels.
Perhaps we have stumbled on the real reason we don't see so many high resolution laptops.
Having more resolution means being able to discern more detail. There is a clear difference in quality (and legibility) of fonts on a high resolution screen and a low resolution one at the same physical font size. For stuff like line drawings and scientific data visualisation, the extra resolution really helps.
Increasing the quality of font rendering can also significantly reduce fatigue when reading a lot of text. So, overall more resolution is better. As near as I can tell there is no downside to increased resolution as long as the underlying subsystem understands how to handle the rendering.
Slashdot Mirror
I have noticed an alarming trend in build tools -- they assume that you are using basically one language for your whole project. One of the reasons Make and co have so much more to specify is that they work for a much wider range of application. I looked into CMake just long enough to see that it would not work to make something that's written in five or six languages.
It's obvious that you can buy simplicity by special casing. What's hard is keeping a bit of it when you generalize. I had the same experience lately with testing frameworks, and I came to realise why dejagnu is cool and is still used even when there are much more polished frameworks available for specific workflows.
Assuming that:
Language expressiveness differs, and dynamic/interpreted languages tend to get more stuff done in less lines than static/compiled ones.
There is good evidence that suggests the number of lines you produce per hour is insensitive of language
Data suggests you can do about twice the number of lines on a known problem than an unknown one
The bottlenecks in large programs are not as easy to predict as one may think -- profiling is often necessary to avoid premature optimization.
we conclude that it makes sense to take the knock on execution speed while developing a new algorithm or routine while the data size is small so that we can get more done in less time. We should then come out positive if we can just optimize the parts that are really slowing the program down, because even though we need more lines to do the same thing, we're in the more lines per hour area because we've solved the problem already.
From the gpeerreview page: "If the author likes the review, he/she will include it with his/her list of published works."
I honestly believe that the future of scientific publication is in a system where everyone publishes whatever they like and generate a hash of the article (or register some kind of unique ID). People then review these articles when they read them, with researchers in the field having unique IDs of their own. The score of the paper then works using something like the pagerank eigeinvector approach. Someone whos own work is rated highly adds more to your paper's score than a nobody. This allows people to post negative reviews (not just the positive ones you like).
For extra credit, there should be a window during which the paper and reviewers are anonymous, allowing the paper's merit to be assessed objectively.
Ideally, though, the reviewers wouldn't know who the authors are. This stops well-known researchers from slipping in bum papers and stops people from unknown institutions getting kicked without regard for their work. This would be the review equivalent of a double blind study, and if the goal of the process was to find valid research, it would already be like this. Unfortunately getting published these days is way more about being known and shaking hands than actually doing good work, because you know the guy you're sucking up to now is going to see your name on a paper he's reviewing and that will shift his opinion in your favour.
The ruby 1.9 is to python roughly as Java -server is to c using gcc (ratio of about 1.5). This is not "totally unusable" when comparing Java to C. The interpreted languages are all within one order of magnitude slower than the compiled languages. This does not change much, and people are still happy to use interpreted/dynamic languages because of the increase in development agility and lower time to solution.
The whole distinction between creativity and "sweat of the brow" is a bit strange to me. How is a photograph of an arrangement of fruit different in creativity from a good still-life? I think people should just get over themselves and admit that "creativity" is just uncommon skill.
I think that at least some applications work on a different kind of metaphor -- the "tool room" or "workshop" metaphor. When I want to edit photos I open (say) Gimp/Photoshop. Maybe I didn't have a particular photo in mind, but I know I want to spend some time working on my photos, so I go to the place that has the tools I need, just like I go to my desk when I want to write or go to my workbench when I want to do some woodwork.
The sad thing about .pkg installers is that although it's a pretty efficient way to get stuff onto the system, there's no clear way to get the stuff off (at least not as clear as dragging the icon from Applications to Trash). I yearn for a package manager (a la Linux distros) in OS X.
I fail to find any reference for the delimiter-based argument for making print a function (I looked for reasons for a print function here, and that PEP has some references too). Note that they didn't just add brackets, they actually changed print's semantics from being a statement to being a function.
I am sorry about the C thing -- I suppose I meant C-like languages as I hear this argument from users of such languages the most.
As for "pushing it [significant whitespace] so forcefully", I think you will find that most of the "python fanbois" are just saying that they tried it and it works, while the delimiter guys are far more belligerent about the stupidness of not having delimiters.
Actually, the reason for the brackets in print() is that it is now a function where it used to be a statement. All the other statements are still there (like return or def, etc). The decision had nothing to do with delimiters. The point the GP was trying to make is that most people who have coded for any amount of time indent consistently as part of their routine. I have been tripped up many times by code that was indented to look different from the actual flow of control. But then I prefer begin end to {}, too.
It is flawed to hold up C as the only language that got things right just because it's popular, and I would hold out on the "more absurd" comments until you have given python a fighting chance (and this means not using whatever brace language you are used to for about 3 months to retrain -- before then you'll just be fighting habits from the other language).
You make it seem that there is this thing called 'creativity' that really creates new ideas out of nothing. It could be argued that the human brain is a computing device and that creating a new song, piece of art or game is just as much the result of an algorithm (or deterministic computation of some kind) as the process in the paper. Of course, the process described here may be vastly simpler, but it is not inherently different. I challenge you to find anything in modern culture that is entirely removed from it so that it is not in some way a combination, albeit an interesting one, of what had come before.
I fail to see how you are going to unify the thinking about things that are inherently different. On the filesystem level, all things are just files with data, it's the different representations of this data that makes it useful. Now, I can buy the idea of some kind of abstraction framework that allows you to hook up different formats to do queries and such, but there are some very hard problems in there, that have been solved in different ways.
For instance, let's say three people have used different software to build the list of people coming to their party, with contact details and some notes. One has used Word and just laid out everything so that it "looks right", using spaces and tabs. Much of the semantic linking between items is now totally in the human's mind and not captured in the data at all. The second has used Excel, but has used a different sheet for every person. The third has used Access and has built a nice view to see the list. Given that there are users that will naturally gravitate to each of these approaches, how can you provide a unified method to access the list? Heck, I've seen some approaches that I couldn't understand until the person explained what they were trying to do, and my pattern recognition and contextual systems are a lot more advanced than the projected AI for the next couple of years.
I think 'meaningless' is quite a stretch. The Intel compilers are definitely better on Intel chips, but GCC is accessible and generates good code for other chips too. It is more of a known quantity for the kind of person who reads Slashdot. The reality is that C++ is _not_ the gold standard for speed any more than GCC (or Intel's compiler) is a standard for compilers. I think that what we are seeing is the convergence of compiler tech. No language is inherently slower than any other language -- compilers are more or less efficient, languages may make their job easier or harder. In the end, language is not all that important, compilers are.
Culture is a pretty pervasive thing. Gender roles are portrayed everywhere, from the home to TV to billboards to advertising in shops. It is very hard to raise a child with no cultural influence. My biggest hint that at least the color-gender link is not innate is that it has changed in the last 100 years
"It is counterintuitive because nature does not execute equations to do its thing. The human brain is orders of magnitude more complex than any program in existence and it does not perform equations. Nobody should be forced to use an unnatural notation for computer programming just because mathematicians are enamored with it. A computer is not a function evaluator. The proper context for computing is behavior and it comes from psychology, not mathematics."
The idea that any notation for computer programming is "natural" is quite funny to me, especially given the amount of time I've spent trying to grok oo. "Natural" is not an absolute -- people differ in their preference for expression. Some sing, some talk, some like music and some like programming. Pretending that the approach that has aligned best with your intuition is the only sensible way of programming a computer is nearsighted at best and pompous at worst. How do you explain the interest in functional programming? Are all these people just "unnaturally" attracted to these bizarre concepts, or have they also found a metaphor that aligns with their preference?
When you rail against someone with preferences expressed as truths, you are bound to tick off some people.
Also, when you talk about 'nature not executing equations' -- one of the most interesting things about most of the behaviours we have identified in nature is that they are best modelled using many simultaneous equations. Languages that are designed to model 'the real world' inevitably contain methods of specifying things that should happen simultaneously (have a look at for example Modelica). Almost all the advances we have made in predicting what happens around us to any degree of accuracy has gone via equations or sets of equations. I cannot see how I would get anything done without them. Definitely I cannot think of anything in nature as 'behaviours' in a way that enables calculations. Of course, if this is how it works for you, that's fine, just don't tell me the way I approach the world is totally wrong and unnatural when it works for me.
I use Python (and scipy) extensively for gluing all my stuff together. That said, the Fortran syntax for handling matrices is infinitely superior.
For instance: "forall (i=1:3,j=4:5) x(i,j) = i+j" as opposed to (perhaps) x = array([[i+j for j in [4,5]] for i in [1,2,3]]). And the forall automatically parallelizes. The where statement is also really cool, and I can have arrays with any indexing scheme I choose. Functions with the elemental property automatically apply to all elements of an array, and parallelize. All of this of course doesn't work so well for non-sparse matrices and so forth, but for the stuff I do (and many engineers do), it rocks.
I know python and sciypy and the built-in support for vectors and matrices that Fortan supplies is better because there is good syntax. To top it all off, the compilers for Fortran are pretty damn efficient, so many low-level algorithms code almost the same in Fortran and Python, they just run about 10 times faster.
My strategy at the moment is to use Python for the high-level stuff and Forrtan for the heavy lifting, using f2py. Python will no sooner replace Fortran than replacing C -- they play in different arenas. My real point in the previous post was that for languages that have efficient compilers, none come close to Fortran for ease of use with my kind of scientific computation. Python and other scripting languages (even Matlab or octave or similar) offer more interaction, but then it comes to the speed, Fortran is better than C, C++ or Java (the most common proposed alternatives).
Most of the engineers I know couldn't be bothered to really learn something as vast as Java or C++. Fortran is simple enough that you can start doing productive work in a day. In the 'hot' languages of today, you need to get the language, then do tons of research about how to handle matrices and vectors, download them, get them installed. With Fortran you download gfortran (or just get it with your package manager) and start writing productive code. Then you compile it and it runs really, really fast with little effort from your side.
If you can point me to a set of tools for the language you propose is squeezing fortran out that makes it as easy to work with vectors and matrices as Fortran, I would be thankful, but I haven't found it yet. I think the major problem is that the average researcher is writing small (1000 lines) programs, while stuff like c++ only starts paying dividends when you are writing big programs.
There's an old joke: "What will the language of scientific computing look like in 10 year's time?" -- "I don't know, but it will be called Fortran".
Fortran has been reinvented many times. Fortran2003 is not your daddy's Fortran. Free-form formatting, implicit matrix and vector operations, smart support for parallel operations. If you like Matlab or Python with NumPy, you will probably like Fortran 2003. The thing is, that Fortran has been around for so long that Fortran compilers are typically crazily efficient. Of course, there's nothing there that can't be done in C, but Fortran makes a lot of it easy as part of the standard language, while in C/C++ you are left wondering which of the (many) matrix libraries you should use.
I think Fortran gets a bad rap because students like you talk to their profs, who remember 'old' fortran (77). A lot has happened since then.
"Engineers and scientists today try to do everything in matlab or excel, except for those that do postgraduate courses, who often try to do things in fortran."
And I suppose we should be using c++ instead of languages that were designed explicitly with our needs in mind? In Matlab (and Fortran) I get out-of-the-box support for imaginary numbers and vectorised operations, even varying levels of support for matrix math. Matlab and Fortran are homeomorphic, so there's little that stops me from porting my Matlab routines to Fortran when I need more speed. Every single test I have done with Fortran vs c++ has shown me that I need to jump through a lot of loops to get the same amount of speed out of c++ as I get with very little effort from Fortran.
I will grant that the object systems in both those languages are limited (in Forrtan's case at least they have chosen to restric the object stuff to things they can expect efficient compiler support for), and I will grant that Excel is not the best tool for large-scale numeric work, but I think there is no real reason to avoid purpose-made tools in favour of generic tools when you just want to get the job done (Excel for instance is great for 'playing' with a problem interactively).
As an aside: I know many languages, have programmed significant programs using several paradigms, and I have learned that one language is never going to solve all your problems. It's better to know many and use the right tool for the job. So I use grep, sed, awk, bash, python, fortran, matlab and a bit of haskell and lisp for the problems they solve well, and I advise people to find out what problems languages solve well before writing them off. If that was your point (the try to do everything part), then I agree with you, otherwise you might want to look into the tools you seem to be dissing again.
I suppose it's all down to what you know. I learned C++ and Pascal in school, then did a lot of Matlab for my Masters, which really got me into the dynamic typing thing, so Python seemed natural to me. Every time I try to do something in C++ now, I feel like I'm spending more time on defining types than on solving the problem. And the braces irritate the hell out of me.
The reality is that one's history with programming affects the way one thinks about programming. If I had a dime for each time I've seen languages that I like being redone with "more natural syntax" where this basically means c-like syntax, I would be a rich man.
By the way -- for solid typing, haskell is better than c++ any day. Type inference means you only have to define types where it is useful and strong typing with proper type handling in the standard prologue means you don't get the undebuggable mess that results from heavy use of the STL.
I will give you this: there are well developed IDEs for the 'big program' languages that make it easier to develop a large program. For my needs as a researcher, there is no upside to c++. I've gone to Python with Fortran for the heavy lifting.
Full disclaimer: This was posted from a mac. I have been using Linux exclusively at work for about 8 years. 3 years ago I bought a mac laptop and found stuff worked pretty much as I thought it should or better. However, when I am faced with a Windows computer these days (especially Vista) I have no clue. At least I am aware of the fact that my experience with one environment makes it hard to use another, instead of just ranting about how unintuitive Windows is.
That being said, I am still irked by the need to download programs from their website instead of just using my package manager and keeping my system up to date (including all my installed apps) seems like a chore. But my mother-in-law has next no no experience with computers and couldn't find her way around the windows machine they had -- I had to do constant tech support. Since they got a mac she figures it out herself. I don't know if she struggles any less, but she certainly bothers me less.
I would love to see a proper long term study on productivity with common OSs - not just 'sit down, do this' type stuff, but 'live with this computer for a couple of weeks, there will be several tasks you need to complete after week 2'.
I would imagine that the cloth is vapour-permeable, so the sweat will be able to get out by evaporating and passing through the fabric.
FWIW, Apple make a development environment called Xcode.
Fine, but remember the original thread started with comments about the high-res screens being hard to read. All other things being equal, I would choose a high resolution screen. Unfortunately, as you point out, there are drawbacks to more pixels.
Perhaps we have stumbled on the real reason we don't see so many high resolution laptops.
Having more resolution means being able to discern more detail. There is a clear difference in quality (and legibility) of fonts on a high resolution screen and a low resolution one at the same physical font size. For stuff like line drawings and scientific data visualisation, the extra resolution really helps.
Increasing the quality of font rendering can also significantly reduce fatigue when reading a lot of text. So, overall more resolution is better. As near as I can tell there is no downside to increased resolution as long as the underlying subsystem understands how to handle the rendering.