Java (alleine) macht dumm

...sagt Professor Robert Dewar: Who Killed the Software Engineer?

Universitäten, die nur auf Studentenzahlen schielen, statt auf fundierte Ausbildung, tendieren nach seiner Aussage dazu, die schwierigen Themen wegzulassen. Man würde eher Java/C# unterrichten und kein C/C++. Eher Grafikeffekte, als Algorithmen, eher Point and Click, als Commandline und Batchscripte.

Anscheinend gibt es inzwischen diplomierte Softwareingenieure, die nicht wissen was "Stack Overflow" bedeutet und was man dagegen tut. Wie wärs mit Studenten, die nicht wissen was ein Compiler macht oder sogar dass es einen gibt. Oder dass Algorithmen viel schneller sind, wenn sie in den Prozessorcache passen. Oder wie HTTP funktioniert und dass da TCP/IP und sogar Ethernet-Frames darunter und außenherum sind.

Und wenn das wirklich so ist, dann hat er Recht. Nur die schönen Seiten des Programmierens zu lehren ist sicher falsch. Wenn die Studenten nur highlevel lernen werden sie anständige Java-Coder oder Projektleiter, aber nie brilliante Softwareingenieure, die jedes Problem selbständig lösen, Projekte durchführen und nicht nur daran arbeiten.

Manche Leute meinen man muss die Matrix nicht kennen, um unsere Welt zu verstehen. Aber wenn was Komisches passiert ist es ziemlich nützlich zu wissen wie die Matrix funktioniert. Es gibt eben nicht nur Blue Pill, noch nicht.

_happy_coding()

Just commented Cory Ondrejkas blog

http://ondrejka.blogspot.com/2008/01/javascriptreplacejava-c.html#c9010177294114126155

I admire the Netscape people for choosing a prototype language. It just took 10 years for the world to learn how to use it correctly. Today I really wonder why we (me included) programmed such a crappy JS style for years, when everything was already there, just because we did not understand it. On the other hand, despite its beauty, it may be a mistake to design a language such that the world needs an eon to grok it. Slow interpreters mean only that no one put a billion $ into it, as they did for Java and C#. JS could be JITed as well.

I am a fan of PHP and I hate it. I am using PHP for large projects an I love its deterministic nature. Even on 100 web servers with memcache and mysql I understand completely what happens. A Java app server of this size produces more surprises.

The funny thing with Smarty templates is that everyone uses them, although they do not need them. Yes, you need a template engine. Separation of code and design, etc., but PHP IS A TEMPLATE ENGINE. Before you start learning Smarty-script, give this a try: http://phpsavant.com/docs/. Savant engine is not another template engine. It is just a wrapper for PHP's native template engine. You can easily build your own engine in a few hours. The Savant site explains it well. Smarty is only useful in the rare case that you do not trust your template writers. If you are the template writer, then you better use PHP as template script rather than learn another, that will be "compiled" into PHP. Speed: Smarty caching ends where PHP starts. That said, my C++ programmer heart cries comparing PHP/Apache/Linux to a C++ server. PHP speed ends where Java/C# start and they both end where C/C++ start.

Java is so 90s

Jahrelang kam man sich ja fast doof vor, noch C++ zu programmieren, weil in Java ja alles besser war. Aber es gibt Gleichgesinnte. Danke Slashdot.

Was hat uns eigentlich so gut an Java gefallen?
- Keine Pointer (nur Objektreferenzen, die null sein können, aha).
- Tolle Containerklassen dabei (bei C++ muss man STL nehmen, oder MFC oder wx oder ACE oder das selbstgebaute Framework, das eh jeder erwachsene Programmierer schon hatte).
- Kein delete, dafür Garbage Collector (schon toll im Normalfall, aber ich erinnere mich an Jigsaw Versionen, die nicht gingen, weil der GC buggy war).
- Threads ganz einfach, man muss nicht mal mehr wissen was in welchem Thread laeuft (fuers Protokoll, das ist Ironie. Wenn Programmierer nicht wissen wo was laeuft, dann sterben sie).
- JIT, eine gute Idee (um laaangsamen Code langsam zu machen).
- keine #defines und Templates (#defines, na ja, aber ohne Templates aus Containerklassen immer das Object hochcasten war schlicht beknackt).

Java war ein Schnellschuss. Die Marketingabteilung hat Goslings Spielzeugsystem breitgetreten, um die Welt mit Applets zu begluecken. Inzwischen kann man Java als Zwischenschritt auf dem Weg zu einem richtigen Framework betrachten. Manche nennen es Mono, andere .NET.

C#/NET hat genau die gleichen Features, wie Java. Eigentlich komisch, dass der GC bei .NET geht und der JIT lichtschnellen Code produziert. Ist MS besser, als Sun? Unwahrscheinlich. Die Konzepte waren in Java einfach noch nicht fertiggekocht. Die Programmierer haben sie zum 1., 2., 3. mal umgesetzt und noch nicht fertiggedacht. Bei .NET wurden die gleichen Konzepte zum 6., und 7. mal implementiert. Man hat Erfahrung gewonnen und aus Fehlern gelernt. Ein schoenes Beispiel fuer einen Software-Reifeprozess. Nicht nur Individualsoftware reift beim Kunden. Auch die Java Konzepte haben 8 Jahre lang bei Millionen Programmierern und Anwendern vor sich hingereift. Der Reifeprozess hat auch ergeben, dass #defines manchmal nötig und Templates doch praktisch sind.

Java musste einfach sein auf dem Weg. Da mussten wir durch. Jetzt sind wirs.

_happy_coding()