De Devschuur Coffee Corner - Iteratie ⓬

[RobertMe]

PatrickH89 schreef op donderdag 3 september 2020 @ 21:23:
Dat is afhankelijk van de zwaarte van de applicatie (en de zwaarte van de websockets functionaliteit). Als ik een blik programmeurs zou hebben voor elke taal zou PHP in dit geval niet de eerste keuze zijn, maar dat geldt ook voor talen als Python en Ruby. Dat zijn vooral de talen waar PHP een alternatief voor kan zijn denk ik.

Als ik een blik PHP developers heb en iets met websockets moet doen, dan zou ik iemand die voor de hobby kennis heeft van een andere taal die wel goed overweg kan met websockets, en liefst door meerdere personen in het team wordt gedragen, het laten maken in die taal.

En dat zeg ik als PHP developer. Use the right tool for the job, en PHP en websockets gaan IMO niet samen. Dat er extensies / implementaties zijn om het in PHP te laten werken maakt het ook nog niet the right tool. Als ik 10 pallets met zakken aardappelen van Maastricht naar Amsterdam moet brengen en m'n personeel heeft alleen een autorijbewijs zou ik ook een transportdienst regelen om het met een vrachtwagen te doen i.p.v. de auto('s) van het personeel vol laden en ze een ritje laten maken.

[PatrickH89]

Mugwump schreef op donderdag 3 september 2020 @ 21:34:
[...]


Ik vind Python nog wel een stuk breder. Data science in PHP, ik zie het nog niet zo.

Ik had de bedoeling daar ergens webapplicatie te typen, maar blijkbaar heb ik er applicatie van gemaakt. Er zijn wel bepaalde initiatieven (zoals een ML library), maar is absoluut niet vergelijkbaar met Python inderdaad.

RobertMe schreef op donderdag 3 september 2020 @ 21:35:
[...]

Als ik een blik PHP developers heb en iets met websockets moet doen, dan zou ik iemand die voor de hobby kennis heeft van een andere taal die wel goed overweg kan met websockets, en liefst door meerdere personen in het team wordt gedragen, het laten maken in die taal.

En dat zeg ik als PHP developer. Use the right tool for the job, en PHP en websockets gaan IMO niet samen. Dat er extensies / implementaties zijn om het in PHP te laten werken maakt het ook nog niet the right tool. Als ik 10 pallets met zakken aardappelen van Maastricht naar Amsterdam moet brengen en m'n personeel heeft alleen een autorijbewijs zou ik ook een transportdienst regelen om het met een vrachtwagen te doen i.p.v. de auto('s) van het personeel vol laden en ze een ritje laten maken.

Dat is niet echt een analogie die je betoog kracht bij zet eerlijk gezegd, ze moeten je punt duidelijk maken, niet ingewikkelder

That said, natuurlijk. Maar hetzelfde kan een paar jaar geleden gezegd zijn over Javascript gebruiken voor de backend. Er is intrinsiek geen reden waarom het niet zou kunnen en tools als Swoole, ReactPHP en Ratchet maken dit prima mogelijk. Er zit nog een aardig verschil tussen mensen met professionele PHP kennis negeren (als ze bijvoorbeeld ook ervaring hebben met zulke PHP oplossingen) en iemand laten hobbieën. Het is veel belangrijker om een oplossing te kiezen die voldoet in combinatie met dat het past bij het dev team dan een oplossing die perfect is, maar niet onderhouden kan worden.

[ Voor 68% gewijzigd door PatrickH89 op 03-09-2020 21:41 ]

[Ghehe]

Kalentum schreef op donderdag 3 september 2020 @ 21:05:
Maar wat is Enterprise? een product? Is Facebook enterprise? Of Nationale Nederlanden? Slager op de hoek? een bedrijf dat 2000 projecten per jaar doet? Philips? Is 'enterprise' een onderneming?

Ik blijf het een vage term vinden. Blijkbaar heb jij er een beeld bij, maar ik heb het niet.

Voor mij is een product Enterprise-waardig als je kan voldoen aan de vele non-functional requirements die grote bedrijven vaak stellen. Het vraagt ook wel een bepaalde ingesteldheid van een bedrijf om aan grote bedrijven te verkopen (heel veel meetings, veel juridisch gedoe, veel onderhandelen/extra uitleg geven, ...)

In welke taal de software is geschreven is bijzaak en helemaal niet van belang* als het maar voldoet aan de eisen uit een RFP, RFQ, ...

* Tenzij de Enterprise natuurlijk één of andere NFR/Governance regel uit zijn gat heeft getrokken die slechts bepaalde programmeertalen toelaat.

* Ghehe werkt voor een grote Enterprise

[gekkie]

PatrickH89 schreef op donderdag 3 september 2020 @ 21:23:
Dat is afhankelijk van de zwaarte van de applicatie (en de zwaarte van de websockets functionaliteit). Als ik een blik programmeurs zou hebben voor elke taal zou PHP in dit geval niet de eerste keuze zijn, maar dat geldt ook voor talen als Python en Ruby. Dat zijn vooral de talen waar PHP een alternatief voor kan zijn denk ik.

Python heeft een beetje wat Perl had (met CPAN), veel libs/modules van doorgaans aardige kwaliteit en in een hoop diverse richtingen (netwerk libs, datascience, webmeuk, GUI's) daarnaast als iets bindings heeft zijn er vaak ook Python bindings (OpenCV bijvb, nu ook java en javascript geloof ik ook).

Bij PHP was mijn indruk van modules in hun repo's toch wel minder (qua breedte van het veld, qua kwaliteit en volledigheid).

Al heeft PHP Perl uiteindelijk glansrijk verslagen, dus wie weet .
(gok dat dat voornamelijk de ASP-a-like combi van het lekker door elkaar mixen van code en templaten en htmlmeuk was).

Maar goed, zulke clean slates heb je zelden. Je hebt altijd te maken met de kennis van je developers en de applicaties die al ontwikkeld zijn. In die situatie is er weinig tot niets mis met PHP (en is het zo schaalbaar als je wilt). In zijn standaard vorm is PHP totaal niet afhankelijk van een server en oneindig horizontaal schaalbaar, puur omdat elk proces ophoudt nadat de request is afgehandeld. Dus in die zin was PHP 'serverless' voordat het cool was.

Klopt, maar goed dan kom ik weer terug op dat alles wat rond PHP een beetje fatsoenlijk is uitgewerkt eigenlijk alleen met web/cms te maken heeft. Maar dat nagenoeg alle andere talen hier in middels ook frameworks, templating libs etc voor hebben. Dat gecombineerd met ogenschijnlijk dalende interesse, zou mij wat voorzichtig maken als iets niet volledig in die niche valt en wat langer dan 5 jaar zou moeten meegaan.
Maar goed ieder zo zijn [A-Za-z] eigen overwegingen.

[.oisyn]

RagingPenguin schreef op donderdag 3 september 2020 @ 20:31:
PHP heeft geen arrays en geen hashing om effectieve (b)trees te bouwen (enkel one-size-fits-all ordered maps).

PHP's maps zijn weldegelijk unordered hashtables en niet ordered. Er is wel een volgorde, maar dat is de volgorde waarin elementen zijn toegevoegd, niet een volgorde die wordt bepaald door de waarde van de keys. De PHP docs zijn wat dat betreft ontzettend misleidend.

[ThomasG]

.oisyn schreef op donderdag 3 september 2020 @ 21:52:
[...]

PHP's maps zijn weldegelijk unordered hashtables en niet ordered. Er is wel een volgorde, maar dat is de volgorde waarin elementen zijn toegevoegd, niet een volgorde die wordt bepaald door de waarde van de keys. De PHP docs zijn wat dat betreft ontzettend misleidend.

Dat maakt PHP arrays dus ordered. Wat ze niet zijn is sorted (tenzij je ze zelf sorteert)

[.oisyn]

ThomasG schreef op donderdag 3 september 2020 @ 21:56:
[...]
Dat maakt PHP arrays dus ordered.

Dat is niet wat ik versta onder een ordered map

[gekkie]

.oisyn schreef op donderdag 3 september 2020 @ 22:04:
[...]

Dat is niet wat ik versta onder een ordered map

Wat verstaat de right honerable gentlemen dan onder Orderrrrrrrr Orderrrrrrrrrrrrrrrrrrrred map ?

[.oisyn]

Dat lijkt me toch evident uit mijn vorige post? In een ordered map bepalen de keys de volgorde.

Ik zie dat wikipedia een bredere betekenis van ordered maps aanhoudt, dat is niet hoe ik het geleerd heb (en hoe verschillende talen dat ook hebben opgepakt). Zie bijvoorbeeld http://www.mathcs.emory.e...abus/Map/ordered-map.html

[thlst]

RagingPenguin schreef op donderdag 3 september 2020 @ 20:31:
PHP heeft geen arrays en geen hashing om effectieve (b)trees te bouwen (enkel one-size-fits-all ordered maps).

Ze zijn er wel maar dat weten niet alle PHP ontwikkelaars

https://www.php.net/manual/en/spl.datastructures.php

[Wilf]

PHP voelt voor mij niet als een programmeertaal maar als extended HTML maar dat komt vooral omdat ik heb begin jaren nul gebruikte op m’n hobbysites voor dingen die niet in HTML zelf konden. Expressions en formules en fatsoenlijke contact forms en zo. Ik ben ook gestopt in 2007 met PHP, ik heb hier nog een dikke pil in de kast staan van PHP 3.0 Oh en MS was evil dus ASP weigerde ik iets mee te doen.

JS heb ik altijd lelijk gevonden. Gewoon lelijk om te lezen. this.stupidNamespace

Python is liev

Alhoewel ik idd een beetje simpel wordt van websockets binnen Python. Dan heb je heel het web vol met voorbeelden hoe je dat via asyncio en wait voor elkaar krijgt, en dat werkt, maar vervolgens blokkeert dat je main loop, of je het nou in een aparte thread runt of niet. Ben ik nou zo dom (retorische vraag)? Ik vind Python mooi en logisch tot aan websocketintegratie

[ Voor 9% gewijzigd door Wilf op 04-09-2020 00:49 ]

[Kalentum]

RagingPenguin schreef op donderdag 3 september 2020 @ 21:31:
[...]

Zoals ik al zei, het is een schaal en geen harde term. Verder denk ik dat het beter is als je 'enterprise software' in Google typed (no-offence maar ik weet echt niet hoe ik het beter zou moeten uitleggen).

Dat had ik al gedaan maar op basis van die definitie (vrij vertaald: software ter ondersteuning van bedrijven in plaats van individuen) kom ik geen stap verder.

Uiteindelijk zijn het de functionele eisen die bepalen of technologie X ingezet kan worden voor doel Y. De stelling 'PHP is niet enterprise ready' is dan per definitie ontkracht op het moment dat er PHP applicaties zijn die voor bedrijven bedoeld zijn. En zulke applicaties bestaan er.

En blijkbaar verwijst de term 'Enterprise' naar 'organisaties' dus dat is zo breed dat elke technologie die het beta stadium ontgroeit is en al een aantal jaren actief onderhouden wordt 'enterprise ready' is.

Als al je data in een enkele database zit, ja true. Maar al wilt je finance afdeling een export met openstaande facturen per klant en je haalt een lijst met projecten uit je ERP, een lijst met facturen een oracle database en een lijst met contactpersonen uit je CRM en moet die data in-memory joinen to rijen met factureren + project + contactpersoon dan gaat die vlieger niet op. En dan zijn schalende data structuren heel belangrijk, het verschil tussen O(n) en O(log(n)) voor het opzoeken van de juiste objecten word met duizenden rijen enorm.

(ook een typisch voorbeeld van 'enterprise' software)

Ah ok dat soort dingen. Dat zal wel in elke taal kunnen. Of je gebruikt een in-memory database die daarvoor bedoeld is. Voor zo'n generieke taak zou ik iets generieks pakken en niet zelf een datastructuur gaan implementeren.

[...]

Oke, fair point. Maar hoeveel php draait er op dotnet en hoeveel op een server in gci? En waarom zou je php willen gebruiken als je al een dotnet omgeving hebt? Wat heeft php wat de extra moeite waard maakt?

Ik heb geen idee, ik gebruik geen dotnet of PHP. Maar ik volg de redenatie: dotnet is enterprise ready, PHP draait op dotnet, dus daarmee is PHP enterprise ready

[...]


Ik snap deze zin niet helemaal? Vind je het gek dat sommige talen met een hoop data structuren komen? Eigenlijk heeft de taal zelf niets meer nodig dan arrays en een efficiënte manier om een hash van een value te maken en dan kan je alles implementeren als een library.

Wel, het woord 'extensions' kwam ter sprake, en VZIW zijn extensies meegecompileerde libraries. Terwijl in de meeste andere scripttalen alles via requires of includes of imports beschikbaar wordt gemaakt. Ik heb dat altijd vreemd gevonden van PHP, wellicht is het ondertussen anders.

[hackerhater]

Naar mijn mening is PHP enterprise ready, maar inderdaad niet de best tool for the job als je dingen als binairy trees nodig hebt of veel geheugen.

Maar laten we eerlijk zijn. Het gros van de applicaties, ook bij enterprise, zijn veredelde CRUD-applicaties met wat fancy UI en beheer pagina's er omheen. En dat kan PHP prima, zeker sinds versie 7 met de strong typing.

Op het moment dat je de reikwijdte van PHP ontgroeid moet je door naar (semi)compileerde talen als java en C#. Echter die hebben weer andere risico's gezien ze blijven draaien zoals memory-leaks.

Wat ik zelf in PHP nog mis: generics. Ik wil niet een collectie waar toevallig klasse A in zit (maar whatever in kan zitten), ik wil een collectie waar gegarandeerd alleen klasse A in zit.
Nu kan je dit prima in PHP doen, maar dan moet je de collectie zelf programmeren (Iterator interface).

In principe heeft PHP 2 type collecties:
- arrays (numeric array)
- hashmap (associate array)

Met een paar variaties erop zoals stacks en queues.

Dat kan soms inderdaad serieus beperkend zijn, maar voor het gros voldoet het.

[ Voor 11% gewijzigd door hackerhater op 04-09-2020 09:35 ]

[bauke1994]

hackerhater schreef op vrijdag 4 september 2020 @ 09:27:
Wat ik zelf in PHP nog mis: generics. Ik wil niet een collectie waar toevallig klasse A in zit (maar whatever in kan zitten), ik wil een collectie waar gegarandeerd alleen klasse A in zit.
Nu kan je dit prima in PHP doen, maar dan moet je de collectie zelf programmeren (Iterator interface).

Met Psalm en/of PHPStan kan je ondersteuning voor generics toevoegen aan PHP met behulp van static analysis. Het wordt dan alleen nog niet runtime afgedwongen, dat zou je dan nog in je implementatie kunnen inbouwen.

[hackerhater]

bauke1994 schreef op vrijdag 4 september 2020 @ 09:35:
[...]


Met Psalm en/of PHPStan kan je ondersteuning voor generics toevoegen aan PHP met behulp van static analysis. Het wordt dan alleen nog niet runtime afgedwongen, dat zou je dan nog in je implementatie kunnen inbouwen.

I know, dat is ook de reden waarom ik ervoor kies om zelf de collecties te maken.
Juist dat at runtime geweigerd wordt dat je er iets anders in stopt dan je verwacht.

Je hebt dan een functie a la :

code:

public function add(User $user): self { .... }

public function current(): User { .... }

Daar krijg je nooit iets anders in dan een User-object of een child ervan.

[ Voor 3% gewijzigd door hackerhater op 04-09-2020 09:39 ]

[bauke1994]

thlst schreef op donderdag 3 september 2020 @ 23:27:
[...]


Ze zijn er wel maar dat weten niet alle PHP ontwikkelaars

https://www.php.net/manual/en/spl.datastructures.php

Gebruik dan liever ext-ds ik heb er zelf geen ervaring mee maar het schijnt een stuk beter te zijn dan SPL.

[kenneth]

Antrax schreef op donderdag 3 september 2020 @ 09:59:
[...]

Snap inderdaad de haat niet tegen PHP.
Iedere taal heeft zijn voor en nadelen. Als je een taal niet leukt vindt, werk er dan niet mee? Hoef je het ook niet te bashen

Vierhonderd pagina's terug maar ik wil hier toch even op reageren.
Natuurlijk heeft elke taal zijn voor- en nadelen. Er zit alleen een verschil tussen voor- en nadelen die het gevolg zijn van afwegingen, voortschrijdend inzicht of ontwerpdoelstellingen aan de ene kant en ontwerpfouten aan de andere kant.

Dat ze bij Java voor de implementatie van generics hebben gekozen voor type erasure kun je ongelukkig noemen maar dat was een afweging (compatibility met eerdere JVMs als ik het me goed herinner). Een nadeel waar je mee moet leven.

Maar dan heb je de pipo's achter Go die doen alsof generics een heel ingewikkeld probleem zijn waar je echt wel heel goed over moet nadenken. Nee! Generics zijn een opgelost probleem en een goed begrepen techniek. In de eenentwintigste eeuw een serieuze taal ontwerpen zonder generics is geen "nadeel", het is dom.

Of als je van tevoren niet goed nadenkt over equality of identity (zie JS met ==, === en waarschijnlijk zullen ==== en ===== inmiddels ook wel bestaan) dan moet je dat oplossen met rare hacks en dan is dat niet een nadeel maar gewoon een ontwerpfout. Dat een nadeel noemen verdoezelt een ontwerpprobleem.

PHP is, onvermijdelijk door de ontstaansgeschiedenis, geen ontworpen taal van iemand met een achtergrond in de theorie van programmeertalen maar een project waar ad hoc nieuwe features tegenaan gegooid werden. Doorgeschoten pragmatisme. En slordigheid: (needle, haystack) vs (haystack, needle) en verschillende naming conventions. Begrijpelijk maar dat maakt het niet opeens acceptabel.

Die haat komt dus niet uit de lucht vallen. Het is geen Java vs C#, Linux vs Windows of emacs vs vi.

[hackerhater]

Het verleden van PHP was inderdaad niet netjes en dat is aan de oudere functies te zien.
Maar je kan het niet zomaar oplossen want dan breek je een hoop code.

Het nieuwe spul zit aardig goed in elkaar, maar de oude functies is inderdaad een zootje.

Betreffende generics: Die vraag is gekomen vanuit de community en er is serieus naar gekeken door de PHP devs, met als antwoord dat het heel lastig gaat worden met hoe PHP nu intern werkt.
Geen harde nee, maar of het ooit komt?

Vooral het afdwingen van type-safety lijkt een groot issue te zijn. PHP is tenslotte nooit ontwikkeld als strongly typed language.

[ Voor 12% gewijzigd door hackerhater op 04-09-2020 10:03 ]

[ThomasG]

hackerhater schreef op vrijdag 4 september 2020 @ 10:02:
Betreffende generics: Die vraag is gekomen vanuit de community en er is serieus naar gekeken door de PHP devs, met als antwoord dat het heel lastig gaat worden met hoe PHP nu intern werkt.
Geen harde nee, maar of het ooit komt?

De noodzaak voor generics komt vooral in strong-typed talen. Howel PHP nu deels strong typing kent, is het in de basis nog steeds een weak-typed taal. Als ze dat nu zouden implementeren krijg je waarschijnlijk trade-offs waar ze laten spijt van krijgen. Zoals bij Java met de type erasure.

[hackerhater]

ThomasG schreef op vrijdag 4 september 2020 @ 10:05:
[...]
De noodzaak voor generics komt vooral in strong-typed talen. Howel PHP nu deels strong typing kent, is het in de basis nog steeds een weak-typed taal. Als ze dat nu zouden implementeren krijg je waarschijnlijk trade-offs waar ze laten spijt van krijgen. Zoals bij Java met de type erasure.

Jup en je kan strong typed collecties maken in PHP hoe het nu is als je het wilt.
Kost alleen wat extra moeite.

[.oisyn]

kenneth schreef op vrijdag 4 september 2020 @ 09:51:
Of als je van tevoren niet goed nadenkt over equality of identity (zie JS met ==, === en waarschijnlijk zullen ==== en ===== inmiddels ook wel bestaan) dan moet je dat oplossen met rare hacks en dan is dat niet een nadeel maar gewoon een ontwerpfout. Dat een nadeel noemen verdoezelt een ontwerpprobleem.

Het voorbeeld bij uitstek daarvan vind ik echt de left-associativity van de ?: operator in PHP. Dat kan niet anders geweest zijn dan: "Hrrr drrr I'm going to implement ?: today. *clickety clickety clickety clickety click*. Done!"

Tja, en toen was het fout. En toen gingen mensen er code mee schrijven. En toen kon je het niet meer aanpassen zonder dingen te breken. Gelukkig is het nesten van de ternary operator tegenwoordig deprecated, zodat ze in de toekomst de switch kunnen maken naar right-associative.

De documentatie ook

quote: https://www.php.net/manua...rators.comparison.ternary

PHP's behaviour when using more than one ternary operator within a single statement is non-obvious:

PHP:

<?php
// on first glance, the following appears to output 'true'
echo (true?'true':false?'t':'f');

// however, the actual output of the above is 't'
// this is because ternary expressions are evaluated from left to right

// the following is a more obvious version of the same code as above
echo ((true ? 'true' : false) ? 't' : 'f');

// here, you can see that the first expression is evaluated to 'true', which
// in turn evaluates to (bool)true, thus returning the true branch of the
// second ternary expression.
?>

Non-obvious? How about wrong. En evaluation order heeft niets met associativity te maken

[ Voor 47% gewijzigd door .oisyn op 04-09-2020 10:28 ]

[Vihaio]

azerty schreef op woensdag 2 september 2020 @ 09:53:
Geven jullie ffe een seintje als het terug over php bashen, welk keyboard nu het beste is of iets anders gaat ipv geneuzel over de eerste computer?

Verbazingwekkend hoe effectief dit was Ben je altijd zo goed in van onderwerp veranderen @azerty ?

[Giesber]

Vihaio schreef op vrijdag 4 september 2020 @ 10:40:
[...]

Verbazingwekkend hoe effectief dit was Ben je altijd zo goed in van onderwerp veranderen @azerty ?

Over azerty gesproken, ik gebruik dat nog altijd. Waarschijnlijk wat minder handig bij het programmeren (hoewel dat meevalt als je het gewend bent), maar wel handig als je Frans moet typen (geen rare dingen nodig om een é, è, ç, à en dergelijke te typen).

Het grootste nadeel is misschien nog dat ik niet meteen een goedkopere laptop kan scoren in Nederland, daar hebben ze niet vaak azerty toetsenborden.

[CodeCaster]

Giesber schreef op vrijdag 4 september 2020 @ 10:45:
[...]

Over azerty gesproken, ik gebruik dat nog altijd. Waarschijnlijk wat minder handig bij het programmeren (hoewel dat meevalt als je het gewend bent), maar wel handig als je Frans moet typen (geen rare dingen nodig om een é, è, ç, à en dergelijke te typen).

Het grootste nadeel is misschien nog dat ik niet meteen een goedkopere laptop kan scoren in Nederland, daar hebben ze niet vaak azerty toetsenborden.

Ik tik m'n hele leven al met de VS International-toetsenbordindeling. Ik gebruik graag accenten op mijn letters voor nadruk.

ReSharper vindt dat iets minder leuk, die gaat soms na een dubbel aanhalingsteken gevolgd door een spatie nog twee dubbele aanhalingstekens invoegen. Sowieso weet ik niet of ik mijn ReSharper ga verlengen na dit jaar, er worden steeds meer analysis- en refactor-goodies in Visual Studio ingebakken.

Daarover gesproken: is er iemand naar volle tevredenheid overgestapt naar Code? Ik kan maar niet wennen aan de houtje-touwtjemanier om dingen te laten werken. Tegelijk debuggen van een ASP.NET Core API, een webapplicatie en een Angular/TypeScript-app? Sterkte... Edit&Continue (tijdens het debuggen wijzigen en on-the-fly hercompileren), instruction pointer verslepen? Succes...

Visual Studio met Mads Kristensens WebCompiler-extensie en Attach To Everything

[ Voor 4% gewijzigd door CodeCaster op 04-09-2020 10:54 ]

[thlst]

bauke1994 schreef op vrijdag 4 september 2020 @ 09:40:
Gebruik dan liever ext-ds ik heb er zelf geen ervaring mee maar het schijnt een stuk beter te zijn dan SPL.

Daar heb je gelijk in. Ik noemde SPL's datastructures omdat die al >10jaar in PHP's standard lib zitten.

[RobertMe]

.oisyn schreef op vrijdag 4 september 2020 @ 10:23:
[...]

Non-obvious? How about wrong. En evaluation order heeft niets met associativity te maken

Advocaat van de duivel. Waarom vind je wat PHP doet fout? Het is niet standaard, en bij nesting "non obvious", maar voor mijn gevoel is er geen "fout". Slechts (zeer) onhandig wat de andere talen niet hebben doordat de associvity daar andersom is. Fout is als PHP bij 1+1 met 3 komt aanzetten, of wat dan ook. Dit is gewoon gedocumenteerd gedrag dat, op basis van de werking in andere talen, niet voor de hand ligt, en in gevallen (nesting) een onverwacht resultaat geeft.

[Antrax]

CodeCaster schreef op vrijdag 4 september 2020 @ 10:52:
Daarover gesproken: is er iemand naar volle tevredenheid overgestapt naar Code? Ik kan maar niet wennen aan de houtje-touwtjemanier om dingen te laten werken.

Ja hier. Van PHPStorm en Rider naar Code met de Intelephense plugin maar ook voor C# en .NET Core met hun officiele plugins. Scheelt mij 20 euro per maand

[.oisyn]

CodeCaster schreef op vrijdag 4 september 2020 @ 10:52:
[...]

Ik tik m'n hele leven al met de VS International-toetsenbordindeling. Ik gebruik graag accenten op mijn letters voor nadruk.

Ik óók , maar ík heb daar een eigen toetsenbord-indeling voor die al die dead keys pas toevoegt als je ook ctrl indrukt. Want quote+spatie vind ik dus rete-irritant. Dus [quote e] is gewoon "e, en [ctrl-quote e] is ë.

En dan kan ik ook dingen doen als [ctrl-\ s] voor √, [ctrl-\ i] voor ∞, [ctrl-\ =] voor ≈, etc

[ Voor 10% gewijzigd door .oisyn op 04-09-2020 11:01 ]

[CodeCaster]

Antrax schreef op vrijdag 4 september 2020 @ 10:58:
[...]
Ja hier. Van PHPStorm en Rider naar Code met de Intelephense plugin maar ook voor C# en .NET Core met hun officiele plugins. Scheelt mij 20 euro per maand

Ik vind het voor de dagelijkse workflow nog zwaar tegenvallen. Alleen al voor het toevoegen van een klasse, waarin de boilerplate usings en namespace staan, moet je een plugin installeren.

Ook heb ik zo ongeveer alle instellingen moeten wijzigen om het fijn te laten werken. De indentation van je projectboom bijvoorbeeld, want op hoge resolutie is er amper onderscheid tussen dieperliggende niveaus (standaard uit m'n hoofd 4 pixels), ik word gek van het window management, enzovoorts.

Voor alle ingebouwde functionaliteiten en de algemene gebruiksvriendelijkheid van Visual Studio Professional betaal ik graag 400 euro per jaar, dan krijg ik er ook nog Azure-tegoed bij en allerlei andere licenties voor Microsoft-spul.

[ Voor 18% gewijzigd door CodeCaster op 04-09-2020 11:05 ]

[.oisyn]

RobertMe schreef op vrijdag 4 september 2020 @ 10:58:
[...]

Advocaat van de duivel. Waarom vind je wat PHP doet fout?

Omdat daar de facto afspraken over gemaakt zijn. In CS zijn die afspraken misschien wat minder oud als in de wiskunde, maar als een taal a - b - c zou evalueren als a - (b - c) dan gaat iedereen dus fouten maken. Omdat we nou eenmaal hebben afgesproken dat minus links-associatief is. Als je in een taal 8 - 4 - 2 doet en daar komt 6 uit, dan noem ik dat fout.

De ?: bestond al een tijdje voordat het in PHP werd geïmplementeerd. Het komt uit CPL, een taal uit de jaren '60 en de voorloper van C. Veelgebruikte talen waar het in zat in de tijd van PHP waren C++, Java en javascript.

Álle talen waar de ?: in zit, met PHP als enige uitzondering, maakten de ?: rechts-associatief. Omdat dat intiuitiever werkt: a ? b : c ? d : e. Als [a], dan [b], anders [als [c], dan [d], anders [e]]. Dat links-associatief parsen, dus ((a ? b : c) ? d : e) gaat tegen de intuitie van elke beginner in die dat leest.

Dat PHP dan "kiest" (en let's face it, dat is nooit een bewuste keuze geweest, dat is gewoon wat er toevallig uit de implementatie kwam rollen) om dat links-associatief te doen, terwijl de rest van de wereld het anders doet en het tegen-intuitief is om het zo te doen, dan noem ik dat "fout".

En laten we wel wezen. Als je iets in je documentatie gewoonweg "non-obvious" noemt, waarom maak je het dan in eerste instantie non-obvious? Waarin maak je het niet gewoon "obvious"? Je zou het zo kunnen noemen als er een doordachte keuze achter zit om het toch zo te doen. Maar die is er niet. Er is geen enkel argument te verzinnen waarom die manier beter is dan wat de rest doet. Dat impliceert, voor mij, dat er een foute keuze is gemaakt.

Fout is als PHP bij 1+1 met 3 komt aanzetten, of wat dan ook

Ok, waarom dan? Waarom zou PHP de + niet kunnen definieren als 2 dingen bij elkaar optellen en daar nog 1 bij doen? De + is ook maar gewoon een symbool. Het is misschien niet wat anderen doen, maar het is gewoon een keuze en daarom niet per se fout. Gewoon gedocumenteerd gedrag dat, op basis van de werking in andere talen, niet voor de hand ligt. Toch?

[ Voor 25% gewijzigd door .oisyn op 04-09-2020 11:26 ]

[hackerhater]

Die ?: implementatie van PHP sucks inderdaad flink.
Echter als ik me niet vergis gaat die in PHP 8 op de schop en gaat ie werken zoals verwacht.

[ThomasG]

.oisyn schreef op vrijdag 4 september 2020 @ 11:08:
[...]

Omdat daar de facto afspraken over gemaakt zijn. In CS zijn die afspraken misschien wat minder oud als in de wiskunde, maar als een taal a - b - c zou evalueren als a - (b - c) dan gaat iedereen dus fouten maken. Omdat we nou eenmaal hebben afgesproken dat minus links-associatief is. Als je in een taal 8 - 4 - 2 doet en daar komt 6 uit, dan noem ik dat fout.

De ?: bestond al een tijdje voordat het in PHP werd geïmplementeerd. Het komt uit CPL, een taal uit de jaren '60 en de voorloper van C. Veelgebruikte talen waar het in zat in de tijd van PHP waren C++, Java en javascript.

Álle talen waar de ?: in zit, zonder uitzondering, maakten de ?: rechts-associatief. Omdat dat intiuitiever werkt: a ? b : c ? d : e. Als [a], dan [b], anders [als [c], dan [d], anders [e]]. Dat links-associatief parsen, dus ((a ? b : c) ? d : e) gaat tegen de intuitie van elke beginner in die dat leest.

Dat PHP dan "kiest" (en let's face it, dat is nooit een bewuste keuze geweest, dat is gewoon wat er toevallig uit de implementatie kwam rollen) om dat links-associatief te doen, terwijl de rest van de wereld het anders doet en het tegen-intuitief is om het zo te doen, dan noem ik dat "fout".

En laten we wel wezen. Als je iets in je documentatie gewoonweg "non-obvious" noemt, waarom maak je het dan in eerste instantie non-obvious? Waarin maak je het niet gewoon "obvious"? Je zou het zo kunnen noemen als er een doordachte keuze achter zit om het toch zo te doen. Maar die is er niet. Er is geen enkel argument te verzinnen waarom die manier beter is dan wat de rest doet. Dat impliceert, voor mij, dat er een foute keuze is gemaakt.

Losgezien van of het links-/rechts-associatief is, is het de meeste gevallen voor de leesbaarheid sowieso niet handig om ze te nesten. Wij vermijden ?: zoveel mogelijk, en gebruiken het enkel waarneer het uitschrijven in een if statement de leesbaarheid juist minder wordt.

[.oisyn]

hackerhater schreef op vrijdag 4 september 2020 @ 11:19:
Die ?: implementatie van PHP sucks inderdaad flink.
Echter als ik me niet vergis gaat die in PHP 8 op de schop en gaat ie werken zoals verwacht.

Nee, het nesten ervan wordt deprecated vanaf 7.4 en 8 (bron). Dus alle code met geneste ternaries zonder expliciete haakjes zal resulteren in een error in 8.

In de toekomst zullen ze dan waarschijnlijk wel de switch maken, als iedereen de kans heeft gehad om zijn code te wijzigen door de error.

[Crazy D]

CodeCaster schreef op vrijdag 4 september 2020 @ 11:03:

Voor alle ingebouwde functionaliteiten en de algemene gebruiksvriendelijkheid van Visual Studio Professional betaal ik graag 400 euro per jaar, dan krijg ik er ook nog Azure-tegoed bij en allerlei andere licenties voor Microsoft-spul.

400?
https://visualstudio.microsoft.com/vs/pricing/
1199 dollar
Op zich nog steeds wel interessant hoor.

[azerty]

Vihaio schreef op vrijdag 4 september 2020 @ 10:40:
[...]

Verbazingwekkend hoe effectief dit was Ben je altijd zo goed in van onderwerp veranderen @azerty ?

Lukt niet altijd helaas, maar oefening baart kunst, dus blijven proberen

[gekkie]

.oisyn schreef op vrijdag 4 september 2020 @ 10:59:
[...]


Ik óók , maar ík heb daar een eigen toetsenbord-indeling voor die al die dead keys pas toevoegt als je ook ctrl indrukt. Want quote+spatie vind ik dus rete-irritant. Dus [quote e] is gewoon "e, en [ctrl-quote e] is ë.

En dan kan ik ook dingen doen als [ctrl-\ s] voor √, [ctrl-\ i] voor ∞, [ctrl-\ =] voor ≈, etc

Ah dat gaat hier dan niet met Ctrl maar met de AltGrrrrrrrrrrrrrrr.

[.oisyn]

gekkie schreef op vrijdag 4 september 2020 @ 11:44:
[...]

Ah dat gaat hier dan niet met Ctrl maar met de AltGrrrrrrrrrrrrrrr.

Ja maar dat is dan zonder dead keys, toch? Je hebt gewoon naast shift nog een andere modifier.

[mcDavid]

.oisyn schreef op vrijdag 4 september 2020 @ 11:45:
[...]

Ja maar dat is dan zonder dead keys, toch? Je hebt gewoon naast shift nog een andere modifier.

Ja en nee.
Met een altgr-deadkeys indeling kun je ook (middels altgr) gewoon deadkeys gebruiken. Beetje wat je zou verwachten n.a.v. de naam laat maar zeggen

[gekkie]

.oisyn schreef op vrijdag 4 september 2020 @ 11:45:
[...]
Ja maar dat is dan zonder dead keys, toch? Je hebt gewoon naast shift nog een andere modifier.

Nope, maar ik heb dan weer geen fancy infinity en die dingen
(maar wel weer op windows en linux gelijk)

[ Voor 7% gewijzigd door gekkie op 04-09-2020 11:52 ]

[CodeCaster]

Crazy D schreef op vrijdag 4 september 2020 @ 11:27:
[...]

400?
https://visualstudio.microsoft.com/vs/pricing/
1199 dollar
Op zich nog steeds wel interessant hoor.

Ik ben zzp'er met minder dan een miljoen omzet per jaar (uit m'n hoofd was dat het criterium om gratis Microsoft Partner te worden en nog recht te hebben op een zogeheten Action Pack), dus ik mag dat Action Pack kopen, met daarin 3 VS Pro-licenties, 10 Windows Pro-licenties, 10 Office-licenties, $ 100 Azure-tegoed per maand, enzovoorts (wel enkel voor OTA-doelen, je mag er geen productie/thuisgebruik op draaien). Dat kost ongeveer € 400 per jaar.

[ Voor 30% gewijzigd door CodeCaster op 04-09-2020 12:06 ]

[Crazy D]

CodeCaster schreef op vrijdag 4 september 2020 @ 11:56:
[...]

Ik ben zzp'er met minder dan een miljoen omzet per jaar (uit m'n hoofd was dat het criterium om gratis Microsoft Partner te worden), dus ik mag een Action Pack kopen, met daarin 3 VS Pro-licenties, 10 Windows Pro-licenties, 10 Office-licenties, $ 100 Azure-tegoed per maand, enzovoorts. Dat kost ongeveer € 400 per jaar.

Oh interessant, eens even kijken zou voor mij ook wel handig kunnen zijn.

[CodeCaster]

Crazy D schreef op vrijdag 4 september 2020 @ 12:01:
[...]

Oh interessant, eens even kijken zou voor mij ook wel handig kunnen zijn.

Aan de andere kant mag het ook weer niet:

quote: https://visualstudio.micr...g-Whitepaper-Mar-2020.pdf

Software offered through the Microsoft Partner Network cannot be used for direct revenue-generating activities, such as providing consulting services, customizing a packaged application for a specific customer, or building a custom application for a customer, for a fee. Partners can use Visual Studio subscriptions for indirect revenue-generating activities, such as building a packaged application on the Microsoft platform, which they can then market and sell to customers.

Dus zou ik alsnog een full-blown licentie moeten hebben die inderdaad € 1200 per jaar (800 na verlenging) kost.

[ Voor 6% gewijzigd door CodeCaster op 04-09-2020 12:14 ]

[Giesber]

Ik heb vroeger gebruik gemaakt van het BizSpark programma. Dat was kort door de bocht een MSDN subscriptie voor 3 jaar, waarbij je alle gebruikte licenties mocht houden. Ik zie dat ze nu iets gelijkaardigs hebben voor startups (bedrijven jonger dan 7 jaar): https://startups.microsoft.com/en-us/benefits/ . Dan moet je misschien wel een vennootschap hebben.

Ik had toen wel een telefoongesprek gekregen, maar als je daar genoeg verteld over hoe je klanten wil helpen met de digitale transformatie en als bedrijf wil groeien om een trouwe partner van je klanten (en van Microsoft) te worden - en even vergeet te vermelden dat je eigenlijk een consultant bent - dan komt dat wel in orde. Vandaar was het wel handig dat ik een vennootschap heb: dan spreek je voor je bedrijf, en niet voor je persoon. Helaas zijn mijn expansieplannen niet zo vlot gelopen dan ik toen voorhad .

[Mugwump]

ThomasG schreef op vrijdag 4 september 2020 @ 11:22:
[...]
Losgezien van of het links-/rechts-associatief is, is het de meeste gevallen voor de leesbaarheid sowieso niet handig om ze te nesten. Wij vermijden ?: zoveel mogelijk, en gebruiken het enkel waarneer het uitschrijven in een if statement de leesbaarheid juist minder wordt.

Voor dingen als simpele nullchecks gebruik ik in Java sowieso liever Optional.ofNullable met een orElse.

[BertS]

CodeCaster schreef op vrijdag 4 september 2020 @ 12:13:
[...]

Aan de andere kant mag het ook weer niet:

[...]

Dus zou ik alsnog een full-blown licentie moeten hebben die inderdaad € 1200 per jaar (800 na verlenging) kost.

Of VS Community Edition gebruiken. Zelf vind ik de verschillen geen 1200/jaar waard (iets meer CodeLens + Enterprise-ready ( ), hier gedefinieerd als >1mln omzet of >250pc's)

[Antrax]

BertS schreef op vrijdag 4 september 2020 @ 12:32:
[...]

Of VS Community Edition gebruiken. Zelf vind ik de verschillen geen 1200/jaar waard (iets meer CodeLens + Enterprise-ready ( ), hier gedefinieerd als >1mln omzet of >250pc's)

Precies. Dat redt ik niet met mijn 3 computers

[RayNbow]

hackerhater schreef op vrijdag 4 september 2020 @ 09:27:
Wat ik zelf in PHP nog mis: generics. Ik wil niet een collectie waar toevallig klasse A in zit (maar whatever in kan zitten), ik wil een collectie waar gegarandeerd alleen klasse A in zit.

Als we generics aan PHP gaan toevoegen, wat is de volgende stap? Def-site of use-site variance?

[ThomasG]

RayNbow schreef op vrijdag 4 september 2020 @ 12:41:
[...]

Als we generics aan PHP gaan toevoegen, wat is de volgende stap? Def-site of use-site variance?

C++ templates natuurlijk

[PatrickH89]

RagingPenguin schreef op donderdag 3 september 2020 @ 21:31:
[...]


Dat is wel een hele ruime interpretatie van term 'serverless' . Zeker als je nagaat hoe sterk php in een webserver zit verweven (mod_php anyone?).

Beetje flauw om het verweven te noemen, PHP is namelijk totaal niet afhankelijk van de mod_php integratie. Daarnaast zou ik dat een bijna legacy manier noemen van het draaien van PHP.

Ruime interpretatie zou ik het niet noemen overigens, ik neem aan dat je wel begreep dat ik dat met een knipoog bedoelde. Daarnaast is de PHP request lifecycle wel heel geschikt om 'serverless' te worden gedraaid.

[Mugwump]

PatrickH89 schreef op vrijdag 4 september 2020 @ 12:50:
[...]


Beetje flauw om het verweven te noemen, PHP is namelijk totaal niet afhankelijk van de mod_php integratie. Daarnaast zou ik dat een bijna legacy manier noemen van het draaien van PHP.

Ruime interpretatie zou ik het niet noemen overigens, ik neem aan dat je wel begreep dat ik dat met een knipoog bedoelde. Daarnaast is de PHP request lifecycle wel heel geschikt om 'serverless' te worden gedraaid.

Dat is ook wel wat onzinnig, want feitelijk kun je in vrijwel elke taal via een (CLI) aanroep als single process draaien. Of dat nou een precompiled binary is of een geïnterpreteerd scriptje.
Ik snap dat vanuit het 'webapplicatiedenken' het idee van een single process per web request klinkt als een goede fit, maar dat slaat verder niet echt ergens op.

[Koenvh]

gekkie schreef op donderdag 3 september 2020 @ 19:30:
[...]

Is Koenvh het pseudoniem van Herman Finkers alhier ?, meester van het bloemrijk taalgebruik .

Helaas niet, maar we delen wel dezelfde soort humor

[CodeCaster]

BertS schreef op vrijdag 4 september 2020 @ 12:32:
[...]

Of VS Community Edition gebruiken. Zelf vind ik de verschillen geen 1200/jaar waard (iets meer CodeLens + Enterprise-ready ( ), hier gedefinieerd als >1mln omzet of >250pc's)

Dat gebruik in inderdaad ook, al sinds 2010. Destijds moest je van Visual Studio Express 2010 nog verschillende edities installeren voor Web, WinForms/WPF, C++ en VB.NET.

Sinds 2012 alweer ondersteunt Express ook extensions, zoals ReSharper, en sinds uit m'n hoofd 2017 doet Community nog maar weinig onder voor Professional.

En het klopt, de limiet om Express/Community commercieel te mogen gebruiken, is een omzet van 1 miljoen, 250 pc's of 5 gebruikers van Visual Studio. Minder restrictief dan Professional via het Action Pack.

Koenvh schreef op donderdag 3 september 2020 @ 19:25:
[...]

Ik had een grap over Martijn Bloem, maar in 't Engels is 'ie flower

[ Voor 16% gewijzigd door CodeCaster op 04-09-2020 16:20 ]

[armageddon_2k1]

Javascript is niet mijn vriend.

JavaScript:

console.log([-3, -2, -1, 0, 1, 2, 10].sort())
// [-1, -2, -3, 0, 1, 10, 2]

Okee....duurde even voor ik daar achter was. Why though?

Even MDN erbij pakken:

The sort() method sorts the elements of an array in place and returns the sorted array. The default sort order is ascending, built upon converting the elements into strings, then comparing their sequences of UTF-16 code units values.

Okee, het is gedocumenteerd, maar hier was ik niet echt vanuit gegaan. Maar, Typescript autocomplete in VSCode geeft wel dit aan:

(method) Array<number>.sort(compareFn?: (a: number, b: number) => number): number[]

Dan is het niet heel gek gedacht dat ik denk dat ie gewoon sorteert op nummer Zet er dan met koeieletters bij: "Warning: converts to string first!"

Het is allemaal gedocumenteerd, maar wel compleet contra-intuitief.

Aan de andere kant, bij dynamically typed talen is het ook lastig denk ik. Maar Python:

Python:

sorted([-3, -2, -1, 0, 1, 2, 3])
# [-3, -2, -1, 0, 1, 2, 3]

doet het wel goed.

[ Voor 13% gewijzigd door armageddon_2k1 op 05-09-2020 08:20 ]

[gekkie]

Mjah PHP en javascript delen de liefde voor dat hele auto-casting/converting gedoe,
niet bepaald het principe van "least surprises" en "explicit". Maar ik moet toegeven dat zelfs met dat in het achterhoofd dat deze me als nog verbaasde.

[Postman]

armageddon_2k1 schreef op zaterdag 5 september 2020 @ 08:00:
Javascript is niet mijn vriend.

JavaScript:

console.log([-3, -2, -1, 0, 1, 2, 10].sort())
// [-1, -2, -3, 0, 1, 10, 2]

Okee....duurde even voor ik daar achter was. Why though?

Even MDN erbij pakken:

[...]


Okee, het is gedocumenteerd, maar hier was ik niet echt vanuit gegaan. Maar, Typescript autocomplete in VSCode geeft wel dit aan:

[...]


Dan is het niet heel gek gedacht dat ik denk dat ie gewoon sorteert op nummer Zet er dan met koeieletters bij: "Warning: converts to string first!"

Het is allemaal gedocumenteerd, maar wel compleet contra-intuitief.

Aan de andere kant, bij dynamically typed talen is het ook lastig denk ik. Maar Python:

Python:

sorted([-3, -2, -1, 0, 1, 2, 3])
# [-3, -2, -1, 0, 1, 2, 3]

doet het wel goed.

Eeuhm de TypeScript autocomplete in VS Code is wel degelijk correct. Zie ook https://www.w3schools.com/JSREF/jsref_sort.asp
In het kort: ja sort maakt er altijd String van, en daarom dus die extra compare functie zodat je toch correct nummers kunt sorteren.

Niet de eerste keer dat ik rare resultaten heb met nummers in JavaScript helaas, blijft het nadeel van dat een variabele alles maar kan zijn en ook tussendoor kan veranderen.

[armageddon_2k1]

Maar maak de sort functie die je mee moet geven dan niet optioneel. Waarom is sorteren op string basis een logische default?

[WK100]

Eens. Zit nu wel dusdanig ingebakken in het ecosysteem, dat je het er in het teken van backwards compatibility niet meer uitkrijgt.

[Ed Vertijsment]

WK100 schreef op zaterdag 5 september 2020 @ 14:35:
Eens. Zit nu wel dusdanig ingebakken in het ecosysteem, dat je het er in het teken van backwards compatibility niet meer uitkrijgt.

Met typed arrays als je alleen ints gebruikt: https://developer.mozilla...l_Objects/TypedArray/sort

[bwerg]

armageddon_2k1 schreef op zaterdag 5 september 2020 @ 08:00:
Aan de andere kant, bij dynamically typed talen is het ook lastig denk ik. Maar Python:

Python:

sorted([-3, -2, -1, 0, 1, 2, 3])
# [-3, -2, -1, 0, 1, 2, 3]

doet het wel goed.

Heeft toch weinig met dynamisch getypeerd te maken? D'r zit hoe dan ook een typeringssysteem achter dat het type van de elementen moet bepalen, al was het maar om de cast goed uit te voeren. Dus overloading op orderning is dan niet bepaald heftig, zoals python ook laat zien.

Nee, dit heeft niets met moeilijk te maken en alles met rare keuzes en legacy-rommel.

[armageddon_2k1]

Ik was een hele reply aan het typen maar toen kwam ik erachter dat ik ging bevestigen wat jij zei. Het heeft idd niet direct veel met dynamically typed te maken. Python lost het in dit geval een stuk netter op iig.

[Ghehe]

Ik vind Python anders helemaal niet zo logisch:

code:

$ python -c 'print sorted(["-5000", -3, -999, -1, 0, "1000", 4, 1, "  spatie  ", "Ghehe"])'
[-999, -3, -1, 0, 1, 4, '  spatie  ', '-5000', '1000', 'Ghehe']

Mijn verwachting was dat alle integers naar string gecast werden en dan alle elementen op basis van hun ascii waardes gesorteerd werden. Nu heb je deels op numerieke waardes en deels op ascii waardes.

Nou ja het is maar wat je gewoon bent en je leert de quirks van een taal toch vrij snel. (Wel altijd eerst een paar keer vloeken als van taal switcht )

[RayNbow]

Ghehe schreef op dinsdag 8 september 2020 @ 23:53:
Ik vind Python anders helemaal niet zo logisch:

code:

$ python -c 'print sorted(["-5000", -3, -999, -1, 0, "1000", 4, 1, "  spatie  ", "Ghehe"])'
[-999, -3, -1, 0, 1, 4, '  spatie  ', '-5000', '1000', 'Ghehe']

In Python 3 is dat ten eerste een syntaxfout (print is tegenwoordig een functie, geen statement) en ten tweede een type error:

C:\>py -3 -c "print( sorted(['-5000', -3, -999, -1, 0, '1000', 4, 1, '  spatie  ', 'Ghehe']) )"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: '<' not supported between instances of 'int' and 'str'

Mijn verwachting was dat alle integers naar string gecast werden en dan alle elementen op basis van hun ascii waardes gesorteerd werden.

Waarom? Op basis van wat moet die beslissing gemaakt worden? Hoe weet je dat je alles naar een string moet casten?

Hier is een eigen (trage) geschreven sorteerfunctie met hetzelfde gedrag in Python 2.x:

Python:

from __future__ import print_function

def mysorted(x_xs):
    if x_xs:
        x = x_xs[0]
        xs = x_xs[1:]
        return mysorted([y for y in xs if y < x]) + [x] + mysorted([y for y in xs if y >= x])
    else:
        return []

print( mysorted(['-5000', -3, -999, -1, 0, '1000', 4, 1, '  spatie  ', 'Ghehe']) )
# [-999, -3, -1, 0, 1, 4, '  spatie  ', '-5000', '1000', 'Ghehe']

[ Voor 41% gewijzigd door RayNbow op 09-09-2020 06:45 ]

[Hydra]

Ghehe schreef op dinsdag 8 september 2020 @ 23:53:
Mijn verwachting was dat alle integers naar string gecast werden en dan alle elementen op basis van hun ascii waardes gesorteerd werden. Nu heb je deels op numerieke waardes en deels op ascii waardes.

Beetje garbage in garbage out verhaal dit, ik vind het niet echt een zinnig voorbeeld en het is m.i. geen voorbeeld van een 'quirk'. Je geeft een runtime een verzameling elementen van compleet verschillende types, dan is het nogal logisch dat het geen zinnige output geeft.

[gekkie]

Ghehe schreef op dinsdag 8 september 2020 @ 23:53:
Ik vind Python anders helemaal niet zo logisch:

code:

$ python -c 'print sorted(["-5000", -3, -999, -1, 0, "1000", 4, 1, "  spatie  ", "Ghehe"])'
[-999, -3, -1, 0, 1, 4, '  spatie  ', '-5000', '1000', 'Ghehe']

Mijn verwachting was dat alle integers naar string gecast werden en dan alle elementen op basis van hun ascii waardes gesorteerd werden. Nu heb je deels op numerieke waardes en deels op ascii waardes.

Nou ja het is maar wat je gewoon bent en je leert de quirks van een taal toch vrij snel. (Wel altijd eerst een paar keer vloeken als van taal switcht )

Waarom zou je in de evidente en simpele gevallen de handel gaan casten en daarmee potentieel onverwachte resultaten gaan retourneren, om in de gevallen die volstrekt ambigu zijn, wellicht iets te kunnen retourneren wat wellicht iets meer richting de verwachting gaat, maar waarschijnlijk nog steeds (subtiel) niet aan die verwachting voldoet ?

[Ghehe]

RayNbow schreef op woensdag 9 september 2020 @ 06:14:
Waarom? Op basis van wat moet die beslissing gemaakt worden? Hoe weet je dat je alles naar een string moet casten?

Goh ja, het is maar wat ik verwachtte dus hoogst subjectief. Volgens mij komt die verwachting van mijn ouderwetse Perl achtergrond en is dat onbewust hoe ik verwacht dat dynamische getypeerde talen zo'n mixed type array gaan sorteren.

Hydra schreef op woensdag 9 september 2020 @ 08:38:
Beetje garbage in garbage out verhaal dit, ik vind het niet echt een zinnig voorbeeld

Is een array hebben van integers gemixt met integers in stringvorm dan zo onzinnig?

code:

$ python -c "print sorted([-999, -3, -1, 0, 1, 4, '-5000', '200', '1000'])"
[-999, -3, -1, 0, 1, 4, '-5000', '1000', '200']

Als je zelf geen controle hebt over de data die je krijgt (bvb JSON met een niet-geforceerd schema) en je let even niet op dan komt een lage waarde (in stringvorm) toch achteraan in de array uit. Ik vond dat opmerkelijk maar het blijkt dat ik de enigste ben.

gekkie schreef op woensdag 9 september 2020 @ 10:16:
Waarom zou je in de evidente en simpele gevallen de handel gaan casten en daarmee potentieel onverwachte resultaten gaan retourneren, om in de gevallen die volstrekt ambigu zijn, wellicht iets te kunnen retourneren wat wellicht iets meer richting de verwachting gaat, maar waarschijnlijk nog steeds (subtiel) niet aan die verwachting voldoet ?

Om eerlijk te zijn, heb ik nog nooit echt diep nagedacht wat ik zou returnen indien ik een mixed type array zou moeten sorteren. Error geven (zoals Python 3), Zonder casts eerst de integers volgens integerwaarde sorteren, dan alle strings volgens ascii sorteren (zoals Python 2), alles casten naar string en volgens ascii sorteren (Perl/Javascript), en andere talen doen misschien nog wat anders.

[ThomasG]

Ghehe schreef op woensdag 9 september 2020 @ 14:07:
[...]


Goh ja, het is maar wat ik verwachtte dus hoogst subjectief. Volgens mij komt die verwachting van mijn ouderwetse Perl achtergrond en is dat onbewust hoe ik verwacht dat dynamische getypeerde talen zo'n mixed type array gaan sorteren.


[...]


Is een array hebben van integers gemixt met integers in stringvorm dan zo onzinnig?

code:

$ python -c "print sorted([-999, -3, -1, 0, 1, 4, '-5000', '200', '1000'])"
[-999, -3, -1, 0, 1, 4, '-5000', '1000', '200']

Als je zelf geen controle hebt over de data die je krijgt (bvb JSON met een niet-geforceerd schema) en je let even niet op dan komt een lage waarde (in stringvorm) toch achteraan in de array uit. Ik vond dat opmerkelijk maar het blijkt dat ik de enigste ben.


[...]


Om eerlijk te zijn, heb ik nog nooit echt diep nagedacht wat ik zou returnen indien ik een mixed type array zou moeten sorteren. Error geven (zoals Python 3), Zonder casts eerst de integers volgens integerwaarde sorteren, dan alle strings volgens ascii sorteren (zoals Python 2), alles casten naar string en volgens ascii sorteren (Perl/Javascript), en andere talen doen misschien nog wat anders.

Python2 cast niet. De sorted implementatie gebruikt de < operator, waarbij Python2 het toestaat om bijv: "a" < 2 te doen; waarbij een string altijd groter is dan een getal (ongeacht wat je erin zet). In Python3 krijg je een type error als je dat probeert.

[Hydra]

Ghehe schreef op woensdag 9 september 2020 @ 14:07:
Is een array hebben van integers gemixt met integers in stringvorm dan zo onzinnig?

code:

$ python -c "print sorted([-999, -3, -1, 0, 1, 4, '-5000', '200', '1000'])"
[-999, -3, -1, 0, 1, 4, '-5000', '1000', '200']

Als je zelf geen controle hebt over de data die je krijgt (bvb JSON met een niet-geforceerd schema) en je let even niet op dan komt een lage waarde (in stringvorm) toch achteraan in de array uit. Ik vond dat opmerkelijk maar het blijkt dat ik de enigste ben.

Als je dat op die manier binnenkrijgt dan is je probleem echt niet Python.

[PrisonerOfPain]

Hydra schreef op woensdag 9 september 2020 @ 16:40:
[...]


Als je dat op die manier binnenkrijgt dan is je probleem echt niet Python.

Zoals altijd is het probleem, de programmeur aan de andere kant van de API

[gekkie]

Ghehe schreef op woensdag 9 september 2020 @ 14:07:
Om eerlijk te zijn, heb ik nog nooit echt diep nagedacht wat ik zou returnen indien ik een mixed type array zou moeten sorteren. Error geven (zoals Python 3), Zonder casts eerst de integers volgens integerwaarde sorteren, dan alle strings volgens ascii sorteren (zoals Python 2), alles casten naar string en volgens ascii sorteren (Perl/Javascript), en andere talen doen misschien nog wat anders.

Daarom vind ik het vooral belangrijk dat de non-mixed types gewoon logisch zijn.
En niet zoals javascript, we casten alles maar naar een string en laten er vervolgens wel regels voor string comparison op los. En is die string comparison eventueel nog op locale gebaseerd ?

De mixed gevallen, tsja wat maakt de keuze uit, error is wel het makkelijkste, zowel om te programmeren als om te documenteren (met alle mogelijke edge cases).

[Woy]

PrisonerOfPain schreef op woensdag 9 september 2020 @ 17:58:
[...]


Zoals altijd is het probleem, de programmeur aan de andere kant van de API

Yup, en dat is wederzijds

[SPee]

Hoe zit dat dan wanneer je beide zelf bent?
bv bij microservices

[Immutable]

@armageddon_2k1
Of met Rust in webassembly:

C:

 
use wasm_bindgen::prelude::*;
use web_sys::{console};

#[wasm_bindgen(start)]
pub fn run() -> Result<(), JsValue> {

    let mut vec = vec![-3, -2, -1, 0, 1, 2, 10];
    vec.sort();
  
    console::log_1(&format!("{:?}",vec).into());

    Ok(())
}
 

En je kan nog JsValue terug geven, via Serde in Json format enz enz. iig van die rare javascript fratsen af

[ Voor 5% gewijzigd door Immutable op 09-09-2020 21:39 ]

[Voutloos]

SPee schreef op woensdag 9 september 2020 @ 20:49:
Hoe zit dat dan wanneer je beide zelf bent?
bv bij microservices

Masochisme komt ook bij developers voor ja.

[Hydra]

PrisonerOfPain schreef op woensdag 9 september 2020 @ 17:58:
Zoals altijd is het probleem, de programmeur aan de andere kant van de API

Het designen van dat soort dingen kun je natuurlijk het beste door een stagair laten doen

[Woy]

Hydra schreef op donderdag 10 september 2020 @ 09:19:
[...]


Het designen van dat soort dingen kun je natuurlijk het beste door een stagair laten doen

Hoezo design? Dat evolueert toch gewoon "agile"......

[Crazy D]

Woy schreef op donderdag 10 september 2020 @ 09:21:
[...]

Hoezo design? Dat evolueert toch gewoon "agile"......

Zolang het maar voldoet aan de MVP... en doorrrrrrr....

[Koenvh]

Woy schreef op donderdag 10 september 2020 @ 09:21:
[...]

Hoezo design? Dat evolueert toch gewoon "agile"......

Maar wel in verschillende teams zonder communicatie ertussen, en dan nog een ander team die het geheel aan elkaar mag knopen

[PrisonerOfPain]

Koenvh schreef op donderdag 10 september 2020 @ 15:07:
[...]

Maar wel in verschillende teams zonder communicatie ertussen, en dan nog een ander team die het geheel aan elkaar mag knopen

Een van mijn belangrijkste skills over de jaren is dus die guy aan de andere kant van de API vinden; ook al werkt 'ie in een ander team of bij een ander bedrijf

[Giesber]

PrisonerOfPain schreef op donderdag 10 september 2020 @ 16:56:
[...]


Een van mijn belangrijkste skills over de jaren is dus die guy aan de andere kant van de API vinden; ook al werkt 'ie in een ander team of bij een ander bedrijf

Dan gok ik dat de volgende skill kickboxen gaat zijn?

[Matis]

Giesber schreef op vrijdag 11 september 2020 @ 00:18:
Dan gok ik dat de volgende skill kickboxen gaat zijn?

Of kantklossen

[gekkie]

Matis schreef op vrijdag 11 september 2020 @ 04:53:
[...]
Of kantklossen

Kijk, goed voor het toverwoord der diversiteit, kan 90+ ook weer aan de slag met een hippe en flitsende carriere als "kantklos-coach" en als je echt een kwieke-oma hebt, "agile kantklossen voor gevorderden".

[.oisyn]

Pet peeve: ik vind quicksort echt zo'n stomme naam. Alle andere sort-routines zijn genoemd naar wat ze doen. Quicksort is niet eens per se 'snel', het heeft een worst-case complexiteit van O(n²). Had het pivotsort genoemd oid.

[Voutloos]

Marketingnaam.

Zelfde pet peeve bij security issues inmiddels. Heartbleed was nog schattig, maar alles wat er na bedacht is gaat ook nergens meer over. Alleen maar marketing voor de e-penis van de security researcher.

(Edit: Excuus!! Ik bedoel e-geslachtsdeel of wat je ook maar graag hebt in deze neutrale tijden)

[ Voor 18% gewijzigd door Voutloos op 11-09-2020 14:21 ]

[bauke1994]

nieuws: Vraagtekens rond 'onthulling' kwetsbaarheden in AMD Ryzen- en Epyc-pl...

Twee jaar geleden konden deze onderzoekers er inderdaad ook iets van.

[SPee]

Koenvh schreef op donderdag 10 september 2020 @ 15:07:
[...]

Maar wel in verschillende teams zonder communicatie ertussen, en dan nog een ander team die het geheel aan elkaar mag knopen

Dat andere team was er alleen tijdens de initiële ontwikkeling. Nu het product in productie draait, is dat bij een andere partij ondergebracht die daar "specialist" in is.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Hipska]

Nog mensen hier last van in deze thread? Ad wil bestand downloaden

[ Voor 24% gewijzigd door Hipska op 22-09-2020 14:33 ]

[Hydra]

Welke ads?

[Mercatres]

Koenvh schreef op donderdag 10 september 2020 @ 15:07:
[...]

Maar wel in verschillende teams zonder communicatie ertussen, en dan nog een ander team die het geheel aan elkaar mag knopen

Daar heb je toch DevOps voor?

[gekkie]

Je laat googletagservices nog door?
Wat mij betreft stoppen ze die rx_lidar maar lekker ergens waar de zon niet schijnt (en de DPG dus ook).

Iets meer scrollen de volgende keer, maar het waren dus de vrienden van atdtm.com, aka Atlas Solutions, aka Meneer Zuckberg, die zin had om eens lekker op safari te gaan met je.

[ Voor 40% gewijzigd door gekkie op 22-09-2020 16:26 ]

[Hydra]

gekkie schreef op dinsdag 22 september 2020 @ 15:59:
Iets meer scrollen de volgende keer, maar het waren dus de vrienden van atdtm.com, aka Atlas Solutions, aka Meneer Zuckberg, die zin had om eens lekker op safari te gaan met je.

Dat ads javascript shit uitvoeren is voor mij de reden om die shit allemaal te blokkeren. Ik ben an sich best bereid om ads aan te zetten voor een site als dit, maar alleen als het ook gewoon plaatjes zijn. Maarja, daar is geen geld mee te verdienen, ads zijn geen ads, het zijn gedragstrackers. En dat gaat me veel te ver.

[gekkie]

Ze lijken er bij tweakers nu wel mee te experimenteren. In mijn optiek als nog spuuglelijk die coolblue meuk (zeker omdat ze er dan gelijk 2 tegelijk plaatsen boven en rechts). Maar goed het is een afbeelding en geen advertentie-netwerk tracker. Nou is onderhand het probleem weer dat DPG inmiddels ook zelf zo groot en omvattend is geworden.

[ThomasG]

Hydra schreef op dinsdag 22 september 2020 @ 16:47:
[...]


Dat ads javascript shit uitvoeren is voor mij de reden om die shit allemaal te blokkeren. Ik ben an sich best bereid om ads aan te zetten voor een site als dit, maar alleen als het ook gewoon plaatjes zijn. Maarja, daar is geen geld mee te verdienen, ads zijn geen ads, het zijn gedragstrackers. En dat gaat me veel te ver.

Dit is deels een gevolg van de cookies. Voorheen hadden ze cookies als tracker. Met javascript kun je een zeer accurate fingerprint maken waardoor ze je nog steeds kunnen tracken. Al proberen sommige browsers dat wel tegen te gaan, door bepaalde APIs nep data terug te geven bij third-party websites.

[bwerg]

.oisyn schreef op vrijdag 11 september 2020 @ 13:20:
Pet peeve: ik vind quicksort echt zo'n stomme naam. Alle andere sort-routines zijn genoemd naar wat ze doen. Quicksort is niet eens per se 'snel', het heeft een worst-case complexiteit van O(n²). Had het pivotsort genoemd oid.

De simpele verklaring is natuurlijk dat het het eerste algoritme met een gemiddelde performance van O(n log n) was.

Niet alle andere (serieus te nemen) sort-routines zijn trouwens vernoemd naar wat ze doen. Timsort en Shellsort zijn gemaakt door Tim en meneer Shell...

[.oisyn]

bwerg schreef op woensdag 23 september 2020 @ 09:31:
[...]

De simpele verklaring is natuurlijk dat het het eerste algoritme met een gemiddelde performance van O(n log n) was.

Niet waar, merge sort was 15 jaar eerder (en gegarandeerd n log n)

[ Voor 4% gewijzigd door .oisyn op 23-09-2020 09:39 ]

[bwerg]

.oisyn schreef op woensdag 23 september 2020 @ 09:38:
[...]

Niet waar, merge sort was 15 jaar eerder (en gegarandeerd n log n)

Correctie, Tony Hoare dacht dat het het eerste snelle algoritme was.

[ThomasG]

bwerg schreef op woensdag 23 september 2020 @ 09:47:
[...]

Correctie, Tony Hoare dacht dat het het eerste snelle algoritme was.

Dan valt het nog mee dat we een quickersort, quickestsort en notsoquickbutstillprettfastsort hebben.

[Creepy]

randomsort ftw!

[Janoz]

Creepy schreef op woensdag 23 september 2020 @ 10:43:
randomsort ftw!

Met een best case van O(N). Bij ons noemde we die BakkerSort, Vernoemd naar de docent Harm Bakker

[Woy]

Creepy schreef op woensdag 23 september 2020 @ 10:43:
randomsort ftw!

Je bedoelt Bogosort

[Douweegbertje]

Zo, even helemaal klaar met mensen die maar wat zitten te yolo'n zonder kennis. In een paar weken tijd nu zoveel ranzige meuk tegengekomen dat je gewoon schrikt van.. wat de fuck gebeurd hier. Gewoon alsof de tijd 10 jaar stil heeft gestaan en er wekelijks prijzen waren voor meest obscure en kwestbare oplossing.

Ik sta heel erg open om 'te enablen', kennis over te dragen, motiveren etc. maar ik heb nu wel behoefte aan vakantie (1 oktober gelukkig )