Welche Sprachen muss man kennen um alle zu können?
-
Vll. auch noch Prolog, obwohl es keine große Rolle mehr spielt. Ich wurde damit in der Uni gequält, kann aber nicht behaupten, dass es mir geschadet hat.
-
LOLAlter schrieb:
hibbes schrieb:
Prozedural: Basic
Imperativ: C
OOP: C++, JavaAhja. Wenn du die drei so schön nebeneinander stellst: erklärst du uns bitte, wieso Basic prozedural ist und C nicht prozedural, dafür imperativ?
LOL Alter! Wenn ich solche Posts lese, lolt es mich schlicht weg.
Rein imperativ sind doch sowieso nur die concatenativen Sprachen wie Forth oder Factor. Typendeklarationen/Definitionen oder mathematische Ausdrücke sind doch schon deklarative Teile, erst Recht bei Sprachen wie Ada. Bei den Concatenativen reihst du dagegen einen Befehl hinter dem anderen an. Selbst neue Wortdefinitionen sind Anweisungen, den Systemmodus von Interpretieren auf Kompilieren umzustellen. Mathematische Ausdrücke gibt es nicht. "2 4 +" sind 3 voneinander völlig unabhängige Anweisungen, auch wenn, wie bei einem mathematischen Ausdruck in umgekehrter polnischer Notation danach 6 auf dem Stack liegt.
Ich sehe es auch eher so, dass man die Paradigmen lernen sollte. Syntax hat man schnell drauf, solange man keine esoterischen Sprachen mit Fokus auf Unlesbarkeit verwendet. Wie beispielsweise Malbolge oder C. :p
-
allescoder schrieb:
Welche Programmiersprachen (möglichst wenige) muss man beherrschen, damit man praktisch jede zur Zeit vorhandene Sprache innerhalb von ein paar Wochen lernen kann? Esoterische Programmiersprache können vernachlässigt werden.
Ich würde sagen, gar keine? Eine Programmiersprache kann man nie "innerhalb von ein paar Wochen" lernen. Eine Programmiersprache ist viel mehr als nur Syntax.
-
Ihr habt ja recht, das war sehr ungenau beschrieben.
Das mit C und imperativ habe ich hier her. http://de.wikipedia.org/wiki/Programmiersprache@Imperator: streite dich mit denen dann lollen die sich weg.
Und von Basic habe ich noch vom GFA-Basic(AtariST) in Erinnerung das dort alles über Prozeduren lief und daher sah ich es als gutes Beispiel dafür. Meine Aufzählung sollte auch nicht bedeuten das die Sprachen nur diese Paradigmen zuzuordnen sind.
@volkard:
Bitte um Erklärung warum Basic nicht eine typische prozedurale Sprache ist und C keine imperative?
-
hibbes schrieb:
@volkard:
Bitte um Erklärung warum Basic nicht eine typische prozedurale Sprache ist und C keine imperative?Beide sind imperativ.
Allerdings ist C darüberhinaus auch prozedural. Und zwar schon immer.
Basic hingegen ist erst seit so modernen Dialekten wie GFA-Basic (1986) prozedural. Schauen wir uns mal das berühmte Basic V2 (1982) an, da wird es schon knapp. Man hat mit gusub/return sowas wie Prozeduren, dort Routinen genannt, machen können. Aber ohne lokale Variablen und ohne Rückgabewert. gosub/return hat Basic schon immer.Damit ist
Prozedural: Basic
Imperativ: C
gar nicht vertretbar.Hingegen könnte man bei
Prozedural: C
Imperativ: Basic
gut argumentieren, daß gosub/return nicht als Mittel reicht, um die Routinen auch Prozeduren zu nenne.
Wikipedia machts zum Beispiel "Der Begriff der prozeduralen Programmierung wird oft synonym gebraucht, setzt aber die Verwendung von Prozeduren voraus, was nicht für jede imperative Programmiersprache gelten muss. Beispielsweise kennen ältere BASIC-Varianten keine Prozeduren."Eigentlich tendiere ich eher dazu, jedes Basic auch prozedural zu nennen. Aber dann muß ich auch ASM, sofern mit Stack und call/return prozedural nennen. Da bin ich unsicher.
-
Ok, danke für die Erklärung. Ist ja doch sehr schwierig alles in seine Schublade zu packen.
Gut an die vielen Basicversionen habe ich jetzt nicht gedacht, sondern habe mich nur an die typsichen Prozeduren von meinem damaligen Basic erinnert(Atari ST, man bin ich alt
)Eigentlich war meine Absicht nur von jedem so gebräuchlichen Paradigma eine oder zwei Sprachen anzuführen und dazu noch Assembler.
Welche Sprachen würdet ihr denn mit diesem Vorhaben eintragen?Maschinennah: ?
Prozedural: ?
Funktional: ?
Imperativ: ?
OOP: ?
-
OOP: Smalltalk (sehr rein), C++/Java (sehr verbreitet)
-
Eine Programmiersprache kann man nie "innerhalb von ein paar Wochen" lernen. Eine Programmiersprache ist viel mehr als nur Syntax.
Ja, aber vielleicht gibt es eine Programmiersprache, in der alle Konzepte enthalten sind. Wie in Scheme ... eine Implementation a la Prolog ist ohne Probleme mittels Continuations moeglich, siehe Schelog. Das ist auch ein Killerfeature und in wenigen (Mainstream)Programmiersprachen zu finden. Desweiteren unterliegen sie in anderen Programmiersprachen einigen Einschraenkungen und sind durch die Syntax manchmal schwerer benutzbar.
Welche Sprachen würdet ihr denn mit diesem Vorhaben eintragen?
Dreimal darfst du raten ...
-
Assembler (kann man wohl als separate Kategorie nehmen; hier geht es nicht um einen konkreten Assembler, sondern um die Art, wie man damit programmiert) und C++/CLI enthalten in diesem Sinn wohl etwa 95% von allem ab, was wirklich jemals gemacht werden muss. C++/CLI alleine deckt ein so grosses Spektrum ab und ist so schwer, dass man, wenn man es einmal wirklich beherrscht, die meisten anderen Sachen im Handumdrehen lernt.
Ich habe C++/CLI gelernt und arbeite nun ohne weitere Vorkenntnisse so ziemlich mit allem, an was ich mich erinnern mag, ohne nennenswerte Probleme. Von C bis C# hat man eigentlich alle C-basierten Sprachen gratis dabei. Man bekommt Erfahrung mit verschiedenen Welten, der komfortablen Welt von grossen Frameworks wie .NET/Java, die hocheffiziente Welt von nativen Bibliotheken wie boost und der Standard Library, wo man fast alles selbst machen muss. Und bis man das alles einmal beherrscht, hat man einen solchen Krieg mit der Sprache, dass einem danach die meisten Sachen recht simpel erscheinen.
Ich konnte so z.B. ohne grosse Einarbeitung recht effektiv im Microsoft Dynamics CRM mit JavaScript programmieren (mit viel XML und SQL), an einem bestehenden, komplexen Silverlight Projekt mit Visual Basic.NET und LINQ weiterarbeiten oder einen ganzen Haufen T-SQL Skripte für die Wartung einer Reihe von Microsoft SQL Server 2008 schreiben. Ich kann über diese Arbeiten mit gutem Gewissen sagen, dass sie einfach waren, solange man eine Dokumentation für die Bibliotheken hatte.
Dann braucht man wohl noch etwas funktionales, aber damit kenne ich mich nicht aus.
-
knivil schrieb:
Eine Programmiersprache kann man nie "innerhalb von ein paar Wochen" lernen. Eine Programmiersprache ist viel mehr als nur Syntax.
Ja, aber vielleicht gibt es eine Programmiersprache, in der alle Konzepte enthalten sind. Wie in Scheme ... eine Implementation a la Prolog ist ohne Probleme mittels Continuations moeglich, siehe Schelog. Das ist auch ein Killerfeature und in wenigen (Mainstream)Programmiersprachen zu finden. Desweiteren unterliegen sie in anderen Programmiersprachen einigen Einschraenkungen und sind durch die Syntax manchmal schwerer benutzbar.
und das kann man bestimmt in wenigen Wochen lernen und meistern, oder? Deine Ausage ändert trotzdem nicht an meiner, du kannst keine Sprache in wenigen Wochen lernen (und beherrschen).
-
Nein, ich habe die Frage so verstanden: Welche Sprache muss man koennen (vielleicht 10 Jahre lang gelernt), um andere Sprachen binnen weniger Wochen zu lernen. Es heisst also nicht, Scheme sei in wenigen Wochen zu lernen.
-
knivil schrieb:
Nein, ich habe die Frage so verstanden: Welche Sprache muss man koennen (vielleicht 10 Jahre lang gelernt), um andere Sprachen binnen weniger Wochen zu lernen. Es heisst also nicht, Scheme sei in wenigen Wochen zu lernen.
Man "kann" Scheme also erst, wenn man Prolog damit als Makro implementiert hat, und alle wichtigen Kombinatoren geschrieben, alle wichtigen imperativen Methoden, und alles, was man als halbwegs übliches Paradigma auffassen kann, in Scheme nachgebaut hat?
Denn eingebaut bietet Scheme das alles nicht, und um es in kurzer Zeit in anderen Sprachen lernen zu können, muss man es vermutlich für Scheme nachimplementieren. Außer man ist ein Supergenie, natürlich.
-
Was ist denn so tolles in Scheme programmiert wurden, als das so ein Wind hier darum gemacht wird?
-
Mr. N schrieb:
Man "kann" Scheme also erst, wenn man Prolog damit als Makro implementiert hat, und alle wichtigen Kombinatoren geschrieben, alle wichtigen imperativen Methoden, und alles, was man als halbwegs übliches Paradigma auffassen kann, in Scheme nachgebaut hat?
Was mir so alles in den Mund gelegt wird ... Jeder wird darueber eine andere Meinung haben. Der amb-Operator ist so alt, wie Lisp selbst, ist aber nicht Bestandteil von Lisp.
Was ist denn so tolles in Scheme programmiert wurden, als das so ein Wind hier darum gemacht wird?
Es enthaelt alle Konzepte, bzw. die Grundlagen. Zwar kann ich auch alles mit C oder Asm nachbauen, aber so meine ich das nicht.
-
Ist ja ganz toll das die Sprache alles enthält, aber wen interessiert das wenn so gut wie keiner mit programmiert?
Gibt es zum Beispiel einen der eine Desktopanwendung erstellen möchte und dann sagt: "Oh wieso machen wie das nicht in Scheme?".
-
Ist ja ganz toll das die Sprache alles enthält, aber wen interessiert das wenn so gut wie keiner mit programmiert?
Den Threadersteller vielleicht. Mir schon klar, dass es dich nicht interessiert.
"Oh wieso machen wie das nicht in Scheme?".
Weil es keiner kennt, weil es nicht Hip ist und weil es nicht von einer Firma promotet wird, wie z.B. Java oder C#. Es sind vergleichsweise (mit Java) wenige, die damit arbeiten, aber es sind genug. Genug in dem Sinne, dass die Sprache weiterentwickelt wird und ernsthafte Anwendungen entstehen. Des weiteren kann man in ihr mit Konzepten experimentieren, die dann in der echten Anwendung mit einer anderen Sprache implementiert werden.
Auch kopieren mehr und mehr Sprachen die Konzepte, wie z.B. Closures in Java 7. Ich bin ja gespannt. Und alle sprechen dann Java dieses "modernes" Element zu, und wie toll doch die Sprache ist und, und, und ... Alles kalter Kaffee.
-
knivil schrieb:
Mr. N schrieb:
Man "kann" Scheme also erst, wenn man Prolog damit als Makro implementiert hat, und alle wichtigen Kombinatoren geschrieben, alle wichtigen imperativen Methoden, und alles, was man als halbwegs übliches Paradigma auffassen kann, in Scheme nachgebaut hat?
Was mir so alles in den Mund gelegt wird ... Jeder wird darueber eine andere Meinung haben. Der amb-Operator ist so alt, wie Lisp selbst, ist aber nicht Bestandteil von Lisp.
Wenn ich dir etwas "in den Mund lege", dann ist das höchstens ein Missverständnis. Und wenn du das hier sagst:
Ja, aber vielleicht gibt es eine Programmiersprache, in der alle Konzepte enthalten sind. Wie in Scheme ... eine Implementation a la Prolog ist ohne Probleme mittels Continuations moeglich, siehe Schelog. Das ist auch ein Killerfeature und in wenigen (Mainstream)Programmiersprachen zu finden. Desweiteren unterliegen sie in anderen Programmiersprachen einigen Einschraenkungen und sind durch die Syntax manchmal schwerer benutzbar.
Oder das hier:
Es enthaelt alle Konzepte, bzw. die Grundlagen. Zwar kann ich auch alles mit C oder Asm nachbauen, aber so meine ich das nicht.
Dann verstehe ich das genau so, wie ich es vorhin verstanden habe.
Es ist auch ziemlich absurd, dass Scheme alle Konzepte enthalten solle. Klar, man kann mit Continuations Exceptions simulieren (mal als Beispiel), und das ist vielleicht sogar praktikabel und nützlich. Aber es ist definitiv nicht "in Scheme enthalten". Scheme enthält keine Exceptions, es enthält Werkzeuge, um Exceptions zu bauen.
Ich denke also nicht, dass es reicht, "Scheme zu lernen", um alle Sprachen in kurzer Zeit lernen zu können, dafür muss man viele Dinge lernen, die nicht in Scheme enthalten sind, und die auch nicht jeder gute Scheme-Programmierer beherrschen wird.
-
Scheme enthält keine Exceptions, es enthält Werkzeuge, um Exceptions zu bauen.
Aber wie aufwendig wird es wohl sein, etwas aehnliches wie Exceptions zu realisieren? Genauso wie der amb-Operator nirgends in Scheme oder Lisp zu finden ist, da er leicht zu implementieren ist, genauso braucht man Exceptions nicht definieren. Obwohl manche Schemesysteme wie Chicken Scheme sie enthalten (z.b. ueber Makros), ist man nicht auf ein Sprachfeature angewiesen. Wahrscheinlich um Continuations zu verbergen, wenn nur das Verhalten Exit-Continuation/Exception benoetigt wird. In diesem Zusammenhang sei noch dynamic-wind zu erwaehnen.
(begin ... (let ((ex (call/cc (lambda (throw) ; try ( ... (throw MyException) ... ))))) (cond ((eq? ex MyException) ... ) ; catch ((eq? ex MyOtherException) ... ) ... (else ; no exception ... ; next code )Aber ich will mich jetzt nicht an Exceptions und so aufhaengen, andere Konzepte sind Closures, Funktionen hoeherer Ordnung oder hygienische Makros. Wobei diese Features mehr Verbreitung gefunden haben. Sicher gibt es Konzepte, die nicht in Scheme enthalten sind, wie die ganzen Designpatterns. Aber manche sind in Scheme (oder anderen funktionalen Sprachen) einfach ueberfluessig.
-
Wir werden uns sicher einig, dass Scheme viel bietet und sich definitiv lohnt. Es ist leichter zu lernen als Lisp, und enthält doch vieles, was einen zu einem besseren Programmierer machen kann.
Aber eben nicht alles! Was zum Beispiel extrem durch Abwesenheit glänzt ist statische Typisierung.
(Zumindest in R5RS. Es gibt ja angeblich Dialekte, die teilweise statische Typen haben.)
-
Wenn ich das richtig verstanden habe ist Scheme also eine Programmiersprache die man programmieren kann?