Perl-Hasser unter uns?

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

Vorheriges Thema - Nächstes Thema

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