Daar had ik inderdaad ook iets van 'heh, de grootte van de transistors maakt de processor sneller?'. Ik interpreteer het maar als: kleinere transistors -> minder power -> meer functionaliteit voor hetzelfde gebruik.oisyn schreef op woensdag 10 juli 2013 @ 16:42:
[...]
Ik stel sowieso serieus vragen bij zijn argument dat de grootte van de transistor serieus bijdraagt aan het gebrek aan performance van ARM tov x86 - dat is gewoon complete nonsens. Inderdaad, het huidige procedé is 22nm, maar de oude Core 2 was 65nm. Echt niet dat de 32nm ARM cpu in de iPhone 5 daar ook maar enigszins aan gaat tippen. En zo enorm veel verschil zit er ook niet tussen bijv. Sandy Bridge (32nm) en Ivy Bridge (22nm). Een kleiner procedé zorgt vooral voor energiezuinigere CPU's, waardoor lagere voltages en hogere clockcycles mogelijk zijn. Maar ze zijn niet per se sneller.
Een veel interessantere globale metric is het aantal transistors, niet de grootte ervan. Wat de x86 zo snel maakt zijn dingen als out of order execution, branch prediction, memory access prediction, lengte van de insturction pipeline, het aantal execution units en de gemiddelde grootte van de cache. Stuk voor stuk dingen die bijdragen aan de complexiteit, en dus het aantal transistors, van de CPU. Maar meer transistors betekent ook meer power, en dus zul je die uitgebreidere features niet snel zien in een mobiele CPU. Kan zo snel geen transistor counts van mobiele SoCs vinden, maar ter vergelijking, een Intel Atom heeft er 47 miljoen, een Core 2 Duo heeft er 219 miljoen. Een Nehalem Core i7 (zonder GPU) heeft er 731 miljoen.
Zo, koffie iemand?
Sorry dat ik een beetje laat ben vandaag.
Sorry dat ik een beetje laat ben vandaag.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Verwijderd
Met een kleinere transistor zijn er uiteraard wel meer te printen op een chip van dezelfde grootte. Indirect maakt een kleinere transistor een processor dus wel snellerSh4wn schreef op donderdag 11 juli 2013 @ 09:20:
[...]
Daar had ik inderdaad ook iets van 'heh, de grootte van de transistors maakt de processor sneller?'. Ik interpreteer het maar als: kleinere transistors -> minder power -> meer functionaliteit voor hetzelfde gebruik
Aah lekker. Proost!Firesphere schreef op donderdag 11 juli 2013 @ 09:38:
Zo, koffie iemand?
Sorry dat ik een beetje laat ben vandaag.
Wat een stilte hier! 
Vandaag maar eens begonnen met een dubbele bak koffie in plaats van een blikje enery drink. Hopelijk kan ik vandaag een beetje motivatie vinden en flink opschieten. Anders heb ik straks nog niet rustig vakantie.
Vandaag maar eens begonnen met een dubbele bak koffie in plaats van een blikje enery drink. Hopelijk kan ik vandaag een beetje motivatie vinden en flink opschieten. Anders heb ik straks nog niet rustig vakantie.
Er wordt hard gewarkt vandaagTheNephilim schreef op donderdag 11 juli 2013 @ 10:31:
Wat een stilte hier!
Vandaag maar eens begonnen met een dubbele bak koffie in plaats van een blikje enery drink. Hopelijk kan ik vandaag een beetje motivatie vinden en flink opschieten. Anders heb ik straks nog niet rustig vakantie.
Ah
Moet nog een beetje op gang komen! Heb alweer een leuke uitdaging staan, niet zozeer omdat het moeilijk te maken is, maar omdat het zo ... niet handig is allemaal.
Website met specifieke onderdelen voor auto's. Deze moeten in een lijst komen en dergelijke. Echter in de Excel sheet die ik gekregen heb, is er alleen een merk, part.no. en een niks zeggende beschrijving. Dat is gewoon te weinig informatie
Just implement as requestedTheNephilim schreef op donderdag 11 juli 2013 @ 10:44:
[...]
Ah![]()
Moet nog een beetje op gang komen! Heb alweer een leuke uitdaging staan, niet zozeer omdat het moeilijk te maken is, maar omdat het zo ... niet handig is allemaal.
Website met specifieke onderdelen voor auto's. Deze moeten in een lijst komen en dergelijke. Echter in de Excel sheet die ik gekregen heb, is er alleen een merk, part.no. en een niks zeggende beschrijving. Dat is gewoon te weinig informatie
Handig is dat inderdaad ook niet maar zorgt er wel voor dat ik voorlopig nog wel commercieel werk heb (detachering)
"Het is de bedoeling dat men gewoon Ctrl + F kan doen op de site, in die lijst."Kayr schreef op donderdag 11 juli 2013 @ 10:50:
[...]
Just implement as requestedZo gaat het hier ook vaak. moet vanuit design daarna toch nog minstens 10 keer anders....
Handig is dat inderdaad ook niet maar zorgt er wel voor dat ik voorlopig nog wel commercieel werk heb (detachering)

Ach, het is eigenlijk niet erg, ik mag niet klagen. Hier ook ontwikkelen vanuit een ontwerp trouwens.
Dat klinkt als een hele vage omschrijving van iets wat de browser zelf wel kanTheNephilim schreef op donderdag 11 juli 2013 @ 10:56:
[...]
"Het is de bedoeling dat men gewoon Ctrl + F kan doen op de site, in die lijst."![]()
Ach, het is eigenlijk niet erg, ik mag niet klagen. Hier ook ontwikkelen vanuit een ontwerp trouwens.
Dus, gewoon die excel exporteren naar HTML en je bent klaar

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Ik vind het toch deel van onze plicht als “webdev” om klanten (en hun klanten) een goed product te leveren en advies te geven. Dit is imho een situatie waarin je de klant moet overtuigen dat het beter kan/moet.TheNephilim schreef op donderdag 11 juli 2013 @ 10:56:
"Het is de bedoeling dat men gewoon Ctrl + F kan doen op de site, in die lijst."![]()
Ach, het is eigenlijk niet erg, ik mag niet klagen. Hier ook ontwikkelen vanuit een ontwerp trouwens.

“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.
Tja wat is het punt da tje hier wilt maken? Ik zeg alleen dat Javascript over een tijdje waarschijnlijk snel genoeg is voor de meeste apps en dan inderdaad prima gebruikt kan worden op alle platformen. Natuurlijk is een native taal altijd sneller dan dat, maar waarom dan niet alles in Assembly ;-)farlane schreef op woensdag 10 juli 2013 @ 20:58:
Het gaat niet alleen over JS, ook over interpreted talen en JIT dingen. Feit is dat hele volksstammen het marketinggeblaat van hun favoriete platformbouwer nadoen en zeggen dat het "net zo snel" of zelfs "potentieel sneller (over X jaar )" dan C of C++ of whatever native taal de mannen met baarden gebruiken is en dat het daarom dus wel "the one platform to rule them all" is. En dat is dus niet zo.
Hmm vandaag netbeans al 3x opnieuw opgestart.. Weet niet wat er aan de hand is maar er gaat van alles mis met deployen naar tomcat.
edit:
Gister netbeans opnieuw geïnstalleerd en had de geheugen opties voor de JVM nog niet goed gezet. Hopelijk werkt het nu beter...
edit:
Gister netbeans opnieuw geïnstalleerd en had de geheugen opties voor de JVM nog niet goed gezet. Hopelijk werkt het nu beter...
[ Voor 34% gewijzigd door Ozzie op 11-07-2013 11:12 ]
"Write code as if the next maintainer is a vicious psychopath who knows where you live."
Directeur van vorige bedrijf zei altijd: "je moet de klant aan de hand nemen door de wondere wereld van software ontwikkeling"OkkE schreef op donderdag 11 juli 2013 @ 11:02:
[...]
Ik vind het toch deel van onze plicht als “webdev” om klanten (en hun klanten) een goed product te leveren en advies te geven. Dit is imho een situatie waarin je de klant moet overtuigen dat het beter kan/moet.
FTFYOzzie schreef op donderdag 11 juli 2013 @ 11:09:
Hmm vandaag netbeans al 3x opnieuw opgestart.. Weet niet wat er aan de hand is maar er gaat van alles mis met deployen naar Stomcat.
[ Voor 21% gewijzigd door Kayr op 11-07-2013 11:13 ]
Haha ja that crossed my mind!Firesphere schreef op donderdag 11 juli 2013 @ 11:01:
[...]
Dat klinkt als een hele vage omschrijving van iets wat de browser zelf wel kan
Dus, gewoon die excel exporteren naar HTML en je bent klaar![]()
Nee de sheet ga ik importeren en zodoende kunnen ze alles netjes binnen de Wordpress omgeving aanpassen.
Helaas zit ik niet altijd met de klant aan tafel. Het ontwikkelen van een website word aan ons uitbesteed. In deze situatie heb ik alleen even met iemand van een marketing bedrijf om tafel gezeten om te bekijken hoe we het een en ander qua SEO/Adwords/etc. gaan aanpakken.OkkE schreef op donderdag 11 juli 2013 @ 11:02:
[...]
Ik vind het toch deel van onze plicht als “webdev” om klanten (en hun klanten) een goed product te leveren en advies te geven. Dit is imho een situatie waarin je de klant moet overtuigen dat het beter kan/moet.
Ik deel je mening hoor, daar niet van!
Ik mistte hem ook al. Tomcat vind ik juist het fijnst van alle containers.
"Write code as if the next maintainer is a vicious psychopath who knows where you live."
Dit klinkt echt niet als een iets wat ik ooit in een WP omgeving zou willen beheren, lijkt me echt een chaos.TheNephilim schreef op donderdag 11 juli 2013 @ 11:23:
[...]
Haha ja that crossed my mind!
Nee de sheet ga ik importeren en zodoende kunnen ze alles netjes binnen de Wordpress omgeving aanpassen.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Het zijn niet alleen seconden die je er af schaaft, maar ook bijvoorbeeld power consumption. Verder hoop ik niet dat we ooit naar een tijd toe gaan waarin alles in javascript gedaan word. Het is namelijk helemaal nergens voor nodig. Af en toe lijkt het wel als of iedereen bang is voor native.jhuiting schreef op donderdag 11 juli 2013 @ 11:04:
[...]
Tja wat is het punt da tje hier wilt maken? Ik zeg alleen dat Javascript over een tijdje waarschijnlijk snel genoeg is voor de meeste apps en dan inderdaad prima gebruikt kan worden op alle platformen.
Omdat assembly aan een hoop andere requirements niet voldoet. Bijvoorbeeld die van portability, schaalbaarheid over grotere applicaties, onderhoudbaarheid en leesbaarheid. De native talen waarover gesproken word zijn een heel stuk onderhoudbaarder dan een blok assembly.Natuurlijk is een native taal altijd sneller dan dat, maar waarom dan niet alles in Assembly ;-)
Ozzie schreef op donderdag 11 juli 2013 @ 11:28:
[...]
Ik mistte hem ook al. Tomcat vind ik juist het fijnst van alle containers.
HAP!
Mee eens, Tomcat werkt over het algemeen prima. (Topcat
Nee hoor, dat werkt prima!Firesphere schreef op donderdag 11 juli 2013 @ 11:29:
[...]
Dit klinkt echt niet als een iets wat ik ooit in een WP omgeving zou willen beheren, lijkt me echt een chaos.
Grote kans dat dat stukje native taal ook nog een stuk sneller is dan een zelfgeschreven blok assembly, met de hedendaagse optimizers..PrisonerOfPain schreef op donderdag 11 juli 2013 @ 11:33:
[...]
Omdat assembly aan een hoop andere requirements niet voldoet. Bijvoorbeeld die van portability, schaalbaarheid over grotere applicaties, onderhoudbaarheid en leesbaarheid. De native talen waarover gesproken word zijn een heel stuk onderhoudbaarder dan een blok assembly.
Als je genoeg van machinetaal en assembly weet, kun je altijd minstens even snel zijn door gewoon dezelfde code te schrijven als die de compiler uiteindelijk produceert. En handgesmeden assembly heeft bijna altijd het potentieel om sneller te zijn dan wat een compiler produceert, omdat de kennis van een compiler over de code maar beperkt is.Radiant schreef op donderdag 11 juli 2013 @ 11:38:
[...]
Grote kans dat dat stukje native taal ook nog een stuk sneller is dan een zelfgeschreven blok assembly, met de hedendaagse optimizers..
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Uiteraard, maar dan ben je ook wel even bezig.. Een compiler zit gecombineerd heel wat jaren aan kennis in van allerlei slimme mensen die je dan ook allemaal zal moeten toepassen en een compiler kan veel sneller dan de mens allerlei situaties en het effect daarvan op de snelheid bekijken en dit elke keer weer opnieuw doen voor het gehele programma bij de meest kleine wijziging.
Uitgaande van een "normaal" programma natuurlijk, geen instructievolgorde kritische dingen enzo.
Uitgaande van een "normaal" programma natuurlijk, geen instructievolgorde kritische dingen enzo.
[ Voor 11% gewijzigd door Radiant op 11-07-2013 11:56 ]
Als er een native taal is die geschikt is op alle platformen is mij dat om het even, maar omdat ik dat niet gebeuren zie ik Javascript als een prima alternatief. Dat heeft verder niets te maken met 'bang voor native' maar meer met 'in 2 / 3 verschillende talen een app moeten ontwikkelen om alle platformen te ondersteunen'. Verder is het momenteel qua power consumption inderdaad nog niet haalbaar om grotere apps in Javascript te bouwen, maar ik verwacht dat met de betere JS-engines daar binnen een jaar of 2 wel verandering in komt.[b]PrisonerOfPain schreef op donderdag 11 juli 2013 @ 11:33:
Het zijn niet alleen seconden die je er af schaaft, maar ook bijvoorbeeld power consumption. Verder hoop ik niet dat we ooit naar een tijd toe gaan waarin alles in javascript gedaan word. Het is namelijk helemaal nergens voor nodig. Af en toe lijkt het wel als of iedereen bang is voor native.
Mijn opmerking over assembly was niet zo serieus bedoeld, maar meer om aan te geven dat een 'langzamere' taal soms ook goed genoeg kan zijn.
Daarom die je dat soort dingen ook alleen een absurd specifieke situaties. Meestal kun je met compiler intrinsics al een heel stuk komen en dan heb je de best of both worlds.Radiant schreef op donderdag 11 juli 2013 @ 11:55:
Uiteraard, maar dan ben je ook wel even bezig.. Een compiler zit gecombineerd heel wat jaren aan kennis in van allerlei slimme mensen die je dan ook allemaal zal moeten toepassen en een compiler kan veel sneller dan de mens allerlei situaties en het effect daarvan op de snelheid bekijken en dit elke keer weer opnieuw doen voor het gehele programma bij de meest kleine wijziging.
Voor een normaal programma doe je zulke dingen gewoon niet, is zonde van je tijd en geld.Uitgaande van een "normaal" programma natuurlijk, geen instructievolgorde kritische dingen enzo.
Weer een onzin argument, zowel C als C++ zijn op ieder platform beschikbaar. Waar denk je dat die javascript interpreters/JITs in geschreven zijn?jhuiting schreef op donderdag 11 juli 2013 @ 12:01:
[...]
Als er een native taal is die geschikt is op alle platformen is mij dat om het even, maar omdat ik dat niet gebeuren zie ik Javascript als een prima alternatief.
Denk dat die meer een native API bedoeld die je overal op kan gebruiken.PrisonerOfPain schreef op donderdag 11 juli 2013 @ 12:03:
[...]
Weer een onzin argument, zowel C als C++ zijn op ieder platform beschikbaar. Waar denk je dat die javascript interpreters/JITs in geschreven zijn?
"Write code as if the next maintainer is a vicious psychopath who knows where you live."
Ozzie schreef op donderdag 11 juli 2013 @ 12:09:
[...]
Denk dat die meer een native API bedoeld die je overal op kan gebruiken.
Lol.. say what? Framework bedoel je zeker? Een crossplatform ".NET omgeving"?Ozzie schreef op donderdag 11 juli 2013 @ 12:09:
[...]
Denk dat die meer een native API bedoeld die je overal op kan gebruiken.
Draait mono ook op iOS? Dan zou je al een heel eind zijn.
Ja, en ook op Android.GateKeaper schreef op donderdag 11 juli 2013 @ 12:13:
[...]
Draait mono ook op iOS? Dan zou je al een heel eind zijn.
We are shaping the future
Qt? C++ dus de voordelen van een native taal en draait op Windows, Linux, OS X, iOS, Android, bijna alles in ieder geval.. Alleen niet binary portable.
* Radiant snapt ook niet waarom tegenwoordig alles ineens JS moet zijn
* Radiant snapt ook niet waarom tegenwoordig alles ineens JS moet zijn
[ Voor 6% gewijzigd door Radiant op 11-07-2013 12:20 ]
Dit nog even naast het feit dat een native taal voor 99% van het werk prima mee kan komen met goed geschreven assembly, terwijl javascript op absoluut geen enkel punt prima mee kan komen met een native taal.PrisonerOfPain schreef op donderdag 11 juli 2013 @ 11:33:
Omdat assembly aan een hoop andere requirements niet voldoet. Bijvoorbeeld die van portability, schaalbaarheid over grotere applicaties, onderhoudbaarheid en leesbaarheid. De native talen waarover gesproken word zijn een heel stuk onderhoudbaarder dan een blok assembly.
Dat gaat lang niet altijd op. Veelal gaat het erom dat je precies de juiste permutatie van instructies pakt zodat de pipelining maximaal is en latency minimaal. Dat is niet een probleem dat met de hand en het bezit van voorkennis een stuk makkelijker op te lossen is, want het is eigenlijk gewoon een variant op het traveling salesperson problem. En een computer kan in een korte tijd veel meer mogelijkheden afgaan dan jij met de hand kan doen. Dit is vooral iets wat je terugziet in shadercompilers, die hebben vaak optimalisatiemodussen die enorm lang lopen te crunchen om uiteindelijk een zo goed mogelijke oplossing te vinden en op die manier een paar cycles te winnen. Shaders lenen zich daar natuurlijk goed voor omdat het relatief korte programmaatjes zijn die enorm veel worden aangeroepen, en daardoor goede kandidaten zijn om tot op het bot geoptimaliseerd te worden.Korben schreef op donderdag 11 juli 2013 @ 11:46:
[...]
Als je genoeg van machinetaal en assembly weet, kun je altijd minstens even snel zijn door gewoon dezelfde code te schrijven als die de compiler uiteindelijk produceert. En handgesmeden assembly heeft bijna altijd het potentieel om sneller te zijn dan wat een compiler produceert, omdat de kennis van een compiler over de code maar beperkt is.
[ Voor 54% gewijzigd door .oisyn op 11-07-2013 12:33 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Blijkbaar is een stapel papier een health and safety risk. Ik zit nu zonder mijn stapel papier als laptop standaard. Tijd om de AntiRSI app maar wat strenger in te stellen... Elke 20 minuten pauze...
Eerder mocht ik al geen theepot gebruiken
Eerder mocht ik al geen theepot gebruiken
Pfff, dat mijn pc hier op kantoor extreem traag is wist ik al, maar vandaag gemerkt dat 4GB ram (3,8 usable) toch wel echt te weinig is. Al keer of 4/5 gehad dat m'n WCF services niet starten omdat er <5% RAM beschikbaar is. En dat stond er echt niet zó veel open.
Helaas heb ik al wel door dat ik op korte termijn niet veel snellers/beters hoef te verwachten. Beetje jammer, maar goed, wel leuk bedrijf/project verder
Helaas heb ik al wel door dat ik op korte termijn niet veel snellers/beters hoef te verwachten. Beetje jammer, maar goed, wel leuk bedrijf/project verder
Xbox
Even the dark has a silver lining | I'm all you can imagine times infinity, times three
Die 5% threshold is in te stellen in IIS 
Server node -> Configuration Editor
Sectie: system.serviceModel/serviceHostingEnvironment
Key: minFreeMemoryPercentageToActivateService
Server node -> Configuration Editor
Sectie: system.serviceModel/serviceHostingEnvironment
Key: minFreeMemoryPercentageToActivateService
En een laptopstandaard kan niet?alienfruit schreef op donderdag 11 juli 2013 @ 12:25:
Blijkbaar is een stapel papier een health and safety risk. Ik zit nu zonder mijn stapel papier als laptop standaard. Tijd om de AntiRSI app maar wat strenger in te stellen... Elke 20 minuten pauze...
Eerder mocht ik al geen theepot gebruiken
Ja wel, geen of dat. Maar ja, dat duurt ook dagen om uit te zoeken. De meeste zijn wat te laag om het scherm op ooghoogte te krijgen.
Een dicht pak papier dan? Dat heb ik hier onder mijn monitoralienfruit schreef op donderdag 11 juli 2013 @ 12:52:
Ja wel, geen of dat. Maar ja, dat duurt ook dagen om uit te zoeken. De meeste zijn wat te laag om het scherm op ooghoogte te krijgen.
Mjah framework bedoelde ikGateKeaper schreef op donderdag 11 juli 2013 @ 12:13:
[...]
Lol.. say what? Framework bedoel je zeker? Een crossplatform ".NET omgeving"?
Draait mono ook op iOS? Dan zou je al een heel eind zijn.
[ Voor 39% gewijzigd door Ozzie op 11-07-2013 12:54 ]
"Write code as if the next maintainer is a vicious psychopath who knows where you live."
Die moest die juist weg doen 
Mwah, vind .net en java wel even wat anders.Ozzie schreef op donderdag 11 juli 2013 @ 12:53:
[...] Mjah framework bedoelde ikEen crossplatform '.NET'-omgeving bestaat al jaren. Die heet Java en bestaat al langer dan .NET zelfs
[ Voor 82% gewijzigd door Caelorum op 11-07-2013 13:01 ]
Bij shaders wel ja, maar bij enorme programma's die uit vele duizenden regels bestaan kan ik me voorstellen dat permutatie-crunchen veel te lang gaat duren. De vraag is of je een heel programma op die manier wilt optimaliseren. Een compiler kan natuurlijk moeilijk nauwkeurig bepalen welke stukken van je code het meest worden uitgevoerd en daardoor de beste kandidaten zijn voor optimalisatie..oisyn schreef op donderdag 11 juli 2013 @ 12:20:
[...]
Dat gaat lang niet altijd op. Veelal gaat het erom dat je precies de juiste permutatie van instructies pakt zodat de pipelining maximaal is en latency minimaal. Dat is niet een probleem dat met de hand en het bezit van voorkennis een stuk makkelijker op te lossen is, want het is eigenlijk gewoon een variant op het traveling salesperson problem. En een computer kan in een korte tijd veel meer mogelijkheden afgaan dan jij met de hand kan doen. Dit is vooral iets wat je terugziet in shadercompilers, die hebben vaak optimalisatiemodussen die enorm lang lopen te crunchen om uiteindelijk een zo goed mogelijke oplossing te vinden en op die manier een paar cycles te winnen. Shaders lenen zich daar natuurlijk goed voor omdat het relatief korte programmaatjes zijn die enorm veel worden aangeroepen, en daardoor goede kandidaten zijn om tot op het bot geoptimaliseerd te worden.
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Wel blijven opletten...Ozzie schreef op donderdag 11 juli 2013 @ 12:53:
Een dicht pak papier dan? Dat heb ik hier onder mijn monitor
alienfruit schreef op donderdag 11 juli 2013 @ 12:25:
Blijkbaar is een stapel papier een health and safety risk. Ik zit nu zonder mijn stapel papier als laptop standaard. Tijd om de AntiRSI app maar wat strenger in te stellen... Elke 20 minuten pauze...
Eerder mocht ik al geen theepot gebruiken
“The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.”
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers.
ik moet altijd gniffelen bij 'No damage to the environment' als oliemaatschappij, Hahahaha
Ik reageerde op je stelling dat je met de hand altijd minstens zo snel kunt zijn als wat een compiler produceert, en gaf een voorbeeld wanneer dat niet opgaat. Dat wil natuurlijk niet zeggen dat het nooit opgaatKorben schreef op donderdag 11 juli 2013 @ 12:58:
[...]
Bij shaders wel ja, maar bij enorme programma's die uit vele duizenden regels bestaan kan ik me voorstellen dat permutatie-crunchen veel te lang gaat duren. De vraag is of je een heel programma op die manier wilt optimaliseren. Een compiler kan natuurlijk moeilijk nauwkeurig bepalen welke stukken van je code het meest worden uitgevoerd en daardoor de beste kandidaten zijn voor optimalisatie.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ik dacht dat je een losse stapel papiertjes had, vandaar dicht pak
"Write code as if the next maintainer is a vicious psychopath who knows where you live."
Ik heb geen zin om een x vs java discussie te starten, maar een framework met een programmeertaal vergelijken gaat natuurlijk niet op.Ozzie schreef op donderdag 11 juli 2013 @ 12:53:
Mjah framework bedoelde ikEen crossplatform '.NET'-omgeving bestaat al jaren. Die heet Java en bestaat al langer dan .NET zelfs
Ah, maar is het wel mogelijk om even snel te zijn als een shadercompiler, als je (toevallig) de juiste combinatie en volgorde van instructies gebruikt..oisyn schreef op donderdag 11 juli 2013 @ 13:02:
[...]
Ik reageerde op je stelling dat je met de hand altijd minstens zo snel kunt zijn als wat een compiler produceert, en gaf een voorbeeld wanneer dat niet opgaat. Dat wil natuurlijk niet zeggen dat het nooit opgaat
[ Voor 10% gewijzigd door Korben op 11-07-2013 13:10 ]
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
Ik bedoelde ook niet dat Java beter/slechter is. Het bied alleen hetzelfdeGateKeaper schreef op donderdag 11 juli 2013 @ 13:08:
[...]
Ik heb geen zin om een x vs java discussie te starten, maar een framework met een programmeertaal vergelijken gaat natuurlijk niet op.
"Write code as if the next maintainer is a vicious psychopath who knows where you live."
Oh dat zal bestHoogie2004 schreef op donderdag 11 juli 2013 @ 12:50:
Die 5% threshold is in te stellen in IIS
Server node -> Configuration Editor
Sectie: system.serviceModel/serviceHostingEnvironment
Key: minFreeMemoryPercentageToActivateService
Xbox
Even the dark has a silver lining | I'm all you can imagine times infinity, times three
Verwijderd
Heb hier al veel gelezen over de ellende van Sharepoint [Alex)
] maar heb er nu dan eindelijk ook zelf mee te maken. Niet als developer maar als gebruiker, weet dus niet of het aan Sharepoint ligt of de implementatie zelf maar het is in ieder geval een draak van een applicatie


Dat die compiler dat doet is een ding, maar hij heeft zich nog steeds gewoon te houden aan bepaalde regels over (bijvoorbeeld) de datatypes die gebruikt worden. Je shader compiler mag niet ineens een float naar een half omzetten, terwijl een programmeur dat wel prima kan - mits 'ie weet wat de datarange & precisie van de waardes zijn..oisyn schreef op donderdag 11 juli 2013 @ 12:20:
Dat gaat lang niet altijd op. Veelal gaat het erom dat je precies de juiste permutatie van instructies pakt zodat de pipelining maximaal is en latency minimaal. Dat is niet een probleem dat met de hand en het bezit van voorkennis een stuk makkelijker op te lossen is, want het is eigenlijk gewoon een variant op het traveling salesperson problem. En een computer kan in een korte tijd veel meer mogelijkheden afgaan dan jij met de hand kan doen. Dit is vooral iets wat je terugziet in shadercompilers, die hebben vaak optimalisatiemodussen die enorm lang lopen te crunchen om uiteindelijk een zo goed mogelijke oplossing te vinden en op die manier een paar cycles te winnen. Shaders lenen zich daar natuurlijk goed voor omdat het relatief korte programmaatjes zijn die enorm veel worden aangeroepen, en daardoor goede kandidaten zijn om tot op het bot geoptimaliseerd te worden.
Maar goed, om even terug te komen op het begin. Dit zijn dingen waar je als native developer tegenaan kunt lopen, maar dat hoeft lang niet altijd zo te zijn. Je kunt prima op een vrij javascripterige manier je code schrijven zonder je al te veel druk te hoeven maken over het low-level gebeuren. Echter, zodra het moet, kun je het onderste uit de kan halen.
Dit wou ik er even uit pikken en op reageren.jhuiting schreef op donderdag 11 juli 2013 @ 12:01:
[...]
maar ik verwacht dat met de betere JS-engines daar binnen een jaar of 2 wel verandering in komt.
Dit kun je namelijk vergeten. Betere, lees: Snellere, JavaScript engines gaan er voorlopig niet komen. De afgelopen 10 jaar is javascript alleen maar substantieel sneller geworden vanwege Moore's law. Niet omdat er betere engines zijn.
"Bijna" verplichte leesstof: http://sealedabstract.com...mobile-web-apps-are-slow/
De programmeur kan dat echter gewoon in zijn high level programmacode aangeven, daar hoeft ie geen assembly voor te gebruiken, wat een beetje het punt van het verhaal wasPrisonerOfPain schreef op donderdag 11 juli 2013 @ 13:33:
[...]
Dat die compiler dat doet is een ding, maar hij heeft zich nog steeds gewoon te houden aan bepaalde regels over (bijvoorbeeld) de datatypes die gebruikt worden. Je shader compiler mag niet ineens een float naar een half omzetten, terwijl een programmeur dat wel prima kan - mits 'ie weet wat de datarange & precisie van de waardes zijn.
Ben je op de hoogte van het feit dat dat artikel de aanleiding was van deze hele discussie?D-Raven schreef op donderdag 11 juli 2013 @ 13:35:
"Bijna" verplichte leesstof: http://sealedabstract.com...mobile-web-apps-are-slow/
[ Voor 19% gewijzigd door .oisyn op 11-07-2013 13:37 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Haha die link startte een paar pagina's terug de discussie alD-Raven schreef op donderdag 11 juli 2013 @ 13:35:
[...]
Dit wou ik er even uit pikken en op reageren.
Dit kun je namelijk vergeten. Betere, lees: Snellere, JavaScript engines gaan er voorlopig niet komen. De afgelopen 10 jaar is javascript alleen maar substantieel sneller geworden vanwege Moore's law. Niet omdat er betere engines zijn.
"Bijna" verplichte leesstof: http://sealedabstract.com...mobile-web-apps-are-slow/
Ow, lol. Niet gezien
Gaat best hard hier af en toe
Hmm, PC-Extreme heeft mijn VPS abonnement stilzwijgend verlengd terwijl ik die eigenlijk niet meer wil hebben. Even kijken of ze lief willen meespelen en de stekker uit de VPS willen trekken (zonder te betalen natuurlijk). Als ze dat niet willen doen, dan kan ik nog even met de Wet van Dam zwaaien om in elk geval maar 1 maand te hoeven betalen (i.p.v. 3).
Niet helemaal waar, want er is de afgelopen jaren door Web 2.0 wel degelijk meer focus komen te liggen op JavaScript, waardoor het interessanter werd om tijd te besteden aan het optimaliseren van JavaScript-engines. Als je kijkt naar een V8, die voert wel degelijk heel erg veel en erg slimme optimalisaties uit, wat de engines van 5 jaar geleden zeker niet of heel veel minder deden. Door Moore's law hebben engines overigens ook meer cycles de tijd gekregen om die optimalisaties uit te voeren. Desalniettemin ben ik het met je eens dat Moore's law een belangrijke oorzaak is van het feit dat JavaScript tegenwoordig zo veel sneller is.D-Raven schreef op donderdag 11 juli 2013 @ 13:35:
[...]
Dit kun je namelijk vergeten. Betere, lees: Snellere, JavaScript engines gaan er voorlopig niet komen. De afgelopen 10 jaar is javascript alleen maar substantieel sneller geworden vanwege Moore's law. Niet omdat er betere engines zijn.
.oisyn: Échte programmeurs haten PHP met een passie. Ben jij soms geen echte programmeur?
eh lief meespelen?Aloys schreef op donderdag 11 juli 2013 @ 13:45:
Hmm, PC-Extreme heeft mijn VPS abonnement stilzwijgend verlengd terwijl ik die eigenlijk niet meer wil hebben. Even kijken of ze lief willen meespelen en de stekker uit de VPS willen trekken (zonder te betalen natuurlijk). Als ze dat niet willen doen, dan kan ik nog even met de Wet van Dam zwaaien om in elk geval maar 1 maand te hoeven betalen (i.p.v. 3).
Ze doen niets verkeerd, dat verlengen mag ook en daarmee mag jij hem nu sowieso met een doorlooptijd van 1 maand je VPS op zeggen. In feite moet je hem nu opzeggen, 1x nog betalen en klaar.
Daar hoef je echt niet moeilijk over te doen.
Dat is waar, maar ik ben natuurlijk niet op de hoogste gesteld van de verlenging. Het is veel fijner vanuit het bedrijf als ze mij voortijdig laten betalen (zoals TransIPCloupdVPS) en daarna verlengen. Uiteraard hoeven ze hier niet aan mee te werken, maar dan ga ik mijn factuur voor 3 maanden niet betalen en wil ik een factuur voor 1 maand.
Edit: Uiteraard is het eerste deel een kul argument
Edit: Uiteraard is het eerste deel een kul argument
[ Voor 10% gewijzigd door Aloys op 11-07-2013 14:21 ]
Ik snap heel je punt niet hoor. Jij wilt iets en betaald hier voor. Als je dit niet meer wilt, dan moet je hem opzeggen wanneer dit kan. Dat ze je dienst verlengen is meer dan logisch, en eigenlijk ook niet raar dat ze dit verzwijgen. Waarom je transip er nu bij haalt snap ik ook niet precies. In feite doen hun precies het zelfde.Aloys schreef op donderdag 11 juli 2013 @ 13:51:
Dat is waar, maar ik ben natuurlijk niet op de hoogste gesteld van de verlenging. Het is veel fijner vanuit het bedrijf als ze mij voortijdig laten betalen (zoals TransIP) en daarna verlengen. Uiteraard hoeven ze hier niet aan mee te werken, maar dan ga ik mijn factuur voor 3 maanden niet betalen en wil ik een factuur voor 1 maand.
Mijn dienst heb ik daar lopen, en er zit in feite dan een "verlengdatum" aan. Dat betekend gewoon dat alles doorgaat, inclusief betaling. Mocht ik het willen opzeggen dan dien ik alsnog op die verlengdatum het bedrag te betalen en vervolgens is de volgende datum het einde van mijn dienst.

De rede dat jij per 3 maanden moet betalen weet ik niet. Wellicht heb je een bepaalde "deal" dat je hiermee korting krijgt. In elk geval als ze de dienst hebben verlengt dan mag het sowieso niet voor een bepaalde tijd zijn. Hierbij denk ik dan ook dat jij wellicht toch voor iets meer hebt getekend misschien, of het is gewoon een foutje. Echter kun je ze gewoon vermelden dat je de dienst wilt stoppen.
Stilzwijgende verlenging mag je gewoon opzeggen per maand volgens de Wet van Dam. Daarnaast haal ik er onterecht TransIP bij, dat klopt (had CloudVPS moeten zijn, nog steeds eigenlijk niet relevant). Ik wilde gewoon proberen of ze coulant zijn en anders dan kan ik de Wet van Dam er bij halen en voor 1 maand betalen i.p.v. 3.
Haha wat prachtig, een erg goede analogie over waarom software-ontwikkeling vaak veel langer duurt dan gezegd wordt:
http://www.quora.com/Engi...el-Wolfe?srid=24b&share=1
http://www.quora.com/Engi...el-Wolfe?srid=24b&share=1
Wel handig om eens aan je baas e.d. te laten zien.Sh4wn schreef op donderdag 11 juli 2013 @ 14:20:
Haha wat prachtig, een erg goede analogie over waarom software-ontwikkeling vaak veel langer duurt dan gezegd wordt:
http://www.quora.com/Engi...el-Wolfe?srid=24b&share=1
Ikzelf heb eigenlijk nooit problemen met mijn planning.
Ik vul dingen meestal ruim in, en vervolgens gooi ik er gemiddeld per "stukje" (lees: feature) daar nog eens 20% bovenop, en vervolgens in het totaal voeg ik nog eens 20% uitloop toe. Zo heb ik in feite 40% uitloop, waarvan men er maar 20% van ziet
Uiteindelijk ben ik altijd op tijd met mijn planning, vaak gezien een paar dagen eerder.
Men moet gewoon leren om fatsoenlijke planningen te maken, en na 5 jaar+ ervaring weet je onderhand echt wel wat reëel is, en door je ervaring ga je echt niet strikt 2 uur neerzetten voor 2 uur werk, maar maak je er 4 van, want uiteindelijk red je die 2 uur toch letterlijk nooit.
Juist die 40% uitloop die je bij plant is een probleem voor managers. zeker als dan blijkt dat je telkens eerder klaar bent. ergens is er dan nog steeds iets mis met je planning alleen de andere kant op.
Geweldig!Sh4wn schreef op donderdag 11 juli 2013 @ 14:20:
Haha wat prachtig, een erg goede analogie over waarom software-ontwikkeling vaak veel langer duurt dan gezegd wordt:
http://www.quora.com/Engi...el-Wolfe?srid=24b&share=1
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Als je een planning hebt van 5 weken, en je bent een paar dagen (2-3) eerder klaar dan hoor je hier niemand over hoor. Dan ben ik gewoon op tijd en alles is prima.Ealanrian schreef op donderdag 11 juli 2013 @ 14:27:
Juist die 40% uitloop die je bij plant is een probleem voor managers. zeker als dan blijkt dat je telkens eerder klaar bent. ergens is er dan nog steeds iets mis met je planning alleen de andere kant op.
Je maakt een planning om juist te plannen, wat nou als ik die 40% weg laat, dan klopt er in feite dus geen ruk van je planning meer. Technisch gezien, als er letterlijk niets fout zou gaan, en er niets tussendoor zou komen dan kun je die 40% weg laten. Echter is een uitloop van 20% sowieso al niet apart, echter gooi ik er nog 20% bij vanwege mijn ervaring met bepaalde projecten.
Je kunt imo beter een realistische planning maken en van te voren een *zucht* horen in de trend van "goh wat lang", in plaats van een scheldkanonnade achteraf.
overigens heb ik geen manager(s), maar een "hoofd".
[ Voor 3% gewijzigd door Douweegbertje op 11-07-2013 14:50 ]
Denk dat de meeste van ons daar wel over beschikken. Het functioneren zal echter van persoon tot persoon verschillen.douweegbertje schreef op donderdag 11 juli 2013 @ 14:49:
[...]
overigens heb ik geen manager(s), maar een "hoofd".Dit werkt prima!
Programma waar ik al even aan werk crasht ineens met:
Geen stacktrace erbij en laatste wijzigingen terugdraaien tot toen het wel werkte helpt ook niet.. Dan maar met breakpoints gaan zoeken waar het gebeurt
Fijn hoor, daar heb ik wat aanA first chance exception of type 'System.InvalidOperationException' occurred in Unknown Module.

Gewoon instellen dat hij meteen breakt als er een exceptie gethrowed wordt, dan heb je toch meteen de locatie gevonden. Dan hoef je alleen nog maar de oorzaak te achterhalen.Radiant schreef op donderdag 11 juli 2013 @ 15:15:
Programma waar ik al even aan werk crasht ineens met:
[...]
Fijn hoor, daar heb ik wat aanGeen stacktrace erbij en laatste wijzigingen terugdraaien tot toen het wel werkte helpt ook niet.. Dan maar met breakpoints gaan zoeken waar het gebeurt
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Tja maar beschikbaar zijn en er bruikbare apps in kunnen bouwen zijn wel twee verschillende dingen. Je kan C / C++ hooguit inzetten voor een library met common functionality maar ook dat valt niet mee. Dus onzin argument?[b]PrisonerOfPain schreef op donderdag 11 juli 2013 @ 12:03:
Weer een onzin argument, zowel C als C++ zijn op ieder platform beschikbaar. Waar denk je dat die javascript interpreters/JITs in geschreven zijn?

Weet je wat? Je hebt helemaal gelijk! C++ is zó verschrikkelijk onbruikbaar als cross-platform taal. Je hebt me het licht laten zien hoor. Ik zal het ze hier doorgeven, doen we heel de codebase opnieuw in Javascript.jhuiting schreef op donderdag 11 juli 2013 @ 15:26:
[...]
Tja maar beschikbaar zijn en er bruikbare apps in kunnen bouwen zijn wel twee verschillende dingen. Je kan C / C++ hooguit inzetten voor een library met common functionality maar ook dat valt niet mee. Dus onzin argument?
Nvm, volgens mij ben je een compleet andere discussie aan het voeren. Ik heb het over de context van mobiele apparaten, voor de meeste applicaties waarbij ik expliciet zeg dat het niet opgaat voor games...PrisonerOfPain schreef op donderdag 11 juli 2013 @ 15:31:
Weet je wat? Je hebt helemaal gelijk! C++ is zó verschrikkelijk onbruikbaar als cross-platform taal. Je hebt me het licht laten zien hoor. Ik zal het ze hier doorgeven, doen we heel de codebase opnieuw in Javascript.
Precies, veel handiger toch.PrisonerOfPain schreef op donderdag 11 juli 2013 @ 15:31:
[...]
Weet je wat? Je hebt helemaal gelijk! C++ is zó verschrikkelijk onbruikbaar als cross-platform taal. Je hebt me het licht laten zien hoor. Ik zal het ze hier doorgeven, doen we heel de codebase opnieuw in Javascript.

Bovendien weet ik nog een mooier plekje voor Javascript, vervang de GLSL shaders maar door javascript, veel duidelijker. Performance is toch niet belangrijk, want je neemt gewoon een snellere videokaart
Edit: Whut?! https://github.com/gre/glsl.js

[ Voor 3% gewijzigd door Aloys op 11-07-2013 15:39 ]
Jij hebt een Status 418?alienfruit schreef op donderdag 11 juli 2013 @ 12:25:
Blijkbaar is een stapel papier een health and safety risk. Ik zit nu zonder mijn stapel papier als laptop standaard. Tijd om de AntiRSI app maar wat strenger in te stellen... Elke 20 minuten pauze...
Eerder mocht ik al geen theepot gebruiken
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Maar... juist op mobiel wil je juist lief omgaan met de batterij van de gebruiker. Als je de discussie over mobile voert, voer je daarom inherent een discussie over performance. Ik snap je punt kwa mobile ook niet helemaal verder, alle iOS apps zijn op het moment al native en blijkbaar is dat prima te doen. Waarom zou je dat zo nodig in Javascript willen doen?jhuiting schreef op donderdag 11 juli 2013 @ 15:35:
[...]
Nvm, volgens mij ben je een compleet andere discussie aan het voeren. Ik heb het over de context van mobiele apparaten, voor de meeste applicaties waarbij ik expliciet zeg dat het niet opgaat voor games...
Omdat het een stuk eenvoudiger en sneller is om een simpele "app" (lees mobiele website) in html + js te bouwen, en die via iets als phonegap naar alle devices te pushen.PrisonerOfPain schreef op donderdag 11 juli 2013 @ 15:42:
[...]
Waarom zou je dat zo nodig in Javascript willen doen?
Dat het goed te doen is ben ik het mee eens, maar het kost nu teveel tijd om relatief simpele apps te ontwikkelen voor alle platformen. Mijn punt was dat deze apps in de toekomst (in mijn optiek) met Javascript gebouwd zullen worden en dat dat prima te doen is qua performance en batterij. Voor de high-performance zaken zoals geavanceerde apps en games blijf je inderdaad bij native, dat zie ik voorlopig niet veranderen.PrisonerOfPain schreef op donderdag 11 juli 2013 @ 15:42:
Maar... juist op mobiel wil je juist lief omgaan met de batterij van de gebruiker. Als je de discussie over mobile voert, voer je daarom inherent een discussie over performance. Ik snap je punt kwa mobile ook niet helemaal verder, alle iOS apps zijn op het moment al native en blijkbaar is dat prima te doen. Waarom zou je dat zo nodig in Javascript willen doen?
-edit- Ik ben het trouwens niet eens met hierboven dat Phonegap daar een oplossing is, dat is momenteel echt nog te traag om heel bruikbaar te zijn. Ik denk dat Sencha achtige tooling dan eerder een oplossing is, ook al moet daar nog veel aan gebeuren.
[ Voor 12% gewijzigd door curvemod op 11-07-2013 15:50 ]
Neem ook ChromeOS. Google adverteert veel voor hun ChromeBooks. Volgens mij zijn de apps daarvoor alleen in javascript.
En je hebt nu natuurlijk ook Firefox OS, die doen alles al in JavascriptDaos schreef op donderdag 11 juli 2013 @ 15:49:
Neem ook ChromeOS. Google adverteert veel voor hun ChromeBooks. Volgens mij zijn de apps daarvoor alleen in javascript.
Mja, dat heb ik uiteraard aan staan, maar dan krijg je alleen dat grijze vakje met een exception erin zonder dat ie een sourceregel aanwijst of het stacktraceschermpje vult. Kennelijk wordt de exception gegooid in een stukje .NET Framework-code waar ik niet in kan kijken en de PDB-files van die module staan precies weer niet op de reference source server van MS.. Heb ik weerWoy schreef op donderdag 11 juli 2013 @ 15:23:
[...]
Gewoon instellen dat hij meteen breakt als er een exceptie gethrowed wordt, dan heb je toch meteen de locatie gevonden. Dan hoef je alleen nog maar de oorzaak te achterhalen.
Omdat je bij een interpreted taal niet afhankelijk bent van de onderliggende hardware. Een ecosysteem waarbij devices uit verschillende soorten hardware kunnen bestaan betekent dat je je 'app' voor alle architecturen moet gaan compilen. Android doet dit bijvoorbeeld, dus het is zeker wel te doen, maar ik kan me voorstellen dat het voor sommige doeleinden niet een ideale oplossing is.PrisonerOfPain schreef op donderdag 11 juli 2013 @ 15:42:
[...]
Maar... juist op mobiel wil je juist lief omgaan met de batterij van de gebruiker. Als je de discussie over mobile voert, voer je daarom inherent een discussie over performance. Ik snap je punt kwa mobile ook niet helemaal verder, alle iOS apps zijn op het moment al native en blijkbaar is dat prima te doen. Waarom zou je dat zo nodig in Javascript willen doen?
Hoera, net een maand aan wereldwijde vluchtdata gedownload en geparsed. M'n visualisatie draait nog heel aardig (30-40 FPS), al is dat wel op een GTX690.
Als het je business is heb je gewoon een build server lopen die die versies bij elkaar compiled.EddoH schreef op donderdag 11 juli 2013 @ 15:56:
[...]
Omdat je bij een interpreted taal niet afhankelijk bent van de onderliggende hardware. Een ecosysteem waarbij devices uit verschillende soorten hardware kunnen bestaan betekent dat je je 'app' voor alle architecturen moet gaan compilen. Android doet dit bijvoorbeeld, dus het is zeker wel te doen, maar ik kan me voorstellen dat het voor sommige doeleinden niet een ideale oplossing is.
Ik krijg de indruk dat het eerder een infrastructuur probleem is dan dat het een native probleem is.
In C en C++ ben je ook niet noemenswaardig afhankelijk van onderliggende hardware. De tijd van wazige 18 bits CPU's (ik noem maar wat) zijn wel al lang en breed voorbij.EddoH schreef op donderdag 11 juli 2013 @ 15:56:
[...]
Omdat je bij een interpreted taal niet afhankelijk bent van de onderliggende hardware.
Nou boo fucking hoo. Compilen is nou echt niet het probleem als je je app wil pushen naar meerdere devices. 2 minuten werkEen ecosysteem waarbij devices uit verschillende soorten hardware kunnen bestaan betekent dat je je 'app' voor alle architecturen moet gaan compilen.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
voor de lulz of heeft het nog een doel? Post eens een screenIntru schreef op donderdag 11 juli 2013 @ 16:00:
Hoera, net een maand aan wereldwijde vluchtdata gedownload en geparsed. M'n visualisatie draait nog heel aardig (30-40 FPS), al is dat wel op een GTX690.
Rustig dames, ik wilde alleen argument geven wat nog wat hout snijdt om voor een interpreted taal te kiezen 
Overal is een oplossing voor en natuurlijk kun je voor elk systeem compilen, en nee dat gaat niet altijd veel tijd kosten etc. Echter, voor een ecosysteem waarin je een generieke interface voor 'apps' wil bieden waar je niet teveel details over de onderlaag wilt of kunt geven, waar veiligheid en makkelijk programmeren belangrijker is dan pure performance, dan KAN een interpreted taal een betere oplossing zijn.
Overal is een oplossing voor en natuurlijk kun je voor elk systeem compilen, en nee dat gaat niet altijd veel tijd kosten etc. Echter, voor een ecosysteem waarin je een generieke interface voor 'apps' wil bieden waar je niet teveel details over de onderlaag wilt of kunt geven, waar veiligheid en makkelijk programmeren belangrijker is dan pure performance, dan KAN een interpreted taal een betere oplossing zijn.
Arm v4, ARM v5, x86, Soft/hw fpu, 64/32 bit, BE,LE, als je dan toch voor optimale performance gaat dien je deze dingen ook mee te nemen..oisyn schreef op donderdag 11 juli 2013 @ 16:02:
[...]
Nou boo fucking hoo. Compilen is nou echt niet het probleem als je je app wil pushen naar meerdere devices. 2 minuten werk. De echte hurdle is het feit dat je voor elk apparaat specifieke code moet gaan schrijven. Aan de andere kant wil je dat bijna toch wel zodat je voldoet aan de look&feel van het systeem zelf.
Heb je ook al de rebuttal van brandon live gelezen?D-Raven schreef op donderdag 11 juli 2013 @ 13:35:
[...]
"Bijna" verplichte leesstof: http://sealedabstract.com...mobile-web-apps-are-slow/
What Drew should call his post
I think a better title would be: “Reminder that JS is crippled on iOS.” Or something along those lines. Yup. It is. But don’t blame JavaScript. Blame Apple. They don’t want you to use JavaScript because then your code would be more portable. And that’s the last thing they want!
[ Voor 33% gewijzigd door Grijze Vos op 11-07-2013 16:10 ]
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
90% Van de code die je schrijft in dit soort situaties is compleet platform onafhankelijk. In de meeste gevallen hoef je je hier net zo min druk over te maken als bij een interpreted taal, het punt is dat zodra het er toe doet je je er druk over kunt maken.EddoH schreef op donderdag 11 juli 2013 @ 16:09:
[...]
Arm v4, ARM v5, x86, Soft/hw fpu, 64/32 bit, BE,LE, als je dan toch voor optimale performance gaat dien je deze dingen ook mee te nemen.
Hoe groot is zo'n dataset dan? Moet ik denken aan duizenden vluchten live visualiseren of honderdduizenden? Wel tof natuurlijkIntru schreef op donderdag 11 juli 2013 @ 16:00:
Hoera, net een maand aan wereldwijde vluchtdata gedownload en geparsed. M'n visualisatie draait nog heel aardig (30-40 FPS), al is dat wel op een GTX690.
Ja, het is voor m'n scriptie (denk maar niet dat ik een GTX690 thuis heb voor de lol). Het is overigens allemaal geschreven in Python, maar de performance bottleneck zit hem toch volledig in de GLSL shaders.douweegbertje schreef op donderdag 11 juli 2013 @ 16:06:
[...]
voor de lulz of heeft het nog een doel? Post eens een screen
En hier een plaatje:

Dit is ongeveer 16 uur aan geaggregeerde data boven de USA
Ongeveer 20.000 vluchtenAloys schreef op donderdag 11 juli 2013 @ 16:16:
Hoe groot is zo'n dataset dan? Moet ik denken aan duizenden vluchten live visualiseren of honderdduizenden? Wel tof natuurlijk.
[ Voor 19% gewijzigd door Intru op 11-07-2013 16:19 ]
Lekker belangrijk of het Javascript of native is. Het grootste probleem is dat webapps het gewoon nooit net niet zijn qua UI en/of user experience. De UI nabootsen in een webapp werken gewoon nooit hetzelfde als de UI components van het OS.
Fixedalienfruit schreef op donderdag 11 juli 2013 @ 16:20:
Lekker belangrijk of het Javascript of native is. Het grootste probleem is dat webapps het gewoon nooit altijd net niet zijn qua UI en/of user experience. De UI nabootsen in een webapp werken gewoon nooit hetzelfde als de UI components van het OS.
Ik heb zojuist 1 van mijn grootste irritaties bij anderen zelf ook gedaan...
Een upgrade met als commentaar
Een upgrade met als commentaar
Small improvements and some bugfixes
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Chrome Native ClientDaos schreef op donderdag 11 juli 2013 @ 15:49:
Neem ook ChromeOS. Google adverteert veel voor hun ChromeBooks. Volgens mij zijn de apps daarvoor alleen in javascript.

We are shaping the future
Dit topic is gesloten.
Let op:
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.