Welche Programmiersprache lernen? (C, Phyton, Lisp, Swift, Smalltalk?)

[Dietmar (Gast)]

Hallo,

wusste nicht wie ich den Threadtitel gestalten sollte... Ich möchte eine 
Programmiersprache lernen, bin mir aber unsicher welche. Das Thema wurde 
hier schon oft behandelt und ich habe auch bereits einige andere Threads 
durchgelesen.

Erst mal ein paar Infos:

- Ich bin jetzt 50 und werde sicher nicht mehr beruflich damit arbeiten. 
Also bleibt es im Hobbybereich. Ich will aber was neues und 
interessantes lernen und mich dabei nicht unbedingt mit dem Mainstream 
treiben lassen.

- Mein späteres Ziel sind einfache Programme und dass ich ein paar 
IO-Ports auf dem Board lesen/ansteuern kann (und den USB-Port).

- Ich nutze ausschließlich Linux.

- Die Sprache soll leicht erlernbar sein. Wobei da sicher keine 
pauschale Aussage getroffen werden kann und es auch darauf ankommt was 
einem liegt.

- Mittlere Erfahrung habe ich mit PHP. Aber da schreibt man sich 
irgendwie die Finger wund. Mir ist da jedenfalls zu viel überflüssiges 
in der Syntax und mir machte das zuletzt immer weniger Spaß. Mir geht’s 
auch nicht darum Webanwendungen zu schreiben, wollte PHP nur erwähnen um 
zu beschreiben was mir liegt und was nicht.

- Auch wenn C zu den führenden Programmiersprachen gehört, kann ich mich 
nicht so recht damit anfreunden. Ich hab mich schon ein paar mal damit 
befasst und es kam nie Freude auf. Und bei Java verstehe ich schon 
gleich nur Bahnhof. Mir geht schon diese Dot-Syntax total auf den Keks. 
Vielleicht ist das auch der Grund, dass ich nie früher programmieren 
gelernt habe. Mir haben diese Sprachen einfach noch nie gefallen. Da ich 
gerne auch Mikroprozessoren programmieren würde, würde ja fast wieder 
nur C in Frage kommen, aber davon will ich meine Wahl wirklich nicht 
abhängig machen.

- Phyton ist gerade total in Mode, soll leicht erlernbar sein und hätte 
den Vorteil einer großen Community. Der Code gefällt mir aber auch nicht 
so richtig.

So bin ich nun auf Lisp gestoßen, genauer gesagt Common Lisp. Sehe ich 
mir den Beispielcode an, erscheinen mir auch ohne Vorwissen bereits 
Teile davon logisch und leserlich und ich habe das Gefühl, das mir das 
Spaß machen könnte. Aber kann man damit heute überhaupt noch was 
anfangen?

Weitere Sprachen wären vielleicht noch Smalltalk und Swift. Dazu habe 
ich mir zwar noch zu wenige Codebeispiele angesehen, bin dafür aber auch 
noch völlig unvoreingenommen.

[J. S. (Gast)]

Welches Board meinst du bei Punkt 3?

[Chris (Gast)]

C# über .NET Core 2.0
Ruby
Python

Dietmar schrieb:
> Ich nutze ausschließlich Linux

Können alle drei Sprachen

Dietmar schrieb:
> Mein späteres Ziel sind einfache Programme und dass ich ein paar
> IO-Ports auf dem Board lesen/ansteuern kann (und den USB-Port)

Wenn du eine virtuelle serielle Schnittstelle als USB-Bridge nimmst, 
kein Problem. "Natives" USB willst du nicht schreiben (ohne gute Libs 
darunter)

Dietmar schrieb:
> Ich will aber was neues und
> interessantes lernen und mich dabei nicht unbedingt mit dem Mainstream
> treiben lassen.

Finde ich den falschen Ansatz. Die Sprachen werden meinst zum 
Mainstream, wenn sie gut zu schreiben/lernen sind oder es keine 
(sinnvolle) Alternative gibt.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Wenn du Lisp sagst, ist Smalltalk nur logisch ;-) allerdings wirst du 
mit beiden im uC-Umfeld nicht glücklich werden (schade eigentlich, ich 
halte Lisp nach wie vor für eine der klarsten und effizientesten 
Sprachen überhaupt)

Ich denke es kommt darauf an, wie viel Erfahrung du im uC-Umfeld schon 
hast, und was du so vorhast.

Wenn du auch im uC-Umfeld "Einsteiger" bist, empfehle ich Arduino: 
Hardware sehr klar und offen (wichtig!), und die Sprache ist zwar C++, 
aber "reduced to the max", also ohne das ganze abgehobene Gedöns.

ich spiele altersmäßig in einer ähnlichen Liga ;-) hatte zwar 
Elektronik- und Programmier-Vorkenntnisse, aber habe mit Arduino einen 
sehr sanften aber spannenden Einstieg gefunden (auch wenn ich dem 
mittlerweile "entwachsen" bin)

Mein Favorit im uC-Bereich ist aber nach wie vor C, ohne ++

[georg (Gast)]

Dietmar schrieb:
> Der Code gefällt mir aber auch nicht
> so richtig.

Der Wurm muss dem Fisch schmecken und nicht dem Angler, und der Code dem 
Computer.

Warum willst du dir unbedingt ein Hobby antun, an dem dir, nach deinem 
Post, eigentlich alles missfällt? Unbewusster Masochismus? Dafür spräche 
auch dein Hang zu besonders exotischen Programmiersprachen.

Für lustbasiertes Programmieren kann ich dir keine der Sprachen 
empfehlen, genau genommen überhaupt keine der hunderte von 
Programmiersprachen, das war auch nie die Absicht bei deren Definition.

Ich bin erheblich älter als du und habe in letzter Zeit einige neue 
Sprachen gelernt, aber das ist echte Arbeit und geht auch nicht mal so 
an einem Nachmittag.

Nebenbei, PHP würde ich nicht nehmen für direktes Hardware-I/O, ist aber 
nur meine persönliche Meinung. Im Prinzip kann man in jeder Sprache 
alles machen, schon Turing hat bewiesen dass seine Turingmaschine jedes 
denkbare Programm ausführen kann.

Georg

[Stefan (Gast)]

Schau Dir Nim an -- zunächst das Tutorial Teil 1 und 2. (Ich gehe mal 
davon aus Du kannst etwas englisch, sonst bleibt Dir eh nicht viel 
Auswahl.) Ein Job mit Nim ist leider noch fast aussichtslos, aber das 
erwartest Du ja auch nicht. Aber natürlich gibt es eine Reihe netter 
neuer Sprachen -- Nim ist wohl aber am universellsten einsetzbar, 
prinzipiell auch für Microcontroller. Für Apple-Fans ist vielleicht eher 
Swift die erste Wahl, und für Android das alte häßliche Java. Oder jetzt 
Kotlin. Rust ist natürlich interessant, aber wie C++ eher für 
Fortgeschrittene, und man hat nicht so viel Spaß damit. Und wenn Du die 
Einrückungen nicht magst, dann vielleicht Crystal. Die anderen Sprachen 
wie etwa Julia, Elixir, Red, Scala sind eher etwas spezieller 
ausgerichtet. Go ist nicht sehr innovativ und verliert auch schon etwas 
an popularität. Haskell wäre natürlich eine nette Herausforderung, wenn 
Du es Dir zutraust. Die Zeit von Ruby und Python ist meiner Ansicht eher 
vorbei, auch wenn Python noch sehr populär ist. Mit JavaScript könnte 
man natürlich nette Web-Spielerein machen, wenn man das mag, aber die 
Sprache an sich ist ja nicht so schön. Na ja, ist eben ein weites 
Feld...

[Vril (Gast)]

Überwinde Dich - und lerne C, bleibe bei Linux, schau die auch mal 
SystemD-freie unixoide OS wie z.B. die BSDs an.

Unter Linux machst Du am besten alles mit der Shell und somit im 
Terminal.
Benutze den vi bzw. vim als Editor.

Wenn Du keine großen Projekte vor hast, dann meide alles was mit OOP zu 
tun hat und programmiere prozedural.

Später kannst Du C noch mit Assembler und Forth ergänzen.

[Schorsch X. (bastelschorsch)]

Kurz und knapp: C

[Michael R. (Firma: Brainit GmbH) (fisa)]

Chris schrieb:
> C# über .NET Core 2.0
Davon würde ich dringend abraten...

Vril schrieb:
> Forth
Das meinst du nicht ernst, oder? (Ja, ich habe Forth programmiert)

Stefan schrieb:
> Nim ist wohl aber am universellsten einsetzbar,
> prinzipiell auch für Microcontroller.
Wie genau meinst du "prinzipiell"?

Vielleicht lese nur ich "uC" raus, aber da wäre eine einfache und 
funktionierende Toolchain (speziell unter Linux) nicht ganz unwichtig...

[Stefan (Gast)]

Und wenn Du noch unsicher bist, sieh dir Rosetta-Code an:

http://rosettacode.org/wiki/Category:Programming_Tasks

Und ja, C sollte man schon können, da man dann eher versteht, was der 
Computer eigentlicht macht. Man muss es später ja nicht verwenden.

[Marc E. (mahwe)]

http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/
Da wird dir C sehr ausführlich erklärt sehr zum empfehlen.
Assembler würde ich nicht unbedingt mehr anfangen aber C ist sehr gute 
Grundlage, ohne das man Blabla Code schreibt es nimmt einem nicht viel 
Arbeit ab, aber viele Beispiele sind in C und wenn du C verstanden hast 
dann verstehst du auch Python.
Auch ist C noch näher am uC.
Arbeite denn Link oben durch und dann schau dir die Beispiele bei z.B. 
http://www.ulrichradig.de/home/index.php/avr an bisschen damit spielen.

[Dussel (Gast)]

Vril schrieb:
> Benutze den vi bzw. vim als Editor.
Genau. Und programmiere am Besten in Malbolge. :D

Ich denke, Python dürfte gut für dich sein. Das wurde als 
Anfängersprache entwickelt und es macht sehr viel sehr einfach.

[Dr. Sommer (Gast)]

Wenn man diese Frage in einem Software-Forum stellt welches keinen Fokus 
auf Embedded-Programmierung hat, würde keiner mit "C" antworten... C hat 
einfach so viele Fallstricke und selbst simple Sachen wie 
String-Verarbeitung sind unnötig kompliziert.
Wenn also die Mikrocontroller-Programmierung keine Pflicht ist, und du 
"normal" auf Linux z.B. auf einem Raspberry-PI programmieren möchtest, 
nimm lieber eine der vielen High-Level-Sprachen. Diese sind intuitiver 
und einfach frustfreier. Der große Vorteil von Mainstream-Sprachen 
(Java, Python, Go, ...) ist, dass es sehr gute Tools gibt und man zu 
jedem Problem eine Antwort findet. Bei Nischen-Sprachen wird man da 
schneller allein gelassen.
Die Schönheit von Code ist allerdings wirklich kein Argument. Die 
Dot-Notation ist absoluter Standard; in C++ kannst du immer -> nehmen 
wenn du es unbedingt willst, aber welchen Zweck häte das? Eine 
konsistente logische Syntax ist viel wichtiger, aber die haben C und C++ 
nun wirklich nicht.

[Stefan (Gast)]

Michael R. schrieb:
> Wie genau meinst du "prinzipiell"?

1. Der uC sollte schon mindestens 64k Ram haben.

2. Man darf teile der Standardbibliothek nicht verwenden, weil sie den 
GC verwenden.

3. Man muss sich die Register und Hardwareadressen definieren.

Gut, ist schon eine gewisse Einschränkung momentan. Such mal nach "Nim 
embedded" da findet man schon einige Projekte. Für die Fraktion "Dumm, 
faul und gefräßig" die alles fertig vorgekaut haben wollen ist das wohl 
noch nichts. Das mit der Standardbibliothek wird sich wohl demnächst 
auch ändern, die soll dann weitgehend ohne GC auskommen.

[Vril (Gast)]

Dr. Sommer schrieb:
> Wenn man diese Frage in einem Software-Forum stellt welches keinen Fokus
> auf Embedded-Programmierung hat, würde keiner mit "C" antworten... C hat
> einfach so viele Fallstricke und selbst simple Sachen wie
> String-Verarbeitung sind unnötig kompliziert.

Das ist natürlich Unfug - ganze Betriebssysteme wurden in C 
geschrieben...
und die gibt es schon seit 30 Jahren und mehr - ganz im Gegensatz zur 
Halbwertszeit des trashes, namens Blue_Screen_irgendwas aus Redmond.

Und was die hier auch erwähnten Mainstream-Sprachen wie Java und Co. 
betrifft:
Schlecht programmierte Software, die zusätzlich noch extrem langsam ist:
garantiert Java!

[Dr. Sommer (Gast)]

Vril schrieb:
> Das ist natürlich Unfug - ganze Betriebssysteme wurden in C
> geschrieben...
Was genau ist Unfug? Nur weil das OS darin geschrieben ist, muss man die 
Anwendung nicht auch darin schreiben.

Vril schrieb:
> Schlecht programmierte Software, die zusätzlich noch extrem langsam ist:
> garantiert Java!
Ja, weil Java so einfach ist dass es jeder kann, und somit auch viele 
Anfänger damit arbeiten und schlechten Code produzieren. Würde man diese 
schlechten Algorithmen nach C überführen, wären sie dann kein bisschen 
besser. Selbstverständlich kann man auch mit Java sehr gute Software 
produzieren. Und für Anfänger-Programme ist die Performance sowieso 
nicht so wichtig. In C instabile Software zu schreiben ist jedenfalls 
deutlich einfacher, dank Buffer-Overflows, mangelnder Typsicherheit usw.

Ich kenn das hier von den ETechnik-Studenten - die werden mit C gequält 
und müssen lustiges Typ-und-Syntax-Raten betreiben, ala "was bedeutet 
void (*A [4]) (int* [], char**, int (*) (void*, signed*, unsigned*), 
char);"? So wird sichergestellt dass die garantiert keine Lust mehr auf 
Programmieren haben. Das geht ja schon los damit, die drei Bedeutungen 
des Sternchens zu erläutern, oder was ein void* ist. Alles nur unnötiger 
Frust und Hirnverrenkung.

[genervt (Gast)]

Es gibt so hübsche bunte Programmierlernbücher für Grundschulkinder zum 
Ausmalen mit süßen Tieren. Ich glaube das wäre das richtige für dich. 
Oder einfach mal Brainfuck googeln.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Dr. Sommer schrieb:
> Selbstverständlich kann man auch mit Java sehr gute Software
> produzieren

was zu bezweifeln wäre ;-)

[wendelsberg (Gast)]

Wenn Du auf dem PC bleibst und der halbwegs (>= 1 GHz) ist, dann kannst 
Du mit Perl auch so ziemlich Alles erschlagen.

wendelsberg

[Stefan (Gast)]

wendelsberg schrieb:
> Wenn Du auf dem PC bleibst und der halbwegs (>= 1 GHz) ist, dann kannst
> Du mit Perl auch so ziemlich Alles erschlagen.

Allerdings Dummschwätzer kann man auch mit Perl nicht wirklich 
erschlagen.

[Dr. Sommer (Gast)]

Michael R. schrieb:
> was zu bezweifeln wäre ;-)
Alle möglichen großen Websiten sind da (serverseitig!) drin geschrieben, 
wie z.B. Twitter, Google (teilweise), Amazon... An PC-Software könnte 
man LibreOffice oder Minecraft (ja ich weiß, frühe Versionen davon waren 
langsam), Umlet, Plantuml nennen.

[Michael R. (Firma: Brainit GmbH) (fisa)]

genervt schrieb im Beitrag #5303969:
> Michael R. schrieb:
>> Dr. Sommer schrieb:
>>> Selbstverständlich kann man auch mit Java sehr gute Software
>>> produzieren
>>
>> was zu bezweifeln wäre ;-)
>
> womit an deiner Dummheit nicht mehr zu zweifeln wäre

Smiley vergessen?

Dieser Vogel ist tot. tot tot tot. Sozusagen ein gewester.

https://www.youtube.com/watch?v=UE0Jk0KqKRc

[Paul B. (paul_baumann)]

Da Du nicht von Irgendjemandem zum Programmieren getriebn wirst und 
selbst wählen kannst, schalge ich "Pure-Basic" vor
https://www.purebasic.com/german/introduction_linux.php

Die damit geschriebenen Programme lassen sich für verschiedene 
Betriebssysteme kompilieren und zerren nicht einen Wust von .Net und 
sonstwas für Zeug hinterher. Das Programm hat eine deutsche Hilfedatei 
und es gibt ein Forum mit vernünftigen Leuten.

(Ich kam von Algol und Pascal her und das C-artige Zeug verursacht mir 
Übelkeit und Brechreiz.)

MfG Paul

georg schrieb:
> Ich bin erheblich älter als du und habe in letzter Zeit einige neue
> Sprachen gelernt, aber das ist echte Arbeit und geht auch nicht mal so
> an einem Nachmittag.

Wer Alles können will, kann am Ende Nichts richtig. Das Fassungsvermögen 
des Menschen ist nicht unbegrenzt.

[Dr. Sommer (Gast)]

genervt schrieb im Beitrag #5304010:
> Das habe ich oben zitiert. Und nun Ende der Diskussion.
Meinst du Apache Tomcat & Konsorten existieren nur aus Spaß? Aber bitte:
https://readwrite.com/2011/07/06/twitter-java-scala/
https://www.quora.com/Which-programming-languages-does-Google-use-internally
https://www.quora.com/What-programming-languages-are-used-at-Amazon

genervt schrieb im Beitrag #5304010:
> Ich unterhalte mich nicht auf Bravo-Niveau
Ah, erst damit anfangen, und es dann nicht gut finden ;-)

[Stefan (Gast)]

Paul B. schrieb:
> chalge ich "Pure-Basic" vor

Eine Kindergartensprache, die nicht OpenSource ist und auch noch Geld 
kostet? Gut, wenn er sogut wie kein Englisch kann vielleicht. Wobei ich 
mal vermute, dass es für die älteren populären Srachen wie Python auch 
deutsche Foren und Bücher gibt?

[Paul B. (paul_baumann)]

Stefan schrieb:
> Eine Kindergartensprache, die nicht OpenSource ist und auch noch Geld
> kostet?

Geld kostet sie in der Probeversion nicht. Das hättest Du selbst 
herausgefunden, wenn Du den Link geklickt hättest.

...und ihr habt die Sprache tatsächlich im Kindergarten gelernt? Bist Du 
dort schon in der grossen Gruppe? Da sieht man aber, daß die Sprache 
doch recht leicht zu erlernen sein muß.

-Paul-

[Rolf M. (rmagnus)]

Dr. Sommer schrieb:
> Vril schrieb:
>> Schlecht programmierte Software, die zusätzlich noch extrem langsam ist:
>> garantiert Java!
> Ja, weil Java so einfach ist dass es jeder kann, und somit auch viele
> Anfänger damit arbeiten und schlechten Code produzieren.

Genau. Nun die Frage: Ist das ein Vor- oder ein Nachteil?

wendelsberg schrieb:
> Wenn Du auf dem PC bleibst und der halbwegs (>= 1 GHz) ist, dann kannst
> Du mit Perl auch so ziemlich Alles erschlagen.

Ja, sogar dich selber, wenn du den Code später jemals wieder lesen 
willst.

[Dr. Sommer (Gast)]

Rolf M. schrieb:
> Genau. Nun die Frage: Ist das ein Vor- oder ein Nachteil?

Zum Lernen ist es ein Vorteil, wenn es leicht zu erlernen ist. Für den 
Nutzer ist es von Nachteil, wenn der Hersteller einer Software keine 
Qualitätssicherung betreibt und somit von Anfängern programmierte 
schlechte Software veröffentlicht - dafür ist der Preis vermutlich 
niedriger.

[Dietmar (Gast)]

genervt schrieb:
> Es gibt so hübsche bunte Programmierlernbücher für Grundschulkinder zum
> Ausmalen mit süßen Tieren. Ich glaube das wäre das richtige für dich.
> Oder einfach mal Brainfuck googeln.

++++[++++>---<]>-.---[----->+<]>-.+++[->+++<]>++.--[--->+<]>.+[->+++<]>+ 
.+++++.---.--[--->+<]>-.-[--->++<]>-.------.+++++.--[--->+<]>--.+[-----> 
+<]>+.-----.------.+++++.++++++++++++.[++>---<]>--.------------.-[--->++ 
<]>--.-------.+.+++.--[--->+<]>-.-[--->++<]>-.------.+++++.--[--->+<]>-- 
.++[->+++<]>+.--.+++++++++++++.+++[->+++<]>++.+++.+.--[--->+<]>-.-[->+++ 
+<]>--.--[->+++<]>+.+++++++++++.-----------.----.+++++++++++++.++.[++>-- 
-<]>.++[--->++<]>.++++[->++<]>+.[->+++++<]>..--------.+++++++++++++.[--> 
+++++<]>+++.---[->++++<]>-.+++[->+++<]>+.+++++.>----------.--[-->+++<]>. 
-[->+++++<]>-.--[->++++<]>--.-------.-.-[->+++++<]>-.+++++[->+++<]>.---- 
---------.+++.+++++++++.-[->+++++<]>-.-[--->++<]>--.---.+++++++++++++.++ 
+[->+++<]>++.+.++[->+++<]>.------------.++[->+++<]>+.--.+++++++..------- 
.>----[---->+<]>.+[-->+<]>.---[->+++<]>.+++[->++++<]>+.----.--[--->+<]>- 
.-[--->++<]>+.++++.--..+++++++.[---->+<]>+++.+[->+++<]>+.---.--[--->+<]> 
--.[->+++++<]>.+[-->+<]>.+[->++<]>.-[--->+<]>--.++++++++++.+.[---->+<]>+ 
++.+[->+++<]>+.--[--->+<]>-.-[---->+<]>+++.+[----->+<]>.----.+++++++++++ 
.[---->+<]>+++.++++[->++<]>.-[--->+<]>++.------------.+++++.------.+++.+ 
+.------.+.[--->+<]>-.-------.-------.-[--->+<]>--.++[->+++<]>+.--.---.+ 
++++++++++++.+++.-------------.+++++++++.-[->+++++<]>-.+++++[->+++<]>.-- 
---------.+.+++++++++++++.[-->+++++<]>+++.--[->++++<]>-.-[->+++<]>-.--[- 
-->+<]>---.-------------.+++++++++.-[->+++++<]>-.+[->+++<]>+.+.++++.++++ 
+.---------.--[--->+<]>-.[-->+++++<]>.[--->+<]>++.---.--------.+++++++++ 
++.+++[->+++<]>++.++++++++++++..----.----.+++++++++++++.-------.------.+ 
++++++++..++++++.------.-----.++++++++++..++++[->+++<]>.--[--->+<]>-.-[- 
-->++<]>-.++++.[->+++++<]>-.+[->++<]>.[-->+++<]>--.+.[--->+<]>+++.---[-> 
+++<]>.[--->+<]>----.-------------.++++.[--->+<]>---.--[->++++<]>--.+[-> 
+++<]>.+++++++++++++.+.+.+++[->+++<]>.--.++++++++.+++++++++.[++>---<]>.+ 
+[--->++<]>.++++[->++<]>+.--[->+++++<]>.+++++.--[--->+<]>--.+[->+++<]>+. 
+.+++++++++.---.------.--[--->+<]>-.+[->+++<]>+.--[--->+<]>-.-[---->+<]> 
+++.-[--->++<]>--.-------.--[--->+<]>--.+.[---->+<]>+++.[->+++<]>+.--[-- 
->+<]>.+[->+++<]>+.+++++.--[--->+<]>--.+[----->+<]>.------------.+++++++ 
++++.[++>---<]>--.[->+++<]>+.+++++++++++++.-------.--.+.-----.++++++++++ 
+++.-------.--.+++++++++.[----->++<]>++.

Den anderen danke für die konstruktiven Ratschläge.

[wendelsberg (Gast)]

Rolf M. schrieb:
> Ja, sogar dich selber, wenn du den Code später jemals wieder lesen
> willst.

Das kannst Du aber mit jeder Programmiersprache hinkriegen (oder mit 
sinnvoller Kommentierung vermeiden)

wendelsberg

[Lothar (Gast)]

Dietmar schrieb:
> Ich nutze ausschließlich Linux
> nicht unbedingt mit dem Mainstream
> IO-Ports auf dem Board

https://www.xojo.com/raspberrypi/

https://ultibo.org/

Und es gibt auch zu Linux bessere Nicht-Mainstream Alternativen:

https://www.riscosopen.org/

[A. S. (Gast)]

georg schrieb:
> Der Wurm muss dem Fisch schmecken und nicht dem Angler, und der Code dem
> Computer.

Für den Computer wurden sicher nicht mehrere 1000 Programmiersprachen 
erfunden...

[Daniel -. (root)]

Ocaml bzw F#
Haskell

 Beide stammen vom Lisp ab und haben keine C Syntax

[Dieter (Gast)]

Achim S. schrieb:
> Für den Computer wurden sicher nicht mehrere 1000 Programmiersprachen
> erfunden...

Für den Computer gibts Assembler. Zurück zum Ursprung!

nop;
nop;
nop;
nop;
nop;
nop;
nop;
nop;
nop;
nop;

[Dietmar (Gast)]

J. S. schrieb:
> Welches Board meinst du bei Punkt 3?

X86 oder ARM


Lothar schrieb:
> Und es gibt auch zu Linux bessere Nicht-Mainstream Alternativen:
>
> https://www.riscosopen.org/

Linux war etwas eng gefasst. Ich bin auch für andere Betriebssysteme 
offen, solange es kein Windows oder was anderes proprietäres ist.


Dr. Sommer schrieb:
> Die Schönheit von Code ist allerdings wirklich kein Argument.

Na ja, schön muss er nicht sein. Aber er sollte mir schon liegen. Wenn 
es mein Ziel wäre damit Geld zu verdienen, könnte ich mir natürlich 
alles reinpauken. Es wäre jedoch utopisch daran zu denken, dass ich 
damit beruflich noch jemals eine Chance hätte. Also entscheide ich mich 
lieber für das, bei dem ich mich am ehesten frei entfalten kann.

[Paul H. (powl)]

Meine Güte Ihr macht den armen Kerl völlig Banane im Kopf. Wofür soll er 
sich denn jetzt entscheiden?

Dietmar schrieb:
> - Mein späteres Ziel sind einfache Programme und dass ich ein paar
> IO-Ports auf dem Board lesen/ansteuern kann (und den USB-Port).

Wie schon meine Vorredner erörtert haben sind 
Mainstream-Programmiersprachen nicht Mainstream weil sie 
ungerechtfertigt gehyped werden sondern weil sie einfach gut und 
zweckmäßig sind, das sollte für dich also als Kriterium wegfallen. Wenn 
du auf deinem Board (Linux-Single Board Computer?) GPIOs und den 
USB-Port ansteuern willst solltest du vorzugsweise eine Sprache nehmen, 
für die es entsprechende Libraries gibt, und das dürfte vermutlich bei 
fast jeder Sprache der Fall sein. Wenn du zusätzlich noch µCs 
programmieren möchtest dann schränkt das die Auswahl schon etwas ein und 
geht gegen C/C++.

Dass eine Sprache dir nicht gefällt sollte kein Kriterium für dich sein! 
Die meisten Programmiersprachen sind sich in ihren Grundkonzepten sehr 
ähnlich und unterscheiden sich in einigen (wenigen) Sprachfeatures 
untereinander. Lediglich die Syntax ist meist der große Unterschied aber 
sobald du erst mal eine Sprache in ihrem Grundkonzept verstanden hast 
kannst du superschnell auf eine andere, geeignetere Sprache umsteigen. 
Das habe ich selbst festgestellt, nachdem ich die ersten 1..2 Sprachen 
gelernt habe. Es ist genaugenommen gar nicht so wichtig, mit was du 
anfängst, hauptsache zu fängst erst mal an. Worauf du beim Programmieren 
tatsächlich Wert legst wird sich hinterher schon herauskristallisieren, 
keine Sorge. Es ist nicht so, dass du dich ein mal entscheiden musst und 
dann auf deiner Entscheidung festhängst. Insofern: Nimm eine beliebige 
Sprache die deine Anforderungen erfüllt und die populär ist, d.h. für 
die es eine ausreichend große Community gibt, die dir bei Problemen zur 
Seite steht und leg los. Kauf dir notfalls für 20..30€ ein Buch dazu und 
arbeite das mal durch.

Generell würde ich dir einfach Java oder Python empfehlen. Mit denen 
kannst du schon mal sehr sehr viel machen. Wenn du bei Java nur Bahnhof 
verstehst: kauf dir ein Buch, arbeite dich rein! So schwierig ist das 
nicht, höchstens ungewohnt. Die Sprache ist in sich völlig logisch und 
nicht widersprüchlich. D.h. alle Fragezeichen in deinem Kopf lassen sich 
letzendlich - auch für dich - noch auflösen, sei dir da sicher. 
Konzepten wie Objektorientierung wirst du in den meisten Sprachen 
begegnen. Objektorientierung macht aber auch einfach Sinn und ist ne 
tolle Sache, wenn man sie mal verstanden hat. Man kann sie aber für den 
Anfang auch - obwohl sie in der Sprache verankert ist - einfach erst mal 
komplett links liegen lassen.

Viel Spaß! Ich lerne übrigens gerade Python und VBA. Nachdem ich schon 
JavaScript, PHP, C und C# gelernt hatte habe ich Java quasi innerhalb 
von zwei Tagen erlernt.

[Dietmar (Gast)]

Daniel -. schrieb:
> F#

Jetzt fängt es an interessant zu werden. Läuft auch auf 
Illumos-Systemen, wie ich gerade las.

[Dr. Sommer (Gast)]

Paul H. schrieb:
> Die meisten Programmiersprachen sind sich in ihren Grundkonzepten sehr
> ähnlich und unterscheiden sich in einigen (wenigen) Sprachfeatures
> untereinander.
Welch kühne Theorie! Manche Sprachen sehen sich zwar oberflächlich 
ähnlich, unterscheiden sich aber darunter dramatisch. Klassisches 
Beispiel sind Java und C++. Die ganze Laufzeitumgebung ist komplett 
anders, das Speichermodell, die Art wie Funktionen definiert werden, 
RAII-Unterstützung, und natürlich das komplette Metaprogrammierungs-Zeug 
von C++, was in Java quasi fehlt. Das ist nicht nur "ein Sprachfeature", 
das ist die halbe Sprache... Dafür hat Java eine riesige 
Standard-Bibliothek und Reflection.
Von dem "Unter der Haube" her sind sich C# und Java sehr ähnlich, und 
beide weit von C++ entfernt. Da ist Pascal näher dran, was aber rein 
oberflächlich komplett anders aussieht.

Dietmar schrieb:
> Jetzt fängt es an interessant zu werden. Läuft auch auf
> Illumos-Systemen, wie ich gerade las.
Wie war das mit den Nischen-Sprachen ;-) ... Aber okay, es ist .NET und 
läuft dann wie alle anderen .NET Sprachen auf allen davon unterstützten 
Systemen.

[Arc N. (arc)]

Daniel -. schrieb:
> Ocaml bzw F#
> Haskell
>
>  Beide stammen vom Lisp ab und haben keine C Syntax

Letzteres: ja, ersteres: Nein. Ocaml/F# sind Ableger von Ocaml/Standard 
ML/ML/ISWIM. Haskell wurde durch viele Sprachen beeinflußt u.a. Lisp, 
Miranda, ML etc.

Zurück zum Thema: Wenn dem Threaderöffner LISP gefällt, dann kann er 
sich Clojure ansehen. Direkter LISP-Ableger und auch auf 
Mikrocontrollern zu finden. Letztere Variante nennt sich Ferret. Erzeugt 
C++-Code und kommt bei Bedarf auch ohne GC aus. https://ferret-lang.org
Direkt unterstützt werden u.a. auch div. Arduinos und Teensys. Eine 
andere Möglichkeit wäre http://www.ulisp.com/ ebenso u.a. auf Arduinos

[Alles Humbug (Gast)]

Dietmar (Gast) schrieb:

> Ich möchte eine
> Programmiersprache lernen, bin mir aber unsicher welche.

Damit bist du nicht allein.

> Ich bin jetzt 50 und werde sicher nicht mehr beruflich damit arbeiten.

Gut. Damit hast du prinzipiell schon mal alle Freiheiten zur Auswahl.

> Mein späteres Ziel sind einfache Programme und dass ich ein paar
> IO-Ports auf dem Board lesen/ansteuern kann (und den USB-Port)

Suche nach Prg-Sprachen die dir diese Anforderung in einer DIR genehmen 
Art ermöglichen.

> Ich nutze ausschließlich Linux.

Damit sind typische bzw. primär auf Windows ausrichtete 
Programmiersprachen/Umgebungen wohl nicht die erste Wahl für dich.

> Die Sprache soll leicht erlernbar sein.

Das ist subjektiv bzw. Programmiersprachen können einem leicht erlernbar 
erscheinen, wenn man sie interessant und motivieren findet und sie 
können genau das Gegenteil an Gefühlen auslösen, wenn sie einem wie 
Kauderwelsch vorkommen.

> .. PHP. Aber da schreibt man sich
> irgendwie die Finger wund. .. zu viel überflüssiges
> in der Syntax und mir machte das zuletzt immer weniger Spaß.
> bei Java verstehe ich schon
> gleich nur Bahnhof. Mir geht schon diese Dot-Syntax total auf den Keks.

Damit wird es schwierig für dich werden eine Begeisterung für C# oder 
Java zu entwickeln und die Auswahl wird deutlich eingeschränkt.

> Auch wenn C zu den führenden Programmiersprachen gehört, kann ich mich
> nicht so recht damit anfreunden.

Da scheint immerhin noch Hoffnung zu bestehen.

> Vielleicht ist das auch der Grund, dass ich nie früher programmieren
> gelernt habe.

Kann sein, aber das lässt sich auch mit 50 noch nachholen. Heutzutage 
sogar viel leichter, weil es viel mehr Möglichkeiten gibt guten 
Beispielcode als auch guten Lesestoff zu erhaschen.

> Da ich
> gerne auch Mikroprozessoren programmieren würde, würde ja fast wieder
> nur C in Frage kommen, aber davon will ich meine Wahl wirklich nicht
> abhängig machen.

Du meinst wahrscheinlich eher Mikrocontroller. Da ist zwar C quasi die 
erste Wahl, aber es gibt auch käufliche meist auf "modernem 
BASIC"-Dialekt basierende (nicht allzu teure) Komplettpakete bestehend 
aus einer integrierten Entwicklungsumgebung, die vielleicht in Frage 
kommen.

> Phyton ist gerade total in Mode, soll leicht erlernbar sein und hätte
> den Vorteil einer großen Community.

Hat wohl seine Gründe.

> Der Code gefällt mir aber auch nicht
> so richtig.

Tja.

> So bin ich nun auf Lisp gestoßen, genauer gesagt Common Lisp. Sehe ich
> mir den Beispielcode an, erscheinen mir auch ohne Vorwissen bereits
> Teile davon logisch und leserlich und ich habe das Gefühl, das mir das
> Spaß machen könnte.

Seit geraumer Zeit kaum mehr verbreitet. Nach meinem Gefühl ist Lisp 
eher was Historisches aus der Ära der Computer-Anfangszeit.

> Aber kann man damit heute überhaupt noch was
> anfangen?

In Bezug auf Mikrocontroller? Eher nicht ..

> Weitere Sprachen wären vielleicht noch Smalltalk und Swift. Dazu habe
> ich mir zwar noch zu wenige Codebeispiele angesehen, bin dafür aber auch
> noch völlig unvoreingenommen.

Dann wirf auch einen Blick auf Pascal/Lazarus. Vielleicht ist das ja was 
für dich.

[Possetitjel (Gast)]

Dietmar schrieb:

> Also bleibt es im Hobbybereich. Ich will aber was
> neues und interessantes lernen und mich dabei nicht
> unbedingt mit dem Mainstream treiben lassen.

Tcl/Tk.


> - Mein späteres Ziel sind einfache Programme und dass
> ich ein paar IO-Ports auf dem Board lesen/ansteuern
> kann (und den USB-Port).

Board?! Mikrocontroller?! Dann bleibt nahezu nur C.


> - Ich nutze ausschließlich Linux.

Ok. Ich auch :)


> - Die Sprache soll leicht erlernbar sein.

Trifft mMn auf Tcl zu.


> - Auch wenn C zu den führenden Programmiersprachen
> gehört, kann ich mich nicht so recht damit anfreunden.
> Ich hab mich schon ein paar mal damit befasst und es
> kam nie Freude auf.

"Führende Programmiersprache"?!

Das ist mMn der falsche Ansatz. Die Syntax der Programmier-
sprache selbst ist nur ein ganz kleiner Teil; man muss das
gesamte Ökosystem sehen: Standardisierung, Präprozessor,
Sprachdefinition, Compiler, Bibliotheken. C ist als
"portabler Assembler", also für Systemprogrammierung und
systemnahe Dinge super, aber für Anwendungen eher suboptimal.

C hat einige gute Seiten, aber die vollkommen kranke Syntax
gehört mMn nicht dazu.

> Da ich gerne auch Mikroprozessoren programmieren würde,
> würde ja fast wieder nur C in Frage kommen, aber davon
> will ich meine Wahl wirklich nicht abhängig machen.

Warum nicht? Das ist doch das richtige Kriterium.


> - Phyton ist gerade total in Mode, [...]
> So bin ich nun auf Lisp gestoßen, [...]
>  Aber kann man damit heute überhaupt noch was anfangen?

Merkwürdige Frage. Es geht doch um Hobby?!

Aber ich wiederhole meinen Vorschlag: Tcl/Tk.

Mein eigener Weg: Ich hatte Assembler, BASIC, Pascal,
AWK (in dieser Reihenfolge) durch und suchte um 2000
herum eine...
- Scriptsprache, die
- reguläre Ausdrücke kennt und
- elementare Graphikausgabe ermöglicht und
- mit meiner beschränkten Intelligenz erlernbar ist.

Perl fiel wegen Verstoß gegen den letzten Punkt heraus;
Python gefiel mir wegen der Einrückerei nicht, und Java
habe ich auf meiner Linuxkiste nicht zum Laufen bekommen.
Durch mehrere Zufälle bin ich bei Tcl/Tk gelandet und bin
letztlich dabei geblieben.

Für Tcl/Tk sprechen aus meiner Sicht folgende Gründe:

1. Tcl/Tk ist sehr portabel, d.h. für Windows und Linux
(und sicher auch viele andere Systeme) verfügbar.
Sauber programmierte Anwendungen laufen ohne Änderungen
auf anderen Systemen (selbst getestet).

2. Tcl hat in Form des Toolkits "Tk" ein Graphikframework,
das sowohl alle üblichen GUI-Elemente (Buttons, Eingabe-
zeilen, Listboxen, ...) wie auch freie Vektorgraphik bietet.
Diagramme, Schaltpläne, ... sind kein prinzipielles Problem.
Ausdrucken (=PostScript-Export) kostet eine einzige
Programmzeile.
Tk scheint so überzeugend zu sein, dass es in Form von
Perl/Tk, Python/Tk, ... für andere Sprachen übernommen
wurde.

3. Viele "Anweisungen" (vordefinierte Worte) sind identisch
zu C definiert. Späterer Umstieg auf C wird also stark
erleichtert :)

4. Die Ausdrucksweise ist ähnlich kompakt wie in C -- aber
zahlreiche Krankheiten von C wurden vermieden. Beispiele:
- ++ und -- gibt es nicht,
- die blödsinnige Verwechslung von = und == ist ausgeschlossen,
- Pointergefrickel ist überflüssig,
- die Regeln für Verbundanweisung ("Anweisungsblöcke") sind
  einfacher und mMn konsistenter als in C.

5. Alles, was mit Strings ausdrückbar ist, ist einfach und
kompakt machbar. Eine ASCII-Datei einlesen und zeilenweise
bearbeiten ist fast ein Einzeiler.

6. Tcl kennt Listen als elementare Datenstrukturen. Das führt
nach meiner Erfahrung mit der Zeit dazu, dass man Algorithmen
von vornherein anders denkt. Man muss sich weniger mit ärger-
lichem technischem Krempel beschäftigen ("muss der Index jetzt
bis n oder bis n+1 laufen?"), sondern man schreibt einfach
"foreach element $inputliste {...}"


Tcl hat aber auch Nachteile:

1. Die Tcl-Syntax wird als "krude" bzw. "gewöhnungsbedürftig"
bezeichnet. Das ist im Kern auch richtig: Klassische
Zuweisungen der Art "x=1+2" gibt es nicht; die Anweisung
"set x 1+2" bewirkt, dass x anschließend den Wert "1+2"
hat.
Wenn man 1+2 RECHNEN will, muss man "set x [expr 1+2]"
schreiben :)

2. Verarbeitung von Binärdaten ist machbar, aber ein Krampf.
Will man nicht wirklich.

3. Alles, was man normalerweise mit Arrays ausdrücken würde,
geht beschissen (Beispiel: Bildverarbeitung). Machbar, aber
ein Krampf.

4. Ein Typsystem existiert (offiziell) nicht. Das kann lästig
sein, wenn Zahlenrechnung notwendig ist. "10/11" ist nicht
dasselbe wie "10.0/11.0".
Mit "foreach zahl {01 02 03 04 05 06 07 08} {...}" kann man
grandios auf die Nase fallen (weil Zahlen mit führender Null
als Oktalzahlen (!!!) interpretiert werden).

5. Tcl ermöglicht gut strukturierte Programme, unterstützt
das aber nicht sonderlich. Aufgrund der SEHR mächtigen
Stringmanipulation kann man leicht komplett unverständliche
Programme formulieren. ("Man kann in jeder Sprache in FORTRAN
programmieren" :)

6. Tcl ist nicht objektorientiert. Klassen, Objekte, Vererbung
werden nicht unterstützt. Das kann man aber auch als Vorteil
sehen: Kapselung wird durch Namespaces unterstützt, aber mit
dem OOP-Gefrickel (Vererbung, Klassenbibliothek) muss man sich
nicht befassen.
Man braucht aber Disziplin, um lesbare Programme zu schreiben.
Ich bin Pascal-sozialisiert; mir fällt das leicht :)

7. Die Tcl-Gemeinde ist nicht sonderlich "einladend". Das mag
merkwürdig und esoterisch klingen, entspringt aber meiner
Erfahrung: Es gibt unheimlich viel gutes Zeug, aber es wird
recht wenig propagiert, dass es dieses gute Zeug gibt.


Alles in allem ist Tcl die optimale Sprache für mich. Ich
programmiere seit Jahren von Zeit zu Zeit an diversen Tools
herum (u.a. einem speziellen Installationstool für Debian-
Pakete) und habe nie das Gefühl, dass mich die Sprache
einschränkt. Der Projektfortschritt hängt nur von meinen
Fähigkeiten ab, nicht von der Sprache.

[Joachim S. (oyo)]

Was den Einstieg in die Programmierung betrifft, finde ich folgenden 
Artikel von Peter Norvig (seines Zeichens "Director of Research" bei 
Google) sehr lesenswert:
http://norvig.com/21-days.html

Speziell seinen Empfehlungen zur Wahl einer sinnvollen ersten 
Programmiersprache (im Abschnitt "Appendix: Language Choice", fast am 
Ende des Artikels) kann ich mich nur anschliessen; sie lauten:
* "Keep it simple" - Für den Einstieg eine leichte Programmiersprache, 
ohne statische Typisierung etc., kein C/C++/Java oder Ähnliches.
* "Play" - Nimm für den Einstieg eine Programmiersprache, die eine 
REPL-Shell bietet
* "Use your friends" - Nimm eine Programmiersprache, für die Du leicht 
Unterstützung findest, z.B. eine, die Freunde von Dir benutzen. Denn 
gerade am Anfang wirst Du häufig auf Probleme stossen; dann ist es 
wichtig, dass Du schnell Hilfe bekommst)

Das dürften tatsächlich so mit die drei wichtigsten Einflussfaktoren 
sein, die darüber entscheiden, ob der Einstieg in die Programmierung 
erfolgreich ist, oder man schon bald frustriert das Handtuch wirft.

Als konkrete Empfehlungen nennt er drei Programmiersprachen:
- Python
- Scheme/LISP
- Javascript (hauptsächlich deshalb, weil es dafür so viele Tutorials 
etc. im Internet gibt)

Wenn Dir LISP/Scheme zusagt, würde ich mir an Deiner Stelle übrigens 
"Racket" (früher DrScheme genannt) anschauen.
Zum Einstieg in die Programmierung mit "Racket" kann ich da ganz 
besonders die Einführung "How to design programs" an's Herz legen; das 
"Prolog"-Kapitel dieses kostenlosen Buches ist die beste Einführung in 
Programmierung, die ich bislang gesehen habe; innerhalb eines einzigen 
Kapitels lernt man da bspw., eine Animation einer startenden Rakete zu 
programmieren:
http://www.ccs.neu.edu/home/matthias/HtDP2e/part_prologue.html

Da LISP/Scheme allerdings deutlich weniger verbreitet ist als andere 
Sprachen, und es daher als Einsteiger deutlich schwerer ist, da Hilfe zu 
bekommen, wäre meine persönliche Empfehlung unter'm Strich aber wohl 
trotzdem Python. Es hat schon gute Gründe, warum Python seit Jahren DIE 
Einsteiger-Programmiersprache schlechthin ist.

[A. S. (Gast)]

Dieter schrieb:
> Für den Computer gibts Assembler. Zurück zum Ursprung!

Das ist jetzt auch nur eine der mehrere Tausend Sprachen, aus denen ein 
Compiler, Assembler, Interpreter oder was auch immer, für den Computer 
Schmackhaftes (um im Bild zu bleiben) erzeugt.

Assembler hat seine Berechtigung, ist aber keine *Hoch*Sprache sondern 
prozessor-spezifisch.

C ist eine Hochsprache, auch wenn es einige IDB gibt.

Die breite Verwendung von C zeigt, dass sie dem Programmierer schmeckt, 
und ich will auf die Gründe gar nicht eingehen.

Dem Computer ist die Programmiersprache egal, er kann sie gar nicht, 
bzw. nur über einen Compiler/Assembler/Interpreter verstehen.

[Bernd K. (prof7bit)]

Achim S. schrieb:
> Die breite Verwendung von C zeigt, dass sie dem Programmierer schmeckt,

Ich glaube nicht daß dieser kausale Zusammenhang existiert. Das fängt 
schon damit an daß es sehr weit hergeholt ist zu postulieren C würde 
einem Programmierer "schmecken". Ich kenne keinen auf den das zutrifft. 
Man arrangiert sich einfach nur mit dem Übel und versucht damit zu 
leben.

[Dietmar (Gast)]

Arc N. schrieb:
> https://ferret-lang.org
> Direkt unterstützt werden u.a. auch div. Arduinos und Teensys. Eine
> andere Möglichkeit wäre http://www.ulisp.com/ ebenso u.a. auf Arduinos

Was es alles gibt! Da finden sich ja sogar kleinere Hardwareprojekte.

Joachim S. schrieb:
> Zum Einstieg in die Programmierung mit "Racket" kann ich da ganz
> besonders die Einführung "How to design programs" an's Herz legen; das
> "Prolog"-Kapitel dieses kostenlosen Buches ist die beste Einführung in
> Programmierung, die ich bislang gesehen habe; innerhalb eines einzigen
> Kapitels lernt man da bspw., eine Animation einer startenden Rakete zu
> programmieren:
> http://www.ccs.neu.edu/home/matthias/HtDP2e/part_prologue.html

Die Einführung ist tatsächlich sehr verständlich geschrieben.

Danke euch beiden, tolle Tipps! Bei den Seiten habe ich mit Sicherheit 
nicht zum letzten mal reingeschaut.


Dr. Sommer schrieb:
> Ich kenn das hier von den ETechnik-Studenten - die werden mit C gequält
> und müssen lustiges Typ-und-Syntax-Raten betreiben, ala "was bedeutet
> void (*A [4]) (int* [], char**, int (*) (void*, signed*, unsigned*),
> char);"? So wird sichergestellt dass die garantiert keine Lust mehr auf
> Programmieren haben. Das geht ja schon los damit, die drei Bedeutungen
> des Sternchens zu erläutern, oder was ein void* ist. Alles nur unnötiger
> Frust und Hirnverrenkung.

Beruhigend, dass ich nicht alleine dastehe. Und ich dachte schon ich 
wäre total verblödet.

Nach all dem was ich bis jetzt an Antworten gelesen habe, bin ich 
bestärkt darin, das Lisp die richtige Wahl für mich ist. Ich weiß nur 
noch nicht welchen Dialekt. Aber das werde ich sicher leicht 
herausfinden.

[A. S. (Gast)]

Bernd K. schrieb:
> Man arrangiert sich einfach nur mit dem Übel und versucht damit zu
> leben.

OK, dann analog zu Churchills Demokratie:

C ist (für Mikrocontroller, bzw. für eine Reihe von Aufgaben) die 
schlechteste aller Programmiersprachen. Abgesehen von denen, die von 
Zeit zu Zeit ausprobiert worden sind.

[Dietmar (Gast)]

Joachim S. schrieb:
> Was den Einstieg in die Programmierung betrifft, finde ich folgenden
> Artikel von Peter Norvig (seines Zeichens "Director of Research" bei
> Google) sehr lesenswert:
> http://norvig.com/21-days.html

Dieser Artikel hat mir einiges klar gemacht. Gut manchmal etwas 
empfohlen zu bekommen. Wenn ich nur zufällig über diesen Artikel 
gestolpert wäre, hätte ich mir vermutlich nicht die Zeit genommen ihn in 
Ruhe zu lesen.

[Karl (Gast)]

Paul B. schrieb:
> Da Du nicht von Irgendjemandem zum Programmieren getriebn wirst und
> selbst wählen kannst, schalge ich "Pure-Basic" vor

PureBasic habe ich jahrelang gemacht, allerdings hat es einen großen 
Nachteil: Keine ARM-Unterstützung und auch keine geplant. Also läuft es 
nicht auf dem Raspberry Pi.

Daraufhin habe ich rumgesucht und bin nach einem Ausflug zu C - bäh! - 
bei FreePascal (https://www.lazarus-ide.org/) gelandet. Pascal hatte ich 
in Schule und Studium mal, aber dann mangels Compiler nie wieder 
genutzt.

Mit Freepascal geht: GUI und Kommandozeilenprogramme auf Windows und 
Linux PC, ebenso auf dem Raspberry, GUI mit Qt und GTK, Crosscompiling 
von Windows auf Linux PC und umgekehrt, Crosscompiling von PC auf 
Raspberry und .... Crosscompiling auf AVR Controller. Du kannst also 
Deinen AVR Controller in der gleichen IDE mit der gleichen Sprache 
programmieren wie Deinen Raspberry, und dabei sogar die gleichen 
Bibliotheken verwenden (z.B. für nRF Kommunikation).

[Vril (Gast)]

Marc E. schrieb:
> http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/
> Da wird dir C sehr ausführlich erklärt sehr zum empfehlen.

Nein, dieses Buch sollte man nicht empfehlen. Es ist grottenschlecht und 
voller Fehler.

[Theor (Gast)]

Ich würde Dir an sich nicht unbedingt LISP zum Einstieg empfehlen.

Allerdings spricht in Deinem Fall dafür, dass Du LISP anziehend findest. 
Motivation ist zunächst das allerwichtigste Element in so einer 
Situation. Versuch das einfach. Es wird Dir in jedem Fall wertvolle 
Erfahrungen verschaffen.

Kennst Du das hier? http://www.ulisp.com/ Das gibts auch für die 
Arduino-Hardware, so dass der Einstieg nicht so teuer ist.


Du solltest allerdings am Anfang mit einigen Schwierigkeiten rechnen.
Die Tutorials dort helfen Dir aber und hier im Forum kannst Du 
nachfragen, wenn Du Probleme hast die Software zu installieren oder das 
LISP bzw. Deine Programme auf den uC zu bekommen. (Vielleicht manchmal 
mit etwas Verzögerung, da eher weniger Leute LISP auf dem uC laufen 
lassen).

[Joachim S. (oyo)]

Theor schrieb:
> Ich würde Dir an sich nicht unbedingt LISP zum Einstieg empfehlen.
>
> Allerdings spricht in Deinem Fall dafür, dass Du LISP anziehend findest.
> Motivation ist zunächst das allerwichtigste Element in so einer
> Situation. Versuch das einfach. Es wird Dir in jedem Fall wertvolle
> Erfahrungen verschaffen.

Da kann ich nur voll zustimmen.

LISP (Scheme etc.) ist toll, eine Sprache, die imho eh viel mehr 
Beachtung verdient hätte. Gerade wenn Dir (@Dietmar) die 
LISP/Scheme-Syntax eh sympathisch ist, würde ich auf jeden Fall 
empfehlen, Dich mit dieser Sprache zu befassen.
Allerdings würde ich tendenziell das erst als zweite Sprache machen, und 
mich zuerst kurz mit Python beschäftigen. Denn gerade zum Einstieg hat 
Python ein paar Vorteile:

- Python ist unter'm Strich doch noch ein gutes Stück leichter zu lernen

- gerade unter Linux, was ja das Betriebssystem Deiner Wahl ist, sind 
Python-Kenntnisse mittlerweile äusserst hilfreich

- Es ist deutlich schwieriger, Leute mit LISP-Kenntnissen zu finden, die 
einem bei Problemen helfen können; Leute mit Python-Kenntnissen hingegen 
gibt's wie Sand am Meer

- Du hast geschrieben, dass Du grundsätzlich auch gerne Mikrocontroller 
programmieren würdest. Obwohl Mikrocontroller wegen der extrem 
begrenzten Ressourcen in den meisten Fällen in der Tat mit C/C++ 
programmiert werden, können leistungsfähige Mikrocontroller (mit viel 
RAM) auch in diversen höheren Programmiersprachen programmiert werden. 
Die Mikrocontroller von Esprissif - der ESP8266 und dessen noch viel 
leistungsfähigerer Nachfolger ESP32 - bspw. haben innerhalb kürzester 
Zeit eine unglaubliche Fan-Gemeinde gesammelt, weil sie zu einem extrem 
günstigen Preis so hervorragend ausgestattet sind (WLAN, viel RAM, ESP32 
auch Bluetooth), dass sie problemlos auch in vglw. hohen Sprachen wie 
LUA, Python etc. programmiert werden können. Und für diese 
ESP-Mikrocontroller ist die Programmierung in Python vglw. populär 
("MicroPython"); wenn Du Python kannst, kannst Du daher auch direkt 
diese extrem populären ESP-Mikrocontroller programmieren.  Mit LISP 
hingegen sieht es da deutlich schlechter aus; für den älteren ESP8266 
scheint es zwar eine Art LISP namens "esp-lisp" zu geben, aber die 
scheint weder besonders ausgereift/sinnvoll nutzbar noch verbreitet zu 
sein, wird offenbar nicht mehr weiterentwickelt und für den aktuellen 
Nachfolger ESP32 scheint es bislang noch gar kein LISP zu geben.

Lange Rede, kurzer Sinn: -> Hole Dir für ein paar Euro ein Development 
Board mit ESP32, und beschäftige Dich (auch) mit Python - dann kannst Du 
Deine neuen Programmierkenntnisse nicht nur am PC nutzen, sondern kannst 
Dich auch direkt mit der Programmierung von Mikrocontrollern befassen.
Ein passendes Development Board wäre z.B. das hier:
https://www.amazon.de/AZDelivery-NodeMCU-Development-Nachfolgermodell-ESP8266/dp/B071P98VTG/
wenn Du ein paar Wochen warten kannst, kriegst Du das gleiche Board bei 
Aliexpress incl. Versand auch für weniger als Hälfte.

[Sheeva P. (sheevaplug)]

Joachim S. schrieb:
> Da LISP/Scheme allerdings deutlich weniger verbreitet ist als andere
> Sprachen, und es daher als Einsteiger deutlich schwerer ist, da Hilfe zu
> bekommen, wäre meine persönliche Empfehlung unter'm Strich aber wohl
> trotzdem Python. Es hat schon gute Gründe, warum Python seit Jahren DIE
> Einsteiger-Programmiersprache schlechthin ist.

Es hat ja auch gute Gründe, warum Python seit vielen Jahren die 
beliebteste Allround-Skriptsprache ist. Dazu zählen sicher seine 
Einfachheit, Performanz, Robustheit, Stabilität, Erweiterbarkeit, 
Konsistenz, Kompaktheit, Lesbarkeit, Plattformunabhängigkeit, eine 
herausragende Infrastruktur von Bibliotheken, Werkzeugen und 
Dokumentation sowie wohl nicht zuletzt auch die Tatsache, daß es 
Bestandteil der Linux Standard Base ist.

[Stefan (Gast)]

Sheeva P. schrieb:
> Es hat ja auch gute Gründe, warum Python seit vielen Jahren die
> beliebteste Allround-Skriptsprache ist.

Die Frau Dr. Merkel unter den Programmiersprachen!

:-)

[michi42 (Gast)]

muuuha - Zeit für Relegionskriege.

Mimm Lisp,
functional rulez! (Java/c++/etc wersucht gerade da hin zu kommen wo Lisp 
vor 30 Jahren schon war - mit grausiger Syntax)

Gibt es sogar für den Arduino. Selbst wenn man hinterher doch wieder 
imperativ/oo macht, bildet es ungemein.
Python wäre meine nächste Alternative, da es Funtional/OO/Imperativ 
gleich gut unterstützt.

[Yalu X. (yalu) (Moderator)]

michi42 schrieb:
> Mimm Lisp,
> functional rulez!

Lisp ist eigentlich alles: nicht nur funktional, sondern auch
prozedural, objektorientiert (mit CLOS) und vieles mehr.

Und wenn es irgendein neumodisches Programmierparadigma geben sollte,
das von Lisp noch nicht unterstützt wird, programmiert man es einfach
mit hinzu. Nicht umsonst hat John Foderaro Lisp als "programmable
programming language" bezeichnet.

Deswegen ist es kein Fehler, sich Lisp einmal etwas näher anzuschauen.
Ob man die schier unbegrenzten Möglichkeiten, die die Sprache bietet,
dann auch gewinnbringend nutzen kann, muss jeder für sich selber
entscheiden und ist eher eine Frage des bevorzugten Programmierstils.
Ein Lisp-Programm wird ganz unterschiedlich aussehen, je nachdem, ob
sein Programmierer vorher hauptsächlich mit Basic, C++ oder Haskell
gearbeitet hat.

[Stefan (Gast)]

Nun ja, es hängt natürlich auch davon ab, ob man eher aus Spaß und 
Freude programmieren möchte, oder eher um mit möglichst wenig Aufwand 
eine konkrete Aufgabe zu lösen bzw. einen Job zu finden. Für den 
letzteren Fall ist man mit den neueren modernen bzw. "exotischen" 
Sprachen sicher nicht so gut beraten. (Wobei ich noch immer nicht recht 
verstanden habe, was der Threadstarter eigentlich genau vor hat, er 
weiss es wohl selber noch nicht so genau. PC-Programmierung und AVR-tiny 
Programmierung unterscheiden sich eben doch stark.)

[Ruediger A. (Firma: keine) (rac)]

Hallo Dietmar,

ich bin zwar in der Embedded Welt zu Hause und codiere fast 
ausschliesslich in C/C++, aber für Testutilities, Decoder und Anderes 
benutze ich (von gelegentlichen Ausflügen in C# abgesehen) sehr gerne 
Racket. Racket ist der Enkel von Lisp. Lisp ist heutzutage eigentlich 
ziemlich out, aber die nächste Generation Scheme (ein "Lisp ohne 
Fehler") ist sowas wie der Rolls Royce unter den Programmiersprachen. 
Die Weiterentwicklung von Scheme (Racket) ist eine 
Metaprogrammiersprache, d.h. Du kannst für jede Programmiersprache einen 
Übersetzungslayer in Racket schreiben oder schon finden (oder eben 
native Racket ~ Scheme codieren).

Wer sich erstmal auf Scheme eingelassen hat, kommt so schnell nicht mehr 
davon los. Es hat eine sehr eigene Ästhetik und Eleganz und kommt auf 
der untersten Ebene mit gerade einer Handvoll Sprachelementen aus, die 
aber so mächtig sind, dass man so gut wie Alles damit machen kann.

Für Embedded eignet sich Racket nicht, aber auf Linux/Windows macht es 
Riesenspass. Du findest den kostenlosen Download auf racket.org. Dort 
sind auch ein paar recht gute Tutorials zum anfixen.

[Alles Humbug (Gast)]

Yalu X. schrieb:
> Und wenn es irgendein neumodisches Programmierparadigma geben sollte,
> das von Lisp noch nicht unterstützt wird, programmiert man es einfach
> mit hinzu. Nicht umsonst hat John Foderaro Lisp als "programmable
> programming language" bezeichnet.

> Ein Lisp-Programm wird ganz unterschiedlich aussehen, je nachdem, ob
> sein Programmierer vorher hauptsächlich mit Basic, C++ oder Haskell
> gearbeitet hat.

Ist das wirklich die Situation? Das man sich von BASIC aus gerne 
weiterentwickeln möchte ist meines Erachtens verständlich, ergibt sich 
ja schon aus daraus, dass BASIC mal als einfache 
Einstiegs-Programmiersprache für jedermann angedacht war "Beginner’s 
All-purpose Symbolic Instruction Code". Aber warum sollte jemand der in 
C++ oder Haskell sich sicher fühlt ausgerechnet zu Lisp greifen? (und 
auf wievielen Hochzeiten kann man gleichzeitig tanzen wenn man KEIN Nerd 
ist??) Welchen Vorteil bietet das? Das erschließt sich mir nicht ganz.

Wie viele von uns sind eigentlich nach ihrer BASIC Anfangszeit (die bei 
einigen Jahrzehnte zurückliegt) anschließend bei Lisp gelandet und dort 
auch wirklich bis heute verblieben, anstatt zu C/C++, C#, Java, Pascal, 
Nim, Rust, go und wie sie alle heißen zu wechseln?

Wie viel Lisp ist in diesem Forum hier bisher aufgeschlagen im vergleich 
zu Bsp. C/C++, C#, Java, Pascal?

Warum brauchte es überhaupt erst neue Sprachen wie Nim, Rust, go, wenn 
doch mit Lisp eigentlich alles machbar ist? Und warum sind genau diese 
Sprachen dann auch noch erfolgreich?

Ruediger Asche (Firma: keine) (rac) schrieb:

> Lisp ist heutzutage eigentlich
> ziemlich out, aber die nächste Generation Scheme (ein "Lisp ohne
> Fehler") ist sowas wie der Rolls Royce unter den Programmiersprachen.
> Die Weiterentwicklung von Scheme (Racket)

Na schön, Lisp ist also "out" und Scheme (Racket) ist nun "in". Aha!

Kurz gegockelt und ..
http://docs.racket-lang.org/quick/index.html

.. über das hier gestolpert

An expression can also be a function call. To call a function, put an 
open parenthesis before the function name, then expressions for the 
function arguments, and then a close parenthesis, like this:

> (circle 10)

Kreis erscheint

Stellt sich einem doch irgendwie sofort die Frage, warum in Gottes Namen 
muss ein Funktionsaufruf SO aussehen?

Was ist falsch daran Funktionen so zu definieren, dass sie einem SOFORT 
ins Auge springen

circle()
circle(10)

Warum kommt ständig jemand auf die "Idee" das Rad nochmal neu erfinden 
zu müssen, nur diesmal so, dass die Felge nach innen gekrempelt wird und 
das ganze nicht mehr nach Rad aussieht?

Mode Hype?
Erschließt sich das nur einem Nerd?
Wer braucht so was?

PS: Nicht aufregen! Nur meine Meinung.

[michi42 (Gast)]

Weil z.B. die Trennung zwischen Daten und Code unnatürlich ist?

[Ruediger A. (Firma: keine) (rac)]

Alles Humbug schrieb:
> Ruediger Asche (Firma: keine) (rac) schrieb:
>
>> Lisp ist heutzutage eigentlich
>> ziemlich out, aber die nächste Generation Scheme (ein "Lisp ohne
>> Fehler") ist sowas wie der Rolls Royce unter den Programmiersprachen.
>> Die Weiterentwicklung von Scheme (Racket)
>
> Na schön, Lisp ist also "out" und Scheme (Racket) ist nun "in". Aha!
>

Weil Lisp einige inherente Probleme hat (z.B. dynamic scoping), die mit 
Scheme gefixt wurden.

>
> Stellt sich einem doch irgendwie sofort die Frage, warum in Gottes Namen
> muss ein Funktionsaufruf SO aussehen?
>
> Was ist falsch daran Funktionen so zu definieren, dass sie einem SOFORT
> ins Auge springen
>
> circle()
> circle(10)
>
> Warum kommt ständig jemand auf die "Idee" das Rad nochmal neu erfinden
> zu müssen, nur diesmal so, dass die Felge nach innen gekrempelt wird und
> das ganze nicht mehr nach Rad aussieht?
>

Hallo A.H.,

das liegt daran, dass in Scheme Funktionen First Class Objekte sind, 
d.h. Du kannst Funktionen als Parameter an Funktionen übergeben und als 
Rückgabewerte von Funktionen bekommen. Grob gesagt gibt es also zwischen 
Funktionen (genauer Lambda Expressions bzw. closures) und anderen 
Datentypen keinen Unterschied. In Scheme gibt es noch Andere 
faszinierende Dinge, die First Class Objekte sind (z.B. continuations, 
was aber hier zu weit führt). Also kann im Prinzip an jeder Stelle 
innerhalb der Klammern () jeder Objekttyp stehen. Wenn eine closure an 
erster Stelle so einen Ausdruckes steht, wird sie halt "als Funktion 
aufgerufen." Das hat hauptsächlich historische Gründe (war schon in Lisp 
so, obwohl der First Class status erst in Scheme festgeschrieben wurde).

In Racket kannst Du ohne Probleme jegliche syntaktische Abstraktion 
schreiben, durch die die Syntax

(circle 10)

durch

circle(10);

oder

invoke (circle,10):

oder

{call function circle with parameter 10}!

oder was auch immer ersetzt werden kann. Das ist aber nicht der Punkt.

Wie viele Andere Leute bist Du scheinbar prozedural sozialisiert, d.h. 
für Dich gibt es zunächst mal Funktionen und ihre Parameter, und das 
sind traditionell verschiedene Konzepte. Aus der Sicht heraus hast Du 
natürlich recht, dass es Geschmackssache ist, wie man den Aufruf 
syntaktisch formuliert. Aber wenn man erstmal das Konzept von Funktionen 
mit ihren aktuellen scopes als Objekte verstanden hat, eröffnet sich 
eine völlig neue Sichtweise der Dinge. Und Möglichkeiten, die Andere 
Programmiersprachen nicht bieten. Beispiel:

(define (genericop operator operand1 operand2)
        (operator operand1 operand2))

(define (addition op1 op2) (genericop + op1 op2))

(define (multiplication op1 op2) (genericop * op1 op2))

(define (genericop_with_constant operator operand1)
        (lambda (operand2) (operator operand1 operand2)))

; oder gleichwertig:
;(define (genericop_with_constant operator operand1)
;        (lambda (operand2) (genericop operator operand1 operand2)))



(define (add1 operand) ((genericop_with_constant + 1) operand))

(addition 2 3) => 5
(multiplication 2 3) => 6
(add1 4) => 5
(add1 ((genericop_with_constant * 2) 3)) => 7

Das sieht jetzt erstmal wie akademischer Spielkram aus, bietet aber in 
der Praxis eine Menge Anwendungen, die sich mit keiner anderen 
Programmiersprache so gut und modular lösen lassen.

Ob Du Dich darauf einlassen magst, ist deine Entscheidung.


> Mode Hype?
> Erschließt sich das nur einem Nerd?
> Wer braucht so was?
>

Wie gesagt: Ob Du Dich darauf einlassen magst, ist deine Entscheidung.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Inwieweit das "code is data" paradigma von Lisp in gefährlichen Zeiten 
wie diesen ein Risiko darstellt, wage ich nicht zu beurteilen. Aber ja, 
es ist unheimlich elegant ;-)

ich dachte schon, ich würde auf reines Unverständnis stoßen, als ich 
hier Beitrag "Re: Welche Programmiersprache lernen? (C, Phyton, Lisp, Swift, Smalltalk?)" 
schrieb:

Michael R. schrieb:
> ich halte Lisp nach wie vor für eine der klarsten und effizientesten
> Sprachen überhaupt

aber es freut mich dass ich mit meiner Meinung nicht alleine bin.

Was man auch noch erwähnen sollte: Lisp lässt sich ungeheuer effizient 
implementieren (kein Wunder, zur Zeit der Entstehung von Lisp konnte man 
Performance-Probleme noch nicht mit GHz bewerfen... was ich im Übrigen 
für eins der entscheidenden Probleme heutiger SW halte, ich sag nur C#)

Auch wenn der Mythos über CAR/CDR und die direkte Entsprechung in 
Assembler nicht ganz der Wahrheit entspricht.

anyway: my other car is a CDR ;-)

[Dr. Sommer (Gast)]

Michael R. schrieb:
> Lisp lässt sich ungeheuer effizient implementieren

Obwohl es GC, dynamische Typisierung und automatische 
Speicherverwaltung hat? Java z.B. hat zweiteres nicht, müsste also noch 
schneller sein?

[Michael R. (Firma: Brainit GmbH) (fisa)]

Dr. Sommer schrieb:
> Java z.B. hat zweiteres nicht, müsste also noch
> schneller sein?

Ja, müsste, könnte, ...

Die Herren Hätti und Wäri sind doch bekannterweise Millionäre, oder?

Wenn ich schon bisher nicht auf Unverständnis gestoßen bin, dann jetzt:

Java ist eine Krankheit, ein "pain in the ass", aber gottseidank ist es 
angezählt...

(ist zwar nur meine ganz persönliche Meinung, aber ich treffe auf immer 
mehr Firmen, wo Java für neu angeschaffte Software ein NoGo ist)

[Dr. Sommer (Gast)]

Michael R. schrieb:
> Java ist eine Krankheit, ein "pain in the ass", aber gottseidank ist es
> angezählt...
Witzig finde ich, dass bei dem ganzen Fluchen über Java immer nur auf 
die große/langsame JVM geschossen wird. Hätte LISP o.ä. eine derart 
umfassende Bibliothek, wäre das auch so groß. Es gibt ja auch winzige 
und anspruchslose Java-VM's. Die Dinge, die mich an Java stören, 
greift aber nie einer auf...

Michael R. schrieb:
> (ist zwar nur meine ganz persönliche Meinung, aber ich treffe auf immer
> mehr Firmen, wo Java für neu angeschaffte Software ein NoGo ist)
Na, die benutzen dann hoffentlich keine Google-Produkte o.ä., denn 
insbesondere im Web-Bereich ist das ja (serverseitig) auch sehr 
verbreitet.

Was ich u.a. an Java cool finde: Selbst gigantische Java-Projekte mit 
Millionen LoC sind superschnell übersetzt, und Code-Vervollständigung 
funktioniert auch da supi. C und C++ brauchen Größenordnungen länger. 
Klar, LISP und Konsorten muss man gar nicht übersetzen, aber man hat ja 
auch was davon: Eine ganze Reihe von Fehler-Prüfungen, insb. auf 
korrekte Typen.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Dr. Sommer schrieb:
> Witzig finde ich, dass bei dem ganzen Fluchen über Java immer nur auf
> die große/langsame JVM geschossen wird. Hätte LISP o.ä. eine derart
> umfassende Bibliothek, wäre das auch so groß.

Du setzt JVM und Bibliothek(en) gleich?

Ich schieße übrigens nicht (primär) auf die langsame VM...

Dr. Sommer schrieb:
> im Web-Bereich ist das ja (serverseitig) auch sehr
> verbreitet.

Ja, aber wie gesagt, angezählt.

Dr. Sommer schrieb:
> Eine ganze Reihe von Fehler-Prüfungen, insb. auf
> korrekte Typen.

Das ist wirklich eine offene Flanke. Ich behaupte, das Zeitalter der 
stark typisierten Sprachen ist vorbei. Aber ganz ohne gehts wohl auch 
nicht... an der Stelle ist noch viel zu tun.

[Dr. Sommer (Gast)]

Michael R. schrieb:
> Du setzt JVM und Bibliothek(en) gleich?
Mir viel gerade der Begriff nicht ein; ich meinte die JavaSE welche man 
normalerweise auf dem Desktop installiert und die die HotSpot JVM und 
die Bibliotheken enthält.

Michael R. schrieb:
> Ja, aber wie gesagt, angezählt.
Könnte sein dass es durch PHP verdrängt wird, aber ob das besser ist?

Michael R. schrieb:
> Ich behaupte, das Zeitalter der stark typisierten Sprachen ist vorbei

Totgesagte leben länger. Statisch typisierte Sprachen sind sehr 
vorteilhaft für große Projekte. Da gibt es m.W. kein besseres 
praktikables Konzept, höchstens hybride Varianten.

[Michael R. (Firma: Brainit GmbH) (fisa)]

Dr. Sommer schrieb:
> Könnte sein dass es durch PHP verdrängt wird, aber ob das besser ist?

PHP eher nicht, denke ich... eher Node.js & Co, aber da bin ich 
zugegebenermaßen auf dünnem Eis.

Dr. Sommer schrieb:
> Statisch typisierte Sprachen sind sehr
> vorteilhaft für große Projekte. Da gibt es m.W. kein besseres
> praktikables Konzept, höchstens hybride Varianten.

Ja, das ist sicher keine Schwarz/Weiss Entscheidung.

Aber wenn man sich anschaut (und ich sehe das täglich, stündlich) was 
uns stark typisierte Sprachen eingebrockt haben (man nehme ein fast 
beliebiges XML, insbesondere aus dem MS-Ökosystem) dann wird schon klar, 
dass es das nicht sein kann...

Nimm einen x-beliebigen (aber geistig flexiblen) 
C++/Java/C#-Programmierer, und erklär im Hashes, Hash-Strukturen, und 
dynamische Objektstrukturen in einer (fast) beliebigen schwach 
typisierten Sprache, und wer wird in Tränen ausbrechen.

[Ruediger A. (Firma: keine) (rac)]

Dr. Sommer schrieb:
> Michael R. schrieb:
>> Lisp lässt sich ungeheuer effizient implementieren
>
> Obwohl es GC, dynamische Typisierung und automatische
> Speicherverwaltung hat? Java z.B. hat zweiteres nicht, müsste also noch
> schneller sein?

Da bin ich (leider) ganz bei Dir. Die Lisp Welt ist für Embedded aus 
mehreren Gründen untauglich. Es gibt (Insel-) Versuche, es zu 
realisieren, und ich habe mich auch mal dran gemacht, aber aufgegeben. 
Das Modell von Lisp/Scheme/Racket lässt sich einfach nicht gut auf 
Embedded aufsetzen, u.A. aus folgenden Gründen:

1. L/R/S bietet keinerlei Kontrolle über Speicher, d.h. es lässt sich 
nicht einfach ein Interface realisieren, um z.B. auf memory mapped 
registers gezielt zuzugreifen. Grundsätzlich sind Treiber für Hardware 
und Peripherie fast unmöglich darin zu realisieren. GC ist notwendig für 
jede L/R/S Implementation und damit für Echtzeitanwendungen so ziemlich 
out.

2. L/S/R sind interpretierte Sprachen, wobei viele Interpreter 
metazirzulär ist, d.h. mit Funktionen wie eval und apply lassen sich 
Ausdrücke zur Laufzeit interpretieren. Wer diese Konstrukte benutzt 
(Sinn und Unsinn davon werden in der Community so lange diskutiert wie 
es die Sprachen gibt), benötigt einen residenten Interpreter, der das 
footprint recht stark aufbläht.

3. Die meisten modernen L/S/R Systeme compilieren Quellcode in Bytecode 
(ähnlich zu Javas P-Code), so dass ein Bytecodeinterpreter ebenfalls 
resident sein muss.

4. Es lässt sich ein Multitasking Betriebssystem komplett in Scheme 
schreiben (da gibt es ein Konstrukt namens engine, das vollständig 
zeitscheibengesteuerte preemption von Berechnungen realisieren kann). Da 
das aber eben wieder auf Scheme aufsetzt, muss untendrunter eben 
mindesetns der GC und der Bytecodeinterpreter sitzen.

Schade, ist aber so. Als Alternative zu Java auf PCs taugt Scheme aber 
allemal (ein Webserver ist in 2 Zeilen geschrieben).

[Dr. Sommer (Gast)]

Michael R. schrieb:
> Nimm einen x-beliebigen (aber geistig flexiblen)
> C++/Java/C#-Programmierer, und erklär im Hashes, Hash-Strukturen, und
> dynamische Objektstrukturen in einer (fast) beliebigen schwach
> typisierten Sprache, und wer wird in Tränen ausbrechen.
Hah! Das akribische Annotieren von Typen ist zwar nervig und für 
Anfänger schwer, sodass dynamisch typisierte oder gar untypisierte 
Sprachen zwar wie eine Erlösung erscheinen, aber auf verschlungenen 
Pfaden zur Laufzeit auftretende Typfehler können auch ganz schön lästig 
sein.
Wenn man das Typsystem verstanden hat (und über den Zustand des Haderns 
über char* vs. char[42] hinaus ist), freut man sich über jeden 
Typ-Fehler den der Compiler anzeigt - ein Fehler weniger, der einen 
irgendwann später in den Hintern beißt! Ich benutze jedenfalls sowohl 
dynamisch als auch statisch typisierte Sprachen und bevorzuge für große 
Projekte definitiv letztere.

Kleines Beispiel: Der Log meines OwnCloud-Servers ist voll von Fehlern, 
dass irgendein Objekt eine Funktion nicht hat. Das wäre mit Java nicht 
passiert... (aber ok, OwnCloud ist generell ziemlich buggy)

Ruediger A. schrieb:
> Schade, ist aber so. Als Alternative zu Java auf PCs taugt Scheme aber
> allemal (ein Webserver ist in 2 Zeilen geschrieben).
Du meinst, die Bibliothek für den Webserver ist in 2 Zeilen eingebunden. 
Wenn du eine HTTP-Bibliothek für Java nimmst, ist die auch in 2 Zeilen 
gestartet. Ich meine Glassfish hat sowas.

[Dietmar (Gast)]

In den letzten zwei Tagen habe ich echt viel neues gelernt, besonders 
über die Unterschiede der einzelnen Programmiersprachen. Jetzt bin ich 
erst recht begeistert und bereit mich da noch mal richtig reinzuknien.

Zunächst war ich durch die Vielfalt noch mehr verwirrt, doch nun 
tendiere stark zu Common Lisp. Aber ich frage mich gerade, ob es nicht 
besser wäre, zunächst mit Scheme zu beginnen. Da finde ich jedenfalls 
viel mehr Information und auch die verständlicheren Tutorials.

Zu Common Lisp habe ich, was mir anfängertauglich erscheint, eigentlich 
nur dieses gefunden: https://www.cse.buffalo.edu//~shapiro/Commonlisp/

Zu Scheme gibts einfach mehr und dazu habe ich ja auch hier schon gute 
Tipps bekommen.

Stefan schrieb:
> Nun ja, es hängt natürlich auch davon ab, ob man eher aus Spaß und
> Freude programmieren möchte, oder eher um mit möglichst wenig Aufwand
> eine konkrete Aufgabe zu lösen bzw. einen Job zu finden.

Wie gesagt, einen Job finde ich damit nicht mehr, das anzunehmen wäre 
utopisch. (Belehrt mich, wenn ich mich irre). Also bleibt nur das 
Interesse und ich denke ich habe einiges an Bildung in diesem Bereich 
nachzuholen. Ich finde das ist doch ein gute Sache und verstehe nicht 
warum es dann Zeitgenossen gibt, die mit einem so blöden Kommentar 
daherkommen: 
Beitrag "Re: Welche Programmiersprache lernen? (C, Phyton, Lisp, Swift, Smalltalk?)"


> (Wobei ich noch immer nicht recht
> verstanden habe, was der Threadstarter eigentlich genau vor hat, er
> weiss es wohl selber noch nicht so genau. PC-Programmierung und AVR-tiny
> Programmierung unterscheiden sich eben doch stark.)

Als ich meinen Eingangspost erstelle, wusste ich das tatsächlich nicht 
so genau. Im Grunde schon beides. Nur werde ich das wohl nicht unter 
einen Hut bringen. Wichtiger ist mir jetzt aber die Programmiersprache 
zu erlernen, Mikroconroller lasse ich erst mal Nebensache sein. Und wenn 
ich irgendwann fitter bin, wurden mir ja schon interessante 
Möglichkeiten wie Ferret und uLisp genannt, die für meine Zwecke völlig 
ausreichen sollten.

Für meine Basteleien hätte ich halt schon öfter mal einen 
Mikrocontroller brauchen können, statt ein CMOS-Grab zu erschaffen. 
Kürzlich habe ich eine Auswertungsschaltung für einen Drehgeber 
aufgebaut. O.k. sie funktioniert und bei einem Hobbyprojekt ist das 
sicher nicht weiter tragisch, aber im Prinzip trotzdem irre 7 Logic-IC 
dafür reinzuknallen. Natürlich hätte ich einfach einen Beispielcode aus 
dem Netz kopieren können, aber am Ende wäre der Aufwand doch wiederum 
größer gewesen, als die 7 Logikbausteine zusätzlich auf die Eurokarte zu 
löten.

Ruediger A. schrieb:

> Wer sich erstmal auf Scheme eingelassen hat, kommt so schnell nicht mehr
> davon los. Es hat eine sehr eigene Ästhetik und Eleganz und kommt auf
> der untersten Ebene mit gerade einer Handvoll Sprachelementen aus, die
> aber so mächtig sind, dass man so gut wie Alles damit machen kann.
>
> Für Embedded eignet sich Racket nicht, aber auf Linux/Windows macht es
> Riesenspass. Du findest den kostenlosen Download auf racket.org. Dort
> sind auch ein paar recht gute Tutorials zum anfixen.

Macht mir echt Mut und Lust zu mehr und beantwortet im Prinzip meine 
Frage am Anfang dieses Beitrags.

[Arc N. (arc)]

Alles Humbug schrieb:
> Was ist falsch daran Funktionen so zu definieren, dass sie einem SOFORT
> ins Auge springen
>
> circle()
> circle(10)
>
> Warum kommt ständig jemand auf die "Idee" das Rad nochmal neu erfinden
> zu müssen, nur diesmal so, dass die Felge nach innen gekrempelt wird und
> das ganze nicht mehr nach Rad aussieht?

Wieso neu erfinden? LISP wurde 1958 spezifiziert, Scheme 1975. Das ganze 
ist eine normale S-Expression und sieht nicht von ungefähr ähnlich aus 
wie Lambda-Kalkül https://en.wikipedia.org/wiki/Lambda_calculus

Dr. Sommer schrieb:
> Michael R. schrieb:
>> Nimm einen x-beliebigen (aber geistig flexiblen)
>> C++/Java/C#-Programmierer, und erklär im Hashes, Hash-Strukturen, und
>> dynamische Objektstrukturen in einer (fast) beliebigen schwach
>> typisierten Sprache, und wer wird in Tränen ausbrechen.
> Hah! Das akribische Annotieren von Typen ist zwar nervig und für
> Anfänger schwer,

Das nehmen einem die besseren, statisch typisierten, Sprachen wieder ab 
und machen das ständige Annotieren überflüssig (Typinferenz, ML, OCaml, 
F#, Haskell etc.)

> sodass dynamisch typisierte oder gar untypisierte
> Sprachen zwar wie eine Erlösung erscheinen,

Es gibt keine dynamisch typisierten oder untypisierten Sprachen ;)
Die kennen schlicht nur einen einzigen Typ und verlagern Arbeit, die die 
Maschine machen sollte, wieder zurück auf den Menschen (und in die 
Laufzeit des Programms)

Dietmar schrieb:
> Wie gesagt, einen Job finde ich damit nicht mehr, das anzunehmen wäre
> utopisch. (Belehrt mich, wenn ich mich irre).

Von Paul Graham gibt's dazu ein schönes Zitat: "The more of an IT flavor 
the job descriptions had, the less dangerous was the company. The safest 
kind were the ones that wanted Oracle experience. You never had to worry 
about those. You were also safe if they said they wanted C++ or Java 
developers. If they wanted Perl or Python programmers, that would be a 
bit frightening. If I had ever seen a job posting looking for Lisp 
hackers, I would have been really worried."

[Dr. Sommer (Gast)]

Arc N. schrieb:
> Das nehmen einem die besseren, statisch typisierten, Sprachen wieder ab
> und machen das ständige Annotieren überflüssig (Typinferenz, ML, OCaml,
> F#, Haskell etc.)
Typinferenz hat C++ auch. An Schnittstellen (z.B. Funktionsparameter) 
will man die explizite Annotation aber explizit haben.

Arc N. schrieb:
> Es gibt keine dynamisch typisierten oder untypisierten Sprachen ;)

https://de.wikipedia.org/wiki/Dynamische_Typisierung
"Vor allem Skriptsprachen wie JavaScript, Python und Ruby verwenden die 
dynamische Typisierung."
"Untypisiert" war der falsche Begriff, ich meinte "schwach typisiert". 
Ein Beispiel ist PHP: https://de.wikipedia.org/wiki/PHP

Arc N. schrieb:
> If I had ever seen a job posting looking for Lisp
> hackers, I would have been really worried."
Weil das kaum einer kann, droht da eh keine Gefahr.

[Sheeva P. (sheevaplug)]

Stefan schrieb:
> Sheeva P. schrieb:
>> Es hat ja auch gute Gründe, warum Python seit vielen Jahren die
>> beliebteste Allround-Skriptsprache ist.
>
> Die Frau Dr. Merkel unter den Programmiersprachen!
>
> :-)

Na, wir wollen mal nicht übertreiben. Keine Programmiersprache hat so 
viel Lob verdient, noch nicht einmal Python.

[Sheeva P. (sheevaplug)]

Ruediger A. schrieb:
> Alles Humbug schrieb:
>> Warum kommt ständig jemand auf die "Idee" das Rad nochmal neu erfinden
>> zu müssen, nur diesmal so, dass die Felge nach innen gekrempelt wird und
>> das ganze nicht mehr nach Rad aussieht?

Ach, Humbug, Lisp stammt von 1958, Scheme von 1975, C von 1972. Wer hat 
da wohl "das Rad neu erfunden"? ;-)

> das liegt daran, dass in Scheme Funktionen First Class Objekte sind,
> d.h. Du kannst Funktionen als Parameter an Funktionen übergeben und als
> Rückgabewerte von Funktionen bekommen.

Das geht in Python natürlich auch, und ist zum Beispiel die Basis zum 
Beispiel von Dekoratoren. Dabei wird dann eine Funktion oder Klasse in 
einer anderen Funktion deklariert und die innere Funktion oder Klasse 
zurückgegeben.

Ein einfaches Beispiel ohne Dekoration:

def createMainForm():
    class MainForm(FlaskForm):
        @classmethod
        def append_field(cls, name, field):
            setattr(cls, name, field)
            return cls
    for field in INPUT_FIELDS:
        f = field[FIELDTYPE](field[LABEL], **field[FIELDPARAMS])
        MainForm.append_field(field[NAME], f)
    return MainForm

# Usage:
form = createMainForm()()

> In Scheme gibt es noch Andere
> faszinierende Dinge, die First Class Objekte sind (z.B. continuations,
> was aber hier zu weit führt).

Das entspräche in Python wohl einem Generator oder einem Iterator. Eine 
Generator-Funktion mit dem Schlüsselwort 'yield':

def func(jump, end):
    start = 1.1
    while start < end:
        yield start**2
        start += jump

# Usage:
f = func(0.3, 5)
for result in f:
  print result

oder objektorientiert mit weiteren Möglichkeiten als Iterator:

class kls(object):
    def __iter__(self): return self

    def __init__(self, start, jump, end):
        self.start = start
        self.jump = jump
        self.end = end    
    
    def next(self):
        if self.start > self.end:
            raise StopIteration
        self.start += self.jump
        return self.start**2

# Usage:
k = kls(1.1, 0.3, 3)
for r in k:
    print r

Natürlich sind Klassen, Instanzen und Funktionen First-Class-Objekte, 
die anderen Klassen und Funktionen übergeben oder als Rückgabewert von 
diesen übernommen werden können.

> wenn man erstmal das Konzept von Funktionen
> mit ihren aktuellen scopes als Objekte verstanden hat, eröffnet sich
> eine völlig neue Sichtweise der Dinge. Und Möglichkeiten, die Andere
> Programmiersprachen nicht bieten.

Daß man in Scheme allerdings auch Operatoren als First-Class-Objekte 
übergeben kann, finde ich wirklich nett, aber den Rest können andere 
Sprachen wie Python oder modernes C++ natürlich auch. Auch als recht 
erfahrener Emacs-Lisp-Nutzer frage ich mich da nach dem Benefit.

> Das sieht jetzt erstmal wie akademischer Spielkram aus, bietet aber in
> der Praxis eine Menge Anwendungen, die sich mit keiner anderen
> Programmiersprache so gut und modular lösen lassen.

Magst Du das in einem separaten Thread besprechen?

[Dr. Sommer (Gast)]

Kleine Anekdote: Ein Prof hat den Lambda-Kalkül in der Vorlesung auf 
Basis von Python und dessen Lambda-Funktionalität erläutert, statt eine 
"klassische" funktionale Sprache zu nehmen... ;-)

[Ruediger A. (Firma: keine) (rac)]

Sheeva P. schrieb:
> Ruediger A. schrieb:
>> Das sieht jetzt erstmal wie akademischer Spielkram aus, bietet aber in
>> der Praxis eine Menge Anwendungen, die sich mit keiner anderen
>> Programmiersprache so gut und modular lösen lassen.
>
> Magst Du das in einem separaten Thread besprechen?

Ok, zugegeben: "Keine Andere Programmiersprache" ist etwas weit aus dem 
Fenster gelehnt. Bitte um Vergebung und würde die Aussage relativieren, 
wenn das Forum es zulassen täte. Da muss ich mich mal in Python genauer 
einlesen, um Jemandem von deinem Kenntnisstand etwas bieten zu können...

[Sheeva P. (sheevaplug)]

Michael R. schrieb:
> Java ist eine Krankheit, ein "pain in the ass", aber gottseidank ist es
> angezählt...

Ich fand Java schon Scheiße, als ich noch bei Sun Microsystems 
angestellt war, sehr zum Mißfallen meiner Vorgesetzten. James Gosling 
kenne ich sogar persönlich, das ist ein extrem kluger und sympathischer 
Typ, auch wenn wir unterschiedliche Ansichten über Java haben.

Aber das ändert heute leider nichts daran, daß Java heute die mit 
Abstand verbreitetste Programmiersprache ist. 70% bis 80% der 
Enterprise-Software, die ich kenne, ist in Java implementiert. Das geht 
schon mit den "alten" Systemgeschichten wie Legato NetWorker (heute EMC, 
IIRC) und der Solstice Disksuite los, über Web Application Server wie 
Websphere von IBM, bis zu wirklich aktuellem Zeug: im Distributed 
Computing kommst Du heute nicht um Java herum, egal, ob Du Batch 
Processing mit Apache Hadoop, Realtime Stream Processing mit Apache 
Storm, -Spark oder -Gearpump machst, Machine Learning mit Tensorflow 
nutzen oder Graphendatenbanken mit Neo4j, Oracle Spatial, SAP Hana oder 
OrientDB nutzen willst: der Große Integrator(c) ist leider Java. Und 
wenn Du irgendwas Spannendes mit einer Oracle-Datenbank machen willst, 
dann rate, womit das am Besten geht.

Versteh' mich bitte nicht flashc: mich kotzt das auch an, aber Java ist 
tatsächlich immer noch die verbreitetste Programmiersprache. Sogar wenn 
Du Java auch nur halb so Scheiße findest wie ich -- was ziemlich schwer 
sein dürfte -- ist es leider da und wird leider vermutlich bis zumindest 
meinem Lebensende da bleiben. Tut mir auch leid, ist aber so. Sorry.

[Sheeva P. (sheevaplug)]

Ruediger A. schrieb:
> Ok, zugegeben: "Keine Andere Programmiersprache" ist etwas weit aus dem
> Fenster gelehnt. Bitte um Vergebung und würde die Aussage relativieren,
> wenn das Forum es zulassen täte. Da muss ich mich mal in Python genauer
> einlesen, um Jemandem von deinem Kenntnisstand etwas bieten zu können...

Herzlichen Dank für die Blümchen -- aber es gibt keinen Anlaß dafür, 
Dich kleiner zu machen, als Du bist. Offenbar kennst Du Dich mit 
funktionaler Programmierung viel besser aus als ich. ;-)

Aber wenn ich in meiner Karriere eins gelernt habe, dann sind es drei 
Dinge: erstens, es gibt immer einen, der besser ist als Du; zweitens, es 
gibt immer etwas Neues zu Lernen; drittens: neue Denkweisen sind dabei 
das Beste!

[Alles Humbug (Gast)]

Sheeva P. schrieb:
>> Alles Humbug schrieb:
>>> Warum kommt ständig jemand auf die "Idee" das Rad nochmal neu erfinden
>>> zu müssen, nur diesmal so, dass die Felge nach innen gekrempelt wird und
>>> das ganze nicht mehr nach Rad aussieht?
>
> Ach, Humbug, Lisp stammt von 1958, Scheme von 1975, C von 1972. Wer hat
> da wohl "das Rad neu erfunden"? ;-)

Ach Sheeva, ihr Fanboys von kruden Dialekten seid alle sooo helle, könnt 
aber keine zwei Zeilen mal im Kontext aufnehmen, ohne immer alles 
wortwörtlich auszulegen. Lies mal nach was ich weiter oben bereits zu 
Lisp schrieb:

Der TE schrieb:
>> So bin ich nun auf Lisp gestoßen, genauer gesagt Common Lisp. Sehe ich
>> mir den Beispielcode an, erscheinen mir auch ohne Vorwissen bereits
>> Teile davon logisch und leserlich und ich habe das Gefühl, das mir das
>> Spaß machen könnte.

ich schrieb dazu:
Seit geraumer Zeit kaum mehr verbreitet. Nach meinem Gefühl ist Lisp
eher was Historisches aus der Ära der Computer-Anfangszeit.

Ich bin kein "Lisp Fachmann", noch nicht mal ein Novize. Ich leiste mir 
nur den Luxus bei Programmiersprachen (nicht nur dort) ein persönliches 
spontanes Gefühl beim ersten Blick darauf zuzulassen, wie solche 
Dialekte in einem ersten Eindruck auf mich wirken und da fiel zufällig 
sofort der Blick auf diesen Beispiel der Funktionen-Definition. Da stört 
mich einfach der Anblick schon. Nur mal als kleiner Vergleich. Als ich 
vor einiger Zeit mal auf Julia stieß, war mein Eindruck genau anders 
herum. Gefällt mir. Auch die umgekehrt Polnische Notation meines alten 
HP 48x mochte ich immer, mag ich noch heute, weil sie mir logisch 
erscheint. Bei C fühle ich mich wohl. C# finde ich prächtig ausgebaut 
und komfortabel. Der Sprung von C# zu Java ist kurz. C++ finde ich 
insgesamt sehr mächtig aber auch anspruchsvoll und bisweilen schwierig. 
F# scheint interessant (leichter Zugang durch MS - ich bin kein Linuxer 
(mehr)). Mit Pascal hab ich mal begonnen (tolle Zeit gewesen; nach 
BASIC). Go-lang hab ich mir schon mal reingezogen, bin aber nicht so 
richtig mit warm geworden (alles noch offen). Nimrod (Nim) mal ein paar 
Blicke riskiert und ein paar weitere Sprächlein noch. Ich bin IMMER 
neuem gegenüber aufgeschlossen. Aber .. ich laufe nicht jedem Hype blind 
hinterher bzw. nehme aufmerksam wahr, was gepflegt wird und was vor sich 
hin gammelt. Wenn mir so eine hipp polierte Webseite (die sehen ja 
inzwischen fast alle gleich aus) nach kurzem stöbern nicht wenigstens 
auch MASSIG Beispielcode bietet und zwar OHNE dass ich mir erst die 
Finger danach wund suchen muss, dann verliere ich die Lust daran und 
gehe davon aus, dass auch die Macher keine Lust hatten ihr Pamphlet für 
andere mit Leben zu füllen. Das heißt nicht zwangsläufig, dass ich dann 
nie mehr dort hineinschaue.

Mir war nicht geläufig, dass es Lisp-Weiterentwicklungen gibt. Mir ist 
Lisp ehrlich gesagt auch bei vielen Recherchen zum Thema 
Programmiersprachen kaum bis gar nicht über den Weg gelaufen, was für 
mich den Schluss nahe legt, es hat wenig bis keine Bedeutung allenfalls 
für kleine Fangrüppchen, die das "Spezielle" lieben, meist auch aus 
einem speziellen Hintergrund heraus. So stellt sich mir die Situation 
auch hier dar. Ein 50-jähriger OHNE (nach eigenen Angaben) großartige 
Programmiererfahrungen, der nach Hilfe in einem Forum zu dieser Frage 
aufschlägt, dem würde ich NIE Lisp, Brainfuck, Haskell oder ähnliches 
anempfehlen. Zu exotisch, zu speziell, zu wenig Foren, zu wenig Leute 
die man um Hilfe bitten könnte. Warum sich das Leben schwer machen, wenn 
es auch leichter geht. Über den TIOB man man schimpfen

https://www.tiobe.com/tiobe-index/

aber das Krude Argument, Recherche hätte keine Aussagekraft über 
Interessen halte ich für abwegig und wenn man sich die dort aufgeführten 
Programmiersprachen anschaut kommt das nach meinem Gefühlt schon recht 
gut hin. Lisp rangiert dort auf Platz 36 (immerhin noch vor Julia ;)).

Hier allerdings hat der TE anscheinend bereits eigene Erfahrungen mit 
Lisp gemacht, so dass sich die Sachlage mir anders darstellt. Wenn er 
damit glücklich wird, ich bin der Letzte der da etwas gegen hätte. Für 
mich kommt Lisp allerdings nicht in Frage. Es bereitet mir keine 
Anfangslust mich damit näher zu beschäftigen.

[Alles Humbug (Gast)]

Ruediger Asche (Firma: keine) (rac) schrieb:

> Aber wenn man erstmal das Konzept von Funktionen
> mit ihren aktuellen scopes als Objekte verstanden hat, eröffnet sich
> eine völlig neue Sichtweise der Dinge. Und Möglichkeiten, die Andere
> Programmiersprachen nicht bieten.

Rüdiger, erst mal Danke für deinen Einlass weiter oben. Klar, wenn man 
sich näher mit der Syntax beschäftigt fängt man auch an darin zu denken. 
Deinen Absatz, den ich gerade nochmal zitiert habe, halte ich für 
fragwürdig. Solche Sätze fallen in JEDER Programmiersprache, die im 
entstehen oder gerade in einer starken Weiterentwicklung sich befinden 
und suggerieren dem Leser immer, man bekäme nun etwas was es vorher so 
nicht gegeben hat. (meist hat man's vorher auch nicht gebraucht)

Es gibt nun seit mehr als einem halben Jahrhundert Software-Entwicklung 
und so ziemlich alles erdenkliche ist bereits schon in allen möglichen 
Programmiersprachen zusammengecoded worden (nicht abfällig gemeint). Ich 
glaube nicht, dass noch irgend etwas wirklich ELEMENTAR neues 
herauskommt, was den "Nobelpreis" zu erwarten hätte (vielleicht mit 
Ausnahme der KI, wer weiß?!).

In Wahrheit verführen bestimmte Paradigmen vor allem die (meist 
jüngeren) "Nerds" dazu ihre Programmier-Probleme den Werkzeugen 
anzupassen (man denkt halt dann in Haskell oder Lisp oder wie beim alten 
C noch stark in Pointern mit all den Macken) und je nach Problem ist das 
mal bei der einen Sprache bequemer, effizienter und dann mal wieder bei 
der anderen. Zudem wird das Thema Programmiersprachen immer wieder von 
aufkommenden Hypes beschwingt. Mal war es der Haskell-Hype, dann kam go 
dran. Ich kann mich noch erinnern, als sogar das öffentlich-rechtliche 
Fernsehen junge bärtige Männer von der wörtlich "sagenhaften neuen 
Sprache namens JAVA" schwärmen ließ, mit der sich alle Probleme lösen 
ließen. Mit der Zeit verliert sich der Hype, Ernüchterung tritt an deren 
stelle dann kommt ein neuer Hype, der alle Vorteile in sich vereint 
sehen möchte (und die Nachteile klein reden oder gleich ganz unter den 
Tisch fallen lässt). Was auf den ersten Blick bloß interessant - weil 
neu - erscheint und was man wirklich braucht (und auch längerfristig 
verwendet, weil's im Gedächtnis bleibt) sind erfahrungsgemäß zwei paar 
Schuhe.

Achja Stichwort "Hype", Bitcoins sind gerade am abstürzen.

Gute Nacht!

[Dr. Sommer (Gast)]

Alles Humbug schrieb:
> Mit der Zeit verliert sich der Hype, Ernüchterung tritt an deren
> stelle dann kommt ein neuer Hype
Und mit der Zeit bleiben die Sprachen übrig, die am meisten praktikabel, 
realitätsnah und erlernbar sind, trotz aller Macken und Kanten. Beim 
TIOBE-Index sind das dann die, die lange oben bleiben. Kurioserweise 
gehört Java dazu...

[Bernd K. (prof7bit)]

Stefan schrieb:
> bzw. einen Job zu finden. Für den
> letzteren Fall ist man mit den neueren modernen bzw. "exotischen"
> Sprachen sicher nicht so gut beraten.

Also bei mir hätte jemand der (auch) Lisp oder Haskell im Repertoire hat 
ein paar gewaltige Pluspunkte, auch wenn es bei uns nie zum Einsatz 
käme, es zeigt daß der Kandidat nicht nur das 08/15 Pflichtprogramm 
beherrscht sondern auch einen unstillbaren Drang hat seinen Horizont zu 
erweitern.

[Bernd K. (prof7bit)]

Ruediger A. schrieb:
> Schade, ist aber so. Als Alternative zu Java auf PCs taugt Scheme aber
> allemal (ein Webserver ist in 2 Zeilen geschrieben).

Du meinst ein Webserver aus einer Bibliothek (den jemand anders 
geschrieben hat) ist in zwei Zeilen instantiiert und gestartet. Das geht 
in jeder Sprache, sogar in C, sogar in Assembler. Das ist also nicht 
unbedingt eine Eigenschaft der Sprache. Interessanter wäre es sich 
anzuschauen wie der Webserver aussähe müsste man ihn in der jeweiligen 
Sprache komplett selber schreiben.

[Yalu X. (yalu) (Moderator)]

Bernd K. schrieb:
> Stefan schrieb:
>> bzw. einen Job zu finden. Für den
>> letzteren Fall ist man mit den neueren modernen bzw. "exotischen"
>> Sprachen sicher nicht so gut beraten.
>
> Also bei mir hätte jemand der (auch) Lisp oder Haskell im Repertoire hat
> ein paar gewaltige Pluspunkte, auch wenn es bei uns nie zum Einsatz
> käme, es zeigt daß der Kandidat nicht nur das 08/15 Pflichtprogramm
> beherrscht sondern auch einen unstillbaren Drang hat seinen Horizont zu
> erweitern.

Heißt du mit richtigem Namen vielleicht Paul Graham? ;-)

Der hat nämlich schon 2004 einen schönen Artikel zu diesem Thema
gechrieben:

  http://www.paulgraham.com/pypar.html

Da Python inzwischen stark an Popularität hinzugewonnen hat, müsste man
das "Python Paradox" in "$NMPL Paradox" umbenennen", wobei $NMPL für
irgendeine "Non-Mainstream-Programming-Language", also bspw. die von dir
genannten Lisp oder Haskell, steht.

[Programmiersprachentheaterintendant (Gast)]

Obschon der TE es von BEGIN (oder "{" für jene die mit mehr als 4 
aneinandergereihten Grossbuchstaben überfordert sind) an so geäussert 
hat, sind wir noch vor dem 100sten Beitrag mehr oder minder zum Konsens 
angelangt dass es AUCH um Horizonterweiterung geht, dass mehr als genug 
Auswahl da ist und dass es bei Allen noch Neuland in Aspekte rund um 
Programmierdenkweisen gibt.

Es sind gute Beiträge dabei, mich dünkt es v.a. die längeren.

Der Vollständigkeit halber will ich noch folgende Programmiersprachen 
auflisten, welche durchaus auch für eine sehr breite Spanne an 
"Sytemgrösse" taugen (von 8- bis 64- Bit Systeme, aka Embedded bis 
Distributed MP, RT bis Batch)
- FORTH (auch auf sehr kleinen uC interaktiv on-target, schnell)
- Lua (s.a. eLua f. Embedded, kompakt, modular, "OO", auch auf uC 
interaktiv on-target)
- Modula-2 (kompakt, modular, skaliert gut f. Grossprojekte, NOCH OHNE 
OO)
- Oberon (wie M2, MIT OO, nicht verbreitet...)
- Ada (OO &Typstrikt, Besenstiel im Axxch wird mitgeliefert)

(ich bestehe weder auf demontierende Besprechung noch auf Jubelpersertum 
dazu. Es sei die Anmerkung erlaubt dass diese meist jüngere Kreationen 
sind als alles bisher im Thread besprochene mit ausnahme v. Java)

Zur Wahl der Programmiersprache scheint es also 2 Arten v. "Hauptwege" 
zu geben, die mindestens Orthogonal zueinander stehen:
- "Herdentrieb": an TIOBE o.Ä. ausgerichtet, "Schafe folgen Schafe und 
sehen nur Schafhinterteile", eigener Geschmack (Syntax) muss 
weggeschlossen werden, "Wer Zahlt befiehlt" & "das haben wir schon immer 
so gemacht, es kann nix besseres geben"
- "Pioniertum": exotisch, wild, speziell, selten, Freiheit, no Limits, 
das muss doch besser/eleganter/kompakter/weniger umständlich zu machen, 
"geht nicht gibt's nicht", "think outside of the box"

Am Ende des Tages sind beide Wege möglich, haben unterschiedliche 
Kompromisse eingehe müssen und unterschiedliche Tribute bezahlt - aber 
beide das Ziel erreicht (passendes Können vorausgesetzt).

Nur etwas scheint mir Pflicht zu sein: man sollte beide Wege 
beschritten haben und 1, besser 2+, Representanten aus beiden Bereichen 
"im Köcher haben" (beherrschen wäre zuviel verlangt, jedoch 
anzustreben).
Monokulturen, Einseitigkeiten und limitierte Denke sind bäh.

[Dr. Sommer (Gast)]

Was wenn ich mich für die Details einer Mainstream Sprache interessiere, 
z.B. wie Java Bytecode jetzt genau funktioniert oder die C++ Value 
Semantics und wie die Optimierungs-Algorithmen des Compilers arbeiten... 
bin ich dann ein Mainstream-Schaf oder hipp und "aufgeweckt"?

[Jörg W. (dl8dtl) (Moderator)]

Programmiersprachentheaterintendant schrieb:
> - Modula-2 (kompakt, modular, skaliert gut f. Grossprojekte, NOCH OHNE
> OO)

Modula-3 wäre noch eine weitere Erweiterung von Modula-2 Richtung OO.

Habe ich in freier Wildbahn aber bislang auch nur einmal erlebt
(FreeBSDs "cvsup" zum Synchronisieren von CVS-Trees).

[Programmiersprachentheaterintendant (Gast)]

Ich will doch noch meine 2 Rupien zu Tcl/Tk abgeben.
Ich hab mal was damit gemacht: oh Wunder, eine Art Installationshilfe 
mit minimalem GUI.
Was mich damals (ca.'96, war so um die Transitionszeit von Perl4 zu 5 
und Py1 zu 2 - damals beide mir noch unbekannt) an Tcl/Tk massivst 
irritierte, war das ich immer Fallunterscheidung auscodieren musste ob 
da nun Liste(mehr als 2 Elem.)/Einzelobjekt(u. entspr. Typ)/oder NULL 
vorlag.
Liste in jedem Fall (egal ob 2+, nur 1 Element oder leere Liste) hätte 
meinem kleinen Projekt den Code um 1/3 kompakter gemacht. (Merke: jede 
Fallunterscheidung ist zu Testen --> Testaufwand!)

Wenige Jahre danach (ca.Jahrtausendwende) stiess ich dann auf Py2.x und 
u.A. sein Duck-Typing + natürlicheren Umgang m. Listen, Tuples, Dicts 
hat mich NIE wieder Tcl/Tk anfassen lassen.

Immerhin wusste ich nach dieser Erfahrung um einen Bewertungsaspekt mehr 
auf den ich achten wollte.

[Chris D. (myfairtux) (Moderator)]

OT:

Programmiersprachentheaterintendant schrieb:
> Was mich damals (ca.'96, war so um die Transitionszeit von Perl4 zu 5
> und Py1 zu 2 - damals beide mir noch unbekannt) an Tcl/Tk /massivst/
> irritierte, war das ich immer Fallunterscheidung auscodieren musste ob
> da nun Liste(mehr als 2 Elem.)/Einzelobjekt(u. entspr. Typ)/oder NULL
> vorlag.
> Liste in jedem Fall (egal ob 2+, nur 1 Element oder leere Liste) hätte
> meinem kleinen Projekt den Code um 1/3 kompakter gemacht. (Merke: jede
> Fallunterscheidung ist zu Testen --> Testaufwand!)

Hast Du dazu ein Beispiel?
Wir nutzen hier Tcl auch schon seit 1996 recht intensiv (unter anderem 
als Portierung auf STM32 inkl. Tk) und ich hatte ehrlich gesagt noch nie 
dieses Problem. Daher interessiert mich das :-)

/OT

[Programmiersprachentheaterintendant (Gast)]

Dr. Sommer schrieb:
> Was wenn ich mich für die Details einer Mainstream Sprache interessiere,
:
> bin ich dann ein Mainstream-Schaf oder hipp und "aufgeweckt"?

Tja, dann hast Du m.M.n. den falschen Thread erwischt: wenn ich hier 
"aufgeweckt" bin, ist das nicht die Perspektive des TE.

Die von Dir angesprochenen Details haben separate Threads verdient.

Nur meine 2 Drachmen. (hier eher Drachen, vom "Dragon Book" & Co. 
assoziiert)

[Stefan (Gast)]

Programmiersprachentheaterintendant schrieb:
> Der Vollständigkeit halber will ich noch folgende Programmiersprachen
> auflisten, welche durchaus auch für eine sehr breite Spanne an
> "Sytemgrösse" taugen

Du hättest dann vielleicht auch Zig und Terra erwähnen sollen, beide mit 
C-ähnlicher low-level Priorität, und damit prinzipiell für uC 
interessant. Ich kenne beide aber nicht, und deren Namen war mir auch 
entfallen.

www.ziglang.org

www.terralang.org

[Dietmar (Gast)]

Ich habe mich nun für BSL und DrRacket entschieden. 
(http://www.htdp.org/)

Das war ein guter Tipp! Habe heute schon mit den Unterlagen gearbeitet 
und es macht mir enorm Lust auf mehr! Hätte ich jetzt in diesem Maße gar 
nicht erwartet. Schade dass ich nicht schon früher darauf gekommen bin.

Dabei verbessere ich auch gleich noch mein Englisch. Wobei ich 
inzwischen eine auf dem Skript basierende deutsche Fassung gefunden 
habe: 
http://ps.informatik.uni-tuebingen.de/teaching/ws15/info1/script/index.html

[M.K. B. (mkbit)]

Ich möchte hier einfach mal meine persönliche Erfahrung beschreiben, 
wobei das jeder hier auch anders sehen könnte.
Auf Aspekte, die Objekt orientiert Programmierung betreffen gehe ich mal 
nicht ein, weil es für die Fragestellung hier zu fortgeschritten wäre.

Ich arbeite beruflich mit C++, weil hardwarenah aber mit Objekten und 
Templates. C habe ich mal für Mikrocontroller verwendet, aber 
mittlerweile setze ich auch dort C++ ein. Das würde ich aber nur Profis 
empfehlen, weil nicht alles was teuer aussieht auch teuer ist es aber 
auch umgekehrt sein kann.
Einem Anfänger würde ich diese Sprachen aber nicht empfehlen, weil man 
durch Pointer und kontrolliert Speicherallokation zwar viel Kontrolle 
hat, greift man aber einmal daneben verhält sich das Programm evtl. 
komisch ohne dass man weiß warum.

Assembler habe ich mal auf einem AVR gemacht. Ich finde es interessant, 
wenn man besser verstehen möchte, wie ein Prozessor funktioniert. Sonst 
war es mir aber zu mühselig und der Compiler soll das übernehmen.

JavaScript ist die einzige Möglichkeit für webbasierte Scripte im 
Browser. Debugger bringen die Browser schon mit. Nachteil ist, dass im 
Browser Dateisystem und IO Pins nicht möglich sind. Über Node.js kann 
man aber auch normale Programme in JavaScript schreiben.

Java verwende ich wenn es ohne Kompilierung auf verschiedenen Systemen 
laufen muss. Die Syntax ist ähnlich wie C++, aber ich habe das Gefühl 
man ist weiter weg von der Hardware und Fehler werden verständlicher 
über Exceptions gemeldet. Mir gefällt die starke Typisierung, weil man 
dadurch Typfehler schon zur Compilezeit erkennt (ich bin es aber auch 
von C++ gewöhnt).

Python nutze ich für Basteleien und um Dinge zu automatisieren. Mir 
gefällt an Python die konsequente Logik in der Sprache und der 
Bibliothek. Das tolle an Python ist, dass man als Anfänger alles selbst 
schreiben kann (mit for loop und so), wenn man aber fortgeschritten ist 
auch die entsprechende Funktion aus der Bibliothek verwenden kann.

Da ich aus der C/C++ Welt komme, fallen mir Sprachen, die diesen ähneln 
leichter, weshalb hier z.B. Lisp fehlt. Das muss aber nicht heißen, dass 
andere Sprachen für einen Anfänger nicht besser wären.

[Sheeva P. (sheevaplug)]

Alles Humbug schrieb:
> Sheeva P. schrieb:
>>> Alles Humbug schrieb:
>>>> Warum kommt ständig jemand auf die "Idee" das Rad nochmal neu erfinden
>>>> zu müssen, nur diesmal so, dass die Felge nach innen gekrempelt wird und
>>>> das ganze nicht mehr nach Rad aussieht?
>>
>> Ach, Humbug, Lisp stammt von 1958, Scheme von 1975, C von 1972. Wer hat
>> da wohl "das Rad neu erfunden"? ;-)
>
> Ach Sheeva, ihr Fanboys von kruden Dialekten seid alle sooo helle, könnt
> aber keine zwei Zeilen mal im Kontext aufnehmen, ohne immer alles
> wortwörtlich auszulegen.

Ach, Humbug, leider wieder daneben. Ich bin gar kein Freund von Lisp und 
benutze es ausschließlich zur Konfiguration meines GNU Emacs.

[Datensprache (Gast)]

Wenn du weitere Übersichten von anderen Programmiersprachen brauchst und 
die passende für dich finden willst solltest du mal auf unsere Seite 
vorbeischauen:   https://datensprache.de/