Ist der Hobbybastler Multilingual veranlagt?

PICSIM schrieb:
> Wie sieht das bei Euch aus? Bleibt Ihr einer Sprache treu?

Ist doch nie und nimmer Praktikabel. Einen µC kann man nicht mit 
Python/PHP programmieren; eine Webanwendung in C geht zwar, ist aber ein 
Krampf.

Da wären: C (nur auf µC), Python, PHP, Javascript, Grundzüge von Java, 
TI-Basic :( und Reverse Polnish Lisp

Hier meine erlernten Programmiersprachen im Laufe des Ingenieurlebens...

ALGOL
PL1
Fortran
Assembler Z80
Assembler Z8
Basic
Pascal
C
Assembler AVR

Zurückblickend würde ich sagen, dass die Programmierung immer gleich 
aufgebaut war und ist. Es geht immer um mathematische Algorithmen. Ob 
der Befehl heute „Print“ heißt und vor 20 Jahren „Output“ ist dabei 
unerheblich. Die Benutzung von hunderttausend Klassenbibliotheken und 
DotNet Kram hat eh wenig mit Programmierung zu tun. Ich würde mal 
prognostizieren, dass sich in 20 Jahren kein Mensch mehr für DotNet 
interessiert. Schleifen, rekursive Anweisungen, Zeiger, ... wird es dann 
aber immer noch geben.

Wenn du aber nicht programmieren möchtest, sondern eine „bunte GUI“ (so 
heißt das wohl) zusammenschieben möchtest, dann brauchst du natürlich 
auch die letzte flippige Programmiersprache dazu. Mathematische 
Algorithmen sind dabei kontraproduktiv :-)

Paul Baumann schrieb:
> Heute verbringe ich Stunden damit, die richtige Syntax für eine Zeile
> zu suchen...

Das nennt man Fortschritt.

PICSIM schrieb:
> Soll also ein klares Ja für Multilingual sein?

Das sollte heißen, das ständige Kommen und Gehen von Programmiersprachen 
mit etwas Abstand und gesundem Menschverstand zu betrachten.

Ich glaube, wie multilingual ein Bastler ist oder sein sollte, hängt
davon ab, was er bastelt. Beispiele:

- Ein Bastler, der nur reine Elektronik ohne Mikrocontroller macht, darf
  durchaus alingual sein.

- Ein Bastler, der mit Mikrocontrollern spielt, aber bspw.mit
  PC-Programmierung nichts am Hut hat, ist typischerweise monolingual,
  und programmiert je nach Geschmack in C, Assembler oder Basic.

- Ein Bastler, der nur auf dem PC programmiert, ist ebenfalls
  monolingual nimmt aber als Programmiersprache eher C++, Java, oder
  C#.

- Fortgeschrittene PC-Programmierer sind bilingual und haben in ihrem
  Repertoire oft eine Sprache für hohe Ausführungsgeschwindigkeit (z.B.
  C++) und eine für hohe Entwicklungsgeschwindigkeit (z.B. Python).

- Fortgeschrittene Bastler mit kombinierten µC/PC-Anwendungen sind
  deswegen meist trilingual.

- Mit steigender Lebenserfahrung werden einige Programmiersprachen
  altmodisch, und der Bastler will sie nicht mehr sehen. Dann lernt er
  eine neu und steigert dadurch seine Multilingualität weiter. Angst,
  dass die Programmiersprachen irgendwann ausgehen, braucht er keine zu
  haben.

Es gilt ja sowieso die Devise:

  "Learn a programming language every year"

Hiermit kann der Bastler den Vorgang noch etwas beschleunigen:

  http://pragprog.com/titles/btlang/seven-languages-in-seven-weeks

Es ist nie schlecht mehrere Sprachen zu beherrschen.
Dann kann man je nach Problem, die geeignetste auswählen.

Vielleicht kennt jemand das Sprichwort:
"Wenn man als Werkzeug nur einen Hammer hat, sieht jedes Problem wie ein 
Nagel aus"

meine Liste:

c      µC, DSP
c++    µC, PC, eher Kommandozeilen, im Job: Entwicklung PC-Prototypen
C#     PC, GUI-lastige Sachen
java   PC, portable oder GUI-lastige Sachen
Delphi PC, kleine GUI-lastige Sachen (seltener)
Perl   PC, Mini-CMD-Tools, Verarbeitung großer Text-Datenmengen, 
Webseiten
SQL    PC, Verarbeitung großer Datenmengen, Webseiten
asm    µC - versuch ich zu vermeiden.
asm    PC - überflüssig
VBA    MS-Excel-Makros :(
matlab/octave numerische Berechnungen
gnuplot Datenvisualisierung
Maxim  CAS

Yalu X. schrieb:
> Hiermit kann der Bastler den Vorgang noch etwas beschleunigen:
>
>   http://pragprog.com/titles/btlang/seven-languages-in-seven-weeks

Der Ansatz, auch andere Paradigmen zu lernen, ist zwar gut und richtig 
und das Buch ebenfalls, aber einem "Bastler" u.a. Scala, Ruby, Haskell 
oder Prolog d.h. völlig fremde Paradigmen im Schnellverfahren 
vorzusetzen, dürfte eher suboptimal sein, zumal einige der vorgestellten 
Sprachen imo alles andere als geeignet sind, diese Paradigmen zu lernen. 
Besser wäre da Standard ML oder Verwandte, Smalltalk/Ruby und zum 
Schluss vielleicht noch etwas Prolog.

Joe G. schrieb:
> Hier meine erlernten Programmiersprachen im Laufe des Ingenieurlebens...
...
> Zurückblickend würde ich sagen, dass die Programmierung immer gleich
> aufgebaut war und ist.

Wenn man nur einen Hammer kennt oder wie hier nur ein Paradigma, das 
imperative, mag das so aussehen...Es gibt noch andere...

> Die Benutzung von hunderttausend Klassenbibliotheken und
> DotNet Kram hat eh wenig mit Programmierung zu tun.

Anders lässt sich heute keine Software in angemessener Zeit und mit 
angemessenem Aufwand mehr entwickeln. Gerade die Bibliotheken 
entscheiden heute über Erfolg oder Misserfolg (nicht nur des einzelnen 
Projekts...).

> Ich würde mal prognostizieren, dass sich in 20 Jahren kein Mensch mehr
> für DotNet interessiert.

Software die in/mit Java, C#, VB etc. entwickelt wurde/wird, wird es in 
20 Jahren immer noch geben, so wie es heute mit Cobol, Fortran und C der 
Fall ist.
Selbst wenn die Software, wie heute schon möglich, automatisch in eine 
andere Sprache übersetzt wird, behebt das nicht die Fehler im Design 
und/oder wandelt unwartbaren, nicht mehr oder schlecht erweiterbaren 
Code in das Gegenteil um. D.h. auch dann wird es darauf hinauslaufen, 
dass entweder, falls Geld und Zeit vorhanden sind, eine Neuentwicklung 
gestartet wird oder, was wesentlich wahrscheinlicher ist, die Codebasis 
bis zum geht nicht mehr "weiterverwendet" wird.

> Schleifen, rekursive Anweisungen, Zeiger, ... wird es dann aber immer noch 
geben.

Z.T....

> Wenn du aber nicht programmieren möchtest, sondern eine „bunte GUI“ (so
> heißt das wohl) zusammenschieben möchtest, dann brauchst du natürlich
> auch die letzte flippige Programmiersprache dazu. Mathematische
> Algorithmen sind dabei kontraproduktiv :-)

Für kleine GUIs, vielleicht, bei größeren Sachen, ist es reine 
Mathematik, auch wenn sie nicht unbedingt als solche wahrgenommen 
wird...

Ich bin auch ehr Multilingual ausgerichtet:

C+Bascom für µC:
Bascom wenn es flott entwickelt sein soll, nicht Ressourcen lastig etc
C wenns profesioneller sein soll- Ethersex z.B. atm^^

C# als Hauptsprache für den PC: muss nichts Rechenintensives machen, 
gute GUI und Datenbankanbindung ist da wesentlich wichtiger, ausserdem 
unterstützt Visual Studio sehr sehr gut!

Java (JSP)+PHP für Webseiten

Pascal bzw MuPAD, für mathematische Geschichten(habe aus der Schule noch 
das CAS)


Je mehr man kann, desto breiter ist man aufgestellt, und desto besser 
weiß man, wie man was am besten löst. Vorallem geht es flotter

Aber das mit dem Semikolon mache ich auch gerne in Bascom, oder das $ 
vergessen in php

Arc Net schrieb:
>> Die Benutzung von hunderttausend Klassenbibliotheken und
>> DotNet Kram hat eh wenig mit Programmierung zu tun.
>
> Anders lässt sich heute keine Software in angemessener Zeit und mit
> angemessenem Aufwand mehr entwickeln. Gerade die Bibliotheken
> entscheiden heute über Erfolg oder Misserfolg (nicht nur des einzelnen
> Projekts...).

Da stimme ich dir voll zu! Der Programmierer hat keine Bibliothek zur 
Berechnung von Eigenwerten und Eigenformen gefunden und wollte das 
Projekt mit der gewählten Programmiersprache deshalb sterben lassen. Auf 
die Idee SELBST ein kleines Unterprogramm zur Berechnung zu schreiben 
ist er nicht gekommen. Diese mathematischen Algorithmen waren ihm 
entweder fremd oder sie ließen sich nicht so einfach mit der Maus 
zusammenschieben :-(

Vlad Tepesch schrieb:
> Vielleicht kennt jemand das Sprichwort:
> "Wenn man als Werkzeug nur einen Hammer hat, sieht jedes Problem wie ein
> Nagel aus"

In den 60 zigern sollte die KYBERNETIK alle technischen und ökonomischen 
Probleme wissenschaftlich exakt und in kurzer Zeit lösen.

Mit den Programmiersprachen Lisp und Prolog war man in den 80 zigern von 
der künstlichen Intelligenz nur noch einen Hauch weit entfernt.

Dann waren Expertensysteme DIE Lösung zur Bewältigung aller komplexer 
Aufgaben.

Vielleicht kennt jemand das Sprichwort:
„Es wind nicht alles so heiß gegessen, wie es gekocht wird“

Joe G. schrieb:
> ...

Ich verstehe den Zusammenhang zwischen dem Quote meiner Aussage und der 
deinigen nicht.

Nun du wolltest sagen, dass jede Programmiersprache mehr oder weniger 
gut für ein spezielles Problem verwendet werden kann, sozusagen immer 
ein Spezialwerkzeug statt eines universellen Hammers darstellt.
Ich wollte sagen, dass ich schon viele Spezialwerkzeuge 
(Programmiersprachen) habe kommen und gehen sehen. Übrig geblieben sind 
robuste Mehrzweckwerkzeuge (Hammer).

Joe G. schrieb:
> Da stimme ich dir voll zu! Der Programmierer hat keine Bibliothek zur
> Berechnung von Eigenwerten und Eigenformen gefunden und wollte das
> Projekt mit der gewählten Programmiersprache deshalb sterben lassen. Auf
> die Idee SELBST ein kleines Unterprogramm zur Berechnung zu schreiben
> ist er nicht gekommen. Diese mathematischen Algorithmen waren ihm
> entweder fremd oder sie ließen sich nicht so einfach mit der Maus
> zusammenschieben :-(

Kleines Unterprogramm?
Simple Eigenwertprobleme lassen sich zwar auch symbolisch recht einfach 
lösen (passende Sprache vorausgesetzt), allgemein sieht das aber 
deutlich anders aus. Da geht's nicht nur darum geeignete Algorithmen zu 
finden, sondern auch darum diese so zu implementieren, dass sie stabil, 
robust und zumeist auch schnell sind und das ist nicht trivial und mal 
eben so mit einem kleinen Unterprogramm lösbar.
Buchempfehlung: J. H. Wilkinson, The Algebraic Eigenvalue Problem
ISBN 9780198534181

Arc Net schrieb:
> Kleines Unterprogramm?
> Simple Eigenwertprobleme lassen sich zwar auch symbolisch recht einfach
> lösen (passende Sprache vorausgesetzt), allgemein sieht das aber
> deutlich anders aus.

Das war doch nur ein Beispiel. Ich hätte auch Dgl, oder Matrixinversion, 
oder Volumenintegral, oder, oder sagen können. Oft habe ich einfach den 
Eindruck, immer wenn es keine Bibliothek dafür gibt geht es nicht 
weiter.

Vlad Tepesch schrieb:
> "Wenn man als Werkzeug nur einen Hammer hat, sieht jedes Problem wie ein
> Nagel aus"

Jo solch ein Exemplar habe ich mit im Büro sitzen, sein Hammer heißt 
EXCEL. Der hat sich sogar schon eine Art Dissambler mit Excel gebastelt. 
Ganz toll sind auch mehrfach verknüpfte Dateien/Tabellenblätter. ^^

Zurück zum Thema:
Im laufe der letzten Jahre habe ich auch einige Programmiersprachen 
sprechen gelernt. Angefangen mit AmigaBasic, C/C++, ASM für 8051, Java, 
Pascal, VBA, PHP, Labview.

Mittlerweile beschränke ich mach auf
C       - µC-Programmierung
Java    - GUI, Webseiten (JSP), Datenbank
Labview - GUI und um schnell mal was zusammen zu klicken

Also laut Yalu -> fortgeschrittener Bastler. :D
Yalu X. schrieb:
> - Fortgeschrittene Bastler mit kombinierten µC/PC-Anwendungen sind
>   deswegen meist trilingual.

Dank diesem Forum demnächst C++ mit Qt für GUI und mal schauen was man 
sonst noch so anstellen kann. ;)

Joe G. schrieb:
> Das war doch nur ein Beispiel. Ich hätte auch Dgl, oder Matrixinversion,
> oder Volumenintegral, oder, oder sagen können. Oft habe ich einfach den
> Eindruck, immer wenn es keine Bibliothek dafür gibt geht es nicht
> weiter.

Da könnte man auch antworten, oft hat man einfach den Eindruck, dass der 
Aufwand, der nötig ist um so was sauber zu lösen, massiv unterschätzt 
wird.
Einfach mal ansehen welche Verfahren zur numerischen Lösung der 
genannten Probleme angewandt werden (müssen)...
Und da wären wir wieder bei den Sachen von oben: Wenn's wirklich schnell 
sein muss bleiben nur die üblichen Verdächtigen übrig...

Bei mir schaugt eher so aus:

C(++)  => AVRs (und in der Arbeit PICs, grmpfh)
FreeBasic/Python => Aufm PC (Vor allem Python ist auf Linux äußerst 
praktisch)

Ansonsten noch ein bisschen PHP-gebastel

Für GUI-Anwendungen hab ich noch nix so richtiges... :(
Mal Python+QT angucken...

Ob das jetzt Multilingual ist - k.a. - Kann wohl jeder so sehen wie er 
will
Aber wohl eher nicht...

PICSIM schrieb:
> C++:
> am kompliziertesten, kann auch Android!!!, mit .Net günstig zu nutzen,

Nein. Mit .Net lässt sich C++ nicht nutzen. Es gibt zwar "C++/CLI" bzw. 
"Managed C++", aber beides sind .Net-Sprachen und kein C++.

Verwirrter Anfänger schrieb:
> Meistens programmier ich meine µC noch mit Textpad,

Ich habe leider auch noch keine gute IDE für die AVRs gefunden

Bascom ist nutzbar, hoffe mal ehr auf AVR Studio 5, was ja aufm Visual 
Studio aufsetzten soll?

Kennt jemand was gutes für den Hobby-C-AVR-Bereich (Kosten überschaubar) 
am besten Unterstützung STK 500 & etc.

PICSIM schrieb:
> Ok JAVA oder C#
>
> Kriterien:
>
> Einsatzmöglichkeiten (Web, Android, Datenbanken, MS Office)
> evtl Kosten
> Support (Forum)
> Lernbarkeit

Wenn Android bzw. Smartphone ein wichtiges Kriterium ist bleibt nur Java 
übrig, C# ist ausschlisslich Windows (wenn man mal von Mono absieht).
Java läuft auf so ziemlich jedem aktuellen Smartphone auch viele ältere 
Handys haben eine VM.

Datenbanken und Web (Client & Serverseitig) gehen mit Java ziemlich gut.

Was du aber mit MS Office meinst ist mir nicht ganz klar.

Bei den Kosten und Support unterscheiden sich beide kaum, beides gibt es 
kostenlos, C# in Form der Express-IDEs.

Marcus B. schrieb:
> Kennt jemand was gutes für den Hobby-C-AVR-Bereich (Kosten überschaubar)
> am besten Unterstützung STK 500 & etc.

Ich habe bisher immer CodeBlocks verwendet, Software fürs flashen/STK 
500 musst du aber selbst einbinden.
Werde demnächst aber wohl auch auf Eclipse umsteigen.

Du machst den gleichen Fehler den du am Anfang angesprochen hast. Du 
willst EINE neue Sprache für komplett unterschiedliche Anforderungen:
Wenn du irgendwelche Erweiterungen für Office machen willst brauchst du 
dafür eine MS spezifische Sprache.
Wenn du Android programmieren willst brauchst du eine passende Sprache. 
Im einen Fall ist das evt. Java, im anderen vieleicht C#

C# und Java ähneln sich in der Synatx, wenn man eine kann ist die andere 
relativ gut erlernbar.
Was du völlig übersiehst ist der Paradigmenwechsel, Sowohl C# als auch 
Java sind objektorientiert. Du kennst bisher nur prozedural. Bis du 
wirklich objektorientiert denkst und sauber designest vergeht mindestens 
ein Jahr mit viel Übung.
Das ist die Crux an C++, man kann immer noch prozedural programmieren 
und in dem Zeitraum in dem ich mich damit beschäftigen musste waren 
nahezu 100% aller Programme ein wüstes Gewurstel aus C und C++. Bei 
großen Projekten mit hunderten von Modulen und mehreren 100.000 Zeilen 
Code kein Spass!

Mein Tipp: Was ist dir wichtiger, Android oder MS-Office? Nimm das 
passende und lerne die richtig (vor allem OO-Design). Die andere wird 
dann nicht mehr so schwer sein.

Udo Schmitt schrieb:
> Das ist die Crux an C++, man kann immer noch prozedural programmieren
> und in dem Zeitraum in dem ich mich damit beschäftigen musste waren
> nahezu 100% aller Programme ein wüstes Gewurstel aus C und C++

Das ist ein Grund warum ich vor ein paar Jahren von C++ weggegangen bin 
und Java gelernt habe. In Java gibt es dieses Gewurstel einfach nicht. 
Ein anderer Grund waren die M$-Vergewaltigungen an C++ (z.B. MFC).

PICSIM schrieb:
> Es ist doch
> bestimmt etwas anderes hinsichtlich der Programmierung, ob ich jetzt
> Web-Anwendungen, Datenbanken oder sonst was programmiere.

Jain, die grundsätzliche programmierung bleibt gleich. Du wirst andere 
Klassen für Web und Datenbanken verwenden. Ausserdem wirst du bei Web 
mit HTML und evtl. XML bennötigen und bei Datenbanken solltest du 
Kenntnisse über SQL haben.

Java bietet sogar die Möglichkeit ein Programm zu schreiben und es 
unverändert auf den Desktop zu verwenden, als Applet in eine Webseite 
einzubinden oder auf dem Smartphone auszuführen. Das ist allerdings 
keine Übung für einen Anfänger :D

PICSIM schrieb:
> Bei JAVA wäre Eclipse als IDE eine gute Wahl richtig?

Eclipse hat den Vorteil du kannst es für C/C++ und Java verwenden.

Also ich bin der Meinung, man sollte seine Nase mal in alle Paradigmen 
stecken.

Somit sollte man aus folgenden Sprachen mal mindestens mit einer mal ein 
wenig gespielt haben: (Die Beispiele in den Gruppen sind nicht 
vollständig und nur eine grobe Einordnung)

"Maschinennahe unstrukturierte Sprachen":
(altes) BASIC (mit Zeilennummern!), Assembler

Prozedurale Sprachen:
Pascal, C (vor C unbedingt Assembler machen)

Funktionale, Symbolische Sprachen:
Lisp, Prolog

Objektorientierte Sprachen:
Smalltalk, Erlang

"C++"-objektorientierte Sprachen:
C++ (vorher unbedingt Assembler lernen), C#, OOPascal, Java

"Getting Things Done"-Sprachen:
bash, perl, awk, sed, VBA, Python

Es geht nicht darum, dass man die Sprachen bis ins letzte Detail 
beherrscht, sondern darum, dass man genügend darüber weiß, welche 
Sprache man für ein gegebenes Problem sinnvoll anwenden kann.

Was ich für nicht sinnvoll halte ist es, momentanen Trends hinterher zu 
laufen. In 10 Jahren schaut die Welt wieder ganz anders aus. 
Modesprachen erkennt man häufig daran, dass sie versuchen, andere 
Sprachen zu kopieren.

Das ist der Grundstock. Für Beruf und Hobby kann man sich natürlich noch 
in ein paar der Sprachen detailiert einarbeiten. Ich persönlich mag die 
Pascal-Schiene, damit komme ich gut zurecht, besonders seit dem ich 
meistens nur noch Textdateien verarbeite. Für GUI nehme ich den Delphi 
Klon Lazarus.

M. K. schrieb:
> Wenn Android bzw. Smartphone ein wichtiges Kriterium ist bleibt nur Java
> übrig, C# ist ausschlisslich Windows (wenn man mal von Mono absieht).

Smartphone ist nicht einfach Java...
iOS = ObjectiveC, Android = Java (C++ für native Anwendungen), webOS = 
JavaScript + HTML (C++ für native Anwendungen), Symbian = C++/Qt, 
BlackBerry = Java (C++), WP7 = C#/VB/F#
Android, iOS und webOS könnte man auch mit C# (bzw. fast allen 
CLI-Sprachen) programmieren (monoTouch, monoDroid, monoWebOS).
Andere Cross-Platform-Tools nutzen dagegen z.B. HTML + JavaScript 
(appcelerator, UnityMobile, PhoneGap), Rhomobile z.B. Ruby und sowohl 
Android, als auch z.B. iOS oder WP7 haben WebBrowser-Controls einbinden 
d.h. man kann auch dort sehr viel mit HTML erschlagen.
JavaME kann man dagegen getrost in die Tonne treten, da es hoffnungslos 
veraltet ist und die Möglichkeiten der aktuellen Systeme nicht 
vernünftig nutzt und kaum noch verbreitet ist. Android + RIM + iOS sind 
z.Z. die Marktführer, Symbian verliert nur noch Marktanteile, RIM 
verliert z.Z. in fast allen Märkten, selbst iOS verliert in einigen 
Märkten. Wenn man jetzt nicht nur aus reinem Interesse Apps entwickeln 
will, stellt sich die Frage was man macht: In die "Haifischbecken" von 
Android und iOS oder in die (mehr oder weniger stabilen) Nischen der 
anderen Systeme.
http://www.guardian.co.uk/technology/2011/apr/18/smartphone-market-android-win-nokia-rim-lose

> Datenbanken und Web (Client & Serverseitig) gehen mit Java ziemlich gut.

Falls man mal LINQ und/oder SL eingesetzt hat, will man nicht mehr zu 
Java zurück...

Arc Net schrieb:
> Smartphone ist nicht einfach Java...

Das war jetzt auf die beschränkte Auswahl C# oder Java bezogen.

Arc Net schrieb:
> Android, iOS und webOS könnte man auch mit C# (bzw. fast allen
> CLI-Sprachen) programmieren (monoTouch, monoDroid, monoWebOS).
M. K. schrieb:
> C# ist ausschlisslich Windows (wenn man mal von Mono absieht).

Arc Net schrieb:
> Falls man mal LINQ und/oder SL eingesetzt hat, will man nicht mehr zu
> Java zurück...

Kenne ich nicht, kann ich also nichts zu sagen.

wobei er sich aus

Christian Berger schrieb:
> "Getting Things Done"-Sprachen:
> bash, perl, awk, sed, VBA, Python

die schlechteste rausgesucht hat:

PICSIM schrieb:
> "Getting Things Done"-Sprachen:
> -> VBA

weibei man bei sed ja nicht wirklich von Sprache sprechen kann.
dennoch gehört es mit grep und perl zu meinen must have programmen

@PICSIM: Probier' mal LISP oder SCHEME, damit lernst du einen vollkommen 
anderen Zugang als mit C und Konsorten.

Zwie Blum schrieb:
> @PICSIM: Probier' mal LISP oder SCHEME, damit lernst du einen vollkommen
> anderen Zugang als mit C und Konsorten.

naja - praktischer Nutzen quasi gleich null

Um die Frage das TO zu beantworten:
Ich bin Hobbybastler durch und durch, mein Job hat nichts mit Elektronik 
und Programmieren zu tun.

Ursprünglich PC Programmierung gemacht bevor ich mit uC angefangen habe. 
Mein Leib und Magensprache ist C++, für meine AVRs und Arms habe ich auf 
C "umgelernt". Da sind ja doch viele kleine Unterschiede.
Am PC nutze ich daneben noch Java, das kommt immer auf die konkrete 
Fragestellung und, ich gebe zu da bin ich Faul, ob für ein Problem schon 
Libraries oder ähnliches vorhanden sind.

Assembler auf den uCs fasse ich nur mit spitzen Fingern an, wenn es für 
Optimierungen absolut notwendig ist und um mal zu debuggen. Ganze 
Programme schreibe ich damit nicht. Wenn der Controller für mein C 
Programm zu klein ist, nehme ich den nächst größeren.

Ansonsten habe ich noch ein paar Erfahrungen mit Pascal / Delphi und 
Basic wobei ich vor allem mit letzterem nie warm geworden bin - da sieht 
auch sauberer Code irgendwie immer total unstrukturiert für mich aus.

Zurzeit lese ich noch Spaßeshalber "Land of Lisp" - einfach weil dieses 
Buch gut geschrieben ist und LISP ganz anders ist als mein üblicher 
Horizont.

Vlad Tepesch schrieb:
> weibei man bei sed ja nicht wirklich von Sprache sprechen kann.

Doch natürlich ist sed auch eine Sprache. Mehr noch: Sie ist sogar
Turing-vollständig:

  http://en.wikipedia.org/wiki/Sed#History

;-)

Vlad Tepesch schrieb:
> Zwie Blum schrieb:
>> @PICSIM: Probier' mal LISP oder SCHEME, damit lernst du einen vollkommen
>> anderen Zugang als mit C und Konsorten.
>
> naja - praktischer Nutzen quasi gleich null

Ich würde sagen, mit Scheme hat man ähnlich viele Möglichkeiten und
Einschränkungen (aber natürlich nicht die gleichen) wie bei VBA. Ich
würde beides nicht lernen, aber wenn ich müsste, dann eher noch Scheme.

Mit "richtigem" Lisp (Common Lisp) sind die Möglichkeiten schon wesent-
lich weitreichender. Und da man als Hobbybastler keine Vorgaben vom Chef
bzgl. der Wahl der Programmiersprache hat, warum sollte man nicht Lisp
verwenden? Einige Freaks, für die beim Programmieren der Weg das Ziel
ist, tun das ja durchaus.

naja, mal eben eine gui?
ein wenig textprocessing mit regulären ausdrücken?
uart-Kommunikation mit dem µC?

für keinen dieser Standardanwendungsfälle ist scheme (CL kenne ich 
nicht) wirklich praktisch

die Sprachen haben sicher im akademischen bereich ihre berechtigung, 
oder um damit algorithmische Probleme zu lösen, aber für die Praxis sehe 
ich da keine große Bedeutung.

Da fällt mir das wieder ein:
http://xkcd.com/224/
einfach genial!
Man beachte auch den Tooltip-Text ;)

Mir gefällt der da besser: http://xkcd.com/297/

"Praktisch" liegt im Auge des Betrachters. Der Witz bei LISP liegt ja 
eben darin, dass der übliche Weg nicht zum Ziel führt :-)

Vlad Tepesch schrieb:
> naja, mal eben eine gui?
> ein wenig textprocessing mit regulären ausdrücken?
> uart-Kommunikation mit dem µC?
>
> für keinen dieser Standardanwendungsfälle ist scheme (CL kenne ich
> nicht) wirklich praktisch

Wie ich oben geschrieben habe, sind die Möglichkeiten von Scheme schon
etwas eingeschränkt, aber das trifft eben auch für VBA zu. Um Scheme mit
VBA vergleichen zu können, muss man eine Scheme-Implementation
betrachten, die wie VBA zum Schreiben von Erweiterungen für bestehende
Anwendungen dient, also z.B. Guile. Als Erweiterungssprache hat Guile
ganz ähnliche Fähigkeit en wie VBA. Der Hauptunterschied liegt (neben
dem völlig anderen Sprachkonzept) darin, dass man mit Guile keine und
mit VBA nur MS-Office-Anwendungen erweitern kann.

Also wenn jemand mal SCHEME probieren möchte, dem kann ich 
http://racket-lang.org/  ans Herz legen. Doku gibt's hier: 
http://docs.racket-lang.org

PICSIM schrieb:
> Ist der Hobbybastler Multilingual veranlagt?

Ja, würde ich sagen. Bisher wurde es nicht genannt, aber man darf nicht 
vergessen dass hinter den Symbolen eines Elektronikplans ebenso eine 
Sprache steckt. Hinzu kommt, dass wohl jeder Bastler nochmal eine eigene 
Symbolik beim Skizzieren von Projekten verwendet.