De Devschuur Coffee Corner - Iteratie 7

[xehbit]

Ennnnnnn begonnen op de DutchOpenHackathon

[Ealanrian]

Jij ook al? Ook al een idee om uit te werken?

[Skyaero]

alwinuzz schreef op vrijdag 19 september 2014 @ 19:45:
Wat zijn dit voor wachtwoord-eisen?


[...]

Anno 2014. Bij de KvK....

Het is bij sommige websites nog wel bedroevender gesteld. Ik ben bezig al mijn wachtwoorden te wijzigen en in KeePass te zetten.

Zo mag je bij PWN (waterbedrijf noord-holland) maximaal 8 karakters hebben. Na het wijzigen is er een bevestigingspagina waar het wachtwoord in plain-tekst op staat . En natuurlijk geen SSL certificaat voor dit alles .

[xehbit]

Ealanrian schreef op zaterdag 20 september 2014 @ 12:28:
Jij ook al? Ook al een idee om uit te werken?

Yess, we hebben inderdaad ook al een idee, nog beetje brainstormen over de functionaliteiten.

en bij jou dan ?

[Ealanrian]

Dragon707 schreef op zaterdag 20 september 2014 @ 12:37:
[...]

Yess, we hebben inderdaad ook al een idee, nog beetje brainstormen over de functionaliteiten.

en bij jou dan ?

Wij gaan beginnen met bouwen. Ik zit in de vleugel boven de ingang naast de koffie tafel in het hokje

[xehbit]

Ealanrian schreef op zaterdag 20 september 2014 @ 12:43:
[...]

Wij gaan beginnen met bouwen. Ik zit in de vleugel boven de ingang naast de koffie tafel in het hokje

Wij zitten in de zelfde vleugel, helemaal in de hoek

[Douweegbertje]

Roep gewoon even elkaars nickname, hoor je je nick; zwaai even en loop naar elkaar toe.

[Ryur]

Douweegbertje schreef op zaterdag 20 september 2014 @ 13:22:
Roep gewoon even elkaars nickname, hoor je je nick; zwaai even en loop naar elkaar toe.

Zeg, we zijn Nerds.
Onbekende mensen ontmoeten is eng

[StM]

Wat is Python toch een derde rangs fluttaal. Er wordt vaak gescheld op PHP, maar ik stoot mijn harses heel wat vaker bij Python. Zoveel constructs die iedere fatsoenlijke taal wel heeft die hun weigeren te ondersteunen en de meest onlogische benamingen en constructies.

[Gamebuster]

Nu 3 Pi's in bezit. Nog 5 te gaan.

[Firesphere]

Hey, Windows is z'n update-geschiedenis kwijt

[Devilly]

Gamebuster schreef op zaterdag 20 september 2014 @ 14:35:
Nu 3 Pi's in bezit. Nog 5 te gaan.

Wat ben je ermee van plan?

[Firesphere]

Devilly schreef op zaterdag 20 september 2014 @ 14:47:
[...]


Wat ben je ermee van plan?

8 Pi's hebben.

[Gamebuster]

Devilly schreef op zaterdag 20 september 2014 @ 14:47:
[...]


Wat ben je ermee van plan?

Mini clustertje maken om te spelen met load balancing e.d.

[Soultaker]

Dragon707 schreef op zaterdag 20 september 2014 @ 12:06:
Ennnnnnn begonnen op de DutchOpenHackathon

Succes!

[F.West98]

Dragon707 schreef op zaterdag 20 september 2014 @ 12:06:
Ennnnnnn begonnen op de DutchOpenHackathon

Ik doe vandaag mee vanuit thuis

Overigens:
http://tobiasahlin.com/spinkit/

Zitten een paar hele mooie tussen

[deadinspace]

StM schreef op zaterdag 20 september 2014 @ 14:16:
Wat is Python toch een derde rangs fluttaal. Er wordt vaak gescheld op PHP, maar ik stoot mijn harses heel wat vaker bij Python. Zoveel constructs die iedere fatsoenlijke taal wel heeft die hun weigeren te ondersteunen en de meest onlogische benamingen en constructies.

Zoals?

[Firesphere]

StM schreef op zaterdag 20 september 2014 @ 14:16:
Wat is Python toch een derde rangs fluttaal. Er wordt vaak gescheld op PHP, maar ik stoot mijn harses heel wat vaker bij Python. Zoveel constructs die iedere fatsoenlijke taal wel heeft die hun weigeren te ondersteunen en de meest onlogische benamingen en constructies.

Heb je wat meer onderbouwing? Ik vind Python juist wel fijn.

[Gamebuster]

https://developer.mozilla...jects/Array/find#Polyfill

Waarom wordt hier var length = list.length >>> 0; gedaan?

[F.West98]

Fuck logic

JavaScript:

var list: Array<Foo> = [];
_.each(data.list, (index, value, list) => {
    list.push(new Foo(value));
}); // de array is vol met lege Foo's
$.each(data.list, (index, value) => {
    list.push(new Foo(value));
}); // de array klopt gewoon

Fijn...

[Gamebuster]

Is dat typescript?

[ Voor 60% gewijzigd door Gamebuster op 20-09-2014 17:15 ]

[F.West98]

Ja
GoT heeft geen TS kleurtjes

[ Voor 24% gewijzigd door F.West98 op 20-09-2014 17:15 ]

[Gamebuster]

Maar ik begrijp dus dat jij typescript gebruikt. Hip. Hoe bevalt het? Toevallig recent nog uitvoerig bekeken en even geprobeerd.

[F.West98]

Het bevalt best goed
Het bevalt me best goed. Ik had gedacht dat de definition files nogal een probleem zouden zijn, maar er zijn echt honderden bestanden voor bijna elke library die ik ooit heb gebruikt. Wat me vooral bevalt is de manier van classes definiëren, en de mogelijkheid om variabelen typed te maken. Samen met Reactive Extensions en Underscore is het zeer krachtig

edit:
Alleen zorgt dat strictly typed ook wel voor problemen

[ Voor 14% gewijzigd door F.West98 op 20-09-2014 17:23 ]

[StM]

do while
in/decrements
block comments
multi level breaks / continue
switch

Is waar ik zo al even op kom en ik had ooit nog wel een langer lijstje verzameld...

En qua benaming bv iets waar ik weer net tegen aan gelopen ben: socket.makefile() als je een buffered line reader wilt hebben.

[RayNbow]

StM schreef op zaterdag 20 september 2014 @ 17:18:
do while

Het is echt lang geleden dat ik dat nodig heb gehad. Heb je een voorbeeldje?

in/decrements

+= en -=?

block comments

Voor welk doel heb je dit nodig? Als je snel wat code uit wil commentarieren dan kan een goede editor dat voor je doen.

multi level breaks / continue

Hmm?

switch

Meerdere oplossingen voor.

[StM]

Geweldige oplossingen zeg. De ene is nog smeriger als de andere. Tuurlijk kan je er omheen werken. Het levert alleen meer en vooral smerige code op.

En waarom ik do while wil? Bv om een buffer uit te lezen tot ik een bepaald token tegen kom. Maar goed, een while True + if werkt ook.

[Gamebuster]

Context 3 bovenliggende posts: Rant op python. Duurde even, maar heb eindelijk door dat het over Python gaat.

[ Voor 51% gewijzigd door Gamebuster op 20-09-2014 18:22 ]

[RayNbow]

StM schreef op zaterdag 20 september 2014 @ 17:57:
Geweldige oplossingen zeg. De ene is nog smeriger als de andere. Tuurlijk kan je er omheen werken. Het levert alleen meer en vooral smerige code op.

In welk opzicht levert het meer code op?

En waarom ik do while wil? Bv om een buffer uit te lezen tot ik een bepaald token tegen kom. Maar goed, een while True + if werkt ook.

Klinkt als takewhile?

[Firesphere]

Pro-tip: Typen nadat je even een beetje los bent gegaan op de gitaar.... is best pijnlijk

[Ealanrian]

Firesphere schreef op zaterdag 20 september 2014 @ 18:34:
Pro-tip: Typen nadat je even een beetje los bent gegaan op de gitaar.... is best pijnlijk

Misschien moet je je vingers niet openhalen aan de snaren...

[Firesphere]

Ealanrian schreef op zaterdag 20 september 2014 @ 18:43:
[...]

Misschien moet je je vingers niet openhalen aan de snaren...

Ik ben gestopt voordat het begon te bloeden

Maar het scheelde weinig of m'n vingers lagen open ja

[StM]

RayNbow schreef op zaterdag 20 september 2014 @ 18:33:
[...]

In welk opzicht levert het meer code op?

Je gaat proberen om via allerlei utility code een language construct na te bootsen. Bv zo: http://code.activestate.com/recipes/410692/ En je gaat toch niet menen dat je iets als dit een nette oplossing vind om een switch na te bootsen? En wil je default values dan moet je maar de exception afhandelen.

Python:

result = {
  'a': lambda x: x * 5,
  'b': lambda x: x + 7,
  'c': lambda x: x - 2
}[value](x)

RayNbow schreef op zaterdag 20 september 2014 @ 18:33:
[...]
Klinkt als takewhile?

Zou kunnen met een generator ja. Ik krijg er alleen direct rillingen van. Terwijl iets als dit imo veel natuurlijker is:

Python:

do:
    l = sr.readline()
while not l.startswith("Token")

Wat mij betreft is het verzinnen van dat soort hacks niet anders dan het recht praten van alles wat krom in PHP is.

[Wolfboy]

StM schreef op zaterdag 20 september 2014 @ 17:18:
do while
in/decrements

Deze heb ik zelden nodig, mijn ervaring is dat je bij pythonic oplossingen deze niet nodig hebt.

Increment/decrement klinkt alsof je een counter gebruikt, al eens naar enumerate() gekeken?
Do while klinkt als een geval voor generators.

block comments

Python:

'''
begin comment

eind comment
'''

multi level breaks / continue

Geeft meestal onleesbare code, waarschijnlijk had je de code al moeten opsplitsen om duidelijk en eenvoudig te houden.

switch

Veel kans op fouten en onduidelijkheid aangezien break statements regelmatig vergeten worden. In veel gevallen (in Python dan) ook de verkeerde oplossing om te willen gebruiken.

En qua benaming bv iets waar ik weer net tegen aan gelopen ben: socket.makefile() als je een buffered line reader wilt hebben.

Kan je vertellen wat je precies wil doen? Het is mij niet duidelijk aan dit verhaal. Zo ongeveer alles in Python is buffered by default dus ik begrijp niet waar het fout gaat

[Wolfboy]

StM schreef op zaterdag 20 september 2014 @ 18:59:
Zou kunnen met een generator ja. Ik krijg er alleen direct rillingen van. Terwijl iets als dit imo veel natuurlijker is:

Python:

do:
    l = sr.readline()
while not l.startswith("Token")

Als je geen takewhile (of generators in het geheel) wil gebruiken, zoiets dan?

Python:

for line in sr:
    if line.startswith('Token'):
        break

[Skyaero]

quote: ING website

Kies een veilig wachtwoord
Gebruik letters, cijfers en leestekens.
Gebruik minimaal 1 hoofdletter, 1 kleine letter en 1 cijfer.
Lengte: minimaal 8 en maximaal 20 karakters.
Uw wachtwoord mag niet hetzelfde zijn als uw gebruikersnaam.
Kies een wachtwoord dat u de afgelopen 12 maanden niet heeft gebruikt.
U kunt kiezen uit de volgende karakters:
Cijfers: 0 t/m 9
Letters: kleine letter (a t/m z) en hoofdletter (A t/m Z)
Leestekens: punt (.), koppelteken (-), liggend streepje (_) en uitroepteken (!)
Overige tekens: @, #, $ en %

*zucht*

[incaz]

Wolfboy schreef op zaterdag 20 september 2014 @ 19:23:
Veel kans op fouten en onduidelijkheid aangezien break statements regelmatig vergeten worden. In veel gevallen (in Python dan) ook de verkeerde oplossing om te willen gebruiken.

Dat klinkt idd als de pythonic way - liever niemand een handige constructie want stel je voor dat het misbruikt zou worden. Ik deel de frustratie dan ook, ik vond python nauwelijks netter, maar php heeft in elk geval geen pretenties en loopt me niet de hele tijd te vertellen dat ik het verkeerd doe.

Toevoeging: die eisen van de ING zijn toch niet zo gek? Voldoende om een sterk wachtwoord in te genereren.
Ok, een lengtelimiet van 20 is niet strict noodzakelijk, en er zijn nog een paar tekens die ook wel geldig zouden moeten zijn, maar ik zie verder het probleem niet echt?

[ Voor 19% gewijzigd door incaz op 20-09-2014 19:34 ]

[Soultaker]

Ik doe in Python meestal gewoon een serie if/elif/elif/else statements in plaats van switch. Ik vind het niet zo'n groot gemis eerlijk gezegd.

@Incaz: die eisen zijn wel gek. Allerlei sterke wachtwoorden zoals automatisch gegeneerde wachtwoorden of bijvoorbeeld Diceware wachtwoorden kun je niet gebruiken. (Zie ook deze XKCD.) Voor het verbieden van bepaalde leestekens is helemaal geen goede reden te verzinnen.

[F.West98]

WTF jQuery (ajax).
Response van de server:

code:

{ someBoolean: true }

Wat krijg je dan in JS:

code:

{ someBoolean: false; }

edit:
Oh
Natuurlijk is mijn developdatabase niet up-to-date...

[ Voor 19% gewijzigd door F.West98 op 20-09-2014 19:52 ]

[Firesphere]

Huh?

[bwerg]

Wolfboy schreef op zaterdag 20 september 2014 @ 19:23:
Veel kans op fouten en onduidelijkheid aangezien break statements regelmatig vergeten worden. In veel gevallen (in Python dan) ook de verkeerde oplossing om te willen gebruiken.

Dan zou je natuurlijk ook kunnen pleiten voor een switch-case waarin automatisch gebreak'd wordt. Niet breaken in een switch-case gebruik ik toch vooral om hetzelfde stukje code bij meerdere cases uit te voeren, zoals

Java:

switch(x) {
    case a:
    case b:
        doABthingy();
    case c:
        doCthingy();
}

Maar hiervoor kun je ook wel een andere taalconstructie bedenken. Naar mijn weten is het breaken ook vooral nodig omdat dat nou eenmaal het gemakkelijkste was voor C-compilers.

Python komt wat mij betreft dan ook een beetje puberaal over. Zal wel dat programmeur x nooit do-while's en switch-case gebruikt, sommige mensen gebruiken het wel, het is geen moeite om het toe te staan en elke andere taal ondersteunt het. Maar nee, je moet gare workarounds gebruiken.

Nou heeft elke taal wel zijn garigheidjes, maar het voelt altijd zo herp-derp om een switch-case te simuleren.

[ Voor 8% gewijzigd door bwerg op 20-09-2014 19:55 ]

[F.West98]

Firesphere schreef op zaterdag 20 september 2014 @ 19:52:
[afbeelding]
Huh?

Het ging om een JSON response van de server, die true bevatte, en jQuery maakte er in de code een false van. Bleek ik de data te vergelijken met een andere DB

[StM]

Wolfboy schreef op zaterdag 20 september 2014 @ 19:23:
[...]
Deze heb ik zelden nodig, mijn ervaring is dat je bij pythonic oplossingen deze niet nodig hebt.

Increment/decrement klinkt alsof je een counter gebruikt, al eens naar enumerate() gekeken?
Do while klinkt als een geval voor generators.

Enumerate ken ik ja. En nee dat is geen alternatief als het om je offset pointer gaat.

[...]

Python:

'''
begin comment

eind comment
'''

Je code als string embedden een goed alternatief voor een multi line comment, WTF?!?!

[...]
Geeft meestal onleesbare code, waarschijnlijk had je de code al moeten opsplitsen om duidelijk en eenvoudig te houden.

Kan, maar het is niet aan de taal om mij dat op te leggen.

[...]
Veel kans op fouten en onduidelijkheid aangezien break statements regelmatig vergeten worden. In veel gevallen (in Python dan) ook de verkeerde oplossing om te willen gebruiken.

Dus omdat de gemiddelde Pythoner niet kan programmeren moet ik me maar in allerlei lastige bochten gaan wringen en allerlei extra condities gaan toevoegen? Vaak zat heb ik een dubbele loop waarbij in de eerste loop niks gebeurd. Maar ik moet opeens wel ifs gaan toevoegen en bv een signaling flag om er uit te breken.

En voor een switch is veel makkelijker de AST te optimaliseren naar een jump table als de condities het toelaten en andere low level optimalisaties. Python is al geen snelheidsmonster, hou vooral dat soort gedachtenkronkels erin, dan zal het dat ook nooit worden.

[...]
Kan je vertellen wat je precies wil doen? Het is mij niet duidelijk aan dit verhaal. Zo ongeveer alles in Python is buffered by default dus ik begrijp niet waar het fout gaat

Ik gebruik Python eigenlijk alleen voor single file projects om even iets snel te doen. Bv een parsertje schrijven voor een custom (binair) protocol. Voor serieuze projecten pak ik andere talen. En zolang ik aan dit soort dingen mijn kop blijf stoten zie ik dat ook niet veranderen.

Wat ik ook regelmatig doe als ik performance nodig heb is het in een high level taal ontwerpen om het daarna te herimplementeren in bijvoorbeeld C. Dan zit ik echt op Pythonaanse constructies te wachten ja.

Het is ook niet dat ik altijd per definitie geen generators wil gebruiken, het is alleen een absurde oplossing voor een heel simpel probleem. Alleen omdat Guido persé niet aan do while wilt gaan we dit soort rare oplossingen bedenken. Het is ook niet alsof de engine hiervoor uitgebreid / vervuilt moet worden. Dit kan je gewoon op AST niveau omschrijven.

Wolfboy schreef op zaterdag 20 september 2014 @ 19:27:
[...]
Als je geen takewhile (of generators in het geheel) wil gebruiken, zoiets dan?

Python:

for line in sr:
    if line.startswith('Token'):
        break

Hmm dit was in principe ook een mogelijkheid geweest ja. Ik vraag me alleen af of het geen gekke dingen gaat doen als je ook nog eens terug gaat schrijven, maar dat was nu toch niet aan de orde.

[RayNbow]

StM schreef op zaterdag 20 september 2014 @ 18:59:
[...]


Je gaat proberen om via allerlei utility code een language construct na te bootsen. Bv zo: http://code.activestate.com/recipes/410692/

Wat je vervolgens eenmalig in een package kunt gooien en dan kunt importeren?

Verder, wat is precies het probleem om een "language construct" te implementeren in code? Als een taal een "language construct" kan nabootsen en het kan inkapselen in een herbruikbare module, dan is dat juist een pluspunt. Dat betekent dat de taal zelf simpeler kan worden gemaakt.

(Beste voorbeeld is hier misschien Haskell? Voor die taal kunnen looping constructs worden geimplementeerd d.m.v. higher order functions.)

En wil je default values dan moet je maar de exception afhandelen.

Python:

result = {
  'a': lambda x: x * 5,
  'b': lambda x: x + 7,
  'c': lambda x: x - 2
}[value](x)

Een dict heeft een get methode die default cases kan afhandelen zonder exceptions.

[...]

Zou kunnen met een generator ja. Ik krijg er alleen direct rillingen van. Terwijl iets als dit imo veel natuurlijker is:

Python:

do:
    l = sr.readline()
while not l.startswith("Token")

Ten eerste, wat is er mis met een generator? Sowieso, is sr in je codevoorbeeld niet vergelijkbaar met wat een generator of iterable is?

Ten tweede, het is moeilijk in te schatten of dat codevoorbeeld natuurlijker is (zonder precies te weten waarom je door een lijst regels itereert). Wat je in feite doet in het bovenstaande voorbeeld is het volgende:

Python:

line = findNext(sr, lambda line: line.startswith("Token"))

Met:

Python:

def findNext(iterator, predicate):
    for item in iterator:
        if predicate(item):
            return item

Maar goed, zonder de context is het lastig om een goede oplossing aan te dragen. Ik neem namelijk aan dat de gevonden regel nog verder in het programma gebruikt wordt. Hoe die regel gebruikt wordt beinvloedt of mijn interpretatie handig is of niet.

[incaz]

Het punt is gewoon dat een taal die volhardend een 'one true way' betoogt nogal eens erg vreemde dingen vraagt die de code helemaal niet helderder, eenvoudiger, veiliger of makkelijker leesbaar maken. Terwijl men dat wel claimt.
Ja, er zijn oplossingen voor, maar ze zijn complexer dan die in andere talen, en niet eenvoudiger. Net zo suf als claimen dat je met alleen maar xor betere code krijgt omdat er minder ambigue constructs zijn. Ik wil een high level language omdat, nou ja, ik eigenlijk geen zin heb om allerlei details zelf uit te gaan zoeken, en het ideaal is als dat gewoon netjes in de basis wordt meegenomen.

(Maar goed. In 'everything is a file'-linux kreeg ik het ook binnen notime voor elkaar om 'this procedure is only available for files' op het scherm te toveren, en 'everthing is an object'-java meldde mij ''not available for primitives'. Ik schijn nogal eens tegen de grenzen van simplificaties op te lopen )

[RayNbow]

StM schreef op zaterdag 20 september 2014 @ 20:01:
En voor een switch is veel makkelijker de AST te optimaliseren naar een jump table als de condities het toelaten en andere low level optimalisaties. Python is al geen snelheidsmonster, hou vooral dat soort gedachtenkronkels erin, dan zal het dat ook nooit worden.

En een serie if/elif/else-statements onder de juiste voorwaarden is niet om te schrijven naar een jump table?

[StM]

(Heel wat) minder makkelijk Ik zou ook geen compiler zo weten die het kan.

*edit*

Nu zal er vast een voorbeeld volgen van een compiler die het wel kan Ik ga er trouwens over ophouden, want ik weet leukere dingen te doen.

[ Voor 52% gewijzigd door StM op 20-09-2014 20:28 ]

[bwerg]

RayNbow schreef op zaterdag 20 september 2014 @ 20:02:
Verder, wat is precies het probleem om een "language construct" te implementeren in code? Als een taal een "language construct" kan nabootsen en het kan inkapselen in een herbruikbare module, dan is dat juist een pluspunt. Dat betekent dat de taal zelf simpeler kan worden gemaakt.

Prima, maar waarom zitten er dan in hemelsnaam wél constructies als while-else en for-else in python?

Daar kan ik met mijn goede verstand niet bij. Een beetje cool en exotisch doen met for-else, maar een gewone do-while of switch-case kan er, ondanks veel vraag, niet in.

Ach ja, elke taal heeft zijn lelijkheden. De BigInteger-klasse in Java levert ook de meest onleesbare meuk op omdat simpele operator overloading 'te vaak misbruikt zou worden' en daarom niet in de taal mag. Soms heeft ook een taalontwerper gewoon een kronkel in zijn hoofd over hoe het zou moeten terwijl dat nergens op slaat, net zoals ander mens.

[ Voor 34% gewijzigd door bwerg op 20-09-2014 21:02 ]

[RayNbow]

bwerg schreef op zaterdag 20 september 2014 @ 20:55:
[...]

Prima, maar waarom zitten er dan in hemelsnaam wél constructies als while-else en for-else in python?

Geen idee, ik gebruik ze niet.

Daar kan ik met mijn goede verstand niet bij. Een beetje cool en exotisch doen met for-else, maar een gewone do-while of switch-case kan er, ondanks veel vraag, niet in.

Het liefst zie ik dat er zo min mogelijk language constructs in een taal ingebakken zitten en dat de rest in code kan worden uitgedrukt en dus in een library kan worden geplaatst.

(Op dit gebied mis ik bijv. lambda's met statements/code blocks in Python.)

[incaz]

RayNbow: waarom zou je dan nog de moeite nemen om een high level taal te nemen, en bouw je niet gewoon je eigen compiler? Kun je alle language constructs precies zo maken als je wilt
(En hoe IDE's dat met language constructs in je IDE? Lijkt me dat je dan ook alle insights en templates en hints zelf moet maken? En krijg je nog wel dat ze de juiste informatie geven, dus over je werkelijke functies en niet over je gemaskeerde language constructs?)

[Gamebuster]

*oeps*

[ Voor 121% gewijzigd door Gamebuster op 20-09-2014 22:23 ]

[Gleighton]

Euh volgens mij zit je in de verkeerde thread Gamebuster

[xehbit]

Gamebuster schreef op zaterdag 20 september 2014 @ 22:09:
Gezien de frequente inactiviteit van de admins van pretjeuh's server heb ik maar m'n eigen server weer online gezet op mc.kutcomputers.nl, incl. 5 spelers die actief gebruik maken van teamspeak. (ts3.kutcomputers.nl) (gehele clan maakt er gebruik van inmiddles)

Geen whitelist, dus iedereen welkom.

kutcomputers.nl

[Gamebuster]

Gleighton schreef op zaterdag 20 september 2014 @ 22:12:
Euh volgens mij zit je in de verkeerde thread Gamebuster

Klopt,

[Soultaker]

RayNbow schreef op zaterdag 20 september 2014 @ 21:21:
Het liefst zie ik dat er zo min mogelijk language constructs in een taal ingebakken zitten en dat de rest in code kan worden uitgedrukt en dus in een library kan worden geplaatst.

Zul je toch van Haskell naar Lisp moeten switchen.

[RayNbow]

incaz schreef op zaterdag 20 september 2014 @ 21:37:
RayNbow: waarom zou je dan nog de moeite nemen om een high level taal te nemen, en bouw je niet gewoon je eigen compiler? Kun je alle language constructs precies zo maken als je wilt
(En hoe IDE's dat met language constructs in je IDE? Lijkt me dat je dan ook alle insights en templates en hints zelf moet maken? En krijg je nog wel dat ze de juiste informatie geven, dus over je werkelijke functies en niet over je gemaskeerde language constructs?)

Haskell is een high level taal waarin je gemakkelijk je eigen "language constructs" kunt produceren, dus waarom zou ik zelf een eigen taal ontwerpen om language constructs op compiler-niveau te definieren?

Heel veel dingen in Haskell zijn trouwens niet eens built-ins, maar zitten in een library. Zelfs iets simpels als een boolean is geen built-in in Haskell, maar is niets anders dan:

Haskell:

data Bool = False | True

 
Short-circuiting logic operators zijn ook niet ingebouwd in Haskell. Die kun je simpelweg zelf definieren:

Haskell:

infixr 3 &&
infixr 2 ||

False && x = False
True && x = x

False || x = x
True || x = True

 
Of wat dacht je van een for-loop als in het onderstaande voorbeeld? Dat zit ook niet in Haskell ingebakken maar in een aparte module:

Haskell:

import Control.Monad (forM_)

example = 
  forM_ [1..10] (\i -> do
    putStr "Iteration: "
    print i
  )

Edit: Had niet door dat er al weer een nieuwe pagina was...

Soultaker schreef op zaterdag 20 september 2014 @ 22:24:
[...]

Zul je toch van Haskell naar Lisp moeten switchen.

Lisp is niet zoet genoeg. Een beetje suiker kan geen kwaad.

[ Voor 32% gewijzigd door RayNbow op 20-09-2014 22:36 ]

[BikkelZ]

bwerg schreef op zaterdag 20 september 2014 @ 20:55:
[...]

Prima, maar waarom zitten er dan in hemelsnaam wél constructies als while-else en for-else in python?

Daar kan ik met mijn goede verstand niet bij. Een beetje cool en exotisch doen met for-else, maar een gewone do-while of switch-case kan er, ondanks veel vraag, niet in.

Volgens mij komt je frustratie vooral uit het feit dat je programmeertaal x in programmeertaal y probeert te doen en op de punten waar dat dan niet lukt levert dat frictie op en de punten waarin programmeertaal y uitblinkt negeer je omdat dat er raar uit ziet of gewoon niet in je op komt.

Er zijn heel veel dingen in Python die ik graag in andere talen terug zou willen zien komen en die ik ook terug zie in vuilnisbakkentalen zoals Apple Swift. Ik vind white space == program flow echt geweldig, gewoon nooit meer gezeik over dat soort dingen. PEP-8 met ingebakken support in PyCharm. Ik huilde bijna van geluk toen ik zag aangezien ik maanden lang alleen maar Objective-C achter de rug had van eigenwijze mensen die allemaal hun eigen in hun ogen de beste manier van code schrijven hebben (en ik deed er net zo hard aan mee ).

bwerg schreef op zaterdag 20 september 2014 @ 20:55:
[...]

Ach ja, elke taal heeft zijn lelijkheden. De BigInteger-klasse in Java levert ook de meest onleesbare meuk op omdat simpele operator overloading 'te vaak misbruikt zou worden' en daarom niet in de taal mag. Soms heeft ook een taalontwerper gewoon een kronkel in zijn hoofd over hoe het zou moeten terwijl dat nergens op slaat, net zoals ander mens.

Zover ik begrepen heb is de scheiding tussen primitieven en objecten pas in een later stadium in verband met performance redenen toegevoegd en had je in het begin dus alléén maar objecten en had je dus alléén een Integer klasse.

Dat C# het voor de gemiddelde programmeur veel makkelijker opgelost heeft is natuurlijk zo klaar als een klontje maar onder de motorkap werken ze eigenlijk allebei precies het zelfde. C# verbergt het probleem eigenlijk alleen.

[Ealanrian]

Zojuist een rare bug gevonden door Chrome's prerendering... een lamp veranderde van kleur voor de get request werd uitgevoerd door de gebruiker. WTF

[BikkelZ]

Ealanrian schreef op zaterdag 20 september 2014 @ 22:55:
Zojuist een rare bug gevonden door Chrome's prerendering... een lamp veranderde van kleur voor de get request werd uitgevoerd door de gebruiker. WTF

Een lamp?

[xehbit]

BikkelZ schreef op zaterdag 20 september 2014 @ 22:56:
[...]


Een lamp?

Philips HUE !

[Ealanrian]

BikkelZ schreef op zaterdag 20 september 2014 @ 22:56:
[...]


Een lamp?

Ik zal even wat licht werpen op deze situatie: Wij zijn bezig met de phillips HUE lampen op de Dutch Open Hackaton en die kunnen we nu via http get requests aansturen. Als je dan een browser hebt die prerendering doet en dus de pagina al vast op haalt krijg je best rare effecten

[Alex)]

Daarom NOOIT een GET-request gebruiken om ergens een actie uit te laten voeren.

[ Voor 25% gewijzigd door Alex) op 20-09-2014 23:13 ]

[Ealanrian]

Alex) schreef op zaterdag 20 september 2014 @ 23:13:
Daarom NOOIT een GET-request gebruiken om ergens een actie uit te laten voeren.

Omdat een browser bedenkt vast een pagina op te halen terwijl je nog niet hebt verteld dat je die pagina wilt zien?

[Alex)]

Ealanrian schreef op zaterdag 20 september 2014 @ 23:14:
[...]

Omdat een browser bedenkt vast een pagina op te halen terwijl je nog niet hebt verteld dat je die pagina wilt zien?

Browsers, web crawlers, cache, proxyservers, CSRF (een andere website die een <img />-tag plaatst met als URL de uit te voeren actie), enzovoorts.

[xehbit]

Ealanrian schreef op zaterdag 20 september 2014 @ 23:14:
[...]

Omdat een browser bedenkt vast een pagina op te halen terwijl je nog niet hebt verteld dat je die pagina wilt zien?

Google chrome verstuurd een GET request inderdaad al via de omnibox(url aavul ding?).

[Ealanrian]

Alex) schreef op zaterdag 20 september 2014 @ 23:16:
[...]

Browsers, web crawlers, cache, proxyservers, CSRF (een andere website die een <img />-tag plaatst met als URL de uit te voeren actie), enzovoorts.

Kijk normaal zouden we dit inderdaad iets beter beveiliging maar iets met hackaton te weinig tijd en lui

Het laat je wel zoeken naar het probleem terwijl die er eigenlijk niet is

[Alex)]

Ealanrian schreef op zaterdag 20 september 2014 @ 23:18:
[...]

Kijk normaal zouden we dit inderdaad iets beter beveiliging maar iets met hackaton te weinig tijd en lui

Met die gedachte zijn al heel veel websites gehacked en userdatabases gelekt.

Het laat je wel zoeken naar het probleem terwijl die er eigenlijk niet is

Eens, het zijn van die stomme dingen die je eigenlik niet verwacht.

[Douweegbertje]

Alex) schreef op zaterdag 20 september 2014 @ 23:19:
[...]

Met die gedachte zijn al heel veel websites gehacked en userdatabases gelekt.

[...]

Eens, het zijn van die stomme dingen die je eigenlik niet verwacht.

eh niet overdrijven. Het is een hackaton, niet een deadline voor een intern product oid. Wereld van verschil.
Je kan moeilijk aan het einde van zo'n programma zeggen van "ja hier is je half gebakken meuk, het werkt niet maar het is wel veilig!!On!On"...

[Alex)]

Douweegbertje schreef op zaterdag 20 september 2014 @ 23:52:
[...]


eh niet overdrijven. Het is een hackaton, niet een deadline voor een intern product oid. Wereld van verschil.
Je kan moeilijk aan het einde van zo'n programma zeggen van "ja hier is je half gebakken meuk, het werkt niet maar het is wel veilig!!On!On"...

Uiteraard! Nou is GET vs POST wel een heel klein verschil

[BikkelZ]

Ik vind zo'n Hackaton best wel een entertainend idee en leuk voor de contacten maar mijn vrouw wordt echt gek als ik dat er ook nog bij doen.

[Douweegbertje]

Alex) schreef op zaterdag 20 september 2014 @ 23:53:
[...]

Uiteraard! Nou is GET vs POST wel een heel klein verschil

Sure, maar per definitie niet direct onveilig. Het zelfde dat iedereen denkt dat je niet met POST CSRF kan uitvoeren.. In feite zit er 'amper' verschil tussen GET en POST qua veiligheid. Sterker is het domweg identiek behalve het feit dat GET variabelen in je URL naar voren komen..
Dus op het moment dat er in de 'backend' geen beveiliging zit als;

code:

if(is_admin($user))
{
   $var = $_GET..
   //of
   $var = $_POST...
}

maakt het geen moer uit. Omgedraaid ook, als er wel beveiliging op die manier er in zit, maakt het weer niet uit of het POST of GET is. Ok, er zijn wel wat puntjes te bedenken ook qua usability en de echte best-practice...

[Firesphere]

Douweegbertje schreef op zondag 21 september 2014 @ 00:03:
[...]


Sure, maar per definitie niet direct onveilig. Het zelfde dat iedereen denkt dat je niet met POST CSRF kan uitvoeren.. In feite zit er 'amper' verschil tussen GET en POST qua veiligheid. Sterker is het domweg identiek behalve het feit dat GET variabelen in je URL naar voren komen..
Dus op het moment dat er in de 'backend' geen beveiliging zit als;

code:

if(is_admin($user))
{
   $var = $_GET..
   //of
   $var = $_POST...
}

maakt het geen moer uit. Omgedraaid ook, als er wel beveiliging op die manier er in zit, maakt het weer niet uit of het POST of GET is. Ok, er zijn wel wat puntjes te bedenken ook qua usability en de echte best-practice...

Maak alsjeblieft geen gebruik van $_ methodes! input_filter() etc. is vele malen veiliger.
Het is niet de oplossing qua veiligheid, maar direct globals aanspreken is echt not done!

[Douweegbertje]

Mja, was wel even makkelijk voor dit voorbeeld

[F.West98]

Firesphere schreef op zondag 21 september 2014 @ 00:15:
[...]

Maak alsjeblieft geen gebruik van $_ methodes! input_filter() etc. is vele malen veiliger.
Het is niet de oplossing qua veiligheid, maar direct globals aanspreken is echt not done!

*er gaat ineens een wereld open*
Ik dacht dat $_-dingen de enige optie waren

Het is ook wel weer meer dan een jaar geleden dat ik serieus met PHP bezig was, en toen was ik nog een stuk meer n00b dan nu

[Firesphere]

F.West98 schreef op zondag 21 september 2014 @ 00:31:
[...]

*er gaat ineens een wereld open*
Ik dacht dat $_-dingen de enige optie waren

Het is ook wel weer meer dan een jaar geleden dat ik serieus met PHP bezig was, en toen was ik nog een stuk meer n00b dan nu

In elke taal geldt dat. Je spreekt globals niet direct aan.

[F.West98]

Toen had ik nog geen benul van wat globals waren

[xehbit]

Firesphere schreef op zondag 21 september 2014 @ 00:15:
[...]

Maak alsjeblieft geen gebruik van $_ methodes! input_filter() etc. is vele malen veiliger.
Het is niet de oplossing qua veiligheid, maar direct globals aanspreken is echt not done!

Hmm, was nog niet echt bekend met filter_input, maar ziet er inderdaad erg handig uit!

[Firesphere]

Dragon707 schreef op zondag 21 september 2014 @ 00:36:
[...]


Hmm, was nog niet echt bekend met filter_input, maar ziet er inderdaad erg handig uit!

Even wat voorbeelden:
http://nl1.php.net/filter_input_array
Filter de input als array, zodat je het resultaat nog kan aanspreken als array, zoals je met $_POST zou doen

http://nl1.php.net/filter_input
Filter 1 input en assign die naar de gewenste variable. Zorgt er voor dat er een basic filter overheen gaat, zodat je weet dat de input in ieder geval SQL veilig is in theorie.

Zonder filter_input methodes, ga je al direct zelf veiligheidszaken inbouwen die niet nodig zijn. PHP, Python en ASP.NET hebben deze filters aan boord, laat de taal het werk doen!
Ik heb even php als voorbeeld genomen, maar ze zijn dus meer beschikbaar Volgens mij heeft iostream van C++ het ook, maar dat weet ik niet zeker.
En de benaming kan varieren. Java heeft trouwens NIET deze filters! (JDK6 in ieder geval)

[F.West98]

Chrome en font-rendering...
font-weight: 600; gaat niet helemaal goed, toont gewoon normaal (400). In Firefox en IE werkt het wel naar wens (semibold).

[.oisyn]

Firesphere schreef op zondag 21 september 2014 @ 00:47:
[...]

Even wat voorbeelden:
http://nl1.php.net/filter_input_array
Filter de input als array, zodat je het resultaat nog kan aanspreken als array, zoals je met $_POST zou doen

http://nl1.php.net/filter_input
Filter 1 input en assign die naar de gewenste variable. Zorgt er voor dat er een basic filter overheen gaat, zodat je weet dat de input in ieder geval SQL veilig is in theorie.

Sorry hoor maar dit is magic_quotes all over again. Sure, je hebt nu controle over waarvoor je het gaat gebruiken, maar nog steeds pas je de escaping toe op de plek waar je de input leest ipv waar je de output gebruikt. Hopeloos.

[Douweegbertje]

.oisyn schreef op zondag 21 september 2014 @ 02:19:
[...]


Sorry hoor maar dit is magic_quotes all over again. Sure, je hebt nu controle over waarvoor je het gaat gebruiken, maar nog steeds pas je de escaping toe op de plek waar je de input leest ipv waar je de output gebruikt. Hopeloos.

Hoe zie je dat dan voor je?

[Firesphere]

.oisyn schreef op zondag 21 september 2014 @ 02:19:
[...]


Sorry hoor maar dit is magic_quotes all over again. Sure, je hebt nu controle over waarvoor je het gaat gebruiken, maar nog steeds pas je de escaping toe op de plek waar je de input leest ipv waar je de output gebruikt. Hopeloos.

Nee, magic_quotes was een escaping methode, terwijl filter_input een filter methode is. Maakt nogal verschil.

Ik zeg ook niet dat het de heilige graal qua veiligheid is, maar dat het een betere methode is om globals lokaal te krijgen, dan ze direct aan te spreken.

[xehbit]

Voor MySQL (PDO) vraag ik me af of dat wat meerwaarde heeft om input_filter te gebruiken wanneer je alles met prepared statements doet. Die zorgt er eigenlijk ook voor dat je query's veilig zijn.

Maar zijn er niet situaties waar je dit juist niet wilt gebruiken?

[Johnnei]

Firesphere schreef op zondag 21 september 2014 @ 00:47:
[...]

Zonder filter_input methodes, ga je al direct zelf veiligheidszaken inbouwen die niet nodig zijn. PHP, Python en ASP.NET hebben deze filters aan boord, laat de taal het werk doen!
Ik heb even php als voorbeeld genomen, maar ze zijn dus meer beschikbaar Volgens mij heeft iostream van C++ het ook, maar dat weet ik niet zeker.
En de benaming kan varieren. Java heeft trouwens NIET deze filters! (JDK6 in ieder geval)

Oi! Kom eens uit de steentijd
Weet ook niet zeker of Java 7/8 wel een functie heeft die dat doet, maar ik gebruik java ook niet voor web.

[Cartman!]

.oisyn schreef op zondag 21 september 2014 @ 02:19:
[...]


Sorry hoor maar dit is magic_quotes all over again. Sure, je hebt nu controle over waarvoor je het gaat gebruiken, maar nog steeds pas je de escaping toe op de plek waar je de input leest ipv waar je de output gebruikt. Hopeloos.

Ik zorg altijd dat m'n inputs geforceerd worden omgezet naar UTF-8 en dat er geen gare control characters inzitten bijvoorbeeld. Ik hoef geen UTF-7 meuk in m'n database te hebben die tijdens output escaping net anders kan reageren omdat ik verwacht dat t UTF-8 is. Filtering + validatie bij opslaan en output escaping tijdens presentatie, lijkt me een hele normale manier van werken.

[RayNbow]

http://nl1.php.net/manual/en/filter.filters.sanitize.php

FILTER_SANITIZE_EMAIL
"email"
Remove all characters except letters, digits and !#$%&'*+-/=?^_`{|}~@.[].

[Cartman!]

RayNbow schreef op zondag 21 september 2014 @ 11:50:
http://nl1.php.net/manual/en/filter.filters.sanitize.php

[...]

Dat is grappig omdat?

[RayNbow]

Cartman! schreef op zondag 21 september 2014 @ 11:51:
[...]

Dat is grappig omdat?

Omdat het een geldig emailadres in een compleet ander emailadres kan veranderen:

PHP:

$a = filter_var('test(comment)@example.org', FILTER_SANITIZE_EMAIL);

[WernerL]

.oisyn schreef op zondag 21 september 2014 @ 02:19:
[...]


Sorry hoor maar dit is magic_quotes all over again. Sure, je hebt nu controle over waarvoor je het gaat gebruiken, maar nog steeds pas je de escaping toe op de plek waar je de input leest ipv waar je de output gebruikt. Hopeloos.

Dit is dan ook geen alternatief op het gebruik van parameterized statements. Het is niet verstandig om de output direct in een SQL query te gebruiken zoals "SELECT * FROM bla WHERE iets = ' . $var ...

Ik gebruik het zelf meer als validatie. Wil ik selecteren op int? Dan geeft de filter_input functie false terug als het geen int is. Op dat punt is het dus ook zinloos om nog de SQL query uit te voeren. Hoewel is_numeric() ook gewoon zou kunnen in dat geval. Voor email validatie oid gebruik ik het dan weer niet. Het is wel een handige methode om ervoor te zorgen dat alle values van het juiste datatype zijn voordat je verder gaat.

[ Voor 6% gewijzigd door WernerL op 21-09-2014 12:16 ]

[.oisyn]

Douweegbertje schreef op zondag 21 september 2014 @ 03:40:
[...]


Hoe zie je dat dan voor je?

Hoe zie ik wat dan voor me? Firesphere's opmerking dat het gebruiken van superglobals "not done" zou zijn is sowieso onzin, dus er is geen reden voor een alternatieve oplossing. Er is amper een toegevoegde waarde van filter_input boven het zelf uitlezen van die globals. Over het algemeen wil je sowieso verschillende dingen doen indien een input niet bestaat en wanneer een input niet goed valideert, dus in plaats van een isset en een losse valideerfunctie zit je dan de returnvalue van filter_input te testen op false danwel null (fijn als je input een boolean is ). Sanitization wil je over het algemeen sowieso niet doen in de laag die de input uitleest. En voor een simpel ad hoc scriptje waarbij je niets geeft om al die dingen mist het weer een essentiële feature: het opgeven van een default waarde voor als het ding niet bestaat of niet goed valideert.

[.oisyn]

WernerL schreef op zondag 21 september 2014 @ 12:13:
[...]


Dit is dan ook geen alternatief op het gebruik van parameterized statements.

Je mist het punt. Het punt is dat de code om die database-query uit te voeren over het algemeen op een compleet andere plek staat dan waar je de input uitleest. In plaats van zelf db queries te gaan zitten bouwen, gebruik je een functie of class die db serialization voor je regelt. Die code is generiek en werkt niet op basis van user input. Je gaat dan ook niet van tevoren die dingen escapen (even compleet los van het feit dat dat voor parameterized queries idd sowieso niet nodig is, maar vervang de sql database met een willekeurig ander systeem en het resultaat is hetzelfde).

[Verwijderd]

RayNbow schreef op zondag 21 september 2014 @ 11:55:
[...]

Omdat het een geldig emailadres in een compleet ander emailadres kan veranderen:

PHP:

$a = filter_var('test(comment)@example.org', FILTER_SANITIZE_EMAIL);

Lees dit even goed door, want het is dus helemaal niet een ander emailadres wat eruit rolt

Met name het stukje wat zegt:

Comments are allowed with parentheses at either end of the local part; e.g. "john.smith(comment)@example.com" and "(comment)[e-mail]" are both equivalent to "[e-mail]".

[RobertMe]

Verwijderd schreef op zondag 21 september 2014 @ 13:34:
[...]


Lees dit even goed door, want het is dus helemaal niet een ander emailadres wat eruit rolt

Met name het stukje wat zegt:


[...]

Er rolt dus wel een ander email adres uit. PHP stript de haakjes, waarna je [e-mail] overhoud. Waar [e-mail] het (geldige) email adres is.

php > echo filter_var('test(comment)@example.org', FILTER_SANITIZE_EMAIL);
[e-mail]

[ Voor 11% gewijzigd door RobertMe op 21-09-2014 13:37 ]

[Verwijderd]

Op zich logisch, want hij stript alleen de characters. En wat gebeurt er eigenlijk als je dat emailadres eerst door een

code:

filter_var($email, FILTER_VALIDATE_EMAIL);

haalt?

Dus:

PHP:

$email = 'john.smith(comment)@example.com';

$email = filter_var(filter_var($email, FILTER_VALIDATE_EMAIL), FILTER_SANITIZE_EMAIL);

[ Voor 31% gewijzigd door Verwijderd op 21-09-2014 13:44 ]

[RayNbow]

Verwijderd schreef op zondag 21 september 2014 @ 13:42:
Op zich logisch, want hij stript alleen de characters. En wat gebeurt er eigenlijk als je dat emailadres eerst door een

code:

filter_var($email, FILTER_VALIDATE_EMAIL);

haalt?

Daar komt onterecht false uit.

[Verwijderd]

Geen comments in emailadressen plaatsen dan

/me zich blijft verbazen over PHP en het naleven van sommige RFC's

Er is wel de nodige discussie over dat filter overigens. Op zich niet heel verbazingwekkend gezien het feit dat de RFC's met betrekking tot emailadressen ook niet heel simpel zijn..

[ Voor 47% gewijzigd door Verwijderd op 21-09-2014 13:48 ]

[Wolfboy]

incaz schreef op zaterdag 20 september 2014 @ 19:32:
[...]


Dat klinkt idd als de pythonic way - liever niemand een handige constructie want stel je voor dat het misbruikt zou worden. Ik deel de frustratie dan ook, ik vond python nauwelijks netter, maar php heeft in elk geval geen pretenties en loopt me niet de hele tijd te vertellen dat ik het verkeerd doe.

Het hangt er geheel vanaf hoe je het wil gebruiken, als je C wil schrijven in Python dan doe je iets verkeerd. C is geen Python en Python is geen C, beiden hebben voor- en nadelen en zijn niet direct vertaalbaar naar elkaar.

Maar om het geheel wat contructiever te maken, geef wat voorbeeldcode en ik zal je een voorstel geven hoe je het op een duidelijke manier kan schrijven zonder die constructs nodig te hebben. Toen ik in eerste instanatie bij Python aankwam mistte ik de features ook (op z'n tijd mis ik de do-while idd nog wel), maar de code is bijna altijd te herstructureren naar iets wat duidelijker is dan de originele oplossing.

bwerg schreef op zaterdag 20 september 2014 @ 19:53:
[...]

Dan zou je natuurlijk ook kunnen pleiten voor een switch-case waarin automatisch gebreak'd wordt. Niet breaken in een switch-case gebruik ik toch vooral om hetzelfde stukje code bij meerdere cases uit te voeren, zoals

Java:

switch(x) {
    case a:
    case b:
        doABthingy();
    case c:
        doCthingy();
}

Zeker, maar is dat nu zoveel duidelijker/beter dan dit?

Python:

if x in (a, b):
    doABthingy()
elif x == c:
    doCthingy()

Of zelfs (al zou ik voorzichtig zijn met deze constructie):

Python:

cases = dict(
  a=doAtThingy(),
  b=doABthingy(),
  c=doCthingy(),
)

cases[x]()

Python komt wat mij betreft dan ook een beetje puberaal over. Zal wel dat programmeur x nooit do-while's en switch-case gebruikt, sommige mensen gebruiken het wel, het is geen moeite om het toe te staan en elke andere taal ondersteunt het. Maar nee, je moet gare workarounds gebruiken.

Do-while is nog best iets voor te zeggen, switch statements geven imho niet echt toegevoegde waarde. Een if/elif/else is bijna altijd korter dan een switch/case/break combinatie.

Nou heeft elke taal wel zijn garigheidjes, maar het voelt altijd zo herp-derp om een switch-case te simuleren.

Fair enough

StM schreef op zaterdag 20 september 2014 @ 20:01:
[...]


Enumerate ken ik ja. En nee dat is geen alternatief als het om je offset pointer gaat.

In dat geval zou een generator mogelijk een uitkomst kunnen bieden. Punt is, Python is een andere taal dan C/Java/C++/etc.

Zie ook: http://dirtsimple.org/2004/12/python-is-not-java.html

Je code als string embedden een goed alternatief voor een multi line comment, WTF?!?!

Multiline strings zijn comments in Python, komen ook gewoon in je __doc__ terecht namelijk.

Zie ook deze code:

Python:

def some_function():
    '''THere are some docs here

    And more...
    '''
    pass

print some_function.__doc__

Tenzij je het doet om je code uit te commenten, in dat geval kan je het beste even de shortcut in je editor zoeken

Dus omdat de gemiddelde Pythoner niet kan programmeren moet ik me maar in allerlei lastige bochten gaan wringen en allerlei extra condities gaan toevoegen? Vaak zat heb ik een dubbele loop waarbij in de eerste loop niks gebeurd. Maar ik moet opeens wel ifs gaan toevoegen en bv een signaling flag om er uit te breken.

Python is gemaakt om duidelijke code te geven, het is niet gemaakt om gelijk te zijn aan andere talen. Dat jij niet gewend bent om zo te programmeren maakt de taal niet slecht, dat geeft gewoon aan dat jij geen ervaring hebt met de taal.

En voor een switch is veel makkelijker de AST te optimaliseren naar een jump table als de condities het toelaten en andere low level optimalisaties. Python is al geen snelheidsmonster, hou vooral dat soort gedachtenkronkels erin, dan zal het dat ook nooit worden.

Als iets heel performance gevoelig is dan gebruik je een C library in plaats van pure Python, leesbaarheid opofferen voor performance is bijna altijd een slecht idee.

Zie ook de uitspraak van Donald Knuth over dit punt: Wikipedia: Program optimization

Ik gebruik Python eigenlijk alleen voor single file projects om even iets snel te doen. Bv een parsertje schrijven voor een custom (binair) protocol. Voor serieuze projecten pak ik andere talen. En zolang ik aan dit soort dingen mijn kop blijf stoten zie ik dat ook niet veranderen.

En zolang je het niet serieus gebruikt en het als een andere taal wil gebreuiken blijf je je kop ook stoten. Niets mis mee, maar dan is Python ofwel niet jouw taal of heb je geen zin om er tijd in te steken.

Wat ik ook regelmatig doe als ik performance nodig heb is het in een high level taal ontwerpen om het daarna te herimplementeren in bijvoorbeeld C. Dan zit ik echt op Pythonaanse constructies te wachten ja.

Daar is Python geen goede taal voor nee, heel veel constructs kan je niet 1 op 1 vertalen. Maar je kan wel deelcode in een library gooien voor meer performance en dat uitvoeren vanuit Python.

Neem bijvoorbeeld Cython voor de makkelijke optie.

Het is ook niet dat ik altijd per definitie geen generators wil gebruiken, het is alleen een absurde oplossing voor een heel simpel probleem. Alleen omdat Guido persé niet aan do while wilt gaan we dit soort rare oplossingen bedenken. Het is ook niet alsof de engine hiervoor uitgebreid / vervuilt moet worden. Dit kan je gewoon op AST niveau omschrijven.

Ik ken het geval niet, misschien heb je gelijk in dit geval. Misschien is de code prima te herstructureren... Geef eens een mooi stuk voorbeeldcode dan kijk ik er naar

[ Voor 80% gewijzigd door Wolfboy op 21-09-2014 14:31 ]

[Gamebuster]

Zojuist alle benodigde kabels en geheugenkaarten besteld voor m'n raspberry pi mini cluster. Ik begin eerst met 4 stuks.

Ik mis nog 1 raspberry pi en een manier om 4 raspberry pi's te voeden. Ik ben benieuwd of een powered USB hub voldoende stroom levert voor 4 PI's. De power supply zou 2A op 5V moeten leveren. 0,5A per Pi zonder aangesloten devices zou voldoende moeten zijn, lijkt mij.

[ Voor 34% gewijzigd door Gamebuster op 21-09-2014 16:33 ]

[Firesphere]

Gamebuster schreef op zondag 21 september 2014 @ 16:28:
Zojuist alle benodigde kabels en geheugenkaarten besteld voor m'n raspberry pi mini cluster. Ik begin eerst met 4 stuks.

Ik mis nog 1 raspberry pi en een manier om 4 raspberry pi's te voeden. Ik ben benieuwd of een powered USB hub voldoende stroom levert voor 4 PI's. De power supply zou 2A op 5V moeten leveren. 0,5A per Pi zonder aangesloten devices zou voldoende moeten zijn, lijkt mij.

Nee, dat is echt niet genoeg, om het goed draaiende te krijgen heb je echt 1A per Pi nodig. Ik zou zeggen, zoek een USB-powerbank-achtige constructie, zodat je ook automatisch een soort UPS hebt.

Een anker heeft 2 1A out en 2 2A out's als ik me niet vergis. Daarme, plus die aan een constante voeding, heb je een UPS plus genoeg power, lijkt me.

---

Een product dat op de site allemaal "OMG dit product is geweldig" quotes heeft, vertrouw ik niet. Die zijn wanhopig hun product aan de man aan het brengen.

[ Voor 8% gewijzigd door Firesphere op 21-09-2014 17:46 ]

[RayNbow]

Ben benieuwd, hoeveel mensen hier hebben eig. ooit Prolog aangeraakt?

* RayNbow heeft het ooit 1x moeten gebruiken voor een vak in het vorige decennium...