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.