Perl-Hasser unter uns?

Begonnen von mahowi, 03 November 2017, 08:24:41

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: Thorsten Pferdekaemper am 03 November 2017, 09:44:19
Hardware-nahe Sachen gehen mit ABAP natürlich nicht wirklich. Man will aber auch eher selten auf einem SAP-Applikationsserver einen GPIO steuern.

Mit SAP Cloud Platform und WebIDE geht inzwischen auch hardwarenahe Programmierung (Stichwort IoT), allerdings derzeit nicht wirklich in ABAP 8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

papa

Ich finde Perl einfach schrecklich und werde wahrscheinlich nie mehr warm damit. Vor allem fehlt mir ein ordentliches OO-Konzept. Und dann gibt es viele Konstrukte, die zwar den Code "schön" kurz machen, aber nicht wirklich zu dessen Lesbarkeit beitragen. Und Lesbarkeit finde ich extrem wichtig. Vor allem in Software, die länger als ein Jahr leben soll und entsprechend gepflegt werden muss. Vor allem das nachgestellte "if" erschwert den Programmfluss zu verstehen. Das erinnert mich immer an die Delay-Slots der Spark-RISC-CPUs.
Aber ich denke, es liegt auch immer daran, wie die Sprachfeatures genutzt werden. C++ Code voll mit Templates und Operator-Overleading versteht auch kein Mensch mehr.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Thorsten Pferdekaemper

Zitat von: betateilchen am 03 November 2017, 10:43:01
Mit SAP Cloud Platform und WebIDE geht inzwischen auch hardwarenahe Programmierung (Stichwort IoT), allerdings derzeit nicht wirklich in ABAP 8)
Ja, klar. Irgendwie geht das schon. Früher war's halt über RFC und JCo.

Zitat von: papa am 03 November 2017, 11:08:16
Ich finde Perl einfach schrecklich und werde wahrscheinlich nie mehr warm damit. Vor allem fehlt mir ein ordentliches OO-Konzept.
Ohne das jetzt im Einzelnen durchgarbeitet zu haben: https://perldoc.perl.org/perlootut.html

ZitatUnd dann gibt es viele Konstrukte, die zwar den Code "schön" kurz machen, aber nicht wirklich zu dessen Lesbarkeit beitragen.
Da gibt es auch wieder verschiedene Philosophien. Am Anfang neigt man dazu, natürlichsprachliche Beschreibungen besser zu verstehen. Ich habe aber auch schön des Öfteren Coding in einen Texteditor kopiert und alle Kommentare rausgeworfen, damit ich verstehe, was da wirklich abläuft.
Wahrscheinlich sieht man irgendwann auch einer RegEx intuitiv an, was sie eigentlich macht.

Zitat
Aber ich denke, es liegt auch immer daran, wie die Sprachfeatures genutzt werden. C++ Code voll mit Templates und Operator-Overleading versteht auch kein Mensch mehr.
Einer der zentralen Sätze der Informatik geht in etwa so: "Wenn ein System mächtig genug ist, um damit sinnvolle Sachen zu machen, dann kann man damit auch Unsinn treiben." Das trifft wohl auch hier zu.

Gruß,
   Thorsten
FUIP

herrmannj

Ich fand perl auch mal schrecklich - aber eigentlich finde ich jede Sprache schrecklich die ich nicht kenne. Dann beschäftigt man sich damit und plötzlich wird es ganz einfach. Dann stellt man plötzlich fest das doch auf einmal ganz viel möglich ist. Das ist für mich mittlerweile eines der perl Pluspunkte. Du kannst Damit eigentlich jeden, noch so kranken Sch..ss (sorry) hinbekommen. Das empfinde ich mittlerweile als Stärke.

Die ganzen kryptischen %$_ Dinger braucht man eigentlich nicht, kann man auch alles "vernünftig" schreiben. In der Regel existiert dazu immer noch eine alternative (sprechende) Schreibweise.

Das OO Konzept ist ganz brauchbar.

Leute die meckern wird es immer geben.

marvin78

So wie es auch verschiedene Vorlieben gibt. Ich kenne auch Leute, die Java lieben. Ich verstehe das nicht aber deshalb gibt es darunter trotzdem Leute, die in anderen Bereichen ganz brauchbar sind  8)

amenomade

Zitat von: betateilchen am 03 November 2017, 09:23:10
In der Statistik fehlt ABAP ...

Jaja.... es fehlen auch COBOL und MARK IV/Vision:Builder... Das liegt daran, dass in diesem Artikel nur die Programmiersprachen mit %dislike/total < 20% aufgelistet sind ;)
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

KölnSolar

... und FORTRAN, PL/1, LISP..... ;)
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wuppi68

Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

andies

Ich kannte Pascal/Delphi und PHP, ein wenig C. Aber was mir bei Perl am Anfang richtig Angst bereitet hat, waren so Sachen wie $@ und @_ oder einfach nur
push
Und ich dachte ,,was soll das denn sein?" Auch finde ich die Hauptreferenz, die beim googeln immer zuerst kommt, schrecklich. Beispiele, die man als Perlexperte sofort toll findet und bei denen man als Anfänger denkt ,,haben die noch alle?"

Inzwischen geht es. Hätte man denn FHEM auch in PHP-MySQL programmieren können? Ich wollte das eigentlich mal in einem Thread fragen.

Wer hat denn das nun geschrieben unter uns?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

betateilchen

Rudi hat die Auswahlkriterien, die seinerzeit zur Entscheidung für perl führten, schon mehrfach erläutert. Damals gab es nicht viele Alternativen.

Heute würde er nach eigener Einschätzung FHEM wohl nicht mehr in perl umsetzen, sondern mit JavaScript bzw. Node.js (*würg*... dann ist mir perl doch lieber)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Thorsten Pferdekaemper

Echt mit Node.js? bisher hatte ich Rudi für ganz vernünftig gehalten. (@Rudi: Bitte nicht zu ernst nehmen...)
Hatte sich die Aussage wegen JavaScript nicht primär auf FHEMWEB bezogen?
Gruß,
   Thorsten
FUIP

blecher-at

Zitat von: betateilchen am 04 November 2017, 14:00:37
Heute würde er nach eigener Einschätzung FHEM wohl nicht mehr in perl umsetzen, sondern mit JavaScript bzw. Node.js (*würg*... dann ist mir perl doch lieber)
;D Perl ist für mich der absichtliche Abenteuerausflug aus meiner sonst heilen Hochsprachenwelt in die männliche, schmutzige, scriptkiddiegeplagte Welt der Scriptsprachen, ohne meinen Verstand sofort mit javascript und seinen noch hässlicheren Derivaten zu verlieren. Es erinnert mich dass wir alle mal ohne threads, memory management, ordentlicher ide, debuggern und ci-system angefangen haben, hält mich gewissermaßen "jung" und lehrt mich meinen dayjob schätzen.

zap

Zitat von: Thorsten Pferdekaemper am 04 November 2017, 18:06:31
Echt mit Node.js? bisher hatte ich Rudi für ganz vernünftig gehalten. (@Rudi: Bitte nicht zu ernst nehmen...)
Hatte sich die Aussage wegen JavaScript nicht primär auf FHEMWEB bezogen?
Gruß,
   Thorsten

Also iobroker läuft ganz gut mit Node.js

Es musste wohl damals unbedingt eine Scriptsprache sein. Wenn es C gewesen wäre, hätte man es heute leichter mit Dingen wie multi Threading.

Aber Perl ist ganz ok, hat halt etwas den Anschluss verloren und führt heute ein Nischendasein. Von den neuen Sprachen gefällt mir Swift am besten. Python wird total gehypt und ist für mich das, was vor 20 Jahren Pascal für einen C Programmierer war: eine Sprache für Hobby Prorammierer bzw ,,Quiche eaters", frei nach:

Real programmers don't use Pascal: http://web.mit.edu/humor/Computers/real.programmers



2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

M.Schulze

Zitat von: zap am 28 Dezember 2017, 21:22:35
Wenn es C gewesen wäre, hätte man es heute leichter mit Dingen wie multi Threading.


Wenn man sich die Mühe machen würde FHEM in C zu konvertieren hätte man ganz neuen Raum für Spielereien. Müsste ja keine 1:1 Umsetzung sein.

Ich spinne mal ein bischen rum:
- FHEM.pl core konvertieren nach C, lauffähig machen unter Linux und für SOCs, z.B. ESP IDF für ESP32
- diverse zweistufige Module schreiben für I2C,SPI, ... (vermutlich Plattformspezifisch), Module nachladbar (Linux) oder bei SoCs im Linkprozess einbinden.
- diverse neue Module schreiben für Hardware die man so an den ESP32 hängen kann z.B. DS18B20,  ...
- Telnet Modul, PWM Modul, Counter Modul, AD-Wandler Modul, WEB-IF Modul ...

Fertig ist der FHEM IoT Client. Könnte dann zunächst auch kommunizieren mit dem konventionellen FHEM Perl Server.
Hardware aus dem Baukasten einfach zusammenstecken und via FHEM.cfg in Sekunden konfigurieren. Sogar im Betrieb.

Machbar ist das, und wäre bestimmt auch professionell einsetzbar. Rechenleistung sollte dann dank C auch für komplexere Dinge ausreichen wie z.B. Audio-Anwendungen und Umgebungsmapping für Roboter.

Stärke wäre die Modularität. Würde dann die projektspezifische Firmware ersetzen, die man in der Regel hat.

MFG

Muss ich das Licht aus machen?

Thorsten Pferdekaemper

Zitat von: M.Schulze am 02 Januar 2018, 00:28:48
Stärke wäre die Modularität.
Tja, die Modularität kommt zum Teil halt auch durch die Sprache. In Perl kann man sehr einfach neuen Code on the run erzeugen und ausführen. Das geht bei C nicht ganz so einfach, da man immer einen Compiler dazu braucht, der nicht unbedingt auf der gleichen Maschine läuft. ...und selbst wenn man den hat, ist es nicht so simpel wie bei Perl.
Gruß,
   Thorsten
FUIP