Mikrocontroller und PHP

小さな猫の女の子 schrieb:
> also der Mikrocontroller ist
> gleichzeitig der Server.

Der Webserver ist da meist gleich das Hauptprogramm.
Da werden auch selten Dateien abgerufen, sondern die Webseite dynamisch 
erzeugt.
Dann kann man gleich die Funktionalität in den Server einbauen.

Ich mache seit Jahren (fast) alle meine Microcontroller-Projekte mit dem 
PocketBeagle bzw. OSD3358. Die 20-30€ die das pro Stück mehr kostet hole 
ich dadurch rein, dass da einfach Linux/Debian drauf läuft, ggf. auch 
mit WiFi-Support. Und wenn man will installiert man einfach Apache + 
PHP.
Das spart hunderte Stunden Entwicklungszeit und Debug-Schnittstellen. 
Selbst hardwarenah, weil der Linux-Kernel für fast alle Schnittstellen 
und Funktionen schon APIs bereitstellt und oft für interessante Chips 
sogar schon Treiber. Und echte Real-Time brauchen die wenigsten 
Anwendungsfälle. Manchmal kann man GPIOs oder I2C oder SPI sogar auch 
aus Shell-Scripts bedienen.
Irgendwo ab ein paar tausend Stück gibt es natürlich einen Break-Even 
über dem ein dedicated-Controller mit RTOS billiger ist. Ein anderer 
Faktor ist wenn das Device batteriebetrieben und möglichst klein sein 
soll. Dann stößt man mit diesem Ansatz an Grenzen.

Ich habe mal einen Webserver fuer einen AVR geschrieben. Dieser 
Webserver kann die Seiten dann ja auch gleich so erzeugen wie es sein 
soll. Wir hatten damals JSON anfragen fuer Hardware Variablen verwendet. 
php macht keinen Sinn.
Wann verwendet man php ?
php bleibt in einem Session kontext, und verschleiert die Konstruktion 
der Seiten. Aus einer Datenbank wird eine kontextabhaengige Seite.

Bei einem controller genuegt ja ein einziger Kontext. Dh ein Rechner 
auf's mal, keine parallelen Verbindungen.

Irgendwelche Rechnereien lagert man gerne per Javascript an den PC aus. 
Der hat genuegend Leistung uebrig.

Wir hatten den Webserver auf AVR an einer seriellen Schnittstelle. Ein 
Ethernet mit Stack haette keinen Sinn gemacht.

PHP ist Overkill..

PHP wird zur Laufzeit übersetzt und man könnte rein theoretisch ein 
Script nativ vorher kompilieren.

Und allein das dann auszuführen wäre wohl schon zuviel für eine MCU. Den 
einzigen Vorteil den PHP hat ist das es mit seinen ganzen Modulen als 
Schnittstelle dienen kann. Ich denke mal man müsste das vielleicht in 
Lua oder Micropython nachbilden. Am besten in C.

Das kommt auf die Applikation an, dann vielleicht nodejs (nur gehört) 
oder so.

Für einen µC ist PHP totaler Overkill. Wie schon gesagt, reich eine 
Session meist aus. Die auszugebenden Websites sind hauptsächlich 
statisch mit eventuell variablen Werten. Datenbankzugriffe gibt es 
nicht. Ein zeitgemäßes Design lässt sich mit Javascript und CSS machen.

小さな猫の女の子 schrieb:
> Ich kann auch nicht genau beantworten, was das PHP machen soll oder für
> was es verwendet wird,

Im Augenblick muss ja für eine Änderung der "Webseite" oder der 
Funktionalität die Firmware für den Controller neu übersetzt und 
geflasht werden.

Das soll wohl entfallen. Blöd ist, das es eigentlich keine normale 
Dateien gibt.

ThomasW schrieb:
> jaja, die ganzen Mausschubser, die das gesamte Backend von Facebook
> geschrieben haben ... was für ein Quark!

Ja.

> In erster Linie ist PHP einfach nur eine Skriptsprache. So wie Python,
> Pearl und Javascript. Ob man Libraries benötigt hängt vom Einzelfall ab,
> ich dachte gerade hier wäre dieses Konzept bekannt!? Außerdem hat PHP
> schon immer ne ordentliche CLI und ist viel mehr als nur eine
> Templateengine.

Äh... räusper Verzeihung, aber... hüstel nein. Leider... machen wir 
das doch einfach mal in Zahlen:

1

/usr/bin/php7.2

2

        linux-vdso.so.1 (0x00007ffcc03f8000)

3

        libargon2.so.0 

4

        libresolv.so.2 

5

        libz.so.1 

6

        libpcre.so.3 

7

        libm.so.6 

8

        libdl.so.2 

9

        libxml2.so.2 

10

        libssl.so.1.1 

11

        libcrypto.so.1.1 

12

        libsodium.so.23 

13

        libc.so.6 

14

        libpthread.so.0 

15

        /lib64/ld-linux-x86-64.so.2 (0x00007fbcbcb68000)

16

        libicuuc.so.60 

17

        liblzma.so.5 

18

        libicudata.so.60 

19

        libstdc++.so.6 

20

        libgcc_s.so.1 

21

/usr/bin/perl5.26.1

22

        linux-vdso.so.1 (0x00007ffea6b6c000)

23

        libdl.so.2 

24

        libm.so.6 

25

        libpthread.so.0 

26

        libc.so.6 

27

        libcrypt.so.1 

28

        /lib64/ld-linux-x86-64.so.2 (0x00007f4f667ed000)

29

/usr/bin/ruby2.5

30

        linux-vdso.so.1 (0x00007ffcffb99000)

31

        libruby-2.5.so.2.5 

32

        libc.so.6 

33

        libpthread.so.0 

34

        libgmp.so.10 

35

        libdl.so.2 

36

        libcrypt.so.1 

37

        libm.so.6 

38

        /lib64/ld-linux-x86-64.so.2 (0x00007fb90ecfb000)

39

/usr/bin/python3.8

40

        linux-vdso.so.1 (0x00007fff06bda000)

41

        libc.so.6 

42

        libpthread.so.0 

43

        libdl.so.2 

44

        libutil.so.1 

45

        libm.so.6 

46

        libexpat.so.1 

47

        libz.so.1

Wissende sehen: PHP benötigt leider immer noch viel mehr Libraries als 
andere Skriptsprachen. Ich persönlich habe da so eine Idee, woran das 
liegt, aber als offensichtlicher PHP-Könner kannst Du mir das sicher 
besser begründen. ;-)

Philipp K. schrieb:
> PHP wird zur Laufzeit übersetzt

Nicht unbedingt. ;-)

NodeJS wäre ja eine Idee auf dem Mikrocontroller wenn man sich schon mit 
Webseitenprogrammierung auskennt: https://www.neonious.com/

Sheeva P. schrieb:
> Nicht unbedingt. ;-)

Caching? :-)

Stefan ⛄ F. schrieb:
> Es wird immer absurder.

Na wenn du meinst, ich hatte ja oben schon geschrieben das es NodeJS 
zwar für Mikrocontroller gibt aber selbst nicht kenne.. als ich dann das 
verlinkte Projekt "LowJS" gesehen habe fand ich das eigentlich keine 
schlechte Idee wenn man Javascript schon beherrscht. Selbst würde ich es 
nicht nutzen, wollte dies aber mal aufzeigen.

小さな猫の女の子 schrieb:
> wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann,
> also zum Beispiel auf einen AVR oder STM, also der Mikrocontroller
> ist gleichzeitig der Server

Ein großer STM32 kann, mit genug externem RAM ausgestattet, Linux 
ausführen. Und wenn man ein Linux hat, sind auch Webserver und PHP 
theoretisch möglich. Sinnvoll ist das in keinem Fall.

ThomasW schrieb:
> jaja, die ganzen Mausschubser, die das gesamte Backend
> von Facebook geschrieben haben ... was für ein Quark!

Erstens läuft das Backend von Facebook nicht auf Mikrocontrollern, 
sondern echt dicken Servern und zweitens läuft das Backend von Facebook 
auch nicht mit dem PHP-Code. Der wird nämlich erst zu C++ transformiert 
und compiliert, bevor er ausgeführt wird.

So ein Ansatz ist mit Mikrocontrollern übrigens auch möglich, weil man 
dann auf den eigentlichen PHP-Interpreter verzichten kann. Für den TO 
allerdings vermutlich trotzdem ungeeignet.

Du hast Facebook als Beispiel genutzt, um damit die Aussage zu 
widerlegen, dass PHP sinnvollerweise eher größere Prozessoren mit 
ordentlichem Betriebssystem (also mindestens Raspberry Pi-Größe) 
braucht.

Und damit zweimal ins Klo gegriffen, denn (a) nutzt Facebook keine 
kleinen Prozessoren und (b) führt Facebook den PHP-Code nichtmal aus.

Jetzt werden hier auch noch die PHP Basics weit vom Thema entfernt 
diskutiert.. Leute das steht in jedem "PHP für Anfänger" Buch im 
Vorwort.

Man kann das ganze auch in SQL Prozeduren auslagern und nur noch Querys 
ausführen. Duck

ThomasW schrieb:
> Sheeva P. schrieb:
>> Wissende sehen: PHP benötigt leider immer noch viel mehr Libraries als
>> andere Skriptsprachen. Ich persönlich habe da so eine Idee, woran das
>> liegt, aber als offensichtlicher PHP-Könner kannst Du mir das sicher
>> besser begründen. ;-)
>
> Benötigt PHP die wirklich, oder wurden die vorm Compilieren ausgewählt?
> Schau dir mal die ganzen Schalter im configure an!

Nunja, bei PHP sind ja viele Dinge bereits im Sprachumfang enthalten, 
für die man anderswo erstmal dynamische Bibliotheken laden muß. PCRE, 
XML, SSL, Crypto, lzma... wenn ich auf das PHP 7.2-Binary auf meinem 
Kubuntu 18.04.5 LTS ein ldd(1) loslasse, spuckt er 19 Libraries aus, bei 
Python3 und Ruby2.5 sind es dagegen lediglich 9.

Ich vermute, daß das Spätfolgen des Designfehlers früherer PHP-Versionen 
sind, die keine Namensräume kannten, und deswegen alles in den globalen 
Namensraum eingebaut hatten. Dabei konnte man schon früher dynamische 
Libraries einbinden, etwa aus dem PECL, aber das zu Ladende wurde da 
über die php.ini konfiguriert und war dann zur Laufzeit immer geladen 
und vorhanden. Wobei der Designfehler ja mittlerweile zum Glück behoben 
wurde, und PHP kann jetzt endlich auch Namensräume -- aber trotzdem ist 
es natürlich absolut verständlich, daß die PHP-Entwickler schon wegen 
ihrer Abwärtskompatibilität keine (oder jedenfalls so wenig wie möglich) 
Funktionen aus dem globalen Namensraum entfernen möchten, weil das zu 
viel existierenden Code zerbrechen und einen Sturm der Entrüstung 
auslösen würde...

> Und zweite Frage: was soll der alberne Angriff?

Wir kommst Du darauf, daß das ein Angriff gewesen sein sollte? Das war 
vollkommen ernst gemeint: offensichtlich benutzt Du aktiv PHP und kennst 
Dich damit vermutlich deutlich besser aus als ich, denn ich habe damit 
nur vor knapp zwanzig Jahren eine Serververwaltungssoftware repariert 
und auf PHP4 portiert, und danach ein Framework mit dem OR-Mapper 
Doctrine -- zu dessen PostgreSQL-Zeitfunktionen ich seinerzeit einige 
dutzend Zeilen beigesteuert habe -- für PHP5 entwickelt.

小さな猫の女の子 schrieb:
> die Frage wurde an mich gestellt und ich konnte diese zu dem Zeitpunkt
> nicht beantworten, deswegen hatte ich die hier gestellt.
>
> Ich kenne mich mit PHP nicht aus und deshalb kann ich diese Frage
>
> Stefan ⛄ F. schrieb:
>> welche Eigenschaft von PHP für dich wichtig ist.
>
> nicht beantworten.

Hallo, nunja... für manche Mikrocontroller gibt es Micropython, das im 
Prinzip eine stark abgespeckte Minimalversion von Python3 ist -- aber 
seinerseits auch schon ein bisschen "Dampf unter der Haube" braucht, 
also meines Wissens mindestens 256k Flash, 16k RAM, und einen 32-Bitter 
(man korrigiere mich, wenn das nicht stimmt).

Möglicherweise, eventuell und vielleicht ließe sich auch ein 
PHP-Interpreter in einer ähnlichen Weise abspecken und mit ähnlichen 
Minimalanforderungen zum Laufen bringen, dazu kann ich keine 
qualifizierte Aussage treffen. Aber das wäre zweifellos ein neues und 
ähnlich umfangreiches Projekt wie Micropython... ich glaube, da wäre es 
einfacher, auf einen RasPi oder einen anderen betriebssystemfähigen SBC 
zu gehen. YMMV! ;-)

Philipp K. schrieb:
> NodeJS wäre ja eine Idee auf dem Mikrocontroller wenn man sich schon mit
> Webseitenprogrammierung auskennt: https://www.neonious.com/
>
> Sheeva P. schrieb:
>> Nicht unbedingt. ;-)
>
> Caching? :-)

Jaein... es gibt Compiler für PHP, zum Beispiel HipHop von Facebook und 
phc. Damit kann man PHP-Code in $Etwas kompilieren -- aber ich weiß 
nicht, in was.

Für Python beispielsweise gibt es verschiedene Möglichkeiten: man kann 
Python in ausführbaren (und ggf. optimierten, aber der Optimizer macht 
wohl nicht allzu viel) Bytecode übersetzen, das kann Python schon in 
seiner Standarddistribution. Man kann es aber beispielsweise mit nuitka 
in C trans- und das dann in nativen Code kompilieren. Zudem gibt es 
dazwischen noch eine Reihe weiterer Möglichkeiten wie etwa py2exe, das 
aber im Wesentlichen nicht com- oder transpiliert, sondern lediglich den 
vorhandenen Python-Interpreter und das angegebene Programm und seinen 
Libraries in ein einzelnes Standalone-Binary verpackt, oder Numba, das 
darauf spezialisiert ist, mathematische Berechnungen in nativen Code zu 
übersetzen.

Ob es sowas auch für PHP gibt, können vielleicht die PHP-Spezialisten 
hier sagen.

ThomasW schrieb:
> Stefan ⛄ F. schrieb:
>> Damit suggerierst du, dass es eine realistische Chance gäbe, PHP auf
>> gewöhnlichen Mikrocontrollern zu verwenden. Also auch ohne
>> Betriebssystem, ohne Datenbank und üblicherweise auch ohne Dateisystem.
>> Wir reden hier von Chips mit weit unter 100kB RAM!
>> Da kommt man mit deiner Methode gar nicht weiter.
>
> War nicht meine Absicht. Denn natürlich haste Recht, das das Quatsch
> ist! Auf nem Mikrokontroller hat ne Skriptsprache mMn. nichts verloren.

Das wiederum ist, bitte entschuldige, meiner Meinung nach -- in dieser 
kategorischen Rigorosität -- Quatsch.

Im Vergleich mit kompilierten Sprachen haben Skriptsprachen spezifische 
Vorzüge und spezifische Nachteile. Der wesentliche Nachteil ist wohl 
meistens, daß sie deutlich umfangreichere Ressourcen zur Laufzeit 
benötigen (mal ganz allgemein gesprochen). Dem gegenüber stehen 
allerdings auch bestimmte Vorzüge, und der wichtigste davon ist wohl, 
daß Skriptsprachen (ebenso allgemein gesprochen) Entwicklungszeit 
sparen.

Das entkoppelt die Frage, welcher Sprachtyp für ein bestimmtes Projekt 
ideal ist, nun  allerdings weitestgehend von den technischen Aspekten 
und macht sie zu einer primär ökonomischen Frage. Dabei hängt es im 
Wesentlichen von den Anforderungen ab, wie die ökonomische Frage zu 
bewerten ist.

Läuft der Code nur auf wenigen Geräten? Kann der Code auf den Geräten 
einfach aktualisiert werden? Werden viele Änderungen am Code pro Woche / 
Monat / Jahr erwartet? Wer mehrere dieser Fragen mit "Ja" beantwortet, 
ist womöglich mit leistungsfähigerer Hardware und einer Skriptsprache 
besser bedient.

Gibt es harte oder weiche Echtzeitanforderungen? Soll der Code auf 
vielen Geräten laufen? Ist es schwierig, den Code zu aktualisieren? Soll 
der Code nur selten geändert werden? In solchen Fällen ist eine 
kompilierte Sprache vermutlich eine bessere Wahl.

Philipp K. schrieb:
> Man kann das ganze auch in SQL Prozeduren auslagern und nur noch Querys
> ausführen.

Das habe ich aus Spaßesgründen vor vielen Jahren mal ausprobiert, und es 
hat prima funktioniert -- aber es war das Gegenteil von performant, und 
beim Entwickeln böse Schmerzen im Gesäß. (Nebenbei: auch OpenLDAP als 
Datenbackend war nicht so der Hit, aber demnächst möchte ich es gerne 
mal mit Elasticsearch ausprobieren...) ;-)

Sheeva P. schrieb:
> aber ich weiß
> nicht, in was.

soweit ich weiß packt das nur das precompiled Binary wie beim Caching 
(oder wie auch immer) mit allen abhängigkeiten in ein Paket... bzw 
HipHop war nur ein Ansatz der nicht weiterverfolgt wurde.

Wie bei den MeinJavaTool.exe Tricks, da wird zum Beispiel ein 
abgespecktes auf die abhängigkeiten ausgelegtes JRE mit eingepackt...

Es gibt auch Programme die holen schon die größe des Fensters und das 
Hauptmenü aus der SQL DB, alles andere ist dann in der DB als Prozedur.. 
Funktioniert, benötigt nur einen vernünftigen Server. Da wäre wohl 
REST/JSON am besten, direkt als SQL Bridge zur MCU.

So, ich öffne diesen Thread erst wieder wenn der Gesperrt ist, dann lese 
ich mit einer Tüte Popcorn weiter :D

MCUA schrieb:
>> Für Python beispielsweise gibt es verschiedene..
> Einrücktiefe als Syntaxbestandteil (!)

Ja, und?

Schau, das hat mich, zugegeben, zumindest am Anfang auch sehr 
abgeschreckt. Aber dann habe ich festgestellt: viele Leute, die ich für 
ausgesprochen kompetent halte, haben offensichtlich keine Probleme damit 
und bieten entweder ein eingebettetes Python oder zumindest eine 
Python-API an. Open- und LibreOffice, zum Beispiel. KDE. Mercurial, 
Blender, Cinema 4D, The GIMP, Boost. Und Unternehmen, von Goldman-Sachs, 
Facebook, Twitter, Google, Ubuntu, SuSE, RedHat, sogar Microsoft... hm. 
Dazu kamen noch einige Freunde vom örtlichen Linux-Stammtisch, von denen 
einige hellauf begeistert und andere zumindest nicht gänzlich abgeneigt 
waren...

Da wollte ich als C-, C++- und Perl-Entwickler, der ich zu der Zeit im 
Wesentlichen war, einfach mal wissen, was es damit auf sich hat. Also 
habe ich mal ein paar Zeilen Programmcode aus einem Tutorial kopiert, 
ein bisschen damit herumgespielt, und sehr schnell festgestellt: diese 
obskure Zeug mit den Einrückungen führt einerseits zu sehr kompaktem und 
andererseits zu sehr lesbarem Code (wobei C, C++ und Perl da ja nun auch 
nicht die besten Beispiele waren und sind...), die Objektorientierung 
war sehr schön und einfach, ich konnte viel schneller entwickeln als in 
C++ und Perl, trotz großer (mehr als zehn Jahre) Erfahrung in den beiden 
Sprachen. Und deutlich performanter als Perl war es obendrein, hatte 
viel mehr nützliche Standardbibliotheken dabei... ich war (und bin es 
bis heute) von Python einfach nur begeistert.

Das ist jetzt... omg, sicher weit über zehn Jahre her, und heute hat 
sich Python zu einer der beliebtesten Skriptsprachen der Welt 
entwickelt. Und immer noch streitet die Welt, ob das nun TROTZ oder 
WEGEN dieser Eigenschaft mit dem syntaxrelevanten Whitespace ist. 
Tatsache ist: Python ist so einfach, daß es in Großbritannien sogar an 
Grundschulen als erste Sprache gelehrt wird, und gleichzeitig so 
mächtig, daß es auch bei den DataScience-Numbercrunchern, GUI-, Spiele- 
und anderen Bereichen, in denen es um hohe Performanz geht, entweder 
sehr beliebt oder sogar das beliebteste Werkzeug überhaupt ist. 
Systemadministratoren schätzen es nicht nur wegen Ansible, Analysten 
wegen Numpy und Pandas, Webentwickler wegen Zope, Plone, Django, und 
Flask, und Datenbankadministratoren, weil sogar Stored Procedures in 
PostgreSQL damit geschrieben werden können.

Du kannst es jetzt machen, wie ich das eine Weile lang gemacht habe, und 
auf Deinen Vorurteilen bestehen. Ich möchte nicht missionieren -- aber 
eine Sprache, die man nicht kennt, mit der man keinerlei Erfahrung hat, 
nur wegen so einer lächerlichen und unwichtigen Äußerlichkeit pauschal 
und rundheraus abzulehnen... das erscheint mir persönlich nicht 
besonders klug. YMMV. ;-)

MCUA schrieb:
>> Wobei der Designfehler ja mittlerweile zum Glück behoben
>> wurde, und PHP kann jetzt endlich auch Namensräume ..
> Und dafür hat es Jahrzehnte gebraucht?

Ja, hat es. Einerseits weil PHP ja zunächst nur als "Personal Home Page 
Tools" von Rasmus Lerdorf geplant war, deswegen hatten die Entwickler 
des Projekts gewisse... Schwierigkeiten mit der Entscheidung, ob es nun 
eine vollwertige Allroundsprache werden, oder doch nur eine einfache 
Sprache zum Coden einfacher Interaktion auf Websites, also etwas wie 
empperl oder eine Art SSI auf Steroiden werden sollte.

Aus... berufenem Mund habe ich auch das Gerücht vernommen, daß einige 
Entwickler des PHP-Interpreters wohl zwischenzeitlich das Projekt 
verlassen hatten, und es deswegen im Projekt niemanden mehr gegeben 
haben soll, der den Code des Parsers verstehen konnte. Keine Ahnung, ob 
das stimmt... "\(".)/"

Wie dem auch sei: ich habe mit PHP gearbeitet und halte es immer noch 
für keine gute Idee, die krude "Stringverarbeitung" von C mit der 
verkopften Objektorientierung von Java in etwas einzubauen, das 
vornehmlich eine gedopte Template-Engine ist. Aber man kann gutes Geld 
damit verdienen, das ist doch immerhin etwas! ;-)

Philipp K. schrieb:
> Sheeva P. schrieb:
>> aber ich weiß
>> nicht, in was.
>
> soweit ich weiß packt das nur das precompiled Binary wie beim Caching
> (oder wie auch immer) mit allen abhängigkeiten in ein Paket... bzw
> HipHop war nur ein Ansatz der nicht weiterverfolgt wurde.

Wie gesagt, das weiß ich nicht. Für mich war PHP zweimal in meinem Leben 
ein Tool, um damit Geld zu verdienen, und wegen meiner Erfahrungen mit 
Perl war ich auch ganz gut damit (das sollen andere beurteilen... aber 
sie haben bezahlt). Trotzdem habe ich natürlich versucht, ein gutes 
Mitglied der Community zu sein, und das, was ich für bestimmte 
Frameworks wie Doctrine entwickelt habe (...mit der Erlaubnis meines 
damaligen Auftraggebers) an die Community zurück zu geben.

> Wie bei den MeinJavaTool.exe Tricks, da wird zum Beispiel ein
> abgespecktes auf die abhängigkeiten ausgelegtes JRE mit eingepackt...

Naja, das ist ja etwas Ähnliches wie das, was py2exe macht, und -- um 
ehrlich zu sein -- löst sowas möglicherweise sehr viele Probleme beim 
Deployment und beim Lifecycle-Management. Und ich weiß, für den 
Entwickler ist so etwas weitgehend irrelevant -- aber für einen Admin, 
der im Zweifelsfalle erstmal Pakete bauen, Abhängigkeitskonfigurationen, 
Paket- oder Docker-Repositories aufsetzen muß...

Bei Java hat mich auch nie die Paketierung gestört, es waren immer 
vielmehr die Web Application Server. Letztes Jahr gab es für eine 
Webapplikation meines Arbeitgebers ausschließlich kommerzielle WAS wie 
JBoss und Websphere -- Wildfly war zu weit und hatte Memory Leaks, 
Tomcat und Glassfish waren nicht weit genug und für produktive Nutzung 
ohnehin ungeeignet, weil es keine Sicherheitspatches gab. Und dann kam 
auch noch diese Sache mit Oracles neuen Lizenzbestimmungen dazu...

> Es gibt auch Programme die holen schon die größe des Fensters und das
> Hauptmenü aus der SQL DB, alles andere ist dann in der DB als Prozedur..
> Funktioniert, benötigt nur einen vernünftigen Server. Da wäre wohl
> REST/JSON am besten, direkt als SQL Bridge zur MCU.

Wie gesagt: BTDT. Macht aber halt keinen Spaß, ne... ;-)

MCUA schrieb:
>>> Einrücktiefe als Syntaxbestandteil (!)
>> Ja, und?
> Habe damit auch programmieren (müssen).
> Einmal Code an andere Stelle verschoben, völlig andere Bedeutung, keine
> Fehlermeldung.
> Bescheuert! Das hat sich ein Id??? ausgedacht.

Merkwürdig, so etwas habe ich noch nie erlebt. Kann es -- ich vermute 
nur -- daran liegen, daß Du es "(müssen)" mußtest?

Nebenbei bemerkt, gab und gibt es an so ziemlich jeder 
Programmiersprache, die ich kann oder mal gekonnt habe, ein paar Sachen, 
die mich manchmal behindert, gestört, oder geärgert haben. Für mich (!) 
ist Python das mit Abstand geringste aller Übel, wenngleich Du ebenso 
frei wie herzlich eingeladen bist, das anders zu sehen. ;-)

Es ist halt nur so, daß persönliche Vorlieben, nunja, persönlich sind, 
und keine sonderlich guten Argumente darstellen. ;-)

Wow, von so 2 Experten, lasse ich mir gerne Sachen erarbeiten....

Es gibt immerhin µ-Python: https://micropython.org/

Stefan ⛄ F. schrieb:
> Sheeva P. schrieb:
>> Da wollte ich als C-, C++- und Perl-Entwickler, der ich zu der Zeit im
>> Wesentlichen war, einfach mal wissen, was es damit auf sich hat.
>
> Soweit war unsere Firma auch mal. Man hat sich das schöne bunte Odoo
> angeschaut. Meine Aufgabe war, ein paar CRM Module von Odoo zu
> erweitern. Am Ende wurden wir alle sehr enttäuscht, vor allem von der
> Performance. Das Programm taugt nur zur Demonstration. Sobald auch nur 5
> Leute damit ernsthaft einen Monat arbeiten, wird es zur Schnecke.

Seltsam, ich kenne drei Unternehmen mit jeweils mehr als 100 MA, die 
odoo verwenden und mit der Performance absolut zufrieden sind. Ein 
Unternehmen, das auf odoo as a Service speziaisiert ist, hostet laut 
deren Angaben etwa 3.000 odoo-Instanzen auf einem Xeon mit sechs Kernen, 
HT und 32 GB RAM, und auch das soll sehr rund laufen. Deswegen frage ich 
mich gerade, ob Ihr vielleicht irgendwas übersehen habt?

Kannst Du mir vielleicht etwas über Euer Setup erzählen, zum Beispiel: 
welches Datenbank-Backend habt Ihr benutzt, wie war es konfiguriert, und 
wie sah das Frontend aus? Besonders die Sache mit der DB würde mich sehr 
interessieren, zumal ich weiß, daß zB. PostgreSQL standardmäßig mit 
EXTREM konservativen Einstellungen ausgeliefert wird und auf moderner 
Hardware nur dann performant läuft, wenn man diese Einstellungen 
entsprechend verändert.

Ansonsten ist Python mit seinem Standard-Interpreter natürlich nicht 
besonders performant, wenn man es mit C oder C++ vergleicht. Aber so 
lahm, wie Du tust, ist es nach meinen Erfahrungen auch nicht, wenn der 
Entwickler weiß, was er tut. Aber das muß er ja überall, nicht wahr?

Stefan ⛄ F. schrieb:
> MCUA schrieb:
>>> Für Python beispielsweise gibt es verschiedene..
>> Einrücktiefe als Syntaxbestandteil (!)
>
> Nicht nur das, auch Leerzeilen gehören zur Syntax.

Das stimmt nicht, wie kommst Du darauf?

MCUA schrieb:
>> Und die Performance ist selbst auf einem Quad Core PC eher traurig.
> Würde sagen, schnarchlangsam.

Genau... deswegen ist Python ja auch gerade in den Anwendungsbereichen 
besonders beliebt und verbreitet, wo es um die Verarbeitung von 
Datenmengen geht, die sich die meisten Mikrocontroller-Entwickler gar 
nicht mehr vorstellen können: im Distributed Computing und im Machine 
Learning gibt es kein ernstzunehmendes Framework, das sich den Luxus 
leisten könnte, keine Python-Schnittstellen zu haben, und im Bereich der 
Data Science ist Python sogar beliebter und verbreiteter als die auf 
dieses Umfeld besonders spezialisierte Sprache R.

Übrigens: mit speziell konstruierten Beispielen performt der 
JIT-Compiler Pypy sogar besser als die äquivalenten Beispiele in C, 
siehe [1] und [2]. Ich persönlich würde mal vermuten: daß Python bei 
Euch nicht performt, liegt nicht an Python. ;-)

[1] 
https://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html
[2] 
https://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html

> Python hat nichts, was man Anders nicht machen könnte.

Ach, wißt Ihr, ich weiß ja nicht, warum Ihr so verbittert und frustriert 
seit. Fakt ist: Auch Eure Unkenrufe konnten nicht verhindern, daß Python 
zur beliebtesten und verbreitetsten Skriptsprache der Welt geworden ist, 
und ich würde jederzeit eine schöne Flasche Scotch darauf wetten, daß 
Euer Gebashe auch in Zukunft nichts daran ändern wird.

Aber in diesem Punkt hast Du Recht: man könnte das mit Python und C 
einfach lassen, und alles einfach in Assembler schreiben. Das Ergebnis 
ist dann bestimmt extremst performant... also, wenn Ihr zu Euren 
Lebzeiten mal zu einem Ergebnis für Aufgaben jenseits von "Hello, world" 
kommt... und ob Euer Ergebnis dann auch nur halb so stabil und 
zuverlässig ist wie der Python-Interpreter, bezweifle ich stark. ;-)

Arduino Fanboy D. schrieb:
> Sheeva P. schrieb:
>> die sich die meisten Mikrocontroller-Entwickler gar
>> nicht mehr vorstellen können
> Einleitung:
> Ich finde es gut, dass du dein Herz für eine Programmiersprache geöffnet
> hast!

Nicht nur für eine, C++ mag ich auch sehr gerne! ;-)

> Kontra:
> Nur, das mit den Äpfeln und Birnen....
> Weder Python noch PHP sind sonderlich gut für "Mikrocontroller"
> geeignet.
> Eher gar nicht.

Naja, wie ich oben schon geschrieben habe: am Ende ist es eine Frage des 
konkreten Anwendungsfalls und seiner ökonomischen Betrachtung. Einfach 
pauschal zu sagen "ist nicht sonderlich gut geeignet für 
Mikrocontroller" finde ich nicht sehr zielführend; Micropython existiert 
und soll sich auf größeren Mikrocontrollern wie dem ESP32 und den 
OpenMV-Kameraboards einiger Beliebtheit erfreuen.

De facto streitet dieses Forum aber schon, seit ich hier mitlese, 
darüber, welche Sprache(n) für die Programmierung von Mikrocontrollern 
geeignet seien. Es gibt da eine nicht sehr große, dafür aber zeitweilig 
sehr laute Gemeinde von Entwicklern, für die selbstverständlich und ohne 
jede Frage nur Assembler in Frage kommt. Eine andere, größere und oft 
noch viel lautstärkere Gemeinde von Entwicklern vertritt hingegen die 
Ansicht, daß C das Einzig Wahre (tm) sei. Die beiden Gruppen liefern 
sich zum Teil sehr erbitterte... "Diskussionen" und hacken dann wieder 
in schönster Einigkeit auf jenen herum, die -- wie ich -- C++ auch für 
die Programmierung von Mikrocontrollern bevorzugen.

Insofern wundert es mich nun wirklich keinen Bruchteil einer Sekunde 
lang, daß bei der Erwähnung einer Skriptsprache auf einem 
Mikrocontrollern genau die "Diskussion" stattfindet, die wir hier sehen. 
Natürlich muß es für Entwickler, die sich mit so "lesbaren" Konstrukten 
in Assembler oder C herumschlagen, wie Blasphemie wirken, wenn wir 
Jungspunde (okay, ich werde im Mai 50) daher kommen und es mit ein paar 
winzigen Tricks schaffen, unseren Code so lesbar zu schreiben, daß ihn 
sogar ein Mensch verstehen kann, der noch nie etwas mit Entwicklung zu 
tun hatte. Insofern verstehe ich den Ärger der Assembler- und C-Freunde 
sehr gut und natürlich auch, warum so etwas wie eine interpretierte 
Skriptsprache auf einem Mikrocontroller diesen Menschen wie ein Sakrileg 
vorkommen muß.

Aber auch wenn ich die Wut verstehe, kann ich sie doch nicht als 
seriöses Argument erkennen. Denn das Zweite, das ich in meiner Zeit als 
Entwickler gelernt habe, ist: verschiedene Werkzeuge haben spezifische 
Vor- und Nachteile, und deswegen kommt es immer darauf an, das richtige 
Werkzeug für einen Anwendungsfall zu wählen. Und sich dabei immer nur 
auf irgendwelche Leitsätze, Glaubenssätze, oder Dogmen zu verlassen, 
halte ich ganz persönlich für unseriös und unprofessionell.

Übrigens habe ich aus meinem Leben noch ein Drittes mitgenommen, nämlich 
die drei wichtigsten Leitsätze der Performanceoptimierung: "Premature 
optimization is the root of all evil" (Donald E. Knuth), "Measure, don't 
guess" (Kirk Pepperdine) und "Make it work, make it right, make it fast" 
(Kent Beck), das Letztere ist bekannt geworden als ein Teil des 
"UNIX-Weges" [1]. Und aus den besagten "Diskussionen" im Forum hier habe 
ich noch etwas Schönes gelernt: "für nichtgenutzte Ressourcen gibt es 
kein Geld zurück". ;-)

[1] https://wiki.c2.com/?UnixWay

Sheeva P. schrieb:
> seit.

Meine Güte... "seid" natürlich, OMG. ;-)

mchris schrieb:
> Diesen Beitrag finde ich zur Diskussion recht passend:
> 
https://www.mikrocontroller.net/attachment/487404/lange_nacht_der_programmiersprachen_dlf_ausschnitt.mp3

Abgesehen von den sachlichen und fachlichen Fehlern des Beitrages habe 
ich leider nicht verstanden, inwieweit er zur Diskussion paßt. Was, 
bitte, meinst Du denn?

Arduino Fanboy D. schrieb:
> Aber alles, was darüber hinaus geht(SkriptSprachen), da muss die
> Hardware schon um (mehrere) Zehnerpotenzen leistungsfähiger sein.

Als was? Als ein AtTiny13? Klar. Hat das jemand bestritten oder auch nur 
bezweifelt? Nicht daß ich wüßte, ansonsten möge man mir bitte einen Link 
geben.

Aber daß die Hardware leistungsfähiger sein muß, ist allein für sich 
doch trotzdem noch kein sachliches Argument. Es sei denn, jemand hätte 
grundsätzlich etwas gegen leistungsfähigere Hardware. Hast Du das? Wenn 
ja, warum? ;-)

Ich bleibe dabei: es kommt immer auf den konkreten Anwendungsfall an.

Stefan ⛄ F. schrieb:
> Und die Performance [von Python] ist selbst auf einem
> Quad Core PC eher traurig.

Erstaunlich positiv überrascht war ich vor vielen Jahren von Perl, 
extrem negativ überrascht von Ruby. Aber Python ist jetzt kein 
besonderes Beispiel von Langsamkeit.

Wenn man damit wirklich große Datenmengen durchnudelt, dann läuft im 
Hintergrund meist sowieso native code, wo es keine Rolle spielt. Ich 
vermute daher, dass bei euch nicht "Python" der Grund, zumindest nicht 
der ausschlaggebende.

Mit der Einrückung muss man sich abfinden. Fand ich anfangs auch 
scheiße, inzwischen nicht mehr. Ist weder gut noch schlecht; andere 
Sprachen (z.B. Kotlin) haben auch ihre festen Ansichten, mit denen man 
sich abfinden muss, wenn man sie benutzen will. Ich mag C, aber wer das 
als ultimativen Maßstab für eine gute Programmiersprache nimmt, sollte 
sich bitte von Computern fernhalten.

MCUA schrieb:
>>> Nicht nur das, auch Leerzeilen gehören zur Syntax.
>>Das stimmt nicht, wie kommst Du darauf?
> Auch wenn es nicht stimmt, ist es bescheuert.
> Die (beschriebene) Fehleranfälligkeit ist da!

Wenn es nicht stimmt - und es stimmt nicht - dann ist es kein Argument.

>>Es bietet sich ASM an, wenn man auf einer Insel wohnen möchte, oder nur
>>zu doof ist, um anständig mit Datentypen hantieren zu können.
> Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein
> Hochsprachen-Programmierer.

Du meinst "word"? Also den einen Integer-Typ, den man in ein Register 
schreiben kann? Weil andere Datentypen gibt es in Assembler nicht. Nur 
verschiedene Instruktionen, die diesen einen Datentyp überall 
unterschiedlich auslegen.

mchris schrieb:
> Sheeva P. (sheevaplug)
>>Abgesehen von den sachlichen und fachlichen Fehlern des Beitrages habe
>>ich leider nicht verstanden, inwieweit er zur Diskussion paßt. Was,
>>bitte, meinst Du denn?
>
> Ich nehme an, du meinst die Anmerkung im Beitrag dass Unix in
> Sieblassblass geschrieben sei. Das ist mir auch etwas sauer aufgestoßen.

Ja, das war einer der Punkte, hinzu kam in dem Zusammenhang auch noch 
der Einspieler von der Dame, die keine Ahnung von C++ hatte und es 
deswegen nicht nur abgelehnt, sondern gleich auch ("häßliche Syntax") 
darauf herumhacken mußte... Ebenso seltsam fand ich die Aussage, BASIC 
sei als eine Art "PR-Maßnahme" entwickelt worden, dabei ging es doch 
vielmehr darum, das Arbeitsgerät Computer auch für Menschen zugänglich 
zu machen, die eben keine studierten Informatiker waren -- ähnlich wie 
das Arduino-Projekt heute die Mikrocontroller-Elektronik für Menschen 
zugänglich machen möchte, die keine E-Techniker oder Informatiker sind. 
Naja, vielleicht habe ich auch einfach den Humor dahinter nicht 
verstanden... ;-)

> Da du Python erwähnt hattest, fand ich den Ausschnitt aus "die langen
> Nacht der Programmiersprachen" von DLF sehr passend, weil die mit Witz
> auf den Kampf zwischen den Anhängern verschiedener Programmiersprachen
> eingehen. In diesem Sinne passt auch "BASIC", dass ja von vielen
> Programmieren als zu einfach erachtet wurde und sich aber genau deshalb
> so weit verbreitet hatte.

Najaaa... als das "originale" BASIC entstand, gab es ja schon andere 
Sprachen, die strukturierte Programmierung ermöglicht haben, ALGOL zum 
Beispiel. Da erschien die BASIC-Lösung mit "GOTO", das letzlich 
Spaghetticode erzwungen hat, nicht schön...

Stefan ⛄ F. schrieb:
> Sheeva P. schrieb:
>> Deswegen frage ich mich gerade, ob Ihr
>> vielleicht irgendwas übersehen habt?
>
> Womöglich hat unsere Projektleitung die hohen Hardwareanforderungen
> nicht hinnehmen wollen. Wir haben es auf einer VM mit 4 CPU Kernen und
> 4GB RAM laufen lassen, so wie fast alle anderen Anwendungen auch.

Najaaa... mit zwei Kernen und 4 GB RAM wart Ihr da nur knapp über dem 
Minimum, 2 Kerne und 2 GB RAM werden für 5 Benutzer als Minimum 
angegeben, empfohlen werden allerdings 8 GB RAM. Und... bitte 
entschuldige, warum richtet Ihr Euch nach Euren anderen Anwendungen 
statt an die Empfehlungen des Herstellers?

> Als Datenbank kam PostgreSQL mit der Standardkonfiguration zum Einsatz,
> lief in der selben VM.

Oh, okay... das ist zwar leider sehr beliebt, aber (fast?) immer ein
Fehler. Wie gesagt, die Standardkonfiguration von PostgreSQL ist für
moderne Maschinen extrem konservativ.

Nun, im PostgreSQL-Wiki gibt es eine Reihe von Links zu verschiedenen
Guides und Tutorials, wie man PostgreSQL optimieren kann. Wenn man ein
PostgreSQL ernsthaft und produktiv nutzen möchte, beginnt das bereits
mit der Auswahl von passender Hardware, aber für ein paar Tests einer
Applikation wird man das wohl nicht wollen.

Nur um ein paar Punkte zu erwähnen: je nach Distribution wird entweder
die Standardkonfiguration aus dem PostgreSQL-Repository paketiert oder
zumindest eine eigene postgresql.conf ausgeliefert wie bei (K)Ubuntu.

Nur um zu zeigen, wie weit die wichtigste Standardeinstellung, nämlich
die Größe des Shared Memory (Konfigurationsoption "shared_buffers")
von optimierten Einstellungen abweicht: in der Standardkonfiguration
des PostgreSQL-Quellcodes steht diese auf 32 Megabyte, unter Ubuntu
sind es immerhin 128 MB. Für ein System mit 4 GB RAM würde dieser Wert
allerdings idealerweise bei etwa 1 GB stehen.

Dazu gibt es allerdings noch einige weitere Möglichkeiten, PostgreSQL
Beine zu machen.

Bekannt sind Indizes, die Lesezugriffe (SELECT) deutlich beschleunigen
können, Schreibzugriffe (INSERT und UPDATE) jedoch etwas verlangsamen
und zudem ihrerseits Arbeitsspeicher oder, wenn man es übertrieben
hat, sogar Festplattenplatz kosten. Neuere Versionen von PostgreSQL
beherrschen dafür allerdings mittlerweile auch Index-Only-Scans, so
daß bei SELECTs, die nur indizierte Spalten betreffen, nicht mehr auf
die tatsächlichen Tabellen zugegriffen werden muß und die Daten gleich
aus dem Index gelesen werden können.

Außerdem gibt es (mittlerweile sogar mehrere) Möglichkeiten, Tabellen
anhand bestimmter Kriterien zu partitionieren. PostgreSQL beherrscht
nämlich etwas, das sich "Vererbung" nennt: Für eine Elterntabelle
werden mehrere Kindtabellen angelegt und eingesetzte Daten anhand des
Partitionierungskriteriums (zum Beispiel Tag oder Monat, das macht
dann auch das Housekeeping einfacher, oder auch anhand eines Feldes
oder eines HAshwerts) auf diese Kindtabellen verteilt. Die Operationen
werden dann nur auf der Elterntabelle ausgeführt und an die Kinder
"verteilt"; neuere PostgreSQL-Versionen können die Zugriffe auf die
Kindtabellen dabei auch parallelisieren. Ein weiterer Vorteil der
Partitionierung ist, daß es keinen riesengroßen Index (der eventuell
nicht mehr in den Arbeitsspeicher passen würde) für die Elterntabelle
gibt, sondern viele kleine Indizes für die Kindtabellen -- und da
PostgreSQL intern Statistiken über die Indexnutzung führt, können
seltener genutzte Indizes der Kinder auf die Festplatte ausgelagert
und die für oft genutzte Kindtabellen im Arbeitsspeicher gehalten
werden -- das funktioniert natürlich am Besten für ein zeitbasiertes
Partitionierungskriterium, was zudem auch noch das Housekeeping der
Datenbank vereinfacht: alte, nicht mehr genutzte Kindtabellen können
dann schnell und einfach gelöscht werden.

Ganz grundsätzlich bietet es sich unter PostgreSQL an, zu langsame
Queries zu loggen ("log_min_duration_statement") oder in den View
"pg_stat_statements" zu schauen. Wer PostgreSQL seriös produktiv
betreiben möchte, dem sei allerdings geraten, sein Logging anhand der
Vorgaben des PostgreSQL-Loganalalyzers "pgfouine" zu konfigurieren und
die Logdateien in regelmäßigen Abständen damit zu analysieren. Dieses
Werkzeug liest die Logdatei und erstellt Statistiken bezüglich der
verwendeten Queries, ihrer Laufzeiten und der Anzahl ihrer Aufrufe,
was wiederum Hinweise darauf liefert, bei welchen Queries womöglich
eine sinnvolle Optimierung ansetzt. Deswegen ist natürlich klar, daß
dieses Werkzeug nur dann sinnvolle Ergebnisse liefern kann, wenn die
analysierten Logdateien unter realen Produktionsbedingungen mit den
realen Produktionsdaten entstanden sind.

Übrigens: PostgreSQL selbst liefert bereits ein gut konfigurierbares
Benchmarkprogramm namens "pgbench" mit aus. Damit kann man den Erfolg
von geplanten Optimierungen prüfen, bevor man sie in die Produktion
übernimmt.

Auch sonst bietet PostgreSQL etliche Möglichkeiten zur Optimierung,
von der Konfiguration der Konstanten des Query Planners, das Ein- und
Ausschalten von bestimmten Scantypen, bis hin zur Konfiguration der
PostgreSQL-internen Statistiksammlungen. Man kann sogar das fsync(2)
nach jedem Write oder das Write-Ahead-Log ausschalten (was ich bei
einer Applikation wie einem ERP, das auf maximale Datenintegrität
angewiesen ist, allerdings nicht empfehlen würde).

Aus meiner eigenen Erfahrung kann ich vom Fall eines us-amerikanischen
Versicherungskonzerns berichten. Nach Inbetriebnahme unserer Software
auf einer ziemlich großen Maschine begann die Applikation zu lahmen,
nachdem die Datenbank mit etwa 30 GB Daten beschickt worden war. Nach
unseren Performancetuning war die Datenbank zuletzt gute 970 GB groß
und hatte keine Performanceprobleme mehr, auf derselben Hardware. Dies
nur, um die Größenordnung zu zeigen, die möglich sein können.

Auch Python kann man sehr deutlich beschleunigen, zum Beispiel, wenn
man nicht den (nicht auf Performance, sondern auf Korrektheit
optimierten) Standardinterpreter durch den wesentlich schnelleren
Interpreter Pypy mit JIT-Compiler ersetzt. Der wirkt zwar erst nach
einiger Zeit, kann die Performance aber um den Faktor drei bis zehn
verbessern, je nach konkretem Anwendungsfall. Leider finden sich im
Netz allerdings nur Benchmarks für den Standardinterpreter, was der
Sprache leider häufig (die Blogosphäre hat ein laaaanges Gedächtnis)
den Ruf eingebracht hat, nicht besonders performant zu sein. Neben
Pypy gibt allerdings auch den Java-Interpreter Jython, der zudem den
großen Vorteil hat, nativ aus Python heraus auf Java-Code zugreifen zu
können, sowie den .NET-basierten Interpreter Ironpython, der dasselbe
mit dem .NET-Framework beherrscht.

Zudem -- nur eine Anregung -- ist es nach meinen Erfahrungen keine so
gute Idee, Applikation und Datenbank auf derselben Hardware oder VM
laufen zu lassen. Dann konkurrieren die beiden Prozesse im Prinzip um
dieselben Ressourcen, die sich aufgrund widerstrebender Ziele leider
auch nicht wirklich für eine der beteiligten Anwendungen optimiert
konfigurieren lassen. Je nach Umfang des Datenverkehrs zwischen der
Webapplikation und dem Datenbank-Backend kann es dabei auch sinnig
sein, eine performantere Netzwerkanbindung anstelle von dem üblichen
Gigabit Ethernet einzusetzen... aber nicht zum Testen, klar.

> Ich glaube dir ja, dass man da einiges noch tunen kann. Aber auch
> funktional hat das Paket nicht überzeugt. Unser Kunde hätte es genommen,
> wenn 80% der gewünschten Funktionen schon drin gewesen wären. Aber das
> war halt nicht der Fall. Am Ende haben sie sich für eine komplett neue
> Anwendung in Java entschieden (an der arbeitet mein Team seit 1,5
> Jahren). Da spielt sicher auch eine Rolle, das sowohl unsere Entwickler
> als auch die des Kunden sich mit Java EE viel besser auskennen. Python
> wäre Neuland gewesen.

Nunja, ich würde sicherlich sehr lange und intensiv nachdenken, bevor
ich eine Entscheidung wie Eure treffe. Anstatt als Basis eine Software
in Python zu benutzen, die schon -- sagen wir -- 50% der Anforderungen
erfüllen kann (und die ihrerseits erweiterbar ist), entwickelt Ihr
eine vollständig neue Software... Das erscheint mir nur dann sinnvoll,
wenn man keine Python-Expertise im Hause hat (oder man als externer
Dienstleister lieber einen großen Entwicklungsauftrag an Land zieht
anstelle eines kleinen Wartungsvertrages, nix für ungut). ;-)

Nunja, wie auch immer: Ich habe leider nicht gerade den Eindruck, daß
Deine letzten Ausführungen Deine frühere Aussage bestätigen, Python
sei per se langsam. Ein an eine relationale Datenbank "angeschlossene"
ERP-Umgebung wird meiner Erfahrung nach ohnehin den größten Teil ihrer
Laufzeit mit dem Warten auf das Datenbank-Backend verbringen -- und
das bisschen Ausfüllen von kompilierten Templates mit den Daten aus
der Datenbank ist dabei meist relativ vernachlässigbar. Bei meinen
Web-Applikationen haben die Datenbackends jedenfalls meistens sehr
viel mehr Last und einen viel höheren Anteil an der Gesamtperformance
als Applikation, Webserver, und Reverse Proxy.

S. R. schrieb:
> Stefan ⛄ F. schrieb:
>> Und die Performance [von Python] ist selbst auf einem
>> Quad Core PC eher traurig.
>
> Erstaunlich positiv überrascht war ich vor vielen Jahren von Perl,
> extrem negativ überrascht von Ruby. Aber Python ist jetzt kein
> besonderes Beispiel von Langsamkeit.

Naja, seinerzeit war einer der weniger wichtigen Gründe, von Perl zu 
Python zu wechseln, daß Python (damals) erheblich performanter war als 
Perl, Ruby, und PHP. Wichtiger war mir allerdings die klare, 
pseudocodeähnliche Syntax, mit der ich mir keine Gedanken mehr machen 
mußte und muß, wie ich meine Ideen formuliere, sondern sie direkt aus 
meinem Gehirn in den Editor gießen kann...

> Mit der Einrückung muss man sich abfinden. Fand ich anfangs auch
> scheiße, inzwischen nicht mehr.

Es hängt natürlich auch davon ab, ob man einen ordentlichen Editor 
benutzt... Mit Notepad.exe macht das sicherlich keinen Spaß. ;-)

MCUA schrieb:
>> ich mir keine Gedanken mehr machen
>> mußte und muß, wie ich meine Ideen formuliere, sondern sie direkt aus
>> meinem Gehirn in den Editor gießen kann...
> Oh Schreck.
> Was haben die Leute denn die letzten 50 Jahre gemacht?

Länger nachdenken müssen als ich das mittlerweile muß. ;-)

Stefan ⛄ F. schrieb:
> Sheeva P. schrieb:
>> Einen endlosen Roman
>
> Bitte nimm es mir nicht übel, aber wenn ich Hilfe zu Oddo/Python
> brauche, mache ich das in einem eigenen Thread.

Dabei ging es allerdings im Wesentlichen um PostgreSQL.

小さな猫の女の子 schrieb:
> Ich kann auch nicht genau beantworten, was das PHP machen soll oder für
> was es verwendet wird, da ich mich damit nicht auskenne. Die Frage kommt
> von meinem Kollegen mit dem ich das Projekt zusammenbetreibe. Er hat
> auch die Dateien für die Webseite geschrieben.

Du bist also nicht fähig deinen Kollegen zu fragen und diese Frage hier 
weiterzuleiten? 100 Trollpunkte! Und noch 42 für den Fakt, dass 
anscheinend der Falsche hier fragt und so praktisch die wichtigste Frage 
(dem  exakten Verwendungsgrund für PHP auf einer MCU) gekonnt als nicht 
beantwortbar suggeriert. Was für ein Zufall?!

Ein weiterer Grund, dass dieses Unterfangen Blödsinn sein könnte ist die 
Größe der Binärdistribution von PHP (ohne dem entsprechenden Gerüst zur 
Ausführung von PHP). Viel Erfolg das auf einen Mikrocontroller zu 
bringen.

Meiner Meinung nach bist Du im falschen Ökosystem und solltest die oben 
genannten Alternativen nutzen. Für 142 Trollpunkte gibt es übrigens 
Beratungsresistenzseife und eine Flasche Schnaps-Idee. Gratis dazu: Das 
Teamfähigkeits-Dosentelefon:P

MCUA schrieb:
>>Wenn es nicht stimmt - und es stimmt nicht - dann ist es kein Argument.
> Doch, die Endekennung fehlt!
> (Wäre gut für Boing, um noch weitere Abstürze zu produzieren )

Du entscheidest auch sonst auf Basis von Aussagen, von denen du weißt, 
dass sie falsch sind? Klingt, als ob du in erster Linie von großer 
Intelligenz beseelt bist. /s

Sheeva P. schrieb:
> Naja, seinerzeit war einer der weniger wichtigen Gründe,
> von Perl zu Python zu wechseln, daß Python (damals) erheblich
> performanter war als Perl, Ruby, und PHP.

Hmm, also bei meinen letzten Vergleichen hat sich Perl deutlich 
schneller durch die Textdateien gebissen als Python; das war aber auch 
massives Regex-Foo. Mit Ruby und PHP arbeite ich nicht, daher kann ich 
die nicht vergleichen.

S. R. schrieb:
> Sheeva P. schrieb:
>> Naja, seinerzeit war einer der weniger wichtigen Gründe,
>> von Perl zu Python zu wechseln, daß Python (damals) erheblich
>> performanter war als Perl, Ruby, und PHP.
>
> Hmm, also bei meinen letzten Vergleichen hat sich Perl deutlich
> schneller durch die Textdateien gebissen als Python; das war aber auch
> massives Regex-Foo. Mit Ruby und PHP arbeite ich nicht, daher kann ich
> die nicht vergleichen.

Naja, ich habe das seinerzeit mal gemacht, und damals (lange her) wies 
Python2 tatsächlich die höchste Performanz auf. Aber: die anderen haben 
wohl mittlerweile deutlich aufgeholt... zumindest gegenüber dem 
Standardinterpreter. ;-)

Ob sie auch mit Pypy mithalten können? Hmmm... Bei Regular Expressions 
würde ich das aber mal stark annehmen, schließlich ist Python die 
einzige dieser Sprachen, bei der die Regex-Engine kein fest 
einkompilierter Teil des Sprachkerns ist.

Stefan ⛄ F. schrieb:
> Sheeva P. schrieb:
>> Aber: die anderen haben wohl mittlerweile deutlich
>> aufgeholt...
>
> So ist es. In einer Phase als es um Perl bereits ziemlich ruhig wurde,
> fanden noch erstaunlich weit reichende Optimierungen statt. Ich habe das
> auch nur zufällig mitbekommen als ich mal Gigabytes von Textdateien
> analysieren musste. Normalerweise mache ich das mit awk, aber irgend ein
> Feature fehlte mir dort, deswegen wich ich auf Perl aus - und wurde
> positiv überrascht.

Lustigerweise hat nach meinem Eindruck erst die hohe Performance von 
Python einige der Skriptspracheninterpreter dazu animiert, an der 
Performance zu schrauben. Aber es ist schon ein gewisser Anachronismus, 
daß wegen der schwächeren Hardware die Performance des Interpreters viel 
wichtiger war als heute und zumindest der Standardinterpreter von Python 
nicht viel an der Schraube gedreht hat.

Übrigens, was so RegEx-Engines angeht, habe ich vor einiger Zeit mal ein 
paar kleine Experimente mit der RegEx-Engine von C++ gemacht und 
festgestellt, daß das gute alte grep(1) immer noch um Größenordnungen 
schneller war...

> Dennoch gammelt Perl auch bei mir in einer einsamen Nische herum, aus
> der es nur selten heraus geholt wird.

Ach, ich benutze perl(1) auch nurmehr (meist mit -pe) als Filter auf der 
Shell, das ist für mich meistens einfacher als grep(1), awk(1) und 
sed(1).