Hallo!
Wie ist Eure Meinung zur Erstellung dynamischer Webseiten?
Nehmt Ihr PHP oder Perl?
( Die vielen anderen Möglichkeiten möchte ich mal außen vor lassen )
Es sollen eine private Wetterstation auf einem kleinen 24/7-Miniserver
mit dyndns erstellt werden.
Von PHP liest man öfter von Sicherheitsproblemen....
Ist Perl da "more safe"?
Ein CMS soll aber erst gar nicht zum Einsatz kommen.
THX
Marco
perl finde ich etwas old school.
wenn, dann gleich ruby.
php ist auch recht alt, mehr für CMS auf simplen hosting paketen
geeignet.
was ganz toll und hipp ist: node.js - den server in javascript
schreiben. klein, schlank, skalierbar. wäre meine wahl für die nächsten
projekte, abgesehen von php mit nginx als webserver.
Ich schlage vor, Du nimmst die Sprache, die Du wirklich beherrschst.
Das Wichtigste: Validierung der Inputs (Stichwort: Remote File
Inclusion)
Zwar stimme ich zu, dass die idiotische Funktionalität von fopen in PHP
Sicherheitslücken begünstigt hat, die für Millionen gehackter Webserver
verantwortlich sind. Der eigentliche Fehler war aber auch dabei
schlampiges Programmieren.
Ein gut geschriebenes PHP-Script ist besser als ein vergurktes
Perl-Unglück.
Von Old Style und Programmierparadigma du Jour braucht sich niemand
beeindrucken lassen. Ich habe schon viele Moden kommen und gehen
gesehen, ein Allheilmittel war nicht dabei.
> ( Die vielen anderen Möglichkeiten möchte ich mal außen vor lassen )
Das solltest du nicht tun.
Stattdessen solltest du Python mit in die engere Wahl nehmen.
Vorteile gegenüber PHP & Pearl:
* lesbarer Code
* Eine Sprache für fast alles (Scripte, GUI, Numerik, Web, ...)
Thomas schrieb:> Vorteile gegenüber PHP & Pearl:> * lesbarer Code
**räusper** Ich habe auch schon hinreichend unlesbaren Python-Code
gesehen. ;-)
Unlesbaren Code kann man nun wirklich in jeder Sprache verfassen,
und man kann auch in jeder lesbar schreiben, wenn man es nur will.
> * Eine Sprache für fast alles (Scripte, GUI, Numerik, Web, ...)
Was soll daran nun anders als bei anderen Scriptsprachen sein?
Versteh' mich nicht falsch, ich habe nichts gegen Python(*), aber diese
Evangelismus-Mentalität nervt. Tritt komischerweise bevorzugt bei
Python-Jüngern auf (oder fällt mir bei denen besonders auf?).
(*) OK, fast nichts, wenn man von der Signifikanz von Leerzeichen
absieht.
Alexander T.-Z. schrieb:> Ich schlage vor, Du nimmst die Sprache, die Du wirklich beherrschst.
Das finde ich den bislang sinnvollsten Vorschlag.
Ich hab da noch eine andere Herangehensweise an die Wahl der
Programmiersprache vorzuschlagen:
> Es sollen eine private Wetterstation auf einem kleinen 24/7-Miniserver> mit dyndns erstellt werden.
Ich vermute mal, daß es sich hierbei um die bekannten WH1080/ Oregon
Sicentific etc. handelt, die es mit USB-Anschluß (oder älter: mit RS232)
gibt. Weiterhin willst du sicher etwas einfaches wie eine modifizierte
FritzBox oder ein Raspberry Pi als Miniserver verwenden.
Von daher: Schau, ich welchen Sprachen entsprechende Programmpakete
schon existieren und wie gut diese auf deinem Server installierbar sind.
Für die WS gibt es Perl-, PHP- und Python-Scripte mit mehr oder weniger
dem, was du suchst. Auf dem Raspi wirst du sicher Python vor Perl/PHP
wählen, während es bei de FB wohl eher Perl oder PHP ist. Tipp: es gibt
kleine standAlone-Perlscripte mit gerade mal 10kbyte, die einen
kompletten Webserver mit ca 200kbyte Ramverbrauch darstellen. Sowas
gibts auch unter Python und vielleicht sogar unter PHP. Der Clou: du
hättest die Dynamik der Seite "auf dem kleinen Dienstweg" erledigt, ohne
groß ein CGI-interface mit allem Drum und Dran zu implementieren.
Schau einfach, was am besten zur vorhandenen Ausstattung passt.
Und seien wir mal ehrlich: jemand, der auf einer Minimaschine wie dem
Raspi für sowas Apache + PHP + X + (+Mysql) installiert, der hängt an
seinen VW Lupo auch einen Wohnwagen und fährt damit ins Gebirge. :)
>> * Eine Sprache für fast alles (Scripte, GUI, Numerik, Web, ...)> Was soll daran nun anders als bei anderen Scriptsprachen sein?
Also, ich bin über NumPy / SciPy nach Python gekommen.
Später habe ich auch kleine GUIs mit PyQt und WXPython implementiert.
Z.Zt. arbeite ich mich in die Webprogrammierung mit Django ein.
Ich bezweifle doch sehr, dass PHP oder Perl ähnlich vielseitig sind.
Nicht wegen der Srache an sich, sondern wegen der Libs, Bindings und der
Community.
> Versteh' mich nicht falsch, ich habe nichts gegen Python
Und wenn schon.
> aber diese Evangelismus-Mentalität nervt.
Dein Problem.
> Tritt komischerweise bevorzugt bei Python-Jüngern auf> (oder fällt mir bei denen besonders auf?).
Vielleicht hat das ja auch andere Gründe - denk mal drüber nach...
> OK, fast nichts, wenn man von der Signifikanz von Leerzeichen absieht.
Diese Meinung taucht grundsätzlich in jeder Python Diskussion auf.
Allerdings nur von denen die diese Sprache noch nie verwendet haben.
Allen anderen ist das keine Diskussion wert.
>> Ich schlage vor, Du nimmst die Sprache, die Du wirklich beherrschst.> Das finde ich den bislang sinnvollsten Vorschlag.
Dem OP entnehme ich, dass Marco wahrscheinlich keine der Sprachen
beherrscht und daher unsicher ist mit welcher er einsteigen soll.
Sollte diese Vermutung stimmen, dann ist der Vorschlag tatsächlich wenig
sinnvoll.
Weiterhin entnehme ich dem OP und der Tatsache, dass wir hier auf uc.net
sind, dass es Marco in erster Linie um die technische Anwendung geht.
Möglicherweise studiert er auch. Vielleicht wird er sich als nächstes
(wenn die Wetterstation läuft) mit einem Raspberry Pi beschäftigen.
Und unter dieser Annahme wäre sicher Python der bislang sinnvollste
Vorschlag.
Denn im technisch / wissenschaftlichen Bereich ist Python nun mal die
mit Abstand verbreitetste dynamische Sprache, da kannst du die Luft
anhalten bis du rot anläufst.
Marco H. schrieb:
> Von PHP liest man öfter von Sicherheitsproblemen....
Das ist totaler unsinn! Nicht die Sprache ist schuld an den
Sicherheitsproblemen, sondern die Programmierer. Wenn man vom User eine
Eingabe entgegen nimmt und die ohne Prüfung direkt in eine Datenbank
schreibt... ja, was soll ich dazu sagen? Da ist mit sicherheit nicht die
Sprache dran schuld. Die Sprache gibt dir alle Mittel und Wege die du
brauchst, wenn man die Mittel aber nicht anwendet ist man selber schuld.
Die Aussage ist vergleichbar mit:
Pointer in C/C++ sind pöse und gefährlich, und in die pösen
Bufferoverflows...!
Ja, das stimmt wohl. Wenn man aber nicht weiß was man tut, ist auch eine
Bastelschere für 3-Jährige eine Gefahr!
In diesem Sinne
Grüße
Kaj schrieb:> Marco H. schrieb:>> Von PHP liest man öfter von Sicherheitsproblemen....>> Das ist totaler unsinn! Nicht die Sprache ist schuld an den> Sicherheitsproblemen, sondern die Programmierer.
Klar, man kann in PHP auch sicher programmieren. Nur tut die Sprache
garnichts dazu das zu erleichtern. Im Gegenteil. Hinter jeder Ecke
lauert eine neue Falle, und man muss als Programmierer immer tausende
von "historisch gewachsenen" Bugs und Eigenheiten im Hinterkopf
behalten.
Einem Anfänger sollte man das nicht antun.
Thomas schrieb:>>> * Eine Sprache für fast alles (Scripte, GUI, Numerik, Web, ...)>> Was soll daran nun anders als bei anderen Scriptsprachen sein?> Also, ich bin über NumPy / SciPy nach Python gekommen.
Gut, das Argument lass ich gelten.
(Evangelismus)
>> Tritt komischerweise bevorzugt bei Python-Jüngern auf>> (oder fällt mir bei denen besonders auf?).> Vielleicht hat das ja auch andere Gründe - denk mal drüber nach...
Ja. Diejenigen sehen Python offenbar nicht als Werkzeug, sondern
als Religion an. Nachdem sie diese Religion dann einmal für sich
entdeckt haben, müssen sie alle anderen auch davon überzeugen.
Dass sie dabei der Sache eher schaden als nutzen, merken sie
natürlich nicht.
>> OK, fast nichts, wenn man von der Signifikanz von Leerzeichen absieht.> Diese Meinung taucht grundsätzlich in jeder Python Diskussion auf.> Allerdings nur von denen die diese Sprache noch nie verwendet haben.> Allen anderen ist das keine Diskussion wert.
Dann kannst du jetzt bei „Allen“ ein „-1“ machen. Ich kenne Python,
ich benutze es, ich finde das trotzdem nach wie vor die größte
Fehlentscheidung dieser Sprache überhaupt. Ich kenne aber auch Perl,
ich benutze auch Perl. Je nachdem, wofür ich halt gerade die
besseren Bedingungen sehe. Von mir findest du auch Tcl-Code im Netz.
Nicht, dass ich die Sprache besonders gut leiden könnte, aber für
Mfile war damals halt die Prämisse, dass nicht noch eine weitere
Abhängigkeit in WinAVR eingebracht werden sollte, und Tcl/Tk war
(durch Insight) bereits da.
> Denn im technisch / wissenschaftlichen Bereich ist Python nun mal die> mit Abstand verbreitetste dynamische Sprache, da kannst du die Luft> anhalten bis du rot anläufst.
Muss ich nicht, für mich ist das keine Religion. Viele
Sysadmin-Dinge sind historisch mit Perl gut bedient worden (CGI
ist damit groß geworden), und die Aufgabenstellung fällt da gut mit
rein.
Man muss sich nicht unbedingt zwischen beiden Sprachen als „alles
oder nichts“ entscheiden. Es seid denn, ja, man sieht sie als
Religion an. Dann kann man natürlich nur eine von beiden entsprechend
nach außen vertreten …
Jörg, ich habe keine Ahnung, was du von mir willst.
Du machst auf mich den Eindruck eines fanatischen Atheisten.
In seinem Eifer bekommt er gar nicht mit, dass er viel verblendeter und
intoleranter ist als die allermeisten Gläubigen.
Kurioserweise nimmt er damit selbst stark religiöse Züge an.
Mein Vorschlag ist sinnvoll und insbesondere in der Antwort auf dich
auch hinreichend begründet.
Du hingegen hast hier noch nichts sinnvolles zum Thema beigetragen, und
dein Evangelismus-Vorwurf ist lächerlich.
Auf meine Sachargumente gehst du erst gar nicht ein.
Ich habe niemanden etwas aufgedrängt und Python auch nicht zur einzig
wahren Scriptsprache erklärt.
Unter den (wenigen) bekannten Gegebenheiten gehört es aber definitiv
hier erwähnt.
Für mich ist hier auch EOT.
Die Diskussion führt eh zu nichts, und Marco scheint sich auch nicht für
die Antworten zu interessieren.
P.S.
An der Sprache Python finde ich übrigens längst nicht alles toll,
insbesondere die ganzen __ und self nerven.
Thomas schrieb:> Jörg, ich habe keine Ahnung, was du von mir willst.> Du machst auf mich den Eindruck eines fanatischen Atheisten.> In seinem Eifer bekommt er gar nicht mit, dass er viel verblendeter und> intoleranter ist als die allermeisten Gläubigen.> Kurioserweise nimmt er damit selbst stark religiöse Züge an.
Ich finde, du reagierst hier eindeutig über.
> Du hingegen hast hier noch nichts sinnvolles zum Thema beigetragen, und> dein Evangelismus-Vorwurf ist lächerlich.
Nö, für mich als Außenstehender passt er hier (wie bei jeder
Entscheidung) gut rein.
> Auf meine Sachargumente gehst du erst gar nicht ein.
Hat er...
> Ich habe niemanden etwas aufgedrängt und Python auch nicht zur einzig> wahren Scriptsprache erklärt.
Dafür reagierst du aber ziemlich schroff, sobald was anderes kommt.
> Unter den (wenigen) bekannten Gegebenheiten gehört es aber definitiv> hier erwähnt.
ACK.
Moin,
ich bin absoluter Perl-Fan! Und meine Meinung schwer Vorbelastet :)
Perl läuft auf praktische allen Systemen, ist extrem Leistungsfähig und
die Anzahl der Module bzw. Erweiterungen z.B. CPAN.org ist riesig. Es
gibt kaum eine Anwendung die man nicht mit Perl in den Griff bekommt.
Ich arbeite seit etlichen Jahren erfolgreich damit und mache das auch
weiter.
Es gibt etliche Internet-Foren und Infos wo man schnelle und gute Hilfe
bekommt.
PHP ist in den modernen Websachen auch überall dabei. Funktioniert im
Web auch gut und es gibt Infos ohne Ende.
Mein Tipp, einfach mal versuchen :) Es ist Geschmackssache, so wie AVR
vs. PIC; Opel vs. Ford; GTI vs. Manta; ...
Grüße aus Berlin
> Ich finde, du reagierst hier eindeutig über.
Du hast recht, ich habe überreagiert.
Dafür entschuldige ich mich.
Ich habe mich durch den Evangelismus-Vorwurf angegriffen gefühlt und
wollte in der selben Sprache etwas entgegen setzten.
> Dafür reagierst du aber ziemlich schroff, sobald was anderes kommt.
Nein, das stimmt nicht.
Ich reagiere nur ziemlich schroff, sobald ich mich angegriffen fühle.
Wenn etwas anderes kommt, dann werde ich das immer mit Interesse lesen,
weiter recherchieren, und evtl. sogar selbst ausprobieren.
> Hat er...
Finde ich nicht.
Das war nur Fachgeplänkel um Nichtigkeiten.
Thomas schrieb:> Ich reagiere nur ziemlich schroff, sobald ich mich angegriffen fühle.
Und ich fühle mich durch das ständige Gejammer, mit Perl wäre
automatisch unlesbarer Code verbunden, angegriffen. Insofern habe
ich da sicher genauso überreagiert.
Dass Python im Hinblick auf das, was der TE möchte, auf jeden Fall
Wert ist, in Betracht gezogen zu werden, stimme ich völlig überein.
Läubi .. schrieb:> Εrnst B✶ schrieb:>> Hinter jeder Ecke lauert eine neue Falle>> Welche den z.B. die wirklich spezifisch für ein aktuelles PHP 5+ sind?
Blödes Beispiel, "Webseiten-Login":
Früher mit dem bescheuerten "=="-Operator.
Das hier:
1
if (md5($salt.$_POST['password']) == $password) { ...
lies jedes Zehnte Zufalls-Password als Richtig durchgehen, wenn das
Passwort in der Datenbank mit einer Ziffer begonnen hat...
Wurde zwar entschärft, "==" ist jetzt aber nicht mehr
Backwards-Kompatibel.
Kommentar der PHP-Entwickler dazu sinngemäß:
Man muss halt "strcmp" verwenden, wenn man Strings vergleichen will.
Super. Nur weil ein anderer PHP-Entwickler bei Version 0.irgendwas mal
gesagt hat, dass ein spezieller String-Vergleichsoperator (wie "eq" bei
Perl) Böse ist.
Ganz toll dabei: strcmp & Co sind ganz dünne wrapper um die
C-Funktionen.
PHP-Strings können üblicherweise '\0' enthalten, C-Strings nicht. mit
%00 kriegt man so ein '\0' auch durch den Webserver. Ergo: str* im
Webseiten-PHP nur mit vorsicht einsetzen...
Und so geht das für so ziemlich jede PHP-Funktion weiter.
Klar, alle funktionieren sie irgendwie. Und alle kann man irgendwie
einsetzen, wenn man an alle Eigenheiten und Sonderfälle gedacht hat,
aber in der Summe macht einem das das Leben nur unnötig schwer.
Schon etwas länger her, aber vielleicht trotzdem interessant: Richtig
großes Webprojekt, Aufwand/Kosten/Nutzen/Risiko-Analyse zur Entscheidung
zwischen Umsetzung mit "Apache + PHP" oder "Selbstgeschriebener (C++)
Application/HTTP-Server mit eigen-entwickelter Script-Sprache + eigenem
Compiler + eigener VM"
Rate was es geworden ist?
Klar: Die Zeit bis zum ersten Prototypen war sicher länger, aber "in the
long run" war die Entscheidung so falsch sicher nicht.
Heutzutage würde man halt den Application-Server nicht mehr selber von 0
ab coden, sondern RoR, nodejs, Java**, ... einsetzen.
Insofern: Ich hab richtig großen Respekt vor den PHP-Anwendern, die es
schaffen trotz PHP so Dinge wie Typo3, Joomla, Magento, owncloud &co
halbwegs sicher auf die Beine zu stellen.
Ich versteh nur nicht wirklich, warum sie sich das antun.
Etwa Analog zu Iron-Man-Läufern: Tolle Leistung, aber weshalb quälen die
sich so?
Εrnst B✶ schrieb:> Früher
Ich schrieb ja extra aktuelle Version... früher war halt auch nicht
alles gut ;-) Najagut der Bug ist von 2011 also noch nicht sooo alt,
ABER inzwischen sollte jeder wissen, das man da den === Operator nutzt
(das gleiche "Problem" mit der Autokonvertierung hat auch JS), es wird
auch eigentlich durchgängig in der PHP Doku immer wieder auf die == vs
=== Problematik verwiesen.
Εrnst B✶ schrieb:> Ich versteh nur nicht wirklich, warum sie sich das antun.
Ich "muss" unter anderem auch PHP Entwickeln da das halt vielfach die
einzige brauchbare "Websprache" war/ist die unterstützt wurde wenn man
nicht gleich einen ganzen VServer kaufen will.
Und seit PHP 5 ist das auch ganz brauchbar, und genauso wie in C gibt es
auch in PHP Fallstricke, trotzdem wird man nur sehr sehr selten in der
Praxis damit konfrontiert. Klar wen man jeden "Hack" oder
"Dirty-Trick" den man findet unbedingt in seinen Code einbauen muss...
oder schluderig Programmiert.
Εrnst B✶ schrieb:> Selbstgeschriebener (C++) Application/HTTP-Server mit eigen-entwickelter> Script-Sprache + eigenem Compiler + eigener VM
mit ganz eigenen Bugs ...
Εrnst B✶ schrieb:> lies jedes Zehnte Zufalls-Password als Richtig durchgehen, wenn das> Passwort in der Datenbank mit einer Ziffer begonnen hat
Hast du dafür einen Testfall? Das würde mich doch sehr interessieren,
ich hätte jetzt die Wahrscheinlichkeit nicht so hoch eingeschätzt, ich
gehe mal davon aus dass du meinst, der MD5 Hash in der Db fängt mit z.B.
0 an und der Hash des "Angreifers" ebenfalls und das PW ist nicht
zufällig gewählt...
Läubi .. schrieb:> Εrnst B✶ schrieb:>> Selbstgeschriebener (C++) Application/HTTP-Server mit eigen-entwickelter>> Script-Sprache + eigenem Compiler + eigener VM>> mit ganz eigenen Bugs ...
Ab einer gewissen Größe kommt man um Eigenentwicklung nicht mehr rum,
siehe Google, FB, ...
Aber ok, nur die wenigsten werden in solche Sphären der Not einer
Eigenentwicklung vorstoßen.
In meiner PHP Version ist der Bug wohl schon behoben, trotz "bösem"
Vergleich gibt es immer -
Caste ich auf int um das vermutlich alte Verhalten zu provozieren, komme
ich bei zufälligen Ziffernfolgen höchstens auf jedes 20. oder 30.
Zufallspasswort das passt wenn der hash mit einer Zahl beginnt. Wenn
man natürlich die ersten Ziffern des Hashes kennt (was meist nicht der
Fall ist) ginge es mit einer Tabelle sicher besser, das jedes 10
Zufalls passwort akzeptiert würde scheint sich aber nicht zu
bestätigen.
Beginnt der hash mit zwei Ziffern gibt es bei bei zufälligem Passwort
keine Kollision mehr bei ca. 1000 Durchläufen.
Läubi .. schrieb:> das jedes 10> Zufalls passwort akzeptiert würde scheint sich aber nicht zu> bestätigen.
Jup, unter der Voraussetzung:
Εrnst B✶ schrieb:> lies jedes Zehnte Zufalls-Password als Richtig durchgehen, wenn das> Passwort in der Datenbank mit einer Ziffer begonnen hat...
ist es deutlich weniger als jedes sechzehnte, wenn md5 gleichverteilt
beginnt.
1/16 damit die erste Ziffer getroffen wird * 6/16 damit die zweite
Stelle ein Buchstabe ist ± Sonderfälle, 1e0XXXX == 1xxxxx usw.
Läubi .. schrieb:> Ich "muss" unter anderem auch PHP Entwickeln da das halt vielfach die> einzige brauchbare "Websprache" war/ist die unterstützt wurde wenn man> nicht gleich einen ganzen VServer kaufen will.
Geht mir nicht anders...
Läubi .. schrieb:> sehr sehr selten in der> Praxis damit konfrontiert
Ok, anderes Beispiel:
1
<?php
2
$a=[1,2,3];// eher: irgendwelche "teueren" Dinge
3
4
foreach($aas&$i){
5
echo$i."\n";
6
}
7
8
// Viel anderer code dazwischen
9
10
11
for($i=0;$i<10;$i++){
12
echo$i."\n";
13
}
14
15
var_dump($a);
16
?>
Was kommt raus? Was würde man erwarten, wenn man schonmal was anderes
Programmiert hat?
Und viel schlimmer: Wie findet man den Fehler, besonders wenn die erste
foreach-Schleife in irgendeinem importierten Fremd-Code liegt?
Niemals Perl! Nimm PHP und gut ist, da gibt es einen Haufen Frameworks,
um was schnelles auf die Beine zu stellen. Perl ist zwar keine
aussterbende Art, aber dennoch eine Rarität.
Εrnst B✶ schrieb:> Was kommt raus? Was würde man erwarten, wenn man schonmal was anderes> Programmiert hat?> Und viel schlimmer: Wie findet man den Fehler, besonders wenn die erste> foreach-Schleife in irgendeinem importierten Fremd-Code liegt?
Scheiß Code kann ich in jeder Sprache produzieren, das ist ein Beispiel
dafür.
Rene Schube schrieb:> Also Perl ist eine mächtige Waffe, nix Rarität.
Es gibt eine Dimension von Fandom, die ist mir unheimlich. ;-)
Perl ist auch so schon kryptisch genug, man denke nur an das "leaning
toothpick syndrome". Aber auf Klingonisch ist krass.
♪Geist schrieb:> Niemals Perl! Nimm PHP und gut ist...
Das klingt genauso wie die zwei Webentwickler, deren Magento-System ich
gerade vor der Nase habe. Die haben einen Kunden von uns eine
Webshop-Applikation verkauft und das Teil ist dem Kunden "buchstäblich
um die Ohren geflogen". Die haben dort in einer diletantischen Weise
Import- und Export-Module rangeklatscht, daß man sich fragt, ob die noch
klar denken konnten.
(Beispiel: Artikelimport und Update per CSV. Nicht mehr in der CSV
stehende Artikel verwaisen im Shop, lassen sich aber nicht löschen.)
Aber solche markigen Sprüche wie oben sollen da auch gefallen sein laut
der IT unseres Kunden. Die haben auch bestimmte Sachen kategorisch
ausgeschlossen, unabhängig vom Anwendungsgebiet.
Nur zum Amüsement aller hier: hast du noch mehr solcher "Geistesblitze"?
A. K. schrieb:> Perl ist auch so schon kryptisch genug, man denke nur an das "leaning> toothpick syndrome".
Wobei ich das in der Shell besonders krass finde. Als deutschen
Terminus dafür kenne ich übrigens „Keilschrift“. ;) Auch immer wieder
gern gesehen sind Quotingorgien a la:
1
echo "The value of "'$VAR'" is '$VAR'."
In Perl kann man ja allemal statt /\/some\/path\// schreiben
m|/some/path/| oder auch m(/some/path/). Irgendein Zeichen wird
man wohl schon finden, was man gerade im RE nicht benötigt und
daher als Begrenzer benutzen kann.
Die Sache mit den Referenzen ist IMO bei Perl etwas undurchsichtig. Das
führt öfters zu lustigem Rätselraten (oder dem Einsatz von
Data::Dumper), wo denn jetzt eigentlich die Werte versteckt sind...
Aber ansonsten ist es schon eine recht schöne Sprache, mit der man sehr
effizient entwickeln kann. Gerade wenn die Anforderungen nicht so klar
sind und man in Zusammenarbeit mit dem Kunden interaktiv was machen
muss.
php vs. Perl nimmt sich nicht so viel (kleine Code-Ausschnitte sind ja
oft gar nicht unterscheidbar), für externe Programme (Daemons, etc.)
finde ich Perl aber praktischer.
Man muss auch nicht unbedingt alle Sprachfeatures benutzen... Ich bin
jetzt auch nicht so der Perl-Nerd, wo alle Programme nach Shift + oberer
Tastatureihe aussehen und regexp 90% des Codes ausmachen ;)
Obwohl, gerade gestern ist wieder eine spassige Zeile entstanden:
my %all_tags = map {$_ => 1} $template =~ /\[(.*?)\]/g;
Das sucht in der Vorlage $template alle Strings innerhalb von [] und
sortiert sie in einen Hash, sodass jedes identische Vorkommen genau
einmal auftaucht. Sowas würde in C++ selbst mit boost&Co sicher etwas
länger werden ;)
Georg A. schrieb:> Sowas würde in C++ selbst mit boost&Co sicher etwas länger werden ;)
Ich hatte so etwas vor Äonen mal ausprobiert, in diversen Sprachen,
darunter auch C++ mit irgendeiner Containerklasse, und Perl. Der Kern
war ein grösseres Hash-Array. Perl war nicht nur viel kürzer, sondern
ulkligerweise auch noch verteufelt schnell.
> my %all_tags = map {$_ => 1} $template =~ /\[(.*?)\]/g;
Grausam.
Sieht ja aus wie PGP verschlüsselter Text.
Was muss ich lesen um das verstehen zu können?
Was soll das sein?
Eine klingonische Programmiersprache? ;)
@Marc:
Das ist weniger der Sprache anzulasten, such nach "Regulärer Ausdruck"
oder "regular expression".
Nein in klingonisch habe ich ein Beispiel gezeigt :)
APL != klingonisch
Aber die Regeln einer Programmiersprache gelten bei beiden.
Also 'eine formale Sprache zur Formulierung von Datenstrukturen und
Algorithmen'.
Marc schrieb:>> my %all_tags = map {$_ => 1} $template =~ /\[(.*?)\]/g;>> Grausam.> Sieht ja aus wie PGP verschlüsselter Text.>> Was muss ich lesen um das verstehen zu können?
Mein Favorit:
1
perl -wle '$_ = 1; (1 x $_) !~ /^(11+)\1+$/ && print while $_++'
Wer errät (vor dem Ausführen) was dieser Code macht?
Εrnst B✶ schrieb:> Wer errät (vor dem Ausführen) was dieser Code macht?
Ist natürlich ein witziger Trick. Nein, ich habe es vorher auch
nicht verstanden. ;-) Aber nach dem Ausführen und nochmaligem
Nachdenken schon.
Fällt aber in die Kategorie "IOCCC".
>> my %all_tags = map {$_ => 1} $template =~ /\[(.*?)\]/g;>> Grausam.> Sieht ja aus wie PGP verschlüsselter Text.>> Was muss ich lesen um das verstehen zu können?
Man kann es auch in zwei Zeilen schreiben ;)
@hits = $template =~ /\[(.*?)\]/g;
%all_tags = map {$_ => 1} @hits;
Die Magie ist der RE (ausgeführt durch =~) innerhalb der //:
\[(.*?)\] sucht die kürzeste (?) Zeichenfolge aller Zeichen (.*) die von
[] umrahmt sind. Da die [] leider auch RE-Spezialzeichen sind, muss man
sie mit \ escapen. Die () liefern das "innen" gematchte Ergebnis zurück.
Ohne die () sagt das nur, dass es überhaupt gematcht hat.
Das g (=go) am Ende macht das nicht nur einmal (wäre ersten Treffer),
sondern durch den ganzen String. Durch die () kommt als Ergebnis damit
eine Liste der Treffer raus, die wird einem Array zugewiesen. Das hat
aber eben alle Treffer, d.h. es kann Dubletten geben.
Um die auszusortieren, wird jedes Array-Element via map in einen Hash
eingetragen. map läuft alle Arrayelemente durch und führt dafür den Code
in den {} aus. $_ ist dabei das aktuelle Element. Der Hashkey ist das
Array-Element $_, 1 der Dummy-Inhalt. Dubletten tragen sich mehrfach auf
denselben Hashkey ein, tauchen im Hash dann also auch nur einmal auf.
Fertig :) Und wenn dann noch ein Kommentar dabeisteht, was das macht,
verstehen es auch andere Perl-Programmierer.
Jörg Wunsch schrieb:> Ist natürlich ein witziger Trick. Nein, ich habe es vorher auch> nicht verstanden. ;-) Aber nach dem Ausführen und nochmaligem> Nachdenken schon.
ich raffs immer noch nicht.
der Ablauf ist mir klar, aber die Bedingung des regexes versteh ich
nicht.
/^(11+)\1+$/
ich versuchs mal zu übersetzen.
^(11+) - string muss mit mindestens 2 einsen anfangen, wobei ich das
gematchte pattern speichere.
\1+$ - genau dieses pattern will ich jetzt vorm Stringende mindestens
noch mal finden? mich verwirrt das \1 - das hab ich sonst nur auf der
ersetzen-seite. Bezieht sich das also auf den gefundenen Ausdruck des
letzten regex oder den aktuellen?
wahrscheinlich den letzten, oder?
aber irgendwie passt das in beiden Fällen nicht zum ausgegebenen Muster.
Vlad Tepesch schrieb:> ich raffs immer noch nicht.> der Ablauf ist mir klar, aber die Bedingung des regexes versteh ich> nicht.
Zuerst wird die zählvariable in das "Finger-Abzähl-Zahlensystem"
gebracht, also
"1" = 1
"11" = 2
"111" = 3
dann matched die Regex alle Strings, die "ganzzahlige Teiler">1 haben,
für die also ein Substring aus mindestens zwei Einsen (11+) existiert,
mit dem man den ganzen Rest des Strings auffüllen kann (Backref \1+ ),
und das Ganze ohne Rest (^ ... $)
=> Primzahlsuche auf ineffizient.
ok, das \1 kommt also aus dem aktuellem suchvorgang.
aber wie passt das auf
"11"?
\1 sollte doch '11' sein, und das findet sich nicht mindestens einmal im
rest des strings, weil an den ersten 2 Zeichen bin ich ja schon vorbei,
dann kommt nur noch Ende. Der Regex sollte aber noch \1+ erwarten
Vlad Tepesch schrieb:> \1 sollte doch '11' sein,
Oder länger, also '111', '1111' oder dergleichen.
> und das findet sich nicht mindestens einmal im> rest des strings, weil an den ersten 2 Zeichen bin ich ja schon vorbei,
Die Strings werden ja immer länger. Für die 5 ist es '11111'.
Da passt das Muster auch nicht (ist ja eine Primzahl). Für die 6 ist
es '111111', da passt das Muster wieder: der Match passt auf '111',
und das wird anschließend genau einmal dahinter gefunden. Ist also
keine Primzahl. Klar, alle geraden Zahlen kann man ja immer in zwei
gleich lange Teil-Ketten zerlegen.
Interessant sind also noch die ungeraden Nicht-Primzahlen. Nimm die
15 als Beispiel: '111111111111111'. Der Match passt auf '111', und
diese Kette wird anschließend weiter viermal gefunden.
T.roll schrieb:> Sowas ist doch krank!
Dass das Klingonisch wohl eher ein Joke ist und die
Primzahlengeschichte von der Qualität eines IOCCC, ist dir aber
nicht entgangen, oder?
IOCCC, gerade auch in C kann man wunderherrlichen Blödsinn verbrechen,
wenn man nur will. Aber man wird sich schwer hüten, sowas in
produktivem Code zu nutzen.
Und
1
%all_tags = map {$_ => 1} @hits;
ist auch nicht kryptischer als
1
j=sum(map(func, range(0,42)))
wie es gerade im Nachbarthread vorgeschlagen worden ist. Bei beiden
diesen Konstruktionen muss man halt ein wenig Verständnis für die
Sprache haben, viel mehr ist das nicht. Andererseits kann man beides
auch alternativ etwas ausführlicher ausdrücken. Der Python-Ausdruck
wurde als Ersatz für eine entsprechende for-Schleife ins Spiel
gebracht, und obiger Perl-Ausdruck ließe sich auch mit einer
for-Schleife
schreiben als:
Jörg Wunsch schrieb:> Dass das Klingonisch wohl eher ein Joke ist und die> Primzahlengeschichte von der Qualität eines IOCCC, ist dir aber> nicht entgangen, oder?
*Auf das hier am Ende meines Textes hinweis*: :)
Jörg Wunsch schrieb:> j=sum(map(func, range(0,42)))
Ich habe mal gelesen (und so mache ich es auch), dass man doch einfach
mal eine neue Zeile oder Variablen benutzen soll, bevor man Funktionen
zigfach verschachtelt. Besonders wenn dann vielleicht auch noch
Parameter drin sind.
1
a = test(haha(1,(fail(irgendwas('abc'), 0),1)),'a');
Die waren nicht unentdeckt, sondern Absicht. Siehe dazu auch die
Funktion php_logo_guid(). Nur hat das sowieso nie einer benutzt und es
war auch ziemlich überflüssig.
die designschwächen von php sind immer wieder für kopfschütteln gut:
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
dennoch bevorzuge ich php vor perl, ruby und java wenn es um eine eigene
webseite auf einem hostingprovider geht.
wenn man für einen µC was bauen will, sollte man dennoch mal überlegen,
einfach auf c oder c++ zu setzen - da einen webserver aufzubauen ist
recht einfach.
wenn man nur statische sachen ausliefern will, geht das wirklich
einfach. oder man nimmt dann "nc", das böse hackerwerkzeug.
wenn man total hipp sein will, wird aber kein weg an javascript in form
von node.js etc vorbeiführen, und wer total geek sein will, wird dagegen
erlang nehmen.
hab ich was vergessen?
n.n. schrieb:> die designschwächen von php sind immer wieder für kopfschütteln gut
Ist halt so "gewachsen".
Ursprünglich wohl ein Quick-n-Dirty Hack, um SSI mit mehr Features zu
haben, offensichtlich von Leuten zusammengefrickelt, die noch nie was
von Compilerbau gehört haben.
Danach musste es halt immer möglichst kompatibel bleiben...
Thread beobachten
Seitenaufteilung abschalten