Microsoft gaat Python toevoegen aan Excel en stelt bètaversie beschikbaar

Microsoft gaat ondersteuning voor programmeertaal Python integreren in Excel. Daarmee kunnen gebruikers Python in hun spreadsheets gebruiken voor het analyseren en visualiseren van data. Een publieke preview van de functie komt per direct beschikbaar.

Met Python in Excel kunnen gebruikers de programmeertaal direct in de Excel-ribbon gebruiken, schrijft Microsoft in een blogpost. Gebruikers kunnen dat doen door '=PY' te schrijven in een cel en vervolgens Python-code toe te voegen. Het is niet nodig plug-ins of extra software te installeren om Python te gebruiken in Excel; de programmeertaal is bij release ingebouwd in Excels connectors en Power Query.

Gebruikers kunnen volgens Microsoft Python-code gebruiken om data in Excel te 'manipuleren en verkennen'. Vervolgens is het mogelijk om die inzichten 'verder te verfijnen' met de formules, grafieken en PivotTables van Excel. De feature is gebaseerd op de Anaconda-distributie van Python die draait in Azure. Daarin zijn verschillende Python-library's geïntegreerd, waaronder pandas voor datamanipulatie, statsmodels voor statistische modellen, en Matplotlib en seaborn voor datavisualisatie.

Python in Excel draait op de Microsoft Cloud als Microsoft 365-dienst. Daarmee draait Python-code niet lokaal, maar in de cloud. Dat gebeurt volgens Microsoft in een geïsoleerde Azure-container. De Python-code heeft geen toegang tot internet of de apparaten en accounts van gebruikers.

De functie is per direct beschikbaar als Insider Preview. Gebruikers kunnen deze testversie installeren door zich in te schrijven in het Microsoft 365 Insider-programma en daarin het bètakanaal te kiezen. Gebruikers kunnen de functie vervolgens activeren door in de ribbon bovenaan het scherm op 'Formules' te klikken, 'Insert Python' te selecteren en vervolgens op de 'Try preview'-knop te drukken. Het is niet bekend wanneer de functie algemeen beschikbaar komt.

Bron: Microsoft

Reacties (173)

[jaenster]

Raar dat hier gekozen word voor python. Ik snap dat het "lekker makkelijk" weg schrijft, maar ik was in de verontstelling dat juist javascript in gebruik was in office 365 (de site) en ook op ipad's word gebruik gemaakt van javascript (correct me if im wrong).

Nu nog een taal toevoegen? Wat ook nog in de cloud draait, meh.

[BiaggioLuciano]

In de data science en kunstmatige intelligentie wordt voornamelijk met Python gewerkt. Functie lijkt me ook daarop gebasseerd.

[Frame164]

Niet alleen daar. Ook bij diverse (niet-IT) academische opleidingen is Python de taal voor analyses en simulaties.

[GeroldM]

De performance van Python is na alle nieuwe versies en implementaties van c-libraries nog steeds matig tot slecht te noemen. Wanneer leert men dat niet het gauw even schrijven van wat software in Python qua kosten bijzonder slim is.

Op het kanaal "Dave's Garage" op Youtube is een serie te zien van welke taal het snelst, c.q. het meest efficient is. Dus een heleboel mensen hebben in hun favoriete taal een bepaalde rekensom gebouwd en de test bestond simpelweg uit hoeveel keer kan die rekensom worden uitgevoerd in een vastgelegd tijdsbestek.

De beste implementatie in Python kon de rekensom bijna 3000 keer voltooien in de vastgestelde periode. Dat mag enigzins mooi klinken in de orene van de toehoorder, maar het was een prestatie die thuishoorde in de laagste regionen. De beste implementatie in C++ en Rust konden de dezelfde berekening op dezelfde hardware ruim 2 miljoen keer voltooien. Er waren echter ook slimmerikken, waarvan hun implementatie niet alle regels van de berekening precies volgden, maar daarmee de prestaties van C++ naar een heel ruime 5 miljoen keer konden opschroeven in de vastgestelde tijd.

Het schrijven van efficiente software doe je dus niet in Python. En met alle grote datasets, LLMs, financiele voorspellingsmodellen, energieverbruik voorspellingsmodellen en wat al niet meer, is het dus van de zotte dat deze in Python worden gedaan. Als er ergens een hoop aan tijd gewonnen kan worden tegen veel lagere kosten in het actueel runnen van deze modellen op computersystemen in zowel energie als in afrekenen per verstookte bit bij je favoriete cloud-boer dan is het wel bij het ver weg blijven van alles wat enigzins naar Python riekt.

Mar ja, zie nog maar iemand te krijgen die werkelijk kan programmeren, in plaats van maar wat in Python kloppen en zien waar het schip strand.

Is Python tegenwoordig goed genoeg voor het gauw even opzetten van een idee? Ja. Python heeft zich door de jaren wel wat weten te verbeteren. Maar iedereen die zich een professional wqant, zou beter moeten weten dan Python te blijven gebruiken voor serieus rekenwerk.

Hier is de lijst van topscorers in de test. De test software, rekenmethode en regels zijn vrij beschikbaar op GitHub. Als jij denkt het beter te kunnen, dan staat het je vrij om deel te nemen. Scroll wat naar beneden als de op een monitor met wat lagere resolutie kijkt, de topscore lijst staat namelijk niet meteen bovenaan.

Er zijn zo rond de 50 programmeertalen gebruikt. Python zit in de laagste regionen. Haskell, C#, zelfs BASIC scoort beter dan Python.

Een van de grootset punten van schaamte die is wel dat er zovelen zijn die voor elkaar hebbn gekregen zoveel modellen enz te maken met Python zonder dat er werd ingegrepen. Nu zitten we dus met modellen waar Python niet meer van los te weken is. En Python dus belangrijker is geworden dan dat het ooit had mogen worden.

[selena81]

In het bedrijfsleven gaat het niet om 'optimaal' maar om 'goed genoeg'. Python is relatief makkelijk, veelzijdig, en heeft bergen documentatie.
En het is stukken sneller dan VBA.
Ik zie op veel plaatsen dat VBA langzamerhand wordt vervangen door Python. Ik denk dat dat de reden is dat Microsoft er nu ook mee aan de slag wil: die zoeken al jaren naar een manier om helemaal van VBA af te komen.

[Blockchain]

Python is relatief makkelijk, veelzijdig, en heeft bergen documentatie. En het is stukken sneller dan VBA.

JavaScript toch allemaal ook?

[karelvandongen]

Daarom gebruikt dan ook iedereen numpy/pandas voor dat soort berekeningen !. Echt iedereen die met python werkt gaat voor intensive berekeningen geen python gebruiken, rust/c++ plugins zijn er voor python meer dan voldoende, zeker bv polars(rust) is heel handig. Python is vooral een hele handige gebruiksvriendelijke schil voor makkelijk gebruik te kunnen maken van meer krachtige programmeer talen. En zeker voor de mensen die programmeren er bij doen (en dat zijn er veel!), is dat een erg handig iets.

[Maurits van Baerle]

Inderdaad, ze kunnen dus direct leunen op een gigantisch ecosysteem van data science tools dat de afgelopen twee decennia rondom Python is ontstaan.

[Stin0]

De halve wereld draait tegenwoordig op Pandas en NumPy!

[avlt]

Precies, maar in dat geval worden er Excelfuncties aangeroepen vanuit Python.
Nu gaat het andersom; en dat lijkt me een oneindige bron van verwarring.

[MaestroMaus]

Ik heb liever dat ze geen programmeertaal in een spreadsheet programma stoppen.

Als ze fatsoenlijk extra functionaliteit zouden willen ondersteunen dan zouden ze een extensie framework maken, net zoals bij browsers het geval is. Dan kunnen de macro's/extensies gemaakt worden door developers met development tools en kunnen ze fatsoenlijk gecontroleerd, gedistribueerd en gecommercialiseerd worden in de Excel macro-store/extensies pagina.

Het huidige over en weer sturen van VBA-programma's waarvan de meesten nooit de inhoud willen of kunnen controleren is en zal altijd een groot beveiligingsrisico blijven. Dat verandert niet door een andere programmeertaal erbij te schuiven.

[Reactie gewijzigd door MaestroMaus op 23 juli 2024 12:35]

[Tintel]

Juist - geen versiebeheer, weer een attack-point, draait enkel in de cloud....allemaal factoren die je juist zouden moeten belemmeren om het in een bedrijfsomgeving te gebruiken.
Leuk hoor - weer een extra feature - handig voor de verkoop.

[SuperDre]

Ja, dat geen fatsoenlijke versiebeheer, zonder omwegen, te kunnen toepassen in excel/access is ook een doorn in mijn ogen.

[curkey]

In feite zijn de Excel formules zelf al een soort programmeerscript, als je erover nadenkt.

[MaestroMaus]

Klopt; alleen ben je veel beperkter in wat toegestaan wordt met Excel formules waardoor het inherent veiliger is. Bovendien is het makkelijker voor MS om Excel veilig/snel te maken wanneer ze alleen Excel formules hebben waar ze zich op kunnen concentreren.

[jerisson]

Los van de veiligheidsrisicos, hebben macro's/scriptingmogelijkheden op spreadsheetniveau wel degelijk nut. Vaak zijn er taken die geautomatiseerd moeten worden (met een macro-opname, of eigen code), maar die enkel nuttig zijn voor die specifieke spreadsheet en die specifieke data. Dan heeft het geen zin om een extensie te schrijven, dat in een of andere store te gooien en dan de spreadsheet niet deftig te kunnen gebruiken zolang de extensie niet geïnstalleerd is. Dat geeft gewoon een hoop bloat, en is niet noodzakelijk veiliger.

Extensies zijn overigens ook al mogelijk in Office (ik herinner me dat ik hier rond 2008 mee experimenteerde in VB.net en C# - voor office 2003), maar die dingen hebben/hadden ook toegang tot alles. Daarnaast kunnen ze Office ook instabiel maken (ik herinner me een demo over bibliografiebeheer plugin. Referentie toevoegen en Word crashte). Macro's kan je nog controleren, dat kan je bij binary extensions vaak niet (al zou dat ook als script kunnen).

Persoonlijk lijkt me een sandbox of permissies beter dan macro's eruit te slopen. Mogelijk dat dit er ook is in nieuwere Office versies. Bij Google weet ik dat het zo geïmplementeerd wordt (zowel macro's als extensies).

[Robby517]

Python wordt heel vaak gebruikt bij databeheer, van simpele zaken tot 'big data'. Het is ook gewoon een solide scripting taal, zeker voor beginners, met minder quirks dan JS. Imho dus een zeer goede keuze en een stuk logischer dan de JS toevoeging van enkele jaren geleden.

[jaenster]

Ik denk dat python een stuk laagdrempeliger is dan javascript wat in het geval van excel een goed ding is. En zoals andere mensen terrecht aanhalen is het met python een stuk makkelijker om correcte berekeningen te doen.

Echter, het voordeel van een JS is dat het gemaakt is om een sandbox te zijn, backwards competable, draait op alles en overal. Denk dat dat ook de reden is dat dit in de cloud draait en niet lokaal. Daarnaast wil je niet dat je zomaar python uitvoert op je pc vanuit een of ander excel sheet

[thalyric]

ik ben zelf JS developer, maar Python is beter voor grote berekeningen / data.

[beerse]

Met dat ze nu hier voor python gekozen hebben en de aanroep als "=py" gebruiken, zie ik openingen voor andere talen: "=js" voor javascript en dergelijke.
Als er dan ook ergens de mogelijkheid is om de te gebruiken interpreter te configureren dan kan het zelfs open/eindeloos worden uitgebreid.

Maar microsoft kennende hebben ze hier vast iets speciaals ingebakken en gaat het naast de bestaande script constructies ook een eigen leven leiden....

=CB: Cobol
=JS: JavaScript
=VB: VisualBasic
...

[Reactie gewijzigd door beerse op 23 juli 2024 12:35]

[svenk91]

Met Javascript kan je met data werken, met python kan je visualisaties doen. Maar Python is beter voor het werken met data (zeker met meer geavanceerde zaken als machine learning) en Javascript is beter voor visualisaties (zeker met live interactie door de gebruiker).

Welke optie je voornamelijk zak gebruiken zou afhangen van wat je voornamelijk doet als werk. Wat dat betreft is het goed als MS beide aanbied.

[Mellow Jack]

De strategie van MS lijkt mij dat je Excel gebruikt voor data (en simpele visualisaties). Als je meer wilt heb je PowerBi (waar je al zelf visualisaties o.b.v. javascript kan maken).

Dus betwijfel of die ondersteuning gaat komen

[vickypollard]

Hou m'n bier vast, want hier kan ik dingen mee maken waar mijn werk nog jarenlang last van heeft

[supersnathan94]

Ik dacht eerst hee dat is vet! En daarna dacht ik oh nee… dit wordt een ramp.

Zie je het al voor je. Een taal die afhankelijk is van indentatie in een Excel Cel schrijven?

En dat is nog niet eens het grootste issue.

[Cergorach]

Dit is heel cool.

Maar imho niet als lange termijn tooling, dat is niet alleen een issue met het toevoegen van Python, dat is al heel lang een issue met Excel en Access. Maar laten we eerlijk zijn, het is eigenlijk geen issue van Excel/Access, maar meer een issue van gebruikers... Hoe vaak ik Excel heb gezien als database en Access als complete 'applicatie' is niet meer funny! En dan is er een major (OS/Office) migratie en duiken allerlei 'databases' en 'applicaties' de kop op die in de decennia daarvoor door gebruikers gemaakt/ontwikkeld zijn, zonder aan te melden bij IT... Vervolgens verwachten dat ze wel even ondersteund/gemigreerd worden...

Excel (en Access) is prima voor korte termijn RAD/RAB, maar als je dat lange termijn wil hebben of fatsoenlijke ondersteuning, bouw er uiteindelijk iets van dat niet zo finnicky is. SUM en SOM werkt al niet onderling in verschillende taal versies van Excel...

Don't get me wrong, ik gebruik heel vaak spreadsheets (wat tegenwoordig weer primair Excel is). Maar oude spreadsheets herbouw ik meestal van scratch, over het algemeen is dat sneller dan uitvissen hoe de oude is opgebouwd (en of dat nog correct is)...

[polthemol]

dit!

Ik gebruik de excelsheets op mijn werk vooral als inputsheets, die ik verder verwerk via pythonscripts. Dat voorkomt heel veel gedoe met vage excelformules die weer kapot gaan door kopiëren ed.

Ik kijk dus erg uit naar deze stap van Microsoft en hoe ze dat implementeren, het zou mijn werk een stuk gemakkelijker kunnen maken

[HansvDr]

Met Access kun je ook snel Applicaties maken. Met eventueel een database als SQL Server of MySQL als backend. Werkt prima en er is snel resultaat te behalen.

[avlt]

Inderdaad, wat dacht je van de scope en namespaceissues als je een cel met functie en classdefinities kopieert.

[latka]

Correct! En het totaal ontbreken van versie beheer in Excel of met Excel voegt een geheel nieuwe dimensie toe aan de uitdagingen voor de mensen na jou! Gouden greep van MS om die bal volledig te laten liggen.

[Upsilon]

Ik vraag me oprecht af wat het grote verschil gaat zijn met de huidige way of working met Excel. Op dit moment kun je ook al veel datamanipulatie doen met PowerQuery. Het is inderdaad nauwelijks (lees: totaal niet) onderhoudbaar door iemand anders dan de 'ontwikkelaar', maar veel meer dan Excel on steroids gaat ook het toevoegen van Python niet zijn als ik het zo lees.

[latka]

Precies mijn punt: het echte probleem van Excel is dat er geen versiebeheer oid mogelijk is, maar ipv. dat een keer oplossen na 20 jaar gaan ze Python toevoegen want dat heeft een hogere hype-factor.

[OruBLMsFrl]

Ettelijke versies van een Excel document zie je bij steeds meer bedrijven gewoon binnen SharePoint/OneDrive, al dan niet als onderdeel van de opslag gekoppeld aan een team in Teams. Als een collega die Excel om zeep helpt, kun je dan zo terugspringen naar een versie van het document waarin het nog wel werkte. Of je dit moet willen met Python in Excel is een andere vraag, maar document versies zijn er minimaal wel in de meeste omgevingen nu.

[BlueSix]

Versiebeheer in inderdaad prima mogelijk met SharePoint/OneDrive, maar dat is bedoeld om content versies te beheren. Zeker met autosave krijg je straks tientallen versies van een document, waarin allerlei probeersels zitten met Python scripts. Bedenk dan nog maar eens wat de goede is en waarom bepaalde wijzigingen zijn gedaan. En wat als in de tussentijd ook nog content is aangepast en/of andere scripts zijn gewijzigd? Met een goed versiebeheersysteem wil je op z’n minst iets van branches kunnen maken, details van wijzigingen zien en comments toevoegen aan je wijzigingen.

[svenk91]

Ook dat is prima te doen met een fatsoenlijk management. Technische documentatie is een ding. Regels voor comments in je code hanteren is ook een ding. Dat bijv. git er bij een commit naar een comment vraagt is vooral een lapmiddel om slecht management te verzachten (en daarom heel goed dat het er is!).

[Frame164]

Volgens mij is het uitgangspunt van dit soort functionaliteit in Excel is dat de gebruiker van de excel sheet additionele mogelijkheden heeft voor (ad-hoc) datamanipulatie. Dat organisaties het misbruiken als alternatief voor beheerde tools is wat anders.

[scholtnp]

Je kunt een binair gecodeerd zoals Excell prima bij een versiebeheertool (subversion, bazaar, mercurial, git...) committen, maar je kunt er weinig mee. Je bedoelt waarschijnlijk dat je geen zinvol verschil kan zien door middel van een 'diff'. Met de flatversie van ods kun je dat wel doen. Dat je data binair opgeslagen wordt in plaats van als leesbare tekst is alleen maar in het voordeel van degene die dat formaat geheim wil houden, en wordt duidelijk afgeraden in het tweede statement van de unix filosofie. Comprimeren kan desnoods op de disk.

[Bor]

Het is wachten op het moment dat dit wordt misbruikt voor minder frisse zaken. Microsoft maakt inmiddels de stap om macro's eindelijk aan banden te leggen na jaren van misbruik voor o.a. phishing om nu met dit te komen..

Natuurlijk zijn er nuttige toepassingen maar ook dit heeft, net als de macro's , een duistere keerzijde wanneer niet goed geïmplementeerd en niet standaard enabled verwacht ik.

[Stievydude]

Ik denk dat je dit hebt gemist in het artikel, dus misbruik zal niet echt mogelijk zijn denk ik:
"De Python-code heeft geen toegang tot internet of de apparaten en accounts van gebruikers."

[Bor]

"De Python-code heeft geen toegang tot internet of de apparaten en accounts van gebruikers."

Dat hoeft ook niet. Je kan slimme scripts gebruiken om de gebruiker over te halen om zelf zaken te doen, uit te voeren of op te sturen. Er is meer te bedenken dan alleen direct actief misbruik door software door het systeem aan te passen etc.

[DesignedRat]

Idd, dacht ik ook meteen. Op mijn werk heb ik ook 2 systemen waar ik ons productgamma up to date moet houden, maar de excel importsheets zijn zo verschillend. Met powerautomate kan je veel, maar is te omslachtig om dit met powerautomate voor elkaar te krijgen. Ik kijk ernaar uit om die functie uit te testen

[DutchHammer]

Ik krijg al flashbacks naar de tijd dat business users met VBA aan de slag gingen...

[Alex3]

In Open- en LibreOffice is Python ook beschikbaar, maar de methode waarop het in Excel geactiveerd moet worden lijkt me incompatibel. Niet verbazend, Microsoft kennende.

[batjes]

Aan de andere kant, Excel is de standaard. Waarom zijn anderen niet compliant met Excel?

[Morrar]

Omdat Microsoft die Excel "standaard" niet openbaar maakt, waardoor het voor anderen heel lastig is om zich eraan te houden... Dat is precies de reden waarom standaarden openbaar moeten zijn; anders gaat een partij ermee aan de haal.

Natuurlijk kun je zeggen dat er een model met licenties mogelijk is, maar dan staat de concurrentie altijd al 1 - 0 achter, want zij moeten betalen voor de standaard en de eigenaar van de standaard zelf niet. Dan is er dus geen eerlijke concurrentie.

Tot slot is een open standaard beter voor de kwaliteit; hoe meer mensen eraan meedenken, hoe hoger de kwaliteit. Zie ook een recente post van een Google Engineer die stelt dat je van Open Source niet kunt winnen: https://www.semianalysis....-have-no-moat-and-neither (betreft machine learning in dit geval).

Het is ook precies de reden dat MS zoveel mogelijk OS aan het omarmen is; alles op Azure (idem AWS / GCP) is zo'n beetje herverpakte OS software en nu zien we het ook hier in Excel weer terug...

Excel is nu wellicht nog de standaard ook vanwege de dominantie van Windows; maar voornamelijk voor thuis- / MKB gebruik. Voor serieuze data analyse wil je er het liefste ver van wegblijven: https://www.youtube.com/watch?v=yb2zkxHDfUE.

[Reactie gewijzigd door Morrar op 23 juli 2024 12:35]

[feuniks]

Onzin.
Ik als bedrijf heb mijn standaarden. Die hoef ik heus niet openbaar te maken, omdat jij je aan mijn standaarden wil conformeren.
Als ik mijn standaarden openbaar wil maken, dan doe ik dat wel. En of ik daar geld voor wil hebben of dat ik dat gratis weggeef is een tweede. Ook of ik die standaarden alleen verder wil ontwikkelen of in een groter verband.

[84hannes]

Ik als bedrijf heb mijn standaarden. Die hoef ik heus niet openbaar te maken, omdat jij je aan mijn standaarden wil conformeren.

ik denk dat je hiermee reageert op een losse zin, niet op de thread.
@Alex3 stelt dat Microsoft incompatible is met LibreOffice.
@batjes wil de vraag omdraaien, waarom LibreOffice niet zijn best zou moeten doen om compatible met Microsoft te zijn.
Het antwoord op deze vraag heeft twee delen:

• LibreOffice was eerst, dus kon niet compatibel zijn met Microsoft
• Microsoft publiceert zijn standaarden niet open publiceert open standaarden en houdt zich hier vervolgens niet aan, dus kan LibreOffice niet compatibel zijn

Dat Microsoft niets verkeerd doet is wellicht waar, maar je kunt ze moeilijk als "de standaard" zien als zij het onmogelijk maken je aan die "standaard" te conformeren.

Een vergelijking: een aanzienlijk deel van de chat-communicatie in Nederland loopt via het protocol van Whatsapp. Toch is dit geen standaard.

[Reactie gewijzigd door 84hannes op 23 juli 2024 12:35]

[delphium]

Daar wil ik nog aan toevoegen dat (open) standaarden wel heel erg belangrijk zijn. Met name voor overheden, maar eigenlijk voor iedereen. Als je wilt dat jouw data toegankelijk is voor iedereen en dat ook blijft (en dat wil een overheid!) dan is het erg belangrijk dat jouw documenten een standaard volgen die vrij en openbaar verkrijgbaar is. Zelfs als bepaalde software verdwijnt, om welke reden dan ook, is het in elk geval mogelijk om aan de hand van die open standaard, opnieuw software te schrijven die de documenten kan openen, bewerken en opslaan.

Zonder deze open standaarden is een WOO (Wet Open Overheid) een wassen neus. Dat bepaalde bedrijven, ik noem geen namen, als Adobe en Microsoft, o pardon, die openheid deels aan hun laars lappen, mag je gerust beschouwen als sabotage van een standaard. Elke niet gedocumenteerde afwijking op de open standaard, maakt deze volstrekt onbruikbaar voor bijvoorbeeld de overheid.

Dat er bij de overheid toch nog zo veel wordt gewerkt met NIET open standaarden, mag je gerust zorgwekkend noemen. Als ik als ambtenaar graag open source software wil gebruiken, word ik daarin belemmerd door DICTU (Dienst ICT Uitvoering), want geen controle, gebrek aan kennis en wildgroei!1one1eleven! Dat is eigenlijk om je kapot te schamen als overheid.

[Reactie gewijzigd door delphium op 23 juli 2024 12:35]

[84hannes]

Elke afwijking op de open standaard, maakt deze volstrekt onbruikbaar voor bijvoorbeeld de overheid.

Ik ben bang dat het niet zo zwart/wit is. In de praktijk wijkt waarschijnlijk iedere implementatie wel van de standaard af, dat geld voor PDF, ODF, C, HTML etc. Daar is binnen bepaalde marges nog wel mee te werken.

[delphium]

Ik heb mijn reactie gewijzigd naar "elke niet gedocumenteerde afwijking..".
Maar het gaat er niet om of er mee te werken is, het moet gewoon open zijn. Gratis toegankelijk voor iedereen. Voldoet het daar niet aan? Ongeschikt!

[batjes]

https://learn.microsoft.c...1e-4a9a-9614-31f71e679456

De technische specs voor Microsoft Office zijn gewoon beschikbaar.

[Andreas01]

Dat is waar, maar in de praktijk zijn die specificaties zodanig complex en voegt Microsoft zelf nog proprietary componenten toe dat het niet te doen is om perfecte compatibiliteit in te bouwen. Hier is wat leesvoer erover: https://fsfe.org/activities/msooxml/msooxml.en.html.

[batjes]

Ach, andersom heeft Microsoft jaren geleden de ODF specs tot op de punt geimplementeerd, toen was het Open/Libre Office die zijn eigen uitzonderingen op dat formaat had geimplementeerd en zelf niet volledig voldeed aan de specs en zo de ODF documenten uit Microsoft Office niet 100% compatible waren met Open/Libre Office ODF documenten.

Het is altijd wat met de office standaarden, is het niet MS die niet mee wil werken, is het de open source community wel.

Microsoft deelt de technische specs van Microsoft Office, heeft schriftelijk ook laten weten aan ECMA International dat ze alle Microsoft Office specs en licenties beschikbaar gesteld hebben om opgenomen te worden in de ECMA standaarden.

Maar, Microsoft, met hun office monopolie, zit niet aan de tafel mee te discusieren over de standaarden. Alle open (office) standaarden worden buiten Microsoft om ontwikkeld. Beetje krom, niet?

[Andreas01]

Ten eerste heeft het ook wel eventjes geduurd voordat Microsoft de "ODF specs tot op het punt had geïmplementeerd" (zie hier het rapport over Office 2007 bijvoorbeeld), en Office 2010 ondersteunde nog niet alle functionaliteit (volgens Wikipedia althans).

Ik ben het ermee eens dat LibreOffice een aantal extensies op het ODF formaat heeft geïmplementeerd (maar je kunt de documenten uiteraard als "normale ODF" opslaan). Dit is niet handig maar betreft vaak wel features die gepland zijn in een komende ODF-standaard en omdat LibreOffice open source is, kunnen deze makkelijker ergens anders geïmplementeerd worden en kan bekeken worden hoe deze werken. Bij Microsoft Office is dit onmogelijk natuurlijk (bij proprietary extensions).

En ten tweede zit Microsoft wel degelijk aan tafel om de open standaarden te ontwikkelen: Zie hier bijvoorbeeld de OASIS OpenDocument commissieleden en hier de stemming van ODF 1.2.

[d3burt]

Microsoft office in de browser is niet compatible met Microsoft office op de desktop. En grappig genoeg, de dingen die in de browser versie niet werken zijn precies de dingen die libreOffice ook niet goed doet. Een voorbeeld zijn docx documenten met velden. Ik heb nooit uitgezocht wat het precies is wat libreOffice niet begrijpt aan die velden, maar het was opvallend dat de browser versie van Word precies dezelfde fouten maakt.

Ikzelf ben al jaren over op Open/libreOffice en erger me iedere keer weer groen wanneer ik Excel moet gebruiken, dat dingen die ik in libreOffice zo voor elkaar klik niet werken in Office. :-) Het is maar net wat je gewend bent.

[atthias]

nu ja maar uit @84hannes zijn bericht begrijp ik dat dat eerst niet zo was

[84hannes]

• Staat Python daar (al) in, en hoe lang al? Was dat voordat LibreOffice Python ondersteunde?
• Implementeert Microsoft die standaard zelf wel? Zie ook https://themukt.com/never-use-microsofts-ooxml-format/

[The Zep Man]

Onzin.
Ik als bedrijf heb mijn standaarden. Die hoef ik heus niet openbaar te maken, omdat jij je aan mijn standaarden wil conformeren.

Jouw bedrijf is niet in een positie om marktverstorend te zijn. Microsoft wel, en die is daarom in het verleden wel eens gedwongen om bepaalde zaken te openbaren. Dat droeg bij aan de deels intercompatibiliteit tussen Office en LibreOffice.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 12:35]

[feuniks]

En daarom ondersteunt Office ODF. Dat niemand dat gebruikt is een ander verhaal.

[rob12424]

Is ODF een open standaard dan?

Gooi een zak geld tegen een Keuringsdienst en je hebt een open standaard

[84hannes]

Is ODF een open standaard dan?

Jazeker, Open Document Format is een Open formaat voor documenten.

[rob12424]

Je hebt de smiley en het stukje eronder even over het hoofd gezien.

Die keuring was toen absoluut niet zuiver.

[84hannes]

Daar zou ik graag meer over horen. Was de standaardisatie van OOXML wel zuiver?

[rob12424]

Ik heb even zitten zoeken. Kan best zijn dat ik OOXML in de war haal met ODF

[Vuggie]

Een dergelijke houding kan een bedrijf zich alleen permitteren als ze een dominante marktpositie heeft, zoals Microsoft dat heeft met Excel. Vaak om de dominante marktpositie te behouden en verder te versterken.

En in dat geval is een dergelijke houding vooral schadelijk voor de klanten die door gebrek aan concurrentie te veel betalen. Daarom is regulering en standaardisering belangrijk.

[Loller1]

Als je klaar bent met de klagen over hoe jij denkt dat Office geen open standaard is kan je misschien beginnen opzoeken wat Office Open XML is, de open standaard die Microsoft al sinds Office 2007 gebruikt (en heeft uitgebracht voor oudere Office versies).

[Morrar]

Ja leuk, maar dat is niet het gangbare formaat waarin Excel bestanden opslaat; de meeste mensen zullen Open XML dus niet gebruiken of zelfs weten dat dit bestaat. Dat is juist altijd de grap bij MS; eigen uitbreidingen / extensies introduceren om mensen aan je product te binden.

Dus nee, Office Open XML is niet "de standaard" waarop degene doelde waar ik op reageerde. Die bedoelde het standaard formaat waarin Excel opslaat *inclusief* alle toeters en bellen die MS daaraan heeft gehangen.

[Blokker_1999]

Microsoft Office Open XML is niet alleen een standaard van MS, het is ook gewoon het standaard formaat dat door MS al sinds 2007 gebruikt wordt in MS Office. En de specificatie van deze standaard is een heel stuk uitgebreider dan die van het concurerende ODF formaat waar jij zo een voorstander van bent. Enkel legacy onderdelen zoals OLE zijn nog altijd gesloiten.

[CH4OS]

De standaard is niet openbaar? Je weet dat een .xlsx bestand gewoon een verpakking rond .zip is, waarin diverse XML-files zitten? Je kunt ook kiezen om OpenOffice XML te gebruiken als standaard...

[Verwijderd]

ik vind wel vreemd dat die vraag 1 x gesteld wordt helemaal aan het begin, en je volgens mij niet meer kunt wisselen tussendoor. wat is er gebeurd met "save as" en dan kiezen tussen .xlsx and odf

[CH4OS]

Dat kan prima, alleen bij de eerste keer Office opstarten, wordt gevraagd welke standaard gebruikt moet worden voor nieuwe documenten, niet bestaande.

[svenk91]

Ik kan hier 26 fileformats kiezen als ik save as klik in excel. Éen daarvan is .xlsx, een ander is .ods (.odf is de tegenhanger van .docx ). Ook nog wat andere open standaarden zoals .csv staan daar tussen.

[Cergorach]

De hele lijn OpenOffice/LibreOffice is ook gewoon gebaseerd op een oud closed source office pakket (StarOffice), wat pas later de boel heeft open gegooid, juist om de concurrentie aan te gaan met MS Office. Als SUN daar vervolgens achter zit gaat dat geheel niet compatible zijn met een MS product. Zeker niet als SUN op dat moment al overhoop ligt met MS ivm. Java en bezig is met een rechtszaak... Alle MS 'compatibility' is er pas veel later ingebouwd toen duidelijk werd dat zonder dit product ten dode was opgeschreven.

Ik heb de afgelopen twee decennia ook heel veel OpenOffice/LibreOffice gebruikt, Google Docs, maar ben weer terug naar MS Office gegaan omdat mijn tijd gewoon mij meer waard is (geworden).

[Maurits van Baerle]

Zoals @Morrar al zegt, MS Office is berucht vanwege het zich niet houden aan de OOXML standaard. Dat is de voornaamste oorzaak van de problemen rond interoperabiliteit tussen verschillende office pakketten en zelfs binnen verschillende versies van MS Office.

Het is niet voor niets dat als je problemen hebt met het openen van een ouder MS Office bestand het advies is om het te openen met LibreOffice omdat die veel meer gefocussed is op werken met allerlei incompatibiliteitsproblemen met MS Office bestanden dan MS Office zelf.

[CH4OS]

Ik merk anders dat een LibreOffice anders ook niet heel bijster goed omgaat met OpenOffice bestandsformaten, waar Excel dan vaak juist weer geen problemen heeft. Die interoperabiliteit is met OpenOffice formaten echt nog ver te zoeken.

[Verwijderd]

Als je klaar bent met de klagen over hoe jij denkt dat Office geen open standaard is kan je misschien beginnen opzoeken wat Office Open XML is,
Ik raad jou dan ook aan eens in te lezen over Open XML en hoe 'open' dat beschouwt wordt:
https://en.wikipedia.org/...Office_Open_XML#Criticism

Kort door de bocht, Microsoft is een van enigen die zegt dat het een 'open standaard' is. Een open standaard van 6000 pagina's.... Deze standaard heeft men gemaakt om de 'EU' op afstand te houden ne boetes te vermijden. Een zoethoudertje.

Samen met het punt dat het niet standaard gebruikt wordt door Microsoft (zoals @Morrar aangeeft) en je toch wel wat document functionaliteit verliest bij gebruik van deze standaard, is het gewoon een dikke streek geweest.

[84hannes]

Samen met het punt dat het niet standaard gebruikt wordt door Microsoft

Wat bedoel je hiermee? Wat is volgens jou het standaard-fornaat van MS Office?

[GeroldM]

Interessante video, waarvoor dank. Kende het kanaal niet, maar er is meer dan genoeg andere interessante content in dat kanaal beschikbaar. Dus nogmaals bedankt.

[DiedX]

Heb jij de standaard van Excel voor mij dan? Oh wacht...

[Umbrah]

Alstu:

http://officeopenxml.com/
https://www.ecma-internat...dards/standards/ecma-376/

Office Open XML is een gestandaardiseerde, open standaard waarin Office vrij "strict" werkt. Er zijn addins, maar op wat niche-scenario's na zoals opsommingslijsten met individueel gemarkeerde tekens heb ik nog geen beperkingen gevonden.

Excel is niet alleen de de-facto standaard in elke DMS-gedreven wereld, het is ook een open standaard. Alleen de software zelf is dat niet.

Ik zie wel steeds meer een migratie naar "open core". Een closed-source product met een open core en componenten en exclusief open standaarden. Het feit dat het nog steeds een "product" is, of zelfs als SAAS wordt aangeboden maakt het aantrekkelijk voor organisaties die zeker in een tijd dat zaken als security een praktische full-time job is per organisatie (en kleine organisaties bestaan) geen behoefte hebben om IT een significante aangelegenheid te maken van hun kernproces.

Excel is de standaard. En de excel producten zijn dat daarbij ook. Persoonlijk juich ik verdere "veropening" door dit soort pythonificatie juist toe.

[Cambionn]

Maar @batjes en @Umbrah als ik het goed begrijp hadden Open- en LibreOffice het al vóór Excel. Beetje lastig een standaard te volgen die er nog niet is .

Tenzij je zou willen zeggen dat niemand mag innoveren behalve Microsoft zodat men op hun "standaard" kan wachten, maar dat lijkt me dus ook weer geen best idee.

[Umbrah]

Och, ik zie het eigenlijk (sorry voor de GIS termen) als de vergelijking tussen i3s en Cesium 3DTiles.

i3s komt van een grote corpo af, en cesium komt van een kleine startup die pretendeert "open" als richtlijn te hebben. I3S en Cesium zijn echter beide volledig open, en door OGC (dé autoriteit op het gebied van geodata standaarden) 'erkend', waar één een community standaard is, en de andere "de" standaard.

Cesium was er eerst, i3s kwam pas later.

i3s echter kan, itt Cesium:
- Relatief makkelijk met niet-globale CRS-en omgaan
- Heeft de backing van praktisch elk groot GIS pakket, waaronder o.a. Bentley, Esri, etc...
- Plugins voor Unity én Unreal
- Dynamisch LOD's aanpassen
- Koppelen naast bestaande 2d infrastructuur

Qua performance, connectiviteit, en bestaande producten kunnen hergebruiken is i3s veruit "beter", ondanks dat het niet "eerder" was. Cesium is naast hun eigen standaard óók een viewer, die recentelijk óók i3s is gaan ondersteunen, en daarmee is denk ik de kous af dat i3s "de" standaard is.

Mag niemand innoveren naast de grootste GIS-boer? Zeker niet. Heck, in 2d vector tiling is juist die gis boer niet de standaard geworden, maar bijvoorbeeld mapbox juist. Wat juist door esri is geadopteerd nu.

Maar het feit is en blifjt dat ik eigenlijk wel goed snap dat Microsoft dit op 'hun' manier doet. Eigenlijk is het ook wel een logische manier. Tuurlijk, Open Office/LibreOffice konden het eerder (die hebben ook naar vbscript gekeken immers), maar MS Office/OOXML heeft het nu ook, en anders. En net als Cesium denk ik dat het niet erg is dat anders kán. Net zoals de UI moet evolutie en verandering gewoon mogelijk zijn.

[Cambionn]

Opzich niet mee oneens. Maar mijn bericht was vooral gericht op:

Aan de andere kant, Excel is de standaard. Waarom zijn anderen niet compliant met Excel?

Dat als reactie op dat Open- en LibreOffice het al eerder hadden ben ik het niet helemaal mee eens. Je kan namelijk niet iets op een standaard bouwen die nog niet bestaat. Die quote dat of Open- en LibreOffice compliant moeten zijn aan Excel betekend in weze dat ze dus niks nieuws mogen maken dat niet in Excel zit, want anders zijn ze zijn niet compliant.

Ik heb niks tegen grote corpo's in algemene zin, en als die een daadwerkelijk betere standaard hebben is daar ook niks mis mee. En soms doen ze het ook oprecht beter, ook zij hebben een hoop knappe koppen daar. In die zin heb ik niks tegen big tech. Het is ook best mogelijk dat over tijd, de Python implementatie compatible wordt gemaakt met die van MS Office, zelfs al werkt het onderwater dan mogelijk wel anders (bijv. naar lokale Python ipv in Azure). Dat zie ik best nog wel gebeuren, en dat is ok.

Waar ik wel wat tegen heb (wat niet per se relevant is in deze casus) is als grote corpo's minder goede standaarden maken en met hun macht en lobbies doordrukken voor een monopoly op standaarden, en (wat hier wel aan de orde is) wanneer de kleine man al veel eerder met een idee komt en wanneer de Big Tech het invoert men meteen roept hoe slecht het is dat de kleine niet compatible zijn. Zelfs als de big corpo een betere versie heeft, kost het tijd om dingen om te bouwen daar naar toe. En vaak genoeg komt de intresse van de big corp op z'n minst mede omdat het idee bewezen is door de kleinere spelers. Die kleinere spelers dan de grond in boren vind ik dan niet helemaal terecht. Het ligt namelijk veel genuanceerder.

[Reactie gewijzigd door Cambionn op 23 juli 2024 12:35]

[Jeffrey2107]

Volgens mij houden ze zich ook niet eens aan hun eigen standaard

[84hannes]

Ik heb een bron gezocht om jouw standpunt te onderbouwen

In fact, each version of MS Office since 2007 has a different and non standard implementation of OOXML, which is defined as “transitional” because it contains elements which are supposed to be deprecated at standard level, but are still there for compatibility reasons.

Overigens is dat niet geheel ongebruikelijk. Ik heb me wel eens laten vertellen door een kopieerapparatenfabrikant dat Adobe de PDF-standaard niet 100% volgt, dus om compatible te zijn met Adobe moesten ze van de PDF-standaard afwijken.

[kabelmannetje]

Excel is geen standaard. Het is een veel gebruikte applicatie en niet meer dan dat.

[D3F]

In de volksmond dus een standaard, net als dat Coca Cola het standaard cola merk is bijvoorbeeld. Niet een standaard die wij als Tweakers gebruiken om een protocol/werkwijze aan te duiden.

[Reactie gewijzigd door D3F op 23 juli 2024 12:35]

[The Zep Man]

Je verwart (formele) standaard met de facto standaard.

[kabelmannetje]

Zowel Excel als Coca-Cola, zijn geen standaarden.

[CivLord]

Het is de meest gebruikte applicatie in zijn soort en daarmee de de-facto standaard.

Wanneer je een spreadsheet voor iemand maakt en die is niet Excel compatible, dan kan je het schudden, tenzij die ander ok één van de zonderlingen is die dezelfde applicatie als jou gebruikt.

[Alex3]

Voor een standaard moet je je aan afspraken houden en dat doet Microsoft niet.

[CivLord]

Microsoft houdt zichzelf prima aan de afspraken die het met zichzelf maakt en ook de wijzigingen daarin spreekt Microsoft met zichzelf af.
Jouw probleem (en dat van vele anderen) is dat Microsoft de standaard dicteert aan de rest van de markt die een spreadsheet wil maken die serieus genomen wil worden (waarbij die anderen ook nog eens een hoop zelf uit mogen vissen omdat niet alles uit de standaard (eenduidig) openbaar is, i.p.v. dat de standaard door een aantal partijen wordt afgesproken en deze goed gedocumenteerd openbaar is.
Maar wanneer er een formaat is waar je compatible mee moet zijn wil je een kans maken om door meer dan een handvol gebruikers gebruikt te worden, dan is dat de de-facto standaard.

[Alex3]

Afspraken met zichzelf zijn geen afspraken. Dat is het probleem, samen met het gebrek aan openbaarheid.

[kabelmannetje]

Excel is geen standaard. Het heeft een dominante positie in het bedrijfsleven onder spreadsheets. Maar dat maakt het geen standaard. Bijvoorbeeld op universiteiten waar research wordt gedaan, heeft Excel absoluut geen dominantie.

[supersnathan94]

Omdat dat niet kan.

Zelfs als het wel kon (docx) is het vaak MS die zich niet aan de standaard houdt en zijn eigen dingen toevoegt die dan zelfs binnen versies niet overeenkomen.

[PolarBear]

Waarom zou het per se compatibel moeten zijn? Microsoft heeft hier gekozen voor een oplossing die samenwerkt met Azure dus het compatibel maken lijkt mij sowieso lastig. En ik zie naast de nodige nadelen ook wel voordelen dat het helemaal in de cloud draait.

[Cambionn]

Je kan natuurlijk gewoon op dezelfde syntax een lokale Python installatie aanroepen ipv Azure, of zelfs Python meeleveren met Open- en LibreOffice danwel deze als (optionele) dependencies neerzetten (zelfs met de extra packages die op Azure voorgeinstaleerd zijn). Zolang de syntax in de spreadsheet compatible is, maakt het niet zó veel uit hoe onderwater Python wordt aangeroepen. Python is immers een eigen taal los van MS Office.

Hooguit konen er problenen als men een te oude Python draait ofzo, maar dan moet men wellicht z'n systemen up to date houden .

[Reactie gewijzigd door Cambionn op 23 juli 2024 12:35]

[Merik]

Inderdaad, behalve dat het met externe tools als openpyxl mogelijk is Excel bestanden aan te maken of beschrijven, maar dat is iets anders. Maar als ik het artikel lees, klinkt het niet aannemelijk dat de nieuwe functionaliteit in alle stand-alone Office versies komt.

[Verwijderd]

meestal past microsoft ook een eigen sausje op de taal toe. Ben benieuwd naar de klachten over een jaar of wat

[Alfa1970]

Waarom zou het incompatibel zijn?
Guido van Rossum werkt voor Microsoft, het lijkt me dat hij er wel voor zorgt dat die koppeling goed functioneert.

[Rekcor]

Mmm... dat draaien in de cloud is wel echt een bummer. Kan ook geen andere dan financiele redenen bedenken waarom Microsoft dit zo heeft gebouwd. Beter zou zijn: optioneel 'dure' bewerkingen in de cloud, de rest lokaal.

[supersnathan94]

Ik wel.

Hoe ga jij python installeren op een thin client of laptop van de baas zonder admin rechten? Je hebt een interpreter nodig namelijk.

[StGermain]

Thin client: Op de server draaien/

Laptop baas: Ik mag hopen dat iemand in het bedrijf admin rechten heeft om dit ff te pushen.

Door in de cloud te draaien maak je van alle capabele machines thin clients waarop excel niet meer werkt als internet uitlegt of er te weinig bandbreedte is.

[supersnathan94]

Laptop baas: Ik mag hopen dat iemand in het bedrijf admin rechten heeft om dit ff te pushen.

En ga jij dan ook de beheerslast erbij verkopen? Enig idee hoeveel updates Python heeft per jaar? Zijn er best wel wat.

Ms moet dan een compatibility matrix bij gaan houden en bedrijven moeten dan die matrix actief in de gaten houden voor wijzigingen en die dan ook actief tegelijk testen en doorvoeren. Veel te veel werk.

Door in de cloud te draaien maak je van alle capabele machines thin clients waarop excel niet meer werkt als internet uitlegt of er te weinig bandbreedte is.

Ja eens, maar dan moet je ook niet dit soort dingen gaan doen en gewoon normaal python gebruiken zoals men in datascience al jaar en dag doet.

Ik begrijp de functie en implementatie vanuit MS, maar ik zie niet waarom je dit als gebruiker zou willen kunnen. Puur vanuit UX perspectief is het al een ramp. Dat hele screenshot wordt ik direct al misselijk van.

[MatthijsZ]

Wellicht zodat je andere packages makkelijk kunt gebruiken, zonder dat die allemaal op computer van elke gebruiker hoeven te worden geïnstalleerd?

[bussie66]

Hopelijk is dit uit te schakelen.

Bij mij op het werk wordt de halve boekhouding ed namelijk nagebouwd in Excel gebruik makend ook van VBA (terwijl we een prima boekhoud-pakketten ed hebben) en uiteraard geen documentatie door de gebruiker.

Excel is een ziekte voor het bedrijfsleven

[Reactie gewijzigd door bussie66 op 23 juli 2024 12:35]

[lighting_]

Een wereld zonder Excel. Sommige snappen niet dat er grote problemen ontstaan.
Excel is niet het probleem maar gebruikers. Het is net IT software.
Ga je ook keukenmessen verbieden omdat je lelijke dingen mee kan doen?

[Reactie gewijzigd door lighting_ op 23 juli 2024 12:35]

[Guus...]

Het zou niet raar zijn om het bedieningspersoneel te verbieden aan de keukenmessen te zitten. Een gevangenis bewaarder mag ook geen keukenmes mee naar z'n werk.

Maar als je het bij it houdt heb je in heel veel software beperkingen zitten die door de it afdeling kunnen worden ingesteld waardoor je bijvoorbeeld geen software kan installeren.

[lighting_]

Of geen keukenmessen verkopen aan iedereen. Eerst een vog laten zien.

[supersnathan94]

Zonder gekheid. Ik zit nu in het VK en moest een schilmesje hebben. Die krengen zijn zowat nergens verkrijgbaar en als je ze wel vind moet je je legitimeren. Worden niet verkocht onder 25 jaar.

[lighting_]

maar wel alcohol verkoop vanaf 18 jaar waar jongeren wekelijks ongelukken veroorzaken.

[Atilim]

Als je halve boekhouding via Excel loopt dan doe je iets verkeerd.

Je maandafsluiting prima
Rapportages ook
Je cijfers aanleveren ook prima

Maar je boekhouden via Excel? Doe je alleen maar als je bijna helemaal niks doe.

[Muncher]

Oh man, hopelijk gaat dit niet tot allerlei (security) issues leiden. Ik bedoel: ActiveX, VBA en consorten hebben niet altijd veel goeds gebracht.

[xFeverr]

Misschien hebben ze daarom ervoor gekozen om de code in de cloud te draaien? Dan heb je geen fratsen lokaal op je computer, die krijgt alleen de waarde terug.

[supersnathan94]

Dat plus het feit dat windows standaard geen python interpreter heeft zoals linux en macOS dat wel hebben. Dan moet de gebruiker ineens weer allerlei zaken gaan installeren en configureren en dat maakt het natuurlijk lastig. Een python installatie op windows is niet moeilijk, maar het is ook niet heel eenvoudig en vereist admin rechten. Iets wat je in zakelijke omgevingen vrijwel nooit hebt. Dus dat ze het via de cloud doen snap ik wel.

[Alex3]

Die rechten heb je ook nodig om Excel te installeren dus dat zou geen probleem moeten zijn.

[Arm1n]

Alleen komt excel mooi voorgeïnstalleerd op elke kantoorlaptop. Dit zouden ze ook met Python kunnen doen maar voor die 1% van de werknemers die dat gaat gebruiken gaan ze dat niet doen

[supersnathan94]

Komt dan ook nog een behoorlijk beheerslast bij kijken om python p to date te houden.

[supersnathan94]

In kantooromgevingen wordt dat gewoon meegeleverd in de image. Dat is dan gewoon voorgeïnstalleerd en updates worden actief gepushet. Komt geen admin account aan te pas.

[IrBaboon79]

Die interpreter is natuurlijk een kwestie van inbakken in excel en is voor de user dus geen issue...de eventuele updates komen via Microsoft en/of de interne updates via IT.

[supersnathan94]

Mja zie je het al voor je? Als er dan een update is voor een issue in python moet de hele wereld excel gaan updaten ook als je het niet gebruikt. No thanks. Houd maar lekker buiten de deur en update los. Ik ga hier wel in mee met MS. Lekker extern laten die hap.

[IrBaboon79]

dat is toch exact hetzelfde als er een issue zit in <wat dan ook>...? je krijgt een update via WU, klaar.

[supersnathan94]

Met alle gevolgen van dien. Microsoft heeft geen enkele applicatie meer die als alleenstaand stuk software geüpdatet kan worden. Alles is aan elkaar geknoopt en werkt daardoor ook gewoon vaak maar matig snel.

Het is juist dit soort monolitische architectuur wat zorgt voor een onbeheersbaar stuk draak van een software met gigantische haken en ogen als het aan komt op updates.

Excel is geen datascience tool, maar een spreadsheet tool. Prima voor wat visualisaties en kleine wiskunde, maar met deze scripting erbij gaan we echt draken van applicaties krijgen.

[IrBaboon79]

In dit geval zorgt embedden in excel dat er controle is over hetgeen er wel/niet mogelijk is met de interpreter; dit overlaten aan de willekeur van gebruikers die dan maar een random versie erin schuiven en dan gaan zeuren dat het niet werkt, het niet bijhouden (want dat is ook weer werk), er zelf aan gaan k*tten (want optie rood maakt het sneller), etc is veel meer ellende dan af en toe een update de deur uit jagen via het bekende en vertrouwde office/windows update kanaal.

Excel is al een enorm pakket, elke cel bevat zo'n beetje de mogelijkheden van heel Acces en Word; die optionele script module maakt het niet erger; users aan je afhankelijkheden laten rommelen maakt het wel degelijk erger.

[supersnathan94]

Klopt. Daarom vind ik het ook best een goede zet dat ze best of both worlds doen. Losse interpreter, maar wel managed in hun eigen cloud.
Beter qua security, beheerslast, installatie en updates.

Updaten is heel simpel alleen de image tag aanpassen (en dus misschien een andere image bouwen) en dan heb je globaal de update uitgevoerd.

Enige nadeel als gebruiker is dat je altijd een netwerk verbinding nodig hebt bij verversen van de data en dat je geen version pinning hebt, maar verder zit je goed qua security en andere ongein.

[andru123]

Bijna hele business wereld 20 jaren gedraaid op excel en office (VBA) automatization.
Ja er waren af en toe issues, maar het was (en voor veel gebruikers nog steeds is) een essentiële feature van Excel.
Zeggen dat VBA niet veel goeds gebracht is net als zeggen dat Office niks goed gebracht.

[Andre_J]

Ik denk dat dit een mooie aanvulling kan zijn.
Alleen jammer dat het weer in de cloud is.
Er zijn genoeg onderzoeksinstellingen waarbij data nog niet naar "buiten" mag en de analyse offline gebeurd.

[4tro]

Waarom moet dit nou weer in de cloud draaien, zou toch niet zo moeilijk moeten zijn om een python interpreter in Excel te embedden lijkt me, vooral aangezien ze Guido van Rossum nu in dienst hebben...

[YGDRASSIL]

Python interpreter is easy. Maar als je iets serieus wil doen heb je ook een bulk up-to-date packages nodig. En dat is natuurlijk makkelijker in de cloud te onderhouden dan op elke client-PC. Maar het lijkt me in de praktijk erg onhandig als je lokale spreadsheet het weer eens niet doet omdat er ergens op weg naar de cloud iets mis is.

[PolarBear]

Interessante ontwikkeling, het voorbeeld in het screenshot is nou niet echt bijzonder (je kan het met een pivottabel ook makkelijk oplossen) maar het opent wel nieuwe mogelijkheden.

[metalmania_666]

Ben benieuwd of het ook op lokale versies van Microsoft komt.
Ik gebruik Office 2019 en 2021

[Umbrah]

Office 365 is lokaal. Ik denk dat het licentiemodel en de cloud componenten soms wat los van elkaar lopen. Office 365 moet je zien als:
- Een account-licentie die je per maand betaald voor de desktop software die zichzelf á la chrome vrij vaak update
- Een stukje rechten tot web- en mobiele applicaties
- Een stukje cloud opslag die wat verder gaat dan file system level access door een live-editing API aan te bieden en indexering (á la sharepoint).

Mocht iemand nu desktop office willen, dan zal ik alsnog office 365 aanraden. De kosten per maand en het gemak van updates is welkom, de optie tot backups is goed, de software werkt echter ook prima zonder internet verbinding als een native desktop applicatie, en opslaan op whatever filesystem je wilt bestaat nog én valt als standaard in te stellen.

[SunnieNL]

ik hoop zo van niet.. want als het lokaal kan draaien weet je zeker dat er een manier wordt gevonden om uit de sandbox te breken en heb je echt een probleem.