Ich hab Angst...

DEvent

bauerb schrieb:

Aber versicuh mal als "nur Eclipse-User", wie du sie nennst, ein Projet mit 20 Mann-Jahren zu realisieren. Er wir kläglich scheitern.
Programmieren ist nicht das beherrschen einer Programmiersprache. Programmieren ist logisches Denken, Anwenden von Design Patterns und viel Erfahrung.

Verstehe nicht ganz worauf du hinaus willst. Meinst du Eclipse eigenet sich fuer keine enterprise Anwendungen?

Eclipse alleine reicht da auch nicht, man braucht Version Control Software, Unit Testing, Quality Metrics Tools, Issee Management Tools, Tech Doc Tools, und was weis ich nicht alles.

Aber so eine grafische Programmiersprache ist doch auch nur ein Textersetzer. Es wird ja wohl niemand auf die Idee kommen eine eigenen Compiler dafuer zu bauen, sondern es wird eine Sprache wie Java, Python, Ruby verwendet. Dann wird aus der Grafik die der User zusammenklickt Programme in diesen Sprachen erstellt.

UML Tools machen das ja z.B., Datenbank-Designer, GUI-Editoren.

Helium schrieb:

Vielleicht haben wir dann irgendwann nicht mehr millionen von austauschbaren ahnungslosen Java-Dronen, sondern millionen von austauschbaren ahnungslosen Typen, die auf ihren riesen Touchscreens grafische Elemente hin und her schieben. Na und?

Wie soll den dieses graphische Elemente hin und her schieben aussehen, damit man damit alle möglichen Programme erstellen kann und nicht nur Speziallösungn? Sowas wie UML reicht da ja bei weitem nicht aus und ist auch nicht wirklich gut geeignet Algorithmen darzustellen. Ich kann mir da nicht wirklich was vorstellen. Sowas wie für Variablen, Scheifen und Bedingungen ein paar Icons zu machen die man dann so zusammensetzt wie jetzt Code mit Text würde zwar gehen, aber nichts besser machen, nur bunter.

zero_x

Hallo ceplusplus@loggedoff,

C++ bleibt eine mächtige Sprache! Man kann nicht einfach sagen das die Programmiersprache aussterben wird. C/C++ ist eine etwas ältere Sprache, aber wird es noch lange geben. Du brauchst keine Angst zu haben, denn die Sprache wird es noch lange geben. Man kann zu jeder Programmiersprache sagen das es Vor- und Nachteile hat. Für die Entwicklung stellt sich z.B. C# oder andere Programmiersprachen sehr gut für den Einsatz! Mit C++ hat man mehr Möglichkeiten was andere Sprachen nicht haben. Man kann so sagen wenn man C++ beherrscht, versteht man auch jede andere Programmiersprache. Fang mit C++ an und du wirst merken das es eine sehr tolle Programmiersprache ist, aber kompliziert! Ich denke jeder hat die erfahrung gemacht. C++ ist unteranderem sehr performant, was andere Sprachen nicht sind. Alles ist eine Ansichtssache... Aber fang mit C++ an! Wie ich schon sagte ist die Entwicklung von Programmen mit C++ nicht das beste, wobei .NET Sprachen mehr Möglichkeiten haben. Mit C++ hast du in anderen Bereichen mehr Möglichkeinten. Mach dir keinen Kopf ;).

Zero_x

Natürlich reicht es nicht aus, einfach nur Text durch Icons zu erstzen. Das Tool muss natürlich auch zus. Logiken unterstützen. Z.B. bestimmte Kontexte erkennen. Wenn ich die Codecompletion von Eclipse benutze, ist diese meistens sehr schlau. Z.B. weiß sie, was sie mir anzeigen soll, wenn ich:

JFrame f = new

Das Codecompletion weiß, das es mir grafisch nur die Typen anzeigen soll, die vom Typ JFrame sind. Alles andere macht keinen Sinn. Und DAS ist sehr wohl eine Hilfe, um mir das Denken abzunehmen.

Aber ob da jetzt JFrame steht oder ein JFrame-Icon zu sehen ist, ist am Ende irrelevant. Es kann aber auch eine Kobination aus beidem sein, ein JFrame-Icon plus einer kleinen Bezeichnung "JFrame" dazu.

Ich denke nicht, das es in dem Tool um Lego-Bilder geht. Grafisches Tool kann auch Texte enthalten. Die heutigen GUIs (G für Grafik!) enthalten trotzdem Text.

Helium

ahahahahaha schrieb:

Wie soll den dieses graphische Elemente hin und her schieben aussehen, damit man damit alle möglichen Programme erstellen kann und nicht nur Speziallösungn? Sowas wie UML reicht da ja bei weitem nicht aus und ist auch nicht wirklich gut geeignet Algorithmen darzustellen. Ich kann mir da nicht wirklich was vorstellen. Sowas wie für Variablen, Scheifen und Bedingungen ein paar Icons zu machen die man dann so zusammensetzt wie jetzt Code mit Text würde zwar gehen, aber nichts besser machen, nur bunter.

Wie es aussehen wird? Keine Ahnung, guck dir doch einfach ein paar Research-Projekte an, wie z.B. Subtext (am besten einfach direkt das Video ansehen). ...

DEvent schrieb:

Aber so eine grafische Programmiersprache ist doch auch nur ein Textersetzer. Es wird ja wohl niemand auf die Idee kommen eine eigenen Compiler dafuer zu bauen, sondern es wird eine Sprache wie Java, Python, Ruby verwendet. Dann wird aus der Grafik die der User zusammenklickt Programme in diesen Sprachen erstellt.

Natürlich wird es Compiler für diese grafischen Programmiersprachen geben. Ich denke da nicht an Codegeneratoren, MDA oder so'n Kram, sondern echte grafische Programmiersprachen.
Vielleicht nutzen sie die selben VMs wie textbasierte Programmiersprachen, so wie jetzt schon viele Sprachen "nur" Bytecode für die JVM, CLR, LLVM, Parrot oder sonst was generieren. Gerade bei der JVM wird doch derzeit viel Diskutiert, wie man sie erweitern kann, damit sie ein besseres Ziel für viele verschiedene Sprachen ist.

Unix-Tom

SAP macht ja nichts anderes.
Man kann seine eigene Oberfläche erstellen.
Sicherheit läuft alles im Hintergrund.
Man braucht keine Programmierer mehr.
Wenn ich mir aber ansehe wieviele SAP-Spezialisten benötigt werden und wie teuer die sind dann .....

JimmydaMage

Solange hier nur mit Halbwissen um sich geworfen wird, kann ich ja auch mein eigenes dazuwerfen
Also, grafische Programmierung, wie ich sie kenne (und der OP sie wohl gemeint hat), hat nichts mit GUI zusammenklicken oder mit der Entwicklung von vollwertigen Anwendungen zu tun. Das Ganze findet eher im Bereich Steuerungs-/Regelungstechnik (zum Beispiel im Auto) seinen Einsatz. Hier mal eine Beispiel, wie sowas aussehen kann. Dabei wird eine Steuerungs-/Regelungslogik aus miteinander verbundenen Funktionsblöcken zusammengeklickt. Diese Logik lässt sich wiederum zu einem Block zusammenfassen und in einem höheren Kontext darstellen, was die ganze Sache natürlich übersichtlicher als einen handgeschriebenen Code macht. Die eigentliche Entwicklung erfolgt hardwareunabhängig, zum Testen steht eine entsprechende Laufzeitumgebung innerhalb des Programmpaketes zur Verfügung, die es über Eingabe-/Ausgabemodule bequemt ermöglicht, während des Programmablaufs die Parameter darzustellen/zu ändern. Wenn das Prototyping abgeschlossen ist, kann dann direkt aus dem Programm C-Code erzeugt werden, der mit dem entsprechenden Compiler auf die Zielplattform umgesetzt wird, was natürlich den Vorteil hat, das ohne große Schmerzen die unterliegende Harware getauscht werden kann, bzw. ggf. auch Funktionsblöcke zwischen den Einheiten eines verteilten Systemes bewegt werden können...

Grüße

Martin

Helium schrieb:

ahahahahaha schrieb:

Wie soll den dieses graphische Elemente hin und her schieben aussehen, damit man damit alle möglichen Programme erstellen kann und nicht nur Speziallösungn? Sowas wie UML reicht da ja bei weitem nicht aus und ist auch nicht wirklich gut geeignet Algorithmen darzustellen. Ich kann mir da nicht wirklich was vorstellen. Sowas wie für Variablen, Scheifen und Bedingungen ein paar Icons zu machen die man dann so zusammensetzt wie jetzt Code mit Text würde zwar gehen, aber nichts besser machen, nur bunter.

Wie es aussehen wird? Keine Ahnung, guck dir doch einfach ein paar Research-Projekte an, wie z.B. Subtext (am besten einfach direkt das Video ansehen). ...

Ja, sieht irgendwie so aus wie ich es mir gedacht hab. Programmiersprache in bunt, aber nichts neues, was Programmieren viel einfacher macht.

JimmydaMage schrieb:

Hier mal eine Beispiel, wie sowas aussehen kann.

Ich kenne aber auch Fälle, da wird Ascet nur zum malen der Bildchen eingesetzt, der Code wird dann in Indien "generiert"

muemmel

Hi,

wo bitte ist der wesentliche Unterschied zwischen Bildchen malen bzw. zusammenschubsen, Quelltext mit IDE-Unterstützung erstellen und programmieren von Hand. In jedem Fall muß einer davor sitzen der weiß wie es geht und was wie muß. Die Programme nehmen einem nur die eintönige Routinearbeit ab, wissen was wie soll muß man aber immer noch selber. Insofern ist höchstens der Arbeitsplatz des reinen Codierers in Gefahr.
Softwareentwicklung ist nun mal primär nicht Codeschreiben (auch wenn die meisten Fachinformatiker das gerne so sheen wollen). Softwareentwicklung ist Logik in die Abläufe reinbringen, und festlegen was wie soll, das kann (auf lange Zeit) kein Computer.
Irgendwann vor ca 10 Jahren hat mri damals schon der Mann einer Ex-Maus weismachen wollen, daß sie in Canada ein Softwareprojekt hätten was alles kann und was mich überflüssig macht. Verdiene aber mit Byteschubsen immer noch mein Geld.

Gruß Mümmel