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 einen alternativen Browser verwenden.
Hm ich fand Java immer mitunter am einfachsten, da man es grade wegen Objektorientierung super aufteilen kann. Jeder bekommt sein Modul, ein UML Chart wie die Methoden zu heißen haben und schon kann man anfangen.
Es geht nicht darum, dass Objektorientierung generell schlecht ist. Es geht darum, dass es nicht für jedes Problem die beste Lösung ist. Abgesehen davon, dass die Objektorientierung von Java ziemlich bescheiden ist.
rob- schrieb:
Java wirkt nur aus Sicht Einzelner Programmierer weniger schön, wobei es immer noch schöner ist als alle anderen gebräuchlichen Sprachen
Keine Ahnung, was für Dich gebräuchlich ist aber schon bei einer einfachen Klassendefinition wirds ja umständlich:
Code:
class Punkt {
int x;
int y;
public Punkt(int x, int y) {
this.x = x;
this.y = y;
}
}
Wie oft ich da allein das x und y tippen muss. Und ich hab jetzt noch nicht mal Getter und Setter die kommen ja noch dazu (hierfür bietet C# ja wenigstens noch Properties an).
Das Ganze würde in Racket Scheme folgendermaßen aussehen:
Code:
(struct Punkt (x y))
Oder, um noch die Typdeklaration mit unter zu bringen:
Code:
(struct Punkt ([x : Integer] [y : Integer]))
rob- schrieb:
nur das hat halt typische Microsoft Grenzen und ist raus bevor es überhaupt eine Chance bekommt.
Was auch immer Du meinst, aber Mono (www.mono-project.com) gibts ja nun schon eine ganze Weile und inzwischen gibt Microsoft ja auch die .NET-Plattform nach und nach frei: github.com/Microsoft/dotnet
Gruß
MichaelK
Ergänzung ()
NoSpace schrieb:
Teile zwar deine Meinung nicht aber eins ist klar soetwas wie Spring/Java EE setzt man nicht für eine kleine Webseite ein
, sondern für Anwendungen die sehr komplex sind und bei denen Anforderungen gestellt werden die andere Sprachen gar nicht abdecken. Stichwort: Transaktionssicherheit
Gerade wenn Applikationen komplex werden fängt man sich ja Probleme mit Java ein. Gerade dann fallen einem nämlich viele Sachen auf die Füße.
NoSpace schrieb:
Zusätzlich bedeutet Spring nicht Java only!
Mit Spring AOP (AspectJ) steht eine powervolle aspektorientiere Programmiersprache zu Verfügung die für die Lösung von Cross-Cutting Concerns geschaffen wurde.
Als ich das erste Mal mit AspectJ experimentiert hab, dass muss so Anfang 2000 gewesen sein (damals war ich noch hauptsächlich in Java unterwegs). Ich fand es ganz nett, aber letztlich ist das auch wieder nur eine Technologie, um Java-Schwächen auszugleichen.
Und letztlich hat sich AspectJ ja auch nie so richtig verbreitet. Es gibt halt wieder ne neue Syntax und man braucht ein extra Compiler und das macht dann auch schnell mal das Debugging etwas anstrengend. Das ist wohl auch der Grund, weshalb Spring meines Wissens nach nicht das komplette AspectJ unterstützt.
Ich komm da jetzt grad drauf, weil ich oben schon mal ne Zeile Lisp geschrieben hab. Irgendwie hat sich wohl dann auch mal die Mühe gemacht und AspectJ nach (Common) Lisp portiert (bin da mal auf CLiki drüber gestolpert). Lustigerweise ist da gar kein extra Compiler vonnöten, sondern man bindet den Kram einfach als Library ein und fertig. Funktioniert dadurch auch in der Lisp-IDE ohne das man dafür ein Plugin schreiben muss usw. Die Sourcen sind da auch weniger als 100kB groß während schon die ersten AspectJ-Versionen mehrere MBs auf die Waage bringen.
Gebraucht habe ich es in Lisp noch nicht wirklich, ist aber ein schönes Beispiel dafür wie umständlich man bestimmte Dinge in Java lösen muss.
Gruß
MichaelK
Ergänzung ()
rob- schrieb:
Hm ich fand Java immer mitunter am einfachsten, da man es grade wegen Objektorientierung super aufteilen kann. Jeder bekommt sein Modul, ein UML Chart wie die Methoden zu heißen haben und schon kann man anfangen.
Es geht nicht darum, dass Objektorientierung generell schlecht ist. Es geht darum, dass es nicht für jedes Problem die beste Lösung ist. Abgesehen davon, dass die Objektorientierung von Java ziemlich bescheiden ist.
rob- schrieb:
Java wirkt nur aus Sicht Einzelner Programmierer weniger schön, wobei es immer noch schöner ist als alle anderen gebräuchlichen Sprachen
Keine Ahnung, was für Dich gebräuchlich ist aber schon bei einer einfachen Klassendefinition wirds ja umständlich:
Code:
class Punkt {
int x;
int y;
public Punkt(int x, int y) {
this.x = x;
this.y = y;
}
}
Wie oft ich da allein das x und y tippen muss. Und ich hab jetzt noch nicht mal Getter und Setter die kommen ja noch dazu (hierfür bietet C# ja wenigstens noch Properties an).
Das Ganze würde in Racket Scheme folgendermaßen aussehen:
Code:
(struct Punkt (x y))
Oder, um noch die Typdeklaration mit unter zu bringen:
Code:
(struct Punkt ([x : Integer] [y : Integer]))
rob- schrieb:
nur das hat halt typische Microsoft Grenzen und ist raus bevor es überhaupt eine Chance bekommt.
Was auch immer Du meinst, aber Mono (www.mono-project.com) gibts ja nun schon eine ganze Weile und inzwischen gibt Microsoft ja auch die .NET-Plattform nach und nach frei: github.com/Microsoft/dotnet
Gruß
Andy
Ergänzung ()
NoSpace schrieb:
Teile zwar deine Meinung nicht aber eins ist klar soetwas wie Spring/Java EE setzt man nicht für eine kleine Webseite ein
, sondern für Anwendungen die sehr komplex sind und bei denen Anforderungen gestellt werden die andere Sprachen gar nicht abdecken. Stichwort: Transaktionssicherheit
Gerade wenn Applikationen komplex werden fängt man sich ja Probleme mit Java ein. Gerade dann fallen einem nämlich viele Sachen auf die Füße.
NoSpace schrieb:
Zusätzlich bedeutet Spring nicht Java only!
Mit Spring AOP (AspectJ) steht eine powervolle aspektorientiere Programmiersprache zu Verfügung die für die Lösung von Cross-Cutting Concerns geschaffen wurde.
Als ich das erste Mal mit AspectJ experimentiert hab, dass muss so Anfang 2000 gewesen sein (damals war ich noch hauptsächlich in Java unterwegs). Ich fand es ganz nett, aber letztlich ist das auch wieder nur eine Technologie, um Java-Schwächen auszugleichen.
Und letztlich hat sich AspectJ ja auch nie so richtig verbreitet. Es gibt halt wieder ne neue Syntax und man braucht ein extra Compiler und das macht dann auch schnell mal das Debugging etwas anstrengend. Das ist wohl auch der Grund, weshalb Spring meines Wissens nach nicht das komplette AspectJ unterstützt.
Ich komm da jetzt grad drauf, weil ich oben schon mal ne Zeile Lisp geschrieben hab. Irgendwie hat sich wohl dann auch mal die Mühe gemacht und AspectJ nach (Common) Lisp portiert (bin da mal auf CLiki (ww.cliki.net) drüber gestolpert). Lustigerweise ist da gar kein extra Compiler vonnöten, sondern man bindet den Kram einfach als Library ein und fertig. Funktioniert dadurch auch in der Lisp-IDE ohne das man dafür ein Plugin schreiben muss usw. Die Sourcen sind da auch weniger als 100kB groß während schon die ersten AspectJ-Versionen mehrere MBs auf die Waage bringen.
Gebraucht habe ich es in Lisp noch nicht wirklich, ist aber ein schönes Beispiel dafür wie umständlich man bestimmte Dinge in Java lösen muss.
Gruß
Andy
Ergänzung ()
TheRepatriate schrieb:
@andy_m4: Du magst mit deinen Aussagen richtig liegen, aber in diesem Threat ging es darum Leute für eine "Lerngruppe" zu begeistern und nicht die tausendste Diskussion darüber loszubrechen ob nun Java gut oder schlecht ist
Wie oft ich da allein das x und y tippen muss. Und ich hab jetzt noch nicht mal Getter und Setter die kommen ja noch dazu (hierfür bietet C# ja wenigstens noch Properties an).
@andy_m4
Du glänzt in Sachen Java aber auch mit ziemlichem antiquiertem Halbwissen. Weder führt AspectJ ein Schattendasein, noch ist AspectJ in Spring integriert, sondern lediglich die Syntax. Auch ist kein extra Compilieren notwendig, wenn man Loadtime Weaving verwendet. Der Vorteil ist ja gerade, dass man die Advices und Pointcuts unabhängig voneinander deployen kann.
Wenn du dich schon als Oberlehrer aufspielen willst, dann erzähl wenigsten kein Stuss.
Ich bin nicht lernwillig , weil ich seit 4 Jahren produktiv mit Spring, Hibernate, MongoDB, Elasticsearch, Jackson, Maven, etc. pp. beruflich arbeite, aber stehe gern für Fragen bereit.
Wenn ihr neu anfangt, solltet ihr direkt auf die aktuellen Technologien setzen: Java8, Spring4, Spring Boot
Und speziell bei den NoSQL Technologien gilt die Devise: Erst Überlegen, dann das Konzept, dann die Diskussion, dann die Überarbeitung, dann noch mal drüber Schlafen, dann alles über den Haufen werfen und neu anfangen, dann ... und zum Schluss dann die Umsetzung.
Da können sonst selbst kleinste Änderungen im Datenmodell einen kompletten Rewrite bedeuten wenn man Wert auf Datenintegrität legt, da es (beim Großteil der NoSQL Datenbanken) keine Transaktionen gibt. Als Belohnung kann man sein Datenmodell exakt auf den Anwendungsfall optimieren, d.h. dass man für Schreib- und/oder Leseperformance optimieren kann, indem man partielle Updates fährt oder Daten denormalisiert speichert. Damit das am Ende mit parallelen Zugriffen auch problemlos funktioniert, muss allerdings erheblich mehr Gehirnschmalz verbraten werden als bei einer SQL Lösung. Dafür muss man sich dann auch nicht mit den Eigenheiten von JPA und Hibernate rumschlagen.
, weil ich seit 4 Jahren produktiv mit Spring, Hibernate, MongoDB, Elasticsearch, Jackson, Maven, etc. pp. beruflich arbeite, aber stehe gern für Fragen bereit.