Skip to content

Latest commit

 

History

History
76 lines (40 loc) · 11.5 KB

File metadata and controls

76 lines (40 loc) · 11.5 KB

Metadaten

Verglichene Sprachen: Java, Javascript/Typescript Seniorität: Junior Domäne: Web-Applikationen, Mobile Apps

Transkript

I: Kurz zu Anfang, mit welchen Programmiersprachen hast du schon länger gearbeitet

B: Javascript, Typescript, Java, Objektive-C, Actionscript

I: Was waren das dann für Applications Domains,

B: Webanwendungen und Mobile-Apps, Also erst 2 Jahre mobile Apps und die restlichen 3 Jahre Webapps

I: Im nächsten Schritt gehts darum mal zwei Sprachen direkt zu vergleichen, Hast du ein Vorschlag welche sich da anbieten. die vielleicht aus der letzten Zeit sind wo du einen guten Vergleich ziehen kannst.

B: Das woran ich gerade arbeite. Also Javascript, Typescript und Java.

I: Meinst du Javascript und Typescript kann man zusammenfassen

B: (überlegt) ja

I: Ok dann würde ich sagen vergleichen wir Javascript/Typescript mit Java. Welch der beiden Sprachen würdest du so direkt als deine Lieblingssprache bezeichnen?

B: Typescript

I: Und woran würdest du das festmachen. Welche Faktoren spielen da für dich eine Rolle

B: Zum einen, Typescript hat halt beide Welten. Also Javascript das dir sehr viele Freiheiten lässt, also zum Beispiel das du die Prototypes ändern kannst von den Javascript Objekten was man natürlich nicht so oft macht, aber als Beispiel jetzt. man kann wenn man will auch den hackigeren Stuff ziemlich gut nutzen und auch ziemlich schnell. Und mit Typescript gibt es halt diese Fehlende Typisierung oben drauf die ja nicht viel weniger mächtig ist wie die von Java weil Typescript ist statisch getypted und das Java typsystem geht ja auch zur Runtime verloren. Also ja das ist für mich der Vorteil davon das man halt zum einen den etwas lockeren prototypen haftigen Sprachstil hat und sie sind auch moderner. Also Java ist ja schon ein bisschen älter. Typescript ist moderner und man merkt auch das da einige KOnzepte sind die ein bisschen mehr können. Zum Beispiel können Typescript generics sehr viel. Und die Sprache entwickelt sich auch ständig weiter. Annotations kommen auch jetzt dazu, Class decorators, damit hab ich auch schon ein bisschen rumexperimentiert. Und ja es funktioniert einfach alles sehr schön und es gibt sehr viel Support.

I: DU meistes gerade das es sehr viel Support gibt. meinst du damit konkret die Community oder die die Sprache vorrantreiben und entwickeln.

B: Naja allgemein die ganze Community drum herum. Man hat sehr viele Packages, sehr viele Tool, Zum Beispiel mit Node.js auch die Möglichkeit Javascript auf Serverseite zu rendern. Und da entwickelt sich sehr viel. Der Nachteil ist das es vielleicht ein wenig unübersichtlich ist wenn man nicht so drin steckt. ist nicht so Anfängerfreundlich.

I: Wie würdest du das nochmal konkret im Vergleich mit Java sehen.

B: (überlegt) Da muss ich bisschen drüber nachdenken. Also die Community ist in Java auch super. Mein Nachteil ist das der Teil den ich richtig Super finde, nähmlich Spring auf meiner Arbeit keine Relevanz hat. Dementsprechend hat Java da natürlich einen Nachteil. Es hängt auch ein bisschen damit zusammen, dass ich gerne mit Gui arbeite und Javascript ist halt mehr Gui orientiert, meistens.

I: Wenn wir mal den Punkt Modularisierung anschaut, würdest du da unterschiede feststellen.

B: In wiefern. Wie die Sprachen aufgebaut sind. die Strukturierung oder? Oder in welcher Sprache es sich leichter modularisieren lässt?

I: Genau

B: Ah ok. ICh finde es kommt ganz stark mit darauf an (überlegt) also Typescript und Java im sinne der Typisierung ermöglichen schon gleichmächtige Konstrukte der Modularisierung. ICh finde Modularisierung hängt vor allen Dingen vom Programmierer ab und weniger von der Sprache. Bei Javascript wäre halt der Nachteil das bei großen Projekten das wenn es nichtmehr Typisiert ist man irgendwann den Überblick verliert und es schwerer ist im Team zu arbeiten. Aber ich seh da jetzt keine Unterscheide warum das eine einfacher sein sollte zu Modularisieren sollte als das andere. Vielleich bei Java, du kannst mit Reflection noch ein paar Sachen machen für abstrakte Konstrukte die vielleiche in Typescript und Javascript nicht so schön zu haben sind. Vielleicht auch zu haben aber nicht so schön. Zum Beispiel wenn man sich das Spring Framework anschaut, da gibt es schon schöne sachen. Ich hätte jetzt fast Lombock gesagt, aber das ist ein schlechtes Beispiel weil Lombock auf dem Heap basiert.

I: Kommen wir nochmal auf die Syntax, fallen dir da unterschiede auf? Sachen die dir da in die eine oder ander Richtung besser gefallen

B: DIe sind halt sehr sehr ähnlich, sind beide Objektorientiert.

I: Ok gut dann nicht.

B: Wir können sonst nochmal Objektiv-C und Java vergleichen.

I: Ja vielleicht erstmal noch ne andere Frage. Hattest du schonmal ein Problem in der einen Sprache das du nicht lösen konntest wo du in der anderen genau gewusst hättest wie es funktioniert?

B: (überlegt) Meinst du Architektur oder funktionell. Also so Strukturell

I: Ja genau

B: Ja, ich muss mal kurz überlegen. Zum Beispiel das Factory Pattern über Klassen. Also wenn du sagt Create New und dann übergibst du ne Klasse und die richtige Klasse wird zurückgegeben.Lässt sich das darauf anweden. Es gibt zum Beispiel so einen Unterschied. Bei Typescript gibt es Interfaces wie bei Java, und es gibt auch Klassen und Interfaces könne Plain Objects sein und bei Plain Objects hast du halt keinen Prototype mit dran, keine Klasseninformationen und du möchtest jetzt zum Beispiel den Konsturktur finden (...). Das ist nicht immer erstsichtlich für jemand dritten der Kommt. Weil du hast irgendeine Library geschrieben und er wundert sich jetzt warum funktionert das nicht wenn du ein Plain Object reinsteckt. Sowas funktioniert in Java halt besser. Da gibts keine Plain Objects sondern nur Klassen und da hast du das Problem erst garnicht. Und andersrum genauso Problematisch. Ich serializiere etwas in einem String da aber gehen Funktionen verloren weil die werden nicht mitserializiert. Da fände ich es auch schön wenn man dem Anwender sagen könnte, du darfst hier jetzt nur Plain objects benutzten. Das fände ich schön wenn es da irgendwas geben würde. Ich hatte mal versucht über die Generics die Typescript da anbietet was zu basteln und das Problem ist das du keine rekursiven Generics machen kannst. Du hast eine recht mächtige aber etwas schwierig zu verstehende Generics Syntax mit wirklich Fallunterscheidungen in den Generics, Oder und so. DU darfst dich aber nicht selbst aufrufen. (...)

I: Du hast jetzt zwischenzeitlich mal dieses Thema angeschprochen: Zusammenarbeit in Teams. Würdest du da einen Unterschied sehen zwischen den Sprachen. Du meintest ja das es bei machen Sachen Typescript und Javascript es etwas schwieriger machen.

B: Ja des war jetzt ein sehr spezielles Beispiel. Schwierigda direkt weitere unterscheide zu finden (überlegt) Ich finde eher nicht ne. Das hängt wieder davon ab wie stark die Leute in der Sprache sind. Wenn du ein Team voller Javaentwickler hast und die sind nicht so versiert in Javascript/Typescript dann ist es natürlich schwieriger mit denen im Team zusammenzuarbeiten. Oder du arbeitest an der Gui die ja oft nicht so schön Modularsierbar oder Trennbar ist. Zumindest finde ich es schwieriger als irgendwie ein Backend aufzuteilen in irgendwelceh Einzelteile an denen je einer gut Arbeiten kann. Getrennt oder Simulatan paralell nebenbei. Hängt es wieder davon ab wie du die software strukturierst.(...) Vielleicht sollte ich nochmal überlegen was denn Sprachkonstrukte sind die zur Modularisierung beitragen. Ah ja da gibts noch was das ich manchmal bisschen nervig finde. Da Typescript ja aus Javascript entstanden ist und Javascript wird ja jetzt auch immer weiterentwickelt und es war ja immer eine sehr naive Sprache und die ECMA Script spezifikationen werden immer weiterentwickelt, gibt es jetzt in Typescript zwar Klassen aber Javascript teilt nicht in Klassen auf sondern immernoch in Dateien. Wenn du irgendwie ein Paket hast: eine Klasse ist eine Datei. Und in dieser Datei exportierst du dann Sachen, also das ist jetzt diese neue ECMA Script 6 spezifikation das du importieren und exportieren kannst, also das gibt man richtig an und es gibt einen Default Export und es gibt exports und dann kannst du aus den verschiedene Dateien die verschiedenen Bausteine importieren die du möchtest. Du kannst aber auch ohne Probleme Sachen außerhalb dieser Klasse definieren. Also du schreibst ne Klasse in die Datei rein, Also zum Beispiel eine "Apple" Objekt und irgendwelche static variablen die eigentlich zu diesem Objekt gehören definierst du außerhalb. Also irgendwelche Standartwerte. In Java bist du wirklich dazu gezwungen das in die Klasse zu schreiben. Das finde ich schöner. Ich hatte halt letztens den Fall da musste ich das so machen und dann hat jemand meinen Code Reviewed der aus der Java Welt kommt und hat mich dann gleich komisch angesprochen "Warum machst du denn das da". Das hatte dann in dem Fall einen technischen Grund. Aber ich seh es auch wenn ich mir gewisse Beispiele anschaue das die Stile teilweise sehr unterschiedlich sind. Also wenn man Javascript nimmt gibt es irgendwie fünf verschiedene Arten eine Klasse zu definieren über diese Prototypes. Es gibt ganz viele komische Sachen die man da machen kann. Das finde ich glaube ich finde ich doof. Gerade für Leute die das neu lernen da die dann schon verwirrt sind. Und wenn man im Team arbeitet muss man natürlich immer im Hinterkopf haben das ständig neue Leute kommen und die müssen eingearbeitet werden. Das wäre vielleicht noch ein Puntk der mir so einfällt. Das die Sprache eien nicht Zwingt einen Stil zu verwenden. Was natürlich bestimmt wieder Leute gut finden das sie da ihren eigenen Stil schon ausleben können wie sie möchten.

I: Ok vielleicht mal noch zu einem anderen Punkt. Bei der Auswahl deines jetzigen Jobs hat da die Sprache eine Rolle gespielt?

B: Eher nicht. Also ich wurde von meinem Arbeitgeber angesprochen. Aber ich denke für sie hat meine Vorerfahrung in der Sprache ne Rolle gespielt. Für mich eher weniger. Was mir nicht so gefallen hatte war Objektiv-C. Also da hätte ich Probleme gehabt wenn das damit gewesen wäre- Aber prinzipiell bin ich der Meinung jeder Programmierer kann in jeder Sprache produktiv arbeiten.Natürlich gibt es viel tiefes Wissen für jede Sprache und natürlich ist ein experte für ne Sprache ist unglaublich viel schneller als jemand der gerade erst Anfängt aber um wirklich produktiven Code herzustellen lassen sich viele Konzepte übertragen von der einen in die anderen Sprache. Deswegen finde ich es garnicht so schlimm wenn man sich mal an eine neue Sprache wagt.

I: Ok das heißt auch in Zukunft würde das für dich keine Übergeordnete Rolle spielen welche Technologien und Sprachen bei einem zukünftigen Arbeitgeber eingesetzt werden.

B: Garkeine Rolle würde ich nicht behaupten. Ich würde schon schon sagen das man sich wohler da fühlt was man schon kennt oder was man interessant findet. Vielleicht gibt es ja irgendeine neue Technologie die man interessant findet und die man unbedingt mal machen will die mich reizt sich bei einem anderen Unternehmen zu bewerben. Aber ich würde jetzt nichts gleich ausschleißen wegen der programmiersprache. Also es würde nicht super stark ins Gewicht fallen. Wenn es andere gute Gründe gibt bei einem Arbeitgeber sein zu wollen wäre die Sprache kein absolutes Hinderniss für mich. Wenn es natürlich noch passt mit den programmiersprachen, wenn es das ist wo ich eh schon Erfahrung hab ist es natürlich ein Vorteil.