programmierer-nachrichten.de
Startseite Podcast RSS Impressum

Podcast Folge 13


Wie versprochen der wöchentliche Podcast!

Dieses Mal Folge 13. Windows Bash/WSL nun auch mit openSUSE und Fedora, Visual Studio 2017 für macOS, was mit Perl 6 passierte und die Mehrheit gegen das Java 9 Modulsystem.

Viel Spaß damit!


Windows Bash/WSL nun auch mit openSUSE und Fedora


Es gibt ja seit einiger Zeit die Möglichkeit bei Windows 10 Bash/WSL in den Software Features zu aktivieren. WSL, das ist dieses Paket, welches ein komplettes Linux Subsystem unter Windows 10 installiert. Und das ist nicht einfach nur emuliert, sondern es wurde viel Aufwand getrieben, um Systemcalls von Linux in Windows zu übersetzen. Wenn es keine passenden Funktionalitäten gibt, wird es neu gebaut oder was auch immer. Ich benutze es seit Anfang an und bin relativ zufrieden, aber es hat auch extrem viele Bugs, die so verrückt sind, dass man es sich mehrmals überlegt, ob das überhaupt eine gute Idee ist. Seit dem Windows 10 Creators Update zeigt "du -sh" zum Beispiel, dass Ordner mehrere TeraByte groß sind, obwohl sie nur wenige hundert MegaByte groß sind. Sehr "komisch".

Bis zum Windows 10 Creators Update wurden die Linuxbinaries und Tools von Canonical bereitgestellt. Man hatte am Ende ein Ubuntu 14.04 LTS unter Windows. Mit dem Creators Update hat man Zugriff auf Ubuntu 16.04 LTS.

Nun hat Microsoft aber weitere Partner ins Boot geholt. So wird es in der Zukunft möglich sein Bash/WSL unter Windows mit openSUSE oder Fedora zu betreiben. Ich bin tatsächlich sehr gespannt, da Microsoft einiges aufzuholen hat. Jetzt, wo Apple den Desktop Power User aufgegeben hat, hat Microsoft eine gute Chance sich einige User zu krallen. Und mich haben sie eh zurück, da ich Linux auf dem Desktop ja nicht mehr so mag. Ich nutze es seit Anfang 2000 auf dem Desktop und jetzt, 2017, gibt es die exakt gleichen Probleme.

Linux auf dem Server? Ja, unbedingt! Auf dem Desktop? Nein danke. Aber mit Bash/WSL könnte man fast sagen, dass das Jahr 2017 tatsächlich das Jahr für Linux sein könnte. Für Programmierer ist dieses Feature auf jeden Fall sehr interessant und extrem praktisch.


Visual Studio 2017 für macOS


Nun, da verwirrt Microsoft aber die Benutzer etwas. Microsoft hat Visual Studio 2017 für macOS veröffentlicht, aber so ganz stimmt das nicht. Visual Studio 2017 für macOS basiert auf Xamarin Studio. Du erinnerst dich, dass Microsoft die Firma Xamarin gekauft hat.

Es handelt sich hier also nicht um _das_ Visual Studio, welches man von Microsoft Windows kennt, sondern um eine weiterentwickelte Version von Xamarin Studio. Gut zu wissen oder?

Sehr viele Features aus dem echten Visual Studio 2017 fehlen. Die Variante für macOS ist eindeutig auf C# fokussiert. Das macht aber auch nichts. Nur die Namensgebung ist, Microsoft typisch, unglücklich. Ich werde diese Firma einfach nie verstehen.


Was ist mit Perl 6 passiert?


Es ist schon erschreckend wie gut ich mich mit Perl 5 auskenne, aber es ist auch nicht verwunderlich, denn immer wieder musste ich mit Perl auseinandersetzen. Das fing schon mit dem Praktikum bei WebControl in Erkrath (jetzt Düsseldorf) an. Da musste ich ein altes Perl-Script vom Chef refaktorieren. Das war sehr gruselig. Aber es zwang mich dazu Perl zu lernen. Zumindest habe ich die Grundlagen von Perl 5 gelernt und etwas gebaut. Ob das gut war, kann ich nicht mehr genau sagen. Ich habe Bind Zonefiles generiert und das war schon spannend genug :D...Ich hatte mich letztendlich an einem Storage verhoben, musste an der Leiste operiert werden und allgemein war die Stimmung nicht gut. Der Chef glaubte an mich, aber ich war jung und unerfahren. Für mich waren Menschen mit weniger Kenntnis unwürdig. Das habe ich die Menschen auch spüren lassen. Kurz: ich war a-sozial. Zum Glück hat mich mein aktueller Arbeitgeber geheilt. Da hatte ich quasi gelernt, dass es kein "perfekt" gibt :D...

Perl 5 ist nicht so schlecht, wie man immer sagt. Ich hatte irgendwann meine Abschlussarbeit geschrieben und für das Abschlussprojekt hatte ich Perl gewählt. Total verrückt oder? Nicht ganz. Ich war zu der Zeit voll im Thema. Ich hatte mich intensiv mit Moose, dem postmodernen Objektsystem für Perl, auseinandergesetzt. Das finde ich auch heute noch sehr gut. Ich hatte zu der Zeit auch ein eigenes Web Framework entwickelt, aber ok...das vergessen wir lieber.

Perl 5 mit Moose kombiniert ist auch heute noch extrem elegant und, ich wiederhole mich, extrem wartbar und ich wiederhole mich erneut, extrem bewertbar. Moose ist so beliebt, dass es Alternativen zu Moose gibt, die nur das Beste aus Moose extrahiert haben. Moose ist nämlich nicht ganz so "leicht". Mit "mod_perl" ist das sogar ab einer bestimmten Last fehleranfällig :). Das ist aber eher ein Problem von "mod_perl".

Aber seit ich Perl 5 kenne, kenne ich auch Perl 6. Also "kennen" ist übertrieben. Ich höre davon. Genutzt oder geschrieben hatte ich Perl 6 nie. Die Idee von Perl 6 gibt es seit dem Jahr 2000. Irgendwann kam ich dann auf die Idee Perl 6 lernen zu wollen. Das war bei Zeiten gar nicht so einfach. Es gab gefühlt zig verschiedene Laufzeitumgebungen, die Perl 6 ausführen konnten. Die eine war stabil, konnte aber keine Threads. Die andere war instabil, aber konnte Threads. Dann gab es was für die Java VM und Bla...sowas ist schon mal nicht gut. Gut, Perl 5 und Threads ist ja auch so eine Sache, also wäre das egal gewesen, aber dass es mehrere Laufzeitumgebungen gibt ist nicht gut. Wenn Adoption gewünscht ist, so sollte es von Anfang an konstistent sein.

Nun muss man der Community auch einen Grund geben von Perl 5 zu Perl 6 zu wechseln. Die Gründe mag es geben, aber sie sind nicht offensichtlich. Jeder, der sich mit Perl 5 auseinandersetzt, weiß, dass Perl 5 so schlecht nicht ist. Perl 5 ist außerhalb der Perl Community als "Hacker" Sprache bekannt. Schnell mal was hinrotzen. Das ist in vielen Fällen auch so, aber das Ökosystem von Perl ist erstaunlich stabil. Es gibt Cpan, ein Archiv mit wertvollen Perl Packages, welche man einfach mit "cpan" installieren kann. "cpan" ist Bestandteil von Perl 5.

Das war eines der ersten Dinge, die mich bei Perl 5 überraschte. Die Packages, die man über Cpan beziehen kann, sind alle außerordentlich gut getestet. Jedes Cpan Package hat zig "Unit"-Tests, die vor der Installation ausgeführt werden. Wenn die Tests nicht positiv durchlaufen, wird das Package nicht installiert. Das ist wirklich außerordentlich bei Cpan. Wenn man ein Package bei Cpan veröffentlichen möchte, ist man auch aufgefordert viele Richtlinien zu beachten. Es wird sehr viel Wert auf Qualität gelegt. Und das überrascht sicher einige, die mit Perl sonst nichts zu tun haben. Die Hürde ein Package bei Cpan zu veröffentlichen ist vergleichsweise hoch. Das ist gut.

Aber was ist nun mit Perl 6? Es gibt noch immer wenig Literatur. Die Adoption in der Community ist extrem gering. Niemand möchte Perl 6 nutzen. Die Probleme beginnen aber auch schon auf der Perl6 Website. Man soll Rakudo runterladen... Meeh! Perl 6 braucht wirklich besseres Marketing und man sollte das Ding nicht Rakudo nennen. Mit "Perl 6" hat es doch schon einen Namen. Und dass Perl 6 inkompatibel zu Perl 5 ist, ist auch unglücklich. Es gibt zwar ein Modul, womit man Perl 5 Packages benutzen kann, aber wenn man sich Perl 6 anschaut, so sieht man, dass es zwar vieles Neues gibt, aber Vieles ist auch so geblieben und nur gering angepasst worden. Mit Moose in Perl 5 hat man auch viel verändert, ohne Perl 5 zu verändern. Aber meine Meinung ist irrelevant, da ich Perl 6 zu schlecht kenne und das ist nicht nur mein persönliches Problem, sondern das eigentliche Problem von Perl 6. Niemand kennt es.

Mein Vorschlag: Perl 6 verwerfen.

Macht ein Perl 7, was mit Perl 5 Code klar kommt und Moose out of the box beinhaltet; von mir aus auch den Kram aus Perl 6. Und bitte trennt euch von diesem Rakudo Namen. Jeder ist von diesem Namen verwirrt. Das muss Perl 7 heißen. Oder wie auch immer. Die Perl 5 Community ist noch heute extrem groß. Die Perl 5 Community hat noch heute eine extrem gute Perl 5 Distribution, ein extrem umfangreiches Archiv an Packages aus Cpan und keinerlei Probleme modernen Code auch in Perl 5 zu schreiben; wenn auch mit Hilfe von weiteren Packages wie Moose.

Wenn sich das nicht ändert, wird Perl 6 nie was werden. Perl 5 wird ewig leben. Es sollte jemand ein aktuelles Buch über Perl 6 schreiben und es sollte jemanden geben, der es vielen Perl 5 Entwicklern zeigt. Aber ich vermute, dass die meisten Perl Entwickler eben nur "Hacker" sind, die kleine Scripte hinrotzen. Wir werden sehen! :)


Mehrheit gegen das Java 9 Modulsystem


Schon vor einigen Wochen hatten IBM als auch Redhat gegen das neue Modulsystem in Java 9 gewettert und offen ihre Bedenken geäußert. Zu dieser Zeit war diese Information für mich wertlos, da ich davon ausgegangen bin, dass die Mehrheit für das neue Modulsystem stimmen wird.

Aber es ist anders gekommen als erwartet. Ich war selber sehr überrascht, dass auf einmal die Mehrheit der Teilnehmer gegen das neue Java 9 Modulsystem gestimmt hatte. Das ist heute die Nachricht des Tages!

Aber es ist nicht so aufregend, wie es derzeit berichtet wird. Alle Teilnehmer, die dagegen gestimmt haben, äußerten auch Verbesserungen. Es ist also davon auszugehen, dass das neue Java 9 Modulsystem trotzdem implementiert werden wird.

Man muss sich auch vor Augen führen, dass große Änderungen oft ungerne angenommen werden, weil bestehende Software geändert werden müsste, um kompatibel zu bleiben. Da IBM als auch Redhat die wichtigsten Applikationsserver implementieren und betreuen, sind diese beiden Stimmen sehr gewichtig und beeinflussen natürlich auch andere Firmen. In diesem Fall gibt es von diesen Firmen eigene Ansätze für die Modularität, die sie natürlich ungerne aufgeben möchten.

Ich hoffe, dass sich alle Teilnehmer einig werden, denn grundsätzlich ist Java eine gute Sprache mit gutem Ökosystem.


Archiv nach Kalenderwochen


2017/KW24, 2017/KW23, 2017/KW22, 2017/KW21, 2017/KW20, 2017/KW19, 2017/KW18, 2017/KW17, 2017/KW16, 2017/KW15, 2017/KW14, 2017/KW13, 2017/KW12, 2017/KW11, 2017/KW10, 2017/KW9, 2017/KW8, 2017/KW7


Startseite Podcast RSS Impressum