Programmier Sprach Auswahl
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Ein immer wiederkehrendes Thema in Online-Foren bzw. eine Routine-Aufgabe in Projekten ist die Auswahl einer für die Aufgabe und die Beteiligten optimalen Programmiersprache. In einer sehr allgemeinen Form stellen diese Frage Programmiereinsteiger, die entweder nach ihrer ersten Programmiersprache suchen, oder nach ersten Erfahrungen mit Sprache X nun die ultimative Sprache für ihre Zukunft - z. B. für maximale Chancen am Arbeitsmarkt - suchen. Bei anderen Projekten stellt sich die Frage nicht, weil die Auswahl durch Fremdeinflüsse (z. B. Pflichtenheft, Kundenwunsch, Managemententscheidung, Kursvorgabe, vorhandenes Know-How) schon vorgegeben ist. Tendenziell ist die Frage nach der jeweils richtigen Programmiersprache aber allgegenwärtig.
Nachdem es viele verschiedenen Perspektiven gibt, nach denen man Programmiersprachen bewerten kann (von der Portabilität bis zur Gratis-Verfügbarkeit), kann es keine allgemein "beste" ProgrammierSprache geben. Eine pragmatische Möglichkeit wäre, typische Perspektiven mit Anwendungsschwerpunkten und jeweiligen Favoriten bzw. Entscheidungskriterien herauszuarbeiten. Die spezifische Reihung könnte man dann durch eine numerische WikiMehrfachAbstimmung herstellen.
Jeder ist eingeladen, besonders diese kontroverse Seite mitzugestalten.
Betrachtete Eigenschaften:
- Ausgereiftheit
- Herstellerunabhängigkeit
- Kosten (schulischer, nicht-kommerzieller, kommerzieller Einsatz)
- Modernität (wie sehr entspricht die Sprache heutigen Spracherwartungen)
- Performance
- Platzbedarf (inkl. Runtime, was muss man verschicken oder auf eine CD packen)
- Portabilität 1 (auf wievielen Systemen läuft das Programm unverändert)
- Portabilität 2 (für wieviel Systeme gibt es jeweils Compiler)
- Stabilität (wird das Programm in X Jahren auch noch laufen)
- ...
Kandidaten im engeren Sinn:
- Ada, Basic, C, C++, C#, Delphi (Pascal), Java, Perl, Python, Smalltalk, ...
Außenseiter für Spezialanwendungen:
- Assembler, Eiffel, Haskell, JavaScript, Lisp, PHP, Prolog, ...
Außenseiter aktuelle Neuentwicklungen:
Außenseiter veraltete Sprachen:
Akademische Softwareentwicklung  |  |
Im allgemeinen besteht an Universitäten der Bedarf für das Arbeitsleben (gängige Sprachen) auszubilden und anderseits dem "Profilierungsbedarf durch Komplexität" gerecht zu werden. Die Kostenfrage stellt sich wegen der Verfügbarkeit preiswerter Lizenzen oder freier Software kaum.
Favoriten:
In Spezialbereichen:
- Lisp (AI)
- Eiffel (OO, Methodologie)
- C (OpenSource, Linux)
- ..
| Datenbankanwendungen/Kommerzielle Anwendungen | |
Für Datenbankanwendungen stehen meist keine hochqualifizierten Mitarbeiter zur Verfügung. Integrierte und visuelle Entwicklungsumgebungen dominieren. Anwendungen werden oft sehr lange über ihre eigentliche Lebensdauer hinaus aufrecht erhalten (legacy).
Favoriten:
- Java
- C++
- Visual Basic
- Smalltalk
- C#
Immer noch existent:
| Erhöhung der Chancen am Arbeitsmarkt (Marktgängigkeit) | |
Um Chancen am Arbeitsmarkt zu haben, sollte man mindestens 2 Programmiersprachen flüssig beherrschen. Es gibt immer aktuelle Analysen über die Nachfrage. Neben den echten Programmiersprachen spielen auch "sprachähnliche" Systeme wie SQL, HTML, XML eine Rolle.
Favoriten:
Man darf den Embedded-Bereich (Industrie) auch hier nicht vergessen.
Die Industrie wirft milliardenfach ge-flash-te Software auf den Markt, die nahezu
ausschließlich in C programmiert wurde, weil es meist nur C gibt für die jeweiligen
Prozessoren und Mikrokontroller.
Möglicherweise ist die Zahl der in C programmierenden Leute in der Industrie
50-fach höher als in allen anderen Bereichen (beispw. reine Software-Firmen)
zusammengenommen.
In den letzten Jahren (>2000..2005) gab es im Realtime-Bereich eine Abkehr von ADA
zurück zu C (Luftfahrt: mil+zivil; etc.)!
C ist nach wie vor eine/diejenige Sprache, an der man kaum vorbeikommt!
Begleitprogramme für Produkte (Windows .exe) werden meist in Pascal (Delphi) oder C++ geschrieben.
| Grafikprogrammierung und Bildverarbeitung | |
Grafikanwendungen und Bildverarbeitung erfordern den unkomplizierten Zugriff auf Dateien und den Programmspeicher, auch um den Preis geringerer Sicherheit gegen Programmfehler. Performance ist ziemlich wichtig.
Favoriten:
| InternetProgrammierung/Web-Anwendungen | |
Gemeint sind hier die üblichen Web-Applikationen zur Realisierung von Websites, Portalen etc. (nicht aber systemnahe Software wie Serverprogramme oder MTAs).
Favoriten:
| Konservative prozedurale Programmierung | |
Favoriten:
Ungeeignet (per Definition):
- Java, Lisp, Smalltalk, Eiffel, ...
| Kostenminimierung | |
Kostenminimierung stellt sich für verschiedene Benutzer unterschiedlich dar. Wer als Privatperson oder Student nichtkommerziell programmiert sieht das anders, als ein Freiberufler, oder jemand mit Zugang zu günstigen Universitäts-Speziallizenzen. Es gibt mittlerweile viele Sprachen, die einen preisgünstigen Einstieg bieten, aber mit professionellen Entwicklungsumgebungen für den kommerziellen Einsatz fast unerschwinglich teuer werden.
Favoriten:
Sprachen, die mit entsprechenden Umgebungen sehr teuer werden können:
Letzteres gilt sogar für C in der Industrie (Embedded).
Wenn man beispielsweise den aus meiner Sicht besten 'klassischen' Mikrokontroller der Welt, den Infineon TC1775, programmieren will, ist man pro Lizenz ab ~6000 EUR dabei, für
den Tasking Compiler (C/C++/MISRA-C).
Entwicklungssysteme für Fujitsu-Controller (16Bit LX ist empfehlenswert: 90F340-family) hingegen sind in Europa gratis!
Favoriten:
Ungeeignet:
Beispiel:
19"-Schrank, 2 m hoch.
15 Thyristor-Module (5 x 3 Phasen) mit je 3 Kontrollern, TI + Atmel.
FAN-Einschub, 6 Lüfter, 2 Kontroller.
Monitoring Unit, LCD 2x40, Hauptkontroller 16Bit, 8 KB, 384 KB Flash, 3 Meßkontroller.
| Moderne OO Programmierung | |
Favoriten:
Ungeeignet:
| Performancemaximierung | |
Favoriten:
- C
- C++
- C#
- Ada
- Fortran (nur für mathematische Anwendungen)
Außenseiterempfehlung:
| Portabilität und Standardisierung | |
Favoriten:
Ungeeignet:
- Visual Basic, C# (zu proprietär), Java (zu wenig Versions-Stabilität), Pascal (Mängel in Standard und Plattformunterstützung), ...
Außenseiterempfehlung:
| Produktivitätsmaximierung | |
Favoriten:
Ungeeignet:
| Programmiersprachentwicklung und Entwicklungstools | |
Favoriten:
Ungeeignet:
| Schulische Verwendung/Lerntauglichkeit | |
Versuche eigene "Lern"-Programmiersprachen (wie LOGO) zu etablieren kann man als gescheitert betrachten. Heute setzen die meisten Schulen auf modernere oder einfach zu handhabende Mainstream-Sprachen.
Favoriten:
Ungeeignet:
- Assembler, Ada, Lisp (zu spezifisch), Prolog (zu spezifisch), ...
Favoriten:
Ungeeignet:
| Stabilität | |
Favoriten:
Ungeeignet:
- Assembler, Visual Basic, ...
| Systemnahe Programmierung/Bibliotheken | |
Favoriten:
Ungeeignet:
- Basic, Lisp, Prolog, Smalltalk, ...
| Technische Systeme/Meßsysteme/Militärische Anwendungen | |
Im Gegensatz zum Embedded-Bereich spielt hier das Auskommen mit geringen Hardware-Resourcen keine Rolle. Wichtig ist die universelle Verfügbarkeit und die Stabilität der Standards.
Favoriten:
- C++
- Ada
- C
- PEARL (Ampelsteuerung für eine Stadt)
Ungeeignet:
Neuerdings:
- Abkehr von Ada, zurück zu C.
| Universelle Einsetzbarkeit | |
Gemeint ist hier: Für unterschiedlichste Projekte, auf unterschiedlichster Hardware, mit unterschiedlichen Betriebssystemen, unabhängig von Herstellern (ausreichend verschiedene Quellen), mit hoher zeitlicher Stabilität.
Favoriten:
- C
- Ada
- C++
- Python (nur in seiner Eigenschaft als Scriptsprache)
- Perl (nur in seiner Eigenschaft als Scriptsprache)
Gemeint sind reine Windows-Applikationen ohne Ambitionen auf Portabilität.
Favoriten:
Ungeeignet:
| Windows - Linux portable GUI-Applikationen | |
Favoriten:
- Java
- Delphi (Pascal), Kylix unter Linux
- Smalltalk
- C/C++ mit portabler GUI-Library
Ungeeignet:
| Wissenschaftliche Programmierung | |
Gemeint sind hier wissenschaftliche Anwendungen (nicht in der Lehre). Großer Bestand an Legacy-Code und langjährig angewachsenem, konservativem Know-How.
Favoriten:
| Diskussion | |
Smalltalk ist also teuer? Also das kann ich nicht bestätigen. Die Entwicklung ist schließlich nicht in den 90ern stehengeblieben. Privatanwender ohne kommerzielle Interessen bekommen die IDE bei Smalltalk fast immer umsonst. Eine kommerzielle Umgebung ist nicht teurer als eine IDE für C++. Man darf nicht vergessen, dass ich zu einer Smalltalk-IDE fast nie Dinge zukaufen muss. KM-Werkzeug, Debugger, Profiler, Case-Tool, Unit-Tests, Lint, Refactoring-Browser, etc. sind meist integriert oder frei verfügbar. Der einzig verfügbare Lint für C++ ist kommerziell.
Außerdem finde ich Smalltalk nicht bei den "modernen" OO-Sprachen, wo immerhin Eiffel aufgelistet ist. Also da müssen wir mal die Begriffe klären. Smalltalk ist vielleicht nicht hipp, aber es kann mit den "modernen" Sprachen locker mithalten und zieht in einigen Bereichen um Längen an Ruby, Python und Co vorbei. Das sagt ein Rubyist.
Bzgl. der Verwendung von Smalltalk in Schulen bin ich nicht informiert, aber dank Squeak e. V. tut sich da was. Wenn sich diese Liste als Bestandsaufnahme versteht, ok. Aber mir fehlen hier Empfehlungen. Ich glaube hier nach wie vor an eine Zukunft von Sprachen wie Squeak, bei deren Entwicklung der Einsatz in Schulen und Universitäten eine maßgebliche Rolle gespielt hat. Mein Vorschlag wäre: Zwischen Verwendung und Tauglichkeit zu unterscheiden. (Siehe 
http://squeakland.org und http://swiki.squeakfoundation.org/squeak-ev.)
-- SDö
- Empfehlungen wären gut, die Argumente kann ich nachvollziehen. Ich hab einige Male in Smalltalk hineingeschnuppert, aber nie ein Projekt damit gemacht. Auf der letzten C'T-CD gibt es ein gratis-Smalltalk, das für kommerzielle Anwendungen dann einige Tausend Euro kostet. Das sehe ich sehr kritisch (weil ich mir das nicht mehr leisten kann oder will :-) ). Für autodidakte Lehrer scheint mir die Komplexität eines Smalltalk oder Java allerdings ein Problem, das nur durch spezielle Schwerpunkte in der Ausbildung zu lösen wäre.
- Grundsätzlich sehe ich diese Seite nur als Startpunkt, den ich aus meiner begrenzten Sicht skizzenhaft angerissen habe, und wo ich hoffe, dass alle ihre Erfahrungen dazu geben, damit in der üblichen Weise was Wiki-geniales entsteht. Der "Gong zur ersten Runde" ist noch kaum verklungen. -- HelmutLeitner
Der Satz:
»Sprachen, die mit entsprechenden Umgebungen sehr teuer werden können«
ist doch korrekt.--hs
- Aber das gilt dann für nahezu alle Sprachen. Mehrere tausend Euro für eine kommerzielle IDE sind, soweit ich die Preise überschaue, völlig normal. Ich denke, dass über Eclipse tatsächlich ein Preisdruck entsteht. Aber selbst da kauft man sich evtl. noch was dazu.
Ich tu mich sehr schwer mit dieser Seite. Ist es nicht so, daß so ziemlich jede Sprache in jedem Bereich mehr oder minder brilliert? Und wenn dem so ist, dann gäbe es doch gar keine richtige ProgrammierSprache, sondern nur eine wahre ProgrammierSprache. In sofern ist das doch mehr eine Bauch-Herz-Seele-Nase-Entscheidung, als eine auf Fakten basierende. Wenn eine Sprache die prinzipielle Fähigkeit besitzt, eine bestimmte Sache zu tun, dann hängt es sehr viel mehr von der persönlichen Neigung zu der einen oder der anderen Sprache ab, als davon, wie fähig sie ist (Fremdeinflüsse klammere ich mal hier aus). Und dieses wie ist eine Metrik, die erstmal hier gefunden werden müßte (wie fähig ist Sprache X im Gegensatz zu Sprache Y bzgl. InternetProgrammierung?). Eine Abstimmung, wie am Anfang dieser Seite vorgeschlagen, würde aber eben auch nur die Stimmung der Abstimmenden wiedergeben und somit keine objektive, sondern eine subjektive Aussage darstellen. Und das wäre dann wieder so eine Bauch-Herz-Seele-Nase-Entscheidung.
Damit das nun nicht falsch verstanden wird: ich bin sehr der Meinung, daß die subjektive/persönliche/eigene Entscheidung für eine Sprache von beispeilsweise einem Projektteam, vielleicht per Abstimmung - besser noch: als einvernehmlicher Konsens - getroffen, sehr viel besser ist als die aufgezwungene Entscheidung, z.B. seitens des Kunden. Denn wenn das Team eben in einer bestimmten Sprache leben möchte, so wird es sehr viel produktiver sein, als es mit einer aufgedrückten Sprache der Fall wäre (Stichworte: Eigenantrieb, Motivation, Selbstbestimmung, Eigenverantwortlichkeit). Beispiel: Internetauftritt mit PHP, Java oder Python gestalten? Aus meiner Sicht würde das mit allen drei Sprachen sehr gut machbar sein. Nun könnte es zwei Vorgehensweisen geben: die richtige und die wahre. Das Richtige ist, die Fakten für die eine oder die andere Sprache herauszuarbeiten (das, was hier auf dieser Seite versucht wird) und dann zu schauen, welche Sprache besser dabei abschneidet. Die "beste" Sprache würde dann zur Projektsprache gemacht, unabhängig (!) davon, ob das Team diese Sprach mag oder eher abgeneigt ist, diese verwenden zu wollen. Das Wahre ist, das Team entscheiden zu lassen, mit welcher der Sprachen es gerne programmieren möchte.
- Ich wäre vorsichtig mit Begriffen wie richtig und wahr. Viele Eigenschaften einer Programmiersprache lassen sich nur schwer als Argumente dafür oder dagegen formal festhalten. Aus eigener Erfahrung mit Python weiß ich, dass man je nach Zielgruppe durchaus Schwierigkeiten haben kann, Vorteile gegenüber sagen wir Perl herauszustellen. Wenn jemand dann aber doch mit Python anfängt, stellt er oft genug fest, dass er in der täglichen Praxis, gelegentlich sogar wider Erwarten, wunderbar damit zurechtkommt. Das heisst, eigene Erfahrung ist oft wichtiger als abstrakte Vergleiche von Eigenschaften. -- DinuGherman
Nun: macht es Sinn, im Kontext meiner obigen Aussage, auf dieser Seite das Richtige zu dokumentieren? Welche Metrik sollte dann angewendet werden? --bs
- Ich finde die Seite eigentlich ganz gut. Bei allen Vorbehalten und Vorlieben gibt es durchaus Dinge, die mich von der Fixierung auf eine einzige Sprache abhalten. Diese Seite gibt eine Idee warum. Mit mehr Wiki-Links auf die konkreten Spezialthemen könnte man einen Teil der möglichen Diskussionen kanalisieren.
- Zu "prinzipielle Fähigkeit [...] eine bestimmte Sache zu tun": Bevor ich mit Smalltalk angefangen habe, konnte ich schon diverse Programmiersprachen. Mein damaliger Favorit war C++. Ich hatte C als Fortschritt gegenüber Pascal empfunden und sah C++ als eine Art "besseres" C an. Heute sehe ich das differenzierter. Manche Dinge würde ich nicht in C++ sondern in C machen. Ich bin Mathematiker. In theoretischer Informatik haben wir neben Theorie auch Prolog gemacht. Hat mir damals nicht wirklich was gegeben. Heute glaube ich, dass man Prolog besser versteht, wenn man sich der Sprache nicht von der Theorie her nähert. Wir haben auch etwas Lisp gemacht. Da habe ich ständig gedacht, das geht doch alles auch mit C, wieso soll ich mir eine lahme Interpretersprache an's Bein binden. Erst mit Smalltalk habe ich begriffen, was die Programmierwelt Lisp zu verdanken hat. Ich denke, ThePragmaticProgrammer hat ein gut Teil recht. Dort wird unter anderem empfohlen, dass man zwar (s)einen Text-Editor gut beherrscht aber auch jedes Jahr eine neue Programmiersprache lernt.
- -- SDö
- Ich beherzige Deinen angesprochenen Tip aus ThePragmaticProgrammer; dieses Jahr hab ich Python gelernt :-) Und ich bin auch gar nicht dafür, nicht über den Tellerrand hinaus zu schauen und sich auf einen "Liebling" zu versteifen, vielleicht sogar krampfhaft daran festzuhalten. Was aber doch jedem Programmierer überlassen sein und respektiert werden sollte, sind doch seine persönlichen Preferenzen für die eine oder gegen die andere Sprache. Und genau dies, so meine ich, wiegt viel stärker als eine nach "harten Fakten" sortierte Liste.
- "...wieso soll ich mir eine lahme Interpretersprache an's Bein binden..." Und damals hast Du bestimmt auch nicht in dieser "lahmen Interpretersprache" programmiert. Und eben weil Dir die Einsicht damals fehlte, hätte man Dich auch selbst mit solch einer Seite wie dieser hier, also mit "harten" Fakten, wahrscheinlich nicht überzeugen können, oder? Dann wäre es mit Sicherheit nicht gut fürs Ergebnis gewesen, wenn Du mit so einer "lahmen" Sprache hättest programmieren müssen, wenn Du innerlich dagegen gewesen wärest. Und bestimmt hast Du mit einer Dir lieben Sprache ein gutes Ergebnis gebracht, auch wenn diese Sprache rein objektiv betrachtet nicht optimal gewesen sein mag. --bs
- Bernd, in deinem Sinn von Art "richtig" und "wahr" (dem ich mich nicht unbedingt anschließen möchte), sollte diese Seite Grundlage für richtige Entscheidungen liefern. Wer die Entscheidung nach welchen Prioritäten trifft, ist für mich ein anderes Thema. Wenn es technische Prioritäten sind, würde ihnen allerdings eine Perspektive auf dieser Seite zukommen. Jemand könnte aber auch eine Schnittmenge über seine Interessen oder Geschäftsfelder legen und relativ leicht die optimale Sprache finden (wenn die Schnittmenge nicht leer ist).
- Dass "ziemlich jede Sprache in jedem Bereich mehr oder minder brilliert" sehe ich überhaupt nicht. Ich denke, dass jede Sprache in Bereichen spektakulär versagt. Niemand programmiert "Kommandozeilentools in Java", "Ego-Shooter in Perl", "IDEs in Assembler", "Internet-applikationen in C", oder "Programmiersprachen in Basic". Ich würde mich jedenfalls dagegen stemmen, wenn Fan-Gruppen der diversen Sprachen ihren Liebling in jede Kategorie hineinreklamieren wollten.
- Gute Beispiele, die Du da anführst. Aber, Beispiel "Kommandozeilentool in Java": wenn eine Firma versierte Java-Programmierer hat und diese nun ein Kommandozeilentool brauchen, warum dann nicht Java dafür nehmen, ist es doch durchaus ein der Lage, auf der Kommandozeile Argumente entgegen zu nehmen und diese auszuführen? Oder wenn beispielsweise Plattformunabhängigkeit eine Anforderung an ein Kommandozeilentool wäre? Und ich habe auch schon IDEs benutzt, die in Assembler geschrieben sind, nämlich Assembler-IDEs bzw. deren Simulatoren (ich glaube, Donald E. Knuth macht das heute noch so). Und Internet-Applikationen in C mittels cgi anzusprechen gibt es doch auch noch. Gut, mir ist schon klar, daß das alles Ausnahmen sind, aber sie haben alle gewisse Vorteile gegenüber dem "Üblichen. Aus solch technischer Sicht (und hier argumentiere ich nicht mit "wahr" und "richtig") gibt es immer Gründe für oder gegen eine Sprache bzgl. einer Aufgabe. Und das meinte ich damit, dass ich sagte, dass "ziemlich jede Sprache in jedem Bereich mehr oder minder brilliert". Daher würde ich auch die von Dir angesprochene Schnittmenge zur Findung der "optimalen" Sprache eher skeptisch betrachten, da eben in diesem Raster "unpopuläre" Faktoren keine Berücksichtigung finden würden (Java und Kommandozeilentools) und somit potentielle Lösungen, die vielleicht nur deshalb zur optimalen Sprache führen würden, weil sie eben so unpopuläre Herangehensweisen offerieren, nicht bedacht werden. Aber vielleicht mache ich mir auch nur Gedanken um eine Anforderung an diese Seite, die zu erfüllen gar nicht ihr Ziel sein soll... --bs
- Deine Frage nach weiteren Methodik oder Metrik ist natürlich überaus berechtigt. Ich denken, man kann nur gemeinsam nach einem brauchbaren Verfahren suchen.
- -- HelmutLeitner
- Dieses "richtig" und "wahr" stammt nicht von mir, sondern sind Betrachtungen von GunterDueck? (in seinem Buch "Omnisophie. Über richtige, wahre und natürliche Menschen",
ISBN 3540209255 überaus detailiert und sehr anschaulich dargestellt). Dies nur zur allgemeinen Information darüber, warum ich gerade diese Begriffe verwendet habe. --bs
Tja, Leute, der Gesamtsieger dieser Seite ist schon C, finde ich.--hs
Ich bin nochmal in mich gegangen und muss feststellen, dass für mich an dem, was Bernd sagt, viel Wahres ist. Ein Symptom sind die vielen neu erfundenen Räder. Ich selbst greife beim XML-Parser für Ruby nicht zu einem C-Wrapper um Expat sondern zu REXML und der ist vollständig in Ruby geschrieben. Für derartiges Verhalten könnte man endlos Beispiele bringen. Eins kann ich mir nicht verkneifen: Smalltalk gibt es für nahezu jeden Bereich. Es gibt ein Scripting-Smalltalk, drei Smalltalk für .NET, mehrere speziell für Windows, eins davon mit Fokus Spieleprogrammierung. Sogar im Embedded-Sektor muss man nicht auf Smalltalk verzichten:
 | |
Mit diesem Wissen würde ich mich scheuen, irgendwo eine Sprache als ungeeignet zu bezeichnen. Die hier in Kommentaren gesammelten Erkenntnisse finde ich für die explizite Sprachauswahl fast hilfreicher als eine Liste, die im schlimmsten Fall Vorurteile bestätigen wird. Das Vorgehen bei Performanz ist vielleicht wegweisend: Erstmal eine Liste der Standardkandidaten und dann die Ansätze der Außenseiter.
-- SDö
- Natürlich versucht Sprachgemeinden und Sprachhersteller den Anwendungsbereich ihrer Sprache auszudehnen. Aber der Wille allein kann nicht fürs Werk gelten. Ein JIT-Compiler für Python, der manchmal X in Geschwindigkeit übertrifft, kann trotzdem im Mittel um 20-50% langsamer sein. [siehe SprachePython/Psyco] Ein Smalltalk für embedded devices wird trotzdem Nachteile im Speicherbedarf (durch den komplexeren Sprachkern und durch gc), in der Verfügbarkeit für verschiedene CPUs und in der RealTime?-Performance haben. C wird nie so sicher in der Anwendung sein, dass es eine gute erste Programmiersprache zum Lernen wird, da hilft auch kein lint oder andere Tools. -- HelmutLeitner
Diese Seite geht von der absolut falschen Annahme aus, dass jedes "Projekt", gleichgültig wie groß, komplett in genau einer Sprache geschrieben werden muss. Absolut bekloppt, und wenig überraschend kommt natürlich heraus, dass "C/C++ der Gesamtsieger" sei. Mannomann, ihr habt doch alle einen Nagel im Kopf... Das hier ist das Deutsche Software Entwickler Wiki, nicht das Deutsche Pointy Haired Boss Wiki!
Allein diese Vergleiche... "20-50% langsamer als X". Beschissenes Argument für X, wenn man dafür 9 Monate länger entwickelt. Dank MooresLaw? haben sich die 50% Performancevorteil dann nämlich erledigt. Wenns überhaupt stimmt... Manchmal braucht man einfach ein besseres Werkzeug, um bessere Argorithmen überhaupt in endlicher Zeit implementieren zu können ( http://www.paulgraham.com/carl.html). "Mit einer stumpfen Axt kann man keinen Bleistift spitzen. Mit zehn stumpfen Äxten geht es auch nicht schneller."
Grundsätzlich benutzt man die ausdrucksstärkste Sprache, für die man eine Implementierung hat. Wenn nicht so recht klar ist, welche das ist, nimmt man eben die, mit der man sich wohl fühlt. Gibt es ein Performanceproblem, schreibt man kritische Teile in etwas niederem, häufig C. Die meisten Projekte enden sowieso damit, dass eine Spezialsprache erfunden und ein Interpreter dafür implementiert wird. (Alternativ enden sie in MaintenanceHell?...)
- von welchem Standpunkt aus schreibst du diese Meinung eigentlich? Interpreter im Interpreter ist quatsch! Dann muss das Gesamtkonzept meiner Meinung nach schon mal sehr sehr schlecht sein und darf auf Resourcen ohnehin nicht mehr besonders achten. Oder bezieht sich dein Schreiben hier auf den Kontext der schnellen Entwicklung? ein A kann und wird im Speicher immer ein A(ein Byte - oder mehr) bleiben, und wenn du 2 Interpreter hast in welchen Sprachen sollen denn die geschrieben worden sein? ASM/C? -- MarkusRechberger
- Sag mal, warum nennst Du mich hier namentlich? Ich habe diese Seite nicht gegründet, habe keinen einzigen Überschriftsabschnitt geschrieben und habe von allen Schreibern hier wohl das wenigste überhaupt geschrieben. Acht kurze Sätze oder so. Von Speicherknappheit habe ich m.W. gar nix geschrieben. --HelmutSchellong
- The Tao gave birth to machine language. Machine language gave birth to the assembler.
- The assembler gave birth to the compiler. Now there are ten thousand languages.
- Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
- But do not program in COBOL if you can avoid it.
- -- Geoffrey James, "The Tao Of Programming"
| Vergleichsdiagramm | |
Ich (hs) habe mal Punkte wie bei Formel1 vergeben:
C "gewinnt" ziemlich oft. Nicht erstaunlich, wenn die Listen alphabetisch geordnet sind.
- Erstens sind sie das nicht! Zweitens ist C in fast jeder Liste dabei, was für andere Sprachen bei weitem nicht der Fall ist.
---
- Python ist für Datenbankanwendungen (derzeit aber eher für Batchprogramme) inzwischen auch auf dem Vormarsch. Und den Satz "Für Datenbankanwendungen stehen meist keine hochqualifizierten Mitarbeiter zur Verfügung." finde ich schon etwas irreführend - er wirkt auf mich als hauptberuflichen DB-Entwickler irgendwie beleidigend. Richtig ist, dass die Datenbank-Anwendungsentwicklung hochqualifizierte Mitarbeiter erfordert (was für andere Bereiche, wenn man es gut machen will, genauso gilt). -- HenningVonBargen
| Artikel | |
KategorieProgrammierSprache
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 31. Dezember 2015 14:34 (diff))
