GentooForum.de

Wenn ich darf, dann will ich auch mal.

Also Du willst ein Spiel programmieren? Und Du willst es Plattformübergreifen (Linux/BSD,Windows,MacOS)?

Da ich für mich auch lange eine geeignete Sprache gesucht hatte, will ich Dir hier mal meine Erfahrungen mitteilen. Die gesetzten Anforderungen erfüllen viele Sprachen, aber ich hatte mich auf die bekanntesten konzentriert.

In meine engere Wahl kamen:
- Pascal (FreePascal)
- C
- C++
- D
- Ada
- TCL/TK
- Ruby
- Python

Die Krriterien für oder gegen die einzelnen Sprachen sahen so aus:
- Pascal (FreePascal)
einfach zu erlernen, Compiler für fast jede Sprache kosten los down zu loaden, viel Doku, große Community, der Compiler kann sehr viele Fehler finden, ist gut geeignet für "sonntagsprogrammier" (also für mich)
- C
hier habe ich mehr Zeit mit Fehlersuche verbracht als mit coden, denn C bietet dem Programmierer sehr viel Freiheiten, dem Anfänger besonders in sachen "Fehler machen", der compiler findet nur recht wenig fehler bzw. bezeichnet sie sehr ungenau, für Windows giebt es kaum freie Compiler
- C++
diese Sprache ist so komplex, das man die Vorteile nur ausspielen kann, wenn man jeden Tag damit zu tun hat also nix für "Sonntagsprogrammierer", für Windows giebt es kaum freie Compiler
- Java
diese Sprache ist so komplex, das man die Vorteile nur ausspielen kann, wenn man jeden Tag damit zu tun hat also nix für "Sonntagsprogrammierer"
- D
die Sprache ist recht neu, wird ghelobt, richtet sich aber eher an die C++- und Java-Programmierer
- Ada
hier gibt es wohl auch einen Windows-Compiler und zwei Linux-Compiler, und diese Sprache ist so aufgebaut das der Compiler so ziemlich alle Fehler finden kann, aber sie spielt in der gleichen Liga wie C++, Java und D mit, also auch nix für "Sonntagsprogrammierer"
- TCL/TK
das ist nicht die neueste Scriptsprache, aber eine geniale, sie ist sehr einfach zu erlernen und es gibt nur ein Binary (den Interpreter), man muss sich nie mehr Gedanken um Module machen, die dann auf der Zielmaschine (vielleicht beim Kumpel) nicht installiert sind
- Ruby und Python
sind Scriptsprachen, die etwas umfangreicher sind als TCL und durch Anlehnung an moderene Programmierparadigmen besonders für größere Projekte erdacht wurden
Ruby ist konzeptionell sauberer, aber Python programmiert sich so fließend von der Hand, als wenn man einen Brief schreibt

Wenn man sich in C++, Java, D oder Ada nur auf die Grundlagen stützt, braucht man oft für eine Aufgabe wesentlich länger als wenn man mit dem gleichen Wissen einer einfacheren Sprache die selbe Aufgabe lösen würde.
Diese großen Sprachen bringen erst richtig was, wenn man die ganzen Libs gelernt hat....

Basic lasse ich mal weg, da man sich damit nur das logische Denken versaut.
Wenn man etwas sucht, das nicht jeder kann, aber womit man nur noch einen Bruchteil der Programmierzeit für das selbe Projekt braucht, dann ist Haskell (ghc) die erste Wahl. Nach Untersuchungen der US-Navy ist man zwischen 9 mal und 24 mal so schnell mit dem Programmieren fertig, gegenüber C++. Aber man muss das funktionale Programmierparadigma erstmal verstehen....

Ich persönlich habe mich entschlossen mir FreePascal und Haskell mal näher anzuschauen und auszuprobieren, wenn ich das funktionale Programmierparadigma in meinen Kopf rein bekomme, dann Haskell, sonst eben FreePascal.
Von den Scriptsprachen kommt für mich nur TCL in Frage aber zum scripten reicht die einfache Shell (sh, nicht bash).


Viel Erfolg noch bei Deinem Vorhaben. Wenn Du Dich für eine Sprache entschieden hast, würde es mich interessieren für welche.

hallo,
ist ja doch schon ein wenig älter,
aber was ich nicht verstehe:

Zitat

C++,Java; diese Sprache ist so komplex, das man die Vorteile nur ausspielen kann, wenn man jeden Tag damit zu tun hat also nix für "Sonntagsprogrammierer"

Was ist denn an diesen Sprachen so viel komplexer als bei anderen?

Es ist doch nicht sinnvoll Programmiersprachen in komplex, leicht, schwierig oder sonstwas einzustufen (obwohl das gerne gemacht wird).

Das Programmieren an sich beinhaltet logische Einheiten aufzubauen und diese miteinander zu
verknüpfen (das kann man mit jeder Sprache lernen) und was die Sprachen unterscheidet sind
Syntax und Anwendungsgebiete(was heisst, kann ich Programmieren, ist die Sprache Nebensache(wobei es natürlich in den verschiedenen Sprachen schon Unterschiede gibt,
nur die Logik ändert sich ja nicht).

Also such ich mir doch eine Sprache danach aus, was ich damit machen möchte und nicht nach dem vermeintlichen "Schwierigkeitsgrad".

Zitat

Original von idefix
Was ist denn an diesen Sprachen so viel komplexer als bei anderen?
Es ist doch nicht sinnvoll Programmiersprachen in komplex, leicht, schwierig oder sonstwas einzustufen (obwohl das gerne gemacht wird).

Eigentlich hast Du recht: C und C++ sind eigentlich recht simple Sprachen. Aber: in keiner anderen Sprache wird es IMO dem/der (Anfänger-)ProgrammiererIn so leicht gemacht, schwerste Fehler in seine/ihre Programme einzubauen. Ich habe mir mehrfach den Mund fusselig geredet, um anderen Menschen, die gerade stolz ihr erstes C-Programm geschrieben hatten und sich über Segfaults bei anderen Benutzern wunderten, den Unterschied zwischen "Variable" und "Pointer auf Variable" u.ä. klar zu machen.

C++ und Konsorten verlangen zudem profunde allgemeine Kenntnisse der objektorientierten Programmierung. Nicht zufällig gibt es Firmen, die sich mit entsprechenden Schulungen eine goldene Nase verdienen.

Und: C++ (C reicht auch schon ) ins Gehirn von Leuten zu prügeln, die die letzten Jahrzehnte nur in COBOL programmiert haben, ist nahezu unmöglich...

Just my 2 ¢
Rudi

Dieses Jahr sind mir mehr Projekte an den Hals gehetzt worden als mir lieb ist und hab wegen diversen Umgebungbedingungen schon verschiedene Sprachen pauken müssen.

Nachdem ich eine Weile mit dem vollen Funktionsumfang von XSL(T) und XPath hantieren musste, fühlte ich mich mit dem Umgang von C++ in die Steinzeit zurückversetzt.
Wie rudib schon gesagt hat: Die Programmiersprache C/C++ bietet eine der benutzerfreundlichsten Fehlerquellen.

Da ich Monate davor Assembler intensiv gepaukt hatte, stelle ich immer wieder fest, dass der Code, den ich in C++ schreiben müsste, teilweise einfacher in Assembler mithilfe von Makros umsetzen kann. Da weiß man wenigstens, was die CPU macht.

Was ich mir wünsche wäre eine echte abstrakte Sprache mit der Abstraktion der ASN.1-Notation und dem hierarchischen Aufbau von XML.
Also eine Sprache, mit der ich logische Verknüpfungen miteinander Gruppieren kann, aber so, dass Logikfehler leicht zu finden sind.

Meist haben nur Skriptsprachen solche Fähigkeiten.

C ist für mich jedenfalls mit mehr Syntax garnierter Assembler.

Ihr habt da beide schon recht, meine Ansicht ist ja auch sehr allgemein und selbstverständlich hat jede Sprache ihre eigenen Tücken und Vorzüge.

Nur kann ich das mit "schwer zu lernen", kompliziert, komplex oder ähnliches nicht nachvollziehen.
Da das ja ein subjektiver Eindruck des Einzelnen ist.
Ob das dann für einen persönlich tatsächlich so ist muss man selber rausfinden.

Zitat

C++ und Konsorten verlangen zudem profunde allgemeine Kenntnisse der objektorientierten Programmierung.

Seh ich jetzt zB nicht unbedingt so, da C++ die objektorientierte Programmierung ja nur unterstützt.
Ich kann genauso gut C oo programmieren oder C++ nicht. Ob das dann effektiv ist steht auf einem
anderem Blatt

Zitat

Original von idefix
Ihr habt da beide schon recht, meine Ansicht ist ja auch sehr allgemein und selbstverständlich hat jede Sprache ihre eigenen Tücken und Vorzüge.

Nur kann ich das mit "schwer zu lernen", kompliziert, komplex oder ähnliches nicht nachvollziehen.
....

Ich will mal an einem Beispiel verdeutlichen, was ich meine.
Wenn man sich mit Pascal nur am Sonntagnachmittag beschäftigt (weil man damit halt nicht beruflich zu tun hat) und mit diesen Kenntnissen ein "Heimprojekt" schreiben will, das nicht gerade in einer Stunde reingehackt ist, dann geht es schneller
als wenn man sich mit
z.B. Java, mit der gleichen Einarbeitungszeit, an das gleiche Projekt macht.
Bei Java liegen zum Beispiel über 300 MB an Bibliotheken bei, alles Arbeit die schon getan wurde, Räder die man nicht ein zweites mal erfinden muss.... aber welcher Sonntagsprogrammierer setzt sich denn damit auseinander?
Keiner, die erfinden das Rad bei jedem Projekt neu. Weil die Lernzeit, um diese 300 MB in den Kopf reinzuprügeln einfach nicht machbar ist, wenn man damit nicht jeden Tag zu tun hat.

Und genau darum ist, für einen Sonntagsprogrammierer, eine Sprache besser geeignet, die vielleicht nicht für große Projekte geeignet ist, bei der es schwer ist ein 200 Mannstunden-Projekt auf mehrere Personen aufzuteilen
aber bei dem es leichter ist (quasi) das Rad jedesmal neu zu erfinden ... die Codezeilen flinker von der Hand gehen (=> kleinerer Sprachumfang).

Zitat

Original von Carminox
.....
Was ich mir wünsche wäre eine echte abstrakte Sprache mit der Abstraktion der ASN.1-Notation und dem hierarchischen Aufbau von XML.
Also eine Sprache, mit der ich logische Verknüpfungen miteinander Gruppieren kann, aber so, dass Logikfehler leicht zu finden sind.
.....

Mit einer ähnlichen Zielsetzung wird ja auch Haskell weiterentwickelt (wenn ich das richtig verstanden habe):
http://www.haskell.org/

yod@, mit dem Argument des Sonntagsprogrammierers hast du nicht ganz unrecht, aber selbst bei einem etwas größeren Projektchen stößt man gelegentlich auf Bibliothekszugriffe (z.B. Kernel-API).

Ich hab gegen C "geflamed", weil die Sprache wirklich nicht mehr der heutigen Zeit entspricht.

Die meisten Pro-Argumente für C, die mir immer wieder vor die Nase laufen:
"Hohe" Sprache mit der Fähigkeit plattformunabhängig hardwarenah schreiben zu können... *blabla*

Da hört's allerdings schon auf. Wenn man ein größeres Projekt zusammenfrickeln will, fangen die Probleme schon bei den "Sicherheitslücken" an, die hauptsächlich, wie ich letztens feststellen musste, durch Über- und Unterläufe verursacht werden. Der Code wurde, wen wunderts, in C geschrieben. Allein schon die Idee Strings nur mit einem NUL zu terminieren ist der reinste Blödsinn, da keine zusätzlichen Sicherungsmechanismen greifen können. Bestimmt behaupten jetzt einige, dass es damals bei anderen Sprachen so gehandhabt wurde, dass am Anfang des Strings ein Byte mit der Länge abgespeichert wurde, die, wegen dem Byte, nur 255 Zeichen lang sein konnte. Toll, man setze à la UTF den Wert FF als Signal für ein weiteres Byte für die Längenangabe.

Obwohl ich mit der Materie noch nicht so bewandert bin wie ein Diplominformatiker, krieg ich jetzt schon kopfweh über die gelegentliche Einfallslosigkeit von eben diesen.


P.S.: Haskell erinnert mich von der Syntax her an die Zuordnungsvorschriften für Funktionen.

Zitat

Da hört's allerdings schon auf. Wenn man ein größeres Projekt zusammenfrickeln will, fangen die Probleme schon bei den "Sicherheitslücken" an, die hauptsächlich, wie ich letztens feststellen musste, durch Über- und Unterläufe verursacht werden.

Das kommt daher, das die Leute sich nicht die Zeit nehmen, das ganze mit einem Memory Debugger zu testen...

Für systemnahe Programmierung kommt halt nur C in Frage. Für andere Anwendungen kann eine Sprache wie Java oder Ruby, die den Programmier von der Speicherverwaltung entbindet, die bessere Wahl sein.

Zitat

P.S.: Haskell erinnert mich von der Syntax her an die Zuordnungsvorschriften für Funktionen.

Das kommt daher, dass Haskell exakt mit diesem Gedanken entwickelt wurde. So sind halt funktionale Sprachen.

Gruß

Stareagle

Zitat

Original von stareagle
Für systemnahe Programmierung kommt halt nur C in Frage.

Aha. Für zuverlässige Datenbanken kommt also auch nur Microsoft SQL Server in Frage und mehr als 640 KB Arbeitsspeicher braucht ja auch keiner. Achja und der iPod wird ein Flop. *blabla*

Zitat

Für zuverlässige Datenbanken kommt also auch nur Microsoft SQL Server
in Frage und mehr als 640 KB Arbeitsspeicher braucht ja auch keiner.
Achja und der iPod wird ein Flop. *blabla*

Auch wenn du noch so oft anderer Meinung sein willst - ich stimme dem anderen Thread zu, das man C so oder so braucht.
Zu diesem Schluss kam ich aus vielen Blickwinkeln.

Der, der für mich persönlich am aktuellsten ist, ist folgender:

Ich schreibe eigentlich ausschliesslich in Ruby. (Shell Skripte, und ein wenig php aus legacy Gründen)
Die Performance Nachteile sind für mich 0 Kriterium - die Zeit die ich mir erspare gegenüber heftigeren Sprachen wie Java ist Zeit die ich anders nutzen kann. (Da kaufe ich lieber einen etwas besseren Rechner )

Leider gibt es Grenzen, und das betrifft vor allem die Unmenge an C Code.
Xorg, Gnome, Linux Kernel, glibc, dietlibc, utillinux, coreutils, binutils, busybox.
Praktisch die Foundation von Linux. (Ja, kein DesktopUser braucht notwendigerweise busybox/uclibc, aber ich mag
eigentlich nicht von glibc abhängig bleiben ... mir ist das developmental model von glibc zu Firmen-abhängig
und ich glaube den maintainern da einfach nicht ... Konkurrenz ist sowieso gut, sehe das bei pcc gegenüber gcc
ähnlich.)

Warum brauche ich C?

Zum einen weil ich Bindings für Ruby nur über C wirklich machen kann (C++ geht natürlich auch, nutzen aber viel weniger als Ruby+C, zudem ist Ruby hauptsächlich in C geschrieben)
Für einen Windowmanager in Ruby bräuchte ich z.Bsp sehr gute Kenntnisse von nicht nur xorg, sondern natürlich auch von C. (Die Dokumentation von Xorg ist eine Frechheit... ich hoffe das es irgendwann einmal echte Konkurrenz zu Xorg gibt ... Gnome vs KDE gibts ja auch, und das ist gut, aber alle sind von Xorg abhängig, und Xorg kämpft an 100 Stellen mit Problemen...)

Dazu gibt es immer wieder Komponenten die schneller gehen *müssen*, und ohne C ist da kaum mehr etwas über Ruby (oder Python) verbesserbar. Mit Ruby-inline kann man einfach den C code hinwerfen und hat spürbare Performance Verbesserungen.

Es gibt darüberhinaus mehrere Gründe warum C so wichtig ist.
Da ändert auch .NET nichts daran, auch D wird nichts daran ändern. Ich sage übrigens nicht das C eine besonders
gute Sprache ist ... aber es ist halt noch immer historisch sehr sehr wichtig

Meiner Meinung nach ist C auch schwieriger (!) als C#, vor allem wegen malloc und Konsorten, aber die komplizierteste Sprache ist sicherlich C++. Und hässlich wie die Pest - da ist ja XML fast schön wenn ich mir Templates ansehe (PS: Das sagt natürlich 0 darüber aus, ob C++ eine gute oder eine schlechte Sprache ist, lediglich das sie KOMPLEX und NICHT SCHÖN ist, wobei sich letzteres auf eben Templates bezieht. C ist auch nicht besonders schön, aber bei weitem nicht so komplex. Ich kann da jedem die Frequently Queried Answers über C++ empfehlen)