Verschwörung der Produktmanager und Nerds - oder werde ich langsam zu alt?

[fanderlf]

@fanderif

Du findest wirklich, dass Python und Javascript sich so ähnlich sind? MMhh, das hab ich nie so gesehen - aber in gewisserweise natürlich grundsätzlich schon (kommt drauf an, welchen Maßstab man anlegt) . Ich find Python ist wunderbar 'aufgräumt' - hoffe du magst das Javascript hinterher auch noch

Ich denke das kommt einfach immer drauf an welche Aspekte einer Sprache man betrachtet. Ich mag es z.B. wenn ich einfach ein Objekt bauen kann und diesem Objekt Eigenschaften und Funktionen zur Laufzeit dazu kleben kann. Über Klammern, Semicolons, Tabs, Spaces usw. kann man mit Sicherheit Glaubenskriege führen, mir sind diese aber herzlich egal. Ich habe z.B. schon eine einigermaßen komplexe Seite in Javascript gebaut und diese war hinterher auch noch aufgeräumt. Das ist ja nur eine Sache der Strukturierung und eigentlich kein Feature der Programmiersprache. Ich denke nicht dass man in Python wesentlich mehr/weniger Möglichkeiten hat Komponenten zu strukturieren als in Javascript. Klar hat Javascript einige Klammern mehr und die nicht vorhandenen Lambdas sind auch nicht so schick, allerdings fand ich die Zeit in der ich die Seite programmiert habe wesentlich effizienter als dieselbe Zeit in C#.

Es mag auch daran liegen, dass ich Vererbung (im speziellen die Java/C# single inheritance) ganz ganz furchtbar finde und man in dynamischen Sprachen wesentlich besser Objekte zusammenbauen (Composition) kann.

[Ralf Jansen]

Klar hat Javascript einige Klammern mehr und die nicht vorhandenen Lambdas sind auch nicht so schick,

Syntactic Sugar. Als hörige Microsoft User benutzen wir doch sowieso Javascript nicht mehr direkt sondern schalten Typescript dazwischen

Typescript

Function f = (x: number) => x * x;

wird übersetzt zu

Function;
f = function (x) {
    return x * x;
};

Und die schicken Lambdas reichen ja wenn man die zur Designzeit hat.

[tömmel]

Naja - wenn man auf Klassen verzichtet mag sich das ja ähnlicher werden - python ist aber durch seine Module sehr mächtig (gibt ja praktisch nix was es nicht gibt oder nicht geht) - naja und dictionary & Co sind auch Gesellen, an die man sich gewöhnen kann. Nach meiner Erfahrung ist da aber schon ein gewisses Umdenken erforderlich.um das sinnvoll einzusetzen - und da fällt das switchen dann manchmal schwer...

[fanderlf]

Brrrrr ich mag sowas wie Typescript gar nicht. Ich find an den dynamischen Sprachen grad cool dass ich eben keinen Compiler oder son Kram mehr hab und einfach nur noch F5 im Browser drück und dann pack ich mir wieder son Teil dran. Nene... da bleib ich lieber bei purem Javascript. Glaub die neue ECMAScript Version hat sowieso schon eine Lambda Definition drin. Und bis dahin kann ich auch mit einfachen functions leben.

Ich verstehe auch den ganzen Hype um Coffeescript nicht.

@Tömmel: Dann schau Dir mal nodejs und die dazugehörigen Module an. Für Javascript gibts glaub ich auch nichts was es nicht gibt. Ausser nen Oracle Treiber für NodeJS der auch auf Windows funktioniert... das würde ich mir gerade wünschen Ja Javascript gibts mittlerweile auch auf dem Server :P

[tömmel]

Genau das mein ich ... - für mich neu...

Da beeinflussen sich schon verschiedene Dinge - und die Entscheidung auf was sich die Industrie am Ende stürzt und was untergeht schwingt irgendwie schon zwischen den Polen worin sich die Nerds verbeißen, und was hinterher den Segen der Bosse findet. Am ECMAScript hängen ja so einige.

Ob da aber immer was oder gar das Beste bei herauskommt ?

Nimm mal php - das ist auch so'n ding - auf jedem Wepspace läuft es traitionell - und das ist schon das Top- Argument....

Frage ist, ob jetzt z.B. Javascript sich dauerhaft tatsächlich auf dem Server etabliert... das weiss man in ein paar Jahren.

Falls nein - wieder Lebenszeit vergeudet....

Frage bleibt - ist das nur ie neue Sau, die durchs Dorf getrieben wird, oder bleibt da etwas übrig...

[Christian Marquardt]

Server-Sided-Javascript gibt es seit Mitte der 90er Jahre....

[Ralf Jansen]

Ich find an den dynamischen Sprachen grad cool dass ich eben keinen Compiler oder son Kram mehr hab und einfach nur noch F5 im Browser drück

Ja das man erst zur Laufzeit merkt das man Mist programmiert hat ist echt Klasse
Der Sinn von Typescript, Coffescript etc. ist ja nicht primär der schönere Syntax sondern der striktere Syntax. Javascript ist leider so gebaut das etwas falsch zu machen einfach ist und dann auch noch erst spät offensichtlich wird.

Frage ist, ob jetzt z.B. Javascript sich dauerhaft tatsächlich auf dem Server etabliert... das weiss man in ein paar Jahren.

Da es Leute gibt die Logik in eine Datenbank packen einfach weil man SQL beherscht wird es auch Leute geben die eine clientseitige Scriptsprache auf dem Server einsetzen einfach weil sie diese Sprache beherrschen. Das mag das falsche Tool sein und die Puristen ärgern (mich auch irgendwie) aber lieber das falsche Tool das man beherscht als das richtige Tool das man nicht beherscht.

[tömmel]

Ja das man erst zur Laufzeit merkt das man Mist programmiert hat ist echt Klasse
Der Sinn von Typescript, Coffescript etc. ist ja nicht primär der schönere Syntax sondern der striktere Syntax. Javascript ist leider so gebaut das etwas falsch zu machen einfach ist und dann auch noch erst spät offensichtlich wird.



Da es Leute gibt die Logik in eine Datenbank packen einfach weil man SQL beherscht wird es auch Leute geben die eine clientseitige Scriptsprache auf dem Server einsetzen einfach weil sie diese Sprache beherrschen. Das mag das falsche Tool sein und die Puristen ärgern (mich auch irgendwie) aber lieber das falsche Tool das man beherscht als das richtige Tool das man nicht beherscht.

Damit wir uns richtig verstehen: Soll jeder glücklich werden wie er meint - und etwas neues auzuprobieren ist ja nie verkehrt. Auch schillernde Vögel haben ihre Berechtigung...

Um aber zum eigentlichrn Thema:

..aber lieber das falsche Tool das man beherscht als das richtige Tool das man nicht beherscht

da steckt viel, ggf. unbeabsichtige Wahrheit drin:

Es ist doch oft ein selbstverstärkender Effekt - mit welchem Werkzeug wird ein Projekt begonnen?

Mit dem, von dem man meint am besten (billigsten) Resourcen angeboten zu bekommen - auf der anderen Seite sind die Leute gezwungen sich mit einer Sache auseinanderzusetzen, weil momentan verstärkt Projekte angestoßen werden.... So ergeben sich Kondensationskerne...

(Böse formuliert: Leute nehmt Scheiße, millionen Fliegen können nicht irren..)

Ob dabei dann aber immer das Optimum herauskommt?

[Ralf Jansen]

ggf. unbeabsichtige Wahrheit drin:

Entgegen meiner sonstigen Geflogenheiten war diese Aussage wirklich mal frei jeglicher Ironie.

[fanderlf]

Ich denke der wirklich große Vorteil bei Javascript liegt einfach darin dass es auf sämtlichen Devices verfügbar ist und somit zumindest für Client applikationen sehr gut geeignet ist. Geschäftskritische Anwendungen bei denen es am Ende noch um viel Geld geht würde ich wahrscheinlich auch nicht in Javascript schreiben.

Zum Thema Compiler:
Es ist war dass man bestimmte Fehler erst zur Laufzeit merkt, allerdings sollte man in egal welcher Sprache sowieso Unit Tests zu seinen Klassen packen die prüfen ob meine Klasse tatsächlich das tut was ich von ihr erwarte. Mache ich dort etwas kaputt, dann sollte sich das eigentlich sofort in den Unit Tests kenntlich machen. Dazu kommt noch dass in Javascript der Red green refactor loop wesentlich kürzer ist als in einem C# Projekt wo ich erst das komplette Projekt kompilieren muss um einen Test ausführen zu können. Gerade bei größeren Solutions kann das dann schon mal 30 Sekunden dauern. Extrem ineffektiv. Der kürzere TDD Loop sorgt natürlich auch dafür dass man Fehler die ein Compiler gefunden hätte auch relativ schnell findet, da man den Code im Browser extrem oft ausführt.
Dazu gibts auch noch den google closure compiler der bei syntax fehler auch einen compile fehler bringt

Ich denke aber auch dass kein Framework die absolut letzte Wahrheit ist. Javascript auf dem Server ist z.B. extrem ineffektiv bei Anwendungen die schwierige Berechnungen durchführen, da Javascript auch dort im Prinzip single threaded ist. Mehrere Cores werden noch supported, mehr Threads als Kerne geht aber nicht. Dafür eignet es sich sehr gut wenn man lange auf etwas warten muss (z.B. Zugriff auf Dateisystem/Datenbank...). .Net kann z.B. mittlerweile sehr sehr viel. Die Frameworks sind allerdings sehr schwergewichtig und nicht so klein und modular wie die Frameworks die es für Javascript gibt.

[tömmel]

Es ist war dass man bestimmte Fehler erst zur Laufzeit merkt, allerdings sollte man in egal welcher Sprache sowieso Unit Tests zu seinen Klassen packen die prüfen ob meine Klasse tatsächlich das tut was ich von ihr erwarte. Mache ich dort etwas kaputt, dann sollte sich das eigentlich sofort in den Unit Tests kenntlich machen.

Da gibt's noch einen einfachen 'Trick' - man wird von echten Meistern zwar gern belächelt - aber als 'Tütensuppenprogrammierer' fährt man garnicht so schlecht:

Wenn ich ein Framework oder eine Klassenbibliothek habe, die Funktionalitätbewährt zur Verfügung stellt, dann nutze ich das auch! Es bringt mir nichts, das Rad ständig neu zu erfinden - das ist unökonomisch und fehleranfällig - es doch wirklich so - viel Neuschnee gibt es ja nicht mehr....

[Ralf Jansen]

Umgekehrt wird leider auch ein Schuh draus. Ich habe schon mehrere Projekte scheitern (oder fast scheitern) sehen weil man Frameworks gewählt hat die Tolles können aber leider mehr Probleme lösen wollten als man eigentlich hatte aber einen trotzdem mit der Komplexität der anderen Probleme konfrontieren. Negativbeispiele - Spring(.Net) obwohl doch ein kleiner Service Locator reichen würde, Enterprise Library verwenden wenn man nur Exceptions loggen will, einen Enterprise Service Bus aufsetzen wo eine Message Queue reichen würde.

[fanderlf]

Ja da geb ich Dir vollkommen recht Ralf. Das ist auch das schöne an Javascript. Viele neuen Libraries sind sehr sehr klein. Das hat den Vorteil dass sie sich um genau ein Problem kümmern und sich andere Frameworks meist sehr leicht integrieren lassen. Bei so Monsterframeworks die alles können wollen, aber irgendwie doch nichts richtig machen ist das eher selten der Fall.
Und natürlich sollte ein Unit Test auch nicht den Code in 3rd Party Frameworks testen