Forum: PC-Programmierung Mikrocontroller und PHP


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 小さな猫の女の子 (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Hallo zusammen =^.^=

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.

Momentan sind die Dateien für die Webseite auf einer SD-Karte 
gespeichert und werden einfach zum Client geschickt, sprich Java, CSS, 
HTML usw.

Mit dem PHP wäre nur so ein "nice to have" , aber nicht notwendig, läuft 
auch so alles wie es soll.

Danke schon mal für Eure Antworten, Fragen werden natürlich so gut es 
geht beantwortet =^.^=

P.S. Ich hoffe, es ist der richtige Bereich für die Frage.

: Verschoben durch Admin
von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Du könntest die Server-Logik auch in C/C++ als Teil des Webservers 
implementieren.
PHP auf einem Mikrocontroller scheint ansonsten eher Gebastel zu sein.
Und außer einer etwas abstrakteren Sprache hätte es gegenüber dick auch 
nicht viele Vorteile, oder?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
PHP braucht dicke Kisten mit Betriebssystem.
Meist auch noch, plus irgendeine Datenbank.
Je mehr Ram, desto besser.

Minimalgröße dürfte die Raspberry Klasse sein.

von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo jemand,

inwie weit mir PHP Vorteile bietet, kann ich nicht genau beantworten, da 
ich mit jemand zusammen das Projekt mache und er vorallem das mit der 
Webseite gemacht hat und mich gefragt hat, ob es eventuell möglich wäre.

Aber du würdest davon abraten bzw. sagen, dass es nicht möglich ist?

von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Arduino Fanboy D. ,

wenn man die stärke eines RaspBerry benötigt, dann ist PHP wohl nichts.
Da ein RaspBerry rausfällt,da ein RaspBerry ein viel zu großer Overkill 
ist, betrachtet auf das große Ganze.

Ich danke für die Antworten =^.^=

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe auf die schnelle zumindest keine PHP-Portierung für 
Mikrocontroller gefunden. Vielleicht gibt es sowas irgendwo, die Chancen 
sind aber gut, dass man dann auch viel mit dem PHP-Interpreter selbst 
kämpft. Die Portierung dürfte auch nicht ganz trivial sein.

Ich persönlich würde obigen Ansatz wählen.

von Stephan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
小さな猫の女の子 schrieb:
> ob PHP auf einem Mikrocontroller laufen kann, also
> zum Beispiel auf einen AVR oder STM, also der Mikrocontroller ist
> gleichzeitig der Server.

Selbst wenn es ein PHP für µC gäbe: wie sieht der gesamte Use-Käs aus? 
z.B. "wie kommt" ein potenzieller Benutzer denn auf die WebSite? -> Aha, 
Du brauchst einen TCP/IP Stack nebst WebServer auf dem µC. Auch einen 
"Stecker wo das Internet rein geht"(;) solltest Du vorsehen...
Kann man alles bauen (z.T. in den verfügbaren RTOS Portierungen 
enthalten), macht aber vermutlich nicht viel Sinn.
Wie bereits von Arduino Fanboy D. empfohlen: RPi wäre wohl (so denn der 
Use-Käs wirklich so ist wie ansatzweise beschrieben) sinnvoll!

VG Stephan und 3 匹の猫からの挨拶

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt schon Durchaus fertige TCP/IP-Stacks vor allem für entsprechende 
STM32F4xx. Und mit entsprechenden Baustein geht das auch am AVR, siehe 
Arduino Ethernet Shield. Je nach Nutzerzahl und sonstiger Elektronik ist 
ein Raspberry da echt ein Overkill. Und es geht auch ohne RTOS.

von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Stephan,

ich komme mit deiner Antwort nicht so ganz zurecht.

Stephan schrieb:
> Selbst wenn es ein PHP für µC gäbe: wie sieht der gesamte Use-Käs aus?
> z.B. "wie kommt" ein potenzieller Benutzer denn auf die WebSite? -> Aha,
> Du brauchst einen TCP/IP Stack nebst WebServer auf dem µC. Auch einen
> "Stecker wo das Internet rein geht"(;) solltest Du vorsehen...
> Kann man alles bauen (z.T. in den verfügbaren RTOS Portierungen
> enthalten), macht aber vermutlich nicht viel Sinn.

Soll ich dazu sagen, wie es bei mir momentan abläuft oder war das nur 
ein Beipiel von dir wie es womöglich aussieht oder aussehen soll?
Mit RTOS ist Multitasking gemeint oder?

Stephan schrieb:
> Wie bereits von Arduino Fanboy D. empfohlen: RPi wäre wohl (so denn der
> Use-Käs wirklich so ist wie ansatzweise beschrieben) sinnvoll

Das verstehe ich von deiner Antwort, aber da muss ich leider dazu sagen, 
dass ein RaspBerry rausfällt, da belasse ich es so wie es momentan ist.

Grüße an die Katzen zurück =^.^=

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
小さな猫の女の子 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.

von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo jemand,

das ist bei mir der Fall, der RaspBerry ist für meine Anwendung ein 
absoluter Overkill.
Zumal wir eine eigene Platine erstellen und per Hand löten. Auch HDMI 
oder so wird nicht benötigt.

von STK500-Besitzer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
jemand schrieb:
> Es gibt schon Durchaus fertige TCP/IP-Stacks vor allem für entsprechende
> STM32F4xx. Und mit entsprechenden Baustein geht das auch am AVR, siehe
> Arduino Ethernet Shield. Je nach Nutzerzahl und sonstiger Elektronik ist
> ein Raspberry da echt ein Overkill. Und es geht auch ohne RTOS.

Was hat das mit PHP zu tun?

TCP/IP Stacks sind schon "ewig" auf Mikrocontrollern verfügbar (Damals 
noch mit ISA-Netzwerkkarten als Netzwerkzugang).
Dann kamen solche Sachen wie "Siteplayer" oder Lantronix "xport" auf den 
Markt. Das war vor ca. 20 Jahren.

php braucht einen Interpreter, und der kostet Kapazität, die erst aber 
einer bestimmten Controller-Größe vorhanden ist.

von Nick M. (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
小さな猫の女の子 schrieb:
> wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann,

Schau dir an wie CGI funktioniert. Dann geht es.

von Nikolaus S. (Firma: Golden Delicious Computers) (hns)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Nikolaus S. und Nick M. ,

ich werde mir mal CGI anschauen, ob mir das weiterhilft.

Der PocketBeagle ist auch interessant, aber soweit ich gesehen habe, 
eventuell für zukünftige Projekte.

Danke für die ganzen Antworten =^.^=

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STK500-Besitzer schrieb:
> jemand schrieb:
>
>> Es gibt schon Durchaus fertige TCP/IP-Stacks vor allem für entsprechende
>> STM32F4xx. Und mit entsprechenden Baustein geht das auch am AVR, siehe
>> Arduino Ethernet Shield. Je nach Nutzerzahl und sonstiger Elektronik ist
>> ein Raspberry da echt ein Overkill. Und es geht auch ohne RTOS.
>
> Was hat das mit PHP zu tun?
> TCP/IP Stacks sind schon "ewig" auf Mikrocontrollern verfügbar (Damals
> noch mit ISA-Netzwerkkarten als Netzwerkzugang).
> Dann kamen solche Sachen wie "Siteplayer" oder Lantronix "xport" auf den
> Markt. Das war vor ca. 20 Jahren.
> php braucht einen Interpreter, und der kostet Kapazität, die erst aber
> einer bestimmten Controller-Größe vorhanden ist.

Das war auf Stephans Beitrag bezogen, der ja wegen TCP/IP direkt auf 
einen Raspberry gehen wollte.

von jemand (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie viel

Nikolaus S. schrieb:
> 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.

Wie viel Zeit man damit So spart, hängt auch mit der Übung auf 
Mikrocontrollern zusammen, die man so hat. Ich bin mir ziemlich sicher, 
dass ich insbesondere Kleinkram mit einem Mikrocontroller schneller 
lösen könnte.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
小さな猫の女の子 schrieb:
> wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann, also
> zum Beispiel auf einen AVR oder STM,

Nein.

PHP ist ein, wie bei heutigen Mausschubsern üblich,  Rechenleistung und 
Resourcen verschwendendes Monster, dass vor allem von seiner Umgebung 
lebt, also den per Library hinzugezogenen Funktionalitäten  die ein 
ganzes Unix/Windows ähnliches Betriebssystem erfordern.

Kleinster Prozessor dafür ist so was wie ein rPi.

von Pandur S. (jetztnicht)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von ThomasW (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
MaWin schrieb:
> 小さな猫の女の子 schrieb:
>
>> wollte mal fragen, ob PHP auf einem Mikrocontroller laufen kann, also
>> zum Beispiel auf einen AVR oder STM,
>
> PHP ist ein, wie bei heutigen Mausschubsern üblich,  Rechenleistung und
> Resourcen verschwendendes Monster, dass vor allem von seiner Umgebung
> lebt, also den per Library hinzugezogenen Funktionalitäten  die ein
> ganzes Unix/Windows ähnliches Betriebssystem erfordern.
> Kleinster Prozessor dafür ist so was wie ein rPi.

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

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.

Auf nem Mikrokontroller hat PHP für mich aber trotzdem nichts zu suchen. 
Gerade weil ich so viel damit zu habe, aber auch weil ich gar keine 
keine Notwendigkeit erkennen kann. Um Daten zum Client zu schicken 
braucht es weder Javascript noch HTML noch CSS. Da genügt einfaches 
JSON.

von Philipp K. (philipp_k59)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nick M. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
ThomasW schrieb:
> Da genügt einfaches JSON.

Dafür genügt das HTTP das sowieso schon da sein muss.
Und für den Austausch in beide Richtungen PUT und GET.
Einfacher gehts nicht.
Und wenn man kapiert hat wie CGI funktioniert (was simpel ist) dann 
bekommt man das ohne Bloatware auf dem µC zum laufen.

von ThomasW (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nick M. schrieb:
> ThomasW schrieb:
>
>> Da genügt einfaches JSON.
>
> Dafür genügt das HTTP das sowieso schon da sein muss.
> Und für den Austausch in beide Richtungen PUT und GET.
> Einfacher gehts nicht.
> Und wenn man kapiert hat wie CGI funktioniert (was simpel ist) dann
> bekommt man das ohne Bloatware auf dem µC zum laufen.

Ich glaube, ich würde es sogar noch einfacher machen: statt nem PUT ein 
GET mit query-Parametern (dafür findest du reichlich fertige Beispiele 
für nen ESP. Das bekommt sogar ein Anfänger in C/C++ hin). Ist eben 
immer die Frage, was brauchst du wirklich und was muss das Teil am Ende 
alles können. Das hat der TE aber leider nicht so genau beschrieben.

von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Guten Abend zusammen,

Nick M. schrieb:
> Und für den Austausch in beide Richtungen PUT und GET.
> Einfacher gehts nicht.

Momentan läuft das auch so ab, es wird ein GET angefordert vom Client 
und darauf wird geantwortet und dann werden eben neue Daten oder eben 
die Dateien für die Webseite gesendet. Ansonsten macht der 
Mikrocontroller nichts oder etwas anderes, da die Webseite lokal beim 
Client läuft.

ThomasW schrieb:
> Ist eben
> immer die Frage, was brauchst du wirklich und was muss das Teil am Ende
> alles können. Das hat der TE aber leider nicht so genau beschrieben.

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.
Wie im Einganspost geschrieben funktioniert alles auch und das PHP ist 
keine Vorraussetzung, es geht mehr darum, ob es prinzipiell möglich ist, 
egal was das PHP am Ende bezwecken soll.

Aber so wie es klingt, ist die Leistungssärke eines Pies notwendig, 
außer ich habe jetzt etwas übersehen oder überlesen.

von Christian H. (netzwanze) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
小さな猫の女の子 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.

von Arduino Fanboy D. (ufuf)


Bewertung
-2 lesenswert
nicht lesenswert
小さな猫の女の子 schrieb:
> außer ich habe jetzt etwas übersehen oder überlesen.
So langsam, kommst du mir etwas quengelig vor, als wollte es dir nicht 
in den Kopf, dass PHP auf µC fürchterlich unsinnig ist.

Dirk B. schrieb:
> 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.

Dagegen gibts sd-karten und SPIFFS
Ja, man kann damit nicht jede Änderung abfangen, aber zumindest alles, 
was mit dem Aussehen zu tun hat.

: Bearbeitet durch User
von Voyager 2 (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Sorry, aber für einen brauchbaren Webserver mit PHP und MySQL würde ich 
zu einem Atom raten. Ein Raspi ist da zu schwach auf der Brust.

von Voyager 2 (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Ergänzug: Posfix, etc. und paar nette Tools gehören ohnehin auf eien 
Webserver mit drauf.

von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> So langsam, kommst du mir etwas quengelig vor, als wollte es dir nicht
> in den Kopf, dass PHP auf µC fürchterlich unsinnig ist.

Das tut mir natürlich leid, so wollte ich nicht klingen.
Ich habe das auch schon verstanden, dass es unsinnig ist bzw. nicht 
möglich.

Arduino Fanboy D. schrieb:
> Dagegen gibts sd-karten

Und so wird es momentan gemacht, dort liegt eine Java Datei und CSS und 
Fonts oder wie das heißt und die werden dem Client nach einer GET 
Anfrage geschickt und die Seite läuft lokal bei dem Client.

Ich wollte lediglich die anderen Fragen beantworten, vielleicht wäre ja 
noch etwas interessantes dabei rausgekommen.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Etwas moderner wären noch Websockets, auch das geht mit 
Mikrocontrollern. Und auch ein REST API kann Daten liefern. Es wird nur 
häufig auf geänderten Code hinauslaufen und damit sind Änderungen nicht 
so einfach wie auf einem dickeren OS.
Vielleicht geht mit microPython mehr, aber damit habe ich mich noch 
nicht näher beschäftigt.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Philipp K. schrieb:
> PHP wird zur Laufzeit übersetzt

Nicht unbedingt. ;-)

von ThomasW (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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! Und zweite Frage: was 
soll der alberne Angriff? Hatte dich eigentlich als sachlichen User in 
Erinnerung ...

von Spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

Erinnert mich irgend wie an QBasic gegen QuickBasic. Wer hat von den 
beiden gewonnen?

MfG Spess

von MaWin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
ThomasW schrieb:
> was soll der alberne Angriff?

Du meinst:

ThomasW schrieb:
> was für ein Quark!

Wer so desinformationsverbreitend auf (meinen) Beitrag antwortet, darf 
sich nicht wundern wenn jemand die Fakten zur Richtigstellung als 
Antwort postet (Dank an Sheeva).

Wenn dich Fakten stören: kritisiere nicht den Überbringer der Nachricht, 
arbeite lieber an deinem (Un)Wissen.

von Stefan ⛄ F. (stefanus)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
小さな猫の女の子 schrieb:
(Frage zu PHP auf µC)

Also PHP gibt es vermutlich nicht für Mikrocontroller. Leider hast du 
nicht gesagt, welche Eigenschaft von PHP für dich wichtig ist.

Falls es dir darum geht, Programmcode in HTML Dateien einzubetten:
Das würde ich auf den Client auslagern. Der Mikro-Webserver könnte diese 
von einer SD Karte aus an den Browser liefern. In der Seite befindet 
sich Javascript (statt PHP), welche dynamische Inhalte per AJAX Request 
nachlädt. Der Code auf dem Mikrocontroller könnte sich dann auf diese 
kleinen Datenschnipsel beschränken. Das können wahlweise HTML Fragmente 
sein, oder etwas Datenstrukturen in JSON, die dann vom Javascript 
geparst und gerendert werden.

Eventuell magst du dir mal meinen embedded Webserver anschauen
http://stefanfrings.de/net_io/index.html, von dem der obige Screenshot 
kommt.

Die HTML Datei enthält Platzhalter, welche während des Auslieferns der 
Seite vom Server (also dem µC) durch ein generiertes Textfragment 
ersetzt wird. In dem Seitenquelltext rufen die Platzhalter "%! name" 
jeweils eine C Funktion auf und "%!: name" inkludiert eine statische 
HTML Datei (da ist auch das Navigationsmenü drin).

Das Formular in der Seite ruft eine weitere C Funktion über AJAX 
(Javascript, HTTP Request) auf und fügt die Response in die Seite ein.

Damit hast du zwei Methoden, die auf Mikrocontrollern in dieser 
Größenordnung (mit weniger als 100kB RAM) realistisch umsetzbar sind. 
Das ganze ist bei weiten mich so leistungsfähig wie PHP.

: Bearbeitet durch User
von 小さな猫の女の子 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan ⛄ F. ,

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.
Deshalb wollte ich es nur allgemein wissen, ob es möglich wäre und 
darauf wurde schon öfters die gleiche Antwort gegeben.

Das was du danach geschrieben hast, ist auch momentan der Stand der 
Dinge wie es bei uns funktioniert.

Trotzdem danke ich dir für die Antwort und allen anderen auch =^.^=

Vielleicht könnte ein Mod diesen Thread hier schließen, da dazu alles 
gesagt worden ist, zumindest meiner Ansicht nach.

von ThomasW (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
MaWin schrieb:
> Wenn dich Fakten stören: kritisiere nicht den Überbringer der Nachricht

Welche Fakten meinst Du - das mit den Mausschubsern oder das Märchen, 
dass PHP immer sämtliche verfügbare Extensions im Bauch haben muss?

Okay, also Fakten: warum ist das Standardpaket von PHP so fett? Nicht 
weil das zwingend so sein muss. Sondern weil da alles reingepackt wird, 
was der übliche User im Webumfeld so nutzt. Sieht man gut an der Liste 
die weiter oben gepostet wurde. Da waren nur bei PHP libssl, libxml und 
ähnliche vorhanden. Eben weil das bei der üblichen Verwendung Sinn 
macht.

Aber jedem steht frei sich seine PHP Engine zu bauen. Mit nur den Libs, 
die man wirklich braucht. Das ist wirklich simpel, dazu braucht es kein 
Spezialwissen. Deshalb ist die Aussage, dass PHP zu umfangreich sei, 
eben Halbwissen. Als würde jemand behaupten Linux wäre nicht für den 
Serverbetrieb geeignet, weil KDE so fett sei.

von Philipp K. (philipp_k59)


Bewertung
0 lesenswert
nicht lesenswert
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? :-)

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
ThomasW schrieb:
> Aber jedem steht frei sich seine PHP Engine zu bauen.
> Mit nur den Libs, die man wirklich braucht.
> Deshalb ist die Aussage, dass PHP zu umfangreich sei,
> eben Halbwissen. (usw und so fort)

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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Philipp K. schrieb:
> NodeJS wäre ja eine Idee auf dem Mikrocontroller wenn man sich schon mit
> Webseitenprogrammierung auskennt

Es wird immer absurder. Hast du schon einen Javascript Interpreter auf 
einem Mikrocontroller gesehen?

Ich meine nicht einen in der Größenordnung vom Raspberry Pi oder ESP32, 
sondern etwas in Richtung ATmega328 oder meinetwegen auch einen Boliden 
wie den STM32F4.

: Bearbeitet durch User
von Nick M. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Es wird immer absurder.

So ist es halt bei den Mausschubsern. Keine Grundlagen, daher muss alles 
immer komplizierter werden.

von ThomasW (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

Deshalb hab ich für den konkreten Fall hier, weiter oben, auch einen 
anderen Weg skizziert. In der der uC nur eine simple RESTful-API 
anbietet. Mit ein bisschen Arbeit bekommt man sogar ne HTML Seite hin, 
in der das notwendige JS eingebettet ist. Dazu braucht es dann 
vermutlich auch externen Speicher (ne SD-KARTE zum Beispiel). Aber 
natürlich ist das weit entfernt von: ich schiebe ein fertiges Projekt 
mal eben auf nen Mikrokontroller.

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Es wird immer absurder. Hast du schon einen Javascript Interpreter auf
> einem Mikrocontroller gesehen?
Auch (viele) Mikrocontroller können riesige Mengen an (ext.)MEM 
ansprechen.
Frage nur, ob sowas Sinn machen würde.

von Philipp K. (philipp_k59)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
MCUA schrieb:
> Auch (viele) Mikrocontroller können riesige Mengen an (ext.)MEM
> ansprechen. Frage nur, ob sowas Sinn machen würde.

Man kann auch auf einem Drucker Doom spielen.

Fehlt "nur" noch jemand, der einem den ganzen Kram portiert. Nnicht 
Doom, das hat tatsächlich schon jemand gemacht, sondern das PHP und 
seine Voraussetzungen meine ich.

Ein Klacks ist das, alles ganz easy. Lass die Maker mal machen.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Philipp K. schrieb:
> LowJS

Das läuft auf einem ESP32 Modul und belegt 3 Megabyte Flash!
Das ist schon kein gewöhnlicher Mikrocontroller mehr sondern so ziemlich 
der größte denn es meines Wissens nach in bezahlbar gibt. Leider hat 
sich der TO nicht dazu geäußert, an welche Hardware er konkret dachte.

: Bearbeitet durch User
von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Man kann GB's an Mikrocontroller dran bauen, wenn es sein muss...

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Man kann auch zu Fuß nach Singapur reisen

von MCUA (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> Man kann auch zu Fuß nach Singapur reisen
Statt der Zusatz-Kleiderkosten kann man Flash kaufen (wenn man will)

von MaWin (Gast)


Bewertung
2 lesenswert
nicht lesenswert
ThomasW schrieb:
> Aber jedem steht frei sich seine PHP Engine zu bauen. Mit nur den Libs,
> die man wirklich braucht.

PHP ohne Libs ist ziemlich witzlos, das ist ja der Nutzen von PHP 
gegenüber shell-Skripten, und die meisten Libs sind ohne Betriebssystem 
nicht einsetzbar.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
小さな猫の女の子 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.

von ThomasW (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> 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.

Das habe ich beides nie behauptet (meine Aussage war, dass der Code in 
PHP geschrieben ist). Einfach mal lesen was ich tatsächlich geschrieben 
habe ... aber das betrifft nicht nur dich ... schönen Sonntag noch!

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Philipp K. (philipp_k59)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Nick M. (Gast)


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

Da würde ich dann doch Nägel mit Köpfen machen und den Server auf dem µC 
in PL/SQL schreiben.

von MCUA (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> Du hast Facebook als Beispiel genutzt, um damit die Aussage zu
> widerlegen, dass PHP sinnvollerweise eher größere
Eine CPU weiss weder was von C noch von PHP.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
小さな猫の女の子 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! ;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> Für Python beispielsweise gibt es verschiedene..
Einrücktiefe als Syntaxbestandteil (!)

von MCUA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> 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?

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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...) ;-)

von Philipp K. (philipp_k59)


Bewertung
0 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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. ;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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! ;-)

von MCUA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>> 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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Stefan ⛄ F. (stefanus)


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

Nicht nur das, auch Leerzeilen gehören zur Syntax. Völlig gaga. Und die 
Performance ist selbst auf einem Quad Core PC eher traurig.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von 小さな猫の女の子 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bei Python den Einrückzwang bzw. Bedeutungsänderung anhand der 
Einrückung finde ich persönlich nicht schlimm, sondern eher gut. Zumal 
man sich daran doch gut daran gewöhnt. Man darf natürlich aber auch 
nicht mit der Einstellung rangehen, Python ist blöd, der Einrückzwang 
ist blöd und dies und jenes, dann kann man mit Python natürlich nicht so 
gut umgehen.

von Mario X. (grinderfx)


Bewertung
-1 lesenswert
nicht lesenswert
Wow, von so 2 Experten, lasse ich mir gerne Sachen erarbeiten....

von MCUA (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> Einrücktiefe als Syntaxbestandteil (!)
Wegen dem fehlenden Abschlusszeichen steigt die Fehleranfälligkeit mit 
zunehmender Einrücktiefe! Und man kriegt (insbes. beim Umstrukturieren) 
keine Fehlermeldung! (was nicht da ist kann man nicht beanstanden)
Sowas bezeichne ich als syntakt. Schwachsinn.

von MCUA (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
> Tatsache ist: Python ist so einfach, daß es in Großbritannien sogar an
> Grundschulen als erste Sprache gelehrt wird,
Lernt man dort auch Mikroprozessortechnik?

von Oliver S. (phetty)


Bewertung
1 lesenswert
nicht lesenswert
Es gibt immerhin µ-Python: https://micropython.org/

von MCUA (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
> Und die Performance ist selbst auf einem Quad Core PC eher traurig.
Würde sagen, schnarchlangsam.
Python hat nichts, was man Anders nicht machen könnte.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
MCUA schrieb:
> Python hat nichts, was man Anders nicht machen könnte.

Ich betrachte es als nachfolger von Perl. Wobei Perl inzwischen in der 
Bedeutungslosigkeit verschwunden ist.

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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?

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Sheeva P. (sheevaplug)


Bewertung
2 lesenswert
nicht lesenswert
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. ;-)

von Arduino Fanboy D. (ufuf)


Bewertung
-1 lesenswert
nicht lesenswert
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!

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

: Bearbeitet durch User
von mchris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.
>...
>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

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

von Sheeva P. (sheevaplug)


Bewertung
4 lesenswert
nicht lesenswert
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

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> seit.

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

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> De facto streitet dieses Forum aber schon, seit ich hier mitlese,
> darüber, welche Sprache(n) für die Programmierung von Mikrocontrollern
> geeignet seien.
Natürlich!
Die Auswahl ist begrenzt, und der Priester Trieb ausufernd.
Es bietet sich ASM an, wenn man auf einer Insel wohnen möchte, oder nur 
zur doof ist, um anständig mit Datentypen hantieren zu können.

Klar dann gibts noch C und C++!

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

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von mchris (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

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.

Der Radiobeitrag ist übrigens 3 Stunden lang und ich kann ihn sehr 
empfehlen. Es geht von den ersten Rechenmaschinen bis zu den modernen 
Programmiersprachen. Etwas später gibt es sogar ein paar Sätze zu PHP ( 
ich bin aber gerade zu faul, das zu kopieren ).

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
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.

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

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.

Aber interessantes Neuland, deswegen hatte ich mich darauf eingelassen.

: Bearbeitet durch User
von MCUA (Gast)


Bewertung
-7 lesenswert
nicht lesenswert
> Weder Python noch PHP sind sonderlich gut für "Mikrocontroller"
> geeignet.
Stimmt

>> 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!

> Aber alles, was darüber hinaus geht(SkriptSprachen), da muss die
> Hardware schon um (mehrere) Zehnerpotenzen leistungsfähiger sein.
Sagt offensichtl. jemand, der keine MCUs kennt (kennen will).


>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.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
MCUA schrieb:
> Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein
> Hochsprachen-Programmierer.

Die wären?

von Jemand (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> MCUA schrieb:
>> Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein
>> Hochsprachen-Programmierer.
>
> Die wären?

Kleine Klappe, mittlere Klappe, große Klappe, riesengroße Klappe, 
exorbitantgroße Klappe, ... :D

SCNR.

von MCUA (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
>> Bloss kennt ein ASM-Programmierer ca 50x mehr Datentypen als irgent ein
>> Hochsprachen-Programmierer.
> Die wären?
Alle möglichen, beliebig zusammenbaubar, was so in Hochsprachen nicht 
möglich ist.


> Kleine Klappe, mittlere Klappe, große Klappe, riesengroße Klappe,
> exorbitantgroße Klappe, ... :D
Dumme Klappe.

von STK500-Besitzer (Gast)


Bewertung
3 lesenswert
nicht lesenswert
MCUA schrieb:
> Alle möglichen, beliebig zusammenbaubar, was so in Hochsprachen nicht
> möglich ist.

So, wie structs in C?

von S. R. (svenska)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von MCUA (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
> Weil andere Datentypen gibt es in Assembler nicht.
ja, die Erde war schon immer eine Scheibe


>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 )

> Fand ich anfangs auch scheiße, ..
warum wohl.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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ß. ;-)

von MCUA (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
> 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?

von Sheeva P. (sheevaplug)


Bewertung
3 lesenswert
nicht lesenswert
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ß. ;-)

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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. Brauche ich aber gerade 
nicht, weil das Management dagegen entschieden hat. Es macht auch keinen 
Sinn, mit mir zu diskutieren, ob die Leute gut oder schlecht entschieden 
haben. Wichtig ist, dass sie mir Arbeit beschaffen, und das haben sie 
getan.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Bewertung
-5 lesenswert
nicht lesenswert
小さな猫の女の子 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

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nick M. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
小さな猫の女の子 schrieb:
> da
> ich mit jemand zusammen das Projekt mache und er vorallem das mit der
> Webseite gemacht hat und mich gefragt hat, ob es eventuell möglich wäre.

Jedzia D. schrieb:
> Du bist also nicht fähig deinen Kollegen zu fragen und diese Frage hier
> weiterzuleiten? 100 Trollpunkte!

Hat er doch klar kommuniziert: Er weiß es nicht wozu. Es war nur eine 
prinzipielle Frage die ganz schnell mit "Nein" beantwortet wurde.

Bis die üblichen Kasperln eine Diskussion um $irgendwas daraus gemacht 
haben.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

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

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.