Perl-Hasser unter uns?

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

Vorheriges Thema - Nächstes Thema

mahowi

CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

bartman121

#1
hehe, cool ist aber die "Statistik" ...

https://www.heise.de/meldung/Stack-Overflow-veroeffentlicht-eine-Liste-der-meistgehassten-Programmiersprachen-3877098.html

Wir scheinen uns mit der meistgehassten-Prorammiersprache herumzuquälen.

Ich muss aber sagen, dass perl am Anfang durchaus gewöhnungsbedürftig ist. Das wird hier im Forum dadurch noch verstärkt, dass Profis den Anfängern teilweise codeschnippsel vorwerfen. Es kommt dabei häufig vor, dass die Leute aus Gewohnheit 1Zeilen-Routinen schreiben, statt anfängerfreundlich alles untereinander zu schreiben.

Ich selbst komme aus dem VBA-Lager, habe aber das Talent mich relativ schnell in andere Sprachen eingewöhnen zu können.

Grüße

Andreas

kumue

der statistik-link liefert
404 - File not found

bartman121

geht schon los, sebst für den Forumseditor scheine ich zu doof :D

mahowi

CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

enno

ZitatConclusion

I don't have any interest in "language wars," and I don't have any judgment of users who share technologies they'd rather not work with. Thinking about how polarizing Microsoft technologies often are does encourage me to share my personal experience. I've been a lifelong Mac and UNIX user, and nearly all of my programming in college and graduate school was centered around Python and R. Despite that, I was happy to join a company with a .NET stack, and I'm glad I did— because I loved the team, the product, and the data. I can't speak for anyone else, but I'm glad I defined myself in terms of what work I wanted to do, and not something I wanted to avoid.

... in der Firma muss ich auch Englisch reden, die Arbeit macht aber trotzdem Spass. Bei FHEM ist es halt Perl, was rauskommt, hat aber Suchtpotential...

Gruss
  Enno
Einfacher FHEM Anwender auf Intel®NUC

betateilchen

In der Statistik fehlt ABAP ...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

eisman

Hi,

wir haben doch Meinungsfreiheit,
ich habe mir in den letzten Jahren, einige Programme angeschaut. Weil einige Sachen in FHEM nicht gehen oder sehr kompliziert sind,
ich bin kein Programmierer und muss dennoch sagen, das FHEM mir immer eine Möglichkeit bietet Probleme zu lösen auch ohne
Programmierkenntnisse und was mir eigentlich wichtig ist ohne Internet-Klaut. Auch klasse die Vielfalt an Unterstützten Geräten.
Also ist mir der Name doch echt egal.
Und Leute die mit einer Programmiersprache nicht klar kommen und meckern, 
was auch normal ist, wird es immer geben, weil Schuld ist immer jemand anderes.

gruss
Eddy
1x FHEM Debian, Homematic,ZigBee,FS20 / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian, Homematic,ZigBee         / 1X Raspberry, ConBee / 5x ESP
1x FHEM Debian,MQTT                               / 1X Raspberry, i2c,onewire,gpio
1x auf Windows 2012 Hyper-V-S

Thorsten Pferdekaemper

Hi,

mir ging das so, dass ich Perl am Anfang furchtbar fand, aber inzwischen wächst die Liebe so langsam. Das Entwickeln dauert zwar etwas länger (als z.B. in ABAP), aber es gibt fast nichts, was nicht geht.
Bei Java ging es mir umgekehrt. Am Anfang war ich begeistert, aber inzwischen bin ich froh, dass ich nichts (mehr) damit zu tun habe.

Von wegen ABAP: Ich glaube, dass das in vielen Statistiken nicht auftaucht, weil es auf eine bestimmte Entwicklungsumgebung beschränkt ist, die auch nicht wirklich frei verfügbar ist. Ansonsten finde ich ABAP sehr komfortabel (wenn man mal das Gesamtpaket mit Entwicklungsumgebung, Debugger, SE30/SAT etc. betrachtet).
Hardware-nahe Sachen gehen mit ABAP natürlich nicht wirklich. Man will aber auch eher selten auf einem SAP-Applikationsserver einen GPIO steuern.

Oft bezieht sich die Kritik an einer Programmiersprache auf deren Syntax. Mit der Zeit lernt man aber, mehr oder weniger von der Syntax zu abstrahieren (wenn nicht gerade https://de.wikipedia.org/wiki/Whitespace_(Programmiersprache)).

Gruß,
   Thorsten
FUIP

mahowi

SPL wäre doch auch eine schöne Sprache für FHEM. Da kann man den Quelltext dann auch als Buch verlegen.  ;D
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

CoolTux

Ich liebe Perl. Endlich eine Programmiersprache wo ich mit klar komme. Ok bash ginge auch noch. Aber C oder C++ oder Pascal (später Delphi) oder Java, nee bin ich nie mit warm geworden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

nils_

ähnlich "toll" wie whitespace...
https://de.wikipedia.org/wiki/Brainfuck  ::)


perl ist auch nicht wirklich meine lieblingssprache, da ist mir c / c++ schon lieber.
viele Wege in FHEM es gibt!

MadMax-FHEM

Und ich dachte immer 80% der Programmierung ist unabhängig von der eingsetzten Sprache ;)

Also:

Problem/Aufgabe analysieren

Lösung finden und "beschreiben"

Und dann eben umsetzen in der jeweils "notwendigen" Programmiersprache

Gut beim Finden/Beschreiben der Lösung muss ich evtl. schon im Kopf haben was (welche Konstrukte etc.) in der Umsetzungssprache nicht gehen/anders gehen...
...aber gefühlt liegt der größere Teil der Programmierung in den ersten Beiden Schritten...
...das Umsetzen ist ja dann eher: ok wie geht das noch mal in PROGRAMMIERSPRACHE ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

marvin78

Perl ist ganz ok. Es gibt Bereiche, da möchte ich es nicht mehr missen obwohl ich am Anfang auch oft geflucht habe. Ich komme aus dem php Bereich (ja, haut drauf aber php ist mittlerweile eine brauchbare Programmiersprache - Gegenmeinungen aus Uhrzeiten von php ;)) und damit kommt man gut zurecht. FHEM und perl bilden, wie ich finde, eine gute Einheit und ich bin sehr froh, dass ich mich nicht mit z.B. Java rumschlagen muss.

christiang

#14
Haha, wollte auch gerade ein Topic darüber erstellen, als ich den Artikel auf Heise gelesen hab :)

Wie sagte ein Kollege, als ich ihm vom Fhem erzählt hab und das es in Perl geschrieben ist:

Lässt du 10 Affen unendlich lang auf einer Schreibmaschine tippen, schreibt einer davon Shakespeare, die anderen 9 Perl Code  ;)

Zum Thema: Ich bin beruflich im Umfeld von C++/Java und Python unterwegs, komme aber schon auch mit Perl gut klar. Ich kann aber auch verstehen, dass es für das ungeübte Auge eine sehr verwirrende Sprache sein kann.

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

devo

Zitat von: M.Schulze am 02 Januar 2018, 00:28:48
Wenn man sich die Mühe machen würde FHEM in C zu konvertieren ...

So einfach geht das sicherlich nicht. Siehe folgenden Beitrag: https://www.perl.com/pub/2001/06/27/ctoperl.html/
Perl hat einige Features, die sich nur Aufwendig in C/C++ umsetzen lassen. Um Fhem in C/C++ umzusetzen, müßte man sicherlich einiges komplett neu programmieren und ob der Aufwand gerechtfertigt ist?

Gruß Detlev

M.Schulze

Zitat von: devo am 02 Januar 2018, 08:13:52
So einfach geht das sicherlich nicht. Siehe folgenden Beitrag: https://www.perl.com/pub/2001/06/27/ctoperl.html/
Perl hat einige Features, die sich nur Aufwendig in C/C++ umsetzen lassen. Um Fhem in C/C++ umzusetzen, müßte man sicherlich einiges komplett neu programmieren und ob der Aufwand gerechtfertigt ist?

Gruß Detlev

Ich glaube nicht das der Aufwand für ein absolut minimales System groß ist. Man benötigt ja für initiale Experimente nur Teile der FHEM.pl umgesetzt, ein Telnet-Modul und Test-Modul als Vorlage für weitere. Das ist überschaubar.
Anschließend kommt erst die Arbeit und das System muss halt wachsen. FHEM ist ja auch über Jahre gereift. Erschwerend kommt eher hinzu, das man ja vermutlich mehrere Cores nutzen will und dafür zusätzlicher Code notwendig ist (mit Semaphores arbeiten).

POSIX C hat auch Regex Funktionen
Muss ich das Licht aus machen?

zap

Man würde wohl eher C++ verwenden, wo die Standard Libraries im Prinzip alles mitbringen, was in Perl auch geht.

Das wäre echt ein Traum: Alle Module / Devices laufen in separaten Prozessen/Threads und können sich nicht gegenseitig behindern/zum Absturz bringen. Kommunikation der Module untereinander über einen Messagebus.

Könnte man natürlich auch in anderen modernen Sprachen umsetzen, die das besser unterstützen als Perl. Von mir aus auch in Nodejs oder Python.
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

Thorsten Pferdekaemper

Zitat von: zap am 02 Januar 2018, 12:04:18
Man würde wohl eher C++ verwenden, wo die Standard Libraries im Prinzip alles mitbringen, was in Perl auch geht.
Eine wirklich funktionierende Speicherverwaltung? Debugger?

Zitat
Das wäre echt ein Traum: Alle Module / Devices laufen in separaten Prozessen/Threads
Naja, eher ein Albtraum. Momentan kann man sich ziemlich sicher sein, dass man immer einen konsistenten Zustand vorfindet. Das wäre dann nicht mehr so.

Man könnte natürlich schon so ein System bauen. Aber wäre das dann noch FHEM?

Gruß,
   Thorsten
FUIP

marvin78

Zitat

Man könnte natürlich schon so ein System bauen. Aber wäre das dann noch FHEM?

Nein. Sehr guter Punkt. Das wäre was neues, das dann sicher auch Daseinsberechtigung erlangen kann aber FHEM wäre es nicht mehr.

zap

Zitat von: Thorsten Pferdekaemper am 02 Januar 2018, 12:14:00
Eine wirklich funktionierende Speicherverwaltung? Debugger?

Ja, das soll es in C++ tatsächlich geben ;-). Zumindest benutze ich das seit >15 Jahren zwecks Broterwerb.

Zitat
Naja, eher ein Albtraum. Momentan kann man sich ziemlich sicher sein, dass man immer einen konsistenten Zustand vorfindet. Das wäre dann nicht mehr so.

Der Albtraum ist eher, dass jeder kleine Bug in einem Modul das komplette Smarthome in den Abgrund reißt. Bei getrennten Prozessen oder Threads würde nur ein Teil ausfallen. Und wenn man parallele Programmierung vernünftig einsetzt, hat man auch kein Problem mit inkonsistenten Zuständen.

Aber Du hast Recht: es wäre kein FHEM mehr. Aber wäre das schlimm? FHEM ist Mittel zum Zweck.


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

schnitzelbrain

Würde etwas gegen eine Entwicklung von
C-Fhem ;-D sprechen?
So aus der Urheberrecht Ecke?

Wenn sich doch genug fähige C++ Programmierer mit Zeit und Kenntnissen finden kann doch eine Entwicklung gestartet werden.

Wenn die Maintainer nix dagegen haben, es wird da ja code buchstäblich übersetzt.
Vielleicht dann auch schon mit einigen oft angesprochenen Anpassungen am Frontend /Backend.

Vielleicht dann auch in Git oder so.
Ich sehe halt viele verschiedene Threads mit Themen die sich mit einer Um-entwicklung sicher lösen lassen würden.
Es muss ja kein Rad neu erfunden werden.

Wenn irgendjemand vielleicht mal mit VB6 um die Ecke kommt könnte ich sogar was dazu beitragen. :-O träumen darf man doch.

Grüße

Schnitzelbrain

CoolTux

Kommt es nur mir so vor, das der Thread langsam albern wird?

Plattformunabhängigkeit geht verloren. Man wird abhängig von Systembibliotheken.
Wir wechseln von eine Hochsprache in die Steinzeit zurück. Sowas kann man doch unmöglich wollen. In Perl sind super tolle Projekte entstanden. Ganze Ticketsysteme die selbst in Großkonzernen verwendet werden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

marvin78

Es wird immer ein  paar C(++) Jünger geben, die die Welt verschlimmbessern wollen und keine Ahnung haben, was sie damit anrichten. Diskussionen sind da zwecklos. Mein Vorschlag: FHEM nehmen, "übersetzen" und glücklich werden aber alle anderen möglichst nicht stören. Und ja, auch dieser Beitrag ist so albern, wie einige davor. Nur nicht ganz so undurchdacht.

herrmannj

was wäre denn, mal ganz hypothetisch gesprochen, die Meinung zu FHEM modulen in perl, c und python. Jeweils in einem eigenen thread ? ;)

Gäbe es Developer die bereit wären Ihre Zeit, sehr ernsthaft und selbstlos, zu investieren und die perl _und_ c / perl _und_ phyton echt gut (!) draufhaben ?

justme1968

#40
meine 'haupt' programmier sprache ist auch c/c++, aber ich würde nie auf die idee kommen so etwas wie fhem damit zu entwickeln. weil:
- threads sind eine noch größere katastrophe (mal abgesehen davon das man threads so gut wie nie nie braucht)
- die platform unabhängigkeit ist eine mittlere katastrophe sobald man nicht mehr nur ansi c/c++ ohne externe libs verwendet
- der mögliche geschwindigkeit zuwachs ist in 99.99 aller fälle für einen einsatz wie fhem unnötig
- plugins, paket manager, ... sind wenn überhaupt sehr platform spezifisch
- einen zusätzlichen interpreter (und eventuell sogar compiler) zu integrieren um das von fhem gewohnte verwenden von 'echtem' code in notifys oder myUtils zu verwenden ist ein ziemlicher aufwand
- memory management ist schwer
- ...

eine kompilierte sprache hat absolut keine vorteile die uns hier nützen.


wenn überhaupt wäre node tatsächlich eine wunderbare option. das asynchrone model ist wirklich gut, es gibt viele viele pakte und einen guten paket manager. als interpretierte sprache erlaubt es die gleiche introspektion und einfache erweiterbarkeit durch zusätzlichen code zur laufzeit. es gibt ein paar konzepte an die man sich gewöhnen muss und man sollte sich an ein paar regeln halten.

was man mit node und ein paar nativen c komponenten machen kann sieht man z.b. an atom.io oder dem neuen plexamp player.

aber wie auch immer: die diskussion hier ist zwar ganz amüsant, aber nicht besonders zielführend. so lange sich niemand aus eigenem interesse hinsetzt und etwas neues/anders aus eigenem antrieb und zumindest zu 80% funktionsfähig vorstellt gibt es keinen grund nicht lieber fhem weiter zu entwickeln. es ist schon interessant aus welcher ecke solche diskussionen immer wieder kommen. wie bei den x tot geboren frontends die sich jemand wünscht weil fhem ja so altmodisch ist.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

M.Schulze

Also ich würde an einer zunächst experimentellen Umsetzung in C mitarbeiten. Nicht C++ (also es wäre wohl möglich trotzdem C++ in den Modulen zu verwenden)

Aber das Ziel wäre der Einsatz auf IoT Geräten mit SoC, Linux oder FreeRTOS, die Clients vom konventionellen FHEM sein könnten, oder an Cloud Dienste angebunden werden können.
Zunächst eher für einfache Dinge. Relays, RGB-Controller, Raumsensoren, ...

Amazon ist da ja auch sehr aktiv:
https://www.youtube.com/watch?v=PerMQkl1QkE

Um Mißverständnisse vorzubeugen: Das würde in keinster Weise eine Konkurenz zum jetzigen FHEM darstellen und unter neuem Namen Firmieren.

MFG
Muss ich das Licht aus machen?

herrmannj

Ich sprach von der (hypothetischen) Möglichkeit einzelne Module für FHEM auch in den Sprachen C und python zu erstellen.

justme1968

@M.Schulze: das was du im auge hast sind sensoren und aktoren die daten an fhem senden bzw. kommandos von fhem empfangen. dafür gibt es heute schon mindestens 20 möglichkeiten mit den unterschiedlichsten protokollen in allen nur denkbaren programmiersprachen. auf diesen geräte muss absolut kein wie auch immer abgespeckter teil von fhem laufen. die müssen nur daten liefern und kommandos entgegen nehmen.

da gibt es nichts 'umzusetzen' sondern das muss man einfach nur machen und benutzen.

@herrmannj: welche hypothetischen module meinst du denn hier? so lange es extern ist braucht es nur eines der oben angesprochenen protokolle, sobald es 'intern' und ein echtes fhem modul ist wird es ohne perl schwierig.

das alte sandbox konzept das ich immer noch nicht weiter verfolgt habe würde einzelne module oder gruppen voneinander abschirmen. das ganze ist aber immer noch perl.

die alte idee das longpoll protokoll zu einem echten json aufzubohren und bidirektional zu nutzen habe ich immer noch nicht beiseite gelegt. damit könnte man komponenten bauen die mehr oder weniger lose an fhem gekoppelt sind. völlig unabhängig von der sprache. das funktioniert mit homebridge-fhem und alexa-fhem die komplett in node.js geschrieben sind ziemlich gut.

in beiden fällen geht es mehr um protokolle als um sprachen. und hier ist es normalerweise besser sich so weit wie möglich an standards zu halten statt das rad immer wieder neu zu erfinden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

again: Ich sprach von der (hypothetischen) Möglichkeit einzelne Module für FHEM auch in den Sprachen C und python zu erstellen. Ich spreche nicht davon das ohne perl zu tun. (warum auch ?)

justme1968

dann verstehe ich es nicht :)

wenn nicht ohne perl dann ist es mit perl. und dann brauche ich kein python oder c. zumindest nicht direkt als fhem modul.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

herrmannj

dann solltest Du den titel des threads hier nochmal lesen ;)

andies

Zitat von: justme1968 am 03 Januar 2018, 20:42:10
wie bei den x tot geboren frontends die sich jemand wünscht weil fhem ja so altmodisch ist.
Als Laie würde ich gern wissen, was an Frontend-Entwicklung so schwer ist?
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

herrmannj

Zitat von: andies am 03 Januar 2018, 23:29:18
Als Laie würde ich gern wissen, was an Frontend-Entwicklung so schwer ist?
Und wenn Du nicht als Laie fragen würdest ?

andies

Wüsste ich dann nicht die Antwort?
8)
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

herrmannj

Zitat von: andies am 03 Januar 2018, 23:33:32
Wüsste ich dann nicht die Antwort?
8)
eventuell aus eigener Erfahrung ;) Es ist nicht schwer sondern arbeitsintensiv und man muss kluge und umsichtige Architekturentscheidungen treffen :) Genau dabei übernimmt sich der von Justme1968 gemeinte Laie gern :) Deswegen sehen wir auch so viele "Versuche" und nur wenige Erfolge :)

zap

Zitat von: CoolTux am 03 Januar 2018, 19:14:43
Wir wechseln von eine Hochsprache in die Steinzeit zurück. Sowas kann man doch unmöglich wollen. In Perl sind super tolle Projekte entstanden. Ganze Ticketsysteme die selbst in Großkonzernen verwendet werden.

Verwechselst du da nicht Steinzeit und Hochsprache Bzw kennst du überhaupt C++17, Node, ...?
Solche Lösungen in Grosskonzernen sind meist in der Steinzeit entstanden und werden nur deshalb noch genutzt, weil sie zu eng mit den Prozessen verwoben sind und/oder eine Ablösung zu teuer wäre und/oder der Entwickler in Rente ist. Kenne ich genügend Beispiele aus der täglichen Arbeit

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

vbs

Ok, ich gestehe, ich hasse Perl ein bisschen :P Ich rede hier nur von Perl als Sprache, nicht von FHEM/FHEM-Architektur (sollte man trennen mMn). Bin erstaunt, wie viele Leute hier offenbar in Perl eine moderne Hochsprache sehen. Ich empfinde schon den Begriff "Hochsprache" als recht antiquiert, ungefähr so wie "EDV" ;)

Auch zwingt einen niemand bei C++, Threads zu verwenden, wenn man Bedenken hat, damit ein stabiles System hinzubekommen. Man hat einfach die Freiheit. Ich halte jedoch auch C++ für nicht (mehr) sehr modern (trotz C++11/14/17 etc.).

Mit der Plattformunabhängigkeit von Perl ist es in der Praxis auch nicht sehr weit her, oder? Wie viele Perl-Pakete basieren auf C-Code, der fürs Target kompiliert werden möchte? Ohne einen Linux-Paket-Manager oder cpan hätte man da ziemlich schlechte Karten. Zumindest ersterer installiert aber auch genau so gerne Libraries für C++-Programme.

Abgesehen von dem Perl-Dilemma (:P) ist aber FHEM mMn eine tolle Plattform, die robust, erweiterbar und transparent arbeitet. Macht schon Spaß! :)

justme1968

@zap: so einfach ist das leider nicht.

jedes neue feature das portabilität und rückwärts kompatibilität zu bestehenden installationen verhindert schränkt den potentiellen nutzer kreis deutlich ein.

das kann man natürlich billigend in kauf nehmen und hat am ende weniger arbeit weil es weniger anwender gibt die man supporten muss. wenn man kein verbreitetet system bauen will ist das gut.

oder man muss doch noch irgendwie die alten anwender unterstützen und hat dann doppelten aufwand weil man ein altes und ein neues system pflegen muss.

merke: es ist eine gratwanderung welche neuen features man verendet nicht immer ist das neuste und modernste wirklich das beste. komplette rewrites sind zwar aus entwickler sicht schön aber aus vielen anderen gründen normalerweise ein absolutes no-go.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Zitat von: zap am 04 Januar 2018, 12:08:39
Verwechselst du da nicht Steinzeit und Hochsprache Bzw kennst du überhaupt C++17, Node, ...?
Solche Lösungen in Grosskonzernen sind meist in der Steinzeit entstanden und werden nur deshalb noch genutzt, weil sie zu eng mit den Prozessen verwoben sind und/oder eine Ablösung zu teuer wäre und/oder der Entwickler in Rente ist. Kenne ich genügend Beispiele aus der täglichen Arbeit

Es wird eingesetzt in Großkonzernen. Nicht entwickelt dort.
https://de.wikipedia.org/wiki/Open_Technology_Real_Services
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

hsepm

Meine 2 cent:

Ich bin kein Entwickler, sondern Projektmanager, aber ich habe eine Historie in Java, C++ und Fortran 90.

Perl an sich finde ich nicht das Problem, es sind jedoch die Regular Expressions, die mich (noch) in den Wahnsinn treiben. Es wird noch eine Weile dauern, bis ich mich damit anfreunde.

Derzeit versuche ich, fhem OHNE viel eigenen Perl-Code zu konfigurieren. Hand auf's Herz, das geht schon ganz gut, gerade DOIF ist doch ziemlich mächtig. Ich umschiffe die Regular Expressions meistens oder kopiere gepostete Beispiele ohne große Interpretationsversuche, was erstaunlich gut funktioniert.

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

hsepm

Ich nehme mir in den Ski-Urlaub ein RegEx Tutorial mit, dann werden wir sehen  :D

JoWiemann

Am Besten in eine Cocktail Bar gehen und den Cocktail mit einer RegEx bestellen [emoji23]


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

vbs

Für mich hängt es nicht so an den RegExen, aber die Möglichkeit, an so vielen Stellen eigenen Code on-the-fly einbauen zu können ist wirklich fantastisch. Sowas wäre auch mit C++ wesentlich umständlicher.

hsepm


Benni

Zitat von: JoWiemann am 04 Januar 2018, 16:53:21
Am Besten in eine Cocktail Bar gehen und den Cocktail mit einer RegEx bestellen [emoji23]

Gefährlich! Wenn man da nicht aufpasst hat man *zack* die halbe Cocktailkarte vor sich stehen.  ;D

Na denn prost!  8)

gb#