Wie groß sind die verschiedenen Unterschiede zwischen den Conputersprachen?

...komplette Frage anzeigen

4 Antworten

Es gibt ein paar grundlegende Konzepte, die man - einmal verstanden - evtl. mit anderer Syntax auch in andere Sprachen übernehmen kann.

Aaaaaaaaaaber ...

Du wirst auch oft so etwas hören wie: "Kann man eine Programmiersprache, kann man alle. Nur die Syntax ist etwas unterschiedlich." ... aber das stimmt ganz und gar nicht. Solche Aussagen kommen größtenteils von Leuten, die höchstens erst wenige Jahre programmieren.

Zu einer Programmiersprache gehören auch Konzepte oder sog. Paradigmen. Diese zu verinnerlichen dauert sehr lange, auch wenn man vorher schon X Programmiersprachen relativ gut beherrscht.

Vergleichen wir mal die Funktionsweise eine einfachen Schleife, mal völlig von syntaktischen Unterschieden abgesehen:

Java: Funktioniert durch inkrementieren eines primitiven Integers.

Ruby: Wie Java, wobei der Integer ein höheres Objekt ist.

Python: Funktioniert mit Generatoren.

Pascal: Funktioniert auch ähnlich wie Java, aber auch ohne Bedingung.

C++ Template: Funktioniert durch Klassenerzeugung zur Kompilierzeit.

Bash: Funktioniert durch Aufruf eines test-Programms.

Assembler: Funktioniert mit reinen Sprüngen.

Haskell: Funktioniert funktional.

Scheme: Rekursiv mit Lambdas.

Verilog: Funktionieren so extrem anders, dass ich es jetzt nicht weiter ausführe.

Disclaimer für mitlesende Profis: Ich weiß, a) viele der Sprachen kennen auch andere Schleifentypen, b) Assembler und vor allem Verilog ist nicht direkt als Programmiersprache zu bezeichnen, c) es geht mir nicht darum zu zeigen, was mit den genannten Sprachen möglich ist, sondern was allgemein getan wird, d)ich will hier jetzt nicht den Rahmen mit Details sprengen. :)

Allein bei Schleifen gibt es unglaublich viele Unterschiede, die nicht nur Syntaktischer Natur sind. Bei erweiterten for-Schleifen in einigen Sprachen, bei Generatoren, bei Objekten, bei Sprüngen und bei Rekursion muss man völlig unterschiedliche Dinge im Hinterkopf behalten um sicher und effizient programmieren zu können.

Wenn man sich allein hierbei denkt: "Och, ist ja nur ne andere Syntax." dann schneidet man sich arg ins eigene Fleisch. So, und das waren nur Schleifen! Es gibt aber noch mehr primitives Zeug wie Ausdrücke, Bedingungen, Operatoren und dann deutlich komplexere Sachen wie Funktionen, Klassen oder gar Generics.

All das wissen der genannten Punkte kann man nur sehr sehr bedingt von einer Sprache in die andere übernehmen. Gerade bei OOP gibt es da sehr viele subtile Eigenheiten und allein die Unterschiede zwischen C# und Objective-C würden alleine schon ein dickes Buch füllen.

So ... bis hier hin reden wir fast nur von Syntax und sprachlichen Eigenheiten. Jetzt kommt aber noch die Standardbibliothek einer Sprache und die dazu gehörenden Entwurfsmuster und Designentscheidungen dazu.

Zum Beispiel C++ Iteratoren sind konzeptionell vöööööllig anders als Javas Iteratoren. Und hinzu kommt, dass C++ ab Version 17 noch einen Schritt weiter geht und das Konzept stark erweitert, was einen riesigen Teil der Standardbibliothek zu überladenen Alternativen zwingen wird. (Obwohl man beide Konzepte bedingt auch in beiden Sprachen implementieren könnte, was im Endeffekt aber ineffizienter wäre.)

Bleiben wir bei C++ und Java: Beide kennen Templates, aber bei C++ sind diese Templates eine Turing-Vollständige und eigenständige Programmiersprache die zur Übersetzungszeit ausgeführt wird, und konstante Ausdrücke erzeugt. Bei Java gibt es Typlöschung, was wiederum völlig anders funktioniert als bei C++.

Javas Generics kann man sehr komfortabel einschränken, bei C++ muss man etwas umständlich mit Traits und static_assert arbeiten, aber auch hier kommt ab Version 17 ein Konzept, dass lustigerweise "Konzepte" heißt. :)

Aber zurück zum Thema: Das Wissen über Generics / Templates beider Sprachen kann man nicht austauschen. Ein C++ler mit mäßigen Java-Kenntnissen wird zwar mit Ach und Krach etwas funktionierendes bauen können, aber nur der Java-Entwickler kennt wichtige Details. Aufgrund des Featureumfangs ist es umgekehrt sogar noch viel extremer, wenn ein Java-Programmierer sich ohne größere Vorkenntnisse an C++-Templates wagt.

Wie gesagt: Es braucht viel Zeit wichtige Paradigmen einer Sprache zu verinnerlichen.

Ob eine Schleife jetzt überall mit "for" oder "while" eingeleitet wird, ist mehr oder weniger uninteressanter Kinderkram. :)

Zu einer ähnlichen Frage hier bei GF, hatte ich mal das Beispiel des Öffnen und des Schließens einer Datei genannt. Dabei geht es nicht mal um das Lesen und Schreiben von Daten, sondern nur den "nackten" Öffnen- und Schließ-Vorgang.

Das ist nämlich genau so ein Beispiel, bei dem viele Einsteiger sagen: "Das ist doch einfach, kann ich locker in mehreren Sprachen". Aber die wenigsten können es tatsächlich, nämlich im Hinblick auf Sicherheit und die Vermeidung von möglichem Datenverlust.

Ich kenne viele Python, C#, Java und C++ Entwickler, die eine Datei mit der entsprechenden close() bzw. Close() Methode schließen würden, aber wenn diese im Gültigkeitsbereich des Dateiobjektes direkt aufgerufen wird, kann man mit zu 99%iger Sicherheit sagen, dass der Programmierer einen Fehler gemacht hat.

In Python benutzt man dafür Scope-Guards, in C# using und Disposable, in Java Try-With-Ressources, in C++ ein Aufräum-Objekt und in anderen Programmiersprachen eben andere entsprechende Konstrukte, aber KEINEN direkten close()-Aufruf.

Um deine Frage zu beantworten:

Wenn du eine oder mehrere Programmiersprachen relativ flüssig kannst, geht es im Laufe der Zeit immer schneller, dir eine neue Syntax, Konventionen für Bezeichner, den Aufbau der Standardbibliothek und gängige Entwurfsmuster einer weiteren Sprache einzuprägen.

Um die Konzepte einer neuen Sprache zu verinnerlichen, wirst du aber immer (fast) gleich lange brauchen, auch wenn du vorher schon mit über 20 Sprachen zu tun hattest.

Bei Assembler, Erlang und AspectJ zum Beispiel muss man erst mal wieder (fast) bei Null anfangen, zumindest auf die Konzepte bezogen, die sich nicht mit anderen Sprachen schneiden.

Andere Sprachen haben viele kleine nette Konzepte, die man so nur in abgewandelter Form bei anderen Sprachen findet. (Rubys Blöcke vs. Groovy's Closures und curry()) Auch hier sind die Unterschiede nicht bloß syntaktischer Natur.

Fazit:

In je mehr Sprachen du Vorkenntnisse hast, desto schneller kannst du die Syntax und die Basics einer weiteren neuen Sprache lernen. Für wirkliches Verständnis und die Fähigkeit wirklich akzeptabel in der neuen Sprache programmieren zu können, brauchst du aber jedes mal aufs neue fast die selbe Zeit.

Bis man wirklich clever, effizient, sicher und elegant in einer neuen Sprache entwickeln kann, vergeht jedes mal aufs neue viel Zeit. Die einzige Ausnahme ist hier wohl die zu aller erst gelernte Programmiersprache, für die man wohl immer am längsten braucht. :)

(Das ist auch der Grund, warum ich hier auf GF fast nichts zu Swift, D, Go, Rust, Vala oder Lua, schreibe, da ich mich in den Konzepten dieser Sprachen darin doch nicht sicher genug fühle, als dass ich anderen auf diesem Gebiet Ratschläge geben möchte.

Zu anderen Sprachen wie PHP schreibe ich bewusst wenig, da diese Sprache ein riesen Haufen Murks ist. Perl und JS sind zwar gewöhnungsbedürftig, aber im Grunde ganz interessant, allerdings mache ich damit in letzter Zeit kaum etwas, sodass ich vermutlich nicht mehr ganz auf dem neuesten Stand bin.)

So, das war jetzt länger als ursprünglich geplant, aber egal. :)

SchakKlusoh 27.11.2016, 11:45

Gehe ich recht in der Annahme, daß Du keine Ahnung von Systematik, Programmierparadigmen und Software-Engineering hast?

Das sind drei Seiten auf meinem Bildschirm mit einem Kuddelmuddel an unstrukturierter Meinung.

Bist Du echt EXPERTE für PROGRAMMIEREN?

0
TeeTier 27.11.2016, 19:53
@SchakKlusoh

Wenn du jetzt auch noch schreiben würdest, welche Stelle dir genau sauer aufstößt (evtl. sogar mit Zitat), dann könnte man vielleicht auch darauf eingehen, aber so ...

Jeder einzelne Halbsatz deines Kommentars ist eine Null-Aussage, die mit dem Thema überhaupt nichts zu tun hat. Zwei oder drei Beispiele hätten nicht geschadet.

Also: Entweder du drückst dich vernünftig aus, und SAGST auch mal, was dir nicht passt, oder du verkneifst dir solche Kommentare. In der aktuellen Form bringt dein Kommentar weder dich, noch mich, noch den Fragensteller, noch andere Mitleser weiter.

Falls du etwas zu sagen hast, dann SAG es gefälligst. Wenn nicht, dann sei - mit Verlaub - bitte ruhig.

Rückmeldungen nach dem Motto "Ich mag deine Antwort nicht, aber ich sag dir nicht waruuuuhhuuum, äääätsch!" sagen mehr über dich, als über mich aus.

Schönen Abend noch! :)

1
SchakKlusoh 27.11.2016, 22:42
@TeeTier

Dein Text beantwortet die Frage nicht, sondern ist nur eine Sammlung von Beschreibungen von Nebensächlichkeiten und eine Wiedergabe von Ansichten zu irgendwelchen Dingen.


..... PHP schreibe ich bewusst wenig, da diese Sprache ein riesen Haufen Murks ist

Du kennst scheinbar keine Sprachfamilien. Alle Sprachen scheinen bei Dir nur irgendwie anders als andere zu sein.

Zum Beispiel schreibst Du unmotiviert etwas über Schleifen, als wäre daran die Struktur und die grundlegenden Herangehensweise einer Sprache zu erkennen.

Manches davon ist sogar unfreiwillig komisch. {{{Haskell: Funktioniert funktional.}}}

Manches ist sogar falsch: {{{ Assembler: Funktioniert mit reinen Sprüngen. }}}


Erst am Ende kommst Du auf die Frage zurück.

In je mehr Sprachen du Vorkenntnisse hast, desto schneller kannst du die Syntax und die Basics einer weiteren neuen Sprache lernen.

Die Aussage ist aber nicht brauchbar, weil sie nichts erklärt.

Begründung: Wenn man zig prozedurale Sprachen erlernt hat und plötzlich mit APL konfrontiert würde, sind fast alle Vorkenntnisse eher sogar hinderlich. Und da sage ich noch gar nichts über Mondrian.

0
TeeTier 28.11.2016, 00:22
@SchakKlusoh

Dein Text beantwortet die Frage nicht, sondern ist nur eine Sammlung von Beschreibungen von Nebensächlichkeiten.

Die Fragen waren, wie groß die Unterschiede zw. versch. Sprachen sind, wie groß der Zeitaufwand pro weiterer Sprache ist, und ob es Ähnlichkeiten gibt.

Das habe ich alles beantwortet und mit Beispielen untermauert. Daher kann ich diesen Kritikpunkt nicht nachvollziehen. Könnte es sein, dass du meine Antwort nur überflogen hast, weil es dir zu viel Text war?

Und dass du als erstes Zitat den PHP-Kommentar zitiert hast, finde ich ganz lustig. Bei dem ganzen langen Text ist das, was dir am wichtigsten erscheint, meine (als solche gekennzeichnete!) persönliche Meinung zu PHP? Ich dachte, du hast andere Prioritäten. Naja.

Du kennst scheinbar keine Sprachfamilien. Alle Sprachen scheinen bei Dir nur irgendwie anders als andere zu sein.

Sind sie ja auch. Wenn es zwei Sprachen geben würde, die fast identisch wären, dann würde eine davon relativ schnell aussterben.

Zum Beispiel schreibst Du unmotiviert etwas über Schleifen, als wäre daran die Struktur und die grundlegenden Herangehensweise einer Sprache zu erkennen.

Äh, ja! Das ist auch so! Sag mal, hast du meine Antwort überhaupt gelesen?

Die "Struktur und grundlegende Herangehensweise" einer Schleife ist ja wohl alleine schon bei Java und Python klar ersichtlich. Unterschiedlicher gehts ja kaum. Außer dass beide "for" heißen, haben die beiden Null Gemeinsamkeiten.

Über Generatoren in Python gibt es in Fachbüchern normalerweise eigene Kapitel. Du kannst jetzt nicht sagen, dass dieses Feature nichts mit der "Struktur und grundlegenden Herangehensweise" einer Sprache zu tun hat. Grundlegender geht es schon gar nicht mehr!

Manches davon ist sogar unfreiwillig komisch. {{{Haskell: Funktioniert funktional.}}}

Das ist nicht "unfreiwillig komisch", das ist eine bewusst locker gewählte Formulierung. Du könntest es auch "subtilen Witz" nennen. Aber der ist wohl an dir vorbei gegangen. Nimm mal bitte nicht alles so toternst, was ich schreibe!

Manches ist sogar falsch: {{{ Assembler: Funktioniert mit reinen Sprüngen. }}}

Ich bitte um einen Gegenbeweis in Quellcode-Form. (Ein zwei oder 3-Zeiler reicht völlig!) Eine Schleife in Assembler ohne (bedingte) Sprünge will ich mal sehen. Und jetzt erzähl mir nicht, dass du nicht gemerkt hast, dass es dem monierten Absatz, davor und danach, ausschließlich um Schleifen geht.

Die Aussage ist aber nicht brauchbar, weil sie nichts erklärt.

Nochmal zum Mitschreiben: Der Fragensteller schrieb in einer Teilfrage "Wenn ich eine Sprache beherrschen würde, wie schwer ist es dann eine neue zu lernen?" und ich antwortete "In je mehr Sprachen du Vorkenntnisse hast, desto schneller kannst du die
Syntax und die Basics einer weiteren neuen Sprache lernen."
. In wie weit ist diese Antwort nicht brauchbar??? Gerade dieser Teil bringt meinen Roman auf den Punkt! :)

Wenn man zig prozedurale Sprachen erlernt hat und plötzlich mit APL konfrontiert würde, sind fast alle Vorkenntnisse eher sogar hinderlich. Und da sage ich noch gar nichts über Mondrian.

Aaahhhaaaaa! Jetzt verstehe ich! Du willst stänkern und Erbsen zählen!

Weißt du, ich schreibe einen langen Text, dessen Kernaussage genau das ist, was du hier auch schreibst. Aber im Gegensatz zu dir, gehe ich auf weitere Details ein. Jetzt suchst du dir natürlich die paar Absätze raus, der nicht zu 100% exakt zu deiner Aussage passen und tust so, als würde ich etwas ganz anderes behaupten.

Versuchs mal mit Kontext und etwas Relativierung, oder bist du ein Roboter???

hahaha ... das ist ja heute wieder mal lustig hier. :)

0
SchakKlusoh 28.11.2016, 19:30
@TeeTier

Manches ist sogar falsch: {{{ Assembler: Funktioniert mit reinen Sprüngen. }}}

Ich bitte um einen Gegenbeweis in Quellcode-Form. (Ein zwei oder 3-Zeiler reicht völlig!) Eine Schleife in Assembler ohne (bedingte) Sprünge will ich mal sehen.

---------------------------------------------------------------------------
Du hast nicht "(bedingte) Sprünge" geschrieben, sondern "reinen Sprüngen".

REPEAT:
....
JMP NZ,REPEAT
;Schleifenende

So und jetzt noch ein Beispiel mit einem "reinen Sprung" (NEC 7810 Assembler - der hat keine Conditional Jumps)

REPEAT:
    .....
SK Z
JMP REPEAT
;Schleifenende

Oops.

0
SchakKlusoh 28.11.2016, 19:52
@TeeTier

Du kennst scheinbar keine Sprachfamilien. Alle Sprachen scheinen bei Dir nur irgendwie anders als andere zu sein.

Sind sie ja auch. Wenn es zwei Sprachen geben würde, die fast identisch wären, dann würde eine davon relativ schnell aussterben.

Das ist nicht korrekt.

BASIC und µC-BASIC leben friedlich nebeneinander, obwohl sie fast identisch sind. µC-Basic wurde vereinfacht, um es besonders leicht compilierbar zu machen. ZB. erlaubt es nur einen Term pro Zuweisung.

Notabene: Es kommt nicht darauf an, wie die Sprachen aussehen, sondern für was sie benutzt werden.

Der eigentliche Punkt ist aber, daß es Sprachfamilien gibt, die deutlich unterschiedliche Konzepte haben.

Es kommt nicht darauf an, daß die eine Schleife kompakter kompiliert wird, sorry.

Hast Du so etwas schon einmal in PHP, Java, Python, Assembler (das sind die Sprachen, die Du in dem Post aufgezählt hast) gesehen?

:Waschmaschine Wasser An Zulauf 5 Warte Wasser Aus Zulauf;

Interessant auch, daß Du APL so einfach übergangen hast.

0
TeeTier 29.11.2016, 01:04
@SchakKlusoh

Du hast nicht "(bedingte) Sprünge" geschrieben, sondern "reinen Sprüngen".

Aua, jetzt wirds wirklich lächerlich. Du findest keine weiteren Haare in der Suppe und klammerst dich als letzten Strohhalm an diese Formulierung?! Ernsthaft?? ;)

Oops.

Was "Oops"? Du unterstellst mir etwas, widersprichst dieser Behauptung, belegst sie aber mit einem Beispiel, und sagst dann "Oops"? Bist du leicht verwirrt, oder so? hahaha :)

Es kommt nicht darauf an, wie die Sprachen aussehen, sondern für was sie benutzt werden.

Das stimmt nicht, bzw. trifft nur auf Proof-Of-Concepts zu. Warum programmiert man µCs nicht in C# oder Java? Eben weil es NICHT nur darauf ankommt, wofür die Sprachen eingesetzt werden. Aber egal ... das ist ein anderes Thema ... (Verkneif dir jetzt einfach mir zu sagen, dass man µC sehr wohl mit C# und Java programmieren kann. Falls du das jetzt wirklich gedacht haben solltest, dann hast du immer noch nicht begriffen, worum es hier geht.)

Es kommt nicht darauf an, daß die eine Schleife kompakter kompiliert wird, sorry.

Doch, deshalb habe ich ja das Python-Beispiel gebracht, da der benötigte Speicher beider Schleifen ein Verhältnis von ca. 1:2204 hat. (Kannste selber nachrechnen oder profilen!)

Bei "Hallo Welt" macht das tatsächlich nichts, aber bei jeder anderen Form von Projekt sehr wohl.

Auch die Ausführungsgeschwindigkeit ist einige 10000% schneller. Und genau DAS meine ich mit "ohne tiefergehendes Verständnis wird ein Anfänger zwar Code zum laufen bringen, der aber nicht effizient läuft". Um zu erkennen, wann jetzt DOCH die vermeintlich langsamere Variante besser sein könnte, braucht man wieder Erfahrung, die sich nicht in kurzer Zeit von selbst ansammelt.

Interessant auch, daß Du APL so einfach übergangen hast.

Oh ja, sehr interessant. Wirklich. Du hast auch Erlang und AspectJ übergangen. Auch interessant, ne?

Merkst du eigentlich, was für Eigentore du dir hier schießt? Deine kurzen Kommentare gehen höchstens auf 10% meiner langen Texte ein, und dann traust du dich tatsächlich noch, obiges Zitat raus zu lassen. ><

Is mir aber ehrlich gesagt völlig egal und hat nix mit dem Thema zu tun.

----------

Sorry, aber das wird mir jetzt zu primitiv, ich steige aus. Sollen
sich die Mitleser ihr eigenes Bild von unserer Konversation hier machen.

PS: Wie ich bereits an anderer Stelle geschrieben habe, versuch es doch mal mit Kontext, anstatt dich absichtlich taub zu stellen. Du klingst wie jemand, der sofort sagt "Neee, dieses Wort gibt es nicht!", wenn er ein zusammengesetztes Substantiv hört, welches er nicht im Duden findet. Naja, mach du mal ruhig dein Ding.

Sorry, aber das ist mir jetzt alles viel zu unwichtig. Hauptsache der Fragensteller hat seine Antwort, und die anderen Mitleser vielleicht sogar etwas gelernt.

Also dann, ich bin raus.

Schönen Abend noch! :)

0

Viele Computersprache sind sich sehr ähnlich. Man kann gewisse Gruppen bilden.

Prozedurale Sprachen: BASIC, C, FORTRAN, PASCAL, PL1  ....

Objektorientierte Sprachen: C++, Oberon, Visual Basic, ...

Maschinennahe Sprachen: Assembler, UCSD,

Imperative Meta-Sprachen: Forth, Fifth ...

Deklarative Sprachen:  ...

Wenn Du eine davon kannst, kannst Du die anderen aus der Gruppe schnell erlernen.

PWolff 27.11.2016, 01:05

Das Einarbeiten in eine Sprache einer anderen Gruppe dauert deutlich länger, ca. 1/3 bis 1/2 so lang wie das Einarbeiten in die erste Sprache überhaupt.

1
SchakKlusoh 27.11.2016, 11:47
@PWolff

Wie kommst Du auf die Zahlenß Eigene Erfahrung, oder gibt es eine Studie?

0
TeeTier 27.11.2016, 20:56
@SchakKlusoh

Ich schätze, dass wenn man in seinem Berufsleben mit deutlich mehr als 30 Programmiersprachen zu tun hatte, kann man das ganze relativ gut einschätzen.

Vor einiger Zeit gab es zu dem Thema hier mal eine Frage, und da bin ich für mich persönlich auf ca. 50 Sprachen gekommen. (Dabei waren aber auch Dinge wie VHDL, HTML oder SQL, aber wirklich echte Programmiersprachen waren ca. 40 Stück dabei.)

Ich denke, das gilt in ähnlicher Weise für PWolff. Wenn man seine Antworten liest, merkt man schon, dass er i. d. R. weiß, wovon er redet.

Von daher stimme ich dem 1/3 bis 1/2 des Zeitaufwandes der ersten Programmiersprache im Schnitt zu.

"Programmieren" ist nämlich nicht nur die Fähigkeit, eine For-Schleife fehlerfrei in die Syntax einer anderen Sprache übersetzen zu können. :)

0
SchakKlusoh 27.11.2016, 22:24
@TeeTier

Okay, verstehe. Du gibst Deine persönliche Erfahrung wieder.

Bei Dir hat das Erlernen einer Sprache aus einem anderen Paradigmenfeld 30% bis 50% der Zeit für die erste gedauert.

0
TeeTier 28.11.2016, 00:24
@SchakKlusoh

Na ENDLICH ist bei dir der Groschen gefallen!

Ja, ich gebe hier persönliche Erfahrungen wieder. Schön, dass du das endlich begriffen hast!

Mal unter uns: Was für eine Antwort hast du denn erwartet bzw. dir gewünscht?

0
TeeTier 28.11.2016, 01:37
@SchakKlusoh

PS: Exakt! So ungefähr kommt das im Durchschnitt ganz gut hin. :)

0
TeeTier 27.11.2016, 20:49

Da du meine Antwort oberflächlich kritisiert hast, ohne auf Details einzugehen, fühle ich mich jetzt leider dazu gezwungen, die deine zu kommentieren. :)

Viele Computersprache sind sich sehr ähnlich.

Diese Ähnlichkeit ist oft nur Oberflächlich. Allein der C-Teil von C++ unterscheidet sich stark von "echtem" C, und wenn jemand behauptet, C sei eine echte Teilmenge (im mathematischen Sinne), dann liegt er falsch. C ist eine Schnittmenge von C++, denn C hat sehr viele Eigenschaften, die völlig inkompatibel mit C++ sind.

(Im schlimmsten Falle führt das zu Bugs oder gar Sicherheitslücken, wenn ein Entwickler denkt, er könne C in C++ einsetzen.)

Zurück zu deiner Antwort: Erst mal fällt mir auf, dass du alle Multiparadigmensprachen auf nur ein einziges Konzept reduzierst, was falsch ist. Dazu möchte ich Bjarne Stroustrup aus der aktuellen Ausgabe von "Die C++ Programmiersprache" ganz am Anfang auf Seite 13 (Absatz Nr. 7) zitieren:

Ich zucke immer zusammen, wenn jemand C++ ausschließlich über einen dieser Stile charakterisiert (wie etwa „C++ ist eine objektorientierte Sprache“) [...]

Aber bleiben wir ruhig mal bei C++ und OOP. Du hast dazu VB aufgezählt, allerdings erlaubt / erzwingt allein schon das Feature der Mehrfachvererbung ganz andere Programmiertechniken.

Das CRTP ist so ein Kandidat, der - dank Mehrfachvererbung - eine Art "Kompilierzeit-Polymorphismus" erlaubt, ohne den Laufzeit-Overhead von VTables zu haben.

Für performance-kritische Flaschenhälse einzelner Methoden ist das eine saubere Lösung, und zwar auch in Kombination mit herkömmlicher Vererbung!

Wenn jetzt jemand OOP mit VB gelernt hat, muss er zwangsläufig (!) viele neue Dinge dazu lernen, wenn er auf C++ umsatteln will. Wie eine Klasse definiert wird, ist dabei nur Syntax, die man in 5 Minuten lernt. Ein bis dato unbekanntes und anfangs verwirrendes Muster wie CRTP wird länger dauern, bis es sich im Gehirn eingenistet hat und abrufbereit ist.

Wie ich in meiner Antwort bereits geschrieben habe: Ein VBler (bzw. Java-Entwickler) wird zwar Code irgendwie zum laufen bringen können, aber dieser wird weder schick, noch effizient, noch elegant sein, ohne die Stärken von C++ einzusetzen. Und besagter Einsatz fußt nun mal auf Verständnis von sprachspezifischen Details.

Im Übrigen zählst du auch BASIC und Pascal als prozeduale Sprachen auf, wobei moderne Dialekte von beiden auch OOP können. Daher ist mir deine Auflistung ehrlich gesagt etwas zu schwammig zusammen gewürfelt.

Und nur um Haarspalterei zu betreiben, weil du mir unter meiner Antwort so einen freundlichen Kommentar hinterlassen hast: Ich habe auch schon OOP in reinem ANSI-C und sogar Assembler programmiert. OOP ist nämlich KEIN Sprachfeature, sondern eine Herangehensweise, und diese kann man auf die meisten Nicht-OOP-Sprachen anwenden.

Allerdings geht das auch nur, wenn man alle Details seiner Sprache kennt, und nicht, wenn man beispielsweise blauäugig von Python zu C wechselt.

(Dass syntaktischer Zuckker OOP wie bei C#, Java oder C++ natürlich extrem vereinfacht, bzw. erst komfortabel möglich macht, ist eine andere Sache! Aber gerade im embedded Bereich wird gerne mal Objektorientert programmiert, auch wenn nur ein einfacher C Compiler verfügbar ist. Und das geht im einfachsten Falle sogar völlig ohne externe Tools, Skripte oder gar den Präprozessor!)

Wenn Du eine davon kannst, kannst Du die anderen aus der Gruppe schnell erlernen.

Nein. Du kannst die grundlegende Syntax in wenigen Stunden lernen, aber "Syntax kennen" und "Programmieren können" sind zwei paar Schuhe.

Ein Anfänger, der seit einem halben Jahr Perl programmiert, und sich dann zusätzlich mit Ruby beschäftigt, wird auch erst mal denken: "Cool, das war ja einfach, jetzt kann ich Ruby!".

Ein erfahrener Perl-Monk, der sich nach 15 Jahren einen ganzen Monat intensiv mit Ruby beschäftigt wird hingegen erkennen: "Ich habe jetzt zwar schon viel gelernt, aber noch einen langen Weg vor mir.". Das betrifft gerade bei Skriptsprachen wie Python und Ruby natürlich auch zu einem großen Teil das Design der Standardbibliothek.

(Siehe dazu eine von mir gestellte Frage zum Thema "Kodierungen bei Python" von vor vielen Jahren, die bis heute keiner beantworten konnte, und für die ich selbst auch noch keine Lösung habe!)

So, das wars. Ist wieder länger geworden, aber ich richte mich ja auch nicht nur an dich, sondern vor allem an alle anderen Mitleser dieser Plattform. Falls du Kritik äußern willst, freue ich mich auf einen fundierten Kommentar.

Schönen Abend noch! ;)

PS: Um eine kleine Frage zu beantworten, die du mir in deinem Kommentar unter meinem Beitrag gestellt hast: Ja, ich bin hier "Experte für Programmieren". Und wenn du dir mein Profil ansiehst, wirst du links oben am Banner auch erkennen, dass ich sogar den Status "Spezialexperte" habe! ;)

0
SchakKlusoh 27.11.2016, 22:20
@TeeTier

Du verwendest sehr viel Text darauf Dein Wissen und Deine Erfahrung herauszustreichen. 

Das ist bedeutungslos, wenn Du Deine Expertenschaft nicht durch eine gute Antwort beweisen kannst.

Du verlierst Dich hier (wieder) in einer endlose Menge von Einzelheiten ohne etwas zu erklären. Von daher ist meine (zugegebenweise vereinfachte) Liste immer noch die beste (und kürzeste) Erklärung, warum manche Programmiersprachen leicht zu erlernen sind, wenn man andere kennt, aber es eben nicht für alle gilt.

0
SchakKlusoh 27.11.2016, 22:54
@TeeTier

Ich kann es auch konkreter machen:


Allein der C-Teil von C++ unterscheidet sich stark von "echtem" C, und

  • Niemand hat C und C++ in einen Topf geworfen. In meiner Antwort sind sie in unterscheidlichen Gruppen.


wenn jemand behauptet, C sei eine echte Teilmenge (im mathematischen Sinne), dann liegt er falsch.

  • Niemand hat das behauptet

Also, warum läßt Du Dich darüber aus? Kann es sein, daß Du mit einer Menge Anekdoten beeindrucken willst?

Hmm, ich denke, daß eine gute Antwort immer auch eine kurze Antwort ist. "Soviel als nötig und so wenig als möglich."

0
TeeTier 28.11.2016, 01:07
@SchakKlusoh

Du verwendest sehr viel Text darauf Dein Wissen und Deine Erfahrung herauszustreichen.

Natürlich, damit alle was davon haben! Ich lerne auch fast nur bei Texten oder Vorträgen von Leuten, die besser sind als ich. Je besser mein Gegenüber, desto mehr lerne ich.

Und da sich hier auf GF viele Einsteiger rumtreiben, versuche ich immer Anekdoten zu bringen oder interessante Details zu erwähnen, die einen Mitleser vielleicht mal zu einer Google-Suche anregen.

Zugegeben, ich reiße viele Themen nur grob an, aber das dient alles nur dem "Interesse wecken". Niemand wird ernsthaft erwarten, dass ich hier noch (!) längere Texte schreibe, und jede Nebensächlichkeit behandele. Dafür gibt es Bücher und Suchmaschinen.

Also ja, ich schreibe gerne über das, was ich weiß. Einfach weil ich persönlich auch gerne über "Tricks" und Dinge lese, die nicht soooo bekannt sind, im Programmieralltag aber u. U. weiterhelfen.

Wenn du das verwerflich findest, dann bist du herzlich dazu eingeladen, meine Beiträge fortan ignorieren zu dürfen. :)

Das ist bedeutungslos, wenn Du Deine Expertenschaft nicht durch eine gute Antwort beweisen kannst.

Mit Verlaub, aber DIR muss ich GAR nichts beweisen. Komm mal runter von deinem hohen Ross! Wir sind hier nicht an der Uni und du bist nicht mein Dozent. :)

Du verlierst Dich hier (wieder) in einer endlose Menge von Einzelheiten ohne etwas zu erklären.

Nochmal: Meine Texte richten sich NICHT nur an dich, sondern an alle Mitleser! (auch dieser Kommentar hier)

Das behalte ich immer im Hinterkopf, bei allem was ich schreibe. Meine Tendenz zu Romanen ist dadurch bedingt, dass ich mir - wie bereits erwähnt - vorstellen kann, dass es andere Mitleser interessiert und evtl. inspiriert.

Dass ich dabei nichts erkläre, ist eine Unterstellung deinerseits.

Von daher ist meine (zugegebenweise vereinfachte) Liste immer noch die beste (und kürzeste) Erklärung,

hahaha ... natürlich. Das Hauptkriterium der Güte einer Antwort ist die Kürze. Was nützt eine kurze Antwort, die die Frage nicht oder gar falsch beantwortet? :)

Und deine Aussage "Wenn Du eine davon kannst, kannst Du die anderen aus der Gruppe schnell erlernen" ist einfach falsch, da ein VBler sehr sehr lange benötigen wird, um die wichtigen C++ Sprachfeatures akzeptabel einsetzen zu können. Vermutlich dauert das sogar länger, als der Lernprozess bei Visual Basic insgesamt.

Wie gesagt, es geht nicht um Syntax. Syntax ist Pippifax und die lernt man in den meisten Sprachen schnell. Aber um zu verstehen, dass man bei C++ Ausnahmen nur als konstante Referenzen fangen sollte, muss man sich mit dem Exception-Stack und der Kopier- / Verschiebesemantik beschäftigen.

Es ist also völlig unerheblich, ob der VBler jetzt an einem Tag die gesamte C++ Syntax inhaliert hat ... ohne Wissen über Interna wird er keinen vernünftigen Code schreiben können. Und genau für DIESE und andere Dinge, welche - nochmal - NICHTS mit Syntax zu tun hat, wird er MINDESTENS ein Jahr benötigen.

Um beim Beispiel aus deiner Antwort zu bleiben: Man kann davon ausgehen, dass ein VBler die C++ Syntax spätestens binnen weniger Wochen gelernt haben wird. Um in C++ aber wirklich (!) programmieren zu können, vergeht mit Sicherheit die 10fache Zeit.

Zusammengerechnet braucht der VBler also länger für C++ als für VB selbst, auch wenn es sich dabei um die erste Programmiersprache handelte.

C++ ist zugegebenermaßen sehr komplex, aber bei Ruby oder Python ist es das gleiche: Syntax im ersten Schritt geht schnell, Grundlegende Sprachelemente auch. Im zweiten Schritt muss aber erst mal Verständnis und ein Gefühl für die neue Sprache wachsen. Und DAS braucht Zeit.

Im ersten Schritt wird der Python-Einsteiger eine for-Schleife kennen lernen und anwenden können. Im zweiten Schritt wird ihm aber erst klar werden, was ein Generator, ein Tupel ist und wie man Objekte erzeugt, die sich ähnlich verhalten.

warum manche Programmiersprachen leicht zu erlernen sind

Genau hier liegt der Hase im Pfeffer! Das stimmt nämlich nicht.

Ein Anfänger "glaubt" (!), dass er eine neue Sprache gut gelernt hat und dass die neue Sprache relativ einfacher war. Nach einigen Jahren wird er aber erkennen, dass er falsch lag, und damals nicht über Syntax und Basics hinaus gekommen ist.

Wenn wir bei besagtem Python-Anfänger bleiben: Bis dieser eigene Doctests schreiben kann, effiziente Klassen mit __slots__ implementiert oder das itertools-Modul entdeckt wird viel Zeit vergehen! Und zwar viel mehr als er benötigt hat, um sämtliche grundlegenden Sprachelemente kennen zu lernen. In dieser gesamten Zeit, wird der Anfänger grauenhaften Code schreiben, und es selbst nicht erkennen.

Mit Verlaub, wenn du von "leicht zu erlernenden Programmiersprachen" sprichst, klingst du wie ein Einsteiger, der vor 2 Monaten angefangen hat.

Wenn du hingegen von "leichtem Einstieg in eine Sprache" redest, bin ich bei dir! Das hat dann aber mit richtigem "Programmieren" oder gar "beherrschen", wie in der Fragestellung formuliert, noch nichts zu tun, :)

0
TeeTier 28.11.2016, 01:31
@SchakKlusoh

Also, warum läßt Du Dich darüber aus?

Weil es a) etwas mit dem Thema zu tun hat und ich b) aufzeigen wollte, wie krass die Unterschiede bei Sprachen sein können, die vermeintlich kaum enger "zusammen gehören" könnten.

Dass du das behauptet hast, habe ich nirgendwo geschrieben.

Hmm, ich denke, daß eine gute Antwort immer auch eine kurze Antwort ist. "Soviel als nötig und so wenig als möglich."

Das sehe ich auch so! Allerdings ist deine Antwort schlicht falsch (siehe andere Kommentare) und sie wird durch die Kürze auch nicht richtiger.

Wäre sie richtig, gäbe es nichts zu meckern.

Des weiteren habe ich bereits geschrieben, warum ich längere Texte verfasse.

An dem ausgesuchten Beispiel mit den Schleifen konnte man auch gut die Unterschiede versch. Sprachen sehen.

Wenn für DICH eine Schleife allerdings nur zum "zählen" oder "iterieren" da ist, dann hast du nicht verstanden, worauf ich hinaus wollte.

Python 2.x Anfänger Beispiel:

for i in range(1000):
# mach was mit i ...

Ein Fortgeschrittener wird hingegen Folgendes machen:

i = 0
while i < 1000:
# mach was mit i ...
i += 1

Für einen Einsteiger sieht erstere Variante einfacher aus, hat aber aufgrund der Liste eine grauenhafte Performance im Hinblick auf CPU und RAM. Bei Python 3.x gibt es immerhin Generatoren, aber die while-Variante ist und bleibt die effizienteste.

Und um DAS zu erkennen, genügen keine 3 Stunden Syntax auswendig lernen. Gut, das war ein primitives Beispiel, aber wenn jetzt jemand von Pascal kommt und die for-Schleife sieht, denkt er sich "Toll, wie einfach!" und wundert sich über das schlechte Laufzeitverhalten.

Ich übertreibe nicht, wenn ich sage, dass es bei Python sicherlich an die 1000 solcher "Fallen" gibt, die für Einsteiger erst mal verlockend einfach wirken, sich aber als hartnäckige Fallgruben entpuppen, wenn man nicht weiß, wie Python intern arbeitet, und sein Wissen von anderen Sprachen 1:1 übernimmt.

So, und das oben gesagte gilt für (vermutlich fast) ALLE Programmiersprachen. Mir fällt keine ohne besondere Eigenheiten und Spezialkonzepte ein. Und selbst wenn du eine finden solltest: Ausnahmen bestätigen die Regel!

So, und um jetzt mal zum Ende zu kommen:

Was ich sagen wollte ist, dass Vorkenntnisse in einer anderen Programmiersprache meistens beim Verständnis von Syntax und den Grundlagen einer weiteren Programmiersprache helfen, das Lernen der entscheidenden Kernkonzepte aber fast immer gleich viel Zeit benötig, so als würde man jedes mal aufs neue mit seiner ersten Programmiersprache anfangen. Mit der Zeit nimmt das zwar auch ab, aber vergleichsweise nur sehr sehr langsam.

(Z. B. kann man Template Wissen von C++ teilweise gut mit nach D mitnehmen und Kenntnisse der aspektorientierten Entwicklung in vielen Sprachen einsetzen, die dieses Paradigma unterstützen)

0
SchakKlusoh 28.11.2016, 20:07
@TeeTier

Mit Verlaub, wenn du von "leicht zu erlernenden Programmiersprachen" sprichst, klingst du wie ein Einsteiger, der vor 2 Monaten angefangen hat.

Bitte korrekt zitieren.

.... warum manche Programmiersprachen leicht zu erlernen sind, wenn man andere kennt, aber es eben nicht für alle gilt.

Du kennst scheinbar nur prozedurale Sprachen und aus ihnen hervorgegangene OOP-Sprachen.

zahlen ← 17 4 4711 0 10000
3×zahlen

Schon mal so etwas gesehen? Irgendeine Idee, wie die Sprache heißt oder gar wie das Ergebnis lautet?

0
SchakKlusoh 28.11.2016, 20:09
@TeeTier

Mir fällt keine ohne besondere Eigenheiten und Spezialkonzepte ein.

Siehe meine Posts mit den Beispielen. Es gibt sie.

0

Gibt sehr viele Ähnlichkeiten aber auch große Unterschiede. Wenn du eine Sprache bzw. gelernt hast, übersichtilich und nachvollziehbar zu programmieren, fällt dir jede weitere deutlich leichter.

skminga 27.11.2016, 00:17

Hast du vergleiche?

0
SchakKlusoh 27.11.2016, 19:32

Weißt Du, was das Wort Syntax bedeutet? Oder Paradigma? Oder Prozedural?

1
TeeTier 27.11.2016, 20:57
@SchakKlusoh

Merkwürdig, das klingt fast so, als würdest du genauso denken, wie ich. Deine Kritik an meiner Antwort kann ich jetzt noch viel weniger nachvollziehen. Jetzt bin ich etwas verwirrt. ><

0

Im Prinzip sind alle ähnliche, sie basieren auf der Englischen Sprache und so ist der grossteil selbst erklärend.

Meistens musst du nur wissen was genau du machen kannst, wie du es schreiben musst und wie verbinden.

TeeTier 27.11.2016, 04:16

Im Prinzip sind alle ähnliche, sie basieren auf der Englischen Sprache und so ist der grossteil selbst erklärend.

Diese Aussage bezweifle ich dann doch sehr sehr stark. :)

(siehe meine Antwort für Erläuterungen)

0
SchakKlusoh 27.11.2016, 11:46

Mach Dich mal schlau über Programmierparadigmen.

Schau Dir mal Assembler, Java und Forth an. Du wirst Dich wundern, wie ÄHNLICH die sich sind.

1
TeeTier 27.11.2016, 20:59
@SchakKlusoh

Da wir ja offensichtlich einer Meinung sind, interessiert mich jetzt so langsam wirklich mal, wogegen sich deine Kritik an meiner Antwort richtet!

0
SergeantPinpack 27.11.2016, 14:21

Diese Antwort ist auf so vielen Ebenen falsch, da weiß man gar nicht, wo man anfangen soll.

1
SchakKlusoh 27.11.2016, 19:30

Wer hat so wenig Ahnung, daß er bei dieser Antwort DREIMAL auf "Pfeil hoch" klickt???????

1

Was möchtest Du wissen?