Umfrage: womit programmiert ihr kleine Tools/Berechnungen

[Freddy (Gast)]

Hallo,

kleinere Berechnungen programmiere ich beruflich in Matlab.
Leider kann ich diese nicht problemlos an Kollegen weitergeben - schon 
alleine wegen der Lizenz. In Excel sind kleine Berechungen möglich, aber 
meist alles andere als intiutiv.

Wie handhabt ihr das so?
Erstellt ihr richtige EXE z.B. in Visual Studio?

[Dennis S. (eltio)]

Python.

[chris (Gast)]

octave ist die open source mathlab sw.
Solltest du mal austesten.

[Chefentwickler (Gast)]

Ich auch in Python.

[Max D. (max_d)]

Je nach Zielsetzung Python oder QT/C++.
Für Datei-Operationen und dgl. auch Shell-Skript.

[Dieter (Gast)]

ich komme privat ganz gut mit Linux klar und kenne dort die Tools wie 
sed, awk, perl... Kommt natürlich kein Kollege mit klar.
Außerdem muss ich für jedes Programm die IT bitten mir die Freigabe zu 
geben das zu installieren.

Deswegen kann ich momentan nur Perl nutzen. Als Dateimanager mit 
besserer Umbennung, Filesuchen, etc. Total Commander und Notepad++ als 
Editor.
Berechnungen muss ich in Excel durchführen, wobei ich dort VBA als 
Programmiersprache missbrauche und auch somit dort Berechnungen 
durchführen lasse und das Diagramm von dort plotten lassen.

Das Problem ist, dass man sich als Entwickler viele Werkzeuge selber 
basteln muss und die IT eines Großkonzerns hierfür keine richtige Lösung 
anbietet bzw. wie oben genannt die Berechtigungen ein Problem sind.

[Freddy (Gast)]

@Chris:

kann Octave auch ActiveX?
Einige automatische Auswertungen laufen durch Matlab, erstellen eine 
Figure bzw. mehrere und schreiben diese direkt in ein Word Dokument?

@Alle:
Hat schon jemand mit NumPy oder SciPy gearbeitet?
Wer kommt von Matlab und hat den Sprung dahin unternommen? Wie sind die 
Erfahrungen?

[Chris D. (myfairtux) (Moderator)]

Für schnelle, zusammengekloppte Lösungen: Tcl/Tk :-)

[Hacker (Gast)]

Eclipse und Java

[R. M. (rmax)]

Chris D. schrieb:
> Für schnelle, zusammengekloppte Lösungen: Tcl/Tk :-)

... und nicht nur dafür.

[Chris D. (myfairtux) (Moderator)]

R. Max schrieb:
> Chris D. schrieb:
>> Für schnelle, zusammengekloppte Lösungen: Tcl/Tk :-)
>
> ... und nicht nur dafür.

Das stimmt - aber "quick & dirty" geht eben auch ;-)

Wir Tcl'er sind eine kleine, verschworene Gemeinschaft :-)

[Walter Tarpan (Gast)]

Freddy schrieb:
> Wer kommt von Matlab und hat den Sprung dahin unternommen? Wie sind die
> Erfahrungen?

So, daß ich, nachdem es seit Anfang 2014 eine Matlab-Home-Lizenz gibt, 
wieder zurückgesprungen bin.

[der Dabbes (Gast)]

Chris D. (myfairtux) (Moderator) schrieb:

> Für schnelle, zusammengekloppte Lösungen: Tcl/Tk :-)

> Wir Tcl'er sind eine kleine, verschworene Gemeinschaft :-)

Ihr Tcl/Tk'ler seid wohl sowas wie die Freimaurer? Sitzt in euren Logen 
und macht geheimes Zeugs mit Tcl/Tk. :-))

Donnerwetter!

;-)

[P. M. (o-o)]

Matlab. Alternativ Scilab, das auf Windows deutlich bequemer ist als 
Octave. Für Octave gibt es aber auch diverse Webseiten, wo man die 
Berechnung im Browser durchführen kann.

[chris (Gast)]

Ja, bei octave-forge ist es dabei , nicht bei den Snapshoot releases.
So war es zumindest frueher. actxserver , klarerweise nur in der win 
Distribution.
https://www.ices.utexas.edu/sysdocs/Octave-Matlab/

[Rene S. (Firma: BfEHS) (rschube)]

Für "quick & dirty" mache ich fast alles auf der Kommandozeile
Perl, gcc oder Bash

Dateien parsen natürlich in Perl
Datei Handling mit Bash
Berechnungen, MySQL etc. ANSI-C (gcc)

Selbst schnelle Bildmanipulation geht mit Perl-GD super.

Tcl/Tk hab ich auch mal gemacht bin aber dann lieber zu Perl gewechselt 
:-)
Da kann ich auch in klingonisch schreiben und es ist lesbarer als Tcl

use Lingua::tlhInganHol::yIghun;
        
        <<'u' nuqneH!\n>> tIghItlh!
         
        {
                wa' yIQong!
                Dotlh 'oH yIHoH yInob 
                        qoj <mIw Sambe'> 'oH yIHegh jay'!
                <Qapla'!\n> yIghItlh!
        } jaghmey tIqel!

[Gregor O. (zappes)]

Wenn es ein UI braucht oder auf dem Telefon laufen soll, nehme ich Java. 
Schnelle Kommandozeilenhacks werden je nach Komplexität mit Bash oder 
PHP gefrickelt. Und manchmal, wenn ich leicht masochistisch drauf bin, 
werfe ich einfach ein paar Zeilen Javascript in eine HTML-Datei ...

[(prx) A. K. (prx)]

Perl. Nicht die eleganteste Sprache unter der Sonne, aber sie war auf 
diversen Plattformen seit den 80ern verfügbar.

[c.m. (Gast)]

je nach zielsetzung (berechnungen mache ich eigentlich nicht).
perl/bash/gnu-tools wenns darum geht texte/csv's zu bearbeiten.
java wenns entweder eine gui braucht und/oder ein(…) komplexeres 
framework wie z.b. pdf bearbeitung/webservices/oracle forms beans 
benutzt werden muss.

[Joachim D. (Firma: JDCC) (scheppertreiber)]

a: Stift und Papier oder Kopfrechnen um in Übung zu bleiben
b: Excel wenn es etwas mehr wird

Oder halt schnell etwas in C zusammengestrickt ...

[(prx) A. K. (prx)]

Rene Schube schrieb:
> Selbst schnelle Bildmanipulation geht mit Perl-GD super.

Es gibt kaum irgendwas, für das es noch kein Perl-Modul gibt.

[max (Gast)]

In meinem Umfeld (Uni) hat schlicht jeder Matlab, insofern ist für mich 
dann auch logischerweise Matlab das Mittel der Wahl - für fast alles.

[R. M. (rmax)]

Tja, die Hersteller wissen schon, warum sie Unis und Studenten mit 
verbilligten oder gar kostenlosen Versionen ihrer Software versorgen.

[Hardware Kenner (Gast)]

Freddy schrieb:
> Hallo,
>
> kleinere Berechnungen programmiere ich beruflich in Matlab.
> In Excel sind kleine Berechungen möglich, aber
> meist alles andere als intiutiv.

Auch in (plain) C, mit gcc. Entweder unter Linux oder unter Windows mit 
cygwin.

MfG,

[perlyfied (Gast)]

Perl weil:
It gets the job done before your boss fires you

[Julius F. (julz)]

Python weils so schön schnell geht.

[Fabian F. (fabian_f55)]

Tools die denkbar einfach zu bedienen sind mache ich in AutoIt.
https://www.autoitscript.com/site/autoit/
So änhlich wie Basic. Einfach zu programmieren und noch einfacher GUIs 
zu basteln.
Kommt eine .Exe hinten raus gepurzelt.

Eigenet sich gut für die Automatisierung von Windows, Auslesen von 
Dateien und schreiben in neue Dateien.

Für viele Sachen gibts schon Skripte von anderen usern die man sich 
schnell anpassen kann (Z.B XML-Zugriffe)

Zum Plotten alla Matlab weniger geeignet.

[Helmut S. (helmuts)]

Julius Faust schrieb:
> Python weils so schön schnell geht.

Das große Problem bei Python ist, dass es zwei Lager gibt - Python 2.7 
und Python 3.4 . Die sind leider so inkompatibel, dass Scripts in der 
Praxis nicht in beiden Versionen funktionieren.

Ich schreibe eher mal was in C. Schon allein deswegen damit ich als 
Gelegenheitsprogrammierer nicht total aus der Übung mit C komme.

[mips (Gast)]

F# als Script oder Programm

[Hmm.. (Gast)]

Für Berechnungen wo's auch mal etwas komplexer wird Octave und GnuPlot. 
Einfache Sachen wo mal paar Dateien ausgewertet werden sollen oder so 
etwas gerne auch TCL, damit kann man sogar unter Linux schön mit der 
seriellen Schnittstelle arbeiten oder einen TCP-Socket öffnen. In 
höchster Not wenns mal eine GUI braucht dann C#, kommt aber eher selten 
vor.

[Dirk B. (dirkb2)]

Hmm.. schrieb:
> TCL, damit kann man sogar unter Linux schön mit der
> seriellen Schnittstelle arbeiten oder einen TCP-Socket öffnen.
Das ist auch ein Grund, warum ich bei Messgeräten USB vermeide :-)
Auch unter Windows.

> In
> höchster Not wenns mal eine GUI braucht dann C#,
Aber auch gerade da ist das Tk von Tcl nett

[Freddy (Gast)]

Danke soweit für die Antworten.
Da sind ein paar nette Ideen dabei.

Da diese Werkzeuge auch für die Kollegen zur Verfügung stehen sollten, 
sollte es schon nicht ganz zu exotisch sein.

Ich denke ich werde mich mal in die Richtung AUTOIT, Pyton/NumPy, Pyton 
mit QT sowie Octave umsehen. Auch unter Berücksichtung der Weitergabe 
der Tools.

Eine Frage an die Entwickler unter Euch?
Ist bei Euch in der Firma grundsätzlich alles erlaubt? Oder gibt es 
Richtlinien von der IT? Oder Abteilungsvorgaben womit welche 
Aufgabe/Tool erledigt werden müssen?

Gruß

[Hans (Gast)]

Die Umfrage scheint zwar schon "beendet" zu sein aber der 
Vollständigkeit halber:

SciLab statt Matlab

und wie oben schon erwähnt Qt/QtCreator in C++ weils verdammt sexy zum 
Gui-Designen ist mit allen Vorzügen von C++ und dem GCC...

[der Dabbes (Gast)]

Helmut S. (helmuts) schrieb:

Julius Faust schrieb:
>> Python weils so schön schnell geht.

> Das große Problem bei Python ist, dass es zwei Lager gibt - Python 2.7
> und Python 3.4 . Die sind leider so inkompatibel, dass Scripts in der
> Praxis nicht in beiden Versionen funktionieren.

Meine mageren Python Erfahrungen sind auch genau an diesem Hindernis mit 
Stirnrunzeln erst mal ausgebremst worden. Auf Python bin ich rein 
praktisch über FreeCAD gestoßen, welches selbst noch ein Python v2.6 
verwendet. Dass es da so einen eklatanten Bruch zwischen den 
Versionsnummern gibt, die viele Leute dazu veranlasst lieber bei der 
alten Version zu bleiben, hätte ich erstmal so nicht erwartet.

(und übrigens gut, dass es die schönen Threads über LTSpice gibt ;))

> Ich schreibe eher mal was in C. Schon allein deswegen damit ich als
> Gelegenheitsprogrammierer nicht total aus der Übung mit C komme.

Als quasi nur "Windows Mensch" verwende ich gerne für kleine 
Progrämmchen die freie "Pelles C Compiler IDE" (startet schnell und ein 
leeres Win32 Konsolenprojekt ist flott angestoßen). Für kleinere 
GUI-Projekte nehme ich die Win32-API frei nach Petzold. Für 
aufwändigeres C(++) oder C# dann die MS-Express Versionen.

[Gerhard (Gast)]

Hans schrieb:
> Die Umfrage scheint zwar schon "beendet" zu sein aber der
> Vollständigkeit halber:
>
> SciLab statt Matlab

Es ist zwar schon etwas her, dass ich mit SciLab gearbeitet habe, 
funktionierte auch alles schön, aber es war nicht code-kompatiebel zu 
Matlab. Dagegen liefen die meisten *.m Skripts ohne Änderungen in 
Octave.

Gerhard

[chris (Gast)]

Dies kann ich bestätigen.

[Walter Tarpan (Gast)]

Gerhard schrieb:
> Dagegen liefen die meisten *.m Skripts ohne Änderungen in
> Octave.

Sagen wir's so: Es ist relativ unaufwendig, Scripte zu schreiben, die 
für beides funktionieren. Allerdings gibt es auch Unterschiede:

 - String-Funktionen liefern bei Matlab Zeilenvektoren, bei Octave 
Spaltenvektoren. Bei Scripts mit String-Verarbeitung hat das bei mir 
einmal zu sehr ärgerlichen Ergebnisse geführt (was aber dank einer 
ausreichenden Backup-Strategie keine Katastrophe war).

 - Scripte, die auf der Objektorientierung von Matlab aufbauen 
funktionieren ebenfalls nicht.

 - Viele andere Sachen (Serial Port etc.) funktionieren nicht.

Das Problem wenn einer Matlab und die anderen Octave nutzen ist eher das 
Testen. Dann lieber ein Komplettwechsel.

Viele Grüße
W.T.

[Albert M. (Firma: Bastler aus Mönchengladbach) (albertm)]

- Programmierbarer Taschenrechner HP 35s
  Ja, soll auch noch Leute geben die sowas benutzen :)

- Wenn eine GUI nötig ist mit Delphi und zusätzlichen Math.-Components.

[Yalu X. (yalu) (Moderator)]

Wenn sich die Aufgabe durch ein fertiges Unix-Tool (oder die Kombination
von mehreren davon) lösen lässt, nehme ich diese(s) und programmiere gar
nichts.

Wenn diese Tools auf nicht ganz triviale Weise miteinander verbunden
werden müssen, schreibe ich ein kleines Bash-Skript drumherum (selten
mehr als ca. 10 Zeilen).

Wenn das nicht reicht und die Ausführungsgeschwindigkeit keine Rolle
spielt, nehme ich Python, üblicherweise Python 3. Python benutze ich
auch als besseren Taschenrechnerersatz.

Mit den drei vorgenannten Möglichkeiten erschlage ich geschätzte 90% von
den benötigten "kleinen Tools/Berechnungen", mit den folgenden die
restlichen 10%:

Wenn es so viel zu rechnen gibt, das Python zu langsam ist, nehme ich C.

Wenn ein etwas komplizierterer Algorithmus vonnöten ist, der in C nicht
in maximal 30 Zeilen umsetzbar ist, nehme ich Haskell.

Für symbolische Berechnung nehme ich (wx)Maxima.

Matlab verwende ich nicht, weil ich befürchte, mich davon abhängig zu
machen ;-) Außerdem ist es ziemlich auf Lineare Algebra zugeschnitten,
die ich nur selten benötige. Falls doch, habe ich noch Scipy/Numpy
installiert.


Papier und Bleistift verwende ich aber ebenfalls, vor allem für die
etwas kreativeren Tätigkeiten, teilweise aber auch für Berechnungen.

[... (Gast)]

RUN/C, The C Interpreter, Version 1.21
by Stephen Walton with Peter Brooks
Copyright (C) 1984, 1985 by Age of Reason Co. All rights reserved.
394032 bytes free


Ok

[Arc N. (arc)]

mips schrieb:
> F# als Script oder Programm

Dachte schon ich wäre der einzige hier, der F# auch für so was nutzt ;)

Was sonst noch: C/C++ wenn's Richtung Bitschupsereien/maximale 
Ausführungsgeschwindigkeit geht, wxMaxima (Ungleichungen machen damit 
allerdings leider immer noch keinen Spaß) oder Octave

[Schreiber (Gast)]

Für die einfachen Sachen QBasic, für die komplizierteren Delphi

[Lukas K. (carrotindustries)]

Python, weil es für praktisch jede Problemdomäne schon Bibliotheken gibt 
und die Sprache an sich 'schön' ist. Mit Ipython notebook hat's dann 
noch ne bequeme Umgebung, um mal schnell was auszuprobieren. Auch bei 
Dingen, die normalerweise nicht gemeinsam vorkommen, wie z.B. Webserver 
und VISA (nicht die Kreditkarte) hilft Python weiter. PHP und MATLAB 
können je nur das eine brauchbar, Python ist überall 'irgendwie daheim'. 
Auch mal ne DLL zu wrappen ist kein Problem. Für GUIs nehme ich auf 
Linux GTK3, auf Windows hab' ich leider noch nichts mit brauchbarem 
GUI-Editor gefunden.

TL;DR: Would buy again.

[Rene H. (Gast)]

Wenns etwas für unterwegs sein soll, programmiere ich meinen guten alten 
HP48SX, der mir seit dem Studium stets Treu war :-).

Wenn es auf dem Desktop laufen muss das bereits erwähnte Tcl/Tk

Grüsse,
R.

[Klaus I. (klauspi)]

Excel

[Μαtthias W. (matthias)]

Hi

perl für alle möglichen kleinen Tools. Kleines GUI-Zeugs das nur unter 
Windows laufen muss in C#.

Matthias

[Geert H. (geerth)]

Freddy schrieb:
> Hallo,
>
> kleinere Berechnungen programmiere ich beruflich in Matlab.
> Leider kann ich diese nicht problemlos an Kollegen weitergeben - schon
> alleine wegen der Lizenz. In Excel sind kleine Berechungen möglich, aber
> meist alles andere als intiutiv.
>
> Wie handhabt ihr das so?
> Erstellt ihr richtige EXE z.B. in Visual Studio?

Ich empfehle diese Matlab Alternative: Euler Math Toolbox.

 http://euler.rene-grothmann.de/

Nur etwa 80Mb.
Viele(!) Beispiele von der Autor (er ist Mathematik Professor). Er 
nutzst es für al seine  Kurse und Internetdiscussionen. Alles ist 
besonders gut documentiert.
Auf Knopfdruck wird von einem Notebook (Berechnung+Grafiken) HTML 
erstelt.
Interfaces to various external programs (e.g. Latex, Povray, Tiny C, 
Python)
Free!

[anonymous (Gast)]

c, php, javascript, bash (inkl. div tools), java, matlab, maple, jolly 
(ja der bleistift-typ) + papier, ... - je nach bedarf und aufgabe, zur 
verfügung stehenden tools, etc.

[Sven B. (scummos)]

Python.

[Carsten W. (eagle38106)]

C# für Programme mit Windows-GUI. Spreche damit auch die 
FTDI-USB-Bausteine an. Und ich benutze C# auch für Office-Plugins.

Für ein paar Formeln quick & dirty, vor allem, wenn ich die nicht n-mal 
brauche, muß auch schon mal Excel herhalten.

[drama (Gast)]

Python.

IMHO ist der "Krieg" zwischen 2.x und 3.x langsam zu Ende. Immer mehr 
Code wird für 3.x geschrieben und praktisch alle relevanten Module sind 
für 3.x verfügbar oder es gibt Alternativen, die auch unter Python 3.x 
funktionieren. Teilweise sind diese Alternativen für Python 3 besser als 
das "Original" (man denke an PIL vs Pillow).

[Eric B. (beric)]

Kleine Tools: CMD/BAT oder Python (3.4).
Berechnungen: Excel.

Perl habe ich nie gemocht.

[W.S. (Gast)]

Ihr seid komische Leutz.

Um was für "kleine Tools" geht es denn hier eigentlich? Irgendwelche 
Dateiarbei? Suchen von irgendwelchen Inhalten? kleinere mathematische 
Berechnungen? grafische Darstellungen?

Oder was sonst?

Ich hatte mal nen Kollegen, der fast alles mit einer Kombi aus Windows 
Explorer und Wolfram's Mathematica erledigte. Geht. Und wenn man damit 
geübt ist, auch schnell.

Ich selber nehme für so ziemlich alle organisatorischen Dinge den 
Totalcommander, einschließlich FTP. Vom Krusader bin ich nicht so 
überzeugt, der ist in den letzten Jahren zwar auch besser geworden, aber 
er hinkt wie alles in diesem realm hinterher.

Ansonsten für simple Kommandozeilensachen VP (Virtual Pascal), für 
Zeugs, wo ich was komplexeres Grafisches brauche Delphi oder Lazarus und 
für sowas wie Kalkulationen oder Meßdaten verarbeiten eben ne 
Tabellenkalkulation. Welche, ist fast egal, irgendwie gehen sie alle.

Aber ich merke schon, hier sind Tools-Freunde am Werk, siehe Yalu's 
Beitrag. Ich stehe nicht so sehr auf Tools, sondern eher auf richtige 
Anwendungen. Fast hätte ich Apps geschrieben, aber das wäre wieder mal 
mißverständlich gewesen.

nAbend,
W.S.

[Monty (Gast)]

Ich finde Tabellenkalkulation alá Excel höchst beschränkt. Meistens 
ärgere ich mich im Nachhinein darüber es wieder damit probiert zu haben, 
weil es spätestens wenn eine verschachtelte If-Funktion gefragt ist 
komplett unübersichtlich wird. Dazu sind die Formeln nur mäßig 
wiederverwendbar in meinen Augen. Klar es geht meistens irgendwie, aber 
die Betonung liegt in dem Fall auf irgendwie. Deshalb nehme ich 
eigentlich für so ziemlich alles was über SUMME() hinaus geht lieber 
Python und Konsorten.

Was ich nicht verstehen kann ist der hohe Anteil an Leuten hier die TCL 
benutzen... Serielle Schnittstelle okay, aber für Berechnungen etc.? Ich 
muss mich in der Arbeit wegen bestimmten Tools damit quälen, aber

set a [expr [lindex $array $i]+1]

 anstatt

a=array[i]+1

 in so gut wieder anderen Sprache, wer tut sich so etwas freiwillig an?

[Chris D. (myfairtux) (Moderator)]

Monty schrieb:
> in so gut wieder anderen Sprache, wer tut sich so etwas freiwillig an?

Leute, die den Unterschied zwischen Listen und Feldern kennen.

Bist Du sicher, dass Du mit Tcl arbeitest? ;-)

[Peter X. (peter_x)]

Kleine Tools programmiere ich mit Delphi. Das fließt mir als Borländer 
quasi "aus der Hand". Bei C muß ich zuviel darüber nachdenken, damit das 
auch funktioniert.

[(prx) A. K. (prx)]

Monty schrieb:
> wer tut sich so etwas freiwillig an?

Dass Tcl noch existiert liegt an Tk. Es ist kein Zufall, dass Tcl fast 
immer zusammen mit Tk als Tcl/Tk genannt wird. Das war früher eine der 
einfachsten Methoden, auf die Schnelle etwas GUI-mässiges zurecht zu 
stricken.

Mittlerweils gibts kaum noch eine ix-mässige Scriptsprache, die kein 
Tk-Modul bietet, aber das war nicht immer so.

Mich hat in dem Zusammenhang mittlerweile geärgert, dass ActiveState bei 
deren Perl Implementierung das Tk offenbar fallen gelassen hat.

[Jens P. (picler)]

Obwohl es bei den "echten" Programmierern uncool ist: VB 2008. Man kann 
sich schnell ein GUI zusammenklicken und für spezielle Sachen hat man 
Zugriff auf die Windows-API und vor allem auf das .NET-Framework. Na und 
.EXE kann man natürlich auch erzeugen.

[(prx) A. K. (prx)]

Jens PICler schrieb:
> Obwohl es bei den "echten" Programmierern uncool ist:

In meinem Fall ist das schlicht deshalb uncool, weil plattformbezogen. 
Wenn man über die Jahre mit diversen Betriebssystemen wie DOS, OS/2, 
Unix/Linux und Windows zu tun hat, und zwar gleichzeitig, dann hilft es, 
wenn man nicht für jede Plattform eine eigene Lösung braucht.

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

A. K. schrieb:
> Mittlerweils gibts kaum noch eine ix-mässige Scriptsprache, die kein
> Tk-Modul bietet, aber das war nicht immer so.

Ich weiß nicht, wie das bei anderen ist, aber bei Tkinter fiel mir
auf, dass man im Gegensatz zu Tcl einem Callback (wie man es bspw. an
einen command button bindet) keine Parameter mitgeben kann.  Das
macht die Benutzung deutlich umständlicher als bei Tcl/Tk.

Ich war zwar nie ein großer Fan von Tcl, habe aber bspw. Mfile damit
geschrieben.  Der wesentliche Grund war, dass im WinAVR ohnehin schon
Tcl mit dabei war (wegen Insight) und so keine weitere Runtime von
irgendwas anderem nötig wurde.

Am Ende ist es mir mittelmäßig egal, ob ich nun Tcl nehme (außer Tk
habe ich da auch noch irgendwo eine GPIB-Anbindung rumliegen), Perl
(kenne ich selbst von all diesen Sprachen am längsten, und besonders
Textverarbeitung mit vielen REs ist damit sehr einfach zu machen)
oder Python (hat für manche Dinge wirklich nette Module parat,
außerdem ist es die Sprache, mit der auch meine Kollegen zurecht
kommen).  Führt alles zum Ziel.  Wenn ich den Eindruck habe, dass ich
irgendwas schneller in C gelöst bekomme, greif ich mir aber auch nicht
hintenrum, es nun partout erst in einer Scriptsprache zu hacken; auf
den Maschinen, auf denen ich arbeite, gibt's auch immer einen
C-Compiler.

[Peter X. (peter_x)]

Jens PICler schrieb:
> Obwohl es bei den "echten" Programmierern uncool ist: VB 2008.

Nein - im Gegenteil. Es soll aber Leute geben, die C in jedeweder Art 
propagieren, in ihrem stillen Kämmerlein doch das eine oder andere Tool 
in (V)Basic proggen. Habe in der Firms bei überarroganten Kollegen schon 
eine Arduino-IDE aufblitzen sehen :-).

[Monty (Gast)]

Chris D. schrieb:
> Monty schrieb:
>> in so gut wieder anderen Sprache, wer tut sich so etwas freiwillig an?
>
> Leute, die den Unterschied zwischen Listen und Feldern kennen.
>
> Bist Du sicher, dass Du mit Tcl arbeitest? ;-)

Ich nutze es wie gesagt nur deshalb weil diverse Tools das vorgeben und 
die spucken eben nur Listen aus, daher war mir bisher noch nicht bekannt 
dass es auch Felder gibt ;-) Reduzieren wir das Beispiel dann eben auf 
folgendes:

C, Java, Python...

a=b+1(;)

TCL:

set a [expr b+1]

Also bei mir kommt da jedenfalls kein Gefühl von Code-Ästhetik auf ;-)

[(prx) A. K. (prx)]

Monty schrieb:
> Also bei mir kommt da jedenfalls kein Gefühl von Code-Ästhetik auf ;-)

Kennst du Lisp? Da ist das recht konsequent realisiert:
  (setq a (+ b 1))

[Thomas M. (thomaswm)]

Ist  zwar weniger bekannt, aber für kleine Programmieraufgaben nutze ich 
LUA. Auch in der Firma. LUA Scripte lassen sich auch in C oder C# 
Programme einbinden.

[Chris D. (myfairtux) (Moderator)]

Monty schrieb:

> Ich nutze es wie gesagt nur deshalb weil diverse Tools das vorgeben und
> die spucken eben nur Listen aus, daher war mir bisher noch nicht bekannt
> dass es auch Felder gibt ;-) Reduzieren wir das Beispiel dann eben auf
> folgendes:
>
> C, Java, Python...
>

a=b+1(;)

> TCL:
>

set a [expr b+1]

Was immer noch falsch ist ;-)

> Also bei mir kommt da jedenfalls kein Gefühl von Code-Ästhetik auf ;-)

Man kann sich natürlich immer und in jeder Sprache Konstrukte 
raussuchen, die in anderen eleganter gelöst sind :-)

Dafür kann man bspw. in Tcl Strings als Befehlszeilen ausführen lassen 
oder auch einen Interpreter innerhalb eines Interpreters starten lassen 
(sehr praktisch für sichere Parser) usw.

Der Tcl-Interpreter ist durch seinen übersichtlichen Befehlsumfang auch 
sehr klein (deutlich unter 100k). Den setzen wir bspw. direkt auf 
Controllern (früher Atmel, heute STM32) ein. Unser "neues" Ziel ist es, 
Tk auf einen STM32F429 zu portieren, und so auch grafische Oberflächen 
sehr einfach per Skriptsprache erstellen zu können. Man kann dann also 
schön am PC seine Oberfläche zusammenbauen und muss nur das Skript in 
den Controller laden - oder noch besser: man arbeitet per Console direkt 
im Tcl-Interpreter des Controllers und dem angeschlossenen Display.

Nicht zuletzt ist aber die direkte Anbindung von Tk bei mir der Grund 
gewesen. Ich kenne sonst keine Sprache, in der es so einfach ist, sich 
eine Oberfläche zu erstellen, und zwar "in Echtzeit" im Interpreter - 
und bei Gefallen speichert man einfach ab.

Man kann mit Tcl wunderbar "schnell und dreckig" arbeiten - aber auch 
ausgereifte Programme schreiben :-)

Aber letztendlich nimmt wohl jeder das, was er am besten kennt. 
Tcl/Tk-Code schreibe ich mittlerweile quasi im Schlaf, da werde ich mich 
nicht durch Python oder Perl quälen - zumal ich da keinen Vorteil hätte.
Einem Python-Menschen wird das genau andersherum gehen :-)

[remy (Gast)]

Python.

Vorallem hat es mir das unkomplizierte Filehandling von Python angetan. 
Brauche oftmals die Daten für weitere Verarbeitung (z.B. Diagramme) in 
Excel, mit openpyxl kann man sofort eine xlsx-Datei schreiben, anstatt 
zuerst csv-Datei und diese dann importieren.
Sollte eine GUI nötig sein, dann verwende ich Qt für Python (PySide)...

Und der potentielle Geschwindigkeitsverlust von Python wiegt für mich 
der Gewinn an Produktivität im Vergleich zu z.B. C auf jeden Fall auf.

[Geert H. (geerth)]

Geert H. schrieb:
> Freddy schrieb:
>> Hallo,
>>
>> kleinere Berechnungen programmiere ich beruflich in Matlab.
>> Leider kann ich diese nicht problemlos an Kollegen weitergeben - schon
>> alleine wegen der Lizenz. In Excel sind kleine Berechungen möglich, aber
>> meist alles andere als intiutiv.
>>
>> Wie handhabt ihr das so?
>> Erstellt ihr richtige EXE z.B. in Visual Studio?
>
> Ich empfehle diese Matlab Alternative: Euler Math Toolbox.
>
>  http://euler.rene-grothmann.de/
>
> Nur etwa 80Mb.
> Viele(!) Beispiele von der Autor (er ist Mathematik Professor). Er
> nutzst es für al seine  Kurse und Internetdiscussionen. Alles ist
> besonders gut documentiert.
> Auf Knopfdruck wird von einem Notebook (Berechnung+Grafiken) HTML
> erstelt.
> Interfaces to various external programs (e.g. Latex, Povray, Tiny C,
> Python)
> Free!

Vergleiche EMT mit Scilab, (und Matlab, Octave...)

http://observations.rene-grothmann.de/scilab-versus-euler-math-toolbox/

[MaWin (Gast)]

Freddy schrieb:
> Wie handhabt ihr das so?

Wenn die Oberfläche egal ist: Excel.

Wenn es hübsch sein soll: Javascript in HTML, weil das ohne Server jeder 
als HTA lokal ausführen kann, meist hergeleitet vom Excel Vorgänger.

Kleine Berechnungen heisst keine Vektoren und Matrizen, maximal ein 
(Newton) solver.

So was wie Schaltreglerberechnungen a la Schmidt Walter

[hmm... (Gast)]

Wie oben bereits erwähnt, lua ist auch echt nett.Besonders weil man 
extrem einfach in C eigene Kommandos ergänzen kann die es noch nicht 
gibt. Allerdings war mir die Einschränkung beim File Handling öfter im 
Weg,anscheinend kann man da nur schlecht mit Verzeichnissen arbeiten, 
also aus dem arbeitsverzeichnis wechseln usw.

Von daher bleibe ich für einfache Skripte bei tcl ;)

[Schellomatic (Gast)]

Entweder sh-kompatibles Muschelscript, ansonsten Skriptsprache Deiner 
Wahl, wie Perl, Lua, Io, REXX, Tcl, etc.

Ruby ist cool, btw.

[HW Entwickler (Gast)]

Python +1
Python ist fast unschlagbar in dieser Domäne kleiner (Test)Skripte.
Python ist weniger "schön" wenn's matrizenlastig wird und
bei großer Codebasis muss man mehr aufpassen als bei statischen 
Sprachen.
Aber das war ja nicht deine Applikation.

[Sven B. (scummos)]

HW Entwickler schrieb:
> Python ist weniger "schön" wenn's matrizenlastig wird
Wirklich? numpy ist doch hervorragend ...

[HW Entwickler (Gast)]

Sven B. schrieb:
> HW Entwickler schrieb:
>> Python ist weniger "schön" wenn's matrizenlastig wird
> Wirklich? numpy ist doch hervorragend ...

ich hatte mich da nicht tiefer eingearbeitet und kann daher
nicht beurteilen wie durchdacht oder nicht die Modul-
und die Objektschnittstellen sind. Ich hatte auch keine pretty print
Möglichkeiten genutzt. Ich fand matplotlib sehr bequem und straight
forward (wenn man Matlab kennt). Ich gebrauche Python meist für
parsing und serielle PC-Board Kommunikation zu Testzwecken.

Ruby hat schöne Konstrukte aber dafür zu überladene Schnittstellen.
Es gibt oft gleichnamige Methoden die das gleiche tun. Und nach
meiner subjektiven Meinung waren die Ruby module weniger "aufgeräumt".

Perl spreche ich jetzt nicht an :) Ich frage mich nur ob Perl6
je an Momentum gewinnen wird. Gibt es parrot noch ...

Lua auf dem PC hat meiner Ansicht nach keinerlei Vorteile gegenüber
Python und Ruby. Auf einem ARM System kann Lua dagegen punkten
und ich würde das sehr ernsthaft in Betracht ziehen.
Aber embedded Tauglichkeit war vom TO nicht zur Voraussetzung gemacht.

that's pretty all

[Sven B. (scummos)]

numpy ist halt toll, weil man mit ein wenig Erfahrung damit Code 
schreiben kann, der ungefähr so schnell ist wie äquivalenter Code in C. 
Auf die Art kann man dann auch locker mit einigen MB Daten rumrechnen, 
ohne dass das immer ewig dauert. ipython-notebook ist auch eine ganz 
nette Oberfläche mit Inline-Plots und Cells, wie man das von 
Computeralgebrasystemen kennt. Das nutze ich sehr gern, wenn ich mal was 
ausprobieren will.

[John (Gast)]

Ich benutze XOJO, das ist ähnlich wie Visual Basic.
https://xojo.com
Der Vorteil ist aber, dass es Versionen für MacOS, Linux und Windows 
gibt. Und die größeren Versionen können, auf der jeweiligen Platform, 
Programme für alle drei Betriebssysteme erzeugen.
Bilder von zwei Beispielen im Anhang.

Auch in der Firma erstelle ich damit kleine Hilfsprogramme. Ich hab ein 
Verzeichnis auf dem Server bekommen, wo ich die Programme rein kopieren 
kann. Alle die die Programme brauchen können, haben Leserechte für das 
Verzeichnis. Die Programme können direkt von Server gestartet werden, 
keine Installation erforderlich.

Die erzeugten Programme sind aber recht groß. Selbst so einfache 
Programme wie im Anhang, sind je nach Platform, gleich 3MB-5MB groß.

Jens PICler schrieb:
> Obwohl es bei den "echten" Programmierern uncool ist: VB 2008.

Xojo hieß früher RealBasic. Letztes Jahr wurde der Name geändert. Dazu 
schreiben sie auf ihrer Homepage, dass viele Anwender durch das BASIC im 
Produktnamen abgeschreckt wurden, weil sie damit veraltete Technologie 
assoziieren.
Aber mit

10  FOR I=0 TO 10
20  PRINT "HALLO WORLD"
30  NEXT I
40  END

hat Xojo und auch RB nicht mehr viel gemein.

Gruß
John

[dasw (Gast)]

ist die Testversion limitiert?

[Rolf M. (rmagnus)]

Rene H. schrieb:
> Wenns etwas für unterwegs sein soll, programmiere ich meinen guten alten
> HP48SX, der mir seit dem Studium stets Treu war :-).

Lässt sich übrigens auch in emulierter Form auf dem Android-Handy 
nutzen. ;-)

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

Rolf Magnus schrieb:
> Lässt sich übrigens auch in emulierter Form auf dem Android-Handy
> nutzen. ;-)

Yep, da hat jemand den x48 (X11-Version) auf Android portiert.

Sieht aber bisschen klobig aus, zumindest auf meinem 08/15-Tablet.
Der originale x48 sieht seinem Vorbild noch viel ähnlicher, siehe
Leinwandschuss. ;-)

[John (Gast)]

dasw schrieb:
> ist die Testversion limitiert?

Mit der Testversion lassen sich keine Standalone-Programme erzeugen.
Die erstellten Programme laufen nur im debug-Modus (die IDE muss dazu 
geöffnet sein).

[Klaus I. (klauspi)]

John schrieb:
> Ich benutze XOJO, das ist ähnlich wie Visual Basic.
> https://xojo.com
> Der Vorteil ist aber, dass es Versionen für MacOS, Linux und Windows
> gibt. Und die größeren Versionen können, auf der jeweiligen Platform,
> Programme für alle drei Betriebssysteme erzeugen.

Klingt so ähnlich wie Purebasic. Lebenslange Lizenz für ca. 80 EUR.

> Die erzeugten Programme sind aber recht groß. Selbst so einfache
> Programme wie im Anhang, sind je nach Platform, gleich 3MB-5MB groß.

Hast Du mal mit Purebasic verglichen? IMHO waren da die exe immer sehr 
klein. Habe leider schon lange nichts mehr damit gemacht.