Das die Programmiersprache von der Aufgabenstellung abhängt hat nichts mit der Realität zu tun. Die Realität ist, dass man sein Werkzeug gut beherrschen muss und damit fast alles machen kann. Es ist insofern unsinnig zu empfehlen, beim Auswahl einer neuen Sprache (1. post) diese an der (ersten) Aufgabe auszurichten. Viel wichtiger ist es, eine Sprache und insbesondere die IDE unabhängig von der Aufgabe auszuwählen, weil es viel Zeit kostet sich in eine Sprache und in eine IDE einzuarbeiten. Und noch viel mehr um gut damit arbeiten zu können. Und noch viel mehr um auch die ganzen Bibliotheken kenenn zu lernen und auch die Feinheiten zu wissen. Insofern empfehle ich eine allgemeine IDE wie Eclipse oder Mono, die Dich erstmal relativ unabhängig von der Sprache machen. Die Einarbeitung in solch eine IDE kostet schon viele Wochen und MOnate. Die Sprache ist nochmals eine ganz andere Dimension - erst recht die zugehörigen Bibliotheken. Bei der Sprache und den Bibliotheken würde ich die wichtigsten Themen abklopfen wie Netzwerk APIs, Grafik APIs und auch multi-threading. Und gerade was Netz und MT betrifft ist man bei Java gut aufgehoben, da es über die Jahre gut gereift und stabil ist. Dafür benötigt man mehr Zeit um sich in die ganzen APIs einzuarbeiten.
VB6 Programmierer will umsteigen
Anmeldungsdatum: Beiträge: 3785 |
|
Anmeldungsdatum: Beiträge: 142 |
@Adun: Genau so war mein Beitrag auch gemeint. Die Beste Sprache, Die Beste Lösung,... gibt es nicht. Da hast du recht, es gibt halt Sprachen die halt spezielle Probleme besser Lösen können als andere, oder besser gesagt geeigneter sind. @dentaku: Danke, für die Screenshots. Oberflächengestalter, gibt es eigentlich für fast jede Sprache. Der Threadstarter , schreibt ja auch das er nicht unbedingt bei Basic bleiben wollte. Softwareentwicklung ist ein weites Feld, daswegen schrieb ich ja auch, er soll sich etwas näher damit beschäftigen. Wenn er es als Hobby machen möchte, wäre ein Problem oder Aufgabe für den Anfang nicht schlecht. Er sollte sich halt auch die Grenzen und wie du schreibts die APIs mit anschauen. Somit stimmen wir beide ja überein. Da wir beide keine Ahnung haben, was er will ist es halt etwas schwierig. |
Anmeldungsdatum: Beiträge: 3785 |
@Powerbauer: also wenn DU es nicht bereits wusstest: inzwischen gibt es IDEs die von der Sprache abstrahieren. Eclipse und Mono sind sehr verbreitete Platformen die auf vielen Systemen (Windows, Linux, Mac, etc.) bereits laufen. Insofern würde ich Dir empfehlen solche IDEs genauer unter die Lupe zu nehmen und Berichte darüber lesen. Weiteres Auswahlkriterium wären die von der IDE bereits (gut) unterstützten Programmiersprachen. Wie auch Microsoft's .NET geht die Reise in Richtung Plattformunabhängigkeit. Diese modernen IDEs übersetzen den speziellen Code der speziellen Sprache in einen eigenen allgemeinen Zwischencode, der wiederum auf jedem System läuft, auf dem auch die entsprechende Laufzeitumgebung (.NET Framework, Java VM, Mono Laufzeitumgebung, ...) unterstützt wird. Letztenendes ist es eine gute EMpfehlung auf die Komponenten zu setzen, die am weitesten verbreitet sind, da sie am besten gepflegt, am stabilsten und am zukunftsichersten sind. Schliesslich willst Du Deine teure Investition (sprich: Einarbeitung), nicht schon nach 1-2 Jahren bereuen. |
Ehemalige
![]() Anmeldungsdatum: Beiträge: 4687 Wohnort: Berlin |
@dentaku: Entschuldige, aber ich würde Dir auch mal den Satz von Nuhr nahelegen, wenn Du den selber schon anderen um die Ohren haust. Mono ist keine IDE und IDEs übersetzen auch keinen Code. Du hast anscheinend wirklich den Unterschied zwischen einer Programmiersprache und einer IDE nicht begriffen, oder gehst ziemlich schwammig mit den Begriffen um. Zwischencode hat im Grunde auch nichts mit Plattformunabhängigkeit zu tun. Bei Sprachen, die in Bytecode übersetzt werden, braucht man Laufzeitumgebungen für die Zielplattform, und bei "nativen" Compilern einen Compiler, der Maschinencode für die Zielplattform erstellen kann. Das macht Java oder C# nicht plattformunabhängiger als C oder Pascal. Sich erst eine IDE zu suchen und die zu lernen, um danach eine Sprache auszusuchen, welche von der gewählten IDE unterstützt wird, ist sicher auch nicht der Weg, der im Allgemeinen empfohlen wird. Erstens weil man damit zum "Fachidioten" für die gewählte IDE wird, also Leute die Java nur Programmieren können, wenn sie Eclipse oder Netbeans verwenden, oder C++ nur, wenn sie Visual Studio vor der Nase haben, und zweitens weil es durchaus Sprachen gibt, bei denen ein guter Texteditor für Programmierer ausreicht. Gerade auch weil die Einarbeitung in fette IDEs viel Zeit kostet und vom Lernen einer Programmiersprache erst einmal ablenkt. Ausserdem haben die meisten IDEs doch einen deutlichen "Sprachschwerpunkt". Bei Eclipse ist das primär Java und bei MonoDevelop C#. Für andere Sprachen wird in der Regel nicht der gleiche Grad an Unterstützung und Komfort geboten. |
![]() Anmeldungsdatum: Beiträge: 17621 Wohnort: Berlin |
Ich möchte ganz ohne Nuhr argumentieren. b) Marc 'BlackJack' Rintsch schrieb:
In gewisser Hinsicht nicht, weil es bestimmt für mehr Plattformen C-Compiler gibt, als JVMs, aber andererseits kann man bei Java eben das Kompilat meist so wie es ist auf einer anderen Plattform laufen lassen, auch wenn der Programmierer nicht daran gedacht hat. Wenn ich für eine Firma für Windowskisten entwickeln soll, dann kann ich das doch auf meinem Linuxnotebook machen. Das kann ich bei C nur, wenn die Grafikbibliotheken auf beiden Systemen vorhanden sind, ich einen Crosscompiler habe, ... - es ist mühseliger. C-Leute kommen zu Linux und suchen die conio.h. a) Quivadis schrieb:
Was ist das - richtig programmieren? Alles außer Basic, oder? ☺ |
Anmeldungsdatum: Beiträge: 3785 |
Marc 'BlackJack' Rintsch schrieb:
Tja (Nuhr...), das ist eben schlichtweg falsch! Wenn Du in Java Quellcode (oder den Quellcode einer anderen von JVM unterstützten Sprache) in den "bytecode" der JVM übersetzt, ist dieser Zwischencode auf jedem System lauffähig, der eine (Java) VM hat - somit also plattformunabhängig ist! Je nach JVM wird dieser Zwischencode interpretiert oder auch zur Laufzeit kompiliert (was wiederum hocheffizienten Maschinencode generiert (z.B. der Sun HotSpot compiler (in der JVM integriert)). |
Ehemalige
![]() Anmeldungsdatum: Beiträge: 4687 Wohnort: Berlin |
@user unknown: Vergleichbare Probleme zur |
Anmeldungsdatum: Beiträge: 3785 |
Marc 'BlackJack' Rintsch schrieb:
"... habe ich ... gehört..." (wieder: Nuhr...). JMF ist plattformunabhängig und funktioniert auf jeder Ziel-JVM exakt gleich. Sollte dies nicht der Fall sein, ist die Ziel-JVM fehlerhaft. Die JVM auf Windows und Linux (von Sun) haben damit grundsätzlich keine Probleme. Bei der Mac JVM weiss ich es nicht. So lange eine Java API in "pure Java" geschrieben ist, sind Programme welche diese APIs benutzen ebenfalls "pure Java" und somit platformunabhängig. Es gibt jedoch auch Java APIs, die sind nicht platformunabhängig (z.B. Java3D) und benötigen je nach System (Windows, Linux) zusätzliche platformabhängige Komponenten (3D DLL/lib). Wobei es übrigens inzwischen auch (3rd party) 3D APIs für Java gibt, die auch einen Software Renderer anbieten und somit wieder platformunabhängig sind. |
Ehemalige
![]() Anmeldungsdatum: Beiträge: 4687 Wohnort: Berlin |
@dentaku: Da lasse ich den Nuhr nicht gelten. Das habe ich nicht irgendwo im Internet gelesen, sondern das hat jemand mit dem ich zusammenarbeite erzählt, weil ein anderer Entwickler in dem Projekt gerade etwas in der Richtung gesucht hat. Ich habe zwar keine Ahnung davon, aber ich vertraue dem Erlebnisbericht. Von kaputten VMs oder dass es gar nicht läuft war hier nicht die Rede. Das JMF von Sun hat unter verschiedenen Plattformen einfach unterschiedlichen Umfang und unterschiedliche Laufgeschwindigkeiten, weil es eben genau eines der Rahmenwerke ist, die auch auf "native" Bibliotheken setzt. Wenn jemand ein Programm mit der Windows-Variante schreibt, und das dann unter Solaris mit der reinen Java-Variante ausprobiert, wird er eventuell etwas enttäuscht sein. Und damit passt das Beispiel IMHO zu der "fehlenden" |
Anmeldungsdatum: Beiträge: 333 |
Mit Java ist man nicht plattformunabhängig, sondern Abhängig von der JVM als Plattform. Daß man weniger Probleme hat, wenn man Binärpakete schnüren möchte, ist natürlich ein Argument, bei freier Software aber relativ egal. |
![]() Anmeldungsdatum: Beiträge: 17621 Wohnort: Berlin |
Bauer schrieb:
Mit plattformunabhängig ist gemeint: Unabhängig von Mac, Solaris, Linux. |
![]() Anmeldungsdatum: Beiträge: 1651 Wohnort: Münster |
Powerbauer schrieb:
Hallo auch! Ich habe mich unter Windows auch mit VisualBasic 6 beschäftigt und bin unter Linux dann recht schnell zu Python + pyGTK gekommen. Ich kann dir nur empfehlen, dir das mal anzusehen: Es ist sehr ansprechend und intuitiv, ist gut dokumentiert und lässt sich auch ohne große Probleme auf Windows portieren (wenn man vorausschauend arbeitet). Von den IDEs würde ich erstmal die Finger lassen. Mit Glade gibt es einen guten Oberflächendesigner, mit dem man später komplexere Oberflächen gestalten kann. Am Anfang ist es auf alle Fälle das bessere Training, einfache Oberflächen direkt im Quelltext zu "definieren". Wie gesagt: Ich kann es dir nur empfehlen. Schöne Grüße, brb |
Anmeldungsdatum: Beiträge: 5792 |
@Barabbas: Was glaubst Du lernt man den so Wichtiges, wenn man Oberflächen unter Verzicht auf den Designer selbst programmiert? |
![]() Anmeldungsdatum: Beiträge: 1651 Wohnort: Münster |
Lunar schrieb:
Du kannst mir glauben, dass ich dieses Textfeld gerade mit irgendwelchen Argumenten gefüllt habe. Aber wozu? Zum Einen: Ich berief mich ja recht konkret auf meine Erfahrung als VB6-Umsteiger. Was will man dazu noch sagen? Mich haben die IDE damals halt mehr irritiert als unterstützt. Es mag bei anderen anders sein. Zum Anderen: Es geht ja recht konkret um Python + GTK. Du bist doch selbst mit Python unterwegs - mir und dem Fragesteller ist (sicher) eher daran gelegen zu erfahren, wie du dich da damals eingearbeitet hast und ob du es heute wieder so machen würdest? Einen schönen Gruß, brb |
Anmeldungsdatum: Beiträge: 5792 |
@Barabbas: Die Verwendung von IDEs ist vielleicht eine Frage des persönlichen Arbeitsstils, aber GUI-Designer sind allgemein sinnvoll, ihre Verwendung für GUI-Entwickler imho verpflichtend. In der Regel reicht mir ein einfacher Texteditor, vor allem für Python, einen GUI-Designer aber würde ich nicht missen wollen. Das Aussehen einer GUI zu programmieren, ist langweilig, wenig intuitiv und aufwendig. Man muss blind entwerfen und daher zwischendurch immer das ganze Programm starten, nur um das GUI-Design zu überprüfen. Außerdem sollte man besser gleich beim ersten Versuch alles richtig machen, denn alles, was über triviale Änderungen hinaus geht, artet in mittelschweres Refactoring aus. Dieser Ansatz ist auch kaum geeignet, einem Anfänger Spaß an der GUI-Programmierung zu vermitteln. Schließlich muss man viel Dokumentation lesen und mit vielen Fehlern kämpfen, bevor man in Form einer funktionierenden GUI den ersten Erfolg verbuchen kann. Im Designer dagegen sieht man das Ergebnis unmittelbar, und kann zudem die GUI direkt verändern, ohne dass größere Änderungen am Quellcode erforderlich sind. Man kommt intuitiv ohne großen Aufwand zu einem greifbaren, direkt anwendbaren Anwendungsentwurf, welchen man dann nach und nach mit Funktionalität füllen kann, ohne sich in den Tiefen der GUI-Programmierung zu verlieren. Man lernt Schritt für Schritt einzelne Steuerelemente zu nutzen und kann sich auf das Wesentliche konzentrieren: Den asynchronen, ereignisgesteuerten Ablauf einer GUI verstehen zu lernen. Außerdem führt die Verwendung des Designers mehr oder weniger zwangsläufig zu einer rudimentären Trennung von Präsentation und Logik. Unter Verwendung des Designers lernt man viel eher, wie moderne GUI-Anwendungen entwickelt und strukturiert werden. Ich würde sogar soweit gehen, dass man beim manuellen Ansatz allenfalls lernt, wie man GUIs nicht programmiert. |