Anwendersoftware > Freeware

Java und IRIX Environment

<< < (5/6) > >>

AlArenal:


--- Zitat ---
alles, was nicht lightweight ist, ist eben sackgasse. nur es gibt zzt keine sichtbaren alternativen. das kann sich aber immer ändern. java ist ja auch so 'aus der ( ok, sonnigen ;) ) garage' gross geworden.
rob

--- Ende Zitat ---


Java hat aber schon 13 Jahre hinter sich. Die Bereiche, in denen Java aktuell stark vertreten ist, haben sich ebenfalls erst in dieser Zeit entwickelt, u.a. auch dank Java. In diesen Bereichen dürfte es schwer werden nachträglich eine neue Sprache zum Durchbruch zu bringen, da die vorhandene Codebase einem gewissen Investitionsschutz unterliegt. Es kommt ja auch keiner auf die Idee Windows komplett neu in C# zu entwickeln (in der Tat gibt es übrigens keine einzige Anwendung die MS auf Basis von .NET neu implementiert hätte).

Neue Sprachen und Systeme würden wohl nur aufgrund ganz neuer Erfordernisse in der IT entstehen, die mit jetzigen Sprachen und Paradigmen nicht mehr zu handlen wären. Derartiges sehe ich derzeit aber nicht auf Java zukommen. (muss nichts heißen, bin ja vielleicht auch blind)

Im Übrigen:
Ist ein Problem nicht "lightweight", kann es in der Regel auch nicht "lightweight" gelöst werden. Die Vernetzung von Systemen und Datenstrukturen wird immer komplexer. Da kann es Lösungen geben, die "ontop" scheinbar "lightweight" arbeitet, aber im Grunde nur kopmplexere tiefer liegende Vorgänge verbirgt und automatisiert.

Wir werden keine Systeme mehr haben, wo man mit peek und poke auf der Eingabeebene mal eben die Rahmen-, Text- und Hintergrundfarbe setzt ;)

rob_gester:

--- Zitat ---
Java hat aber schon 13 Jahre hinter sich. Die Bereiche, in denen Java aktuell stark vertreten ist, haben sich ebenfalls erst in dieser Zeit entwickelt, u.a. auch dank Java.

--- Ende Zitat ---
richtig. im klartext heisst das -> java wurde nach der ersten euphorie aus den clients richtung server verbannt, weil sie eben schwer heavyweight ist. wer spielt noch mit applets heutzutage?

--- Zitat ---In diesen Bereichen dürfte es schwer werden nachträglich eine neue Sprache zum Durchbruch zu bringen, da die vorhandene Codebase einem gewissen Investitionsschutz unterliegt. Es kommt ja auch keiner auf die Idee Windows komplett neu in C# zu entwickeln (in der Tat gibt es übrigens keine einzige Anwendung die MS auf Basis von .NET neu implementiert hätte).

--- Ende Zitat ---
auch richtig. niemand mehr bei gutem verstand wird so viele systemunabhängige classes packages neu entwerfen.

--- Zitat ---
Neue Sprachen und Systeme würden wohl nur aufgrund ganz neuer Erfordernisse in der IT entstehen, die mit jetzigen Sprachen und Paradigmen nicht mehr zu handlen wären. Derartiges sehe ich derzeit aber nicht auf Java zukommen. (muss nichts heißen, bin ja vielleicht auch blind)

--- Ende Zitat ---
ein beispiel: ein telekommukationsunternehmen, wo ich gearbeitet habe, hat sich ein komplexes crm-tool zugelegt, mit dem ganzen datenbanknetz, middleware und verschiedenen front ends dazu. das einizige, das nicht richtig bis nie funktioniert hatte (das hat eine weltberühmte consultingfirma implementiert) waren java teile, vor allem web interface. die ausführenden entwickler aus aller welt haben sich stark gewundert, warum man die datenbank logic nicht mit einfachen pl/sql funktionsaufrufen statt komplizierten und anfälligen enterprise beans entworfen hatte.

--- Zitat ---
Im Übrigen:
Ist ein Problem nicht "lightweight", kann es in der Regel auch nicht "lightweight" gelöst werden. Die Vernetzung von Systemen und Datenstrukturen wird immer komplexer. Da kann es Lösungen geben, die "ontop" scheinbar "lightweight" arbeitet, aber im Grunde nur kopmplexere tiefer liegende Vorgänge verbirgt und automatisiert.

Wir werden keine Systeme mehr haben, wo man mit peek und poke auf der Eingabeebene mal eben die Rahmen-, Text- und Hintergrundfarbe setzt ;)

--- Ende Zitat ---
ich denke die legacies sind so unterschiedlich, dass man die zukunft in einfachen handles-systemen sehen wird, die die daten untereinander austauschen. xml ist ein _guter_ weg in diese richtung. auf jeden fall es ist ein fehler, wenn man die systeme zwangsweise harmonisieren und unifizieren will, auch die neuesten, die gerade entstehen. es gibt für verschiedene aufgaben optimale lösungen, die mal mit vb oder php oder c# oder java oder sogar perl und shell-scripten bewältigt werden können. die zukunft ist in der schlanken kommunikation miteinander, denke ich.
rob

AlArenal:

--- Zitat ---
richtig. im klartext heisst das -> java wurde nach der ersten euphorie aus den clients richtung server verbannt, weil sie eben schwer heavyweight ist.

--- Ende Zitat ---


Java wurde nicht vom Client verbannt, sondern fand dort einfach wenig Anklang, weil die anfänglich mitgelieferte Oberflöche, das AWT, einfach grauenvoll war. Erst mit Java 2 (JDK/JRE 1.2) kam mit Swing ein wirklich gutes GUI, das es mit den nativen GUIs aufnehmen konnte.


--- Zitat ---wer spielt noch mit applets heutzutage?
--- Ende Zitat ---


Map24.de :D
Ich entwickle Desktop-Anwendungen und manchmal auch Applets in Java. Und fürn Desktop gibts doch so einiges...


--- Zitat ---
auch richtig. niemand mehr bei gutem verstand wird so viele systemunabhängige classes packages neu entwerfen.
ein beispiel: ein telekommukationsunternehmen, wo ich gearbeitet habe, hat sich ein komplexes crm-tool zugelegt, mit dem ganzen datenbanknetz, middleware und verschiedenen front ends dazu. das einizige, das nicht richtig bis nie funktioniert hatte (das hat eine weltberühmte consultingfirma implementiert) waren java teile, vor allem web interface. die ausführenden entwickler aus aller welt haben sich stark gewundert, warum man die datenbank logic nicht mit einfachen pl/sql funktionsaufrufen statt komplizierten und anfälligen enterprise beans entworfen hatte.
--- Ende Zitat ---


Java ist ja nicht Schuld daran, wenn IT-Manager die falschen Entscheidungen treffen. Ich war immer ein Anhänger von Das-geeignete-Werkzeug-für-die-jeweilige-Aufgabe, ganz egal ob das nun hieß, dass ich mich in PHP einarbeiten oder mit Perl und Shellskript rumhantieren musste.

Und wenn die nunmal nur Peilung von EJB und keinen Bock haben sich in PL/SQL einzuarbeiten, dann machen sie es eben mit EJB. Persönlich halte ich auch nichts davon Arbeiten außerhalb der DB zu erledigen, die da besser drin bleiben. Daher freue ich mich bei MySQL auch auf die Stored Procedures (leider nutzen wir nicht PostgreSQL).


--- Zitat ---ich denke die legacies sind so unterschiedlich, dass man die zukunft in einfachen handles-systemen sehen wird, die die daten untereinander austauschen. xml ist ein _guter_ weg in diese richtung.
--- Ende Zitat ---


Übrigens sind nahezu alle Referenzimplementationen für irgendwelche XML-Technologien alle in Java geschrieben.. ;)


--- Zitat ---auf jeden fall es ist ein fehler, wenn man die systeme zwangsweise harmonisieren und unifizieren will, auch die neuesten, die gerade entstehen. es gibt für verschiedene aufgaben optimale lösungen, die mal mit vb oder php oder c# oder java oder sogar perl und shell-scripten bewältigt werden können. die zukunft ist in der schlanken kommunikation miteinander, denke ich.

--- Ende Zitat ---


Ist grundsätzlich richtig und entspricht meiner oben gemachten Aussage. Im Grunde ist das ja eine alte Angewohnheit und Stärke von Unix-Systemen einzelne Komponenten mit etwas Glue-Logic zu komplexen Systemen zusammenzuschalten.

Allerdings können diese Komponenten neben kleinen Kommandozeilentools auch sehr komplexe Anwendungen und Systeme aus Anwendungen sein. Wenn ich ein komplexes Projekt vergebe, dann wird der Ausführende wohl kaum ein halbes Dutzend Sprachen auf einer Unix-Umgebung zur Umsetzung nutzen., sondern er wird sich auf sehr wenige Technologien beschränken und diese stark einbringen, weil er vermutlich auch vom Know-How her in der Breite die notwendige Tiefe nicht bieten kann - kleiner Tribut an den Spezialisierungszwang und möglichst geringe Projektzeiten und damit auch Kosten.

Manche füllen ihren Wagen auch stets mit Billig-Baumarkt-Öl und wundern sich, warum die Karre im Winter so ruppelt und warum der Motor verreckt.. - aber man hat erstmal gespart.

In der Praxis ist es nunmal häufig einfacher und kostengünstiger für einen Auftraggeber ein wenig mehr in Hardware zu investieren oder eben ne Sekunde länger zu warten, als viel mehr fürs Projekt auszugeben und länger drauf zu warten - hat auch immer firmenpolitische Gründe.

Ich sehe es ja bei uns. Wir müssen auch immer möglichst schon vorgestern die neuesten Features in die Software integrieren und möglichst gestern schon liefern, um heute noch die Rechnung stellen und mir nen neuen Wagen gönnen zu können... ;)

Die freie Marktwirtschaft lässt wenig Raum für Idealismus. Drum haben wir auch technisch veraltete SGIs zum Hobby, weil wir wenigstens privat in einigen Nischen die Möglichkeit haben den Idealisten in uns auszupacken. Aber wer von uns verdient schon an einer SGI sein Geld?

AlArenal:
Wenn mir jetzt noch einer sagen kann, warum der Post zerschossen ist :(

rob_gester:
mach es wie ich ;D
rob

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete