Servus,
bisher bin ich immer in C/C++ unterwegs. Für kleine Hilfs-Tools erzeugt
das natürlich immer einen gewissen Overhead. Deswegen denke ich schon
lange darüber nach eine Scriptsprache zu lernen. Jetzt bräuchte ich ein
wenig Entscheidungshilfe. Wobei ich schon relative sicher bin, was ich
nicht will und bereits eine Tendenz habe, was ich will:-)
Perl und TCL sind jedenfalls schon mal keine Option, da ich die Syntax
als grausig empfinde.
Ein wenig Erfahrung habe ich mit ECMA/Javascript (Mit QtScript
verwendet). Das gefällt mir wegen der C++ ähnlichen Syntax eigentlich
recht gut. Leider ist die Sprache eher im Webdesign verbreitet und es
ist mir bisher nicht gelungen einen Standalone-Interpreter als Binary
aufzutreiben. Ich habe mal versucht Googles V8-engine zu bauen (soll
angeblich kein Problem sein) und bin kläglich gescheitert.
Eine weitere Option wäre Python. Was für mit sehr stark für Python
spricht, ist dass es mit PyQt eine sehr mächte Erweiterung gibt, die
vollen Zugriff auf auf meine geliebte Qt-Umgebung erlaubt :-)
Was mich an Python abschreckt, ist die Tatsache, dass die
Code-Strukturierung über Einrückung erfolgt. Vom Handling gewöhnt man
sich vermutlich daran, aber ich frage mich, ob das nicht arg
Fehleranfällig ist. Was sagen die Leute mit Python-Erfahrung dazu?
Weitere Vorschläge für Sprachen?
Philip K. schrieb:> Eine weitere Option wäre Python. Was für mit sehr stark für Python> spricht, ist dass es mit PyQt eine sehr mächte Erweiterung gibt, die> vollen Zugriff auf auf meine geliebte Qt-Umgebung erlaubt
Wenn die Lizenz für dich in Ordnung ist, ist das eine sehr gute Wahl.
PySide scheint ja nie richtig gelebt zu haben.
Ich selbst bin Ruby-Mensch, aber Python wäre auch meine Wahl, wenn ich
heute von Grund auf anfangen würde. Nicht nur die Toollandschaft ist
gut, sondern insbesondere die Dokumentation ist exzellent.
Philip K. schrieb:> Perl und TCL sind jedenfalls schon mal keine Option, da ich die Syntax> als grausig empfinde.
wo ist denn der Syntax von Perl so großartiung unterschiedlich zu C++?
Es gibt zwar in Perl sehr viele Möglichkeiten etwas zu schreiben. Aber
man kann es ebend auch sehr C ähnlich schreiben. Es gibt halt nur keine
Datentypen.
Wenn du aber schon an solchen kleinigkeiten schreitert, dann wirst du
mit keiner andere sprache außer C zurechtkommen.
Peter II schrieb:> Philip K. schrieb:>> Perl und TCL sind jedenfalls schon mal keine Option, da ich die Syntax>> als grausig empfinde.>> wo ist denn der Syntax von Perl so großartiung unterschiedlich zu C++?>> Es gibt zwar in Perl sehr viele Möglichkeiten etwas zu schreiben. Aber> man kann es ebend auch sehr C ähnlich schreiben. Es gibt halt nur keine> Datentypen.>> Wenn du aber schon an solchen kleinigkeiten schreitert, dann wirst du> mit keiner andere sprache außer C zurechtkommen.
Das musst Du doch nicht gleich persönlich nehmen ;-)
Wenn ich mir mal folgenden Codeschnipsel (willkürlich aus einem bei mir
rumliegenden file genommen) anschaue:
printfOUTFILE"%s_%s_i <= (%s_%s_o and %s_%s_bg)",$slave[$i]{"wbs"},$rename_tga,$master[$tmp]{"wbm"},$rename_tga,$master[$tmp]{"wbm"},$slave[$i]{"wbs"};
printfOUTFILE" or (%s_%s_o and %s_%s_bg)",$master[$j]{"wbm"},$rename_tga,$master[$j]{"wbm"},$slave[$i]{"wbs"};
20
};
21
};
22
};
23
};
24
printfOUTFILE";\n";
25
};
26
};
Kann ich da keine große C++ - Ähnlichkeit erkennen.
Und Perl hat doch einen gewissen Ruf, was die Lesbarkeit angeht.
Zitat von Wikipedia: “Perl: Write once – never understand again”
Philip K. schrieb:> Kann ich da keine große C++ - Ähnlichkeit erkennen.
man muss ja perl nicht so schreiben
> printf OUTFILE "-- tga_i\n";
printf(OUTFILE "-- tga_i\n");
> for ($i=1; $i le $slaves; $i++) {
for ($i=1; $i < $slaves; $i++) {
Peter II schrieb:> for ($i=1; $i < $slaves; $i++) {
for ($i=1; $i <= $slaves; $i++) {
Das sind doch alles nur kleinigkeiten, damit sollte man als
Programmierer zurechtkommen.
Philip K. schrieb:> Und Perl hat doch einen gewissen Ruf, was die Lesbarkeit angeht.> Zitat von Wikipedia: “Perl: Write once – never understand again”
och komm, das problem haben alle sprachen. deswegen…
1
# neu gefundene links in url_list inserten,
2
# links den selben server betreffend werden mit depth+1 insertet,
3
# links die auf neue server verweisen mit depth=0 maxdepth=$config{FETCHER_NEW_SERVERURL_INITIAL_MAXDEPTH}.
4
# $focuslevel beeinflusst NUR maxdepth auf seitenlinks des selben servers,
5
# wird aber in der jetzt ermittelten grösse auch für fremdseiten eingetragen
6
# (verwandte themen auf anderen servern...)
7
foreach my $newurl (@{$linklist_ref}) {
8
&log(2,"insert new url: $newurl");
9
if (&DETECT_SUBURL($server_url,$newurl)) {
10
# link gehoert zu DIESEM server
11
# nur inserten wenn depth <= maxdepth
12
# TODO ">" logik richtig?
13
next if ($url{'depth'}+1 > $url{'maxdepth'}+$maxdepth_delta);
Philip K. schrieb:> es ist mir bisher nicht gelungen einen Standalone-Interpreter> als Binary aufzutreiben
Windows enthält seit längerem einen standardmäßig Interpreter für die
Microsoft-Implementation von Javascript, die "JScript" genannt wird.
http://javascript.about.com/od/reference/a/jscript.htm
Der Interpreter existiert in einer Variante für Kommandozeilengebrauch
(cscript.exe) und mit einer meiner Ansicht nach eher nutzlosen, die
Meldungen als Messagebox (und nicht in das Kommandozeilenfenster)
ausgibt (wscript.exe).
Beide verarbeiten sowohl JavaScript als auch VBScript.
Für Datei-Operationen muss über die JScript-eigene
Automationsschnittstelle mit dem "Windows Scripting Host" kommuniziert
werden.
Ein Problem bei der Sache ist, daß der ganze Kram im Rahmen der
MSDN-Webseite dokumentiert ist, und da die ständig anders aussieht
(Windows-8-Design mit jetzt noch weniger auf einen Bildschirm passenden
Informationen), sind häufig Links zwischen den Seiten kaputt.
>Was mich an Python abschreckt, ist die Tatsache, dass die>Code-Strukturierung über Einrückung erfolgt.
Das ist grässlich und extrem fehleranfällig. Gerade bei grösseren
Programmteilen. Da hat der Erfinder falsch gedacht.
(Man müsste die Ebenen wohl mit '}' oder Ähnlichem kommentieren)
Philip K. schrieb:> Was mich an Python abschreckt, ist die Tatsache, dass die> Code-Strukturierung über Einrückung erfolgt. Vom Handling gewöhnt man> sich vermutlich daran,
Ja.
> aber ich frage mich, ob das nicht arg Fehleranfällig ist. Was sagen> die Leute mit Python-Erfahrung dazu?
Kommt darauf an. Ich verwende zur Einrückung nur Leerzeichen und habe
meinen Editor so eingestellt, dass er versehentlich eingegebene Tabs
automatisch in Leerzeichen expandiert. Dann kann man eigentlich nicht
viel falsch machen. Wenn die Einrückung optisch stimmt, stimmt auch die
Semantik.
Was mich an der Zwangseinrückung etwas stört, ist folgendes:
Wenn man zu Debug-Zwecken schnell eine if-Zeile auskommentieren möchte,
um den nachfolgenden Code bedingungslos auszuführen, muss man diesen
eine Ebene ausrücken, damit Python nicht meckert. Ist man mit Debuggen
fertig und kommentiert die if-Zeile wieder ein, muss der nachfolgende
Code wieder eingerückt werden. Ich behelfe mir in solchen Fällen meist
dadurch, dass ich die if-Zeile stehen lasse und der Bedingung ein "1 or"
voranstelle.
Ähnliches passiert, wenn man temporär einen Code-Block von einem
Programmteil in einen anderen – tiefer verschachtelten – kopieren
möchte.
Diese Fälle betreffen aber nur die temporäre Murksprogrammierung, wie
hin und wieder beim Debuggen üblich. Code, der längeren Bestand haben
soll, wird selbstverständlich immer korrekt eingerückt (wie man das als
anständiger Programmierer auch in C++ machen würde), dann ergeben sich
auch keinerlei Probleme.
Etwas nervig ist es mitunter auch, wenn man Python-Code von anderen
verwendet und dieser nach anderen Richtlinien formatiert ist (andere
Einrückungstiefe oder Tabs statt Spaces).
die genannten Mängel sind aber ahb so schlimm, wenn man die richtigen
Tools bereitliegen hat. Dazu gehört an erste Stelle ein gescheiter
Editor, ggf. mit einem Python-Plugin.
Des Weiteren gibt es pindent.py, das Python-Quellcode (um)formatiert und
spezielle Blockkommentare der Form "#end <keyword>" zur automatischen
Einrückung verwendet. Es wandelt bspw. diesen (falsch eingerückten) Code
1
def factorial(n):
2
prod = 1
3
for i in range(2, n+1):
4
prod *= i
5
#end for
6
return prod
7
#end def
in diesen (richtig eingerückten) um:
1
def factorial(n):
2
prod = 1
3
for i in range(2, n+1):
4
prod *= i
5
#end for
6
return prod
7
#end def
Das Tool kann diese Blockkommentare in bereits korrekt eingerücktem Code
automatisch einfügen oder entfernen. Da man zusätzlich die gewünschte
Einrücktiefe für den ausgegebenen Code angeben kann, ist es möglich,
Fremdcode automatisch an eigene Einrückrichtlinien anzupassen.
Wer will, kann diese Blockkommentare ständig benutzen und im Editor ein
Kommando definieren, das pindent.py über den getippten Code laufen
lässt. Wenn man dann noch das Syntax-Highlighting so anpasst, dass die
Blockkommentare in der gleichen Farbe wie die Schlüsselwörter erscheinen
und dabei vielleicht sogar noch das '#'-Zeichen ausgeblendet wird, fühlt
es sich so an, als hätte Python eine Fortran-90-ähnliche Blockstruktur.
Ich glaube aber nicht, dass das jemand tatsächlich so macht. Entweder
man freundet sich mit der Strukturierung durch Einrücken an oder nimmt
Ruby :)
Philip K. schrieb:> Weitere Vorschläge für Sprachen?
Ruby habe ich schon genannt. Das ist ähnlich wie Python, nur anders ;-)
Lua gehört ebenfalls in diese Klasse. Es hat weniger, dafür aber
flexibler einsetzbare Sprachelemente und Datentypen als Python und
Ruby.
Du kannst dir auch mal eine Shell-Sprache wie Bash anschauen. Bash sieht
zwar sehr altbacken aus, ist aber sehr viel mächtiger, ale auf den
ersten Blick den Anschein hat. Der Schwerpunkt liegt hier aber weniger
auf der Programmierung von komplexeren Algorithmen, sondern eher darin,
bereits bestehende Programme zu einer größeren Anwendung
zusammenzufügen.
In letzter Zeit verwende ich zur Hilfstoolprogrammierung auch verstärkt
Haskell. Das hört sich vielleicht etwas seltsam an, weil Haskell
eigentlich eher für sehr große Softwareprojekte gemacht ist. Es hat
jedoch zwei wesentliche Eigenschaften mit Python, Ruby, Lua und
Konsorten gemeinsam, die es auch für kleine "Wegwerfprogramme"
interessant machen:
- Programme lassen sich i.Allg. sehr kurz und mit wenig Overhead
schreiben. Oft werden sie sogar noch kürzer als in Python.
- Es gibt einen interaktiven Modus, in dem man mal schnell mal etwas
ausprobieren kann. Man erspart sich damit oft auch das Schreiben eines
konsolebasierten Benutzerschnittstelle.
Einige weitere Vorteile:
- Obwohl man kaum Typ- und sonstigen Deklarationen braucht, ist die
Sprache im Gegensatz zu Python statisch typisiert und das sogar sehr
streng. Dadurch sinkt die Fehleranfälligkeit, wenn die Programme doch
einmal etwas größer werden.
- Wenn das verwendete Algorithmus wider Erwarten für den Interpreter
doch etwas zu rechenaufwendig wird, schickt man den Quellcode einfach
durch den Compiler. Bei Python ist es mir schon oft passiert, dass ich
den angefangenen Code weggeschmissen und ihn noch einmal neu in C oder
C++ geschrieben habe.
Bei all den Vorteilen noch ein Nachteil:
- Haskell ist einfach komplett anders. Man fängt praktisch noch einmal
bei Null an, Programmieren zu lernen. Und je geübter man in einer der
Mainstream-Sprachen ist, umso schwerer fällt der Umstieg ;-)
Unter welchem Betriebssystem willst du diese Scripte primär anwenden?
Ich bin seit ewigen Zeiten unter Windoofs mit Autohotkey unterwegs. Die
Sprache nervt mich zwar mittlerweile ab und zu aber sie leistet trotzdem
immer wieder sehr gute Dienste. Der Sprachwortschatz ist relativ klein
und gut dokumentiert. Zu jedem Befehl gibt es eigentlich ein
Beispielprogrämmchen zum besseren Verständnis. Wenn das nicht reicht,
kann man in der doch recht aktiven Community weiter nachfragen.
Besondere Vorteile von Autohotkey: Simulation von Benutzereingaben
(Mausbewegungen und -klicks, Tastatureingaben), man kann einfache Guis
schnell basteln und die Scripte lassen sich einfach Compilieren.
Letzteres spricht eigentlich gegen das Ziel von Scriptsprachen ABER:
gerade in der Windoofs-Welt sind Interpreter für Python, Perl und Ruby
sehr schlecht vertreten. Oft hacke ich auf Arbeit kleine Scripte für
Kollegen und da will keiner extra einen ganzen Interpreter für effektive
5 Zeilen Code installieren. Allerdings muss ich auch sagen, dass es
vereinzelt Wrapper für die ganzen bekannten Scriptsprachen gibt - jedoch
meist mit Einschränkungen und nicht jeder kann alles.
Was ich mal überlegt hatte: C# als "Scripting-Sprache" zu verwenden.
Allerdings scheitert das bei Visual Studio meist daran, dass immer
Projekte angelegt werden. Damit kann man nicht mal eben eine Datei
zusammenfriemeln.
Yalu X. schrieb:> In letzter Zeit verwende ich zur Hilfstoolprogrammierung auch verstärkt> Haskell.
Hast Du schon mal GTK+ mit Haskell probiert? Oder auch Qt?
Nach Haskell und GTK hatte ich vor längerer Zeit mal gesucht, sah
irgendwie nicht so toll aus, daher hatte ich eher vor, mich mal mit Vala
näher zu beschäftigen, wobei Vala ja stark an GTK und GObject gebunden
ist. Vala, Go, Rust, Scala, Python -- das wären meine aktuellen
Kandidaten, nachdem ich mit dem Lernen von Ruby halbwegs durch bin. Oder
doch mal richtig systematisch C++, damit ich besser mit BOOST und CGAL
klarkomme -- aber C++ ist hässlich, schwierig, und man vergisst es eh
schnell wieder, weil man es dann doch nie verwendet.
Weißt Du wie gut die Python Bindings für CGAL und BOOST sind? Für Ruby
musste ich kürzlich dafür einige Bindings selber schreiben, das ist
wegen all der Templates nicht ganz einfach, wenn man sich nicht wirklich
auskennt mit C++.
>Bei Python ist es mir schon oft passiert, dass ich
>den angefangenen Code weggeschmissen und ihn noch einmal neu in C oder
>C++ geschrieben habe
PyPy soll je recht gut sein. Für Ruby gibt es das auf gleicher
Technologie aufbauende Topaz, aber da tut sich wohl nicht (mehr) viel.
> Weißt Du wie gut die Python Bindings für CGAL und BOOST sind?> Für Ruby musste ich kürzlich dafür einige Bindings selber schreiben,> das ist wegen all der Templates nicht ganz einfach, wenn man sich nicht> wirklich auskennt mit C++.
Schau mal hier:
http://www.swig.org/
Ich stand letztens auch vor der Entscheidung für eine Scriptsprache, und
da ich in C sowie VHDL ganz gut unterwegs bin, hab ich mich auch für
Python entschieden. Der Umsteig geht sehr schnell, erfrischend dass man
so gut wie nix deklarieren muss. Die Sache mit den Einrückungen nervt
halt anfangs etwas. Ich musste mehrere C# DLLs einbinden, das ging mit
IronPython gleich super. Und Visual Studio Tools for Python sind auch
ziemlich klasse, das macht dann bei IronPython sogar Intellisense für
die referenzierten .NET Objekte.
Thomas schrieb:> Schau mal hier:> http://www.swig.org/
Ja und? Swig kenne ich selbstverständlich, dass findet mal ja ganz zu
oberst, wenn man nach C++ Bindings zu CGAL oder BOOST sucht. Mit Swig
Ruby-Bindings für CGAL zu erzeugen ist keinesfalls trivial -- ich habe
von jemandem gelesen (Noel Warr), der sich stark bemüht hatte und auch
auf den Mailinglisten mehrfach nachgefragt hatte, und dann doch
weitgehend gescheitert war. Ist auch irgendwie zu erwarten, mit all den
Templates. Wie das bei Python aussieht weiss ich nicht so genau, daher
hatte ich ja auch bei Yalu nachgefragt, der kennt sich aus.
Hi,
Habe Jahrelang, viel mit Perl gemacht. Man kann sehr schlechten Perl
Code schreiben, aber das geht, wie schon angemerkt, mit vielen Sprachen.
Ich habe C-Shell, Bourne-Shell, Bash usw benutzt. Trotzdem komme ich
immer wieder auf Perl zurück.
Javascript ist nett, aber was fehlt sind die Interfaces für andere
Systeme/APIs. Perl und Python bieten da viel. In CPAN gibt es für fast
alles irgendeine Lösung. Wenn man sich an die Modulvorgaben von CPAN
hält kann man sich auch sehr gut eine Modulbibliothek aufbauen die eine
gute Wiederverwendbarkeit bietet. Dokumentation gehört dann natürlich
auch dazu. Ich bin mit den MAN-Pages immer gut zurecht gekommen.
Mit Python arbeite ich erst seit einem Jahr. Ich habe sehr schnell drauf
gehabt. An das Einrücken gewöhnt man sich auch schnell. Fehleranfällig
ist es meiner Meinung nach nicht.
Perl verwende ich lieber, weil ich es besser beherrsche. Python hat
Vorzüge wenn es darum geht vorkompilierte Versionen zu verwenden, an der
Stelle ist Perl sperrig (geht zwar, ist aber nicht schön).
Meiner Meinung nach sieht Perl-Code mehr nach C aus.
Python sieht eher nach Java Sourcecode aus.
Philip K. schrieb:> Wenn ich mir mal folgenden Codeschnipsel (willkürlich aus einem bei mir> rumliegenden file genommen) anschaue:
Warum nimmst du dir ausgerechnet die schlechten Beispiele?
Wenn du dir dann die IOCCC-Einreichungen ansiehst, dürftest du ja nie
wieder irgendetwas C-ähnliches anfassen. ;-)
Ich habe auch schon in Python schräges Zeug gesehen. Da hatte
nämlich jemand, der die Sprache gut verstanden hat, dann wie da
oben maximal viele Zeichen auf eine Zeile gequetscht. Man muss ja
schließlich optimieren, nicht, dass das dann 10 unnötige
Millisekunden länger dauert. ;-)
Normalerweise würde man aber einfach Zwischenvariablen einführen
(auch, wenn die in einer interpretierten Sprache u. U. etwas an
Laufzeit kosten), und schon ist das wieder übersichtlich.
Perl finde ich von den Syntaxstrukturen viel näher an den
C-ähnlichen Sprachen dran alles alle anderen Scriptsprachen (mit
Ausnahme von JavaScript). Python ist da weiter weg:
1
C:
2
int j = 0;
3
for (int i = 0; i < 42; i++) {
4
j += func(i);
5
}
6
7
Perl:
8
my $j;
9
for (my $i = 0; $i < 42; $i++) {
10
$j += func($i);
11
}
12
13
Python:
14
j = 0
15
for i in range(0, 42):
16
j += func(i)
Philip K. schrieb:> Was mich an Python abschreckt, ist die Tatsache, dass die> Code-Strukturierung über Einrückung erfolgt. Vom Handling gewöhnt man> sich vermutlich daran, aber ich frage mich, ob das nicht arg> Fehleranfällig ist.
Ich finde das auch nicht wirklich toll (einen Einzeiler, direkt auf
der Kommandozeile getippt, kann man damit vergessen), aber es stimmt
schon, man kann damit zurecht kommen. Normalerweise rückt man den
Code ja ohnehin entsprechend ein, egal ob nun C, Perl, Python oder
Shell. Die wirklichen Ärgernisse dabei hat Yalu ganz gut beschrieben.
In die gleiche Kategorie fällt es, wenn du irgendwo aus einem anderen
Script ein Codeschnipsel entnehmen willst, welches sich dort auf
einer anderen Einrückungstiefe befand. In anderen Sprachen könnte
man es danach den Editor (oder ein Tool wie "indent") automatisch
neu einrücken lassen. In Python geht das nicht, weil die Zuordnung
nicht mehr immer eindeutig ist (denn führende Leerzeichen haben eine
syntaktische Relevanz).
Christian R. schrieb:> erfrischend dass man so gut wie nix deklarieren muss.
Naja. In Perl muss man auch nicht, trotzdem ist es üblich, dass man
bei allem, was nicht nur ein "quick hack" ist (den man eine halbe
Stunde später sowieso wieder wegwirft), halt doch lieber sauber
deklariert. Die Programme fangen dann normalerweise an mit
1
use strict;
2
use warnings;
Damit bekommt man für die Benutzung einer nicht deklarierten Variablen
einen Fehler geworfen. Das hilft gut gegen Tippfehler.
Jörg Wunsch schrieb:> Ich habe auch schon in Python schräges Zeug gesehen.
Was ich mich immer noch frage, und was mich neben den Einrückungen, den
dauernden self. und __ anfangs an Python am meisten gewundert hat:
Warum werden oft globale Funktionen wie len(str) usw. verwendet?
Irgendwie passt das doch nicht so recht zur objektorientierten
Programmierung. Bei Ruby ist ja alles ein Object, und entsprechend
werden eigentlich nur Methoden verwendet, also etwa str.length.
1
j = 0
2
(0..42).each{|i|
3
j += func(i)
4
}
hat mir anfangs besser gefallen als Pythons for (das Ruby ja auch in
ähnlicher Form zur Verfügung stellt) und ist mir auch jetzt noch
sympathischer.
Wenn du Javascript magst dann solltest du dir mal node.js anschauen. Es
basiert auf der V8 Engine. Die API ist zwar größtenteils noch nicht
stable aber ich find das bisher schon richtig gut.
http://nodejs.org/
Stefan Salewski schrieb:> Warum werden oft globale Funktionen wie len(str) usw. verwendet?
Man kann sie bequem, in map, filter, etc. verwenden.
Beispiel zum Entfernen von leeren Strings aus einem Tupel:
1
>>> l=("foo", "", "bar")
2
>>> tuple(filter(len ,l))
3
('foo', 'bar')
Ist aber vermutlich nicht der Hauptgrund.
Ohnehin machen einem Elemente aus der funktionalen Programmierung wie,
map, filter und lambdas einem das Leben deutlich einfacher; es muss ja
nicht gleich Haskell sein ;)
Ich mußte mal für ein Projekt Ruby verwenden.
Diese Sprache hat sich als recht mächtig und effizient erwiesen.
Ich mag diese erzwungene Einrückung von Python nicht. Da find ich ein
'end' am Ende des Blockes praktischer.
Für Ruby gibt es auch eine QT-Bibliothek. Die ganze Oberfläche habe ich
dann mit QT gemacht, das lief ganz gut.
Lua habe ich auch einmal verwendet. Die Sprache ist mir aber zu
unflexibel, da fühle ich mich eingeengt.
Ach - noch ein Zusatz.
Ein schlaues Buch meinte einmal, ein Programmierer sollte jedes Jahr mal
eine neue Sprache lernen. Also nimmst du dieses Jahr die eine, und
schaust 2015 noch mal nach etwas anderem.
Noch eine offensichtlich unbeliebtere Variante: MATLAB bzw. Octave.
Warum? Weil ich es kann ;-) bzw. besser kann als den Rest der Sprachen
und ich zu faul bin was neues zu lernen.
Pro: Es sind einige Sachen dabei die man in der µC-Entwicklung öfter mal
braucht und die Sprache steht mir persönlich nicht im Weg.
Contra: Bindings für externe Bibliotheken sind eher Mangelware. GUI nur
mit MATLAB.
Stefan Salewski schrieb:> Hast Du schon mal GTK+ mit Haskell probiert? Oder auch Qt?
Kaum, aus zwei Gründen:
1. Es fehlt mir die Motivation, überhaupt irgendwelche GUIs selbst zu
programmieren. Das ist für mich neben Datenbankandwendungen so
ziemlich das Langweiligste, was man programmieren kann ;-)
2. Es gibt eine ganze Reihe von Wrapper-Bibliotheken für die
einschlägigen GUI-Toolkits:
http://www.haskell.org/haskellwiki/Applications_and_libraries/GUI_libraries
Aber mit welcher beginnen? Ich könnte einige der meistversprechenden
Bibliotheken heruntarladen und der Reihe nach ausprobieren, aber
jedesmal, wenn ich damit beginne, schlägt Punkt 1 zu.
Insgesamt scheint die Entwicklung von GUI-Bibliotheken für Haskell
ziemlich zäh voranzuschreiten. Das ist eigentlich schade, denn gerade
die im obigen Link unter "High-level" genannten Projekte scheinen
eine Menge Struktur in die GUI-Programmierung zu bringen, die ich bei
den derzeitigen Vorgehensweisen (dort als "Medium-level" bezeichnet)
stark vermisse.
> Weißt Du wie gut die Python Bindings für CGAL und BOOST sind?
CGAL kenne ich kaum und benutze ich nicht, BOOST hin und wieder schon.
Aber was willst du mit BOOST in Python oder Ruby? Ein Großteil der
BOOST-Bibliotheken dient doch nur dazu, Features für C++ verfügbar zu
machen, die in Python auch ohne zusätzliche Bibliotheken ganz
selbstverständlich sind.
> Für Ruby musste ich kürzlich dafür einige Bindings selber schreiben,> das ist wegen all der Templates nicht ganz einfach, wenn man sich> nicht wirklich auskennt mit C++.
Gerade solche Dinge, die in C++ fast nur aus riesigen Template-Gräbern
bestehen, schreibt man in Python oder Ruby oft mit wenig Aufwand neu.
> PyPy soll je recht gut sein. Für Ruby gibt es das auf gleicher> Technologie aufbauende Topaz, aber da tut sich wohl nicht (mehr) viel.
Ja, das sollte ich mir mal etwas genauer ansehen.
Yalu X. schrieb:> CGAL kenne ich kaum und benutze ich nicht, BOOST hin und wieder schon.> Aber was willst du mit BOOST in Python oder Ruby? Ein Großteil der> BOOST-Bibliotheken dient doch nur dazu, Features für C++ verfügbar zu> machen, die in Python auch ohne zusätzliche Bibliotheken ganz> selbstverständlich sind.
Von CGAL hatte ich kürzlich die "Constrained Delaunay Triangulation"
benötigt -- so etwas schreibt man nicht mal eben selber. Zunächst hatte
ich dazu die GTS library verwendet, war damit aber auch nicht wirklich
glücklich. Und von Boost hatte ich die Fibonacci-Queue verwendet -- kann
man natürlich auch in Ruby machen, aber das macht wenig Sinn, denn
Einfügen und Decrease_Key sollen ja möglichst schnell sein. Gut, für
Python hätte es wohl eine schnelle Priority-Queue gegeben, und selbst
für Ruby gibt es eine, die aber seit 2005 nicht mehr angefasst wurde,
und der Autor ist wohl verschollen. Da ich für CGAL eh was schreiben
musste hatte ich dann Boost gleich mit erledigt. Beides war übrigens für
meinen experimentellen toplologischen Router.
Für interpretierte Sprachen wie Ruby oder Python wird man wohl stets C
oder C++ Bibliotheken benötigen, etwa im Bereich Nummerische Mathematik.
Es sei denn man will es sich antun direkt mit C oder C++ zu arbeiten.
Pythons unterstützung ist da wohl schon besser, Boost_Python existiert
jedenfalls, NumPy und Mathplotlib sollen ja sehr gut sein. Das wäre für
mich schon ein Grund, nach Ruby doch noch zusätzlich richtig Python zu
erlernen.
>> Hast Du schon mal GTK+ mit Haskell probiert? Oder auch Qt?>Kaum, aus zwei Gründen:>1. Es fehlt mir die Motivation, überhaupt irgendwelche GUIs selbst zu> programmieren. Das ist für mich neben Datenbankandwendungen so> ziemlich das Langweiligste, was man programmieren kann ;-)
Ja, langweilig ist das schon etwas, wobei Ruby + GTK eigentlich schon
Spaß macht. Und eine Gute GUI braucht man für viele Sachen einfach.
Lukas K. (Firma: carrotIndustries) (carrotindustries) schrieb
>Datum: 07.09.2013 01:16>Stefan Salewski schrieb:>> Warum werden oft globale Funktionen wie len(str) usw. verwendet?>Man kann sie bequem, in map, filter, etc. verwenden.>Beispiel zum Entfernen von leeren Strings aus einem Tupel:
Danke für den Hinweis, ich werde mal drüber nachdenken.
Yalu X. schrieb:> 2. Es gibt eine ganze Reihe von Wrapper-Bibliotheken für die> einschlägigen GUI-Toolkits:>> http://www.haskell.org/haskellwiki/Applications_and_libraries/GUI_libraries>> Aber mit welcher beginnen?
Das ist die Frage -- einige wie die Fruit Homepage lassen sich gar erst
aufrufen.
Das meiste ist wohl sehr experimentell, damit kann man viel Zeit vertun.
(Ich hatte vor langer Zeit mal die Oberon GUI der ETH Zürich mit der
Sprache Oberon verwendet, und auch noch die Nachfolger GUI mit dem Namen
BlueBottle -- aber wenn der Doktorand, der dafür Hauptverantwortlich
ist, dann fertig ist, dann hat sich das meist erledigt.)
Salewski, Stefan schrieb:> Das meiste ist wohl sehr experimentell, damit kann man viel Zeit vertun.
Bleibt die Frage, warum man sich solche Exoten überhaupt antun sollte.
Ich meine kann ja jeder machen was er will, und Interesse, Geek-Faktor
oder akademische Selbstbefriedigung mögen ja alles gute Gründe sein.
Aber mit Anfang 30 sollten doch die meisten darüber hinweg sein, und im
industriellen Alltag spielen solche Dinge eh keine Rolle.
Nichts gegen Haskell, nur in freier Wildbahn ist mir das noch nie
begegnet.
Jetzt fällt mir die Entscheidung fast noch schwerer :)
Ein Kriterium das ich vergessen habe zu erwähnen ist, dass die Sprache
unbedingt objektorientiert sein sollte.
Mein Favorit wäre was die Syntax angeht weiterhin ECMA/Javascript. Wie
weiter oben beschrieben wurde fehlen hier aber tatsächlich Interfaces
für Grundlegende Sachen. Gut, man könnte sich mit Qt einen eigenen
Interpreter bauen, da die ScriptEngine bereits existiert und man
prinzipiell jede von QObect abgeleitete Klasse im Script verfügbar
machen kann. Leider ist das aber ziemlich viel Arbeit. Mich wundert aber
schon, dass noch keiner auf die Idee gekommen ist, sowas wie PyQt für
ECMAScript umzusetzen.
Ich denke mal für mich wirds auf Python hinauslaufen. Bei Ruby gefällt
mir zwar die Syntax besser aber ich habe gelesen, dass es für Python
deutlich mehr "Zubehör" gibt. Falls ich mit der Einrückung nicht zurecht
kommen sollte kann ich ja immer noch wechseln...
Irgendeine exotische Sprache möchte ich eher nicht lernen...
Jörg Wunsch schrieb:> Ich habe auch schon in Python schräges Zeug gesehen. Da hatte> nämlich jemand, der die Sprache gut verstanden hat, dann wie da> oben maximal viele Zeichen auf eine Zeile gequetscht. Man muss ja> schließlich optimieren, nicht, dass das dann 10 unnötige> Millisekunden länger dauert. ;-)
Richtig schräg fand ich den Code von decompyle, ein in python
geschriebener Decompiler, der also aus Python-Bytecode wieder den
Quellcode macht. So richtig hab ich den Code nie verstanden.
Jörg Wunsch schrieb:> Perl finde ich von den Syntaxstrukturen viel näher an den> C-ähnlichen Sprachen dran alles alle anderen Scriptsprachen (mit> Ausnahme von JavaScript).
Dann schau dir mal awk an. Das ist sehr C-nah.
> Python:> j = 0> for i in range(0, 42):> j += func(i)
Ich empfehle dringend xrange() statt range().
Rolf Magnus schrieb:>> Python:>> j = 0>> for i in range(0, 42):>> j += func(i)>> Ich empfehle dringend xrange() statt range().
Ist in python3 hinfällig geworden. range verhält sich so wie xrange in
python2
Das obige Beispiel ist allerdings nicht der schönste Weg ein solches
Problem zu lösen
Thomas schrieb:> Salewski, Stefan schrieb:>> Das meiste ist wohl sehr experimentell, damit kann man viel Zeit vertun.>> Bleibt die Frage, warum man sich solche Exoten überhaupt antun sollte.
Es gibt ja noch andere Computeranwendungen als GUIs. Wie schon
geschrieben, ist der GUI-Support von Haskell tatsächlich nicht so toll.
Wenn ich mal ein GUI für ein selbst geschriebenes Programm brauche,
werde ich es mit Gtk2Hs und vielleicht noch mit WxHaskell versuchen. Zu
Gtk2Hs gibt es im Buch "Real World Haskell" ein eigenes Kapitel, somit
wird es nicht ganz so schlecht sein.
http://hackage.haskell.org/packages/archive/pkg-list.html> Ich meine kann ja jeder machen was er will, und Interesse, Geek-Faktor> oder akademische Selbstbefriedigung mögen ja alles gute Gründe sein.> Aber mit Anfang 30 sollten doch die meisten darüber hinweg sein, und im> industriellen Alltag spielen solche Dinge eh keine Rolle.
Natürlich ist Haskell noch Lichtjahre entfernt vom Mainstream. Im
industriellen Alltag spielen eigentlich nur C, C++ eine wesentliche
Rolle, in der Web-Branche zusätzlich noch Java und einige
Skriptsprachen. Für alle anderen Sprachen gibt es zwar Beispiele, wo
auch sie industriell eingesetzt werden, die gibt es aber auch für
Haskell:
http://www.haskell.org/haskellwiki/Haskell_in_industry
Ich habe gerade eine repräsentative und wissenschaftlich fundierte
Studie zur industriellen Relevanz der gängigen Programmiersprachen
durchgeführt.
Siehe Anhang.
Zu Ruby ist noch erwähnenswert, dass sich dessen Relevanz zu 95% durch
Rails begründet.
Quelle: http://www.jobworld.de/
Ach ja, mehr als 10000 Stellen werden leider nicht angezeigt, deswegen
ist die wahre Relevanz von Java und C nicht feststellbar.
Interessant wäre es diese Studie jährlich zu wiederholen um Trends zu
erkennen.
Ich denke der große Gewinner der letzten Jahre wäre JavaScript.
Thomas schrieb:> Ach ja, mehr als 10000 Stellen werden leider nicht angezeigt, deswegen> ist die wahre Relevanz von Java und C nicht feststellbar.>> Interessant wäre es diese Studie jährlich zu wiederholen um Trends zu> erkennen.>> Ich denke der große Gewinner der letzten Jahre wäre JavaScript.
Da tauchen anscheinend eine ganze Reihe von Jobs und min. eine
Programmiersprache nicht auf... F#
Was auch zum skripten genutzt werden kann (F# interactive)
http://www.itjobswatch.co.uk/jobs/uk/fsharp.do (da gibt's auch zu den
anderen Sprachen mehr Informationen zu Gehältern, Trends etc.)
Schon eine Weile her und ich hab immer noch nichts gelernt...:)
Jetzt ist mir noch eine andere Idee gekommen. Da ich beruflich immer
mehr mit Linux zu tun und mir gerade ein Buch über Shell-Programmierung
zugelegt habe - was haltet Ihr alternativ zu Python&Co von
Shell-Scripten? Unter Windows dann halt mit Cygwin.
Stefan Rand schrieb:> Abstand.
Und zwar ganz weit! Wenn man strukturierte Programmier-/Scriptsprachen
kennt, rollen sich einem da die Fußnägel. Klar, für schnell mal was in
der Linux Konsole machen OK, aber das wars dann auch.
pks schrieb:> Na wenn da nicht mal irgendwelche Linux-Gurus empört widersprechen
Das werden sie ganz sicher. Denn da ist ja der Weg das Ziel.
...schnell weg... :)
als Softwareentwickler im Embedded bereich habe ich python lieben
gelernt
Nachteile:
- Intepreter Fehlermeldungen sind oft nicht besonders aussage kräftig
- durch die mächtigkeit kann es sehr komplex werden (gilt wohl für jede
Sprache)
Geschmackssache:
- Erzwungene Einrückungen
- code ist in textform verfügbar und schwer "copySafe" zu machen
Vorteile:
- sinnvolle Mischung aus objekorientiert und funktional
- sehr viele vorgerfertigte libs
- sehr gute doku
- läuft auf sehr vielen Plattformen
- für mich hat sich als ein ganz besonders großer Vorteil erwiesen,
dass es auch Implementierungen für Java (JPython) und .Net(IronPython)
gibt. Dadurch ist man in der Lage native auf libs von Java oder .Net
direkt zuzugreifen, mit dem python gewohnten Komfort
- sehr mächtig: man kann direkt auf die ganzen metha daten von Klassen,
Methoden etc. zugreifen. Mit MagicMembers und Decoraters kann man sehr
einfach vorhandene funktionen erweitern. z.B. wollte ich im nachhinein
für protokolierungszwecke ein tracing meines python Programms
implementieren. Jetzt hätte ich jede Methode noch mal anfassen können
und diese um trace ausgaben erweitern oder ich habe in ein paar zeilen
python code, einen decorator geschrieben der genau das macht und das
original programm belassen wie es ist.
anderes Beispiel.: ich habe meinen code fein säuberlich kommentiert, ich
war aber zu faul für die eigentliche doku das ganze nochmal zu
schreiben. Durch ein paar zeilen python code konnte ich alle Klassen-,
Funktionsnamen und die dazu gehörigen Komentare einfach extrahieren und
damit meine doku ohne zusätzliche tools wie doxygen einfach generieren.
kleiner tipp, für eclipse gibt es ein tolles plugin "PyDev" das einem
z.B. das Einrücken abnimmt und man kann damit wie gewohnt mit
breakpoints debuggen
Philip K. schrieb:> was haltet Ihr alternativ zu Python&Co von Shell-Scripten?
Alternativ zu einer richtigen Scriptsprache: nein.
Muss man kennen und können: auf jeden Fall. Aber dann bitte auf die
Features konzentrieren, die von Posix genormt worden sind. Wenn man
eine nicht-bash als Shell zum Testen nimmt, ist das eine ganz
brauchbare Prüfung. Nichts ist schlimmer, als wenn sich portabel
wähenende Shellscripte ausgiebigst vom creeping featurism der Bash
Gebrauch machen, egal ob das nun gerade Sinn hat oder nicht.
Shell ist halt (auf Unixen) überall da, insofern muss man das einfach
können, und viele einfache Abläufe im täglichen Unix-Leben lassen sich
damit prima automatisieren. Aber sowie das Ding komplexer wird, kann
Shell schnell der Horror schlechthin werden.
> Perl und TCL sind jedenfalls schon mal keine Option, da ich die Syntax> als grausig empfinde.
Schade, ebendiese wollte ich gerade empfehlen. Genau wegen dieser
kryptischen Aura. Wer will schon Code, den jeder lesen kann ;-)
> wo ist denn der Syntax von Perl so großartiung unterschiedlich zu C++?
Wir zwei sollten uns mal über reguläre Ausdrücke unterhalten. Dann wird
dir schnell klar, was die große Stärke von Perl ist.
> Es gibt zwar in Perl sehr viele Möglichkeiten etwas zu schreiben. Aber> man kann es ebend auch sehr C ähnlich schreiben. Es gibt halt nur keine> Datentypen.
Das stimmt nicht. Es gibt nur nicht viele: Skalare, Felder und Hashes.
Herr Tickl Pöörl schrieb:> Dann wird dir schnell klar, was die große Stärke von Perl ist.
Das wurde alles vor zwei Monaten durchgekaut, und muss jetzt nicht
neu aufgerollt werden.
Philip hatte lediglich eine Zusatzfrage zu seinem alten Thread.
Ich bin zwar noch kein richtiger programmierer aber auf dem weg (1sem,
Informatik), das ganze hier hat mich neugiereig gemacht und würde gerne
wissen wofür ihr die Scriptsprache in euerem täglichen Job braucht
(Beispiele)?
Jörg Wunsch schrieb:> Herr Tickl Pöörl schrieb:>> Dann wird dir schnell klar, was die große Stärke von Perl ist.>> Das wurde alles vor zwei Monaten durchgekaut, und muss jetzt nicht> neu aufgerollt werden.>
Da muss ich widersprechen. Über reguläre Ausdrücke, die ja gerade die
Stärke von Perl ausmachen, wurde eben NICHT gesprochen.
Herr Tickl Pöörl schrieb:> Jörg Wunsch schrieb:>> Herr Tickl Pöörl schrieb:>>> Dann wird dir schnell klar, was die große Stärke von Perl ist.>>>> Das wurde alles vor zwei Monaten durchgekaut, und muss jetzt nicht>> neu aufgerollt werden.>>> Da muss ich widersprechen. Über reguläre Ausdrücke, die ja gerade die> Stärke von Perl ausmachen, wurde eben NICHT gesprochen.
Wo ist denn die Stärke? Reguläre Ausdrücke bekomme ich doch in jeder
Programmiersprache.
Das Thema Reguläre Ausdrücke finde ich tatsächlich auch interessant.
Leider verhält es sich damit ähnlich wie mit der Linux-Shell oder dem
Vi-Editor - sicher toll und mächtig wenn mans kann, aber eine hohe
Einstiegs-Hemmschwelle. Aber Unterstützung für reguläre Ausdrücke gibt
es sicher auch in Python, oder? Nur eben nicht nativ als Teil der
Sprache.
Martin schrieb:> Ich bin zwar noch kein richtiger programmierer aber auf dem weg (1sem,> Informatik), das ganze hier hat mich neugiereig gemacht und würde gerne> wissen wofür ihr die Scriptsprache in euerem täglichen Job braucht> (Beispiele)?
Python für dreckige Hacks... ;-)
Martin schrieb:> Ich bin zwar noch kein richtiger programmierer aber auf dem weg (1sem,> Informatik), das ganze hier hat mich neugiereig gemacht und würde gerne> wissen wofür ihr die Scriptsprache in euerem täglichen Job braucht> (Beispiele)?
Ich nutze Python als Skriptsprache um in Linux in der Bash mir eben
kleine Skripte zur Automatisierung verschiedener Prozesse zu schreiben.
D.h. ich habe eine Simulationsprogramm, dass eine Parameterdatei als
Input hat und etliche Dateien mir ausgibt. Das Erstellen,
Zusammenführen, ... sowie das Aufbereiten der Output-Daten werden bei
mir mittels Python Skripte gemacht.
Zwar finde ich die Sprache verglichen mit C an sich hässlich und
ungeeignet für größere Vorhaben, da man sehr leicht Fehler einbauen kann
die man nur sehr schwer findet (man braucht auf jedenfall einen
geeigneten Editor um die Einrückungen nicht zu versauen).
Dafür ist sie eben sehr einfach zu benutzen, recht intuitiv, gut lesbar
und dank regulärer Ausdrücke ideal für mein Vorhaben Daten
aufzubereiten.
Zum lernen von Python innerhalb ein oder zwei Tage fine ich dieses
Tutorial perfekt da es sich auf die wichtigen Dinge konzentiert:
https://developers.google.com/edu/python/
pks schrieb:> Das Thema Reguläre Ausdrücke finde ich tatsächlich auch interessant.> Leider verhält es sich damit ähnlich wie mit der Linux-Shell oder dem> Vi-Editor - sicher toll und mächtig wenn mans kann, aber eine hohe> Einstiegs-Hemmschwelle. Aber Unterstützung für reguläre Ausdrücke gibt> es sicher auch in Python, oder? Nur eben nicht nativ als Teil der> Sprache.
Die Einstiegsschwelle ist in der Tat sehr hoch, da stimme ich dir
vollkommen zu. Ein komplexer regulärer Ausdruck ist für
"Nicht-Eingeweihte" wahrscheinlich Horror pur.
Um auf die Frage von Bernd (n. t. B.) eingehen, mir ist keine Sprache
bekannt, die reguläre Ausdrücke in dem Maß unterstützt, wie Perl.
Immer wenn es darum geht, komplexe Muster in Texten zu suchen sind
reguläre Ausdrücke unschlagbar. Und in keiner anderen Sprache geht das
formulieren so einfach, wie in Perl. Zugegebenermaßen geht es allerdings
auf Kosten der Lesbarkeit.
@Bernd (n. t. B.): Ich lerne ja gerne dazu, welche Sprache unterstützt
dies, wie Perl?
Fluke schrieb:> Ich lerne ja gerne dazu, welche Sprache unterstützt> dies, wie Perl?
Python bspw.? Ich kenne Perl nicht, aber denke da ist wenig Unterschied:
http://www.johndcook.com/python_regex.htmlhttps://developers.google.com/edu/python/regular-expressions
ansonsten frage ich mich auch, was die Aussage von Bernd soll, denn in
typischen Hochsprachen muss man sich das über Stringfunktionen alles
selber zusammenfrickeln, was deutlich aufwendiger und umständlicher ist,
als ein Einzeiler der sucht, findet und ersetzt, was immer man will.
Philip K. schrieb:> ... - was haltet Ihr alternativ zu Python&Co von> Shell-Scripten?
Ich hasse es Shell-Scripte zu schreiben, aber ich nutze es oft.
Ruby treibt mich auch immer wieder zum Wahnsinn, aber ich würde mich
eigentlich gerne damit tiefer beschäftigen.
Perl und Python habe ich mir zwar mal angeeignet, aber ich nutze es
nicht. Vllt. mal ein Script abändern, aber mehr auch nicht.
Lua ist auch ganz nett und lässt sich sehr leicht in ein Programm
einbinden.
Wenn Du nicht etwas spezielles damit vor hast, dann ist die Wahl (fast)
egal.
Bernd (n. t. B.) schrieb:> Reguläre Ausdrücke bekomme ich doch in jeder Programmiersprache.
Ja, allerdings sind sie in Perl zugegebenermaßen besonders einfach
handhabbar.
Also versteh' mich recht, REs sind immer “write-only” :), das liegt
in der Natur der Sache. In Perl ist die ganze RE-Mimik aber als
Operator „eingebaut“ in die Sprache, in Python ist es ein Modul wie
jeder andere, von dem ich erst eine Instanz eines RE-Objekts anlegen
muss etc. pp.
Martin schrieb:> würde gerne wissen wofür ihr die Scriptsprache in euerem täglichen Job> braucht (Beispiele)?
Für alles, wo's ein simpler Shell-Script nicht mehr tut. ;-)
Jörg Wunsch schrieb:>> Reguläre Ausdrücke bekomme ich doch in jeder Programmiersprache.>> Ja, allerdings sind sie in Perl zugegebenermaßen besonders einfach> handhabbar.
In Ruby sind sie auch in der Sprache eingebaut (und auch sehr einfach
nutzbar).
Python ist prima. Ich weiss nicht wie das inzwischen ist, aber Arrays
waren immer mehr oder weniger ein Problem.
Zu Perl: Ich habe es versucht. Vielleicht liegt es auch die Literatur.
Ich habe keine Anleitung/Buch gefunden (habe aber auch bald aufgegeben),
wo nicht alles vollkommen zufällig erscheint und die Sprache sehr
unstrukturiert erklärt wird.
Ich habe es auf die Sprache geschoben, aber vielleicht ist dem gar nicht
so.
Gute Literatur?
Um mal ein extremes Beispiel zu haben:
http://krum.rz.uni-mannheim.de/perl-tut.html
dadada schrieb:> Python ist prima. Ich weiss nicht wie das inzwischen ist, aber Arrays> waren immer mehr oder weniger ein Problem.
Und noch so einer der in Rätseln spricht.
Martin schrieb:> Ich bin zwar noch kein richtiger programmierer aber auf dem weg (1sem,> Informatik), das ganze hier hat mich neugiereig gemacht und würde gerne> wissen wofür ihr die Scriptsprache in euerem täglichen Job braucht> (Beispiele)?
bash/sed/awk: Einzelne Kanäle aus großen Messdatenmengen (5 Mio
Messwerte, 400 Kanäle, ASCII) herausfischen.
Kollegen teilen die Messdaten in Dateien mit maximal 150000 Werten auf
und sortieren das dann mit Excel - dauert auch "nur" eine halbe Stunde
zum Öffnen und eine weitere halbe Stunde zum Schließen. Pro 150000
Werte, versteht sich, also >3 Arbeitstage für die 5 Mio Messwerte.
MfG, Arno
Arno schrieb:> bash/sed/awk: Einzelne Kanäle aus großen Messdatenmengen (5 Mio> Messwerte, 400 Kanäle, ASCII) herausfischen.
Das würde ich heute aber eher mit Ruby machen, oder menetwegen Python,
Perl...
Ich hatte mich früher schon mit awk abgemüht um Messdatensätze zu
bearbeiten. Für ganz einfache Sachen ging es noch ganz gut, für etwas
schwierigere Sachen war es dann schon sehr kniffelig -- ich wess jetzt
nicht mehr ob ich fragen musste oder es selbst hinbekommen habe,
jedenfalls habe ich das Script dann nach ein paar Monaten selbst nicht
mehr verstanden. Mit sed und bash geht es mir heute auch oft so.
Bash/sed/awk wenn das Script dort laufen soll, wo andere Sprachen nicht
verfügbar sein könnten, oder wenn es eben wirklich ganz triviale
Operationen sind.
Stefan Salewski schrieb:> oder wenn es eben wirklich ganz triviale Operationen sind.
Ja, sowas wie
1
awk 'FNR>1 {print $2}'
um aus einer Menge von Zeilen ab der 2. Zeile jeweils die zweite Spalte
auszugeben. Dafür würde ich kein Perl oder Python oder sowas erst
anwerfen. Wenn ich beispielsweise wissen will, welche UIDs alle gerade
Prozesse auf meinem System laufen haben:
1
$ ps alx | awk 'FNR>1 {print $2}' | sort -u
2
0
3
1
4
1000
5
101
6
102
7
104
8
107
9
110
10
114
11
115
12
117
13
13
14
65534
Ja, kann man auch alles in einer Scriptsprache machen, daber dafür sind
die Bordmittel schnell und einfach genug zu handhaben.
dadada schrieb:> Was soll das denn?> Um die beim Rätseln zu helfen:> http://www.i-programmer.info/programming/python/3942-arrays-in-python.html> aber wie gesagt, das kann inzwischen alles besser sein.
Ich sehe da jetzt auf den ersten Blick kein Problem.
In Ruby funktionieren Arrays sehr gut, und ich habe nie gehört dass es
in Python schlechter funktionieren würde.
Wobei Python eben den Ausdruck List verwendet. Vielleicht meinst du
mehrdimensionelle Arrays -- in Ruby werden die nicht direkt unterstützt,
man muss also etwa A[i][j] schreiben. Ist ja aber auch nicht tragisch.
´Fluke schrieb:> Um auf die Frage von Bernd (n. t. B.) eingehen, mir ist keine Sprache> bekannt, die reguläre Ausdrücke in dem Maß unterstützt, wie Perl.> Immer wenn es darum geht, komplexe Muster in Texten zu suchen sind> reguläre Ausdrücke unschlagbar. Und in keiner anderen Sprache geht das> formulieren so einfach, wie in Perl.
Welche Unterstützung meinst du konkret? Die Syntax der Regexes ist ja
immer ähnlich, die meisten Programmiersprachen bzw. Bibliotheken (bspw.
auch Python) lehnen sich syntaxmäßig ohnehin an Perl an. Ganz nett ist
die Möglichkeit in Perl, Regexes mit dem Infix-Operator =~ auszuwerten,
was meist etwas Tipparbeit einspart und oft auch die Übersichtlichkeit
etwas erhöht. Den =~-Operator hast du aber bspw. in Haskell auch, obwohl
dort die Regex-Funktionen nicht zum eigentlichen Sprachumfang gehören,
sondern als Bibliothek (von denen man so an die 10 zur Auswahl hat :))
eingebunden werden.
dadada schrieb:> Python ist prima. Ich weiss nicht wie das inzwischen ist, aber Arrays> waren immer mehr oder weniger ein Problem.
Ähnlich wie Stefan kann auch ich nicht ganz verstehen, wo da ein Problem
liegt.
dadada schrieb:> Um die beim Rätseln zu helfen:> http://www.i-programmer.info/programming/python/3942-arrays-in-python.html> aber wie gesagt, das kann inzwischen alles besser sein.
In diesem Artikel steht geschrieben:
"Python doesn't have a native array data structure, but it has the
list which is much more general and can be used as a multidimensional
array quite easily."
Frei übersetzt: Die Listen in Python sind wie Arrays, nur viel besser.
Von Problemen, Python-Listen anstelle von Arrays zu verwenden, ist in
dem Artikel keine Rede.
Letztendlich ähneln ja die Python-Listen, was ihre interne Darstellung
betrifft, sehr viel mehr den Arrays als den Listen in anderen Sprachen.
Herr Tickl Pöörl schrieb:> Wir zwei sollten uns mal über reguläre Ausdrücke unterhalten. Dann wird> dir schnell klar, was die große Stärke von Perl ist.
Einen großen Teil der Fähigkeiten von Perls regulären Ausdrücken gibt es
auch als Library, die sich in C/C++ verwenden lässt: PCRE
http://www.pcre.org/Martin schrieb:> wofür ihr die Scriptsprache in euerem täglichen Job braucht
Shell (/bin/sh, keine bash) für einfache Sachen, die keine/wenig Prüfung
auf Fehler benötigen. Als Wrapper für Applikationen, die ein spezielles
Environment benötigen und dabei das .profile nicht versauen sollen.
Makefiles bei Abhängigkeiten, die sich damit formulieren lassen. Ist
zwar keine Scriptsprache, aber trotzdem sehr nützlich.
Perl für nicht ganz so einfachen Abläufe, fürs Datensammeln und
-auswerten, für kleine und mittlere GUIs, für Datenbankabfragen und
Ausgabeaufbereitung, im Web-Server als mod_perl. Auch zum prototypen von
Algorithmen, bevor diese dann in C umgesetzt werden.
Yalu X. schrieb:> Die Syntax der Regexes ist ja> immer ähnlich, die meisten Programmiersprachen bzw. Bibliotheken (bspw.> auch Python) lehnen sich syntaxmäßig ohnehin an Perl an. Ganz nett ist> die Möglichkeit in Perl, Regexes mit dem Infix-Operator =~ auszuwerten,> was meist etwas Tipparbeit einspart und oft auch die Übersichtlichkeit> etwas erhöht.
Ich denke schon, dass er darauf hinaus wollte. Ist ja noch mehr als
der Infix-Operator. Die nach einem RE match (oder substitute) sofort
via $1 ... $<N> zur Verfügung stehenden submatches finde ich auch
sehr viel handlicher zu benutzen als die Variante über eine Methode
zum RE-Objekt in Python. Python lehnt sich hier meiner Meinung nach
recht stark an das (ähnlich umständlich zu handhabende) C-API der
regexp-Bibliothek an.
Wenn ich irgendwo viel mit REs herumopern muss, würde ich daher eher
zu Perl greifen als zu Python. Python wiederum wäre dann meine
bevorzugte Wahl, wenn vielleicht irgendeine der dort zahlreichen
Bibliotheken irgendeine andere Aufgabe recht einfach lösen lässt.
Die von vielen als abschreckend beschworene ach so schreckliche Syntax
von Perl muss man ja für sich nicht in ach so schrecklicher Form zur
Anwendung bringen. ;-) In Perl darf man halt, solange es eindeutig
ist, immer die Klammern bei Funktionsaufrufen weglassen (aber man darf
sie auch immer schreiben, wenn man das übersichtlicher findet), während
uns allein ein derartiges (Mis?)Fietscher bei Python eine zwischen den
Protagonisten und Gegnern scheinbar unüberwindbare Hürde zwischen zwei
Python-Versionen nur wegen einer print-Funktion beschert hat, die man
einmal mit und einmal ohne Klammern aufrufen muss …
Yalu X. schrieb:> Wenn man zu Debug-Zwecken schnell eine if-Zeile auskommentieren möchte,> um den nachfolgenden Code bedingungslos auszuführen, muss man diesen> eine Ebene ausrücken, damit Python nicht meckert. Ist man mit Debuggen> fertig und kommentiert die if-Zeile wieder ein, muss der nachfolgende> Code wieder eingerückt werden. Ich behelfe mir in solchen Fällen meist> dadurch, dass ich die if-Zeile stehen lasse und der Bedingung ein "1 or"> voranstelle.
Ich füge immer ein "or True" hinzu, damit sollte die if Zeile
unschädlich gemacht worden sein. Man muss natürlich dann auf Präcedenzen
achten, also
[code]
if a and b:
print "code"
[code]
wird dann zu
[code]
if (a and b) or True:
print "code"
[code]
Ich stand vor Äonen mal vor der Frage, welche Sprache(n) für Kleinkram
und komplexere Shell-Scripte in den diversen Betriebssystemen für mich
in Frage kam. Die Unix-Shells flogen schlicht deshalb raus, weil damals
nur in Unix verfügbar. Perl gabs überall, egal ob OS/2, Windows, Unix
und Linux. Bzw. gab es dann überall, denn der OS/2-Port war Eigenbau.
Insofern wars einfach, die Auswahl war ohnehin nicht so immens gross.
Heute hat man das Problem, dass es eine riesige Auswahl in Frage
kommender Sprache gibt. Und mit jedem zweiten Antworter auf eine solche
Frage kommt eine neue hinzu. Je länger man also laut drüber nachdenkt,
desto schwieriger wird die Entscheidung. ;-)
Hallo,
Stefan Salewski schrieb:> Jörg Wunsch schrieb:>> Ich habe auch schon in Python schräges Zeug gesehen.
Man kann in jeder Programmiersprache schräges Zeug schreiben. Aber
Python macht es einem vergleichsweise schwer.
> Was ich mich immer noch frage, und was mich neben den Einrückungen, den> dauernden self. und __ anfangs an Python am meisten gewundert hat:>> Warum werden oft globale Funktionen wie len(str) usw. verwendet?> Irgendwie passt das doch nicht so recht zur objektorientierten> Programmierung.
Aber natürlich. Für len() gibt es eigens ein Standard-Interface, das
alle Array-Typen haben: __len__(). Das kannst Du natürlich auch
benutzen: len(string) ist äquivalent zu string.__len__().
1
class obj(object):
2
def __len__(self):
3
return 8
4
o = obj()
5
print len(o)
6
print o.__len__()
Eigentlich ist das eines von vielen nifty features von Python.
LG,
Karl
Karl Käfer schrieb:> Man kann in jeder Programmiersprache schräges Zeug schreiben. Aber> Python macht es einem vergleichsweise schwer.
Nur, wenn man es durch die Python-Brille sieht. ;-) Ich habe da auch
schon genügend "coolen Code" gesehen, bei denen der Autor unbedingt
seine Mikrooptimierungen schon in den Code einbauen musste. Das
Ergebnis ist dann etwas, was für jemanden, der nicht ganz so flüssig
in den allerletzten Features der Programmiersprache ist, wie völlig
unlesbarer Kauderwelsch aussieht.
Selbstverständlich ist derjenige völlig felsenfest davon überzeugt,
dass die Syntax von Perl absolut schrecklich ist, und man Perl-Code
prinzipiell nicht lesen kann. :-)
Jörg Wunsch schrieb:> Selbstverständlich ist derjenige völlig felsenfest davon überzeugt,> dass die Syntax von Perl absolut schrecklich ist
Sie ist schrecklich. Sagt einer, der seit zig Jahren darin
programmiert. Aber C finde ich schliesslich auch schrecklich. :-)
Stefan Salewski schrieb:> Arno schrieb:>> bash/sed/awk: Einzelne Kanäle aus großen Messdatenmengen (5 Mio>> Messwerte, 400 Kanäle, ASCII) herausfischen.>> Das würde ich heute aber eher mit Ruby machen, oder menetwegen Python,> Perl...
Ich glaube dir gerne, dass jemand, der andere Skriptsprachen beherrscht,
für die Aufgabe sinnvollerweise eine andere wählt.
Ich kann ein wenig bash/sed/awk, dafür weder Ruby noch Python noch Perl,
daher war die Frage, was ich für diese Aufgabe nehme, recht einfach...
(und bash/sed/awk war mit Cygwin mitinstalliert, perl/python/ruby
nicht).
In Zukunft wird das vermutlich bei uns in Matlab/Octave gemacht werden -
zusammen mit weiterer Auswertearbeit.
MfG, Arno
Hallo,
Pythonskript schrieb:> ansonsten frage ich mich auch, was die Aussage von Bernd soll, denn in> typischen Hochsprachen muss man sich das über Stringfunktionen alles> selber zusammenfrickeln, was deutlich aufwendiger und umständlicher ist,> als ein Einzeiler der sucht, findet und ersetzt, was immer man will.
Regular Expressions sind nicht gleich Regular Expressions, da gibt es,
nunja, verschiedene "Geschmäcker". POSIX Regular Expressions unterstützt
beispielsweise die GNU C Library (man regex). Außerdem gibt es
Generatoren wie lex, flex und flexc++, die RegEx-Code für C und C++
generieren.
Perl-kompatible Regular Expressions (PCRE) werden von etlichen Sprachen,
unter anderem auch Python, bereits nativ unterstützt. Für C/C++ kann man
die PCRE-Library von, Überraschung: http://www.pcre.org/ verwenden, die
dank BSD-Lizenz auch in kommerziellen Projekten genutzt werden darf.
HTH,
Karl
Hallo Jörg,
Jörg Wunsch schrieb:> Karl Käfer schrieb:>> Man kann in jeder Programmiersprache schräges Zeug schreiben. Aber>> Python macht es einem vergleichsweise schwer.>> Nur, wenn man es durch die Python-Brille sieht. ;-) Ich habe da auch> schon genügend "coolen Code" gesehen, bei denen der Autor unbedingt> seine Mikrooptimierungen schon in den Code einbauen musste.
Immer wenn Du etwas wirklich idiotensicher hinbekommen hast, kommt die
Natur und bekommt bessere Idioten hin.
> Selbstverständlich ist derjenige völlig felsenfest davon überzeugt,> dass die Syntax von Perl absolut schrecklich ist, und man Perl-Code> prinzipiell nicht lesen kann. :-)
Ich habe selber sicher zehn Jahre lang Perl gecodet und bin dann zu
Python gewechselt. Man kann auch in Perl sauberen, lesbaren Code
schreiben, aber dafür muß man aktiv etwas dafür tun, und es erfordert
Disziplin. In Python muß man hingegen aktiv etwas dafür tun, wenn man
unlesbaren Code schreiben will.
Python hat nicht umsonst den Ruf, quasi ausführbarer Pseudocode zu sein.
Mit Python kann ich meine Gedanken und Ideen quasi direkt in den Editor
hacken, schon läufts. Das ist einer der Gründe dafür, warum ich meine
ehemalige Standardskriptsprache Perl gegen Python getauscht habe: ich
muß meine Gedanken nicht mit den Sprachkonstrukten einer
Programmiersprache ausdrücken, sondern Python arbeitet direkt mit den
Konstrukten in meinen Gedanken. Trotzdem nutze ich Perl immer noch sehr
oft mit -p oder mit -pe als Filter auf der Kommandozeile, aber bless()
habe ich schon ewig nicht mehr geschrieben... ;-)
Was ich in Python im Vergleich zu Perl vermisse, sind einerseits das
CPAN und andererseits Perls herausragende Dokumentation. Python ist zwar
auch ganz gut dokumentiert, aber an perldoc mit seinen vielen Beispielen
kommt pydoc leider (noch?) nicht heran.
Herzliche Grüße,
Karl
Karl Käfer schrieb:> Immer wenn Du etwas wirklich idiotensicher hinbekommen hast, kommt die> Natur und bekommt bessere Idioten hin.
Den rahm ich mir ein :-)
Das Original geht m.W. so: "Programming today is a race between software
engineers striving to build bigger and better idiot-proof programs, and
the Universe trying to produce bigger and better idiots. So far, the
Universe is winning."
Karl Käfer schrieb:> Jörg Wunsch schrieb:>>> $ ps alx | awk 'FNR>1 {print $2}' | sort -u>> 0>> 1>> 1000>> 101>> 102>> 104>> 107>> 110>> 114>> 115>> 117>> 13>> 65534>> sort -un würde die Ausgabe noch übersichtlicher gestalten.
Wenn wir schon am Optimieren sind: ps kann eigentlich schon fast
alles, was hier benötigt wird, nämlich Header weglassen, Spalten
auswählen und sortieren. Damit ist awk überflüssig. Leider kann ps
wiederholt vorkommende Zeilen nicht ausblenden, so dass es doch noch
etwas externe Hilfe braucht. Da die Zeilen aber schon sortiert sind,
genügt dafür uniq anstelle von sort -un.
1
ps hakuid xouid | uniq
Dieses Kommando dürfte sogar die Gegner "kryptischer" Syntax begeistern,
da nur ein einziges Sonderzeichen verwendet wird ;-)
Scheint also rein Linux-spezifisch zu sein. Die awk-Variante
funktioniert dagegen zumindest auf allen Systemen, die BSD-Syntax
für die ps-Optionen verstehen.
Jörg Wunsch schrieb:> % ps hakuid xouid | uniq> ps: illegal option -- k
Mist, dabei habe ich mir so viel Mühe gegeben, genau so etwas zu
vermeiden ;-/
A. K. schrieb:> Pardoxerweise gelten die Optionen ohne "-" als BSD Optionen. ;-)
Das dachte ich auch. In der Man-Page von GNU-ps steht:
1
This version of ps accepts several kinds of options:
2
3
1 UNIX options, which may be grouped and must be preceded by a dash.
4
2 BSD options, which may be grouped and must not be used with a dash.
5
3 GNU long options, which are preceded by two dashes.
Weil ich weiß, dass du BSD-User bist und weil ich es auch sonst so
gewohnt bin, habe ich mich für die Optionen unter Punkt 2 entschieden
und keine aus den beiden anderen Gruppen verwendet.
Ich hätte aber wohl gleich auch in die BSD-Dokumentation schauen sollen.
Das habe ich jetzt getan:
http://www.freebsd.org/cgi/man.cgi?query=ps&sektion=1
... und überrascht festgestellt, dass alle Optionen mit einem Dash
geschrieben werden müssen und teilweise eine andere Bedeutung als die
entsprechenden in der GNU-Man-Page beschriebenen dash-losen Optionen
haben (bspw. die h-Option).
Da passt irgendwie überhaupt nichts zusammen. Und dein
1
ps alx
dürfte unter BSD eigentlich auch nicht funktionieren (sehr wohl aber in
GNU), weil der Dash fehlt. Zumindest verwendest du da anscheinend ein
undokumentiertes Feature ;-)
Ok, aber Folgendes sollte aber sowohl nach der GNU- als auch nach der
BSD-Man-Page korrekt sein:
1
ps -axo uid= | sort -un
Weil das BSD-ps nur über eingeschränkte Sortiermöglichkeiten verfügt,
bin ich hier wieder zu sort zurückgekehrt. Den awk braucht man aber
immer noch nicht, weil das "-o uid=" – auch nach BSD-Man_Page – sowohl
die UID-Spalte selektiert als auch den Kopfzeile weglässt.
Funktioniert das bei dir unter BSD? Wenn nicht, geb ich's auf, zumal
das gerade etwas offtopic wird ;-)
Yalu X. schrieb:> ... und überrascht festgestellt, dass alle Optionen mit einem Dash> geschrieben werden müssen und teilweise eine andere Bedeutung als die> entsprechenden in der GNU-Man-Page beschriebenen dash-losen Optionen> haben (bspw. die h-Option).
Nun, historisch wurden bei BSD die ps-Optionen ohne Strich geschrieben,
und viele (ich auch) tippen sie heute noch so — nicht zuletzt, weil
es halt dann wiederum ps-Implementierungen gibt, die bei einem
einleitenden Bindestrich auf System-V-Modus umschalten. Bei denen
(ich glaube, HP-UX 10.x gehört dazu) ist dann "ps aux" etwas anderes
als "ps -aux".
GNU wiederum hat dem Satz von Optionen eigene Erweiterungen zugefügt,
und sicher auch FreeBSD (verglichen mit der Basis 4.4BSD). So sind
es dann zwar vom Stil (ohne einleitenden Strich) BSD-Optionen, aber
eben keine wirklich von BSD stammenden mehr.
> Ok, aber Folgendes sollte aber sowohl nach der GNU- als auch nach der> BSD-Man-Page korrekt sein:>>>
1
> ps -axo uid= | sort -un
2
>
Ja, das klappt wieder.
> Den awk braucht man aber> immer noch nicht, weil das "-o uid=" – auch nach BSD-Man_Page – sowohl> die UID-Spalte selektiert als auch den Kopfzeile weglässt.
Ja, sicher. Mir ging's ja auch eher um ein nicht völlig praxisfernes
Beispiel für Dinge, bei denen ich wohl ohne weiteres Nachdenken sofort
zum awk greifen würde. Wäre für das Beispiel vermutlich sogar schneller
gewesen als das tiefgreifende Studium der man page von ps. :-)
Hallo,
Jörg Wunsch schrieb:> Ja, sicher. Mir ging's ja auch eher um ein nicht völlig praxisfernes> Beispiel für Dinge, bei denen ich wohl ohne weiteres Nachdenken sofort> zum awk greifen würde. Wäre für das Beispiel vermutlich sogar schneller> gewesen als das tiefgreifende Studium der man page von ps. :-)
1
import psutil
2
print sorted(set( [i.uids.real for i in psutil.get_process_list()] ))
Getestet unter Linux, soll auch unter Solaris, FBSD, Windows und OS/X
funktionieren.
LG,
Karl
Karl Käfer schrieb:> Getestet unter Linux, soll auch unter Solaris, FBSD, Windows und OS/X> funktionieren.
Ja, würde ich vielleicht benutzen, wenn ich das so portabel brauche.
Allein aber das Nachlesen der Doku hätte 10mal so lange gedauert, wie
das bisschen awk hinzuschreiben. Außerdem denke ich über Python für
„Einzeiler“ gar nicht erst nach, weil das dank des Einrückungswahns
über kuzr oder lang sowieso an seine Grenzen stößt.
Hi Jörg,
Jörg Wunsch schrieb:> Ja, würde ich vielleicht benutzen, wenn ich das so portabel brauche.> Allein aber das Nachlesen der Doku hätte 10mal so lange gedauert, wie> das bisschen awk hinzuschreiben. Außerdem denke ich über Python für> „Einzeiler“ gar nicht erst nach, weil das dank des Einrückungswahns> über kuzr oder lang sowieso an seine Grenzen stößt.
Ehrlich gesagt, hab' ich dafür nichtmal die Doku gelesen... einmal kurz
google angeworfen, psutil-Modul gefunden, installiert und im
interaktiven Modus geladen und dann mit dir() hineingeschaut. Alles
andere gehört ja eh zum Sprachkern von Python. (Ja, ich kenne Hacker's
secret #7: hackers read manuals. Aber manchmal ist das gar nicht nötig.)
;-)
Andererseits benutze ich auf der Kommandozeile auch gerne perl -p und
perl -pe, das ist in Verbindung mit Regular Expressions ausgesprochen
mächtig -- und auch [g]awk(1) benutze ich sehr regelmäßig, genau wie den
interaktiven Modus von Python. ;-) Um es mit Larry Wall zu sagen:
TIMTOWTDI.
Liebe Grüße,
Karl
Yalu X. schrieb:> ps -axo uid= | sort -un> Funktioniert das bei dir unter BSD?
Unter AIX 5.3 jedenfalls nicht (kein -x).
> ps alx | awk 'FNR>1 {print $2}'
Liefert lauter Zeilen mit dem Prozesszustand
A
Soviel zur Universalität solcher Einzeiler. ;-)
Perl, Ruby, Pythhon & Co. - na ja, wenn man sich das unbedingt antuen
will mittels angloamerikanischer Doku nach vielen Wochen vielleicht den
ersten Erfolg zu sehen?
Was haltet Ihr von "AutoIt" - http://www.autoit.de/index.php ?
Das hat zwar auch angloamerikanischen Ursprung, wird aber von der
deutschen HP in hervorragender Weise unterstützt.
Vorteilhaft bei "AutoIt" ist, dass man damit in einfacher Weise auch
selbstlaufende Programme (.exe) erzeugen kann, die extrem klein sind -
und das ohne irgendwelche Laufzeitbibliotheken (wie z.B. Bei BASIC).
Der Syntax ist leicht erlernbar (BASIC-ähnlich) und durch die zahlreich
vorhandenen Bibliotheken (.au3) einschließlich GUI-Unterstützung sind
die unterschiedlichsten, auch anspruchsvolle Anwendungsmöglichkeiten
gegeben.
Damit hatte ich mich mal u.a. an einem CAD-Projekt versucht -
http://www.autoit.de/index.php?page=Thread&threadID=20968.
Aus Zeitgründen und anderen Prioritäten ist die weitere Bearbeitung
z.Zt. unterbrochen...
Grüsse aus Berlin
PSblnkd
PSblnkd schrieb:> will mittels angloamerikanischer Doku
Das hast du bloss dagegen? Mir ist eine englische Doku meistens lieber
als eine eventuelle deutsche Doku. Dazu kommt, dass dieses AutoIt eine
Insellösung für eine einzige Plattform ist.
A. K. schrieb:> Unter AIX 5.3 jedenfalls nicht (kein -x).
Schon lange nichts mehr mit AIX gemacht ... kann es sein, dass das eins
der Systeme ist, bei denen man "ps ax" schreiben muss?
(Ob AIX allerdings die Option o unterstützt, selbst falls sie die
BSD-Optionssyntax haben, wage ich zu bezweifeln.)
Jörg Wunsch schrieb:> Schon lange nichts mehr mit AIX gemacht ... kann es sein, dass das eins> der Systeme ist, bei denen man "ps ax" schreiben muss?
Da fehlt dann der User. Die AWK Variante ist schon ok, nur ist die UID
eine Spalte weiter.
Wenn das übergreifend sein soll, dann mache ich sowas in der Art gerne
eine Nummer komplexer und werte die erste Zeile aus. Um rauszukriegen,
in welcher Spalte UID steht.
Hallo,
PSblnkd schrieb:> Perl, Ruby, Pythhon & Co. - na ja, wenn man sich das unbedingt antuen> will mittels angloamerikanischer Doku nach vielen Wochen vielleicht den> ersten Erfolg zu sehen?
Selbstverständlich gibt es für alle etablierten Programmiersprachen gute
Fachliteratur in deutscher Sprache.
> Was haltet Ihr von "AutoIt" - http://www.autoit.de/index.php ?> Das hat zwar auch angloamerikanischen Ursprung, wird aber von der> deutschen HP in hervorragender Weise unterstützt.
Also ich ganz persönlich halte gar nichts von AutoIt, denn unter meinem
Linux läuft es ebensowenig wie auf einem Mikrocontroller.
LG,
Karl
(Thematisch vorangegangener Thread:
Beitrag "Scriptsprache lernen" )
Thomas schrieb:> Salewski, Stefan schrieb:>> Das meiste ist wohl sehr experimentell, damit kann man viel Zeit vertun.>> Bleibt die Frage, warum man sich solche Exoten überhaupt antun sollte.>> Ich meine kann ja jeder machen was er will, und Interesse, Geek-Faktor> oder akademische Selbstbefriedigung mögen ja alles gute Gründe sein.> Aber mit Anfang 30 sollten doch die meisten darüber hinweg sein, und im> industriellen Alltag spielen solche Dinge eh keine Rolle.>> Nichts gegen Haskell, nur in freier Wildbahn ist mir das noch nie> begegnet.
Das dümmliche Gemecker sollte damit dann ja wohl erledigt sein, also zum
Thema:
Bei den "neuen" Programmiersprachen tut sich erfreulicherweise ja nun
doch einiges: Bei der Suche nach Mozillas Rust bin ich am Samstag auch
auf Julia, ATS und Nimrod gestoßen. Eigentlich wollte ich mir als
nächstes (nach Ruby) mal Vala oder Haskell etwas genauer ansehen, wobei
Vala eben stark an GTK/Glib gebunden ist, und bei Haskell lernt man, wie
Yalu so schön schrieb, das Programmieren noch mal ganz von vorne. Rust
hat keinen Garbage-Collector und bietet (beabsichtigt) keine
revolutionären Neuerungen. Julia ist wohl stark auf den Einsatzbereich
von MatLab ausgerichtet, ATS habe ich mir nicht näher angesehen, mag
aber auch interessant sein. Für mich persönlich am interessantesten ist
aber das kürzlich im DrDobbs Journal vorgestellte Nimrod. Python
ähnliche Syntax, statisch typisiert, schnell, echtzeitfähiger GC,
derzeit wird C Zwischencode erzeugt. Also prinzipiell auch für uC und
Embedded Systeme geeignet.
Übrigens, bei Oberon gibt es ja auch wieder etwas Aktivität: Wirth hat
eine RISC-CPU auf einem Spartan-3 FPGA gebaut -- mit Oberon als OS and
Sprache. So hat man ein völlig freies, quelloffenes System. Aber das ist
ein anderes Thema.
Bin großer Fan von Python. Python skaliert sehr gut von recht kleinen
Skripten bis hin zu größeren Applikationen.
Ansonsten muss man sagen: The right tool for the right problem. Die Wahl
der konkreten Technologie bei einem Projekt hängt immer von vielen
Faktoren ab. Niemand wird heute eine Businessanwendung mit Web Services
usw.usf. mit plain C programmieren. im embedded Bereich führt aber oft
kein Weg um C herum.
Was mit ansonsten aufgefallen ist: Was nützt die neueste und tollste
Programmiersprache, wenn viele Programmierer nicht in der Lage sind,
überhaupt informationstechnische Probleme ordentliche zu
konzeptionieren? Es gibt immer noch genug Programmierer, die meinen, ein
dynamisches Array sei das höchste der Gefühle an Datenstrukturen und
dann wird geschimpft, warum die Programmiersprache denn so langsam
sei...
ing² schrieb:> Niemand wird heute eine Businessanwendung mit Web Services> usw.usf. mit plain C programmieren.
Es gibt aber noch viele, für die C das einzig Wahre ist -- ich kam
übrigens auf diese Thematik, weil jemand kürzlich meinte, dass er gerne
den Java Code von Alfons W. nach C übertragen würde.
>> Was mit ansonsten aufgefallen ist: Was nützt die neueste und tollste> Programmiersprache, wenn viele Programmierer nicht in der Lage sind,> überhaupt informationstechnische Probleme ordentliche zu> konzeptionieren? Es gibt immer noch genug Programmierer, die meinen, ein> dynamisches Array sei das höchste der Gefühle an Datenstrukturen und> dann wird geschimpft, warum die Programmiersprache denn so langsam> sei...
Das ist natürlich auch wahr -- wer mit Java Fachinformatiker wird oder
in der Schule etwas Python lernt, weiss natürlich oft nicht, was im
Computer überhaupt vor sich geht. Aber wenn man den Kids Assembler, C
oder die Instruktionen einer einfachen abstrakten ALU erklären würde,
dann schlafen sie ein oder laufen weg. Kann ich irgendwie auch
verstehen.
Stefan Salewski schrieb:> Aber wenn man den Kids Assembler, C> oder die Instruktionen einer einfachen abstrakten ALU erklären würde,> dann schlafen sie ein oder laufen weg.
Eben, heutzutage muss man mit 10 Zeilen kopiertem Code mindestens eine
App haben, mit der man einen Mikrocopter mit Kamera über den
Nachbarsgarten steuern und den Video direkt in youtube stellen kann.
Udo Schmitt schrieb:> Vieleicht sollte man den Beitrag dahin verschieben wo er hingehört?
Wenn mir vielleicht mal jemand auf die Sprünge helfen würde, in welchen
Thread das gehört?
Jörg Wunsch schrieb:> Wenn mir vielleicht mal jemand auf die Sprünge helfen würde, in welchen> Thread das gehört?
Nach mir gehört das schon genau hier hin.
Yalu hatte kürzlich geschrieben, dass er sich mit Haskell beschäftigt,
und da kam mal wieder das typische Gemecker. Und damit die Deppen das
nicht alles wiederholen müssen, hatte ich das mal gleich oben eingefügt.
Du kannst den Thread meinetwegen aber gerne komplett löschen, vielleicht
schickst Du eine Kopie an Yalu. Mein Beitrag war nur als Anregung
gedacht, es ist ja nicht so ganz einfach etwas über die Sprachen zu
erfahren, wenn man deren Namen nicht kennt.
Stefan Salewski schrieb:> Nach mir gehört das schon genau hier hin.
Ja, der neue Thread kann schon seinen Sinn haben, da das Thema vom
anderen ziemlich weit abdriftet.
Allerdings hättest du die Referenz ruhig gleich selbst oben anbringen
können (habe es jetzt mal nachgetragen), und vielleicht noch dazu
schreiben sollen, dass man jetzt bitteschön nicht nochmal all das
aufwärmen sollte, was da schon geschrieben worden ist.
Damit hätte sich der Plug für Python nämlich bereits erledigt.
> Yalu hatte kürzlich geschrieben...
„Kürzlich“ ist gut. :-)
dumdi dum schrieb:> Ich finde die Monaden in Haskell nicht gut. Im Prinzip wird aus der> Funktionalen Sprache wieder ein mit globalen Variablen durch die> Hintertür.
Dann benutze sie einfach nicht oder schlage eine bessere Alternative
vor ;-)
IMHO sind Monaden mit das Genialste, was die Softwaretechnik in den
letzten paar Jahrzehnten hervorgebracht hat. Für diejenigen, die sich
dafür interessieren, habe ich ein paar Aspekte dazu zusammengefasst:
Das Verändern globaler Variablen ist einer von vielen möglichen
Nebeneffekten, den eine Funktion in einem Programm haben kann. Solche
Nebeneffekte sind oft unerwünscht, weil sie eine häufige Fehlerquelle
darstellen. In rein funktionalen Programmiersprachen wie Haskell sind
alle Funktionen grundsätzlich nebeneffektfrei. Diese Einschränkung
erschwert etwas die Programmierung, schließt aber dafür von vornherein
mehrere Fehlertypen aus und erleichtert zudem die Parallelisierung von
Algorithmen.
Es gibt aber auch Fälle, wo Nebeneffekte erwünscht sind. Hier sind zwei
wichtige Beispiele:
- Ein-/Ausgabe: Kein sinnvolles Programm kommt ohne jegliche Interaktion
mit der Außenwelt aus. Jede Ein-/Ausgabeoperation ändert aber Zustände
außerhalb der Funktion, bspw. den Tastaturpuffer, den Bildschirm- oder
den Festplatteninhalt, und hat damit Nebeneffekte.
- Effizienzsteigerung: Das Ändern eines einzelnen Elements eines großen
Arrays ist in rein funktionaler Programmierung eine aufwendige Aktion,
da hierzu, um Nebeneffekte zu vermeiden, eine komplette Kopie mit der
entsprechenden Änderung angelegt werden muss. Im schlimmsten Fall kann
dies sogar zu einer Erhöhung der algorithmischen Komplexität führen.
Viele funktionale Programmiersprachen umgehen dieses Dilemma einfach
damit, das sie auch einige Operationen mit Nebeneffekten zulassen. Das
Problem dabei: Solche Operationen "infizieren" immer auch die jeweils
aufrufenden Funktionen, so dass, wenn man nicht aufpasst, schnell ein
Großteil des gesamten Codes mit Nebeneffekten verseucht ist.
Monaden erlauben nun eine Programmiertechnik, mit denen lokal begrenzte
Nebeneffekte nachgebildet werden können, ohne dabei gegen die Regeln
der reinen funktionalen Programmierung zu verstoßen.
Mit der entsprechenden Unterstützung des Laufzeitsystems (das bei
Haskell übrigens in ganz profanem C geschrieben ist), ist es möglich,
Nebeneffekte nicht nur nachzubilden, sondern sogar Realität werden zu
lassen. Erst damit lassen sich auch Dinge wie Ein-/Ausgabe realisieren.
Diese realen Nebeneffekte finden logisch gesehen aber nicht innerhalb
des Programm statt, sondern werden in das Laufzeitsystem ausgelagert.
Es gibt also nachgebildete und ausgelagerte Nebeneffekte, die beide mit
der rein funktionalen Programmierung vereinbar sind. Aus der Sicht des
Programms unterscheiden sich beide nur dadurch, dass die ausgelagerten
über eine spezielle Monade namens IO abgehandelt werden, die auch der
vorgegebene Rückgabetyp der Main-Funktion ist.
Wenn im folgenden Text von "Nebeneffekten" die Rede ist, sind damit
nicht die echten, sondern die gerade beschriebenen nachgebildeten oder
ausgelagerten Nebeneffekte gemeint.
Auch wenn die Programmierung mit Monaden streng genommen nicht "unrein"
ist, bringt sie trotzdem einige der im Zusammenhang mit Nebeneffekten
bekannten Probleme mit sich. Allerdings wirken sie sich aus den
folgenden Gründen meist deutlich weniger stark aus als in imperativen
Sprachen:
- Die nachgebildeten Nebeneffekte finden nur lokal innerhalb einer
übergeordneten Funktion statt, die nach außen hin nebeneffektfrei ist.
Es erfolgt hier also keine Infizierung der übergeordneten Funktionen.
- Funktionen mit Nebeneffekten haben immer die entsprechende Monade als
Rückgabewert. Damit kann man ohne Analyse des Funktionscodes direkt
aus der Funktionssignatur erkennen, ob eine Funktion Nebeneffekte hat
und welcher Art diese sind.
- Einer bestehende nebeneffektfreie Funktion kann nicht einfach durch
Hinzufügen von nebeneffektbehaftetem Code selbst nebeneffektbehaftet
gemacht werden. Um dies zu tun, muss man nämlich zusätzlich ihren
Rückgabetyp ändern und alle direkten oder indirekten Aufrufer
ebenfalls entsprechend anpassen. Das macht die nebeneffektbehaftete
Programmierung ziemlich unbequem, weswegen sie wirklich nur dort
eingesetzt wird, wo es keine sinnvolle Alternative gibt.
Dadurch sind die manchmal unvermeidbaren Nebeneffekte nur in sehr engem
und streng kontrolliertem Rahmen einsetzbar, was die dadurch bedingten
Fehlerquellen auf ein Minimum reduziert.
Hier sind ein paar Informationen von außerhalb des Tellerrands:
Die Programmierung mit Monaden ist keineswegs auf Haskell beschränkt,
sondern in jeder Programmiersprache möglich. Haskell unterscheidet von
den meisten anderen Sprachen lediglich dadurch, dass es syntaktischen
Zucker anbietet, mit dem die monadische Programmierung schöner und
übersichtlicher dargestellt wird.
Monaden sind auch nicht der einzige Weg aus dem oben beschriebenen
Dilemma. Clean bspw., eine Haskell in vielen Punkten ähnliche Sprache,
verwendet stattdessen so genannte "unique types":
http://de.wikipedia.org/wiki/Clean_%28Programmiersprache%29
Der Begriff der Monade wurde eigentlich aus der Kategorientheorie
(einem recht abstrakten mathematischen Teilgebiet)
http://de.wikipedia.org/wiki/Kategorientheorie
übernommen und fand in die Softwaretechnik erstmals Einzug als Lösung
des I/O-Dilemmas von Haskell. Mittlerweile hat man aber festgestellt,
dass das Konzept sehr viel weiter reicht und damit in ungeahnter Weise
gänzlich unterschiedliche Problemstellungen vereinheitlicht und auf
elegante Weise gelöst werden können, und das nicht nur in Haskell. Ein
Beispiel, das auch einigen Nicht-Haskellianern bekannt sein dürfte, ist
LINQ:
http://de.wikipedia.org/wiki/LINQ
Wieviele neue Programmiersprachen schlagen eigentlich pro Jahr so auf?
Wieviele davon gelangen zu einer Verbreitung die auch längere Zeit (mehr
als ein paar Jahre) trägt, also genügend Nutzer bindet und genügend
Leute findet, die sich langfristig um die Pflege der neuen Sprache
kümmern? Gibt es darüber Statistiken? Wer außer Enthusiasten und dem
Informatik-Lehrkörper soll andauernd neue Programmiersprachen lernen?
Das ist ja so, als ob man sich ständig mit neuem "Werkzeug" eindeckt,
anstatt endlich mal mit der Arbeit zu beginnen. Wobei das "Werkzeug"
hier ja nicht selten mehrere hundert Seiten Bedienungsanleitung mit sich
bringt und das auch noch in einer Fremdsprache (= fremden
Programmiersprache) geschrieben. Das ein Informatiker bei einer neuen
Programmiersprache schnell mal einen wässrigen Mund bekommt und sich an
Details mit dem Ausstoß eines "Hosianna" förmlich ergötzt oder ereifert,
mag ja nachzuvollziehen sein. Andere sehen das vielleicht deutlich
nüchterner und schauen einfach wie sie mit dem was sie kennen und
gelernt haben umzugehen (in Wahrheit meistens halbwegs beherrschen) das
Problem "gebacken" bekommen. Und seit dem kürzlich entdeckten
Sicherheitsleck "Heartbleed", das in einer Silvesternacht 1h vor
Mitternacht entstand (vermutich so ähnlich wie "schnell noch ein paar
Zeilen hacken und dann ab zur Party") braucht keiner mehr der Illusion
auferliegen, dass kommerzielles programmieren in Wahrheit mehr ist als
Trial and Error "Alltags-Gecode".
Auch die Brot-und-Butter-Sprache, die du verwendest, war vielleicht mal
eine von ganz vielen neu entwickelten Sprachen und hat sich dann gegen
viele andere durchgesetzt, von denen heutzutage niemand mehr redet.
Viele Sprachen, die vielleicht etwas esoterisch anmuten oder nicht so
sehr bekannt sind, haben ja auch oft ihre Nischen, wo sie sich als
nützlich erweisen.
Also "Brot-und-Butter-Sprache" vs "Nische"?
Ja, die Nische wird immer verteidigt, ähnlich wie die jeweils aktuelle
Mode. Was gerade hipp ist glänzt, alles andere wirkt grau, altbacken und
abgegriffen.
Dennoch springen die Allermeisten im Alltag dann doch lieber auf den
"Brot-und-Butter-Sprache"-Zug. Warum wohl? Vielleicht weil das Trendige
schneller veraltet als das bereits lange Bestehende an Wert verliert.
> war vielleicht mal> eine von ganz vielen neu entwickelten Sprachen
Für manche Sprachen gab es schließlich auch handfeste Gründe vielerlei
Art sie zu entwickeln. Im Ergebnis haben die dann auch eine beachtliche
Fangemeinde dauerhaft hinter sich versammelt. C# wäre als Beispiel zu
nennen. Bei den Skriptsprachen sicher Python und Ruby (die selber wieder
in einigen Varianten auftreten).
Hallo Philip,
Philip K. schrieb:> Eine weitere Option wäre Python. Was für mit sehr stark für Python> spricht, ist dass es mit PyQt eine sehr mächte Erweiterung gibt, die> vollen Zugriff auf auf meine geliebte Qt-Umgebung erlaubt :-)> Was mich an Python abschreckt, ist die Tatsache, dass die> Code-Strukturierung über Einrückung erfolgt. Vom Handling gewöhnt man> sich vermutlich daran, aber ich frage mich, ob das nicht arg> Fehleranfällig ist. Was sagen die Leute mit Python-Erfahrung dazu?
Vor rund acht oder neun Jahren bin ich von Perl auf Python umgestiegen
und habe es keinen Tag bereut. Die Sache mit der Code-Einrückung hat
mich am Anfang auch abgeschreckt. Mittlerweile liebe ich das, weil es
mich dazu zwingt, lesbaren und klar strukturierten Code zu schreiben.
Außerdem kann man den Code sehr viel schneller lesen, wenn man daran
gewöhnt ist. Und mit einem Texteditor, der blockweise automatisch
einrücken kann (GNU/Emacs, was mich betrifft) ist das Ganze überhaupt
nicht fehleranfällig, sondern hilft durch die Übersichtlichkeit eher
dabei, Fehler zu vermeiden.
Auch sonst hat Python vieles, das richtig Spaß und die Entwicklung sehr,
sehr schnell und komfortabel macht. Das Exception-Handling. iPython als
interaktive Shell. numpy, scipy und pandas für die Verarbeitung großer
Datenmengen, Matplotlib für deren Visualisierung. TKinter und Tix für
einfache GUIs. Eine anständige Standard-API für SQL-Datenbanken. Die
Dokumentation reicht zwar nicht ganz an die von Perl heran, ist aber
trotzdem ziemlich gut.
Liebe Grüße,
Karl
Hallo Peter,
Peter II schrieb:> Das sind doch alles nur kleinigkeiten, damit sollte man als> Programmierer zurechtkommen.
"Zurechtkommen" != "Komfort". Man kann lesbaren Perl-Code schreiben,
aber es erfordert eine Menge Übung, Anstrengung und Disziplin. Man muß
sich darauf konzentrieren, lesbaren und sauber strukturierten Code zu
schreiben.
In Python ist es genau anders herum: durch die Sache mit der Einrückung
und ein paar andere Schmankerln muß man sich nicht anstrengen, um
lesbaren und sauber strukturierten Code zu schreiben; das passiert ganz
von alleine.
Deswegen bin ich in Python schon nach wenigen Wochen sehr viel
produktiver gewesen, als ich es in Perl jemals war. Das kann man aber
vermutlich nur dann beurteilen, wenn man beide Sprachen auf einem
vergleichbar guten und relativ hohen Niveau beherrscht.
Liebe Grüße,
Karl
Karl schrieb:> Noch eine offensichtlich unbeliebtere Variante: MATLAB bzw. Octave.> Warum? Weil ich es kann ;-) bzw. besser kann als den Rest der Sprachen> und ich zu faul bin was neues zu lernen.
Matlab als Sprache ist genial. Mit der MEX-Schnittstelle lassen sich
Tests mit C-Funktionen sehr gut aufsetzen - und auch gut systematisch
gegen eine Schnellimplementierung in Matlab gegentesten.
Dummerweise ist eine Lizenz als Privatperson nahezu unerschwinglich.
2000kEUR+MwSt. kostet eine Matlab-Lizenz ohne Toolboxen.
Und so steht man dann, wenn die Uni-Zeit vorbei ist, vor einem Haufen
selbstgebauter Werkzeuge, die nicht mehr funktionieren (und eine
Neuimplementierung in Octave ist extrem zeitaufwendig).
Diesen Lock-In-Effekt sollte man nicht unterschätzen.
Ich habe es getan :-(
> Dummerweise ist eine Lizenz als Privatperson nahezu unerschwinglich.> 2000kEUR+MwSt.
2000kEUR = 2.000.000 €
Sooo teuer wirds wohl nicht sein.
Ich habe mit mathworks.de nachgeschaut.
Da gibt es neben Student-Versionen auch Home-Versions für ca. 105€ +
Ust.
Das finde ich ok.
Hallo Arno,
Arno schrieb:> Kollegen teilen die Messdaten in Dateien mit maximal 150000 Werten auf> und sortieren das dann mit Excel - dauert auch "nur" eine halbe Stunde> zum Öffnen und eine weitere halbe Stunde zum Schließen. Pro 150000> Werte, versteht sich, also >3 Arbeitstage für die 5 Mio Messwerte.
Mit Python wende ich komplexe Regelwerke für die Betrugserkennung auf
150k Datensätze mit je 200 Feldern an -- in deutlich unter zehn
Sekunden.
Liebe Grüße,
Karl
Nürnberger schrieb:> 2000kEUR = 2.000.000 €> Sooo teuer wirds wohl nicht sein.>
Hoppla, Zehnerpotenz.
> Ich habe mit mathworks.de nachgeschaut.> Da gibt es neben Student-Versionen auch Home-Versions für ca. 105€ +> Ust.> Das finde ich ok.
Ich habe nach einem solchen Lizenzmodell schon mehrere Male angefragt.
Wahnsinn! Es gibt sie wirklich! Damit ist das hier gerade der beste
Forenthread geworden, den ich dieses Jahr gelesen habe.
Hi Yalu,
Yalu X. schrieb:> dadada schrieb:>> Python ist prima. Ich weiss nicht wie das inzwischen ist, aber Arrays>> waren immer mehr oder weniger ein Problem.>> Ähnlich wie Stefan kann auch ich nicht ganz verstehen, wo da ein Problem> liegt.
Möglicherweise habe ich verstanden, worauf er hinaus will: in Python
gibt es keine Array-Struktur, die erzwingt, daß alle Elemente denselben
Typ haben:
1
l = [1, 2.0, 'drei']
ist also möglich, aber eben eine Liste und kein Array.
Aber natürlich kann man ein echtes Array-Verhalten mit einer eigenen
Klasse erzwingen, die von list() erbt und die Methoden __init__(),
__add__(), __iadd__(), __mul__(), __imul__(), __setitem__(),
__setslice__(), append() und extend() mit eigenen Methoden überschreibt,
die mit isinstance() oder type() überprüfen, ob der übergebene und in
die Liste einzufügende Datentyp der gewünschte ist. Ich kann mir
allerdings keine Situation vorstellen, in der so etwas wirklich nötig
sein sollte.
LG,
Karl
Karl Käfer schrieb:> Möglicherweise habe ich verstanden, worauf er hinaus will: in Python> gibt es keine Array-Struktur, die erzwingt, daß alle Elemente denselben> Typ haben:
Ja, vielleicht meint er das. Aber das entspricht ja voll der Philosphie
von Python: Durch die dynamische Typsystem wird nirgends ein bestimmter
Typ erzwungen (es gibt allenfalls einen Laufzeitfehler, wenn eine
Operation auf einen Datentyp angewendet wird, für den er nicht definiert
ist). Eine Variable kann einen beliebigen Typ haben und diesen auch
jederzeit ändern, dasselbe gilt konsequenterweise für jedes einzelne
Element von zusammgesetzten Datentypen (Lists, Tuples, Dictionaries und
Objects). Eine Vorschrift, dass alle Elemente eines zusammgesetzten
Datentyps vom gleichen Typ sein müssen, würde mit der Typphilosophie von
Python brechen.
> l = [1, 2.0, 'drei']>> ist also möglich, aber eben eine Liste und kein Array.
Streng genommen ist das ein Array, auch wenn die Dinger in Python "List"
heißen:
http://en.wikipedia.org/wiki/List_%28abstract_data_type%29
"Lists are distinguished from arrays in that lists only allow
sequential access, while arrays allow random access."
Der Elementtyp ist bei der Unterscheidung zwischen Liste und Array ohne
Bedeutung. In C++ bspw. haben sowohl in Arrays als auch in Listen alle
Elemente den gleichen Typ.
Hallo Stefan,
Stefan Salewski schrieb:> Warum werden oft globale Funktionen wie len(str) usw. verwendet?
Weil das sehr generische Funktionen sind und eigentlich nur Wrapper für
die eigentlichen OO-Methoden der betreffenden Objekte. len(a) ruft zum
Beispiel a.__len__() auf und kann für Dictionaries (Hashes), Listen,
Tupel, aber auch in user-definierten Klassen verwendet werden. Im
Prinzip sind das auch gar keine Funktionen, sondern Operatoren, die --
wie sich das für OO-Sprachen gehört -- natürlich überschrieben werden
können. a + b funktioniert ähnlich: da wird a.__add__(b) aufgerufen.
HTH,
Karl
Hallo Thomas,
Thomas schrieb:> Ich habe gerade eine repräsentative und wissenschaftlich fundierte> Studie zur industriellen Relevanz der gängigen Programmiersprachen> durchgeführt.
Python hinter Erlang, C und Java gleichauf und deutlich vor C++, und
.NjET als Programmiersprache aufgeführt, aber C#, COBOL und FORTRAN
nicht? Also, sorry, irgendwas kann da nicht stimmen. Kann man die Studie
einsehen?
Liebe Grüße,
Karl
Hi Dennis,
Dennis S. schrieb:> Python für dreckige Hacks... ;-)
In Python kann man keine dreckigen Hacks machen, sondern nur saubere.
Manche halten das für einen Nachteil, aber die sollte man nicht ernst
nehmen.
Liebe Grüße,
Karl
Walter Tarpan schrieb:> Matlab als Sprache ist genial.
Wirklich?
Keyword args? negativ
vermüllter globaler Namespace? check
objektorientierung wir verwendet? negativ
seltsames scoping? check (die erste funktion in einer datei ist global,
alle anderen lokal)
Bei meiner doch eher kurzen Bekanntschaft mit MATLAB sind mir keine
Sprachfeatures untergekommen, die ich in Python vermissen würde. MATLABs
einzige stärke liegt in den umfassenden Toolboxen und Simulink, von der
Sprache her sind Python, etc. um einiges Voraus.
Lukas K. schrieb:> objektorientierung wir verwendet? negativ
Soll das "wird" oder "wirr" heißen? OO in Matlab gibt es theoretisch,
die wurde aber (wie alle Features, die über das Rechnen mit Matrizen
hinausgehen) irgendwie ohne erkennbares Konzept drangebastelt. Leider
kann ein Teil der E-Techniker nur Matlab und C und "löst" auch die
ungeeignetsten Probleme damit, statt den Horizont etwas zu erweitern...
Thomas schrieb:> Soll das "wird" oder "wirr" heißen?
Ersteres.
Besonders negativ ist's mir aufgefallen, als mit MATLAB Messgeräte
mittels VISA angesteuert wurden.
1
instrument = visa('agilent', 'GPIB0::17::INSTR'); %set variable to instrument
Lukas K. schrieb:> objektorientierung wir verwendet? negativ
Vorhanden seit Version 2008a. Benutzbar seit 2009a.
Lukas K. schrieb:> seltsames scoping? check (die erste funktion in einer datei ist global,> alle anderen lokal)
Finde ich nicht verkehrt.
Lukas K. schrieb:> Bei meiner doch eher kurzen Bekanntschaft mit MATLAB sind mir keine> Sprachfeatures untergekommen, die ich in Python vermissen würde. MATLABs> einzige stärke liegt in den umfassenden Toolboxen und Simulink,
"Sprachfeatures" sind definitiv nicht die Stärke. Die Stärke ist der
Umgang mit der Numerik. LaPack. ScaLaPack. BLAST. Sparse-Solver.
Faktorisierungsmechanismen. Handliche Parallelisierung. Hervorragende
Plot-Optionen. Visualisierung.
Eben alles, was mit der Arbeit mit Matrizen zu tun hat. Deswegen ja auch
der Name "MATrix LABoratory". Sicher, in Python kann man mit den
Numerik-Libraries viel nachrüsten, und die Plot-Optionen werden auch
immer besser. Aber im Umgang mit Sparse-Matrizen mit wenigen hundert MB
hört es dann langsam auf, Spaß zu machen. Und bei Matlab fängt er da
erst an.
Thomas schrieb:> Leider> kann ein Teil der E-Techniker nur Matlab und C und "löst" auch die> ungeeignetsten Probleme damit, statt den Horizont etwas zu erweitern...
Um für die Datenaquisition Matlab anstelle LabView zu benutzen sollte
man schon gewichtige Gründe haben. Es ist weder billiger noch ähnlich
gut dazu geeignet. Aber ich finde auch meinen Lötkolben nicht schlecht,
obwohl er nicht als Tauchsieder taugt.
Egal. Völlig OT.
Sollten sich hier noch ein paar schöne Ansätze mit Python auftun, bin
ich natürlich auch gespannt.
Ich habe dann gestern abend tatsächlich mal Nimrod installiert, zusammen
mit dem Paketmanager Babel und dem Editor Aporia. Kann man alles lokal
in sein Home-Verzeichnis installieren, der Code ist in wenigen Sekunden
kompiliert. Aporia, der stark gedit ähnelt: 3k sehr übersichtlicher
Code, 600k Executable. Also ich bin immer noch sehr beeindruckt, zumal
Nimrod fast ausschlieslich von einer Person entwickelt worden ist.
Hier noch ein (entfernter) Link zum Wikipedia:
http://en.wikipedia.org/wiki/User:Dom96/sandbox
Python war meine Entdeckung des Jahres 2004. Bereits damals
war die Sprache mehr als 15 Jahre "auf dem Markt". Bis dahin
habe ich vorwiegend C++ als Vehikel für alles benutzt. Noch vorher
Turbo Pascal und Turbo C. Python verwende ich bis heute sehr gern.
Muss allerdings zugeben, dass ich noch nicht zu 3.x gewechselt bin.
Seit "Damals" ist Python extrem Modulreich geworden ... dennoch
mache ich hin und wieder Erfahrung, dass "battaries included"
Versprechen immer schwieriger zu halten ist.
Die Abhängigkeiten zwischen den Modulen in Griff zu bekommen
(plattformunabhängig) ist wohl noch die Herausforderung.
Erst gestern wollte ich auf Windows-Plattform etwas mit scapy spielen,
und musste feststellen, dass ich windows binaries nur für 2.6 bekomme
.. oder eben selbst kompilieren muss. Habe dann zu raw sockets
gegriffen.
Haskell ist keine Programmierung im herkömmlichen Sinne.
Haskell ist mehr eine Sammlung von Gleichungen, die "reduziert" werden
:)
Karl Käfer schrieb:
(Viele Lobhymnen auf Python)
> Und mit einem Texteditor, der blockweise automatisch einrücken kann> (GNU/Emacs, was mich betrifft) ist das Ganze überhaupt nicht> fehleranfällig, sondern hilft durch die Übersichtlichkeit eher dabei,> Fehler zu vermeiden.
Nein, genau das ist der Schwachpunkt, weshalb ich die Einrückomania
an Python auch nach mehreren Jahren, die ich damit arbeite, immer noch
hasse. Ein Texteditor kann das nicht von allein sauber auf die Reihe
bekommen. Wenn ich etwas schreibe wie:
1
if foo == bar:
2
do_something
3
do_more
4
done = True
Dann hat der Editor einfach keine Chance, von sich aus festzustellen,
dass das "done = True" hinter der if-Anweisung stehen soll. Ich muss
mich manuell drum kümmern, ihm das mitzuteilen, denn freiwillig würde
er das noch als zur if-Anweisung zugehörig zählen.
Mag beim Neuschreiben ja gerade noch so gehen, aber wenn ich einen
Block Code von woanders kopiere, und er landet dann auf einem neuen
Einrückungsniveau, dann ist das einfach gruselig, egal was die
Verfechter der "so werde ich zu ordentlichem Programmieren
gezwungen"-Fraktion immer wieder gebetsmühlenartig wiederholen. Man
muss in dem Moment dann anfangen, den kompletten kopierten Block in
all seinen Details neu zu durchdenken um zu sehen, ob man die blöde
Einrückerei jetzt korrekt auf die Reihe bekommen hat.
Für mich ist das das kränkste syntaktische Konzept einer
Programmiersprache seit FORTRAN (bei dem die Schlüsselwörter keine
reservierten Namen sind), von nicht ganz ernst zu nehmenden Sprachen
wie "Whitespace" mal abgesehen.
Wer nicht in der Lage war, mit Unterstützung des Editors ohne diesen
Zwang eine vernünftige Einrückung hinzubekommen, der hat doch einfach
nur seinen Beruf (oder sein Hobby) verfehlt. Das kann man ganz und
gar freiwillig tun, völlig ohne Zwang. Wenn einen die Sprache aber
mit entsprechenden syntaktischen Elementen dann unterstützt, dann kann
es eben auch eine dumme Maschine schaffen, den Code komplett neu
einzurücken, ohne dabei zu riskieren, etwas an der Bedeutung des Codes
zu verändern. indent(1) ist deutlich älter als Python …
Das zweite, was mich an Python zuweilen stört ist, dass sie zwar so
großen Wert auf OO legt, dann aber trotzdem nicht konsequent ist. Die
Länge eines Strings bekomme ich eben nicht über eine Methode des
Strings raus, sondern über eine globale Funktion (und nur darüber).
Versteh' mich nicht falsch, ich benutze die Sprache, aber ich bin
nicht blind vor Liebe. Ich habe scheußlichen und unleserlichen
Python-Code gesehen (den der Autor sicher ob der schön ausgenutzten
Möglichkeiten der Sprache "cool" fand), genauso wie ich weiß, dass man
in C oder Perl unleserlichen Code schreiben kann. Ich habe natürlich
auch viel netten Python-Code gesehen, genauso wie ich viel netten
Perl-Code kenne.
Jörg Wunsch schrieb:> Das zweite, was mich an Python zuweilen stört ist, dass sie zwar so> großen Wert auf OO legt, dann aber trotzdem nicht konsequent ist. Die> Länge eines Strings bekomme ich eben nicht über eine Methode des> Strings raus, sondern über eine globale Funktion (und nur darüber).
Die Frage hatte ich ja auch kürzlich gestellt.
Es ist wohl so, dass der Trend wieder etwas von den OO Methoden weg
geht. Beispiel: Mehrere Strings mit einem (Leer)-Zeichen verbinden: '
'.join(string_array) oder string_array.join(' ')? Eine Lösung ist wohl,
dass man einfach eine Prozedur join() mit zwei Argumenten hat (multiple
dispatch oder so?). Macht für mich irgendwie Sinn, muss ich aber erst
lernen. Als "Syntatic Sugar" ist dann oft auch die Schreibweise als
Methode mit .xxx() erlaubt.
Und zu Python -- wer die Einrückungen nicht mag, kann doch Ruby
verwenden. Dass Python im Bezug auf Popularität Ruby so stark überholt
hat, verwundert mich noch immer. Gut, PyPy, NumPy, MathPlotLib gibt es
für Ruby nicht, aber sonst ist für mich Ruby gleichwertig zu Python, nur
etwas eleganter.
Stefan Salewski schrieb:> Gut, PyPy, NumPy, MathPlotLib gibt es für Ruby nicht
Ja, es ist letztlich das Umfeld, was es macht.
Wenn ich irgendwo für Perl eine schöne Klasse finde, die genau das tut,
was ich gerade als Problem gelöst haben möchte, dann fange ich auch
nicht extra an, das alles in Python (oder Ruby) neu zu schreiben.
Jörg Wunsch schrieb:> Dann hat der Editor einfach keine Chance, von sich aus festzustellen,> dass das "done = True" hinter der if-Anweisung stehen soll.
Naja, hat er woanders auch nicht direkt -> in C musst du } schreiben. In
Python drückst du stattdessen Backspace.
> wenn ich einen> Block Code von woanders kopiere, und er landet dann auf einem neuen> Einrückungsniveau, dann ist das einfach gruselig [...]> anfangen, den kompletten kopierten Block in> all seinen Details neu zu durchdenken um zu sehen, ob man die blöde> Einrückerei jetzt korrekt auf die Reihe bekommen hat.
Ich weis nicht welchen Editor du verwendest, aber alle die ich kenne
unterstützen Blockweises Ein-/Ausrücken. D.h. Block markieren und dann
Tab und Shift-Tab, oder Strg+I und Strg+U
Ich habe keine Probleme mit der Einrückung. Nur sollte man sich vorher
mit sich selbst einig werden, ob man jetzt Leerzeichen oder Tabs benutzt
(und den Editor passend einstellen)
Simon S. schrieb:> Ich weis nicht welchen Editor du verwendest, aber alle die ich kenne> unterstützen Blockweises Ein-/Ausrücken. D.h. Block markieren und dann> Tab und Shift-Tab, oder Strg+I und Strg+U
Wenn man zwischendrin noch mehr basteln muss, ist das trotzdem Mift,
weil es alles schnell durcheinander kommt. Ein ordentliches
Syntaxelement (egal, ob nun "}", "end" oder was auch immer) hilft an
dieser Stelle eben nicht nur dem Compiler/Interpreter, sondern auch dem
Editor.
Simon S. schrieb:> Ich weis nicht welchen Editor du verwendest, aber alle die ich kenne> unterstützen Blockweises Ein-/Ausrücken. D.h. Block markieren und dann> Tab und Shift-Tab, oder Strg+I und Strg+U
Wenn man den gerade gepasteten Block anders einrücken möchte, muss man
ihn bei einigen Editoren nicht einmal neu markieren.
Im Vim bspw. tippt man direkt nach dem Pasten
1
`]>
zum Einrücken und
1
`]<
zum Ausrücken um jeweils eine Ebene. Will man mehrere Ebenen ein- bzw.
ausrücken, drückt man danach einfach noch solange auf die Punkttaste,
bis die Einrückung stimmt.
Man kann den Editor sicher auch dazu bringen, den Block anhand der
aktuellen horizontalen Cursorposition einzurücken. Dann muss man
überhaupt nichts mehr nacharbeiten.
Zum Thema len(str) vs. str.len() hat Guido folgende Stellungsnahme
abgegeben:
https://mail.python.org/pipermail/python-3000/2006-November/004643.html
Das ist für mich jetzt zwar nicht hundertprozentig überzeugend, aber
schon nachvollziehbar. Solche Inkonsequenzen gibt es in jeder größeren
Sprache, meistens historisch bedingt.
Etwas anderes stört mich an Python viel mehr, nämlich der redundante
Doppelpunkt am Ende von Zeilen mit if, for usw. Zum einen sieht er
an dieser Stelle hässlich aus, zum anderen vergesse ich ihn ständig nach
dem else. Aber auch damit kann ich gerade noch so leben.
Yalu X. schrieb:> Wenn man den gerade gepasteten Block anders einrücken möchte, muss man> ihn bei einigen Editoren nicht einmal neu markieren.
Es setzt trotzdem voraus, dass ich mit diesem Block direkt nach dem
paste rein noch gar nichts gemacht habe, und ihn dann gleich erstmal
auf das richtige Einrückungsniveau setze.
Habe ich schon mit anderen Dingen angefangen zu editieren, und erst
dann fällt mir auf, dass ich jetzt lieber den ganzen Block noch
passend einrücken möchte, dann bin ich gears***t.
In allen anderen Programmiersprachen markiere ich mir dann den Block
und sage dem Editor, dass er den markierten Block jetzt nach den
Regeln, die er fürs normale Editieren auch benutzt, auf Soll-Einrückung
bringen möge.
Ich bleibe dabei: whitespace als syntaktisch signifikantes
Sprachelement zu benutzen, war und ist ein großes "don't do this".
Da ändert es auch nichts dran, dass Python ansonsten ganz nett ist.
> Zum Thema len(str) vs. str.len() hat Guido folgende Stellungsnahme> abgegeben:
Überzeugt mich auch nicht gerade. Ich weiß doch bereits, dass ich
einen String habe, dessen Länge ich haben will (und dass es nicht
etwa ein Integer ist).
> Etwas anderes stört mich an Python viel mehr, nämlich der redundante> Doppelpunkt am Ende von Zeilen mit if, for usw.
Der stört mich nun weniger. Man hätte ja an der Stelle auch eine
öffnende Klammer schreiben können. =:-)
Hallo Walter,
Walter Tarpan schrieb:> "Sprachfeatures" sind definitiv nicht die Stärke. Die Stärke ist der> Umgang mit der Numerik. LaPack. ScaLaPack. BLAST. Sparse-Solver.> Faktorisierungsmechanismen. Handliche Parallelisierung. Hervorragende> Plot-Optionen. Visualisierung.>> Eben alles, was mit der Arbeit mit Matrizen zu tun hat. Deswegen ja auch> der Name "MATrix LABoratory". Sicher, in Python kann man mit den> Numerik-Libraries viel nachrüsten, und die Plot-Optionen werden auch> immer besser. Aber im Umgang mit Sparse-Matrizen mit wenigen hundert MB> hört es dann langsam auf, Spaß zu machen. Und bei Matlab fängt er da> erst an.
Bitte verzeih' mir, aber für mich liest sich das nicht gerade wie die
Beschreibung einer General-Purpose-Sprache. :-)
Liebe Grüße,
Karl
Hallo Stefan,
Salewski, Stefan schrieb:> Ich habe dann gestern abend tatsächlich mal Nimrod installiert, zusammen> mit dem Paketmanager Babel und dem Editor Aporia. Kann man alles lokal> in sein Home-Verzeichnis installieren, der Code ist in wenigen Sekunden> kompiliert. Aporia, der stark gedit ähnelt: 3k sehr übersichtlicher> Code, 600k Executable. Also ich bin immer noch sehr beeindruckt, zumal> Nimrod fast ausschlieslich von einer Person entwickelt worden ist.
Das sieht ja ganz nett aus, aber: was genau kann diese Sprache besser
als die etablierten Programmiersprachen?
Liebe Grüße,
Karl
Hallo Jörg,
Jörg Wunsch schrieb:> Nein, genau das ist der Schwachpunkt, weshalb ich die Einrückomania> an Python auch nach mehreren Jahren, die ich damit arbeite, immer noch> hasse. Ein Texteditor kann das nicht von allein sauber auf die Reihe> bekommen. Wenn ich etwas schreibe wie:>>
1
>
2
> if foo == bar:
3
> do_something
4
> do_more
5
> done = True
6
>
>> Dann hat der Editor einfach keine Chance, von sich aus festzustellen,> dass das "done = True" hinter der if-Anweisung stehen soll. Ich muss> mich manuell drum kümmern, ihm das mitzuteilen, denn freiwillig würde> er das noch als zur if-Anweisung zugehörig zählen.
Du kannst ein "pass" hinter "do_more" einfügen, dann rücken ordentliche
Editoren wie Emacs automatisch aus. ;-)
> Mag beim Neuschreiben ja gerade noch so gehen, aber wenn ich einen> Block Code von woanders kopiere, und er landet dann auf einem neuen> Einrückungsniveau, dann ist das einfach gruselig, egal was die> Verfechter der "so werde ich zu ordentlichem Programmieren> gezwungen"-Fraktion immer wieder gebetsmühlenartig wiederholen. Man> muss in dem Moment dann anfangen, den kompletten kopierten Block in> all seinen Details neu zu durchdenken um zu sehen, ob man die blöde> Einrückerei jetzt korrekt auf die Reihe bekommen hat.
Ein anständiges Werkzeug wie Emacs oder vi wirkt da Wunder.
> Für mich ist das das kränkste syntaktische Konzept einer> Programmiersprache seit FORTRAN (bei dem die Schlüsselwörter keine> reservierten Namen sind), von nicht ganz ernst zu nehmenden Sprachen> wie "Whitespace" mal abgesehen.
Ja, es gibt diese Fehlerquellen, aber wenn man drauf achtet, sind sie
nicht allzu problematisch. Da kenne ich in Perl, PHP und C sehr viel
üblere Fallen. ;-)
> Wer nicht in der Lage war, mit Unterstützung des Editors ohne diesen> Zwang eine vernünftige Einrückung hinzubekommen, der hat doch einfach> nur seinen Beruf (oder sein Hobby) verfehlt.
Wer sein Werkzeug nicht beherrscht, hat das ohnehin verfehlt.
> Das zweite, was mich an Python zuweilen stört ist, dass sie zwar so> großen Wert auf OO legt, dann aber trotzdem nicht konsequent ist. Die> Länge eines Strings bekomme ich eben nicht über eine Methode des> Strings raus, sondern über eine globale Funktion (und nur darüber).
str.__len__(), list().__len__() etc. existieren.
> Versteh' mich nicht falsch, ich benutze die Sprache, aber ich bin> nicht blind vor Liebe. Ich habe scheußlichen und unleserlichen> Python-Code gesehen (den der Autor sicher ob der schön ausgenutzten> Möglichkeiten der Sprache "cool" fand), genauso wie ich weiß, dass man> in C oder Perl unleserlichen Code schreiben kann. Ich habe natürlich> auch viel netten Python-Code gesehen, genauso wie ich viel netten> Perl-Code kenne.
Wie gesagt: man kann in jeder Sprache ordentlichen Code schreiben, und
man kann in jeder Sprache besch...enen Code schreiben. Python hat seine
Fallen -- keine Frage -- aber einen Obfuscated Python Contest wird es
wohl nie geben.
Und was eindeutig für Python spricht, ist seine Umgebung. Numpy, Scipy,
Matplotlib, Tkinter/Tix, PIL, SimpleCV... nur um ein paar der Module zu
benennen, die ich diese Woche benutzt habe.
Liebe Grüße,
Karl
Hallo Jörg,
Jörg Wunsch schrieb:> Wenn man zwischendrin noch mehr basteln muss, ist das trotzdem Mift,> weil es alles schnell durcheinander kommt. Ein ordentliches> Syntaxelement (egal, ob nun "}", "end" oder was auch immer) hilft an> dieser Stelle eben nicht nur dem Compiler/Interpreter, sondern auch dem> Editor.
Die betreffenden Syntaxelemente in Python heißen "pass" und "return".
SCNR,
Karl
Karl Käfer schrieb:> Bitte verzeih' mir, aber für mich liest sich das nicht gerade wie die> Beschreibung einer General-Purpose-Sprache. :-)
Das muß daran liegen, daß es eine Sprache ist, die für einen
abgegrenzten Themenbereich entwickelt wurde.
Walter Tarpan schrieb:> Karl Käfer schrieb:>> Bitte verzeih' mir, aber für mich liest sich das nicht gerade wie die>> Beschreibung einer General-Purpose-Sprache. :-)>> Das muß daran liegen, daß es eine Sprache ist, die für einen> abgegrenzten Themenbereich entwickelt wurde.
Dann dachten die wohl bei Mathworks, hey da geht noch was, lass uns doch
noch GUI, VISA, TCP/IP, .... anflanschen. Und so wurde MATLAB zu einer
general-purpose Sprache.
Was dann dabei herausgekommen ist erinnert mich immer wieder
erschreckend an PHP. Kein wunder, beides waren zu beginn recht
spezifische Sprachen, die im Laufe der zeit strukturfrei erweitert
wurden.
Karl Käfer schrieb:> Die betreffenden Syntaxelemente in Python heißen "pass" und "return".
Leider nicht. Wenn es Syntaxelemente wären, wären sie verpflichtend.
Da sie es nicht sind, finde ich sie in fremdem Code nicht. Damit ist
das aber wieder witzlos, denn ich müsste sämtlichen Fremdcode erst
umarbeiten.
Damit habe ich das gleiche Dilemma wie mit dem genannten PythonB; ist
ja lustig (kannte ich noch nicht), aber Fremdcode würde höchstens als
byte-compiled code direkt durchgehen.
Du brauchst mich ansonsten nicht zu agitieren, den Emacs zu benutzen:
das tu' ich schon seit 20 Jahren.
> aber einen Obfuscated Python Contest wird es wohl nie geben.
Aber auch nur, weil die Python-Programmierer, die dazu in der Lage
wären, nie zugeben würden, dass sie es mit der Sprache mühelos geschafft
haben, obfuscated code zu produzieren. Die sind halt stolz auf ihre
tollen Konstrukte und bemerken rein gar nicht, dass der Salat für einen
Außenstehenden völlig unleserlich ist. Selbst sind sie ja noch der
Meinung, dass man in Python gar nicht unleserlich schreiben könnte …
Ehrlich, da sind mir die C- und Perl-Programmierer lieber, die einfach
darum wissen, dass man in jeder Sprache unleserlichen Blödsinn zimmern
kann (“Real programmers can write FORTRAN in any language.”), die es
aber an den Stellen, wo es drauf ankommt, strikt vermeiden, genau das
zu tun.
Karl Käfer schrieb:> Das sieht ja ganz nett aus, aber: was genau kann diese Sprache besser> als die etablierten Programmiersprachen?
Na ja, viele der Annehmlichkeiten von Python oder Ruby kombiniert mit
(fast) der Geschwindigkeit von C. Ich mag Ruby, aber bei einigen
Projekten sorgt man sich halt um die Performance. Und auch Python wird
mit PyPy und ähnlichen Projekten nicht an C bzw. C++ herankommen. Aber
neben Nimrod werde ich auch Rust weiter beobachten, und wenn ich C++
Bibliotheken wie CGAL oder Boost verwende, werde ich womöglich doch C++
verwenden.
Thread beobachten
Seitenaufteilung abschalten