Programmiersprachen/Umgebungen

[marcov]

Mit welcher programmiersprache kann man am meisten machen? und welche programmierumgebung sollte man für diese sprache am besten verwenden?
außerdem sollte das ganze schon ausgereift sein und am besten sehr gut dokumentiert.

Mit jeder völlig turing-fähigen Programmiersprache kannst du jedes Problem (das reale Computer lösen können) lösen. Ich würde also Assembler vorschlagen!

Aber es gibt immer das Unterschied zwischen Theorie und Praxis: In Theorie ist Turing-fähig nützlich, im Praxis hat man nie unendlich schnelle Computer, unendliche Speicher, und, wichtiger unendliche Programmier Zeit.

[carli]

Aber es gibt immer das Unterschied zwischen Theorie und Praxis: In Theorie ist Turing-fähig nützlich, im Praxis hat man nie unendlich schnelle Computer, unendliche Speicher, und, wichtiger unendliche Programmier Zeit.

Was in der Praxis aber mehr zählt ist der Komfort, zu entwickeln. Dazu zählen folgende Dinge:
- habe ich genug syntactic sugar in der Programmiersprache?
- habe ich Anbinung an alle Bibliotheken, die ich benötige?
- lässt sich das Build-System einfach aufsetzen?
- wie schnell ist ein Patch kompiliert und getestet?
- wie gut kann ich debuggen?

[marcov]

Aber es gibt immer das Unterschied zwischen Theorie und Praxis: In Theorie ist Turing-fähig nützlich, im Praxis hat man nie unendlich schnelle Computer, unendliche Speicher, und, wichtiger unendliche Programmier Zeit.

Was in der Praxis aber mehr zählt ist der Komfort, zu entwickeln. Dazu zählen folgende Dinge:
- habe ich genug syntactic sugar in der Programmiersprache?
- habe ich Anbinung an alle Bibliotheken, die ich benötige?
- lässt sich das Build-System einfach aufsetzen?
- wie schnell ist ein Patch kompiliert und getestet?
- wie gut kann ich debuggen?

Das ist nicht unbedingt wahr. Das hängt davon ab was man tut. Zb wenn man Firmware macht für Medizinisch orientierte Maschinen ist alles ganz anders. Kontrolle und Sicherheit ist alles.

Nicht alle Software Entwicklung ist Standard (und die nicht-Standard Jobs zahlen besser

[diogenes]

Mit welcher programmiersprache kann man am meisten machen? und welche programmierumgebung sollte man für diese sprache am besten verwenden?
außerdem sollte das ganze schon ausgereift sein und am besten sehr gut dokumentiert.

Also, um das Technische voweg zu nehmen: Mit jeder Turing-vollständigen Sprache läßt sich alles machen, solange die Hardware mitmacht.

Fragt sich bloß, und das ist schon weniger technisch, ob Du mit CoBOL technisch-wissenschaftliche Probleme lösen willst. Willst Du nicht. Fazit: Kommt darauf an, was Du magst und womit Du arbeiten darfst oder mußt. (Lots of C# around, not to mention CoBOL ...)

Das Problem "Wie sag ich's dem Computer?" hat so viele Lösungen, daß dem Lebenserfahrenen die Ahnung beschleicht, daß keine davon wirklich gut ist, zumindest nicht perfekt. Nicht einmal FPC/Lazarus, um hart, aber ehrlich zu sein. Sonst würde ja jeder DIE Programmiersprache verwenden und nicht eine der tausenden, die's jetzt gibt. Ich programmiere mit FPC/Lazarus, weil's mir liegt, nicht, weil ich es für ideal halte. Es halte es für das Beste, aber für mich, nicht für (Name einsetzen), der lieber in C++ codet.

Stichwort Doku:
Jeder, der schon Selbstgecodetes aus dem Netz gesaugt und verwendet hat, und FPC/Lazarus gehört eigentlich dazu, weiß, daß die Begeisterten Programmierer gerne programmieren, aber nicht dokumentieren oder Gebrauchsanweisungen schreiben. Folge: Die Doku wächst langsamer als die Fähigkeiten der zu dokumentierenden Software. Damit muß man leben oder die Doku selbst schreiben. Bist eingeladen

[ErnstVolker]

.

[Christian]

Ich möcht noch kurz was zur CIL hinzufügen.
Meiner Meinung nach werden sich die Runtime Interpretierten Konstrukte nie durchsetzen.
Sun hat vor 20 Jahren getönt das in 5 Jahren nur noch thin Clients an Arbeitsplätzen stehen werden und der Rest aus dem Netz kommen wird
(heute würde man Cloud sagen ).
Java würde das alles lösen.
20 Jahre danach ist der Java Hype gebrochen und es verliert an Stellenwert.
.net soll das selbe von MS aus machen. Eine tolle Idee nur meiner Meinung nach nie Umsetzbar.
Die Leistung moderner Computer reicht für soche späße noch nicht aus. Immernoch ist es schwirig
Menüs in heutiger Grafischer Qualität flüssig ohne 3D Beschleunigung darzustellen ganz davon zu schweigen
das da auch noch interpretierter Code genutzt werden soll.
Android Apps nutzen alle möglichen Tricks um auf aktueller Hardware halbwegs flüssig zu laufen
immer häufiger wird das NDK genutzt um Java zu umgehn.
Und man muss dabei sehn solange es keinen Quantensprung in der Technologie gibt und wir bei
Transistoren aus Silizium bleiben werden wir die 5Ghz Grenze nicht brechen.

Und selbst wenn es plötzlich eine Technologie gibt die einen einzelnen Core mit 50 Ghz betreiben kann
wird niemand wirklich interpretierten Code einsetzen wollen weil das ganze mit nativem Code nur 1/10.
des Stroms braucht.
Ich sehe es immernoch nicht kommen das Java/.net/Visual Basic jemals die Rechentechnik erobern.
Eher sehe ich kommen das Android in Version 3.5 reine native Linux Applikationen zulässt.

[mschnell]

Und selbst wenn es plötzlich eine Technologie gibt die einen einzelnen Core mit 50 Ghz betreiben kann
wird niemand wirklich interpretierten Code einsetzen wollen

CIL ist kein "interpretierter Code". Die Idee hinter CIL ist:

- Jeder moderne Compiler erzeugt in einem ersten (sehr aufwändigen) Schritt einen Architektur-unabhängigen Zwischencode und dann in einem zweiten (weniger aufwändigen) Schritt den Systemcode des Zielsystems.

- Bei CIL werden diese Schritte getrennt. Bei der "Compilierung" wird nur der erste Schritt ausgeführt, der zweite Schritt erfolgt auf dem Zielsystem beim Laden des Programms in den Speicher. Die Ausführung des Programms ist also (mit Abstrichen wegen meist schlechterer Optimierung (z.B. auch wegen Garbage-Control) als bei "echten" Compilern) so schnell wie native Code. Der Ladevorgang dauert wesentlich länger. Bei Programmen, die nicht komplett in den Speicher passen, wird möglicherweise öfters geladen (und nach-übersetzt) und es kann dann deutlich langsamer werden.

Es gibt für CIL auch einen Nach-Compiler, der auf dem Zielsystem läuft und den übersetzten Code in einer Datei ablegt. Dann hast Du native-Code der wie ein exe geladen wird.

Es gibt für CIL natürlich auch einen wirklichen Byte-Code Interpreter. Der wird aber eigentlich nur während der Entwicklungs-Phase des Frameworks (z. B. Portierung von Mono auf eine neue CPU) verwendet.

-Michael

[Euklid]

Der Witz ist, dass man überall ließt, dass es bzgl. des CIL Probleme mit der Abwärtskompatibilität gibt. D.h. Verwendet der Entwickler eine relativ aktuelle Version um sein Programm zu schreiben, kann der von ihm erzeugte Zwischencode unter Umständen eben nicht auf Zielsystemen laufen, die eine ältere Version des Frameworks enthalten. Ziemlich bescheuert also.

Die oft versprochene Architektur-Unabhängigkeit, die mschnell auch anspricht, kann es natürlich nur dann geben, wenn genügend Zielarchitekturen von dem Framework unterstützt werden. Wenn man sich aber mal bei .net umschaut, kümmert sich Microsoft nur um die hauseigenen Systeme. Alle anderen Systeme hinken der Entwicklung einfach hinterher. D.h. Entwickler, die ihre Programme mit dem .net-Framework erstellen, werden die unter Umständen garnicht mit Mono zum Laufen kriegen, da Mono .net hinterher hinkt und auch immer hinterherhinken wird, weil MS nunmal bzgl. .net den Standard setzt und nicht Novell. Dadurch geht die ganze versprochene Plattformunabhängigkeit flöten: Die Programme können nur auf den Systemen ausgeführt werden, auf denen eine kompatible Version des Frameworks installiert ist.

Generell, wenn wir .net betrachten fällt auf: Es ist rießig groß. Um ein .net-Programm auf einen PC zu installieren, muss zuvor das über 60 MB große Framework installiert sein, damit das überhaupt geht. Was für ein Aufwand! Und es ist ja nicht so, dass man es einmal installiert hat und dann für immer alle .net-Programme ausführen kann. Vielmehr muss man seine Bibliotheken am Laufenden halten, immer wieder diese 60 MB herunterladen, damit neuste Versionen der Programme nicht an der mangelnden Abwärtskompatibilität der .net-Versionen scheitern.

Zudem wäre da noch ein weiteres, für Firmen wohl viel gravierenderes Problem zu nennen. Der Zwischencode ist nämlich im Grunde nichts anderes als ein komprimierter und mit bekannten Algorithmen verschlüsselter Quelltext. Wenn man sein Programm also mit .net schreibt und veröffentlicht, kann man es gleich als OpenSource bezeichnen, da das Rückübersetzen - im Gegensatz zu nativen Binärcode - hier mit den passenden Toolz ein Leichtes ist. D.h. der Quelltext der mit .net geschriebenen Programme liegt jedem, der das Programm erhält und sich ein bisschen auskennt, offen. Und schon gehen sämtliche streng behütete Betriebsgeheimnisse flöten...

... nun kommt in der Praxis hinzu, dass .net-Programme nach vielen Internet-Berichten in der Ausführung(!) als um das 2 bis 4-fache langsamer beschrieben werden als native Programme - ganz zu schweigen von den von mschnell bereits genannten Ladezeiten und dem Speicherverbrauch.

Was ist also das Ende vom Lied?
CIL wird sich bei denen durchsetzen, die sich auf Windows-Systeme konzentrieren, denen Firmengeheimnisse sowie kurze Ladezeiten und eine schnelle Ausführung des Programms nicht so wichtig sind.

Zu Java: Ich benutze Ubuntu 9.04. Welches der dort standardmäßig installierte Programm wurde mit Java geschrieben? Meines Wissens nicht eines. Java ist in meinen Augen nicht bezüglich praktischer Programme, sondern vor allem wegen Web-Anwendungen so weit verbreitet. Sogar der Unterbau von Google Chrome (wie z.B. die Javascript-Enginge) wurde mit C++ und nicht mit Java geschrieben. Weshalb nicht mit Java? - Weil es zu langsam ist. Java leidet in dieser Hinsicht unter dem selben Problem wie .net, nur mit einem Unterschied: Es wird seit 15 Jahren daran entwickelt. Bis heute hat man es nicht fertig gebracht, Java schnell zu machen. Ich habe ernste Zweifel daran, dass dies überhaupt gelingen kann.

Meiner Meinung nach handelt es sich bei diesen Technologien um neumodische Ideen, die in der Theorie vielleicht ganz nett klingen, beim näheren Hinsehen aber mehr Nachteile als Vorteile bringen. Im Endeffekt fährt denke ich jeder gut damit, der nicht diesem Hype aufspringt.

- Euklid

[Christian]

@mschnell
teoretisch ist das sicher richtig, aber wenn ich .net ode rjava Programe benutze fühlen diese sich viel langsamer an als nativer code
und das trots dessen das sich die programmierer dieses effektes sicher bewusst sind und sicher versuchen das zu vermeiden.
.net und java kommen Geschwindigkeitstechnisch keinesfalls an nativen Code heran. Das ist jednefalls meine subjektive Erfahrung damit.

Und die vielgepriesene Plattformunabhängigkeit wird gegen Frameworkabhängigkeit getauscht.
Wenn ein Natives Programm also auf allen i386 kompatiblen Prozessoren ausgeführt werden kann so
kann ein .net 2.0 Programm nur noch auf diesem framework laufen incl aller Abhängigkeiten.

[marcov]

Und selbst wenn es plötzlich eine Technologie gibt die einen einzelnen Core mit 50 Ghz betreiben kann
wird niemand wirklich interpretierten Code einsetzen wollen

CIL ist kein "interpretierter Code". Die Idee hinter CIL ist:

- Jeder moderne Compiler erzeugt in einem ersten (sehr aufwändigen) Schritt einen Architektur-unabhängigen Zwischencode und dann in einem zweiten (weniger aufwändigen) Schritt den Systemcode des Zielsystems.

- Bei CIL werden diese Schritte getrennt. Bei der "Compilierung" wird nur der erste Schritt ausgeführt, der zweite Schritt erfolgt auf dem Zielsystem beim Laden des Programms in den Speicher. Die Ausführung des Programms ist also (mit Abstrichen wegen meist schlechterer Optimierung (z.B. auch wegen Garbage-Control) als bei "echten" Compilern) so schnell wie native Code. Der Ladevorgang dauert wesentlich länger. Bei Programmen, die nicht komplett in den Speicher passen, wird möglicherweise öfters geladen (und nach-übersetzt) und es kann dann deutlich langsamer werden.

Das ist nicht CIL an sich, aber (verpflichte) JIT. Aber nicht alle native Code ist gleich. Das Nachteil ist das den Jit nicht so viel seit fuer Kompilieren hat, der Vorteil ist das er den exakten Prozessor (Serien) weißt(*), und, wichtiger, Execution data Profilen kann nutzen.

Typisch compiliert CIL erst ein sehr langsame Code, und geht dann die Hotspots sukzessiv verbessern.

(*) Ist typisch nicht so interessant als mache denken. Die größte Verbesserungen in Benchmarks kommt vom Prozessor spezifischen Runtime Libraries (lowlevel Primitiven wie Move und pos() usw), nicht von der User compilierter Code.

Es gibt für CIL auch einen Nach-Compiler, der auf dem Zielsystem läuft und den übersetzten Code in einer Datei ablegt. Dann hast Du native-Code der wie ein exe geladen wird.

Ja, aber das bringt nicht so viel. Hoechstens ein bisschen startup zeit (aber es bleibt immer langsamer).

Die große Verzögerungen in Java kommen durch ein Sprache der mehr "highlevel" ist (mehr mechanisch kopieren von Data was nicht unbedingt nötig ist), und, vor allem GC. Beide machen Programmieren etwas einfacher (aber darüber, und wie viel kann man sich streiten), aber sind Systematisch langsamer.

Es gibt für CIL natürlich auch einen wirklichen Byte-Code Interpreter. Der wird aber eigentlich nur während der Entwicklungs-Phase des Frameworks (z. B. Portierung von Mono auf eine neue CPU) verwendet.

Das ist neu für mich. Ich dachte CIL war nur sehr schwierig zu Interpretieren weil die Interpretierung Typ Interferenz benötigt (in Gegensatz zu (ältere?) Java bytecode, der für value- Type unterschiedliche bytecodes definiert). Ist es fürchterlich Langsam?

[carli]

Mal ein kleiner Spaßverderber punkto Geschwindigkeit:
Freepascal hat für x86_64 nicht mal einen Peephole optimizer, die Units sind im FPC-Source leer. Auch die i386-Variante hat aus irgendwelchen Gründen ihre Optimierungen abgeschalten.

Die gute Nachricht hingegen ist, dass sich Freepascal im Gegensatz zu Java (und sogar C++) noch extrem steigern kann, wenn sich wirklich mal jemand an den Compiler-Code setzen würde.

Einen anderen Ausweg der Plattformunabhängigkeit sehe ich in der LLVM:
Die LLVM ist eine Compilerinfrastruktur, die gute Optimierer bereitstellt und sowohl JIT- als auch statischen Code erzeugen kann. Für den FPC ist übrigens auch ein LLVM-Backend geplant. Die LLVM kompiliert schnell und extrem gut, was den gewollten Leistungsschub für Freepascal liefern sollte.

[ErnstVolker]

.

[marcov]

Einen anderen Ausweg der Plattformunabhängigkeit sehe ich in der LLVM:
Die LLVM ist eine Compilerinfrastruktur, die gute Optimierer bereitstellt und sowohl JIT- als auch statischen Code erzeugen kann. Für den FPC ist übrigens auch ein LLVM-Backend geplant. Die LLVM kompiliert schnell und extrem gut, was den gewollten Leistungsschub für Freepascal liefern sollte.

Das sind die Vorteile. Die Probleme sind aber noch immer denselben als mit GCC, die auch solche Ambitionen hat. LLVM is nur eine Modernisierung des Konzept.

Die Probleme sind das es extrem schwierig ist ein Projekt eines Umfangs wie FPC/Lazarus von ein ander, sehr Umfangreich Projekt als LLVM (oder GCC) abhängt. Das bezeichnet das LLVM's API extrem stabil sein muss (nicht nur in Detail, aber auch über eine Zeit von 5 Jahre und länger). Eben wann das passieren wurden, ist das noch immer 5 Jahren+ im Zukunft, und muss LLVM zuerst beweisen es sei ein Projekt das bleibt.

Siehe selbst .NET, 1.1 und 2.x sind nicht kompatibel, und MS ist ein Champion im Kompatibilitäts Bereich. (im Gegensatz zu Apple seit Jobs da ist)

Darüber kommt das Problem ist das ein Projekt wie FPC/Lazarus umstellen auf LLVM nicht wirklich Praktisch ist.

[carli]

Die Probleme sind das es extrem schwierig ist ein Projekt eines Umfangs wie FPC/Lazarus von ein ander, sehr Umfangreich Projekt als LLVM (oder GCC) abhängt. Das bezeichnet das LLVM's API extrem stabil sein muss (nicht nur in Detail, aber auch über eine Zeit von 5 Jahre und länger). Eben wann das passieren wurden, ist das noch immer 5 Jahren+ im Zukunft, und muss LLVM zuerst beweisen es sei ein Projekt das bleibt.

Die LLVM ist inzwischen schon extrem weit verbreitet, viele der großen Scriptsprachen, darunter Python und LUA, haben inzwischen einen LLVM-Unterbau, der mesa-Grafikkartentreiber nutzt die LLVM für die Shader, das OpenJDK basiert auf der LLVM, clang sowieso.

markov: kann es sein, dass du google translate benutzt? deine Sätze sind so komisch.

[mschnell]

D.h. Entwickler, die ihre Programme mit dem .net-Framework erstellen, werden die unter Umständen garnicht mit Mono zum Laufen kriegen,

Das ist doch nur logisch.

Wenn Framworks verschiedener Hersteller und in verschiedenen Versionen verwendet werden sollen, kann der Programm-Entwickler natürlich nur den kleinsten gemeinsamen Nenner der Features verwenden.

Dass Entwicklungs-Umgebungen (wie die von Microsoft) keine Möglichkeiten bieten, die verwendbaren Features einzustellen, so dass die notwendigen Einschränkungen bei der Programm-Entwicklung direkt abgeprüft, und nicht kompatible Programmierung gar nicht erst angeboten oder automatisch umschifft wird ist Ignoranz, "schlechter Stil" oder Bosheit des Herstellers. _Dagegen_ sollte man sich natürlich wehren (wenn möglich). Das spricht aber nicht gegen das Prinzip, das CIL zugrunde liegt.

-Michael