Scriptsprache lernen

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.

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:

1

    printf OUTFILE "-- tga_i\n";

2

    for ($i=1; $i le $slaves; $i++) {

3

      if ($slave[$i]{"tga_i"} eq 1) {

4

        $tmp=0;

5

        for ($j=1; $j le $masters; $j++) {

6

          if ($master[$j]{("priority_".($slave[$i]{"wbs"}))} ne 0) {

7

            $tmp+=1;

8

          };

9

        };

10

        if ($tmp eq 1) {

11

          $tmp=1; until ($master[$tmp]{("priority_".($slave[$i]{"wbs"}))} ne 0) {$tmp++;};

12

          printf OUTFILE "%s_%s_i <= %s_%s_o",$slave[$i]{"wbs"},$rename_tga,$master[$tmp]{"wbm"},$rename_tga;

13

        } else {

14

          $tmp=1; until ($master[$tmp]{("priority_".($slave[$i]{"wbs"}))} ne 0) {$tmp++;};

15

          printf OUTFILE "%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"};

16

          for ($j=$tmp+1; $j le $masters; $j++) {

17

            if ($master[$j]{("priority_".($slave[$i]{"wbs"}))} ne 0) {

18

        if ($master[$j]{"tga_o"} eq 1) {

19

                printf OUTFILE " or (%s_%s_o and %s_%s_bg)",$master[$j]{"wbm"},$rename_tga,$master[$j]{"wbm"},$slave[$i]{"wbs"};

20

        };

21

            };

22

          };

23

        };

24

        printf OUTFILE ";\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:
> 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.

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 ;-)

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.

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.

Danke, Jörg, für einen sachlichen und fundierten Beitrag!

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 ;)

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.

Thomas schrieb:
> Nichts gegen Haskell, nur in freier Wildbahn ist mir das noch nie
> begegnet.

John Carmack portiert gerade Ur-Wolfenstein dorthin. :-)

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...

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

1

j=sum(map(func, range(0,42)))

oder list comprehension

1

j=sum([func(i) for i in range(0,42)])

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

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.

Philip K. schrieb:
> was haltet Ihr alternativ zu Python&Co von
> Shell-Scripten?

Für jemanden der masochistisch veranlagt ist eine gute Lösung. :)

Philip K. schrieb:
> was haltet Ihr alternativ zu Python&Co von Shell-Scripten?

Abstand.

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.

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.

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... ;-)

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. ;-)

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.

´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 …

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. ;-)

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. :-)

A. K. schrieb:
> Sie ist schrecklich.

An jeder Sprache ist irgendwas schrecklich. ;-)

Wie war das gleich?  "Real programmers can write FORTRAN programs in
any language."

http://www.pbm.com/~lindahl/real.programmers.html

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 ;-)

1

% ps hakuid xouid | uniq

2

ps: illegal option -- k

3

usage: ps [-aCcdefHhjlmrSTuvwXxZ] [-O fmt | -o fmt] [-G gid[,gid...]]

4

          [-M core] [-N system]

5

          [-p pid[,pid...]] [-t tty[,tty...]] [-U user[,user...]]

6

       ps [-L]

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:
> Scheint also rein Linux-spezifisch zu sein.

Pardoxerweise gelten die Optionen ohne "-" als BSD Optionen. ;-)

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. :-)

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.

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. ;-)

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.

Vieleicht sollte man den Beitrag dahin verschieben wo er hingehört?

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?

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. :-)

Ich finde die Monaden in Haskell nicht gut. Im Prinzip wird aus der 
Funktionalen Sprache wieder ein mit globalen Variablen durch die 
Hintertür.

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

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.

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.

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.

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

2

fopen(instrument);  %connect to the instrument 

3

4

fprintf(instrument,'*IDN?'); %query instrument

5

idn = fscanf(instrument) %read from instrument

vs.

1

import visa

2

rm = visa.ResourceManager()

3

keithley = rm.get_instrument("GPIB::12")

4

print(keithley.ask("*IDN?"))

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.

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.

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. =:-)

Wobei es ja sogar Python mit Klammern wie in C gibt: 
http://www.pythonb.org/

Aber ohne ist mir doch lieber wenn ich mir die Beispiele so ansehe..

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.