Of course, intuition is not the same for everyone. I find object-oriented languages 'painfully counterintuitive', but I have the good sense to realise that it's working for many people and it may be my personal experience (or lack thereof) that is making the process painful, rather than the actual technology.
Actually, C is a prime example of a weakly/statically typed language. The existence of a void pointer (or, actually, values in memory that are not tagged as being of a particular type) means that any piece of memory could be accessed as though it was any type. I could, for instance create an integer variable and a string variable pointing to the same piece of memory in C. This is weak typing. If there was a mechanism that explicitly forbade me from accessing a piece of memory which has been marked as 'type A' as 'type B', we have strong typing. If this can be enforced at compile time, we have static typing. Automatic type conversion does not really require weak typing if the coercion rules are well defined.
I'm sorry, "the horror of... python..."? Where did that come from? Wait, let me guess, the language would be great if it had "ends"" or, even better, used braces to delimit blocks.
In my experience trying to do the same at our university, Matlab's performance is a fair bit better than Python's, except on the stuff that's handled by LAPACK, when the performance is about the same. Newer versions of Matlab also have pretty good support for multicore/parallel programming that's easy to set up. I've never heard of anyone experiencing a speedup when moving to Python, although I agree it's a really nice language.
As an aside, when you really want some good performance bits, f2py is really good and newer Fortran is almost exactly like Matlab, just compiled with really efficient compilers (this is how I solve my performance problems in Python).
The reason why languages that choose to use typed _value_ instead of typed _variables_ (like python) are rarely compiled is because it is either infeasably difficult (even in the case of code where everything's known up front) or impossible (in the case of programs that read from files and so on) to determine what type a value will have until you run the program. This means that even if we were to compile the python program, it would effectively require the python interpreter in its runtime to operate in the same way. This is what compiled Lisps do.
Regarding what defines a scripting language, there's no generally agreed-upon definition. Typically it involves the language being interpreted, loosely or dynamically typed and having a standard library/modules that make operations in a certain field (like text processing, dom navigation, etc) easy.
And about Java performance: There is building support for Java vms (with hotspot optimisation and disregarding startup times for the server) running code being in the same order of magnitude as things like gcc, while the interpreted languages are by conventional wisdom about an order of magnitude slower (see the alioth shootout).
I have honestly tried Eclipse and Netbeans for my programming, but the learning curve is just way too high. When I started using Emacs, I could do what I wanted almost instantly (open a text file and start editing it). To just open a file in Eclipse, edit it and compile it seems impossible. You need to get the correct plugins for the filetype you have chosen (and I am using many types of files). Then, you need to create a project, figure out what workspace this is supposed to be in. I suppose if I didn't already have tons of projects organised into a nice directory structure -- if Eclipse was my first experience with programming and I could just create new projects in the default workspace -- it would be a little easier, but the existing code adds a bit of inertia to my development style.
I posted a question that got some airtime on Slashdot about IDE support for multi-language projects. The studio-style apps seem to be built around the idea that you will be using a single language for the whole project. This is not bad as far as it goes, but your existing codebase is Python, C, C++ and Fortran with lots of shell scripting, m4, awk, sed and Makefiles in between, the studio stule stuff doesn't cut it. Not to mention, that even when I'm working on a large project in one language (which Ecipse does well), I may want to open a text file of some other kind (XML, CSV, whatever) and Eclipse doesn't make it easy in the same way that emacs does. I also can't fire up Eclipse from the terminal to edit a file from home via ssh. And I haven't found a text editor that does indenting the way I have grown to love -- by hitting tab anywhere and having the indentation done right.
Now, I know all the arguments for IDEs, and I have really tried, but I think many people are like me in using Emacs because they are (or at least feel) more productive in it on their codebase. The underlying mindsets are just so different that it's really hard to get going in IDEs.
Just use auto-wrap on 75 chars. This makes it much easier to find the bug that LaTeX is complaining about. The long lines are the first thing I change when I inherit files.
The long lines also make change tracking that much harder, as most tools only go down to line granularity.
Ya know, for a guy who worked in a Patent office, Albert really missed out on stunning opportunity on royalties on general relativity. I'm pretty sure most countries have exemptions on copyright and patents for mathematical formulae. Mine (South Africa) sure does, and so does America
No need to recode from the IAPWS standards (I've done it, but those equations are huge and a pain to type and debug). Just go use http://freesteam.sourceforge.net/
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
Gotta have functions because expecting all programmers to know how to copy and paste large chunks of code when they use them isn't unfair to those who haven't gained those skills yet.
When I'm programming, certain things set off red flags. If I see myself doing something similar many times, I extract that stuff into a function if "the thing" is parameterised by values. If it's parameterised in terms of types, I use a template, if there's obvious structure, I use a class. If it's small and gets done a lot, I use a loop. These structures are things that are not technically necessary for programming, but each mechanism cuts down on redundancy and reduces the chance of errors by having to remember where all the changes are. In addition, reducing the boilerplate makes it easier to see the structure in the program.
The auto variable is an example of type inference, and the fact that C/C++ doesn't have it is really a nuisance once one has gotten used to languages with more powerful type systems like Haskell.
So, if you're good with powertools you can be safe without guards, eye protection and hearing protection? I suppose you think that all the buffer overflow and memory leak problems we've seen in high quality software is because the programmers are no good. Nobody claims absolutes, but language features that make it easy to do the right thing make it more likely that people will do the right thing. Language features that allow you to do something that is likely to cause problems increase the risk that these problems will occur. That's just basic probability.
I can tell you that I have had to debug off-by-one errors in Fortran and C (where no range checking is done, so you can easily end up modifying the next variable in memory rather than the last element of your array), but never in something like Matlab or Python where range checking is done. Now, that may make me a bad programmer, but show me the programmer who has never made a typo.
I hear that -- I just got two new LG LCDs and the blue power lights are incredibly bright and aimed forward, so I had to cover them with a piece of tape. I don't see how this could get past testing.
I suppose curving would fix this, but I am in South Africa, where you get the mark you obtained on the test, full stop.
Regarding the types of students that do well in my subjects -- yes, different people did well. Students that were used to acing subjects weren't doing well using their standard techniques and students that actually attempted to "get" it were doing quite well. Unfortunately the typical makeup of my classes meant that this gave me far lower marks on average than many other classes.
I'm still doing what I do -- just remember my original post was about how the average student can drive behaviour that is bad for the top fraction.
Of course I agree that one should have unpredictable tests. However, most of my students did not thank me for giving them a more valuable learning experience.
I have grappled with this problem myself. I am a lecturer at a university (chemical engineering) and I taught our introductory programming course using Matlab. I believe that it's crazy to have tests on programming where you don't have references or a computer with you, so I set alll my tests as open book, with computers in front of the students. I gave many small assignments throughout the semester and one large assignment at the end. The students uniformly hated the subject. Some of their concerns were that the tests were "too unpredictable."
You can't blame faculty alone for courses being the way they are -- the students have learnt how to play the game. You work many old papers and basically end up memorising the classes of problems that can be asked. This behaviour leads to a sort of conundrum: if you keep setting new and interesting papers, you will start running out of problems that are within a certain difficulty level. Your students will hate you because they can't prepare for your tests they way they are used to. If you set similar papers (or recycle papers) the first-time difficulty of each paper remains the same, but the apparent difficulty of your subject decreases because your subject is easily gamed by people not interested in mastering the subject but rather passing your tests.
From the educator's perspective, testing is hard in computer-based subjects because a realistic test (like a project) is trivially easy to copy and testing within a realistic timeframe restricts you to such simple problems that you run into the problem above. There therefore didacticly valid reasons for wanting to keep the answers to problem sets a secret: there are less students with the self control of using the answers as a solid teaching aid than there are who will use them as a quick shortcut to doing the assignments, just like there are fewer students who can manage their time to meet a single deadline than students who need frequent deadlines to make sure that they stay up to date. Pretending that the students are all just there to maximise their mastery of the subject is unrealistic. Most students are doing courses to get the magic paper that will give them a job (or to please their parents or to figure out what to do or to get a husband/wife or many other motivations).
So you're saying that, in your experience, all languages have similar power? Or at the very least that programmer skill and motivation is far more important language choice. That doesn't jibe with my experience at all. I have learnt many languages and I find that using them idiomatically gives benefits in their specific areas of expertise. I also find myself missing more things in some languages than others.
Now, I don't think Lisp is necessarily the solution, but I think Paul has a point with his Blub paradox -- I have seen this argument from many people who are used to their tools. You say 'but, I can do X and Y with Blub'. They say 'but I can do the same thing in Excel'. Or VB or C or whatever. Because of the whole Turing completeness mess, you can pretty much do anything in any halfway decent language. What isn't clear from Turing completeness (and actually, one of the reasons for developing Turing tarpits like brainfuck) is that Turing completeness doesn't guarantee usability and language power. And that's what it's all about.
BTW: comparing Lisp with Brainfuck is a really low blow. You need to distinguish between esoteric languages that were often designed to be hard to use (intercal, brainfuck, etc) and languages that were designed to be easy to use or powerful, but just haven't become popular (Lisp, Haskell, etc).
Unfortunately, Haskell lacks good syntax for vector/matrix operations (by good I mean something that remotely resembles the formulas I have in my text book) and no clear way to create it. The infix operations are easy to make, but the slicing and the conditional assignments are very hard. And, let's face it, if you're doing numeric work, most of your problems are matrices and vectors.
There is definitely a feeling of expressiveness being similar to practical power in languages. I think Paul Graham summed it up well here: http://www.paulgraham.com/avg.html
For numeric work, it has a really well thought-out syntax, that is part of the language. For instance, you can assign parts of arrays to one another with slicing like in Matlab or Python, but with some additional good bits that automatically parallelise. I have looked far and wide, but I have not found anything in the c++/java world with as much expressive power for matrix and array based problems.
Additionally, most of the choices in the language were made based on whether the features can be implemented efficiently. The fact that (for instance) fortran doesn't allow aliasing without notification makes it easier for compilers to optimize certain constructs. Keywords like pure (guarantees that a function is side-effect free) allow even more optimizion. You can also specify a function as elemental, which allows it to be mapped over the elements of an array automatically.
For me, Fortran is more of a domain specific language. Modern fortran code resembles Matlab in many ways, but outperforms c/c++ with very little trouble. You can usually get similar (or even a bit better) performance from c/c++ but not without jumping through some pretty interesting hoops.
I can vouch for the fact that begin able to do 64 bit IEEE double precision math natively (instead of having to restate all your double precision work as single precision) translates to roughly 2x speedup* on my programs (which are CPU limited). It depends what you are doing, but for my work 64 bit is definitely twice as fast as 32 bit. If your work is memory or disk limited, going to 64 bit won't do much at all.
* On a 32 bit system, changing all your doubles to singles and doing the same calcs with less precision is about twice as fast. On a 64 bit system, it makes no difference, as the FPU is using 64 bits anyway.
Slashdot Mirror
Of course, intuition is not the same for everyone. I find object-oriented languages 'painfully counterintuitive', but I have the good sense to realise that it's working for many people and it may be my personal experience (or lack thereof) that is making the process painful, rather than the actual technology.
Actually, C is a prime example of a weakly/statically typed language. The existence of a void pointer (or, actually, values in memory that are not tagged as being of a particular type) means that any piece of memory could be accessed as though it was any type. I could, for instance create an integer variable and a string variable pointing to the same piece of memory in C. This is weak typing. If there was a mechanism that explicitly forbade me from accessing a piece of memory which has been marked as 'type A' as 'type B', we have strong typing. If this can be enforced at compile time, we have static typing. Automatic type conversion does not really require weak typing if the coercion rules are well defined.
I'm sorry, "the horror of ... python..."? Where did that come from? Wait, let me guess, the language would be great if it had "ends"" or, even better, used braces to delimit blocks.
I'm surprised that no-one has posted a link to Easy Java Siimulations yet. This allows you to get your hands on the equations more.
In my experience trying to do the same at our university, Matlab's performance is a fair bit better than Python's, except on the stuff that's handled by LAPACK, when the performance is about the same. Newer versions of Matlab also have pretty good support for multicore/parallel programming that's easy to set up. I've never heard of anyone experiencing a speedup when moving to Python, although I agree it's a really nice language.
As an aside, when you really want some good performance bits, f2py is really good and newer Fortran is almost exactly like Matlab, just compiled with really efficient compilers (this is how I solve my performance problems in Python).
The reason why languages that choose to use typed _value_ instead of typed _variables_ (like python) are rarely compiled is because it is either infeasably difficult (even in the case of code where everything's known up front) or impossible (in the case of programs that read from files and so on) to determine what type a value will have until you run the program. This means that even if we were to compile the python program, it would effectively require the python interpreter in its runtime to operate in the same way. This is what compiled Lisps do.
Regarding what defines a scripting language, there's no generally agreed-upon definition. Typically it involves the language being interpreted, loosely or dynamically typed and having a standard library/modules that make operations in a certain field (like text processing, dom navigation, etc) easy.
And about Java performance: There is building support for Java vms (with hotspot optimisation and disregarding startup times for the server) running code being in the same order of magnitude as things like gcc, while the interpreted languages are by conventional wisdom about an order of magnitude slower (see the alioth shootout).
I have honestly tried Eclipse and Netbeans for my programming, but the learning curve is just way too high. When I started using Emacs, I could do what I wanted almost instantly (open a text file and start editing it). To just open a file in Eclipse, edit it and compile it seems impossible. You need to get the correct plugins for the filetype you have chosen (and I am using many types of files). Then, you need to create a project, figure out what workspace this is supposed to be in. I suppose if I didn't already have tons of projects organised into a nice directory structure -- if Eclipse was my first experience with programming and I could just create new projects in the default workspace -- it would be a little easier, but the existing code adds a bit of inertia to my development style.
I posted a question that got some airtime on Slashdot about IDE support for multi-language projects. The studio-style apps seem to be built around the idea that you will be using a single language for the whole project. This is not bad as far as it goes, but your existing codebase is Python, C, C++ and Fortran with lots of shell scripting, m4, awk, sed and Makefiles in between, the studio stule stuff doesn't cut it. Not to mention, that even when I'm working on a large project in one language (which Ecipse does well), I may want to open a text file of some other kind (XML, CSV, whatever) and Eclipse doesn't make it easy in the same way that emacs does. I also can't fire up Eclipse from the terminal to edit a file from home via ssh. And I haven't found a text editor that does indenting the way I have grown to love -- by hitting tab anywhere and having the indentation done right.
Now, I know all the arguments for IDEs, and I have really tried, but I think many people are like me in using Emacs because they are (or at least feel) more productive in it on their codebase. The underlying mindsets are just so different that it's really hard to get going in IDEs.
Just use auto-wrap on 75 chars. This makes it much easier to find the bug that LaTeX is complaining about. The long lines are the first thing I change when I inherit files.
The long lines also make change tracking that much harder, as most tools only go down to line granularity.
Ya know, for a guy who worked in a Patent office, Albert really missed out on stunning opportunity on royalties on general relativity. I'm pretty sure most countries have exemptions on copyright and patents for mathematical formulae. Mine (South Africa) sure does, and so does America
No need to recode from the IAPWS standards (I've done it, but those equations are huge and a pain to type and debug). Just go use http://freesteam.sourceforge.net/
Yes, sorry -- clicked on the wrong link, and there's no way to delete a comment.
Original quote by George Bernard Shaw:
"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
At least add some attribution (the original quote was by George Bernard Shaw)
Gotta have functions because expecting all programmers to know how to copy and paste large chunks of code when they use them isn't unfair to those who haven't gained those skills yet.
When I'm programming, certain things set off red flags. If I see myself doing something similar many times, I extract that stuff into a function if "the thing" is parameterised by values. If it's parameterised in terms of types, I use a template, if there's obvious structure, I use a class. If it's small and gets done a lot, I use a loop. These structures are things that are not technically necessary for programming, but each mechanism cuts down on redundancy and reduces the chance of errors by having to remember where all the changes are. In addition, reducing the boilerplate makes it easier to see the structure in the program.
The auto variable is an example of type inference, and the fact that C/C++ doesn't have it is really a nuisance once one has gotten used to languages with more powerful type systems like Haskell.
So, if you're good with powertools you can be safe without guards, eye protection and hearing protection? I suppose you think that all the buffer overflow and memory leak problems we've seen in high quality software is because the programmers are no good. Nobody claims absolutes, but language features that make it easy to do the right thing make it more likely that people will do the right thing. Language features that allow you to do something that is likely to cause problems increase the risk that these problems will occur. That's just basic probability.
I can tell you that I have had to debug off-by-one errors in Fortran and C (where no range checking is done, so you can easily end up modifying the next variable in memory rather than the last element of your array), but never in something like Matlab or Python where range checking is done. Now, that may make me a bad programmer, but show me the programmer who has never made a typo.
I hear that -- I just got two new LG LCDs and the blue power lights are incredibly bright and aimed forward, so I had to cover them with a piece of tape. I don't see how this could get past testing.
I suppose curving would fix this, but I am in South Africa, where you get the mark you obtained on the test, full stop.
Regarding the types of students that do well in my subjects -- yes, different people did well. Students that were used to acing subjects weren't doing well using their standard techniques and students that actually attempted to "get" it were doing quite well. Unfortunately the typical makeup of my classes meant that this gave me far lower marks on average than many other classes.
I'm still doing what I do -- just remember my original post was about how the average student can drive behaviour that is bad for the top fraction.
Of course I agree that one should have unpredictable tests. However, most of my students did not thank me for giving them a more valuable learning experience.
I have grappled with this problem myself. I am a lecturer at a university (chemical engineering) and I taught our introductory programming course using Matlab. I believe that it's crazy to have tests on programming where you don't have references or a computer with you, so I set alll my tests as open book, with computers in front of the students. I gave many small assignments throughout the semester and one large assignment at the end. The students uniformly hated the subject. Some of their concerns were that the tests were "too unpredictable."
You can't blame faculty alone for courses being the way they are -- the students have learnt how to play the game. You work many old papers and basically end up memorising the classes of problems that can be asked. This behaviour leads to a sort of conundrum: if you keep setting new and interesting papers, you will start running out of problems that are within a certain difficulty level. Your students will hate you because they can't prepare for your tests they way they are used to. If you set similar papers (or recycle papers) the first-time difficulty of each paper remains the same, but the apparent difficulty of your subject decreases because your subject is easily gamed by people not interested in mastering the subject but rather passing your tests.
From the educator's perspective, testing is hard in computer-based subjects because a realistic test (like a project) is trivially easy to copy and testing within a realistic timeframe restricts you to such simple problems that you run into the problem above. There therefore didacticly valid reasons for wanting to keep the answers to problem sets a secret: there are less students with the self control of using the answers as a solid teaching aid than there are who will use them as a quick shortcut to doing the assignments, just like there are fewer students who can manage their time to meet a single deadline than students who need frequent deadlines to make sure that they stay up to date. Pretending that the students are all just there to maximise their mastery of the subject is unrealistic. Most students are doing courses to get the magic paper that will give them a job (or to please their parents or to figure out what to do or to get a husband/wife or many other motivations).
So you're saying that, in your experience, all languages have similar power? Or at the very least that programmer skill and motivation is far more important language choice. That doesn't jibe with my experience at all. I have learnt many languages and I find that using them idiomatically gives benefits in their specific areas of expertise. I also find myself missing more things in some languages than others.
Now, I don't think Lisp is necessarily the solution, but I think Paul has a point with his Blub paradox -- I have seen this argument from many people who are used to their tools. You say 'but, I can do X and Y with Blub'. They say 'but I can do the same thing in Excel'. Or VB or C or whatever. Because of the whole Turing completeness mess, you can pretty much do anything in any halfway decent language. What isn't clear from Turing completeness (and actually, one of the reasons for developing Turing tarpits like brainfuck) is that Turing completeness doesn't guarantee usability and language power. And that's what it's all about.
BTW: comparing Lisp with Brainfuck is a really low blow. You need to distinguish between esoteric languages that were often designed to be hard to use (intercal, brainfuck, etc) and languages that were designed to be easy to use or powerful, but just haven't become popular (Lisp, Haskell, etc).
Unfortunately, Haskell lacks good syntax for vector/matrix operations (by good I mean something that remotely resembles the formulas I have in my text book) and no clear way to create it. The infix operations are easy to make, but the slicing and the conditional assignments are very hard. And, let's face it, if you're doing numeric work, most of your problems are matrices and vectors.
There is definitely a feeling of expressiveness being similar to practical power in languages. I think Paul Graham summed it up well here: http://www.paulgraham.com/avg.html
For numeric work, it has a really well thought-out syntax, that is part of the language. For instance, you can assign parts of arrays to one another with slicing like in Matlab or Python, but with some additional good bits that automatically parallelise. I have looked far and wide, but I have not found anything in the c++/java world with as much expressive power for matrix and array based problems.
Additionally, most of the choices in the language were made based on whether the features can be implemented efficiently. The fact that (for instance) fortran doesn't allow aliasing without notification makes it easier for compilers to optimize certain constructs. Keywords like pure (guarantees that a function is side-effect free) allow even more optimizion. You can also specify a function as elemental, which allows it to be mapped over the elements of an array automatically.
For me, Fortran is more of a domain specific language. Modern fortran code resembles Matlab in many ways, but outperforms c/c++ with very little trouble. You can usually get similar (or even a bit better) performance from c/c++ but not without jumping through some pretty interesting hoops.
I can vouch for the fact that begin able to do 64 bit IEEE double precision math natively (instead of having to restate all your double precision work as single precision) translates to roughly 2x speedup* on my programs (which are CPU limited). It depends what you are doing, but for my work 64 bit is definitely twice as fast as 32 bit. If your work is memory or disk limited, going to 64 bit won't do much at all.
* On a 32 bit system, changing all your doubles to singles and doing the same calcs with less precision is about twice as fast. On a 64 bit system, it makes no difference, as the FPU is using 64 bits anyway.
Well, actually, unix definitely predates pbs (developed in the early to mid 1990s) by about 30 years.