I could see an alternative design approach that beats Apple's focused on simplicity and ergonomics. Even all black and white only.

When I look at something, I don't want to be distracted by the things that might linger underneath, I'd like the system to support my attempt to focus.

The original Mac combined simplicity and "human-friendliness" (e.g., round corners) with a systematic UX (apart from menus, which should have been attached to app-controlled windows from the beginning instead of changing in appearance upon selecting different apps).

Apple lost its simplicity and systematic UX several years ago. Now we have menus called "+" or "...." and despite having a Ph.D. in computer science and having used computers for many decades I have no idea whether to find a function in the former, in the latter, or elsewhere, because the system lacks self-documentation and discoverability.

The Thomson Reuters Foundation has deployed itsnew Emergency Information Service (EIS) to Haiti. An experienced team of Foundation journalists was sent to the country on Wednesday with the goal of seeking out, collating and disseminating life-saving information to the people.

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.