Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Hobbyist maakt speelbare versie van Civilization in Excel

Een knappe kop heeft een simpele versie van strategiegame Civilization ontwikkeld die speelbaar is in Excel. Het spel heeft een 1v1-modus voor twee spelers en is al werkend. Bovendien is het Excel-bestand gratis te downloaden.

[Cell]ivization is gemaakt door 's0lly', die onlangs versie 1.0 van het spel gratis beschikbaar heeft gesteld. Hij deed dit om mee te doen aan de OLC Codejam 2019. Het thema van deze wedstrijd is dit jaar 'destructie'. "Dat is toepasselijk, want de enige manier om te winnen in [Cell]ivization is door het andere team te vernietigen", schrijft s0lly.

Het Excel-spel mist nog wel de nodige features. Momenteel ondersteunt het alleen een simpele deathmatch-modus voor twee spelers. De spelers bewegen daarbij hun eenheden met de wasd-toetsen. Spelers moeten wel even geduld hebben, want het duurt enkele seconden voordat de bewegingen worden doorgevoerd.

In de toekomst zal s0lly nog artificiële intelligentie toevoegen. Momenteel kun je alleen uit de voeten met een andere, menselijke tegenstander. Daarnaast worden in de toekomst verschillende beschavingen verwacht. Ook staan er andere functies in de planning, waaronder diplomatie, wetenschap en nieuwe grondstoffen. Op dit moment kunnen spelers nog geen grondstoffen bezitten.

Bovendien bevat de game nog de nodige bugs. Zo breekt het spel als er geen units meer aanwezig zijn. Daarnaast loopt het vast als een unit geen kant meer op kan. De game is dan ook zeker geen vervanger voor Civilization 5 en 6.

[Cell]ivization is niet het eerste spel dat volledig in Excel is gemaakt. De spreadsheetsoftware ondersteunt Visual Basic, Adobe flash en macro's, waarmee prima games kunnen worden gemaakt. Verschillende knappe koppen maakten eerder al speelbare versies van bijvoorbeeld Monopoly, puzzelspel 2048, Flappy Bird, Angry Birds en XCOM. De games zijn niet zozeer als volwaardige games bedoeld, maar eerder als klein tijdverdrijf. Daarnaast staat Excel natuurlijk op vrijwel elk workstation. Kantoormensen kunnen dus vrij gemakkelijk stiekem een potje Flappy Bird spelen.

Door Daan van Monsjou

Stagiair nieuwsredactie

09-09-2019 • 15:50

94 Linkedin Google+

Reacties (94)

Wijzig sortering
Voor de mensen die hierdoor geïnspireerd worden: de maker heeft op Reddit aangekondigd een tutorial te maken over hoe je games kunt ontwikkelen in excel (+vba).

https://www.reddit.com/r/...ing_a_civ1_clone_in_excel
Wat een madlad. fascinerend hoe veel je met Excel kan doen.
Ik zag laatst een YT video van ray-tracing in Excel
Fun fact: Excel ondersteunt geen multi-threading.

Lees dat nog eens een keertje goed...

GEEN MULTI-THREADING.

Er zijn workarounds voor (door bijv. meerdere instanties van excel te openen in de achtergrond om parallel berekeningen uit te voeren) maar de fucking native applicatie ondersteunt het gewoon niet.

Écht bizar.. ik snap er geen drol van.

Tof overigens hoor dit! Maar met hetzelfde gemak had hij dit ook gewoon in VB.NET kunnen doen.. de meerwaarde van Excel gebruiken is er gewoon niet behalve dan misschien dat je eindigt met een .xlsm in plaats van een .exe (whoopty doo!) :+

Overigens moet ik wel toegeven dat VBA wel echt iets heel erg tofs is.
Je kunt vanuit Excel of Word gewoon een verbinding maken met een SQL/Access database en daar queries tegenaan gooien om data op te slaan/uit te lezen.. en VBA is 'volwaardig' genoeg als programmeer taal dat je er eigenlijk praktisch alles wel mee kan.. zolang het niet te intensief is vanwege beperkingen zoals het gebrek aan multi-threading. :+

Het is handig om gewoon een Excel bestand of zo te kunnen maken met een 'programma' erachter dat nuttige dingen doet.. al moet je goed beseffen dat je relatief snel op het punt komt dat het wellicht beter zou zijn om een volwaardige programmeertaal te gebruiken (bijv. VB.NET wat kwa taal sterk overeenkomt met VBA).

(p.s. 'VBA' staat voor 'Visual Basic for Applications', en het is in principe Visual Basic ingebouwd in alle Microsoft Office applicaties zoals Excel, Word, Access).

VBA in zoiets als Excel is echter wel een hele mooie 'instap' plek voor beginnende programmeurs die snel resultaat willen en ik zou de leercurve dan ook als vrij laag bestempelen.

[Reactie gewijzigd door Ayporos op 9 september 2019 16:08]

Ik weet niet precies wat [Cell]ivization doet, maar de raytracing example gebruikt VBA alleen voor de toetsinput. het raytracen zelf wordt puur door excel formules gedaan.
Mja.. en die excel formules worden dus NIET parallel berekend.. tenzij dat hij dus in de achtergrond 'worker threads' genereert door meerdere instanties van Excel te openen.
Tenzij die formules on the fly gegenereerd worden door VBA, worden excel formules wel degelijk parallel berekend.
Multithreading is best ingewikkeld, ik zou het knapper vinden als hij dat wél had ingezet.

Vroeger had men ook geen multithreaden, daar werd en meerdere processen 'tegelijk' (althans, die indruk moest het wekken) door 'concurrent' programmeermodellen. Dat is de manier om dit soor projecten aan te lopen.

Persoonlijk ben ik wel fan van dit soort projecten trouwens. Specificaties oprekken zo ver als je kan. CodeGolf is ook een leuke stack subsite om te zoeken naar dit soort pareltjes. :)
Vroeger had men veel niet, waardoor programma's veel efficienter werden ontwikkeld en elke beschikbare byte werd gebruikt en geoptimaliseerd. Als je kijkt hoe er nou wordt ontwikkeld, dan is het huilen met de pet op.
Vroeger had men veel niet, waardoor programma's veel efficienter werden ontwikkeld en elke beschikbare byte werd gebruikt en geoptimaliseerd. Als je kijkt hoe er nou wordt ontwikkeld, dan is het huilen met de pet op.
Vroeger had men ook veel wel: memory leaks, buffer overflows, stack overflows en noem maar op. Mede met de opkomst van het internet is beveiliging in software veel belangrijker geworden, en omdat het risico op een vergetelheid in een taal als C nu eenmaal redelijk groot is, hebben complexere talen als C++, Java en .NET allemaal zaken ingebakken om die risico's te beperken of in de meeste gevallen volledig te vermijden. Maar dat kost nu eenmaal geheugen en processorkracht. Al heeft men in deze tijden meestal liever wat meer geheugen- of CPU verbruik dan een programma waarin zich na een dag 10 virussen genesteld hebben (OK, ik overdrijf wat).

Wat ook meespeelt is dat programmeurs duur zijn, waardoor men soms liever een extra server huurt in plaats van X% van de tijd van de programmeur kwijt te zijn voor optimalisaties in de code (dat is dan een economische keuze). Vroeger was dat minder mogelijk omdat de beperkte hardware die keuze niet toeliet. Toen moest men wel optimaliseren.
Dat laatste vind ik een goed punt van je; hardware is veel en veel goedkoper dan een programmeur. Wanneer je een programma wil versnellen, dan kost je dat veel tijd en veel bugs. Dat is een veel pijnlijker proces dan er een snellere server tegenaan gooien.
Kromme gedachtengang, en een die kostbaar is. Ja, die programmeur kost geld. Maar die hardware ook. En met meer hardware komen er allerlei licentievoorwaarden ineens naar voren waardoor die server al gauw 30.000 euro per jaar meer kost, puur en alleen omdat je van 1 model processor naar een andere bent overgestapt.

Dan is er ook nog eens het hogere energie verbruik, het vervroegd afschrijven van server hardware en aanschaf van nieuwe server hardware (welke moet passen in de lege ruimte in je rack(s) die je oude server achterlaat. Met al die extra (jaarlijks terugkerende) kosten, kun je een junior programmeur een jaar laten stoeien met optimalisaties.

Meer hardware tegen een probleem aangooien, dat getuigt van een luiheid in denken. Dat wil dus niet zeggen dat het een slechte oplossing is. Het is alleen een flink stuk duurder dan de meeste mensen denken.

Ploeg voor de lol eens door de licentie voorwaarden van database software als Oracle, IBM's DB2 of zelfs SQL Server en hou je hart vast voor de bedragen die gepaard gaan met betere/snellere/meer hardware.

Daarna spreken we nog wel eens.
Dat laatste vind ik een goed punt van je; hardware is veel en veel goedkoper dan een programmeur. Wanneer je een programma wil versnellen, dan kost je dat veel tijd en veel bugs. Dat is een veel pijnlijker proces dan er een snellere server tegenaan gooien.
Hangt heel erg sterk van je beginsituatie af... Als die al goed geoptimaliseerd is, ja dan kan je beter hardware ertegenaan gooien.

Alleen in de praktijk zie ik bijna dagelijks totaal ongeoptimaliseerde dingen voorbij komen waarbij het enkel vervangen van een list door een hashset al snel 1000x versnelling aanbrengt. Net zoals het zonder index benaderen van een database, dat versnel je ook al snel met een factor 1000 door even een index aan te brengen.

En tegen dat soort simpele optimalisaties kan jij geen hardware aanschaffen die ook maar enigszins in de buurt komt hoor.
Met hardware mag je blij zijn als je 2 tot 5x versnelling haalt, de rest moet je toch echt uit je code halen.
Met C# compileer je ook gewoon naar machine code. Er is dan wel een IL, maar tot voor kort kon je ML code meeleveren die via NGEN gegenereert zijn. Ik zie dan ook niet zozeer in waarom je beweert dat C# onder doet voor C als je op kleine stukken kijkt. Door klasse barrieres heenprikken met optimilisatie is nog steeds een probleem voor de meeste compilers, maar dat ligt aan de compilers niet aan wat er mogelijk is.

Daarnaast kan je ook gewoon in C# bijv. bytecode tables gebruiken om stukken te versnellen, maar toch doet dit vrijwel niemand.

Overigens heb je in C legio tools om dat soort fouten tegen te gaan.
Het is waar dat beperkingen meer creativiteit in de ontwikkelaars naar boven haalt, maar voor veel applicaties maakt het geen drol uit of ze efficiënt draaien of niet; onderhoudbaarheid is vaak veel belangrijker.

ps leuke avatar heb je trouwens :+
Dit, inderdaad.
Vroeger moest elke bit optimaal gebruikt worden (want je betaalde voor je compile-tijd, en geheugen en CPU power waren gewoon reteduur), dan zijn we richting 'gooi er maar wat tegenaan' gegaan, en nu we terug naar het 'betalen voor wat je gebruikt' gaan (Cloud) gaan we weer best richting 'lean and mean'.
Mwah. Ik zie juist dat men in de cloud veel meer richting optimized performance gaat, omdat je daar juist dik mee kunt besparen. waarbij je on-premise bijna geen kostenreductie hebt in 10% performance increase (je betaald nog steeds voor de aangevraagde machine) heb je in de cloud direct 1-op-1 die kostenreductie door het pay-per-use model.
.... dat...zeg ik toch net? "lean and mean".
Lean&mean is juist niet per se performance optimized.

Lean&mean is make it work, make it pretty en we zien wel wanneer de performance niet meer toereikend is.
What does Lean Programming mean?
Lean programming is methodology focusing on optimizing efficiency and minimizing the waste of software applications during their design and creation.
https://www.techopedia.com/definition/13647/lean-programming
|:(

[Reactie gewijzigd door Tokkes op 10 september 2019 16:10]

Probeer voor de lol eens 50 verschillende Excel instanties te openen. Voor normaal gebruik is dat excessief, voor back-end software is dat meer dan bittere noodzaak. Dat heb ik 1 keer veeor elkaar gekregen in de tijd van XP en na een heleboel geklooi met geheugenbeheer van Windows.

Zowiezo geen aanrader.

Die mogelijkheden om te klooien met geheugenbeheer heeft MS er sinds Vista al uitgesloopt, nu mag je al blij zijn als je 25 instanties haalt. Maakt niet uit hoeveel RAM en CPu's er in je server zijn gebouwd, Windows heeft niet genoeg heap-memory beschikbaar. En je Windows server word er merkbaar slomer door.

Excel is een stuk afval met een heleboel "technische schuld".
Ik vraag mij oprecht af waarom je Excel überhaupt op een server (backend) zou willen draaien.
Wij hebben een order-inlees-module, die orders uit de mail haalt, analyseert en in de database zet. Een groot aantal van die orders worden aangeleverd via Excel. Op de server hebben we dan ook Excel draaien, die door dat proces wordt gestart om de order te kunnen bewaren als csv file, waarna we hem gemakkelijker kunnen inlezen in de backend-programmatuur om hem verder te analyseren.

Dus ja, daarom zou je Excel op de server kunnen willen draaien.
Dan kun je toch beter gewoon de XLS(X) parsen? Excel op de backend draaien om een bestand te converter is echt bizar...
Gewoon de XLS parsen? Waarom zou ik dat in hemelsnaam doen als ik Excel kan starten. En hoezo is een XLS parsen ineens "gewoon"? Is dat überhaupt met enig fatsoen te parsen? We hebben 1 instance op de server die dat lachend verwerkt (als in: met twee vingers in de neus). Ik zie het probleem niet.
Voor het parsen van XLS zijn legio libraries die het je gemakkelijk maken. Als je het bizarre aan een full blown desktop applicatie starten op de server voor alleen het converteren van een bestand niet ziet dan, tja...

Ik denk aan: schaalbaarheid, memory/resource usage, platform onafhankelijkheid, onderhoudbaarheid, foutafhandeling, data validatie, uitbreidbaarheid, etc
Een (geunzipte) XLSX is heel goed te parsen omdat je hiervoor van 3e partijen afhankelijk bent. Als de orders simpel en gestructureerd zijn kan je zelf een lexical scanner bouwen.

Dan moet je zoiets scannen:
<sheetData>
<row r="1" spans="1:3" x14ac:dyDescent="0.25"><c r="A1" t="s"><v>0</v></c></row>
<row r="2" spans="1:3" x14ac:dyDescent="0.25"><c r="A2"><f>SUM(B2+C2)</f><v>0</v></c></row>
<row r="3" spans="1:3" x14ac:dyDescent="0.25"><c r="A3"><f>SUM(B3+C3)</f><v>3</v></c><c r="B3"><v>1</v></c><c r="C3"><v>2</v></c></row>
</sheetData>
Je kan ook de xls naar csv converten via code zonder excel.

https://github.com/dfinke/ImportExcel bijvoorbeeld

Excel op je server draaien is altijd een band-aid , al was het enkel al maar puur licentietechnisch gezien.
Aspose.Cells maakt je leven makkelijker en je platform een stuk stabieler.
Epplus is gratis. Heb ik al op verschillende projecten gebruikt en ben er best tevreden van.
En dan heb je er 50 nodig omdat?

C# VSTO:
- Open
- Convert
- Save
- Loop

Multithreaded, dus 8 tegelijk (4 cores zonder HT).
Nee, nee, nee, wij gebruiken er maar 1, zeker geen 50. Ik zie zo ook geen use-case daarvoor.
Wanneer je server software hebt draaien, welke gevoed worden door excel bestanden (want dat is wat de consultant kent) is dat op zich geen probleem. Wanneer het wel een probleem word is dat er duizenden van zulke processen moeten draaien, 24 uur per dag, 7 dagen in de week.

De server van een klant met 64 Xeon processoren en 64TByte aan RAM kan niet meer Excel tegelijkertijd instances draaien (want elk proces opent een aparte Excel instance) dan mijn 4GByte XP machine destijds.

Dat bedrijf had een fortuin geinvesteerd in dat systeem (energie leverancier die meerdere markten in Europa bedient) en was dus serieus kwaad over dit feit. Wij niet voorzien, want wie doet zulke dingen nou tenslotte.

Nou, dat werd dus al snel duidelijk dat dit bedrijf dus heel veel Excel-kneuzen in dienst had en/of inhuurde (over heel Europa).

Als oplossing werd een ander onderdeel van het pakket wat die business processen af moest handelen zodanig aangepast dat deze de meeste functionaliteit van Excel herbergt, beter te scripten is en als Windows service kon draaien.

Consultants ook ingelicht en via cursussen/studie leveren ze nu hun materiaal aan via die Excel kloon, die wel met duizenden tegelijkertijd verwerkt kunnen worden. En voor de echte "die-hard" Excel-lert, ook maar een scriptbare "vertaler" van Excel naar CSV en vice-versa als script commandos toegevoegd.

Dat was een "interessant" kwartaal. Uiteindelijk een compliment van de CEO zelf gekregen, omdat ze nu wel een oplossing hebben die schaalt en sneller werkt dan die Excel meuk.

Excel is wel degelijk afval met een hoop "technische schuld". Misschien dat ik je er niet van overtuig via mijn posts. En dat is niet erg. Betekent niet dat het niet waar is.
Dank voor je verhaal, lijkt me inderdaad een "interessant" traject.

Ik geloof graag dat Excel afval is met een leuke UI, het pakket is dan ook al erg oud en sleept jaren aan geschiedenis met zich mee. Het punt is dat er bij ons 1 proces met enige regelmaat XLS / XLSX bestanden uit de mail omzet naar csv. De server is overbemeten, het proces draait om de vijf minuten en er is maar 1 proces dat dit gebruikt. Dit proces draait al tijden foutloos, waarom zou ik het veranderen?

@EddoH noemt
Ik denk aan: schaalbaarheid, memory/resource usage, platform onafhankelijkheid, onderhoudbaarheid, foutafhandeling, data validatie, uitbreidbaarheid, etc
en daar heeft hij een punt, maar schaalbaar is niet nodig, want 1 bedrijfsproces. Memory/resources hebben we meer dan voldoende op de server, het platform gaan we niet veranderen, de onderhoudbaarheid is geen issue, fouten zijn wel uit het proces inmiddels etc.

Het is voor ons geen probleem, dus door het nu op de schop te nemen bereiken we op zijn allerbest dat het net zo werkt als nu, maar realistischer is dat een nieuw systeem weer met een aantal kinderziektes gepaard gaat en dat kunnen we in ons ordertraject missen als kiespijn. Elke order is geld.
Wanneer je server software hebt draaien, welke gevoed worden door excel bestanden (want dat is wat de consultant kent) is dat op zich geen probleem. Wanneer het wel een probleem word is dat er duizenden van zulke processen moeten draaien, 24 uur per dag, 7 dagen in de week.
Dat is nog steeds geen enkel probleem...
Dan gooi je gewoon op de server een pakket wat xlsx kan uitlezen en je kan gewoon verder gaan, alleen geen excell op je server zetten.
Ik zou het omdraaien, elke backend-software (wat dat ook moge wezen, backoffice?) die 50 Excel instanties nodig heeft is crap.

Edit: tenzij Citrix o.i.d., in dat geval is het inderdaad niet best.

[Reactie gewijzigd door oef! op 9 september 2019 18:35]

Nee hoor. Dat betekent dat je niet groot genoeg hebt nagedacht.

Daarnaast is Excel traag met het opstarten en afsluiten van een Excel instantie op een computer. En soms faalt Excel hier zelfs in. Zeker als het snel moet gebeuren. De software waar ik het over heb moet namelijk processen verwerken van opnamens meterstanden in miljoenen huishoudens en bedrijven in Europa, verwachtte energie verbruik van die huishoudens en bedrijven in de toekomst (want er hangen serieuze boetes van enkele tonnen aan Euro's, te betalen aan nationale en internationale gridoperators als je hierin fouten maakt), een veiling systeem voor bedrijven die onderling in energie handelen, bedrijven die controleren op de doorgifte van die energie, bedrijven die energie opwekken....oh en deze software doet dat ook voor gas en water nuts voorzieningen.

Als jij denkt dat er geen use-case is, wil niet zeggen dat deze niet bestaat. Er is een uitstekend Engels-talig gezegde: "If you think it can't get any worse, you lack imagination."

Dat jij je niet voor kan stellen dat er geen use-case is voor deze hoeveelheid aan Excel instances die tegelijkertijd zouden moeten draaien, betekent niet dat je zulke use-cases maar moet ontkennen. Kortom, je hebt niet groot genoeg nagedacht.

Kan je verzekeren dat dit geen prettige les was om te leren.
Dat jij je niet voor kan stellen dat er geen use-case is voor deze hoeveelheid aan Excel instances die tegelijkertijd zouden moeten draaien, betekent niet dat je zulke use-cases maar moet ontkennen.
Jouw "use-case" is gewoon verkeerde software gebruiken voor het verkeerde doeleinde.
Incorrect. En mocht het uit vorige post niet duidelijk zijn, ik wil geen Excel gebruiken, ik ben helaas verplicht om Excel te gebruiken. Dat is een heel andere insteek dan jij hier aangeeft.

Back-end software is data verwerken wat word aangeleverd, in welke vorm dan ook. Dat is de enige reden waarom er in dit geval Excel op een server geinstalleerd dient te worden. Voor de uiteindelijke dataverwerking word echt geen Excel gebruikt.

Maar ja, als data via Excel word aangeleverd en alleen via Excel terug word verlangd, want zo is het ontvangende bedrijfsproces nou eenmaal ingeregeld, dan zit de back-end server dus wel degelijk met Excel in de maag.
Wat mij betreft gooien ze het nog verder dicht in Excel. Dat gehobbibobbi van iedereen die denk te kunnen programmeren in Excel.. een systeembeheerder word er niet vrolijk van.

We hebben klanten die gehele database applicaties in Excel maken.. SQL en Access is te moeilijk dus frutten ze wat in elkaar in Excel. Lokaal werkt dit meestal nog wel redelijk met een SSD.. maar in een Citrix omgeving werkt het een stuk minder snel. :)

Doe je zelf een plezier.. als je meer dan een paar Excel bestanden nodig bent.. denk dan na over iets anders dan Excel. Omdat het kan betekend niet dat het een goed idee is.
Ik, als leek op het gebied van backend software, vraag me dan toch af in hoeverre je 50 instances moet willen. Als Excel op die manier gebruikt wordt vraag ik me af waarom er op dit vlak niet door ontwikkelt wordt. Misschien omdat er niet zoveel vraag is....? Als spreadsheet- en data analyse programma is Excel inmiddels enorm goed. Excel = afval doet mijns inziens niet echt recht...
Fun fact: Excel ondersteunt geen multi-threading.

Lees dat nog eens een keertje goed...

GEEN MULTI-THREADING.

Er zijn workarounds voor (door bijv. meerdere instanties van excel te openen in de achtergrond om parallel berekeningen uit te voeren) maar de fucking native applicatie ondersteunt het gewoon niet.

Écht bizar.. ik snap er geen drol van.

Tof overigens hoor dit! Maar met hetzelfde gemak had hij dit ook gewoon in VB.NET kunnen doen.. de meerwaarde van Excel gebruiken is er gewoon niet behalve dan misschien dat je eindigt met een .xlsm in plaats van een .exe (whoopty doo!) :+

Overigens moet ik wel toegeven dat VBA wel echt iets heel erg tofs is.
Je kunt vanuit Excel of Word gewoon een verbinding maken met een SQL/Access database en daar queries tegenaan gooien om data op te slaan/uit te lezen.. en VBA is 'volwaardig' genoeg als programmeer taal dat je er eigenlijk praktisch alles wel mee kan.. zolang het niet te intensief is vanwege beperkingen zoals het gebrek aan multi-threading. :+

Het is handig om gewoon een Excel bestand of zo te kunnen maken met een 'programma' erachter dat nuttige dingen doet.. al moet je goed beseffen dat je relatief snel op het punt komt dat het wellicht beter zou zijn om een volwaardige programmeertaal te gebruiken (bijv. VB.NET wat kwa taal sterk overeenkomt met VBA).

(p.s. 'VBA' staat voor 'Visual Basic for Applications', en het is in principe Visual Basic ingebouwd in alle Microsoft Office applicaties zoals Excel, Word, Access).

VBA in zoiets als Excel is echter wel een hele mooie 'instap' plek voor beginnende programmeurs die snel resultaat willen en ik zou de leercurve dan ook als vrij laag bestempelen.
Er zijn wel meer populaire talen die geen multi-threading hebben: Python is een bekend voorbeeld.

Er zijn maar weinig talen waar intensief multi threaden "comfortabel" is voor de ontwikkelaar. Ik ken eigenlijk alleen Elixir/Erlan die daar echt op focust.

Niet zo raar dat VBA het niet heeft. Simpel + multi threading gaat niet echt samen.
Fair enough. Maar zowat alle libraries zijn (nog) niet thread-safe geschreven. Als ze al van Python 2 naar 3 geport zijn :P

En het is nog allemaal heel nieuw :P
Mwahh.. ben ik het niet helemaal mee eens.

Mijn specifieke frustratie ermee was dat ik een Excel file had gemaakt waar een gebruiker ID's invult.
Zodra die persoon op enter drukt na een ID ingevuld te hebben en naar het volgende veld te gaan om een nieuw ID in te vullen runt er code om tegen een database te checken of het ingevulde ID bestaat en geldig is. Het probleem echter is dat, terwijl die VBA code runt, de interface van Excel niet reageert en als je dus dat volgende ID aan het intypen bent ZIE je niet wat je aan het typen bent omdat de workbook niet update.

Dát was waarom ik wou dat die VBA code in een aparte thread runt van de hoofd Excel applicatie zodat mensen gewoon ID's door kunnen blijven typen terwijl op de achtergrond die ID's gecheckt worden.

Multi-threading in dat geval is dus vrij simpel. Gewoon een lock op de cell die gecontroleerd word op dat moment en op de achtergrond valideren, zodra validatie klaar is visueel weergeven of de cell valide is of niet en de lock eraf halen.. Niks super spannends eigenlijk... maar in Excel VBA werkt dat dus niet 'out of the box'.

Multi-threading vereist een andere mindset dan 'procedureel' programmeren, en als je niet goed lockt en/of geheugen deelt tussen threads (en dus geen thread-safety toepast) ben ik het met je eens dat je programma hele rare dingen kan gaan doen.. maar parallelisering is wél een heel erg krachtige tool.
Zonder parallelle verwerking geen (noemenswaardige) grafisch kaarten of big-data computing.

ikzelf werk het liefst in C#, en persoonlijk heb ik niet zo veel problemen met multi-threading in C#.
Correct omgaan met threading is slechts een (mijns inziens) kleine stap wanneer je al comfortabel en ervaren bent met OOP principes.

[Reactie gewijzigd door Ayporos op 9 september 2019 19:11]

ikzelf werk het liefst in C#, en persoonlijk heb ik niet zo veel problemen met multi-threading in C#.
Correct omgaan met threading is slechts een (mijns inziens) kleine stap wanneer je al comfortabel en ervaren bent met OOP principes.
Wat zijn OOP principes? Voor zover ik weet bestaat er niet 1 definitie van OOP waar informatici het over eens zijn.

Sommige vinden agent oriented programming OOP (losse services/agents als objecten zien) en voor anderen is het indelen van programmatuur in categorieën met hiërarchie OOP. Bij dat eerste is multithreading essentieel. Bij dat 2e staat het er volledig los van.

En dan komen we dus terug bij: simpel + multi threading gaat niet echt samen. :P

Petje af trouwens dat je multi threading maar een kleine stap vindt. Het is de nummer 1 bug in software samen met memory leaks.
Excel kent wél multithreading, standaard staat dit ook aan:
http://drive.google.com/uc?export=view&id=1yv5CGO8UuBRB9qQRU_FLjmen-ZKe6DqE

Wat niet multi-threaded is, is VBA. Helaas beschrijft het artikel niet of deze game alleen met behulp van Excel formules is gemaakt of in VBA.
In dat laatste geval is het eigenlijk niet in Excel gemaakt maar had het iedere Office toepassing kunnen zijn. Het enige verschil tussen VBA in die toepassingen is hoe je zaken weergeeft (in Excel in cellen en reeksen, in Word paragrafen en woorden etc)

[Reactie gewijzigd door dixet op 9 september 2019 16:40]

nooit geprobeerd maar je kunt in Word ook gewoon 'tabellen' plaatsen.. ik neem aan dat die dan ook 'soort van' toegankelijk zijn vanuit VBA net als cellen in Excel?..
Zulk een tabel, dat is een OLE object...oftewel Excel zelf. En werken met OLE is niet echt soepel te noemen.
Excel ondersteund wel multi threading, al sinds versie 2007.
Excel werkt zeker wel via multithreading.

VBA ondersteunt geen multithreading, en dat is maar goed ook want de gemiddelde "advanced excel" gebruiker, gaat daar echt niet mee overweg kunnen. Heck, de gemiddelde programmeur kan daar al niet eens mee overweg.

Als jij niet in ziet waarom dit cool is, snap je ook daar geen drol van. Waarom vind iemand het leuk om Doom op zijn koelkast te spelen ipv gewoon op een PC? Niet omdat het gemakkelijk is, integendeel. Omdat het moeilijk is, maar kàn!
Ik zeg niet dat het niet cool is, en ja als ik dat niet zou snappen zou ik daar inderdaad 'geen drol' van snappen.. maar die statement is nogal overbodig lijkt me dan? :+

Ik had het in der daad over VBA (gebrek aan) multi-threading.

Ik vind jou statement over de 'gemiddelde advanced excel gebruiker', als ook de 'gemiddelde programmeur' nogal kleinerend. Het is niet alsof Multi-threading een of andere zwarte doos is waar je 10 jaar voor geleerd moet zijn om te kunnen begrijpen..

Wellicht projecteer je je eigen tekortkomingen in deze nogal frustratie gevulde post van jou?.. Kan je me aanwijzen op de pop waar multi-threading je gekwetst heeft? :P
Ik had het in der daad over VBA (gebrek aan) multi-threading.
Hmm, ik heb je vorige post er nog even bij gepakt:
Fun fact: Excel ondersteunt geen multi-threading.

Lees dat nog eens een keertje goed...

GEEN MULTI-THREADING.
Hoe vaak en hoe goed ik dat ook lees, er staat "Excel" niet "VBA"...
Ik vind jou statement over de 'gemiddelde advanced excel gebruiker', als ook de 'gemiddelde programmeur' nogal kleinerend. Het is niet alsof Multi-threading een of andere zwarte doos is waar je 10 jaar voor geleerd moet zijn om te kunnen begrijpen..
Het probleem van multithreading is niet om de theorie te begrijpen, dat is nog best te doen (als je goed lesmateriaal hebt), de kunst is om het in de praktijk correct te gebruiken. En dat is wel degelijk zeer lastig (en een complete nachtmerrie om te moeten debuggen: veel bugs zijn niet betrouwbaar reproduceerbaar en single steppen is geen optie). Maar goed, als multithreading zo makkelijk is, hier een lekker simpel voorbeeld:
Init: x = 0
Thread 1: for ( i = 0; i < 10; i++ ) { x++ }
Thread 2: for ( j = 0; j < 10; j++ ) { x++ }
Jij kunt me vast vertellen welke waarden x allemaal kan hebben nadat beide threads klaar zijn? (Ik had het zelf de eerste keer ook fout trouwens.)

Lang niet iedereen die Excel gebruikt is een programmeur. Lang niet elke programmeur die Excel gebruikt weet zelfs maar van het bestaan van threaded code. En lang niet elke programmeur die weet wat threads zijn kan ook daadwerkelijk correcte multithreaded code schrijven. Had MS ergens een optie aan kunnen bieden om multihreading in te schakelen? Ja, dat had gekund, maar dan hadden ze erg veel tijd en moeite moeten steken in een functie die extreem weinig gebruikt zou worden. Was het een goed idee geweest om multithreading default aan te zetten? Nee, absoluut niet, dat zou een gigantische puinhoop zijn geworden.
Jou specifieke voorbeeld kan ik geen antwoord op geven, zonder context van ten minste taal kan deze code alles produceren van een crashende applicatie tot overflows of gewoonweg iets tussen 0 en 20... of wat dat betreft álle mogelijke valide integer waarden.

Shared resources zijn inderdaad even een puntje waar correct locken en handling/wachten belangrijk is.
Ik zou persoonlijk bovenstaande code geen bug beschouwen maar gewoon onvolledige code. Er is geen thread-safety/locking toegepast dus verwachten dat die code doet wat je wil dat het doet is gewoon onzinnig.
Jou specifieke voorbeeld kan ik geen antwoord op geven, zonder context van ten minste taal kan deze code alles produceren van een crashende applicatie tot overflows of gewoonweg iets tussen 0 en 20... of wat dat betreft álle mogelijke valide integer waarden.
Ik had het opzettelijk taal-agnostisch gehouden. Maar goed, jij je zin; noem je favoriete C-achtige taal (C, C++, C#, Pascal, ..., wat mij betreft desnoods Basic, als jij een Basic-dialect kent dat threading ondersteunt) en het is perfect duidelijk hoe die voorbeeld-code bedoeld is (ja, je moet wat syntactische details fixen om er geldige code van te maken, maar dat is triviaal). Dit gebruikt geen enkele speciale feature van een specifieke taal, dit werkt in alle (threaded) talen hetzelfde.
Shared resources zijn inderdaad even een puntje waar correct locken en handling/wachten belangrijk is.
Ik zou persoonlijk bovenstaande code geen bug beschouwen maar gewoon onvolledige code. Er is geen thread-safety/locking toegepast dus verwachten dat die code doet wat je wil dat het doet is gewoon onzinnig.
Dat weet jij, dat weet ik, maar er zijn meer dan genoeg programmeurs (om het over niet-programmeurs die wel Excel gebruiken helemaal maar niet te hebben) die dat absoluut niet weten. Wat betekent dat de post van @T0mBa gewoon helemaal correct is en niets met "kleinerend" te maken heeft.
Het ging hem dan ook vooral over de lol ervan, niet zozeer dat dit de beste tool is om dit te maken 😀.
Fun fact: Excel ondersteunt geen multi-threading.

Lees dat nog eens een keertje goed...

GEEN MULTI-THREADING.
Wat is dit dan? Want de optie kun je gewoon aanvinken in excel.

Uitleg: https://techglimpse.com/e...013-speedup-calculations/

Bestaat dus wel gewoon.
Excel ondersteunt tegenwoordig gewoon multithreding. VBA echter niet...
Nvm.

[Reactie gewijzigd door BenVenNL op 9 september 2019 19:40]

De debugger in Office is waardeloos en alleen daarom zou ik VBA niet aanraden.
Public Declare PtrSafe Function GetTickCount Lib "kernel32.dll" () As Long

Public Sub Timer()
starttime = GetTickCount()
Application.Wait (Now + TimeValue("0:00:1"))
timeelapsed = (GetTickCount() - starttime)
Call MsgBox(timeelapsed & " ticks")
End Sub
Inderdaad complimenten aan de ontwikkelaar.

Wat betreft VBA, GScript is veel handiger. Al was het maar omdat hernoemen/verplaatsen van files de boel gewoon blijft werken in een multi document oplossing (be it meerdere spreadsheets, presentaties, documenten of zelfs andere type bestanden zoals csv's en plaatjes... En elke combinatie hiervan).

Vroeger heb ik veel met VBA kunnen doen die anders niet mogelijk waren. Maar nu jaren later is de GSuite (de betaalde variant), gewoon beter behalve het imago.
geen multi threading is een ding. Geen twee bestanden met dezelfde naam, echt bizar in 2019.
Geen twee bestanden met dezelfde naam vind ik eigenlijk best wel logisch?
Waarom zou je twee bestanden met dezelfde naam willen in dezelfde directory?

Wat ik persoonlijk wel grappig/irritant vind is hoe Windows hiermee omgaat.
Stel je hebt een map vol met afbeeldingen, sommige waarvan .jpg, anderen .jpeg en anderen .png
Als jij ál die bestanden selecteert, en renamed (bijv trip-20190909) dan gaat hij (1) (2) (3) etc toevoegen aan de bestanden... MAAR hij doet dit per extensie!
Dus je eindigt met:
trip-20190909.jpg
trip-20190909.png
trip-20190909.jpeg
trip-20190909 (1).jpg
trip-20190909 (1).png
trip-20190909 (1).jpeg
etc etc

Dát is pas vaag en niet intuïtief wat je verwacht dat het zou moeten doen... :+

[Reactie gewijzigd door Ayporos op 9 september 2019 16:15]

ook niet in verschillende directory
is dit niet 2x het zelfde bestand?
Nope, de ene zat in de map tmp. De ander in tmp/tmp.

Echter... Dat was op kantoor, waar we nog Office 2007 gebruiken (ja echt...)
Nu zit ik thuis met 2016 en hier werkt het inderdaad niet.

De truc met 2007 was een nieuwe instantie te openen (shift+klik op de shortcut voor Excel) en hier het tweede bestand in te slepen. De instantie-structuur is met Office 2010 op de schop gegaan dus ik denk nu dat het sindsdien niet meer werkt. Jammer, want dat doe ik regelmatig en over een paar maanden gaan we op kantoor dan toch eindelijk over naar een nieuwere versie.
En wat nou als je gewoon de hele Excel installatie dubbel uitvoert? i.e. 2 'executables' gebruikt? :P
Waar heb je het over? In Windows (NTFS) is dit geen probleem?
Dit staat los van NTFS.
Excel wilt niet 2 bestanden open hebben met dezelfde naam, ongeacht het pad.
Dus bijv:
c:\temp\1\test.xlsx
c:\temp\2\test.xlsx
Het erge vind ik de 255 character path limit, ongeacht dat al vanaf XP gewoon paden van 1024+ chars worden gesupport
over Excel. Probeer maar eens twee foo.csv te openen.

[Reactie gewijzigd door chaogai op 9 september 2019 16:22]

Ah, ja dat klopt in der daad.. Voor mij is dat tot op heden nog nooit een issue geweest.. maar kan me voorstellen dat dat in bepaalde situaties irritant kan zijn ja.
Het openen in Excel van 2 bestanden met dezelfde naam uit verschillende directory's.
Je kunt in Excel geen 2 files met dezelfde naam openen tegelijkertijd. Ook als ze in verschillende folders staan. Bizar, maar waar...
Dat is zo te zien van dezelfde persoon! _/-\o_
Wow, ik heb best wat excel/vba skills.. maar dit is toch wel echt next level...
Leuk om eens even op te downloaden..
Zie ik dat goed? Met cellen een 'scherm' (pixels) maken en die aansturen?

Gevalletje om dat het kan :)
Ik denk dat elke cell een "blokje" of tile is. Dan heeft die zegmaar; een afbeelding van 32x32 pixels per cell, die zich in het geheel verplaatst.
Ja dat dacht ik eerst ook. Misch is de minimap met hele kleine cellen en de gewone map met grotere cellen met afbeeldingen ofzo. Gekkenwerk :9
Excel-lent job!
Did I just spot a cowlum?

[Reactie gewijzigd door AJediIAm op 9 september 2019 16:09]

Als liefhebber van alles van Civilization (met name Civ2; nog steeds leuk om 'even' te spelen; als iemand ooit een potje Civ2 Gold tegen elkaar wil spelen online.. DM please!), zeg ik: Wow! Briljant! Ik kijk uit naar de uitbreiding met meer dan 2 beschavingen. Gaaf! Maar ook: wat. een. werk. Pfff! :)

[Reactie gewijzigd door Frituurman op 9 september 2019 16:16]

Ik denk dat als ik dat op werk ga doen ik mijn pc laat vast lopen, hij heeft al meer dan een minuut nodig om op te starten en meer dan 15 seconden om outlook te openen. |:(
Excel Macro's zijn voor mietjes:
Voor simpele taken volstaan vaak gewone de excel formules, hetgeen ook leesbaarder is voor je collega's.

Mijn vader maakte ooit mastermind in Excel zonder macro's, was best elegant gedaan, begon met copy-paste van random values naar zwart gemaakte cellen, zodat je het antwoord niet ziet.
:+ maar....wanneer komt de port naar LibreOffice Calc?


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone 11 Nintendo Switch Lite LG OLED C9 Google Pixel 4 FIFA 20 Samsung Galaxy S10 Sony PlayStation 5 Moederborden

'14 '15 '16 '17 2018

Tweakers vormt samen met Tweakers Elect, Hardware Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True