It's a good idea to ask technical question to probe an applicant's knowledge, however it can be alienating if done wrongly (and I know a few companies who pursue it in a way that is unproductive). What I prefer is to ask applicants in what areas they are most proficient, and then zoom in to find out what they know in the areas. It should not be question-answer style but rather a casual conversation, where you make it clean why you ask what you ask and ideally let the candidate know why the question is relevant to the job he or she is applying for. That way, the applicant gets something back, namely feedback to what degree he or she covers the skills required. While I agree with previous posters that analytical problem solving skills (and also social skills like team ability and communications skills) are ultimately more important than knowledge, I do believe that there are minimal standards that everybody who has reached a certain level of education should accommodate. When you want to hire a developer for a new operating system and they can't name you a few different scheduling algorithms and their main property, those candidates would be ill-advised for hiring. However, don't ask them things that an experienced developer would look up on the Web anyway.

I guess a native call from FORTRAN will be faster.

Please avoid ad-hominem attacks, that's not fair regardless of your opinion.

When you buy SAP, you actually get the full ABAP source code of all the business logic, which is more openness than can be said for most businesses. Having said this it's not the same as open sourcing the software, as you need a commercial license to legally execute it.

> Some products were Windows only for a very long time, and the GUI still is for the most part. The Java GUI is multi-platform, but still missing stuff.

That's not quite the right perspective: it actually started out from a cross-platform position. When R/3 came out, it supported 15 platforms (e.g. most Unices), and only later did it become more and more Windows-dependent. Part of this was the desire to integrate SAP's R/3 GUI more closely with Microsoft Office.

I was with the SAP basis technology group at the time.

> The plus of teaching Python is that it's a badass OOP language with clean and simple syntax.

Not really. Last time I checked, client code using a class could modify local fields of all its instances, thus violating the tenet of encapsulation. You also have to explicitly pass "self" by hand each time.

See Section 10 of this reference, for instance.

I agree. Why teach them Python which is slow and doesn't have the libaries that FORTRAN 95 has?

Modern versions of FORTRAN don't have the odd reliance on source code formatting anymore that come from the punchcard era (although ironically Python relies on identation now).

I've taught graduate students FORTRAN 90 and they could pretty quickly implement matrix calculations, use imaginary numbers and I/O to solve the kind of problems they need to solve, often without prior programming experience. Science and engineering computations often require vast numerical throughput, and FORTRAN compilers are unrivalled at that (and have the best optimizers and parallelization support).

I'm not saying Python can't do the same, but change for change's sake is a pretty poor argument, and the existing huge FORTRAN libaries and code bases mean FORTRAN users truly stand on the shoulder of giants.