Wat is er mis met PHP?

[Hydra]

Barryvdh schreef op donderdag 06 maart 2014 @ 11:28:
Dan is dat nu toch niet meer relevant?

Het is wel een goed voorbeeld dat een beetje de denkprocessen van de PHP 'designers' in beeld brengt.

[.oisyn]

Ontopic. Dit is toch compleet absurd?

PHP:

$a = array("fiets", "a23", "a123", "23", "123");
sort($a);
echo implode("\n", $a);

code:

23
123
a123
a23
fiets

[Rob]

.oisyn schreef op donderdag 06 maart 2014 @ 11:34:
Ontopic. Dit is toch compleet absurd?

PHP:

$a = array("fiets", "a23", "a123", "23", "123");
sort($a);
echo implode("\n", $a);

code:

23
123
a123
a23
fiets

PHP:

$a = array("fiets", "a23", "a123", "23", "123"); 
sort($a, SORT_STRING); 
echo implode("\n", $a);

ik begrijp je punt overigens heel goed. Punt is wel dat een iedereen die een programmeertaal zich goed moet verdiepen in de functies die er zijn

[ Voor 16% gewijzigd door Rob op 06-03-2014 11:50 ]

[TheNephilim]

Zijn er nog vrijwilligers die een Python/Ruby variant van Wordpress willen maken?

Nee niet een willekeurige CMS in één van de genoemde talen, maar gewoon een kopie met dezelfde gebruiksvriendelijkheid voor de klant, maar dan met fatsoenlijke architectuur en code . Oh en het moet ook makkelijk uit te breiden en aan te passen zijn...

Maar, ik heb nog veel te leren. Ik vind het alleen zo lastig om iets te maken waarvoor ik ook meteen een toepassing heb. Anders komt het er toch niet van. Daarnaast zijn er nog zoveel andere dingen die ik wil/moet doen.

/me Mist .oisyn's Quick-Quote functie...

[DXaroth]

Rutix schreef op donderdag 06 maart 2014 @ 08:06:
[...]

Precies. Hiervoor zei iemand dat programmeurs geen aannames mogen maken (wat natuurlijk onmogelijk is want je kunt niet alles weten) maar ik vind dat talen dat sowieso niet mogen doen en precies om de reden die .oisyn aangeeft.

Je hebt aannames maken en aannames maken, aan de ene kant vind ik dat programmeurs never, ever een aanname mogen maken dat gebruikersinput is wat je verwacht dat het is.. maar afgezien daarvan zijn er logische grenzen..

[ZaZ]

Ik zie vaak dat al dat soort eigenaardigheden in PHP dan soort van tafel geveegd worden met een voorbeeld hoe het is op te lossen.
Mijn grootste bezwaar is dat het gewoon alles vreet. Als je dus een foutje hebt gemaakt, hobbelt je code gewoon vrolijk verder in kreupele staat en zonder dat jij doorhebt dat er een fout zit.
Wanneer zo'n fout zich dan (vaak veel te laat) openbaart, ben je je rot aan het zoeken naar het probleem

[DXaroth]

TheNephilim schreef op donderdag 06 maart 2014 @ 11:53:
Zijn er nog vrijwilligers die een Python/Ruby variant van Wordpress willen maken?

Nee niet een willekeurige CMS in één van de genoemde talen, maar gewoon een kopie met dezelfde gebruiksvriendelijkheid voor de klant, maar dan met fatsoenlijke architectuur en code . Oh en het moet ook makkelijk uit te breiden en aan te passen zijn...

Maar, ik heb nog veel te leren. Ik vind het alleen zo lastig om iets te maken waarvoor ik ook meteen een toepassing heb. Anders komt het er toch niet van. Daarnaast zijn er nog zoveel andere dingen die ik wil/moet doen.

/me Mist .oisyn's Quick-Quote functie...

django-cms komt tegenwoordig best een eind.. ze hebben nog wel wat te gaan, maar het is redelijk vriendelijk al.

[incaz]

ZaZ schreef op donderdag 06 maart 2014 @ 11:59:
Mijn grootste bezwaar is dat het gewoon alles vreet. Als je dus een foutje hebt gemaakt, hobbelt je code gewoon vrolijk verder in kreupele staat en zonder dat jij doorhebt dat er een fout zit.
Wanneer zo'n fout zich dan (vaak veel te laat) openbaart, ben je je rot aan het zoeken naar het probleem

Daar heb ik dus zelf niet zoveel last van. Enerzijds omdat veel dingen gewoon helemaal niet zo ambigu zijn (waar het in javascript nogal vervelend uitpakt met ints en strings en de +-operator geeft dat in php geen onjuiste resultaten), en anderzijds omdat validatie van input of params over het algemeen om hele andere dingen gaat dan type alleen. En als je daar steeds rekening mee houdt verdwijnen de meeste type ambiguiteiten als sneeuw voor de zon.

[Rob]

ZaZ schreef op donderdag 06 maart 2014 @ 11:59:
Ik zie vaak dat al dat soort eigenaardigheden in PHP dan soort van tafel geveegd worden met een voorbeeld hoe het is op te lossen.

Dat is het mooie: er is overal een oplossing voor

In het verleden zijn er rare dingen bedacht die ze in PHP gestopt hebben. Deze rare dingen hebben ze opgelost, maar wel op aan manier waarop het nog backwards compatible is.

[R4gnax]

incaz schreef op donderdag 06 maart 2014 @ 12:04:
(waar het in javascript nogal vervelend uitpakt met ints en strings en de +-operator geeft dat in php geen onjuiste resultaten)

Omdat dat expliciet numerieke operatoren zijn in PHP en string concatenatie plaats vindt met de speciaal daarvoor gereserveerde . operator, ja. Ga daarentegen maar eens met de comparison operators spelen en kijk dan eens welk type coercion systeem meer logisch in elkaar steekt; PHP of JS. Ik weet het antwoord al...

[ZaZ]

Rob schreef op donderdag 06 maart 2014 @ 12:30:
[...]


Dat is het mooie: er is overal een oplossing voor

In het verleden zijn er rare dingen bedacht die ze in PHP gestopt hebben. Deze rare dingen hebben ze opgelost, maar wel op aan manier waarop het nog backwards compatible is.

Hoe is dat mooi? Ik zeg niet dat andere talen geen eigenaardigheden hebben, maar zoveel eigenaardigheden en dan workarounds aanbieden vind ik niet 'mooi'.
Nodig, ja, maar mooi is wel wat stationnetjes verder hoor.
Die compatibility met oude meuk zit ze in mijn optiek juist behoorlijk in de weg. Ik ben van mening dat ze juist het beste kunnen breken en een nieuwe versie aanleveren.

Het argument wat incaz aandraagt kan ik ook niet zoveel mee. Zolang je je maar houdt aan bepaalde dingen gaat het goed. Is dat eigenlijk niet altijd zo? Maar fouten worden nou eenmaal gemaakt en dan is het wel fijn als een compiler je op de vingers tikt, of als iets eerst een int was en er wordt om een of andere reden ineens at runtime een string ingefrot, dan wil ik dat ie klapt.
De documentatie van PHP is daarbij ook niet echt een pretje waar onervaren volk een soort van best practice aandragen die soms te erg voor woorden is.
En vanwege de inconsistentie in de API is een foute aanname snel gemaakt.

[Hydra]

Rob schreef op donderdag 06 maart 2014 @ 11:49:
ik begrijp je punt overigens heel goed. Punt is wel dat een iedereen die een programmeertaal zich goed moet verdiepen in de functies die er zijn

Dus je moet voor elke functie onthouden welke rare bijeffecten je krijgt? Nee dank je.

[Patriot]

Rob schreef op donderdag 06 maart 2014 @ 11:49:
[...]

PHP:

$a = array("fiets", "a23", "a123", "23", "123"); 
sort($a, SORT_STRING); 
echo implode("\n", $a);

ik begrijp je punt overigens heel goed. Punt is wel dat een iedereen die een programmeertaal zich goed moet verdiepen in de functies die er zijn

Ik ben nu overigens wel heel erg benieuwd wat ze in hemelsnaam onder een "regular" sort verstaan (dat is die tweede param namelijk standaard: SORT_REGULAR). Ik weet niet hoe ze die vergelijkingen intern doen, maar als dat volgens dezelfde regels gaat als in PHP dan ben je tijdens je sort dus steeds op een andere manier aan het vergelijken

[ZaZ]

Hydra schreef op donderdag 06 maart 2014 @ 13:28:
[...]
Dus je moet voor elke functie onthouden welke rare bijeffecten je krijgt? Nee dank je.

Jij wilt dus zeggen dat je niet documentatie van de hele jar-jungle uit je hoofd kent?
Valt me van je tegen

[.oisyn]

Patriot schreef op donderdag 06 maart 2014 @ 13:29:
[...]


Ik ben nu overigens wel heel erg benieuwd wat ze in hemelsnaam onder een "regular" sort verstaan (dat is die tweede param namelijk standaard: SORT_REGULAR). Ik weet niet hoe ze die vergelijkingen intern doen, maar als dat volgens dezelfde regels gaat als in PHP dan ben je tijdens je sort dus steeds op een andere manier aan het vergelijken

Dat dus. Het gedrag is hetzelfde als gewoon de standaard < operator.

[Verwijderd]

Om nog meer olie op het vuur te gooien:

Wat ik persoonlijk een goed voorbeeld vind van het denkbeeld van de "ontwerpers" achter PHP is hun visie op overloading. Wanneer je een gemiddelde programmeur vraagt hoe overloading werkt zal die waarschijnlijk met het standaard verhaaltje komen, zoals we dit al jaren kennen van menig taal.
Vraag je het echter aan een PHP programmeur dan krijg je daar een antwoord wat in mijn ogen echt helemaal niets met overloading te maken heeft. Natuurlijk is het een "oplossing", maar het komt op mij heel erg over alsof ze vergeten waren om overloading te implementeren. Daarna hebben ze de meest lelijke en omslachtige workaround bedacht en daar gewoon het label overloading op geplakt.

Het lijkt er haast op alsof ze er alles aan doen om maar erbij te horen, in plaats van een als doel stellen om een zo goed mogelijke taal te ontwerpen.

[NMe]

PHP heeft helemaal geen overloading en pretendeert dat voor zover ik weet ook niet? Het enige wat veel programmeurs zullen zeggen is dat je het kan faken door met parameters te gaan jongleren maar geen enkele serieuze programmeur zal dat overloading noemen.

[.oisyn]

Volgens mij wordt dat in ieder geval in de javascript wereld wel overloading genoemd. Het is dan ook gebruikelijk om de verschillende "overloads" apart te documenteren ipv als 1 functie die meerdere soorten parameters accepteert.

[Janoz]

NMe schreef op donderdag 06 maart 2014 @ 15:08:
PHP heeft helemaal geen overloading

Klopt

en pretendeert dat voor zover ik weet ook niet?

Klopt niet.


http://nl1.php.net/language.oop5.overloading


En daar dan specifiek

PHP's interpretation of "overloading" is different than most object oriented languages. Overloading traditionally provides the ability to have multiple methods with the same name but different quantities and types of arguments.

[NMe]

Kittens just died.

[Merethil]

NMe schreef op donderdag 06 maart 2014 @ 15:45:
Kittens just died.

PHP:

class MyKittenClass() {

    public function createNewKittens($kittens, $kittensDie = true) {

        if($kittensDie) {
            foreach($kittens as $kitten) {
                kill($kitten);
            }
        }

    }

}

He bah, had je de overload niet gezien!? Jij monster!


Edit: Soms mis ik bovenstaande wel in Java. Al dat getyp om al die overloaded constructors en overloaded functions te bouwen..

[ Voor 12% gewijzigd door Merethil op 06-03-2014 16:03 ]

[NMe]

Ja, dat is wat ik dacht dat bedoeld werd. Maar blijkbaar ging het over magic methods in classes om je properties te kunnen getten en setten, en dat noemen ze dan overloaden. De bovenste commenter slaat de spijker op zijn kop:

This is a misuse of the term overloading. This article should call this technique "interpreter hooks".

[Merethil]

NMe schreef op donderdag 06 maart 2014 @ 16:07:
Ja, dat is wat ik dacht dat bedoeld werd. Maar blijkbaar ging het over magic methods in classes om je properties te kunnen getten en setten, en dat noemen ze dan overloaden. De bovenste commenter slaat de spijker op zijn kop:

[...]

... Eh wat. Dat slaat nergens op. Moet je nagaan, had het stuk niet eens goed gelezen
Er wordt hierboven wel gequote hoe het zou moeten kloppen maar opeens gebruiken ze overloading dus voor iets geheel anders?
Raar...

En toch mis ik bovenstaande

[Janoz]

Een typisch php-er antwoord zou daarop zijn:

Nee hoor, dat is er wel. Kijk, zo kun je dat doen:

Java:

public void createNewKittens(Collection<Kitten> kittens) {
  createNewKittens(kittens,true);
}

public void createNewKittens(Collection<Kitten> kittens, boolean kittensDie) {
  /* implementation */
}

[Merethil]

Janoz schreef op donderdag 06 maart 2014 @ 16:41:
Een typisch php-er antwoord zou daarop zijn:

Nee hoor, dat is er wel. Kijk, zo kun je dat doen:

Java:

public void createNewKittens(Collection<Kitten> kittens) {
  createNewKittens(kittens,true);
}

public void createNewKittens(Collection<Kitten> kittens, boolean kittensDie) {
  /* implementation */
}

Kittens just died again...

[RayNbow]

NMe schreef op donderdag 06 maart 2014 @ 16:07:
Ja, dat is wat ik dacht dat bedoeld werd. Maar blijkbaar ging het over magic methods in classes om je properties te kunnen getten en setten, en dat noemen ze dan overloaden. De bovenste commenter slaat de spijker op zijn kop:

[...]

This is a misuse of the term overloading. This article should call this technique "interpreter hooks".

Interpreter hooks? Smalltalk noemde het doesNotUnderstand...

[Barryvdh]

Dit klinkt wel interessant: http://nikic.github.io/20...imitive-types-in-PHP.html

[incaz]

Op 't eerste gezicht dacht ik: zou het echt iets oplossen? Op het tweede gezicht ziet het er gewoon heel nice uit. En dan scoort het alweer 1 abomination minder dan python ( "str".join(list))

[Barryvdh]

Het lost iig het probleem van de inconsistente API op en het leest ook wel wat makkelijker lijkt me.

[RayNbow]

incaz schreef op zaterdag 15 maart 2014 @ 20:53:
En dan scoort het alweer 1 abomination minder dan python ( "str".join(list))

Maar is dit niet nog duidelijker?

Python:

s = str.join(sep, iterable)

Maar goed, het probleem is eigenlijk dat join() ook niet echt thuishoort in list. Je hebt namelijk ook andere datatypes waar je over kunt itereren.

[NMe]

Barryvdh schreef op zaterdag 15 maart 2014 @ 23:42:
Het lost iig het probleem van de inconsistente API op en het leest ook wel wat makkelijker lijkt me.

Klopt, maar het is een beetje een pipe dream. Programmeurs over de hele wereld roepen al jaren dat ze dat soort bewerkingen op die manier willen kunnen doen, net zoals er al jaren geroepen wordt om een consistentere ervaring in PHP en het mogelijk maken van type hinting op primitieve types. Ik zie niet helemaal hoe dat blog (en het blog dat de aanleiding daarvan was) bij kunnen dragen aan het daadwerkelijk overhalen van de developers om het eindelijk toe te voegen?

[Zoijar]

"Here is the surprising truth: It’s often easier to make something 10 times better than it is to make it 10 percent better." Erg toepasselijk voor PHP. Als je alle API dingetjes fixed, dan zit je nog steeds met PHP...

PHP is ook ontworpen als pre-hypertext processor: een soort van template engine om HTML te genereren; en daar was het redelijk goed in. Later is dat met verschillende kunstgrepen uitgebreid naar een soort van taal waar je hele applicaties in kan schrijven, maar het kan zijn roots niet ontkomen. Het is alsof ik hele applicaties ga schrijven in Jinja; het kan misschien, maar het blijft een template engine. Het is in dit geval dus veel makkelijker om gewoon de hele taal weg te gooien en iets nieuws op te zetten dat wel ontworpen is voor de moderne manier van web apps schrijven. Hey, C#...

[ Voor 57% gewijzigd door Zoijar op 16-03-2014 13:44 ]

[NMe]

PHP heden ten dage nog afdoen als "het blijft een template engine" is niet eerlijk. Er zijn nog héél veel dingen stuk maar die opmerking doet eigenlijk alle stappen die de ontwikkelaars van de taal hebben gezet om de taal op te laten groeien af als onbelangrijk, en zo ver zou ik niet willen gaan.

Daarbij: je bedoelt niet C# maar .NET. C# heeft weliswaar een eenduidigere basis door zijn strong typing maar het is het framework (en met name de aanwezig application context) dat het geschikt maakt om webapplicaties mee te schrijven.

Wat PHP betreft zijn er ook prima frameworks om moderne webapps te schrijven. Symfony is een mooi voorbeeld van hoe het ook kan. Natuurlijk zit ook dat vast aan bepaalde limitaties (het blijft PHP) maar dat maakt het nog niet ongeschikt voor het maken van webapps.

[Barryvdh]

NMe schreef op zondag 16 maart 2014 @ 12:42:
[...]

Klopt, maar het is een beetje een pipe dream. Programmeurs over de hele wereld roepen al jaren dat ze dat soort bewerkingen op die manier willen kunnen doen, net zoals er al jaren geroepen wordt om een consistentere ervaring in PHP en het mogelijk maken van type hinting op primitieve types. Ik zie niet helemaal hoe dat blog (en het blog dat de aanleiding daarvan was) bij kunnen dragen aan het daadwerkelijk overhalen van de developers om het eindelijk toe te voegen?

Nouja, nikic is wel een van de ontwikkelaars die ook echt functionaliteit toevoegt aan php, hij heeft al meerdere rfc's voorgesteld, laten accepteren en ook ontwikkeld. Zoals hij al zegt heeft hij ook al een php extensions geschreven met een deel van de functionaliteit en heeft hij discussies gehad met andere ontwikkelaars. Ircmaxell is iig ook iemand die werkt aan php/rfc's, dus het is niet zomaar een blog van een random ontwikkelaar met een idee, maar daadwerkelijk iemand die weet waar hij over praat.
Wil niet zeggen dat het ook echt geaccepteerd wordt, maar wel dat het een serieuze mogelijkheid is..

[NMe]

Klopt, maar het zijn niet bepaald nieuwe ideeën. Het feit dat er in al die tijd dat ze al ter sprake zijn niets met die ideeën is gedaan stemt niet echt hoopvol. Al is het mysterieuze gedoe rondom PHP 6 misschien omdat ze eindelijk eens de juiste keuzes maken. De tijd zal het leren.

[R4gnax]

NMe schreef op zondag 16 maart 2014 @ 14:10:
PHP heden ten dage nog afdoen als "het blijft een template engine" is niet eerlijk. Er zijn nog héél veel dingen stuk maar die opmerking doet eigenlijk alle stappen die de ontwikkelaars van de taal hebben gezet om de taal op te laten groeien af als onbelangrijk, en zo ver zou ik niet willen gaan.

Ik zou het eerder zo stellen; wat er aan PHP op het moment uitgebouwd wordt, komt neer op wolkenkrabbers bouwen op drijfzand. De fundering is en blijft ruk en dat zal door blijven schijnen. Zo niet in quirky architectuurkeuzes en verwrongen APIs dan wel in performance degradatie door alle lagen extra dekverf die er nodig zijn om de drek weg te poetsen.

NMe schreef op donderdag 06 maart 2014 @ 15:45:
Kittens just died.

Merethil schreef op donderdag 06 maart 2014 @ 16:59:
Kittens just died again...

Het is PHP; alle kittens zijn a lang en breed verzopen in het drijfzand.

[NMe]

R4gnax schreef op dinsdag 18 maart 2014 @ 21:56:
[...]

Ik zou het eerder zo stellen; wat er aan PHP op het moment uitgebouwd wordt, komt neer op wolkenkrabbers bouwen op drijfzand. De fundering is en blijft ruk en dat zal door blijven schijnen. Zo niet in quirky architectuurkeuzes en verwrongen APIs dan wel in performance degradatie door alle lagen extra dekverf die er nodig zijn om de drek weg te poetsen.

De mate waarin het door blijft schijnen is natuurlijk sterk afhankelijk van wat je zelf met je code doet. Wanneer je een goed framework gebruikt met ORM, namespaces, een arsenaal aan fatsoenlijke wrappers voor standaardfunctionaliteit, enz. kom je al een heel eind. De enige "problemen" die je dan regelmatig tegen zou kunnen komen hebben te maken met dynamic/weak typing, het niet kunnen type hinten van primitieve types en een paar andere dingen waar best mee te werken zijn. Ik kan me de laatste keer dat ik door een ==/===-probleem in de problemen kwam niet eens meer herinneren en het typehintingprobleem vang je grotendeels af met PHPDoc en een goeie IDE. De meeste dingen die geopperd worden als probleem in PHP zijn weliswaar in de basis echt onhandig maar hebben doorgaans ook oplossingen die het probleem trivialiseren zonder dat je erover hoeft na te denken.

[Gomez12]

NMe schreef op dinsdag 18 maart 2014 @ 22:09:
[...]

De mate waarin het door blijft schijnen is natuurlijk sterk afhankelijk van wat je zelf met je code doet. Wanneer je een goed framework gebruikt met ORM, namespaces, een arsenaal aan fatsoenlijke wrappers voor standaardfunctionaliteit, enz. kom je al een heel eind.

Het nadeel is alleen dat het wolkenbouwers blijven.
Een goed PHP-framework is over het algemeen niet cheap (qua performance) en dat vind ik toch zonde. De php-broncode is best snel, maar frameworks die in php gebouwd zijn om pijnpunten binnen php op te lossen zijn echt vele malen trager waardoor je er weer een apc / nginx etc voor moet zetten en het idee van lean and mean en snel iets opzetten verdwijnt en het meer richting een enterprise programmeertaal gaat, alleen dan zonder de specifieke optimalisaties en met de php-ondergrond (en op sommige plekken nog de bovengrond)

Zie bijv dat je php-hosting hebt, maar daarnaast ook wordpress / magento pakketten omdat die veelal niet goed presteren onder standaard php-hosting (waarmee ik niet wil zeggen dat wordpress / magento juweeltjes zijn qua programmeren of de meest briljante frameworks gebruiken maar het geeft wmb toch iets aan)

PHP is te gebruiken voor grotere toepassingen, maar dan ben je veelal de voordelen boven een willekeurige "grotere" taal kwijt (lean and mean, snel inzetbaar, snel resultaat) en houdt je toch de kleine irritaties van php. Plus dat je beheer opeens uit vele ongerelateerde pakketten gaat bestaan.
Voor een echte enterprise toepassing is bovenstaande niet zo relevant (daar heb je die geintjes ongeacht welke taal je kiest) maar voor de kleine / iets grotere toepassingen heeft het wmb weinig voordeel terwijl ik wel de nadelen blijf behouden.

[hillbillie]

Zolang je het SOLID principe hanteert, je klassen goed unittest, documentatie schrijft e.d. kan je wat mij betreft elke programmeertaal gebruiken.

Tuurlijk, php heeft soms zijn eigenaardigheden, maar noem mij eens een taal waar je dit niet in hebt... juist

Alle talen spelen leentjebuur bij concurrerende talen, zo vind ik PHP steeds meer op java lijken met de SPL toevoegingen.

Wat ik wel een heel groot voordeel van PHP tov andere talen vind, is dat er zo ontiegelijk veel opensource packages zijn te vinden en de frameworks/libraries zijn echt goed `mature`. Symfony2 en Doctrine zijn gewoon degelijk.

[PatrickH89]

Gomez12 schreef op woensdag 19 maart 2014 @ 00:43:
[...]

Het nadeel is alleen dat het wolkenbouwers blijven.
Een goed PHP-framework is over het algemeen niet cheap (qua performance) en dat vind ik toch zonde. De php-broncode is best snel, maar frameworks die in php gebouwd zijn om pijnpunten binnen php op te lossen zijn echt vele malen trager waardoor je er weer een apc / nginx etc voor moet zetten en het idee van lean and mean en snel iets opzetten verdwijnt en het meer richting een enterprise programmeertaal gaat, alleen dan zonder de specifieke optimalisaties en met de php-ondergrond (en op sommige plekken nog de bovengrond)

Zie bijv dat je php-hosting hebt, maar daarnaast ook wordpress / magento pakketten omdat die veelal niet goed presteren onder standaard php-hosting (waarmee ik niet wil zeggen dat wordpress / magento juweeltjes zijn qua programmeren of de meest briljante frameworks gebruiken maar het geeft wmb toch iets aan)

PHP is te gebruiken voor grotere toepassingen, maar dan ben je veelal de voordelen boven een willekeurige "grotere" taal kwijt (lean and mean, snel inzetbaar, snel resultaat) en houdt je toch de kleine irritaties van php. Plus dat je beheer opeens uit vele ongerelateerde pakketten gaat bestaan.
Voor een echte enterprise toepassing is bovenstaande niet zo relevant (daar heb je die geintjes ongeacht welke taal je kiest) maar voor de kleine / iets grotere toepassingen heeft het wmb weinig voordeel terwijl ik wel de nadelen blijf behouden.

Je verhaal is leuk, maar dat er speciale Wordpress en Magento hosting is geeft puur en alleen aan dat die waardeloos zijn mbt architectuur, niets anders.

[RayNbow]

hillbillie schreef op woensdag 19 maart 2014 @ 10:23:
Tuurlijk, php heeft soms zijn eigenaardigheden, maar noem mij eens een taal waar je dit niet in hebt... juist

Lambda calculus?

[NMe]

Gomez12 schreef op woensdag 19 maart 2014 @ 00:43:
[...]

Het nadeel is alleen dat het wolkenbouwers blijven.
Een goed PHP-framework is over het algemeen niet cheap (qua performance) en dat vind ik toch zonde.

Dat hangt van het framework af. Zoals ik eerder al riep in dit topic gebruiken we vanwege enkele specifieke eisen op kantoor een in-house ontwikkeld framework en de performance daarvan is amper (verwaarloosbaar) lager dan die van native code.

Het jammere is dat PHP een ingebouwde library met functies heeft, of een "standaardframework" als je het zo wil noemen. Andere talen hebben dat ook maar daar staat het framework doorgaans los van de taal. PHP en diens framework worden echter gelijkgesteld aan elkaar terwijl de meeste kritiek die er op de taal is eigenlijk kritiek op het framework is en dus te voorkomen is met een goed eigen framework daarbovenop.

[begintmeta]

NMe schreef op woensdag 19 maart 2014 @ 11:52:
[...]

Dat hangt van het framework af. Zoals ik eerder al riep in dit topic gebruiken we vanwege enkele specifieke eisen op kantoor een in-house ontwikkeld framework en de performance daarvan is amper (verwaarloosbaar) lager dan die van native code.
...

Hoe is dat eigenlijk getest? (vergeef me mijn onkunde, ik heb nu eenmaal weinig met softwareontwikkeling te maken)

[Sh4wn]

TheNephilim schreef op donderdag 06 maart 2014 @ 11:53:
Zijn er nog vrijwilligers die een Python/Ruby variant van Wordpress willen maken?

Nee niet een willekeurige CMS in één van de genoemde talen, maar gewoon een kopie met dezelfde gebruiksvriendelijkheid voor de klant, maar dan met fatsoenlijke architectuur en code . Oh en het moet ook makkelijk uit te breiden en aan te passen zijn...

Maar, ik heb nog veel te leren. Ik vind het alleen zo lastig om iets te maken waarvoor ik ook meteen een toepassing heb. Anders komt het er toch niet van. Daarnaast zijn er nog zoveel andere dingen die ik wil/moet doen.

/me Mist .oisyn's Quick-Quote functie...

Mezzanine is een zeer goed Django gebaseerd CMS, wat volgens mij behoorlijk dicht in de buurt komt van Wordpress. Bevat veel functionaliteit builtin, en is bijzonder makkelijk uit te breiden met eigen functionaliteit. Plus de source code zit gewoon goed in elkaar.

[ Voor 5% gewijzigd door Sh4wn op 19-03-2014 12:31 ]

[NMe]

begintmeta schreef op woensdag 19 maart 2014 @ 12:06:
[...]

Hoe is dat eigenlijk getest? (vergeef me mijn onkunde, ik heb nu eenmaal weinig met softwareontwikkeling te maken)

Ik weet er het fijne ook niet van omdat ik die tests niet zelf uitgevoerd heb maar degene die het getest heeft zal sowieso naar de parsetijd gekeken hebben en naar de CPU- en memory-footprint.

[ Voor 38% gewijzigd door NMe op 19-03-2014 12:27 ]

[Barryvdh]

NMe schreef op woensdag 19 maart 2014 @ 12:27:
[...]

Ik weet er het fijne ook niet van omdat ik die tests niet zelf uitgevoerd heb maar degene die het getest heeft zal sowieso naar de parsetijd gekeken hebben en naar de CPU- en memory-footprint.

Nouja, het is natuurlijk wel lastig vergelijken met 'native php', want een framework doet ook veel meer. Het is alleen altijd de afweging dat een framework niet veel meer gaat doen dan dat je nodig hebt. En een framework maakt het meestal ook weer makkelijk om bijvoorbeeld caching te gebruiken, zodat het juist weer sneller wordt.

[SvMp]

PHP heeft een aantal hele 'lelijke' eigenschappen.

Een van de meest vreselijke dingen is het keyword global.

Daarnaast het niet OOP-karakter. Ik heb veel liever dat iedere request een class is en alle onderdelen via ingebouwde classes afgehandeld worden. Zo zou elke request een object kunnen zijn van een class die zaken als cookies, sessies en request data bij houdt. Beter dan die rare globale arrays.

PHP6 zou eigenlijk moeten breken met wat het nu is en zoals Java helemaal gericht moeten zijn op classes.

[ Voor 11% gewijzigd door SvMp op 19-03-2014 18:01 ]

[Barryvdh]

SvMp schreef op woensdag 19 maart 2014 @ 18:00:
PHP heeft een aantal hele 'lelijke' eigenschappen.

Een van de meest vreselijke dingen is het keyword global.

Daarnaast het niet OOP-karakter. Ik heb veel liever dat iedere request een class is en alle onderdelen via ingebouwde classes afgehandeld worden. Zo zou elke request een object kunnen zijn van een class die zaken als cookies, sessies en request data bij houdt. Beter dan die rare globale arrays.

PHP6 zou eigenlijk moeten breken met wat het nu is en zoals Java helemaal gericht moeten zijn op classes.

Zoals de Symfony HttpFoundation dus? http://symfony.com/doc/cu...ndation/introduction.html

In PHP, the request is represented by some global variables ($_GET, $_POST, $_FILES, $_COOKIE, $_SESSION, ...) and the response is generated by some functions (echo, header, setcookie, ...).
The Symfony2 HttpFoundation component replaces these default PHP global variables and functions by an object-oriented layer.

[ Voor 23% gewijzigd door Barryvdh op 19-03-2014 18:59 ]

[NMe]

SvMp schreef op woensdag 19 maart 2014 @ 18:00:
PHP heeft een aantal hele 'lelijke' eigenschappen.

Een van de meest vreselijke dingen is het keyword global.

Niemand dwingt je dat te gebruiken. De meeste moderne talen hebben ook een goto en toch zal vrijwel iedere programmeur wel 100 keer nadenken of er geen betere oplossing is voor 'ie die gebruikt.

Daarnaast het niet OOP-karakter. Ik heb veel liever dat iedere request een class is en alle onderdelen via ingebouwde classes afgehandeld worden. Zo zou elke request een object kunnen zijn van een class die zaken als cookies, sessies en request data bij houdt. Beter dan die rare globale arrays.

Zonder daadwerkelijk een framework te hebben zou je vervolgens zonder globals geen enkele manier hebben om die cookies, sessies en requestgegevens aan te spreken. In een framework heb je waarschijnlijk iets als Kernel::getApplication()->getRequest()->getPostParameter('foo') of een makkelijke shorthand daarvoor, maar de library van PHP biedt daar geen ruimte voor. Je hebt hier dan ook geen kritiek mee op de taal maar op het standaardframework, en dat framework is niet begonnen als framework maar als library. Zend heeft vrij vroeg het Zend Framework opgezet als "fatsoenlijk" alternatief daarvoor. Tegenwoordig is Symfony een van de betere PHP-frameworks waarmee je je code vrijwel geheel zo op kan zetten als je omschrijft.

PHP6 zou eigenlijk moeten breken met wat het nu is en zoals Java helemaal gericht moeten zijn op classes.

Met het eerste deel van die zin ben ik het eens, maar met het tweede deel niet. Een taal hoeft echt niet volledig OOP te zijn om er volledig OOP mee te kunnen werken.

[simplicidad]

Waar ik mij soms nog het meest aan stoor - alhoewel de inconsistenties hoog genoteerd staan - is het soort van volk die het aantrekt.

Ik werk als Drupal* ontwikkelaar en eerlijk gezegd ik kom dagdagelijks dingen tegen waar ik toch even van in mijn haar krab. PHP ontwikkelaars die zelf geen basis kennis van OOP hebben, met moeite weten wat een singleton is of die code schrijven alsof het nog altijd het jaar 1997 is.

Laatst werd ik nog teruggefloten omdat ik unit tests schreef en dat niet wenselijk was omdat we geen "echte" software ontwikkelden. Een ander argument was ook dat qua offertes we tegenover bedrijven staan die het op dat vlak ook niet nauw namen en dat financieel (tijdverlies) te kostelijk is. Dat zegt eigenlijk al veel over de standaard die men soms hanteert.

Pas op aan de andere kant ken ik ook mensen die in PHP ontwikkelen en die hun job echt wel ten harte nemen. In die zin ik las hier ergens de opmerking dat je PHP niet snel terugvind in de enterprise sector of bij grote bedrijven, maar daar zou je toch schromelijk in kunnen vergissen.

Ik ken toch wel enkele projecten bij een BNP Baribas, InBev , VMMA om een paar te noemen, die toch echt wel in PHP (Symfony wel ) zijn ontwikkeld. Voor ik deze job had heb ik ook heel wat PHP opdrachten gehad voor een Capgemini bvb.

* Drupal is dan op zich ook al een wereld vol pijn. Ik heb (naïef waarschijnlijk) mijn hoop gevestigd op Drupal 8 die meer Symfony componenten zal gebruiken. Het zegt al veel dat er een fork bestaat BackDrop omdat er een groep developers zijn die al die "professionele" zaken niet wil leren en te complex vind.

[ Voor 211% gewijzigd door simplicidad op 19-03-2014 22:37 ]

[MeZZiN]

Voor mij is PHP een middel net zoals java dat ook is.

Zelf genoeg talen geleerd en gebruikt.

Ik heb geen issues met PHP het is prima voor kleine/middel grote projecten en een prima taal om mee te scripten. Grootste probleem is taal is niet zo mooi en consistent. OO is niet goed geïmplementeerd maar al in al goed genoeg voor het doel. Tevens aardig wat vreemde bugs die soms opgelost worden door alleen de code in andere volgorde te zetten. Ik denk wel dat PHP er te vaak te veel mee gedaan wordt waarbij het te complex wordt en PHP niet helemaal voldoet. Maar ik heb zelf PHP op high (extreem) traffic websites / apis gebruikt (zonder fameworks) en het werkt geniaal op AWS. Zou dat niet zo makkelijk zo goed kunnen maken in Java. That said de meeste frameworks in PHP zijn niet super snel omdat alles elke request opnieuw geladen moet worden. Het is niet traag maar snel ook niet en daar heeft een taal zoals JAVA (of beter gezegd de application server het beter voor elkaar.)

Dus all in all niet slecht maar zeker geen super taal veel afwijkende functies en niet echt voorspelbaar hoe ze heten. Maar niet slecht ik ben wel blij dat ik weer even een tijdje java kan schrijven. Maar zoals ik al aangeef als developer kies ik te taal die het beste werkt voor de Usecase en soms is dat PHP en soms java of soms python of vul taal in. Voor elke usecase is de juiste oplossing of meerdere.

Voor mij is er niets mis met PHP alleen het kan zeker beter maar dat kan ik ook zeggen van Java of vul random taal in.

[.oisyn]

nieuws: Facebook geeft eigen op php gebaseerde programmeertaal vrij

[NMe]

.oisyn schreef op donderdag 20 maart 2014 @ 18:52:
nieuws: Facebook geeft eigen op php gebaseerde programmeertaal vrij

Waarom in hemelsnaam de Pascal-syntax voor returntypes? PHP heeft toch nog het meest weg van C, had dan die syntax overgenomen...

[.oisyn]

Omdat dat de parser behoorlijk wat complexer maakt, en je dan in de knoei komt met return types in lambda's. Bij lambda's in C++ komt het return type ook achter de parameterlijst.

[ Voor 55% gewijzigd door .oisyn op 20-03-2014 19:11 ]

[NMe]

Fair enough. Blijft lelijk though.

[.oisyn]

*kuch*

[Caelorum]

NMe schreef op donderdag 20 maart 2014 @ 19:13:
Fair enough. Blijft lelijk though.

Is gewoon gewenning, Actionscript 3 en typescript hebben het ook op die manier.

[Gomez12]

simplicidad schreef op woensdag 19 maart 2014 @ 21:48:
Waar ik mij soms nog het meest aan stoor - alhoewel de inconsistenties hoog genoteerd staan - is het soort van volk die het aantrekt.

Ik werk als Drupal* ontwikkelaar en eerlijk gezegd ik kom dagdagelijks dingen tegen waar ik toch even van in mijn haar krab. PHP ontwikkelaars die zelf geen basis kennis van OOP hebben, met moeite weten wat een singleton is of die code schrijven alsof het nog altijd het jaar 1997 is.

Laatst werd ik nog teruggefloten omdat ik unit tests schreef en dat niet wenselijk was omdat we geen "echte" software ontwikkelden. Een ander argument was ook dat qua offertes we tegenover bedrijven staan die het op dat vlak ook niet nauw namen en dat financieel (tijdverlies) te kostelijk is. Dat zegt eigenlijk al veel over de standaard die men soms hanteert.

Zoals ik het lees heeft het soort volk niets met PHP te maken, maar meer met het bedrijf waar je werkt.
Als jullie bedrijf met zolderkamerprogrammeurs zit te concurreren dan kan je idd geen unit-tests maken, maar in elke taal heb je zolderkamerprogrammeurs alleen een goed bedrijf weet daar bovenuit te komen ongeacht de taal.

In die zin ik las hier ergens de opmerking dat je PHP niet snel terugvind in de enterprise sector of bij grote bedrijven, maar daar zou je toch schromelijk in kunnen vergissen.

Ik betwijfel toch ten zeerste of PHP een relevant deel van het it-budget inpikt op enterprise nivo.
Uiteraard wordt er wel eens wat mee gedaan, maar dat wordt overal wel mee.

[Cyphax]

NMe schreef op donderdag 06 maart 2014 @ 15:45:
Kittens just died.

Mooi he? Ik heb ook weleens iets zitten schrijven in PHP, kan goed ook function overloading geweest zijn, en op gegeven moment zat ik me af te vragen wat ik nou in vredesnaam aan het doen was. Het werkte wel maar het voelde erg wankel aan om de een of andere reden. Dit soort dingen heb ik eigenlijk altijd het meest opvallende vreemde aan PHP gevonden. Maar het is ook niet zo dat ik er daardoor een hekel aan PHP heb overgehouden. Het is gewoon een beetje... vreemd. Je moet het min of meer gewoon accepteren.

[Kajel]

Ik ben ook ooit met PHP begonnen, en heb een hartgrondige hekel gekregen aan de taal. Het merendeel van de redenen is al meermaals in dit topic genoemd. Tegenwoordig ben ik vooral bezig met Java & Scala voor mijn werk, Python en Scala voor mijn hobbyprojecten. Alle 3 de talen hebben - zoals ook van PHP gezegd wordt - zo hun voor- en nadelen, maar ik hou van alle 3 de talen, met hun toffe aspecten en tekortkomingen.

Wat ik zo interessant vind aan de hele PHP discussie, is dat er door voorstanders keer op keer wordt gezegd dat elke taal zijn voor- en nadelen heeft, dus PHP ook. En dat ook PHP voor sommige "jobs" de juiste "tool" is. Dat laatste durf ik tegen te spreken. Er is geen enkele job waarbij PHP een betere keuze is dan andere talen. De traditioneel "sterke" kant van PHP, webdevelopment, kan tegenwoordig heel goed - nee, beter zelfs - met een hoop andere talen, zoals Java, Scala, Python, Ruby etc. En als we het hebben over laagdrempeligheid, dan zijn Ruby on Rails en bijvoorbeeld Python met Flask, prima instap-mogelijkheden.

Het enige "voordeel" van PHP, is dat elke webhost het draait. En dat is waarschijnlijk meteen het grootste nadeel, naast alle taal-specifieke tekortkomingen. Ik vind niet dat programmeren een elite-bezigheid moet zijn, en dat is het ook niet als je ziet hoe laagdrempelig bv. Python is, maar ik vind wel dat je als beginnend developer je tools moet leren kennen. Dat gebeurt niet als je enkel een zwik aan ongeordende PHP bestanden naar een servertje toe-FTPt.

Ik heb toevallig een tijdje terug - mede door de observatie dat er zoveel negatieve geluiden over PHP op het web verschenen - een verzameling gemaakt van een hoop kritieken op PHP en een hoop misstanden binnen de PHP community. Die kun je hier vinden.
Toen ik dit begin deze week op Twitter plaatste, brak de hel los. Ik kreeg de halve PHP community over me heen. Nu zie ik ook wel in dat ik hier en daar wat kort door de bocht ben geweest in mijn commentaren op de artikelen en tweets die ik in het verhaal deel, maar de heftige reacties die ik krijg, geven wel aan dat er een gevoelige snaar geraakt wordt, waarschijnlijk omdat men aanvoelt dat er een grote kern van waarheid in alle negativiteit zit.

Ik kreeg ook regelmatig de opmerking "doe er dan wat aan i.p.v. erover te zeiken". Leuk bedacht, maar het heeft wat mij betreft geen zin om er tijd in te steken omdat er zoveel betere alternatieven zijn.

[NMe]

Kajel schreef op zaterdag 22 maart 2014 @ 11:41:
De traditioneel "sterke" kant van PHP, webdevelopment, kan tegenwoordig heel goed - nee, beter zelfs - met een hoop andere talen, zoals Java, Scala, Python, Ruby etc. En als we het hebben over laagdrempeligheid, dan zijn Ruby on Rails en bijvoorbeeld Python met Flask, prima instap-mogelijkheden.

Python diskwalificeert zichzelf wat mij betreft door betekenis te geven aan whitespace; formatting heeft niks met de werking van je code te maken. En Ruby draait op bijna geen enkele host, dus daar gaan je goedkope hostingkeuzes.

Verder:

Er is geen enkele job waarbij PHP een betere keuze is dan andere talen.

Een aardig statement. Wie ben jij om dat te bepalen? Misschien is brede ondersteuning bij hosters wereldwijd wel een vereiste van het product dat je neer wil zetten.

[R4gnax]

NMe schreef op zaterdag 22 maart 2014 @ 13:54:
Misschien is brede ondersteuning bij hosters wereldwijd wel een vereiste van het product dat je neer wil zetten.

Die brede ondersteuning wereldwijd is niet zo zeer een eigenschap van PHP, maar eerder een eigenschap van het feit dat er lang niets anders geweest is wat voor een lage kostprijs op een serve te draaien viel. Het is een verschijnsel wat puur voortgekomen is uit het feit dat PHP op de low-end hosting markt een monopolie positie had en die situatie begint zich nu er alternatieven zijn, pas te veranderen.

Vanuit de business kant is het nog steeds een goed argument, maar het spreekt niet voor of tegen PHP specifiek. Als Microsoft jaren geleden besloten had om Mono stevig te backen en uit te ontwikkelen, dan had PHP op dit moment al in de goot gelegen en hadden alle hosters in plaats daarvan goedkoop Mono aangeboden.

[dylanvana]

Iedereen lekker haten op PHP terwijl het telkens maar marktaandeel blijft snoepen van de "traditionele" talen. Ondertussen ga ik even PHP updaten en de changelog bekijken.

Ruby schijnt ook in trek te raken in andere gebieden van de wereld. Iemand hier ervaring mee? Is de syntax een beetje met PHP te vergelijken?

*Googlen gaat*

[RayNbow]

NMe schreef op zaterdag 22 maart 2014 @ 13:54:
[...]

Python diskwalificeert zichzelf wat mij betreft door betekenis te geven aan whitespace; formatting heeft niks met de werking van je code te maken.

Maar waarom zou een programmeertaal geen betekenis aan whitespace geven als mensen dat wel doen?

Herinneren we deze nog?

C:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;

[R4gnax]

dylanvana schreef op zaterdag 22 maart 2014 @ 15:35:
Iedereen lekker haten op PHP terwijl het telkens maar marktaandeel blijft snoepen van de "traditionele" talen.

Enige reden dat PHP marktaandeel groeit is dat een heleboel gratis CMS systemen zoals Wordpress in PHP geschreven zijn en door veel mensen neer gezet worden. Als je dat soort gegevens in je statistieken meeneemt, dan kom je er heel snel achter dat PHP al jaren in een zachtjes dalende lijn zit met af en toe een kleine opleving.

[ Voor 3% gewijzigd door R4gnax op 22-03-2014 15:54 ]

[NMe]

R4gnax schreef op zaterdag 22 maart 2014 @ 15:21:
[...]

Die brede ondersteuning wereldwijd is niet zo zeer een eigenschap van PHP, maar eerder een eigenschap van het feit dat er lang niets anders geweest is wat voor een lage kostprijs op een serve te draaien viel. Het is een verschijnsel wat puur voortgekomen is uit het feit dat PHP op de low-end hosting markt een monopolie positie had en die situatie begint zich nu er alternatieven zijn, pas te veranderen.

Waar het door komt boeit niet. Effectief is PHP nog steeds "marktleider" als het gaat om ruime beschikbaarheid en wereldwijde ondersteuning bij vrijwel elke hoster. Voor bedrijven die bijvoorbeeld forumsoftware, CMS'en, enz. ontwikkelen is het domweg een eis dat er een zo breed mogelijk publiek aangesproken kan worden. Dan kun je wel koppig je product in Ruby of Python schrijven, maar feit blijft dat je product dan veel minder gebruikt zal worden omdat de ondersteuning minder is.

RayNbow schreef op zaterdag 22 maart 2014 @ 15:45:
[...]

Maar waarom zou een programmeertaal geen betekenis aan whitespace geven als mensen dat wel doen?

Mensen doen het voor leesbaarheid, niet voor functionaliteit.

[ Voor 12% gewijzigd door NMe op 22-03-2014 16:56 ]

[Gomez12]

R4gnax schreef op zaterdag 22 maart 2014 @ 15:21:
[...]
Vanuit de business kant is het nog steeds een goed argument, maar het spreekt niet voor of tegen PHP specifiek. Als Microsoft jaren geleden besloten had om Mono stevig te backen en uit te ontwikkelen, dan had PHP op dit moment al in de goot gelegen en hadden alle hosters in plaats daarvan goedkoop Mono aangeboden.

Complete larie, als ik even je Mono voorbeeld overneem (maar het gaat op voor de meeste andere voorbeelden ook).

Mono is gewoon vanuit beheersoogpunt geen low-maintenance / low-performance taal en Microsoft had Mono wel gigantisch stevig moeten backen (waardoor hun eigen .Net weer minder was geworden, want je kan niet alles backen) en er gigantische hoeveelheden geld / programmeeruren in moeten steken om het enigszins op het low-cost level van een PHP te krijgen dat ze dat geld nooit terugverdiend hadden.

En vergeet ook niet dat er voor PHP er eigenlijk bijna geen markt was voor low-cost hosting (op wat cgi-scripts na dan), dus wat jij voorstelt is dat MS even miljarden gaat investeren in een techniek die niet hun core is (dat is de .Net kant) om een eigen markt te gaan creeeren, dat is simpelweg niet realistisch.

Ik ben ook niet blij met PHP, maar het heeft wel de webdevelopment markt een gigantische boost gegeven en compleet nieuwe markten gecreeerd, mede doordat PHP heeft aangetoond dat het kon zijn een Ruby en een Python ook richting web gegaan.

[incaz]

RayNbow schreef op zaterdag 22 maart 2014 @ 15:45:
[...]

Maar waarom zou een programmeertaal geen betekenis aan whitespace geven als mensen dat wel doen?

Echt erg is dat de tabs en spaties gemixt kunnen worden. En dan kun je dus toch hele rare effecten krijgen, ook in python.

[Caelorum]

Gomez12 schreef op zaterdag 22 maart 2014 @ 16:36:
[...]
Mono is gewoon vanuit beheersoogpunt geen low-maintenance / low-performance taal en Microsoft had Mono wel gigantisch stevig moeten backen (waardoor hun eigen .Net weer minder was geworden, want je kan niet alles backen) en er gigantische hoeveelheden geld / programmeeruren in moeten steken om het enigszins op het low-cost level van een PHP te krijgen dat ze dat geld nooit terugverdiend hadden.[...]

Mono is geen taal en daarnaast had MS uiteraard al het werk dat ze nu in hun eigen .net stack hebben gestouwd in mono kunnen steken. Dan was het waarschijnlijk net zo ver geweest, alleen dan cross-platform.
Ik snap overigens niet waarom iemand een low-performance platform zou willen hebben?

[ Voor 5% gewijzigd door Caelorum op 22-03-2014 16:55 ]

[RayNbow]

incaz schreef op zaterdag 22 maart 2014 @ 16:41:
[...]


Echt erg is dat de tabs en spaties gemixt kunnen worden. En dan kun je dus toch hele rare effecten krijgen, ook in python.

Ten eerste word thet mixen van tabs en spaties al door veel mensen als een doodzonde beschouwd en vandaar dat ook veel mensen hun editor zo instellen dat of de een of de ander gebruikt wordt, niet beide.

Ten tweede, als je per se tabs en spaties gaat mixen, dan moet je vooral zelfdiscipline hebben (of een intelligente editor als die bestaat) en de tabs en spaties ook zodanig gebruiken waarvoor ze bedoeld zijn: tabs voor inspringen, spaties voor uitlijnen.

Nu is het zo dat het in Python mogelijk is dat door incorrect mixen van tabs en spaties een bepaalde regel opeens in een ander statement block terecht komt, maar dan zou ik toch echt aanraden om Python altijd uit te laten voeren met -tt.

[Soultaker]

Caelorum schreef op zaterdag 22 maart 2014 @ 16:55:
Mono is geen taal en daarnaast had MS uiteraard al het werk dat ze nu in hun eigen .net stack hebben gestouwd in mono kunnen steken. Dan was het waarschijnlijk net zo ver geweest, alleen dan cross-platform.

FYI: Microsoft hád al een portable, semi-open-source implementatie van .NET gemaakt (Rotor, zie ook Wikipedia). Als ze een OSS implementatie van .NET wilden backen hadden ze dat project dus beter een OSS licentie kunnen geven, dan had Mono nooit ontwikkeld hoeven worden.

Ik snap overigens niet waarom iemand een low-performance platform zou willen hebben?

Het punt is dat PHP zelfs op een crappy virtual host nog redelijk performt, wat een belangrijk selling point is in de low budget hosting markt.

[NMe]

RayNbow schreef op zaterdag 22 maart 2014 @ 17:15:
[...]

Ten eerste word thet mixen van tabs en spaties al door veel mensen als een doodzonde beschouwd en vandaar dat ook veel mensen hun editor zo instellen dat of de een of de ander gebruikt wordt, niet beide.

Ten tweede, als je per se tabs en spaties gaat mixen, dan moet je vooral zelfdiscipline hebben (of een intelligente editor als die bestaat) en de tabs en spaties ook zodanig gebruiken waarvoor ze bedoeld zijn: tabs voor inspringen, spaties voor uitlijnen.

Je bent al de lul als je iemand anders z'n code base over moet nemen of erger nog: samen met een ander moet werken. Zelfs als er conventies zijn die je onderling afspreekt is een gewoonte erg lastig af te leren en als je het eenmaal fout doet in Python zit je te debuggen op spul dat niet eens in je code staat. PHP is een ramp, maar Python is ronduit achterlijk door die betekenis van whitespace.

[incaz]

RayNbow schreef op zaterdag 22 maart 2014 @ 17:15:
[...]

Ten eerste word thet mixen van tabs en spaties al door veel mensen als een doodzonde beschouwd en vandaar dat ook veel mensen hun editor zo instellen dat of de een of de ander gebruikt wordt, niet beide.

Ik vind het zo fijn dat die argumenten zo voorspelbaar zijn

Maar de redenatie klopt niet. Python lost het probleem dat hierboven werd aangehaald van misleidende whitespace niet op omdat de taal nog steeds geen consistente niet-ambigue whitespace enforcet. En als je toch op editors en zelfdiscipline moet vertrouwen is het dus geen meerwaarde van die taal.

(Mijn php-editors formatten mijn code overigens ook prima, en misleidende indentation zoals in het voorbeeld zou ik uberhaupt niet schrijven - met mijn zelfdiscipline is niets mis.)

(Python had trouwens daarin ook een heel praktisch probleem: het delen van codevoorbeelden via websites gaat nog wel eens mis omdat de blogsoftware daar niet consistent mee omgaat. Dat is te voorkomen, maar dat gebeurt niet altijd. En dan zit je met incorrecte code. Al die dingen samen maken toch dat die whitespace-afhankelijkheid heel wat meer fouten en verspilde tijd heeft opgelost dan heeft voorkomen. En dat zijn toch de punten waarop ik beoordeel of een bepaalde eigenschap een voordeel of een nadeel is. De praktijk is voor mij belangrijker dan een mooie theoretische onderbouwing.)

[Soultaker]

incaz schreef op zaterdag 22 maart 2014 @ 17:40:
Python lost het probleem dat hierboven werd aangehaald van misleidende whitespace niet op omdat de taal nog steeds geen consistente niet-ambigue whitespace enforcet. En als je toch op editors en zelfdiscipline moet vertrouwen is het dus geen meerwaarde van die taal.

Dat is nogal een zwart/wit argument; als Python 90% van de problemen weet af te vangen, heeft het dan géén meerwaarde omdat dat minder dan 100% is?

Editors en zelfdiscipline zijn ook niet 100% betrouwbaar (zie het goto-voorbeeld dat Raynbow aanhaalde -- wat in Python trouwens afgevangen zou zijn) -- hebben ze daardoor ook geen meerwaarde?

Python had trouwens daarin ook een heel praktisch probleem: het delen van code via websites gaat nog wel eens mis omdat de blogsoftware daar niet consistent mee omgaat.

Zou kunnen, maar je bent ook een aap als je productie-code van random blogs copy/pastet. (Overigens is de kwaliteit van PHP code op random weblogs ook niet bijster hoog!)

De praktijk is voor mij belangrijker dan een mooie theoretische onderbouwing.

Aangezien de praktijk zo zwaar meetelt: het probleem dat je net beschrijft ben ik in de praktijk nog nooit tegengekomen. Ik vraag me af wat voor Python programmeur je bent als je het probleem hebt dat je Python code niet goed werkt omdat je het slecht gecopy/paste hebt...

[ Voor 3% gewijzigd door Soultaker op 22-03-2014 18:02 ]

[Wolfboy]

NMe schreef op zaterdag 22 maart 2014 @ 17:37:
[...]

Je bent al de lul als je iemand anders z'n code base over moet nemen of erger nog: samen met een ander moet werken. Zelfs als er conventies zijn die je onderling afspreekt is een gewoonte erg lastig af te leren en als je het eenmaal fout doet in Python zit je te debuggen op spul dat niet eens in je code staat. PHP is een ramp, maar Python is ronduit achterlijk door die betekenis van whitespace.

Mag ik vragen wat voor editor jij gebruikt dat dit een probleem is? Het moet wel een vrij waardeloos ding zijn als ie uit zichzelf tabs/spaties gaat mixen.

Mijn editors (Vim, Eclipse, Pycharm) geven allemaal bij een tab gewoon 4 spaties en mocht iemand hier van willen afwijken dan is dit per project instelbaar. Daarnaast zou het eventueel nog te fixen zijn met een simpele git commit hook als je je dan echt zo stoort aan spaties/tabs.

Python 3 laat overigens geen tab/space mixing toe

[Gomez12]

Wolfboy schreef op zaterdag 22 maart 2014 @ 18:10:
[...]
Mag ik vragen wat voor editor jij gebruikt dat dit een probleem is? Het moet wel een vrij waardeloos ding zijn als ie uit zichzelf tabs/spaties gaat mixen.

Mijn editors (Vim, Eclipse, Pycharm) geven allemaal bij een tab gewoon 4 spaties en mocht iemand hier van willen afwijken dan is dit per project instelbaar. Daarnaast zou het eventueel nog te fixen zijn met een simpele git commit hook als je je dan echt zo stoort aan spaties/tabs.

Het moet een waardeloze editor zijn als hij het gaat mixen en dan ga jij aankomen met editor-instellingen die gewoon 1 toets op je toetsenbord waardeloos maken als antwoord?
Of je kan een git commit hook instellen?

Ik vind dit allemaal maar lelijke workarounds (vooral de git-commit hook is een lelijke als ik multiline text wil produceren vooraf gegaan door een tab, dan moet ik opeens erop gaan letten want anders commit ik andere code dan die ik gerund heb) voor een probleem wat simpelweg in de taal zit, niet in de editors.

Elke normale programmeertaal kan ik een willekeurige editor pakken en code typen, behalve bij python daar moet ik eerst allerlei checken omdat ik anders spontaan een kans heb dat ik in een moeras beland.

[gekkie]

Gomez12 schreef op zaterdag 22 maart 2014 @ 18:19:
[...]

Ik vind dit allemaal maar lelijke workarounds (vooral de git-commit hook is een lelijke als ik multiline text wil produceren vooraf gegaan door een tab, dan moet ik opeens erop gaan letten want anders commit ik andere code dan die ik gerund heb) voor een probleem wat simpelweg in de taal zit, niet in de editors.

Elke normale programmeertaal kan ik een willekeurige editor pakken en code typen, behalve bij python daar moet ik eerst allerlei checken omdat ik anders spontaan een kans heb dat ik in een moeras beland.

Tsja tis een keuze om indenting / formatting als onderdeel van de syntax te beschouwen.
Het gedwongen karakter daarvan is dan gelijk ook het voor en het nadeel

Het dwingt in iedergeval tot consistent indenten, en haalt een deel van je parentheses weg ...
dit in tegenstelling tot wat je bijvb in C (zie bijvb de linux kernel) tegenkomt .. met per C file en soms zelfs per delen van een file, andere code style wbt indenten en parentheses.
Natuurlijk zijn der dan nog genoeg onderdelen over zoals wel/niet camelCasen maar goed, tis iets :-)


Maar ik vind het persoonlijk niet echt vervelend werken.

[ Voor 22% gewijzigd door gekkie op 22-03-2014 18:31 ]

[Wolfboy]

Gomez12 schreef op zaterdag 22 maart 2014 @ 18:19:
[...]

Het moet een waardeloze editor zijn als hij het gaat mixen en dan ga jij aankomen met editor-instellingen die gewoon 1 toets op je toetsenbord waardeloos maken als antwoord?

Waardeloos? Het tab knopje werkt bij mij precies zoals ik verwacht dat een tab knop werkt.

Het indent m'n code... wat verwacht jij dat je tab knop doet dan?

Of je kan een git commit hook instellen?

Ik vind dit allemaal maar lelijke workarounds (vooral de git-commit hook is een lelijke als ik multiline text wil produceren vooraf gegaan door een tab, dan moet ik opeens erop gaan letten want anders commit ik andere code dan die ik gerund heb) voor een probleem wat simpelweg in de taal zit, niet in de editors.

Dat is ook een lelijke workaround, maar als mensen erop staan om non-conform te zijn heb je workarounds nodig.

Aangezien er vele duizenden Python programmeurs zijn die deze problemen niet ondervinden ga ik toch uit van PEBKAC.

Elke normale programmeertaal kan ik een willekeurige editor pakken en code typen, behalve bij python daar moet ik eerst allerlei checken omdat ik anders spontaan een kans heb dat ik in een moeras beland.

Bij elke fatsoenlijke editor staan de settings al goed, we hadden het nu over editors die blijkbaar niet-conform reageren. Daarom vroeg ik ook welke editor dat was

[incaz]

Soultaker schreef op zaterdag 22 maart 2014 @ 18:01:
[...]

Dat is nogal een zwart/wit argument; als Python 90% van de problemen weet af te vangen, heeft het dan géén meerwaarde omdat dat minder dan 100% is?

Ik betwist die 90%: python heeft mij met de ambigue whitespace meer problemen opgeleverd dan misleidende whitespace in php ooit heeft gedaan. Het lost dus niets op, het creeert een nieuw probleem. Vooral inderdaad op het vlak van het integreren van code die andere achtergronden en dus andere coding standards had.

Zou kunnen, maar je bent ook een aap als je productie-code van random blogs copy/pastet. (Overigens is de kwaliteit van PHP code op random weblogs ook niet bijster hoog!)

Nice frame :y Maar ik kopieer inderdaad wel eens voorbeeldjes om te proberen, shame on me, hoe durf ik!

Aangezien de praktijk zo zwaar meetelt: het probleem dat je net beschrijft ben ik in de praktijk nog nooit tegengekomen.

Geeft niks, ik ben het false indenting probleem in php nog nooit tegengekomen. (En het zou door mijn editor netjes geflagd worden trouwens.)

Dat argument is net zo lang als het breed is

[Gomez12]

Wolfboy schreef op zaterdag 22 maart 2014 @ 18:25:
[...]
Waardeloos? Het tab knopje werkt bij mij precies zoals ik verwacht dat een tab knop werkt.

Het indent m'n code... wat verwacht jij dat je tab knop doet dan?

Ik verwacht dat er een tab neergezet wordt.

[...]
Bij elke fatsoenlijke editor staan de settings al goed, we hadden het nu over editors die blijkbaar niet-conform reageren. Daarom vroeg ik ook welke editor dat was

Dus conform is volgens jou dat een druk op de tab-toets geen tab produceert, maar 4 spaties?

En ik vrees dat ik weinig van jouw "fatsoenlijke" editors ken, de meeste van mijn editors produceren simpelweg een tab en dan kan ik die instelling wijzigen naar hoeveel spaties ik wil (2 of 4 of 6 net naargelang het project en de codingstyle)

[Wolfboy]

Gomez12 schreef op zaterdag 22 maart 2014 @ 18:47:
Dus conform is volgens jou dat een druk op de tab-toets geen tab produceert, maar 4 spaties?

En ik vrees dat ik weinig van jouw "fatsoenlijke" editors ken, de meeste van mijn editors produceren simpelweg een tab en dan kan ik die instelling wijzigen naar hoeveel spaties ik wil (2 of 4 of 6 net naargelang het project en de codingstyle)

Conform is voor mij het produceren van output die verwacht wordt volgens de style guide van een bepaalde taal. Wat dat ook mag zijn, is dat bij jouw taal een tab dan moet het een tab doen, is het bij jouw taal een verzameling spaties dan moet het dat doen.

Als developer begrijp ik niet waarom je er uberhaupt om geeft of het tabs of spaties zijn. Of m'n editor nou 1 spatie, 100 spaties of 50 tabs naar een bestand wegschrijft is compleet irrelevant voor mij. Ik wil de code kunnen lezen en schrijven en verwacht een consistente reactie van mijn editor ongeacht de taal en het gebruik van tabs of spaties.

[RayNbow]

incaz schreef op zaterdag 22 maart 2014 @ 18:31:
[...] ambigue whitespace [...] Vooral inderdaad op het vlak van het integreren van code die andere achtergronden en dus andere coding standards had.

Wacht even... Als je code van een andere bron integreert, dan doe je dat normaal gesproken op bijv. module-niveau. Je plempt dus, in het geval van Python, de .py files naast de jouwe. Wanneer je dit doet, heb je geen probleem dat de code op een andere manier opgemaakt is.

Als je onder integreren verstaat dat je code handmatig gaat kopiëren van de ene source file naar de andere (geen idee waarom je dit wilt doen, maar goed), dan is er geen probleem wanneer je top-level definities kopiëert. Immers, deze beginnen in het geval van Python altijd in de eerste kolom. Hoe de definitie is opgemaakt maakt dan niets uit.

Dan blijft eigenlijk alleen inlinen van code over?

[NMe]

Wolfboy schreef op zaterdag 22 maart 2014 @ 18:10:
[...]
Mag ik vragen wat voor editor jij gebruikt dat dit een probleem is? Het moet wel een vrij waardeloos ding zijn als ie uit zichzelf tabs/spaties gaat mixen.

Mijn editor converteert alles prima naar spaties maar ik werk niet altijd aan projecten die spaties gebruiken voor indentering, of dat nu komt omdat ik samenwerk met iemand die zo nodig tabs wil gebruiken of omdat ik aan wat opensource-spul werk. En dan kan ik wel een conversie doen, maar dan heb ik weer alle bestanden in de repository gewijzigd voor zoiets achterlijks als whitespace, en alleen maar omdat een taal daar betekenis aan geeft. Het interesseert me niet als een ander tabs gebruikt zolang de tab spacing maar overeenkomt.

Python 3 laat overigens geen tab/space mixing toe

In elke andere taal is het geen probleem. Mensen geven hier uitgebreid af op PHP omdat het arbitraire dingen doet, maar een veel gekkere designkeuze dan betekenis geven aan whitespace kan ik niet bedenken...

[Gomez12]

Wolfboy schreef op zaterdag 22 maart 2014 @ 18:51:
[...]
Conform is voor mij het produceren van output die verwacht wordt volgens de style guide van een bepaalde taal.

Tja, zoals ik al zei : Ik ben bang dat ik weinig van favoriete editors ken, voor mij moet een editor namelijk taal-onafhankelijk zijn. Een IDE mag taalafhankelijk zijn, maar een editor is maar een editor wmb.

Als developer begrijp ik niet waarom je er uberhaupt om geeft of het tabs of spaties zijn.

Als developer geef ik er juist geen ene mallemoer om, daarom gebeurt het nog wel eens dat ze door elkaar heen gebruikt worden in 1 project over meerdere pc's / meerdere developers.
Alleen met python heb je een taal waarbij het opeens niet meer triviaal is en je er juist als developer opeens om moet gaan geven.

RayNbow schreef op zaterdag 22 maart 2014 @ 18:56:
[...]
Als je onder integreren verstaat dat je code handmatig gaat kopiëren van de ene source file naar de andere (geen idee waarom je dit wilt doen, maar goed), dan is er geen probleem wanneer je top-level definities kopiëert.

Ok, dus ik ben iets aan het maken. Ik zoek even wat documentatie over 1 statement op. Ik zie daar op inet 1 of 2 lange regels die ik voor 90% wil hebben. Natuurlijk copy/paste ik die (en indent ik die iets meer/minder) ipv over te typen, maar jij kan niet begrijpen waarom ik dit zou doen?

En dit is in zo ongeveer elke reguliere programmeertaal geen enkel probleem alleen in python heb ik een probleem als ik per ongeluk 1 of 2 tabs vergeet weg te halen

[incaz]

gekkie schreef op zaterdag 22 maart 2014 @ 18:25:

Wacht even... Als je code van een andere bron integreert, dan doe je dat normaal gesproken op bijv. module-niveau. Je plempt dus, in het geval van Python, de .py files naast de jouwe. Wanneer je dit doet, heb je geen probleem dat de code op een andere manier opgemaakt is

Ik integreer geen code op moduleniveau, ik gebruik gewoon een voorbeeld voor een bepaald probleem wat ik daarna aanpas aan mijn eigen wensen. Is dat iets dat je nooit doet?

Maar het punt is gewoon dat whitespace nogal fragiel is: als je altijd binnen je eigen editor blijft is het niet zo'n probleem maar als je daarbuiten komt krijg je code die makkelijk incorrect is. Een probleem dat je bij {}-blocks gewoon niet hebt.

[gekkie]

Een van de nadelen van PHP (wellicht voor sommigen dan weer een voordeel) is dat het nagenoeg alleen op het web als platform gericht is (ok ok php_cli does exist, maar zou het toch niet snel gebruiken om te proberen m'n seriele poort uit te lezen).
Voordeel van andere talen is dat je dezelfde taal kunt inzetten voor voor meer zaken (executables bakken, GUI, CLI scriptjes etc)

[gekkie]

incaz schreef op zaterdag 22 maart 2014 @ 19:13:
[...]


Ik integreer geen code op moduleniveau, ik gebruik gewoon een voorbeeld voor een bepaald probleem wat ik daarna aanpas aan mijn eigen wensen. Is dat iets dat je nooit doet?

Maar het punt is gewoon dat whitespace nogal fragiel is: als je altijd binnen je eigen editor blijft is het niet zo'n probleem maar als je daarbuiten komt krijg je code die makkelijk incorrect is. Een probleem dat je bij {}-blocks gewoon niet hebt.

Devil's advocate ... pas je de indenting en codestyle van het ge-inlinde stuk ook aan .. of laat je
dat dan gewoon soep zijn?

[ValHallASW]

Hoe is dat python-specific? Dat is toch de standaard tabs-versus-spaties-discussie? Als je tabs en spaties mixt in PHP dan wordt dat óók een bende. Dan ziet het er in jouw editor toevallig OK uit (omdat jij je tabs als 2 spaties hebt ingesteld), maar in een andere editor wordt het een rotzooitje (omdat diegene zijn tabs als 8 spaties heeft ingesteld).

Python 3 dwingt af dat je consistent bent in je indentation, python 2 geeft je ook nog de vrijheid om ze te mixen, zolang je je editor maar op 8 spaties per tab instelt.

Conclusie: Python zorgt ervoor dat code éénduidig te interpreteren is (met de eis dat je editor een tab als 8 spaties weergeeft). In elke andere taal moet je maar hopen dat tab-en-spatie-combinaties daadwerkelijk overeenkomen met hoe de blokken bedoeld waren.

[NMe]

Gomez12 schreef op zaterdag 22 maart 2014 @ 19:08:
[...]

Als developer geef ik er juist geen ene mallemoer om, daarom gebeurt het nog wel eens dat ze door elkaar heen gebruikt worden in 1 project over meerdere pc's / meerdere developers.
Alleen met python heb je een taal waarbij het opeens niet meer triviaal is en je er juist als developer opeens om moet gaan geven.

Amen.

ValHallASW schreef op zaterdag 22 maart 2014 @ 19:15:
Hoe is dat python-specific? Dat is toch de standaard tabs-versus-spaties-discussie? Als je tabs en spaties mixt in PHP dan wordt dat óók een bende.

In PHP of zo'n beetje elke andere taal is het ergste dat je kan gebeuren dat de code onleesbaar is. In Python is het dermate onderdeel van de taal dat er dingen stuk kunnen gaan als je indenting niet klopt. Niet bepaald de "standaard tabs-versus-spaties-discussie" dus.

[gekkie]

ValHallASW schreef op zaterdag 22 maart 2014 @ 19:15:
Hoe is dat python-specific? Dat is toch de standaard tabs-versus-spaties-discussie? Als je tabs en spaties mixt in PHP dan wordt dat óók een bende. Dan ziet het er in jouw editor toevallig OK uit (omdat jij je tabs als 2 spaties hebt ingesteld), maar in een andere editor wordt het een rotzooitje (omdat diegene zijn tabs als 8 spaties heeft ingesteld).

Python 3 dwingt af dat je consistent bent in je indentation, python 2 geeft je ook nog de vrijheid om ze te mixen, zolang je je editor maar op 8 spaties per tab instelt.

Conclusie: Python zorgt ervoor dat code éénduidig te interpreteren is (met de eis dat je editor een tab als 8 spaties weergeeft). In elke andere taal moet je maar hopen dat tab-en-spatie-combinaties daadwerkelijk overeenkomen met hoe de blokken bedoeld waren.

Counter argument zal wel zijn dat dat de interpreter niet boeit .. en die opzich de code nog wel netjes uitvoert ... dus het doet wat het moet doen.

maar goed met copy en paste'n in andere talen ook vaak genoeg dat het door spaties en tabs mix een soepzooitje is .. en je vervolgens niet ziet dat er ergens een haakje ontbreekt wat je vergeten bent mee te copy en paste'n.

Denk dat de meeste een probleem hebben met het dwingende karakter ervan

[incaz]

gekkie schreef op zaterdag 22 maart 2014 @ 19:15:
[...]


Devil's advocate ... pas je de indenting en codestyle van het ge-inlinde stuk ook aan .. of laat je
dat dan gewoon soep zijn?

Natuurlijk pas ik dat aan. Maar alt-shift-F weet gewoon wat het doen moet En als de code incorrect is, kan dat niet hersteld worden door een handige editor.

Mijn hele handige editor meldt overigens ook netjes als de haakjes niet matchen.

[gekkie]

incaz schreef op zaterdag 22 maart 2014 @ 19:22:
[...]

Natuurlijk pas ik dat aan. Maar alt-shift-F weet gewoon wat het doen moet En als de code incorrect is, kan dat niet hersteld worden door een handige editor.

Mijn hele handige editor meldt overigens ook netjes als de haakjes niet matchen.

Erhmmm de discussie was nou net dat je geen handige editor nodig moest hebben.
In een handige editor die herkent dat het python is .. zou die het ook gewoon consistent kunnen maken bij
een reformat.

Maar goed .. tis onderhand tijd om een "Wat is er tegelijkertijd mis en briljant in python" topic te openen ;-)

[ Voor 9% gewijzigd door gekkie op 22-03-2014 19:36 ]

[RayNbow]

NMe schreef op zaterdag 22 maart 2014 @ 19:06:
[...]

In elke andere taal is het geen probleem. Mensen geven hier uitgebreid af op PHP omdat het arbitraire dingen doet, maar een veel gekkere designkeuze dan betekenis geven aan whitespace kan ik niet bedenken...

Het idee stamt uit 1966 (ISWIM, If you See What I Mean).

Gomez12 schreef op zaterdag 22 maart 2014 @ 19:08:
[...]

Ok, dus ik ben iets aan het maken. Ik zoek even wat documentatie over 1 statement op. Ik zie daar op inet 1 of 2 lange regels die ik voor 90% wil hebben. Natuurlijk copy/paste ik die (en indent ik die iets meer/minder) ipv over te typen, maar jij kan niet begrijpen waarom ik dit zou doen?

Het zijn 1-2 regels? Als je dat in je eigen code plakt, dan zie je meteen in 1 oogopslag als je de code verkeerd plakt.

Als de code wat langer is, dan is de kans groot dat het generieke functionaliteit biedt en dus in een aparte (top-level) functie hoort.

incaz schreef op zaterdag 22 maart 2014 @ 19:13:
[...]

Ik integreer geen code op moduleniveau,

Ik wel. Ik vind of een package (en dan doe ik pip install awesomepkg en importeer vervolgens de jusite modules... lang leve code reuse)...

ik gebruik gewoon een voorbeeld voor een bepaald probleem wat ik daarna aanpas aan mijn eigen wensen. Is dat iets dat je nooit doet?

...of ik vind een stukje functionaliteit en dump ik het in een module/functie (lang leve code reuse).

[Wolfboy]

NMe schreef op zaterdag 22 maart 2014 @ 19:06:
[...]

Mijn editor converteert alles prima naar spaties maar ik werk niet altijd aan projecten die spaties gebruiken voor indentering, of dat nu komt omdat ik samenwerk met iemand die zo nodig tabs wil gebruiken of omdat ik aan wat opensource-spul werk. En dan kan ik wel een conversie doen, maar dan heb ik weer alle bestanden in de repository gewijzigd voor zoiets achterlijks als whitespace, en alleen maar omdat een taal daar betekenis aan geeft. Het interesseert me niet als een ander tabs gebruikt zolang de tab spacing maar overeenkomt.

Er zullen misschien een paar mensen zijn die tabs gebruiken met Python, maar in principe gebruikt iedereen spaties (dat is ook wat de officiele style guide adviseert) dus dat probleem zou je eigenlijk nooit moeten hebben. Als het voor een bepaald project wel een probleem is, wat me bij open source problemen tot nu toe 2x gebeurd is, dan is het advies om het om te zetten meestal voldoende en krijg je eigenlijk nooit bezwaren om het gewoon om te zetten.

In elke andere taal is het geen probleem. Mensen geven hier uitgebreid af op PHP omdat het arbitraire dingen doet, maar een veel gekkere designkeuze dan betekenis geven aan whitespace kan ik niet bedenken...

Tja... fatsoenlijke indenting is wegens de leesbaarheid aan te raden en wordt in principe in de meeste talen sowieso al gedaan dus ik zie het probleem eigenlijk niet.

Het nadeel is dat incorrecte indenting incorrecte code oplevert, het voordeel is wel dat je (zoals RayNbow zijn voorbeeld al liet zien) niet zomaar over foute code heen leest omdat de indenting verkeerd is.
Daarnaast heeft het nog het (imho) voordeel dat je minder syntax bloat hebt doordat je niet expliciet hoeft aan te geven waar je functie/class/etc. definities eindigen.

[incaz]

gekkie schreef op zaterdag 22 maart 2014 @ 19:31:
[...]
Erhmmm de discussie was nou net dat je geen handige editor nodig moest hebben.
In een handige editor die herkent dat het python is .. zou die het ook gewoon consistent kunnen maken bij
een reformat.

Een handige editor kan geen foute code corrigeren. Fucked up whitespace == incorrecte code. Mogelijk niet eens parse errors, maar incorrect werkende code.

En ik ben helemaal voor handige editors die je leven prettiger maken - het moet alleen geen noodzakelijkheid zijn voor de taal.

(Wat betreft mijn opmerking over integreren van modules: het ging er vooral om dat er ook situaties zijn waarin ik een deel van de code gewoon kopieer om aan te passen, zonder integratie op moduleniveau.)

[Wolfboy]

incaz schreef op zaterdag 22 maart 2014 @ 19:42:
[...]


Een handige editor kan geen foute code corrigeren. Fucked up whitespace == incorrecte code. Mogelijk niet eens parse errors, maar incorrect werkende code.

En ik ben helemaal voor handige editors die je leven prettiger maken - het moet alleen geen noodzakelijkheid zijn voor de taal.

Het is ook geen noodzakelijkheid voor de taal. Het is best mogelijk tabs en spaties te mixen (in Python 2 iig) alleen is het absoluut niet aan te raden.

Python gaat er vanuit dat 1 tab gelijk staat aan 8 spaties by default, dus als je het op die manier mixt werkt de code correct.

Voorbeeld:

Python:

def spam():
        print 'within spam with spaces'
    print 'within spam with tabs'

print 'Before calling spam'
spam()
print 'After calling spam'

Output:

Before calling spam
within spam with spaces
within spam with tabs
After calling spam

[ Voor 5% gewijzigd door Wolfboy op 22-03-2014 19:51 ]

[incaz]

Wolfboy, maar seriously, 8 spaties voor 1 tab? Dus de coding standard is halve tabs? En je def spam wordt zelfs door de editor hier waardeloos geformatteerd... dan kun je toch werkelijk niet met droge ogen beweren dat dat een goed idee is??

Ik kan daar echt met mijn verstand niet bij. Daarbij valt een niet-logische paramvolgorde toch ver in het niet.

[dcm360]

incaz schreef op zaterdag 22 maart 2014 @ 20:05:
Ik kan daar echt met mijn verstand niet bij. Daarbij valt een niet-logische paramvolgorde toch ver in het niet.

Om tabs te fixen heb ik niet de documentatie van de taal bijna continu open staan. Met de niet-logische parametervolgorde van PHP daarentegen...

[Kajel]

Ja maar lieve jongens en meisjes, gaan we nu echt de vermeende tekortkomingen van Python gebruiken om de aandacht af te leiden van PHP? Je kunt zeggen wat je wil, maar je hoeft je over het algemeen tegenover anderen minder te schamen als je Python gebruikt, dan dat je PHP gebruikt. Je wordt al snel meer serieus genomen.
Het is niet voor niets dat Python een heel scala aan wetenschappelijke libraries en tools heeft en diep doorgedrongen is in Universiteiten en andere delen van de wetenschappelijke gemeenschap. Je hoort zelden iemand die voor zijn proefschrift aan de slag is gegaan met PHP.

Dan nog even het eeuwige "PHP draait tenminste overal en is lekker makkelijk" argument. Ik blijf erbij dat goedkope, shared, flut-hosting juist enorm bijdraagt aan het PHP-probleem. Een VPS is bijna even goedkoop, en dan weet je _wel_ waar je mee bezig bent. Als je liever gebruiksgemak hebt, kun je in veel gevallen (Python, Ruby, Java etc.) terecht bij diverse PaaS oplossingen als Heroku.

Wetenschapswereld gebruikt oa veel Python, R en Haskell, hipster startups gebruiken Ruby of Scala, Enterprise wereld gebruikt Java, Windows desktop applicatie bouwers gebruiken C# en .NET. Game-devs gebruiken C++. Web-scale bedrijven als Twitter, Google en Facebook gebruiken een combinatie van alle voorgaande talen, for each job a different tool, en daarnaast nog wat exotischere opties als Erlang.
En ja, een enkel bedrijf als Facebook gebruikt ook PHP nog, omdat het goedkoper is om allerlei tools eromheen te bouwen zoals HHVM, en zelfs de taal opnieuw uit te vinden, dan om een enorme code-base te herschrijven. Maar FB springt ook heus geen gat in de lucht van de briljantie van PHP, anders was hun hele backend daar ook wel in geschreven.

Wat blijft over? Kneuzen met Wordpress sites (80% van het internet), ja, zelfs als die sites tot de top 10 van het internet behoren. Daar doet de kneuzigheid niets aan af

[Wolfboy]

incaz schreef op zaterdag 22 maart 2014 @ 20:05:
Wolfboy, maar seriously, 8 spaties voor 1 tab? Dus de coding standard is halve tabs? En je def spam wordt zelfs door de editor hier waardeloos geformatteerd... dan kun je toch werkelijk niet met droge ogen beweren dat dat een goed idee is??

Ik kan daar echt met mijn verstand niet bij. Daarbij valt een niet-logische paramvolgorde toch ver in het niet.

De coding standaard is 4 spaties, geen tabs. Maar als je ze toch wil mixen zal je 8 spaties per tab moeten gebruiken, waarvan ik overigens meermaals gezegd heb dat het een slecht idee is.

Het was simpelweg een illustratie dat het mogelijk is in tegenstelling tot wat sommige mensen hier denken/zeggen.