Programmiersprache für Anfänger

[ninti]

@darktrym: Da frage ich mich, was du noch für Sprachen kennst und ob Lua die erste war? Scheint nicht so.
Denn ich denke, wenn man, bspw. wie bei mir mit C anfängt und dann eher minimalistische Sprache vorfindet, dann fängt man auch zu "meckern" an, warum diese nicht dies und jenes hat - jedenfalls kann ich mir das so vorstellen, wobei ich dann wirklich Lua nicht mehr anfassen würde.

Vielleicht bin ich zu verwöhnt bei Python aber wenigstens eine Übersicht über neue Typen und Operationen samt Beispiele, Paper warum das so implementiert wurde, wären schön gewesen.

Wo hast du solche Dinge über Python dann her? Meinst du die Entwickler von Python bringen es immer auf der Seite raus?
Okay, die Python Seite schaut ja anders aus, aber hier hast du eigentlich genug Infos.
Sonst klar, wenn eine Sprache mehr Bewunderer hat, dann macht man ja gleich eine fette Seite mit allem drumherum.
Lua scheint da eher eine "Nische" zu sein, um jetzt nur das Wort benutzen zu dürfen.
Ich frag mich jetzt, ob C eine Seite hat. ^^
Ich konnte keine finden.

Du scheinst dann "verwöhnt" zu sein, sag ich einfach, ohne dich jetzt beleidigen zu wollen.
Außerdem, wenn neuer Standard rauskommt, dann kauft man sich gleich das dazugehörige Buch.
Sonst hätte ich auch gerne eine Seite, wo alles zu der Sprache geschrieben steht.

 

[darktrym]

Wenn man Lua im gleichen Kontext zu C, Java, Python nennt, könnte schon der Eindruck entstehen, Lua könnte da irgendwo mithalten als Allzwecksprache. Aber die Lücken sind ja so offensichtlich für jemanden mit Vorkenntnissen, das man jeden Programmieranfänger nur davon abraten kann. Es ist schwieriger zu programmieren(umständlicher), unleserlicher und somit auch wartungsanfälliger. Schon die Weitergabe des Geschaffenen bedarf ein Anleitung.

 

[Yamagi]

Vielleicht sollte man der Fairness halber nochmal dazu sagen, dass Lua in erster Linie als Sprache zum Einbinden in Anwendungen gedacht ist. Nicht, um damit eigenständige Anwendungen zu schreiben. Auch wenn das natürlich irgendwo möglich ist. So stellt die Mutteranwendung im Prinzip die Funktionalität und Lua komponiert sie nur noch mit wenigen Zeilen.

 

[ninti]

@Yamagi Kann ich dann mit C Lua einbinden?
Bzw. welche Muttersprache ist es dann, die du erwähnst? Oder kann es sein?

So gesehen ist Lua dann doch nichts für den Anfänger. Ich find das ganze schon etwas irritierend.

 

[Rakor]

Lua wurde hauptsächlich zur Integration in C-Anwendungen entwickelt. Im Lua-Buch gibt es auch einen recht großen Bereich der sich damit befasst. Lua ist eine Sprache für Plugins und Konfigurationen. Für umfassende Anwendungen macht es kein Spass da es einfach einige seltsame Annahmen macht.

 

[darktrym]

War nicht die Ausgangsthese das Lua für Spieleprogrammierung geeignet sei? Und da würde ich schon ein Veto nehmen. Lua um KI zu programmieren oder anderen Nichtprogrammierern Anpassungen an def. Schnittstellen vornehmen zu lassen, ok, aber niemals alleine um komplexere Sachverhalte abzudecken.

 

[ninti]

War nicht die Ausgangsthese das Lua für Spieleprogrammierung geeignet sei?

Glaub jetzt habe ich den Überblick, man benutzt Love2d + Lua, da man mit Lua Plugins in seinem Spiel programmieren kann(?)

Wie sagt man das so schön, da lege ich dir die Wiki ans Herz?
Siehe unter "Beispiele für den Einsatz von Lua" da kriegst du große Augen wie ich
So wie das ist, ist Lua eher eine Plugingerichtete Programmiersprache bzw. nur für Plugins ausgerichtet und weniger zum Programmieren und da soll ein Anfänger damit was machen können?
In meinen Augen scheint das eher so, dass wenn der Coder kein Bock mehr aufs Schreiben hat, dann nimmt er mal kurz Lua und gut.

Nun, deshalb habe ich auch ganz am Anfang ja geschrieben, dass Bash Scripting da noch am besten für den Anfang ist.
Man lernt die wichtigen Sachen kennen, welche auch nicht aufs Detail "gucken" und lernt dazu noch mehr über Linux/Unix.
Also 2 Fliegen mit einer "Programmiersprache" ( Ja ich weiß..... )
Und nur um zu begreifen und kennen lernen reicht das alle mal, anschließend wenn man eh Scripten nicht will, kann man es wieder vergessen.
Und sich dann auf die richtige Programmiersprache konzentrieren.
Das hängt aber auch damit, welche Programmiersprache die nächste sein soll.
In meinem Fall zu C, könnte ich so gehen: Bash -> Pearl - > C
Denn Bash für den Anfang, Pearl um C reinzuschnuppern und dann C um endlich alles verstehen zu können.
Man könnte aber auch über Csh ins C gehen, da die Shell ja viel mit C zu tun hat.

Fazit: Ich finde seine Frage ist eher eine falsche, da jede Sprache, wenn man damit beginnt, nicht wirklich Anfänger freundlich ist.
Wobei, was weiß der Anfänger nun? Was ist sein Wissensstand? Fängt er bei 0 an, dann müsste man ihm erst mal eine "Stunde" erklären, was eine Variable ist.
Weil Variable ist ja nicht nur der Name, welche definiert und deklariert wird. Aber dass wisst ihr besser als ich.
Also das Ganze ist ziemlich subjektiv bezogen.

Sorry wenns wieder lang und Unsinn ist (?), irgendwie mag ich mit euch zu diskutieren.

 

[sternchen]

Meinst Du mit Pearl vllt Perl?

 

[rubricanis]

Vielleicht sollte man der Fairness halber nochmal dazu sagen, dass Lua in erster Linie als Sprache zum Einbinden in Anwendungen gedacht ist. Nicht, um damit eigenständige Anwendungen zu schreiben Auch wenn das natürlich irgendwo möglich ist.

Lua wurde im technischen Bereich zunächst als "Glue-Language" entwickelt, vergleicbar TCL oder Perl, also um unterschiedliche Applicationen miteinander zu verbinden. Natürlich kann man damit genauso wie in Python oder Perl ganze Applikationen entwickeln, wieweit das Sinn macht ist eine andere Frage, genau so wie bei Phyton oder Perl.. Aber natürlich ist es wie jede dynamische Sprache zur Entwicklung von Prototypen bestens geeignet. Nur muss man das dann auch tun...

So stellt die Mutteranwendung im Prinzip die Funktionalität und Lua komponiert sie nur noch mit wenigen Zeilen.

Umgekehrt wird eher ein Schuh daraus. Nach Main() wird der größte Teil in Lua geschrieben und nur für die zeitkritischen Teile wird C/C++ eingesetzt, sei es statisch gelinkt oder dynamisch.. Das ist so einfach billiger und schneller in der Entwicklung. Und anders als andere Skriptsprachen läßt es sich eben auch leicht einbetten. Adobe Leightroom ist ein bekanntes Beispiele dafür, aber eben auch viele Spiele.

Anders als Python, Ruby und Co versucht Lua nicht eine vollständige Programmiersprache zu sein sondern ist bewußt klein gehalten, was sich sowohl in de Geschwindigkeit als auch im Speicherverbrauch auswirkt, - also keine "Batteries included". Wer also "the job done" haben möchte, wird eher Python wählen, wer klug ist und evtl. schon einige LuaLibs rumliegen, nimmt Lua.

Lua ist wie C minimalistisch. Anders als C verfügt es aber über wichtige high-level Konzepte wie Closers. Coroutinen GarbageCollection etc. Und anders als Python & Co zwingt es niemanden eine bestimmtes Programmier-Paradigma auf. Gerade deshalb ist es für Anfänger besonders gut geeignet. Hier wird ihm nämlich nicht vorgegaukelt dass es nur eine einzige richtige Art und Weise zu programmieren gäbe, wie z.B. eine bestimmte Form von OOP, vielmehr kann er unterschiedliche Konzepte entwickeln und verwenden und sieht dann schon was Vorteile hat und welche Nachteile damit verbunden sind. Wer weiss was manche Dinge an Overhead produzieren geht mit Code etwas zurückhaltender um.

Im übrigen läßt sich Lua bestens standalone zum skripten verwenden, also als Ersatz von Shell-Scripts. Evtl. sollte man dann den Command-Interpreter in C schreiben.

 

[rubricanis]

Für umfassende Anwendungen macht es kein Spass da es einfach einige seltsame Annahmen macht.

Was meinst du damit ?

 

[Rakor]

z.B. dass eine Variable erst mal global ist wenn ich es nicht extra anders vorgebe. Das ist für Konfigscripte ja ok, aber für ernsthafte Programmierung ist es .... nicht so dolle

 

[Rakor]

Ich versteh bis heute nicht wie man Shell-scripte zum Einstieg in die Programmierung empfehlen kann. Ich halte es für einen gänzlich ungünstigen Einstieg. Zum Einen ist die Syntax von Shell-Scripten sehr eigen und zum Anderen ist es (für mich) kein Programmieren an sich, sondern eher zusammenleimen von unterschiedlichsten Programmen (die auch wiederum alle Ihre eigene Syntax haben).
Programmieren lernt man am besten mit einer durchgängigen Sprache. Ich weiss auch nicht wo das Problem ist mit "umfangreichen Sprachen". Keiner nutzt den kompletten Sprachumfang der einem von solch einer Sprache geboten wird, braucht man aber auch nicht. Im Gegenteil für einen Anfänger ist es evtl einfacher mit Strings hantieren zu können bevor es zu char* geht und er sich alles selbst von Hand bauen muss.

 

[rubricanis]

z.B. dass eine Variable erst mal global ist wenn ich es nicht extra anders vorgebe. Das ist für Konfigscripte ja ok, aber für ernsthafte Programmierung ist es .... nicht so dolle

Na gut, Peanuts! Lua hat wie alle Sprachen ihre Idiosynkrasien die zumeist aus der Geschichte zu verstehen sind. Und dann schlägt die Backward-Compatibilität zu. Ich schreibe "local" schon aus dem Rückenmark heraus. Aber das ist nun wirklich kein HIndernis für ernsthafte Programmierung. Andererseits: Das Semikolon, und gelegentlich auch das Komma bei C/C++ bingen mich um!

Yep, Shell-Scripte sind absoluter Schitt!

 

[Rakor]

Das wollte ich damit auch nicht ausschließen, ich sag nur, dass es (mir) damit kein Spass machen würde was größeres zu schreiben. Und das ist halt auch was was einem Anfänger evtl. beim Umstieg etwas Schwierigkeiten machen könnte.
Ich hab mich mal in Lua grob eingelesen, mich dann aber auch nie weiter mit beschäftigt. Es gab da einfach einige Dinge dir mir nicht so zusagten.

 

[ninti]

ich versteh bis heute nicht wie man Shell-scripte zum Einstieg in die Programmierung empfehlen kann.

Mir gings eher weniger, was für Kommandos es gibt, sondern mehr das dort auch Operationen und Kontrollstrukturen gibt.
Man muss/soll sich auch nicht gleich drauf "aufhängen", sondern eher als kleine Einleitung sehen.
Und Lua hat bestimmt auch eine andere Syntax als C.
Klar Shell Scripting ist keine Programmierung, aber manchmal schauts schon danach aus.
Ansonsten, jeder mag anders, dir sagt Shell nicht, den anderen doch.
Genauso wie jeder sagt lern am Anfang kein C, wo anders steht, dass es eine "Anfängersprache" ist.
Vielleicht ist es auch eine Anfängersprache, weil damit alles angefangen hat?
Ja ich weiß, vor C gabs noch B usw.

Das alles ist zu sehr subjektiv, um sagen zu können, "diese Sprache musst du als allererstes lernen".

 

[chaos]

Meinst Du mit Pearl vllt Perl?

Ich gehe doch davon aus, dass ninti Perl von Pearl unterscheiden kann:
http://de.wikipedia.org/wiki/PEARL

 

[rmoe]

Fagg! Wir können das Forum hier dicht machen. Es hat seinen Daseinszweck nicht erfüllt, wir sind gescheitert. Wir konnten ninti nicht überzeugen.

Was mich etwas misstrauisch macht ist, dass die Erde sich noch zu drehen scheint.

 

[rubricanis]

Da fällt mir gerade ein: Du kannst folgendes in dein init.lua schreiben dann ist das Problem mit den globalen Variablen gelöst.

----- metatable von _G modifizieren -----
setmetatable(_G, {
    __newindex = function (_, n)
        error("attempt to write to undeclared variable " .. n, 2)
    end,
    __index = function (_, n)
        error("attempt to read undeclared variable " .. n, 2)
    end,
})

------ declare global variable -----
function declare (name, initval)
     rawset(_G, name, initval or false)
end

Benutze ich zwar nicht, aber wen es stört das globale Variable automatisch gesetzt werden, muss die dann halt mit declare einfügen. Ansosnten bleibt alles beim alten.

Es gibt noch einige andere Tricks die man anwenden kann wenn einen etwas stört. Es ist sowieso gut globale in lokale zu überführen da dass dann sehr viel schneller ist. Lua ist eben unwahrscheinlich flexibel was man nutzen kann um alles an seine eigenen Bedürfniss anzupassen.

 

[ninti]

Perl oder doch kein Pearl? ^^
Ich habe meine kleinen Schreib-Denk-Fehler und Perl ist da nicht das einzige dabei.

Ja, die verdammte Kugel dreht sich immer noch!

Yep, Shell-Scripte sind absoluter Schitt!

Ja stimmt, aber sehr dienlich.

 

[Athaba]

@darktrym Ja, Lua ist ganz weit weg von Python, in vielerlei Hinsicht, aber wenn du so Dinge wie UTF-8 erwähnst ist ja Python(2) auch nicht sehr berühmt für angenehmes Arbeiten. [Nur damit das nicht nach Flame klingt: Setze selbst großteils auf Python bei meinen persönlichen Projekten, wo ich es mir aussuchen kann]

Du wirst als jemand der Python haben will aber ganz einfach nicht glücklich werden mit der Sprache. Die Sprache ist extrem minimal gehalten und einen Punkt der die von dir gezeigten Probleme vielleicht etwas in Perspektive stellt ist, dass die Sprache zu einem recht großen Teil Embedded genutzt wird, also du meist außenrum C oder C++ bzw. eine Software hast. Ein paar Beispiele sind neben diversen Engines und Frameworks für Spiele zum Beispiel die Datenbank Redis, der nginx Webserver, Snort scripting, VLC, Wireshare, PowerDNS scripting so wie diverse Window Manager. Auch in der Webentwicklung tut sich mit OpenResty seit einer Weile viel.

Aber ernsthaft, geht Sprachen ganz generell nicht so an, dass ihr eine Sprache habt die euch gefällt und dann erwartet, dass die neue Sprache genau so ist. Ich entwickle selbst kein Lua, aber wie gesagt kenne ich mittlerweile ziemlich viele Leute, die mit Lua angefangen haben und entweder bei der Spieleprogrammierung geblieben sind oder sich von dort aus in eine Richtung entwickelt haben, die sie dann interessiert hat. Dadurch das Lua eben in allen möglichen Bereichen embedded wird ergibt sich eine ungeheure Menge an Möglichkeiten in die man sich entwickeln kann. Lua ist eben ziemlich klein, was ein großer Unterschied zu typischen Skriptsprachen (Ruby, Perl, Python, JavaScript ist). Die Diskussion hatten wir ja gerade. Dinge werden aufwendiger, umso kleiner die Sprache ist, dafür hat man schneller einen Überblick.

Kurzum: Jedem das seine. Ob du's glaubst oder nicht, aber es gibt Leute, die nicht mit Python können, eben wegen den Unicodesachen, wegen 3/2 = 1 (das macht Leute echt oft fertig, vor allem wenn sie noch nie was von Floating Point gehört haben, aber man kann es besser angehen, als Python das macht oder einfach wissen wie man damit umgeht), weil man Variablen nicht explizit als lokal definieren kann, weil sie das Handling von Modulen komisch finden, etc. Andere beschweren sich, dass Python so grottenlangsam ist.

Wie geschrieben, verwende ich auch meist Python, wenn ich es mir aussuchen kann, aber ich find's doof wenn Leute sagen, Sprache X ist blöd, weil sie nicht Python ist und Python wird häufig herangezogen, weil es derzeit eine recht große Community hat. Leider führt das aber zu dem Effekt, dass viele nicht mal Probleme einsehen, die in Python 3 gefixed wurden. Damit spreche ich nicht explizit dich an, aber es ist ganz generell ein Problem, wenn eine große Community ein Problem immer auf die selben Weg angeht und sich so alle Vergleiche auf die Vor- und Nachteile einer Sprache beziehen. Ist auch immer wieder komisch, wenn ich über Blogs stolper, da jemand seit 10 Jahren Java programmiert, sich dann drei Tage eine Skriptsprache ansieht und dann wundert und darüber aufregt, dass die Sprache nicht ein besseres Java ist.

Ich meine nur, dass Lua, das versucht möglichst klein zu sein vorwirft, dass es von Grund auf nur wenig OO-Gimmicks bietet (und damit keine Array-Klasse mit Append-Methode), wie Python, dann geht man das glaube ich etwas falsch an. Auch dreht sich alles in Lua um (Meta)Tabellen, weshalb die meisten egal, was das nun in C oder Python wäre Tabellen mit .insert und .remove bearbeiten, aber ich glaube das geht dann zu weit.

Wie gesagt, ich bin kein Lua-Programmierer sondern habe nur zugestimmt, dass es ganz gut sein kann damit zu beginnen, weil man ein Feeling bekommt und trotzdem, sehr sehr weit kommt. Die Sprache ist einfach (im Sinne von klein), gibt Bibliotheken für alles (FFI, Netzwerk, Async, alles an Datenbanken, etc.), eine was ich so mitbekomme recht große und hilfsbereite Community und egal, ob man seinen Windowmanager skripten oder seinen IRC-Client erweitern will hat man was davon die Sprache mal angeschaut zu haben.

Ich bin mir auch nicht sicher was du mit Versionierung meinst. Redest du von Modulen/Bibliotheken oder von der Sprache? Bei der Sprache finde ich es recht spannend, dass durchaus mehrere Featurereleases 5.1-5.3 noch breite Anwendung finden und es keinen Rush auf jedes neue Feature gibt (scheinbar werden bitwise Operators und UTF-8 garnicht so dringend gebraucht bzw. wird gerne auf eigene Implemtierungen zurückgegriffen). Lua kommt nicht mit sowas, wie pip, aber es gibt eigenständige Projekte, allem voran LuaRocks, das die meisten Leute, die rein Lua verwenden (und eben nicht in einer Engine, Datenbank oder ähnlichem, was doch ein recht kleiner Teil zu sein scheint). Das sind aber alles so Dinge, die ich aber auch nur weiß, weil ich ab und zu News-Links klicke oder weil ich das eine oder andere Programm, das stark oder ausschließlich auf Lua setzen verwende, Prosody (verbreiteter XMPP Server), CorsixTH (Theme Hospital Engine Klon) zum Beispiel, aber ich entwickle bei keinem der Projekte mit und habe auch keine Patches geschrieben. Wie gesagt, ich bin kein Lua-Programmierer und habe mich nur mal ein wenig damit gespielt und jemanden bei einem Löve-Projekt ausgeholfen, was ganz gut ging, ohne mich damit zu beschäftigen. Auch habe ich Code gelesen. Meine Aussage, dass Lua sehr leicht ist basiert eben darauf, dass der Code leicht zu lesen war und dass ich ohne ein Tutorial zu lesen mithelfen konnte und Dinge verständlich waren.

EDIT: Ja, ich finde auch, dass Tabellen für alles komisch sind. Bei den neueren Features ist es aber wirklich so, dass das in den meisten Fällen was für den C-Code außen rum oder Calls zu C-Code zu sein scheint, kann ich aber mangels Erfahrung nicht gut beurteilen, nur ist Lua doch etwas zu populär (was nicht heißt, dass die Sprache "gut" ist), als das es so ein massives Problem sein könnte und ich vermute mal es liegt daran wo und wie die Sprache hauptsächlich eingesetzt wird.

 

[darktrym]

Ich weiß nicht genau was du meinst, aber UTF8 ist in Python schon lange drin, vermutlich sogar schon immer. Eigentlich brauchts ja nur die En-/Dekodierung von Zeichenketten, alles andere sind Luxusprobleme. Ein Rätsel wie die Portugiesen nur mit ASCII leben konnten.
Auch die Verarbeitung von externen Datenquellen(struct) sind auch für Lua elementar, gerade wenn man das im Embedded-Umfeld einsetzen will. Das hat man vorher von Hand zurecht gefrickelt, ein Unding. Für mich ist das alles ein Indiz das mit der tatsächlichen Nutzung/Verbreitung nicht sehr weit her ist. Ich hab das öffentl. Dokumentationsbuch zum 5er gelesen. Da wird allen ernstes verteidigt, das Workarounds für fehlende Datentypen ok ist. Im Endeffekt darf man bei größeren Projekten lauter Helper basteln um diese Lücken im Sprachdesign zu verstecken. So sollte eigentlich keine moderne Programmiersprache sein. Ich kann ja nochvollziehen, wenn das technisch eine Herausforderung darstellt, aber es ist ja häufig nur syntaktischer Zucker. Ein Datentyp mit dem man theoretisch alles nachbauen kann, aber dann doch soviel Eigenanteil hängenbleibt, ich weiß nicht ob ich die Cleverness da richig zu schätzen weiß.
Und zu den Beispielen für Löve und den gesichteten Pacman, welches ich mal überflogen hab. Löve nimmt einiges der klass. Spieleprogrammierung einem ab, wesentlich mehr als SDL, was den Code erfreulich lesbarer macht, aber das ist kein Feature von Lua. Es werden nur ein Bruchteil der Konstrukte gebraucht und diese wiederholen sich ständig. Es wäre schön gewesen, dass man Bereiche vergleichen oder der In-Operator effektiver genutzt werden könnte statt IF-Kaskaden zu propagieren. Diese Prosody sieht dahingehend recht erwachsen aus aber vieles gehört da nicht hin und sollte niemals selbst implementiert werden müssen.
Lua kommt mir so vor, als hätte man die Pläne der Einzelteile eines Schweizer Taschenmessers und weigert sich diese fertig, zusammengebaut, auszuliefern. Das ist umso ärgerlicher weil vieles mit geringen Aufwand in ein annehmbaren Zustand gebracht werden könnte, IMHO.

 

[rmoe]

Ich bezweifle ja, dass Fachsimpeleien über bevorzugte Sprachen einen Anfänger weiterbringen. Aber OK, hier geht's ja auch nicht wirklich um einen, der wirklich programmieren lernen will.

3/2 = 1 treibt Leute in den Wahnsinn? Gut so! Dann erleben sie ganz praktisch, warum jede halbwegs gesunde Sprache zwischen Ganzzahlen und Fließkommazahlen unterscheidet.

Aus eben solchen Gründen empfahl ich (wenn auch nicht begeistert) Pascal. Weil die ganzen bequemen Sprachen mit automatischen Datentypen vielleicht bequem wirken, aber auch die Entwicklung von Unsitten fördern. Und der Luxus ist obendrein dünn und unzuverlässig (siehe 3/2); letztlich, das lässt sich zumindest bei heute gebräuchlichen Prozessoren nicht umgehen, gehören Datentypen zum A und O von Programmierung.
Ein gut ausgebildeter Programmierer hat's in Fleisch und Blut, der wird, wenn er floats braucht, vollautomatisch und im Halbschlaf "3.0" tippen. Und da sind wir beim wirklichen Nutzen der ganzen interpretierten bequemen Hoch-Sprachen: kein housekeeping, keine weitergehenden Details, einheitliche Schnittstelle zu massenhaft Bibliotheken (und kein header Gefummel), etc.

Dahinter steckt eine hier noch nicht angesprochene Grundformel, nämlich diese: Interpretierte Hochsprachen sind schnell und billig zu nutzen, aber das Produkt läuft teuer und langsam. Compilierte (eher lower level) Sprachen sind teuer und aufwendig bei der, eher langsamen, Produkterzeugung, aber das Produkt läuft billig und schnell (und meist auch stabiler und sicherer).
Daraus ergibt sich unmittelbar eine Leitlinie: Für Einmal oder Gelegenheitsjobs interpretierte Hochsprache und für häufig genutzte Produkte hoher Qualität und Leistung compilierte eher lower level Sprachen.

Der Gral, den so etliche gesucht haben und der mit so etlichen Anläufen versucht wurde, den gibt es nicht. Es kann ihn gar nicht geben, jedenfalls nicht mit heutiger Technik. Denn der deal läuft letztlich immer darauf hinaus, dass man für die Flexibilität und bequeme Programmierung irgendwo bezahlen muss und, wenn auch selten erwähnt, auch darauf, dass Maschinen uns nach wie vor nicht ersetzen können und schon gar nicht einen guten, erfahrenen Entwickler.

Zurück zum Anfang: Programmieren lernen (ernst gemeint) heisst notwendig auch lernen, dass es und welche Datentypen es gibt und warum es die gibt. Denn das hat ja Gründe, das ist ja Ausdruck technischer Gegebenheiten. Und es heisst auch zu lernen, wie man die Grundbausteine nutzen, kombinieren, usw. kann zu komplexen Datentypen. Und es heisst, den Unterschied zwischen Code und Daten und den zwischen Stack und Heap zu lernen und auch, woher der Speicher eines Programms überhaupt herkommt (und dass das heutzutage auch de facto von der disk sein kann oder von einem anderen System oder ...).

C ist insofern sehr gut geeignet. Zugleich ist es alt und für die allermeisten Situationen unnötig aufwendig. (Modernes Object-) Pascal ist auch deshalb eine gute Empfehlung, weil es "menschengerechter" und etwas moderner und weniger martialisch ist. Nochmal: Mögen tue ich Pascal kein bisschen, aber das war nicht die Frage; die drehte sich um Programmieren lernen.

Python empfehle ich, weil es weniger minimalistisch und exotisch ist als z.B. Lua, dimensional besser zu erlernen als Perl, viel gesünder und professioneller als php. Und, brutal gesagt, weil viele die sagen "ich will programmieren lernen" eigentlich meinen "ich will cool sein, spiele basteln und vielleicht ne schicke webseite mit einigen Gadgets" (also nicht programmieren sondern spass-fummeln).
Lua finde ich rein technisch interessant. Die Jungs haben ein paar mutige Schritte gewagt, ein paar sehr interessante Ansätze implementiert und sogar eine notdürftig brauchbare Sprache dabei hinbekommen, Hut ab. Aber zum Programmieren lernen (ausgenommen vielleicht Spiele fummeln) empfehle ich es nicht.
Und, das nur am Rande, es ist auch beileibe nicht die kleinste Implementation einer (zumindest leidlich brauchbaren) Sprache.

 

[ninti]

Und, brutal gesagt, weil viele die sagen "ich will programmieren lernen" eigentlich meinen "ich will cool sein, spiele basteln und vielleicht ne schicke webseite mit einigen Gadgets" (also nicht programmieren sondern spass-fummeln).

Wenn das wirklich so ist, dann hast du mir echt die Augen geöffnet, denn ich dachte man würde immer eine ernste Diskussion darüber führen wollen. Jetzt nicht nur in diesem Forum.
Ich habe auch schon bemerkt, es gibt auch immer wieder ähnliche Themen, wo "alle drauf springen" und den Threadstarter interessiert es eigentlich gar nicht. Keine Ahnung was das zu bedeuten hat.
Wenn man eh nur fummeln will, dann finde ich HTML/CSS ziemlich gut, da man sich da gut tot fummeln kann.
Und mit JavaScript bzw. Java kann man dann noch ein Spiel vom Browser her basteln - soweit mein Wissensstand.
Wo wir nicht so ernst mit dem "programmieren" nehmen.

Grüße

 

[rubricanis]

Und da sind wir beim wirklichen Nutzen der ganzen interpretierten bequemen Hoch-Sprachen: kein housekeeping, keine weitergehenden Details, ....

So ist es! Und damit werden auch eine Menge Fehlerquellen einschließlich der unsäglichen Fehlermeldungen von C/C++ eliminiert.

Dahinter steckt eine hier noch nicht angesprochene Grundformel, nämlich diese: Interpretierte Hochsprachen sind schnell und billig zu nutzen, aber das Produkt läuft teuer und langsam.

Erzähl das mal einem gestandenen Lisper, der lacht dich aus! Ich habe ja Verständnis dafür dass jemand der in der Bitschieber-Kultur augewachsen ist skeptisch auf dynamische Sprachen schaut, aber es gibt noch eine Welt weit jenseits von Python. Und es gibt gute Gründe späte Bindung einer frühen vorzuziehen.

Der Gral, den so etliche gesucht haben und der mit so etlichen Anläufen versucht wurde, den gibt es nicht. Es kann ihn gar nicht geben, jedenfalls nicht mit heutiger Technik. Denn der deal läuft letztlich immer darauf hinaus, dass man für die Flexibilität und bequeme Programmierung irgendwo bezahlen muss und,...

Klar, z.B. auch mit einem hochgradig optimierenden Compiler. Dann braucht man nicht notwendigerweise, oder nur in Ausnahmefällen, auf Low-level-Werkzeuge zurückzugreifen. Und wer sich ernsthaft mit Datentypen befassen will sollte sich vielleicht besser mit Haskel als C/C++ oder Pascal beschäftigen...

Zurück zum Anfang: Programmieren lernen (ernst gemeint) heisst notwendig auch lernen, dass es und welche Datentypen es gibt und warum es die gibt. Denn das hat ja Gründe, das ist ja Ausdruck technischer Gegebenheiten. Und es heisst auch zu lernen, wie man die Grundbausteine nutzen, kombinieren, usw. kann zu komplexen Datentypen. Und es heisst, den Unterschied zwischen Code und Daten und den zwischen Stack und Heap zu lernen und auch, woher der Speicher eines Programms überhaupt herkommt (und dass das heutzutage auch de facto von der disk sein kann oder von einem anderen System oder ...).

Sicherlich ist das richtig, aber man muss jemanden jemanden der lernt nicht gleich die ganze Kompexität von allem um die Ohren schlagen. Programmieren heißt u.A. Reduktion von Komplexität und genau das leisten eben Hochsprachen.

Und, das nur am Rande, es ist auch beileibe nicht die kleinste Implementation einer (zumindest leidlich brauchbaren) Sprache.

Was sind die kleineren Alternativen, FORTH? S-EXPRESSIONS? ASM?

Du hast zwar nicht ganz unrecht in deiner Einschätzung, aber du übertreibst mal wieder reichlich und übersiehst großzügig die Blindheiten statisch getypter Sprachen. Na ja, language war, da muss man nicht einig sein!

 

[rmoe]

Language war? Unsinn. Rein persönliche Rechthaberei übrigens auch nicht *zwinker

Verzeih, aber teilweise entsteht der Eindruck, dass du, ähm, wie formuliere ich das freundlich, ... weder konkrete Erfahrung mit Sprachentwicklung noch weitergehende Kenntnisse aus diesem Feld hast. Versteh mich nicht falsch, das ist absolut OK und gilt wohl für >90% der Kollegen, nur ist es halt keine Basis für Diskussionen jenseits von wikipedia Übersichten.

Im übrigen habe ich "meine" bevorzugte Sprache nicht mal genannt. Weil es eben *nicht* um "meine ist besser als deine" geht sondern darum zu erörtern, welche Sprache wohl besser (oder schlechter) geeignet ist programmieren (im echten oder im fummler Sinn) zu lernen. Und da sind eben auch Fragen wie community, verfügbare Doku (bevorzugt nicht (fast) nur in Englisch), IDEs usw. durchaus maßgeblich.

Um mal aus dem Nähkästchen zu plaudern, ich habe als (gar nicht verwöhnter) junger Mann als erstes Basic gelernt, aus einem einfachen Grund: Der nette Chef, wo ich mein Studium verdiente, hatte mir zwei Sachen geschenkt, ein 25 MHz Phillips Oszi und einen riesigen "tragbaren" IBM Portable mit kaputtem Netzteil (das ich reparierte und so einen Computer hatte). Dumm nur, dass nicht mal ein Handbuch dabei war und ich mir alles, aber auch wirklich alles selbst zusammensuchen musste an Info; ohne Internet und ohne nennenswerte Ansprechpartner, die sich auskannten. Alles was ich hatte war eine Diskette, die mir jemand zugesteckt hatte mit diversen "Artikeln" zum Thema drauf.
Dass Basic für mich unattraktiv war, war sehr schnell klar. Also C. Und das lernte ich auf die ultraharte Tour. Mit einer Raubkopie des Microsoft Compilers und ein paar kopierten Seiten und einer K&R Bible, die ich nach Wochen warten endlich beim Buchhändler abholen konnte. Mein Vorteil war, das muss ich dazu sagen, dass ich schon reichlich TTL Erfahrung hatte und auch schon "Prozessoren" (in TTL auf Platinen) entwickelt hatte und mich also ziemlich gute auskannte auf der Ebene, die du herablassend "Bitschieberei" nennst.

Würde ich es nochmal so machen? Nein. Das war extrem mühsam, vermutlich nur durch vorhandene Vorkenntnisse überhaupt machbar, langwierig und oft deprimierend, zumal ich niemanden hatte, den ich mal was fragen konnte. Aber so ist es halt nunmal gewesen und ich sehe, dass ich auch sehr profitiert habe von dem harten Weg.
Als Turbopascal weithin verfügbar und üblich wurde, wurde auch Programmieren wesentlich einfacher, vor allem, es zu lernen. Gemocht habe ich Pascal nie, aber ich habe gesehen - und erkenne an - was es in Sachen Erziehung/programmieren lernen geleistet hat. Und zwar auch *wegen* der statischen Typen. Ebenso habe ich gesehen, was im Schnitt herauskam bei C und bei Pascal Lernenden (und gewonnen haben dabei nicht die C Leute ...).

Ich würde Studenten natürlich weitaus lieber Modula-2 lernen lassen, aber da sieht's sehr mau aus in Sachen IDE, community, usw. Oder Oberon, aber da sieht's noch mauer aus und obendrein müssen die Lernenden gleich noch komplett umdenken in Sachen OS. Heute schwanke ich zwischen Ada und (modernem) Pascal, auch aus ganz pragmatischen Gründen. C/C++ sind aus meiner Sicht Randgebiete, z.B. für OS Entwickler. Für den Alltag sind sie weitaus zu ineffizient und zu fehlerbehaftet. Allerdings würde ich sie einem *fortgeschrittenen* Studenten als wichtige Ergänzung vorschlagen.
Und nochmal, nur zur Erinnerung: Ich bin beileibe kein C Hasser. Ich habe 20+ Jahre damit gearbeitet (und oft auch mit C++, das ich allerdings nie mochte. Heute würde ich vermutlich D verwenden, wenn ich noch mit solchen Sprachen arbeiten müsste/würde).

Noch kurz dazu:

Was sind die kleineren Alternativen, FORTH? S-EXPRESSIONS? ASM?

tiny python (ca 80 KB), die rc shell (ca 80 KB) oder auch die gute alte sh (140 KB). Allemal gut geng für eie ganze Menge schnelle jobs. Aber es gibt auch Basic und anderes Zeug, das jedenfalls nicht nennenswert größer ist als Lua.