Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
mich hat mal interessiert, wieviel schneller C++ eigentlich gegenüber Java ist.
Dafür hab ich sowohl in C++ als auch Java ein kleines Mini-Programm geschrieben, das die Zahlen von 0 bis 9.999.999 mit Zeilenumbruch auf der Konsole ausgibt.
Wenn ich den Bytecode aus Java zeitgleich starte mit der exe aus C++, dann ist das Java-Programm erheblich schneller fertig.
Wie kann das sein? Ich dachte bisher immer, dass C++ das non-plus-ultra ist in Sachen Performance.
Dein Test, testet übrigens auch nicht die Sprache, sondern wie schnell es möglich ist Daten auf der Konsole auszugegeben, das hat nix direkt mit der Sprache zu tun. Sprich, das was du dort misst ist nicht die Performance des Programms, sondern die Performance der Konsole.
Grundsätzlich sind solche Messungen zwar eine nette Spielerei, aber in 99,99% der Fälle nicht praxisrelevant. Die Unterschiede zwischen den Sprachen sind so gering, dass das selten der entscheidende Faktor ist.
Schreib mal ein Programm das nicht anderes machst als ein sleep von 1s in C++ und in Java. Dann schreibst du ein Java Programm welches mit exec() erst das java und dann das c++ Program 100 mal started und mit wie lange die 100 Durchläuft dann dauern.
Ich denke das wird ein komplett anderes Ergebnis geben.
Schreib mal ein Programm das nicht anderes machst als ein sleep von 1s in C++ und in Java. Dann schreibst du ein Java Programm welches mit exec() erst das java und dann das c++ Program 100 mal started und mit wie lange die 100 Durchläuft dann dauern.
Ich denke das wird ein komplett anderes Ergebnis geben.
Das ist aber dann ja nur ein Check der Startzeit. Das ist weniger ein Java Thema sondern ein JVM Thema.
Ich will damit nicht sagen, dass es unwichtig ist oder uninteressant. Das kann sehr interessant sein. Das ist ja auch mit ein Grund, wieso man z.B. neben HotSpot auch die J9 JVM hat (Die soll schneller starten). Und dann ist natürlich auch GraalVM zu nennen als eine Option, direkt zu einer native Applikation zu kommen, was vermutlich auch die Startzeit positiv beeinflusst.
Wenn man schlechte Zeiten provozieren will, dann würde ich bei allen Konstrukten mit Garbage Colector schauen, wie man diesen herausfordern kann. Massig Objekte erzeugen, die direkt gelöscht werden können, ist zu einfach - da ist der GC sehr effektiv. Ich habe den Java GC nicht im Detail betrachtet, aber den vom .Net Framework habe ich mal tiefer im Detail angeschaut. Der arbeitet mit mehreren Generationen (0, 1 und 2) um da dann effektiv vor allem um jüngere Objekte durchzugehen. Da könnte man also auch überlegen, wie man etwas aufbauen kann, um dies stärker zu fordern.
Weiterhin ist hier dann die Hardware wichtig: Wie viele Threads können parallel laufen? Wie gut kann ich den Speicher auslasten? .Net arbeitet mit dem ganzen Arbeitsspeicher und hat keine begrenzte VM wie Java. Dadurch kann ich den Speicher nicht wirklich einfach so begrenzen. Aber schlechte Laufzeit bekommt man natürlich, wenn neue Instanzen in der Erzeugung erst einmal einen GC Lauf provozieren.
Und klar: Wenn ich nur 1 oder 2 Threads haben kann, dann schlägt jeder parallel laufende Thread massiv zu buche. Und da ist dann wichtig: Eine Java Applikation startet ja gleich mehrere Threads:
Java:
Set<Thread> threadSet
= Thread.getAllStackTraces().keySet();
System.out.println("Number of threads: " + threadSet.size());
for (Thread x : threadSet) {
System.out.println(x.getName());
}
[CODE title="Ausgabe mit AdoptOpenJDK 16.0.1 auf Windows 10 x64"]Number of threads: 8
Notification Thread
Monitor Ctrl-Break
Reference Handler
Signal Dispatcher
Common-Cleaner
Attach Listener
main
Finalizer[/CODE]
Es gibt deutliche Unterschiede, die man natürlich provozieren kann, wenn man unterschiedliche Laufzeitverhalten sehen möchte / provozieren möchte. Interessant ist dann vielleicht eher die Geschwindigkeit von Berechnungen und da dürfte es keine großen Unterschiede geben. Java hat den Overhead vom JIT Compiler, aber das fällt bei genügend Durchgängen beim Code nicht ins Gewicht.
Aber man darf auch nicht vergessen: Da wo die Unterschiede zu Tage treten, da ist das durchaus bewusst erkauft. Ich habe eine Funktionalität, die es auf der anderen Seite nicht gibt. Eine vereinfachte Programmierung ist schon einiges wert und hat sich eigentlich auch durchgesetzt in vielen Bereichen (wo es eben möglich war). Bei C++ muss man deutlich mehr beachten, auch wenn durch die letzten Standards, die veröffentlicht wurden, sich einiges getan hat. Aber da muss man auch nur Vergleiche anstellen, die z.B. bei C++ auftreten, wenn ein Entwickler dann zu oft den Copy Konstruktor bemüht statt Referenzen. Da kann es auch interessant sein, unterschiedliche Compiler zu vergleichen, die dann unterschiedliche Ergebnisse abliefern (weil unterschiedliche Optimierungen in dem Bereich getätigt werden - "copy elision" - ein Compiler erkennt: Hey, hier kann ich das Objekt selbst raus geben ohne es zu kopieren und der andere Compiler erkennt es nicht, so dass es dann zu einer veränderten Laufzeit kommt).
Das einfach nur mal als meine Sicht - frei herausgeschrieben und nicht wirklich überprüft / validiert. Daher bitte nur als grobe Sichtweise / als Anregungen ansehen. Da sind jetzt weder empirische Tests noch wissenschaftliche Untersuchungen durchgeführt worden
Ein paar weitere Anmerkungen noch von mir:
* Vermutlich hat Java im Schnitt einen höheren Memory-Footprint als C++ (bedingt durch die JVM)
* Vermutlich ist im Schnitt Java langsamer als C++
Aber wie mit allem - der Durchschnitt ist zwar interessant, aber in der Praxis nicht geeignet. Und solche Messungen wie hier, sind da nicht hilfreich, dazu ist das Thema zu diffizil.
Performance-Messungen im luftleeren Raum sind grundsätzlich schon sehr schwierig bzgl. ihrer Aussagekraft - zwei Performance-Messungen im luftleeren Raum zweier verschiedener Programmiersprachen noch umso mehr. Denn was spielt alles eine Rolle:
Welche Zeit messe ich
* Aufruf des Programms auf der Kommandozeile bis Rückkehr zur Kommandozeile
* Erste Zeile Main bis Ende Programm
Macht - vor allem bei kleineren Programmen - ggf. schon eine Menge aus, weil die JVM eine gewisse Ramp-Up Zeit hat
Wie ist das Programm optimiert
* Ist bei C++ für eine bestimmte Architektur kompiliert?
* Welchen Garbage Collector hab ich bei Java
* Greift die JIT-Optimierung in Java?
Was sind die beschränkenden Faktoren
Wo läuft das Programm an seine Grenzen? Was ist eigentlich hauptsächlich für die Laufzeit verantwortlich? CPU? RAM? Graphik? Netzwerk?
In dem Programm hier aus dem ersten Beitrag ist mit ziemlicher Sicherheit die Ausgabe auf der Konsole der limitierende Faktor
Wie belastbar bzw. wiederholbar sind die Daten
Ein Durchlauf sagt genau gar nichts aus.
Wie sehr lassen sich die Ergebnisse auf unterschiedlichen Rechnern, unterschiedlichen Umgebungen verifizieren und wiederholen? Wie hoch ist die Standardabweichung bei den gemessenen Laufzeiten?
Deswegen ist ganze Thema schwierig, wenn man es wirklich gut machen will, muss man tief einsteigen und genau drauf achten, dass man wirklich auch belastbare Ergebnisse hat. Es gibt nicht umsonst das Sprichwort "Wer viel misst misst Mist"
Und selbst wenn man belastbare Ergebnisse hat - was macht man mit denen? Wofür dienen sie? Wenn ich weiß das C++ bei Fourier-Transformationen auf Intel Maschinen 5% schneller ist - was bringt mir das, wenn ich eine Lagerverwaltung programmieren will?
Wenn man schlechte Zeiten provozieren will, dann würde ich bei allen Konstrukten mit Garbage Colector schauen, wie man diesen herausfordern kann. Massig Objekte erzeugen, die direkt gelöscht werden können, ist zu einfach - da ist der GC sehr effektiv. Ich habe den Java GC nicht im Detail betrachtet, aber den vom .Net Framework habe ich mal tiefer im Detail angeschaut. Der arbeitet mit mehreren Generationen (0, 1 und 2) um da dann effektiv vor allem um jüngere Objekte durchzugehen. Da könnte man also auch überlegen, wie man etwas aufbauen kann, um dies stärker zu fordern.
Dein Test, testet übrigens auch nicht die Sprache, sondern wie schnell es möglich ist Daten auf der Konsole auszugegeben, das hat nix direkt mit der Sprache zu tun. Sprich, das was du dort misst ist nicht die Performance des Programms, sondern die Performance der Konsole.
Bist du sicher, dass exakt die gleichen Strings in der gleichen Reihenfolge an die gleichen OS-Funktionen zur Ausgabe geschickt werden? Und weder Der C++ Compiler, noch die Java VM, noch der JIT Compiler der VM da irgendwelche Optimierungen bzgl. Buffering und Co vornehmen? Sämtliche Ausgaben laufen ggf. durch einen Buffer durch, der geflushed wird. Und ob das bei beiden Sprachen analog funktioniert?
Nachtrag: Hier steht für (Linux soweit ich was sehe) schon einiges bzgl. Buffering. Also nein, es ist nur einfach "Die Console". Da ist noch eine Menge Zeugs zwischendrin involviert bis es auf der Konsole erscheint:
original text When the container prints the log to the console blocking, you see a point of view: Printing logs to the console is slower and very slow than printing to files. This is also mentioned by the two issue officials of log4j2 and logback (see LOG4J2-2239, LOGBACK-1422). So why is it...
Aber Java ist hauptsächlich auf dem Server zuhause und hat da eine sehr weitgehende Infrastruktur. Und ja: Die Libraries machen da den Unterschied aus
Edit: Ups - beim erneuten lesen gesehen, dass da ein nicht zu viel war - Man erkennt, dass es erst eine andere Formulierung werden sollte. So ist der Sinn aber wenigstens korrekt.
Aber Java ist hauptsächlich auf dem Server zuhause und hat da eine sehr weitgehende Infrastruktur. Und ja: Die Libraries machen da den Unterschied aus
Edit: Ups - beim erneuten lesen gesehen, dass da ein nicht zu viel war - Man erkennt, dass es erst eine andere Formulierung werden sollte. So ist der Sinn aber wenigstens korrekt.
also ich hab mit FXGL urm gespielt gehabt ... es funktioniert einwandfrei für 2D Spiele und man könnte sagen es kann mit den C# und C++ Libraries auf der 2D Ebene mithalten kann aber 3D technisch ist das eher ein Trauer Spiel... FX hat gute Simulations Möglichkeiten in 3D zb dass ein Würfel sich wellenartig ausbreitet aber für 3D Spiele ist es meines Erachtens "unterentwickelt" im Vergleich zu C++ und C# ...
Wenn man jetzt sagt "ja bin der beschte im Programmmieren" und schafft es 3D Sachen erfolgreich mit fx zu programmieren .. schön und gut
aber in unity geh ich in das Programm rein und lass mir den Code "größtenteils" erstellen
bzw in Unreal Engine lässt man sich den Code komplett generieren
in Einem thread dazu hatte ich mal aufgeschnappt dass Oracle sich bei Java nicht in die 3D Richtung bewegen wollte ka ob das stimmt oder nicht
Einige "negative Punkte" über Java sind einfach "antik" oder unwahr...
1. "java Hello world hat 4kb und Cprogramm nur paar bytes" : ist zwar wahr aber wen jucken noch die paar gigabyte mehr oder weniger...
2. jvm ist sehr langsam im verlgeich zu C : war zu Anfangszeiten von Java noch wahr aber heutzutage kann man das nicht mehr behaupten
3. Meinungen werden falsch interpretiert zb von torvalds "java has such a bad virtual machine"( ist auch schon des längeren her ) ... ja ist klar ... eine Sprache die nicht so system nah ist weil sie in einer Virtuellen Maschine läuft als KERNEL Sprache komplett ungeeignet ist eig klar dass da C die Nase vorne hatte
Nennen wir doch einfach mal den größten Nachteil von Java. Es läuft nur mit einer JVM. Davon gibt es hunderte verschiedene Versionen auf Billionen verschiedenster Rechner. ich erkaufe mir mir den Vorteil der Plattform-Unabhängigkeit mit dem Horror unendlich verschiedene Kombinationen von Rechner/Software Konfigurationen Supporten zu müssen.
Da ist mir Javascript deutlich lieber wenn ich unbedingt Plattform unabhängig sein will und eine Compilersprache wenn ich es nicht brauche.
Nennen wir doch einfach mal den größten Nachteil von Java. Es läuft nur mit einer JVM. Davon gibt es hunderte verschiedene Versionen auf Billionen verschiedenster Rechner. ich erkaufe mir mir den Vorteil der Plattform-Unabhängigkeit mit dem Horror unendlich verschiedene Kombinationen von Rechner/Software Konfigurationen Supporten zu müssen.
Da ist mir Javascript deutlich lieber wenn ich unbedingt Plattform unabhängig sein will und eine Compilersprache wenn ich es nicht brauche.
in meiner Vorlesung ist dran gekommen "ihr solltet schon wissen wie vor java 5 die Generics ausgesehen haben das wird ziemlich sicher auf euch zu kommen das ist noch nicht lange her"... just sayin
in meiner Vorlesung ist dran gekommen "ihr solltet schon wissen wie vor java 5 die Generics ausgesehen haben das wird ziemlich sicher auf euch zu kommen das ist noch nicht lange her"... just sayin
Alleine java8 hat mittlerweile über 200 Releases und du glaubst doch nicht das alle User ihr java refelmäßig auf den neusten Stand bringen? Ich hatte Java 8 Versionen die haben die verrücktesten Sachen gemacht. der fix kam dann natürlich sehr schnell in der nächsten Version, nur blöd wenn nur Ein User das Update verpasst.
Alleine java8 hat mittlerweile über 200 Releases und du glaubst doch nicht das alle User ihr java refelmäßig auf den neusten Stand bringen? Ich hatte Java 8 Versionen die haben die verrücktesten Sachen gemacht. der fix kam dann natürlich sehr schnell in der nächsten Version, nur blöd wenn nur Ein User das Update verpasst.
Dann sind C , C++ und C# komplett für den Müll weil du nicht erwarten kannst dass irgend jemand irgendwas gleich hat...und dann noch auf windwos wo du nicht den Code kennst oder auf Linux wo niemand die gleiche Version hat ..ohoh ...dann sind Java C# und C++ wirklich für die Tonne und werdne nirgendwo benutzt..
Alleine java8 hat mittlerweile über 200 Releases und du glaubst doch nicht das alle User ihr java refelmäßig auf den neusten Stand bringen? Ich hatte Java 8 Versionen die haben die verrücktesten Sachen gemacht. der fix kam dann natürlich sehr schnell in der nächsten Version, nur blöd wenn nur Ein User das Update verpasst.
Ich hatte Java 8 Versionen die haben die verrücktesten Sachen gemacht. der fix kam dann natürlich sehr schnell in der nächsten Version, nur blöd wenn nur Ein User das Update verpasst.
Mal davon abgesehen, dass Java auf dem Desktop eh nicht die präferierte Anwendung ist - und im Server-Bereich ist das alles kein Problem, weil das läuft da in jeder unterstütztem VM, bzw. Application-Server (je nach eingesetzter Technologie). Aber hunderte Versionen ist grober Unfug, wenn an eine JVM mitliefert, sind das halt 3 Varianten - eine Windows, eine Linux und eine MacOS, done. (bzw. unter Linux kann man vermutlich noch am ehesten davon ausgehen, das User da eine installieren können)
Wenn ich eine Software für bestimmte Plattformen anbieten möchte, dann muss ich das eh testen, muss Probleme von Kunden nachstellen können u.s.w. Daher ist logisch, dass ich - so ich Windows, OS X und Linux supporte, auch entsprechende Systeme haben muss.
Wenn ich die Systeme habe, dann kann ich da auch eben das Build laufen lassen, daher:
Ja, es läuft dann auf allen drei Systemen und ich habe ein Linux Binary, ein Mac Binary (im Typischen .App Ordner) und ein Windows Binary.
Und ich gebe den Kunden auch genau das Erlebnis, das sie gewohnt sind. Windows hat dann einfach die MSI Datei, mac ein DMG mit der Applikation ... Linux ist und bleibt natürlich die Frickel Plattform. Was darf es denn alles sein? .deb, .rpm. flatpack, snap, appimage, ...? (Ja, appimage ist schon ok, das nimmt man zur Not einfach ...)
Also ich habe gerade paar kleine Probleme, euch wirklich zu folgen:
Wenn ich eine Software für bestimmte Plattformen anbieten möchte, dann muss ich das eh testen, muss Probleme von Kunden nachstellen können u.s.w. Daher ist logisch, dass ich - so ich Windows, OS X und Linux supporte, auch entsprechende Systeme haben muss.
Wenn ich die Systeme habe, dann kann ich da auch eben das Build laufen lassen, daher:
Ja, es läuft dann auf allen drei Systemen und ich habe ein Linux Binary, ein Mac Binary (im Typischen .App Ordner) und ein Windows Binary.
Und ich gebe den Kunden auch genau das Erlebnis, das sie gewohnt sind. Windows hat dann einfach die MSI Datei, mac ein DMG mit der Applikation ... Linux ist und bleibt natürlich die Frickel Plattform. Was darf es denn alles sein? .deb, .rpm. flatpack, snap, appimage, ...? (Ja, appimage ist schon ok, das nimmt man zur Not einfach ...)
ich wollte ja auch nur damit sagen, dass du dann den (in meinen Augen) einzigen Vorteil gegenüber anderen Sprachen verloren hast. Dann ist es genauso einfach (wenn nicht einfacher) ein C++ Programm 3x zu kompilieren.
ich wollte ja auch nur damit sagen, dass du dann den (in meinen Augen) einzigen Vorteil gegenüber anderen Sprachen verloren hast. Dann ist es genauso einfach (wenn nicht einfacher) ein C++ Programm 3x zu kompilieren.
Aber man hat doch einiges an Plattform spezifischen Sachen in #ifdef und so. Vieles mag in Abhängigkeiten geregelt sein (qt, boost, ...) aber das reicht oft nicht. Da ist Java schon deutlich schöner und einfacher....
Aber das ist nur meine Erfahrung... vielleicht kann man das noch besser machen ...
Gleichzeitig ist dir aber Javascript (was genau das gleiche Konzept mit VM nutzt, die allerdings im Vergleich zur JVM nahezu kein Endnutzer installiert hat) lieber?
Gleichzeitig ist dir aber Javascript (was genau das gleiche Konzept mit VM nutzt, die allerdings im Vergleich zur JVM nahezu kein Endnutzer installiert hat) lieber?
Ahja also kaum ein Endnutzer hat Javascript in seinem Browser installiert? Interessant.... Ich wußte gar nicht das man Javascript nachträglich installieren muss. Ich dachte immer man muss wenn überhaupt es nachträglich deaktivieren. Aber man lernt hier ja nie aus....
Ahja also kaum ein Endnutzer hat Javascript in seinem Browser installiert? Interessant.... Ich wußte gar nicht das man Javascript nachträglich installieren muss. Ich dachte immer man muss wenn überhaupt es nachträglich deaktivieren. Aber man lernt hier ja nie aus....
du kannst aber mit Javascript auch auf der Console arbeiten und Programme schreiben wie in java oder C oder php ... die kannst du auch alle auf der Konsole benutzen unabhängig vom Web -> das ist nirgends vorinstalliert soweit ich weis bei javascript
Ahja also kaum ein Endnutzer hat Javascript in seinem Browser installiert? Interessant.... Ich wußte gar nicht das man Javascript nachträglich installieren muss. Ich dachte immer man muss wenn überhaupt es nachträglich deaktivieren. Aber man lernt hier ja nie aus....
Davon gibt es hunderte verschiedene Versionen auf Billionen verschiedenster Rechner. ich erkaufe mir mir den Vorteil der Plattform-Unabhängigkeit mit dem Horror unendlich verschiedene Kombinationen von Rechner/Software Konfigurationen Supporten zu müssen.
Fullstack meint üblicherweise den vollen Stack für Web-Anwendungen – das ist eben Frontend + Backend + Drumherum, also kommt man um JavaScript für's Browserseitige Frontend nicht herum (für PHP gibts allerdings einen Haufen besserer Alternativen, Java ist nur eine davon...).
In den meisten Fällen sind Web-Anwendungen auch die sinnvollste Wahl, weil es vieles sowohl für Entwickler als auch Nutzer einfacher macht.
Javascript im Browser kann aber einfach weniger als eine "native" Anwendung, zB schon deshalb, weil es in einer zusätzlichen Sandbox läuft. Vor allem muss man mit Web-Anwendungen nicht weniger "verschiedene Kombinationen von Rechner/Software Konfigurationen" unterstützen, als mit Java-Anwendungen.
a) Weil es Bullshit-Bingo ist.
b) Weil JavaScript an vielen Stellen eine unterstützende Sprache ist. Sehr viele Serveranwendungen bieten ein Web-Frontend. Und für dynamsiche Web-Frontends kommt man nicht ohne JavaScript aus. Je nach Framework wird es mehr oder weniger gut weggekapselt, aber irgendwann gibt es immer den Fall, wo man mal an den Javascript Code ran muss
Wer sagt denn sowas? Also JavaScript kann ich noch verstehen weil das halt eine Grundlage ist für webbasierte Dinge (aber da auch nicht zwingend notwendig, wie genug Alternativen zeigen) aber PHP? Zumindest in dem Bereich, den ich so überblicke, spielt PHP absolut keine Rolle.
Wer sagt denn sowas? Also JavaScript kann ich noch verstehen weil das halt eine Grundlage ist für webbasierte Dinge (aber da auch nicht zwingend notwendig, wie genug Alternativen zeigen) aber PHP? Zumindest in dem Bereich, den ich so überblicke, spielt PHP absolut keine Rolle.
Du kennst doch sicher diese Stellen Anzeigen wo man das ganze Internet Durchgelesen haben muss und 10 verschiedene Sprachen können sollte ... da ist oft php mit javascript dabei
ich behaupte nicht dass php javascript unbedingt das geilste auf der Welt ist..
als Junger Mensch muss ich mir diese "irrsinnigen" Anzeigen anschauen wo einfach alles verlaangt wird...
Also ich muss gestehen, dass ich halt nicht irgendwelche Anzeigen betrachte. Ich bekomme eher mit, was wir als Dienstleister bei großen Kunden so an Projekten "staffen" dürfen. Da taucht PHP eigentlich nicht auf.
Aber egal wie sehr das angefordert wird oder nicht: Das ist auf keinen Fall gleich zu setzen. Ein FS Entwickler kann halt Frontend und Backend bedienen. Und das geht auch ganz ohne JavaScript und PHP. Statt JavaScript ist einfach TypeScript zu nennen. Das hat zwar JavaScript noch als Ergebnis, aber ein Entwickler muss das nicht zwingend kennen (z.B. mit aktuellem Angular). Aber es gibt auch Lösungen wie Flutter mit Sprache Dart. Da kann man auch FS Entwickeln ohne JavaScript zu können .... Und auch WebAssembly geht einen Weg ohne JavaScript - denn das Ziel ist ein ByteCode.
Daher ist das keine Anforderung für einen FS Entwickler.
Also ich muss gestehen, dass ich halt nicht irgendwelche Anzeigen betrachte. Ich bekomme eher mit, was wir als Dienstleister bei großen Kunden so an Projekten "staffen" dürfen. Da taucht PHP eigentlich nicht auf.
Aber egal wie sehr das angefordert wird oder nicht: Das ist auf keinen Fall gleich zu setzen. Ein FS Entwickler kann halt Frontend und Backend bedienen. Und das geht auch ganz ohne JavaScript und PHP. Statt JavaScript ist einfach TypeScript zu nennen. Das hat zwar JavaScript noch als Ergebnis, aber ein Entwickler muss das nicht zwingend kennen (z.B. mit aktuellem Angular). Aber es gibt auch Lösungen wie Flutter mit Sprache Dart. Da kann man auch FS Entwickeln ohne JavaScript zu können .... Und auch WebAssembly geht einen Weg ohne JavaScript - denn das Ziel ist ein ByteCode.
Daher ist das keine Anforderung für einen FS Entwickler.
Full Stack Dev wir d in den Anzeigen auch nicht gleichgesetzt mit Frontend und Backend ...sondern es gibt einen Stack aus Sprachen und die muss man alle können ..also ...full... stack...
Full Stack Dev wir d in den Anzeigen auch nicht gleichgesetzt mit Frontend und Backend ...sondern es gibt einen Stack aus Sprachen und die muss man alle können ..also ...full... stack...
Ähh ... nein? Ich will ja nicht bestreiten, dass es Leute gibt, die Bullshit Bingo spielen und keine Ahnung von Begriffen haben, aber FS Entwickler sind Entwickler, die den ganzen Stack (Im Sinne von Frontend, Backend, Database - also von n-Tier Applikationen abgeleitet) beherrschen.
Die Auflistung von Sprachen, die man erwartet, sind dann ergänzend und davon unabhängig ... halt eine Wunschliste, was ein Bewerber bitte können sollte.
Das Full Stack ist aber nach meinem Verständnis im Full stack Developer nicht so gemeint, wie es da aufgeführt wurde. Also ein Entwickler, den den Android Stack bedient, kann den ganz bedienen, aber wäre nach meinem Verständnis kein Full Stack Developer.
Full Stack Dev wir d in den Anzeigen auch nicht gleichgesetzt mit Frontend und Backend ...sondern es gibt einen Stack aus Sprachen und die muss man alle können ..also ...full... stack...
Kann natürlich auch reine Backend-Stacks geben, nahezu immer meint es aber den gesamten Stack von Datenbank bis Frontend.. Stack macht ja auch nur Sinn, wenn es aufeinander aufbauende Technologien sind, wenn die rein parallel sind, ist es kein Stack..
Ähh ... nein? Ich will ja nicht bestreiten, dass es Leute gibt, die Bullshit Bingo spielen und keine Ahnung von Begriffen haben, aber FS Entwickler sind Entwickler, die den ganzen Stack (Im Sinne von Frontend, Backend, Database - also von n-Tier Applikationen abgeleitet) beherrschen.
Die Auflistung von Sprachen, die man erwartet, sind dann ergänzend und davon unabhängig ... halt eine Wunschliste, was ein Bewerber bitte können sollte.
Das Full Stack ist aber nach meinem Verständnis im Full stack Developer nicht so gemeint, wie es da aufgeführt wurde. Also ein Entwickler, den den Android Stack bedient, kann den ganz bedienen, aber wäre nach meinem Verständnis kein Full Stack Developer.
