De Devschuur Coffee Corner - Iteratie ⓬

[Immutable]

gekkie schreef op maandag 20 juli 2020 @ 12:22:
[...]
Ik vind het vooral fascinerend dat je met de pattern-matching en een berg statistiek je toch al een eind kunt komen in de wereld. Op zich misschien ook weer niet zo vreemd, een fruitvlieg komt ook best een eind (en soms iets te ver ..).

Wij mensen hebben ook geen vrije wil, wij zijn gewoon de meest complexe patroon herkenningsmachine in de natuur. Met onze 80 tot 100 miljard hersencellen welke elk ieders 7000 verbindingen hebben met andere hersencellen. Deze verbindingen kunnen worden gemaakt en verbroken doormiddel van een chemisch process genaamd neuroplasticiteit.

Als je bekend bent met datastructures weet je dat de dichtsbijkomende dier in het dierenrijk maar 30 tot 40 miljard hersencellen heeft. En dan zie je dat wij exponentioneel veel hogere patroon herkenningsvermogen hebben en vandaar dat we op een "hoger" niveau kunnen denken. Dit zien wij als "bewustzijn". Maar eigenlijk moet je bewustzijn in een getal kunnen uitdrukken. Dat kunnen we helaas nog niet.

Probleem met AI, is dat we een "vaste" neuron network trainen, en dan gebruiken. Terwijl het onze continu aan het veranderen is door externe bronnen. Wie weet maken we ooit een super krachtige AI, waarbij hij zichzelf dingen kan leren door middel van zijn eigen neural network aan te passen. In een mens is dit een chemisch process van welke netwerken vaker of minder gebruikt worden en dus afzwakken. Dit noemen wij wel "leren" en "vergeten".

Ik denk echt dat er in de wereld van informatica veel gaat veranderen hoe meer we gaan weten van onze hersens en hoe we die technieken kunnen toepassen in de informatica.

Ik heb net ook een Kendryte K120 microcontroller voor een paar dollar gekocht, deze kan ook al een getrained AI netwerk behuizen. Gezichtsherkenning in een microcontroller!! Wie had dat ooit gedacht. En het kost geen drol. https://www.antratek.nl/sipeed-maix-bit-kit (Ook nog eens samen met een Risc-V processor )

[Mugwump]

Immutable schreef op maandag 20 juli 2020 @ 12:15:
[...]


Generative Engineering word al heel veel gebruikt hoor in de mechanica. Hierbij wordt inderdaad evolutionaire algoritmen gebruikt om snel heel veel iteretaties te doen om sneller naar een redelijk optimaal punt te komen in plaats van brute force wat veel te lang duurt. Dit wordt ook gedaan bij trading algoritmen af te regelen van de parameters.

AutoDesk is hier al heel erg hard mee aan de weg aan het timmeren. Het is springlevend.

Daarnaast was mijn vorige post wel erg provocerend (met opzet) om reactie uit te lokken. Maar ik was redelijk onder de indruk van GTP-3. Dit zou nog wel eens een Google 2.0 kunnen worden, waarbij een op maat gemaakte antwoord voor je wordt geproduceerd door een AI.

Het moet eigenlijk een soort interface worden tussen mens en machine, waarbij de machine ons kan begrijpen door onze gewone menselijke taal te gebruiken. Google nu zoekt een antwoord op, GTP-3 genereerd een antwoord. https://twitter.com/paraschopra/status/1284801028676653060

Er zijn zelfs al ideeen om GTP-3 in visual studio code te implementeren om jou als programmeur te helpen programmeren.

Maar hebben jullie dan wel eens een AI gezien die dit soort "menselijke" tekst kan begrijpen en om kan zetten tot GUI + Logica ?? Is hier dan niemand die hier van onder de indruk is???
https://twitter.com/sharifshameem/status/1284815412949991425

Maar het was ook helemaal niet mijn punt dat dergelijke zaken niet gebruikt zouden worden, integendeel. Mijn punt was dat ze vooral zaken versimpelen of werkzaamheden ondersteunen, niet dat ze nu overal hun werktuigbouwkundigen de laan uit sturen.

Kijk, ik ben het met je eens dat dit weer een hele mooie stap is, maar ik ben nooit zo onder de indruk van dit soort hyperbolische claims.
Kevin Lacker had nog wel een leuke Turing test gedaan en dan valt GTP-3 hier en daar toch nog wel door de mand.

Kijk, we doen bij AI net of het de eerste keer is dat we werk uit handen nemen van software engineers, maar het tegendeel is natuurlijk waar. Voor wie in een hedendaagse programmeertaal werkt aan 'business software' zijn alle low-level concerns als memory management al volledig weggemanaged. Werk je met APIs en databases (en soms zelfs UIs), dan zijn er al allerhande codegeneratietools die de code van clients / models / UIs voor je genereren. IDEs doen legio intelligente checks en suggesties om de kwaliteit van je code te verbeteren en ga zo maar door. Ik zie dit soort middelen meer als een nieuwe stap in dat proces, dan als een revolutionaire verandering die software developers overbodig maakt.

Het spannende aan mijn werk is ook nooit hoe ik van exact uitgekristalliseerde requirements die in foutloze taal volledig correct zijn gespecificeerd code kan maken. De grootste uitdaging is om de requirements überhaupt in een dergelijke staat te krijgen. En nog iets heel simpels, hoe werkt dit als de requirements en communicatie níet in het Engels zijn? Mooi spul hoor dit soort ontwikkelingen, maar alle software developers de WW in? Ik dacht het niet.

[Immutable]

Mugwump schreef op maandag 20 juli 2020 @ 12:38:
[...]
Het spannende aan mijn werk is ook nooit hoe ik van exact uitgekristalliseerde requirements die in foutloze taal volledig correct zijn gespecificeerd code kan maken. De grootste uitdaging is om de requirements überhaupt in een dergelijke staat te krijgen. En nog iets heel simpels, hoe werkt dit als de requirements en communicatie níet in het Engels zijn? Mooi spul hoor dit soort ontwikkelingen, maar alle software developers de WW in? Ik dacht het niet.

Ik ben het dan ook volledig met je post eens. Was ook een beetje over de top om te zeggen dat onze banen verdwijnen. Ik zie het vooral als een hulpmiddel, wat je ook in de mechanica ziet. We gaan bepaalde taken uitbesteden aan een hulpje die saaie vervelende arbeidsintensieve taken zal overnemen. De wereld gaat steeds verder met automatiseren, dus zullen programmeurs zeker niet verdwijnen. Echter zie ik wel dat bijvoorbeeld dat er wel steeds meer vraag komt naar systemen bouwen, en dat klant specifieke aanpassingen en aanpassingen aan de systemen door de klanten zelf gedaan kunnen worden op een gebruiksvriendelijke manier, in plaats van dat je moet leren programmeren. (En dus van die dure mensen moet inhuren, om elke kleine aanpassing te laten programmeren) Hier kan de AI bijvoorbeeld wel van toepassing komen. Het onderliggende "systeem programmerings" deel zal altijd natuurlijk programmeurs voor nodig zijn.

[Mugwump]

Immutable schreef op maandag 20 juli 2020 @ 12:49:
[...]


Ik ben het dan ook volledig met je post eens. Was ook een beetje over de top om te zeggen dat onze banen verdwijnen. Ik zie het vooral als een hulpmiddel, wat je ook in de mechanica ziet. We gaan bepaalde taken uitbesteden aan een hulpje die saaie vervelende arbeidsintensieve taken zal overnemen. De wereld gaat steeds verder met automatiseren, dus zullen programmeurs zeker niet verdwijnen. Echter zie ik wel dat bijvoorbeeld dat er wel steeds meer vraag komt naar systemen bouwen, en dat klant specifieke aanpassingen en aanpassingen aan de systemen door de klanten zelf gedaan kunnen worden op een gebruiksvriendelijke manier, in plaats van dat je moet leren programmeren. (En dus van die dure mensen moet inhuren, om elke kleine aanpassing te laten programmeren) Hier kan de AI bijvoorbeeld wel van toepassing komen. Het onderliggende "systeem programmerings" deel zal altijd natuurlijk programmeurs voor nodig zijn.

Wat versta je onder 'systeem programmerings'? Ik zit eigenlijk nauwelijks meer in de front-end applicaties. Ik zit eigenlijk meer in wat je de 'data engineering' kan noemen. Het bouwen van applicaties die veel data verwerken, o.a. APIs beschikbaar stellen, data in geoptimaliseerde vorm beschikbaar stellen voor specifieke doeleinden en ga zo maar door. Betekent vaak dat er data uit veel verschillende richtingen binnenvloeit die ook weer geintegreerd moet worden, waarbij ontbrekende data gegenereerd moet worden en ga zo maar door. Het écht begrijpen van context en materie is dan wel cruciaal. Ik zou dolgraag AIs willen hebben waartegen ik gewoon kan zeggen "alsjeblieft, hier is driehonderd pagina's aan specificatie van systeem A en hier van systeem B, regel even dat ik de data uit beide systemen automatisch in dit formaat netjes geharmoniseerd en geïntegreerd in een data store naar keuze krijg", maar ik vrees dat dat nog redelijke toekomstmuziek is.

[gekkie]

Immutable schreef op maandag 20 juli 2020 @ 12:35:
[...]
Wij mensen hebben ook geen vrije wil, wij zijn gewoon de meest complexe patroon herkenningsmachine in de natuur. Met onze 80 tot 100 miljard hersencellen welke elk ieders 7000 verbindingen hebben met andere hersencellen. Deze verbindingen kunnen worden gemaakt en verbroken doormiddel van een chemisch process genaamd neuroplasticiteit.

Als je bekend bent met datastructures weet je dat de dichtsbijkomende dier in het dierenrijk maar 30 tot 40 miljard hersencellen heeft. En dan zie je dat wij exponentioneel veel hogere patroon herkenningsvermogen hebben en vandaar dat we op een "hoger" niveau kunnen denken. Dit zien wij als "bewustzijn". Maar eigenlijk moet je bewustzijn in een getal kunnen uitdrukken. Dat kunnen we helaas nog niet.

Daarnaast doen we op zich hetzelfde, we vullen ook de helft in en aan op basis van het geleerde model van de wereld en de context om zaken heen (wat een van de dingen is die AI vaak minder heeft, de context is vaak nog erg beperkt).

Probleem met AI, is dat we een "vaste" neuron network trainen, en dan gebruiken. Terwijl het onze continu aan het veranderen is door externe bronnen. Wie weet maken we ooit een super krachtige AI, waarbij hij zichzelf dingen kan leren door middel van zijn eigen neural network aan te passen. In een mens is dit een chemisch process van welke netwerken vaker of minder gebruikt worden en dus afzwakken. Dit noemen wij wel "leren" en "vergeten".

Ik denk echt dat er in de wereld van informatica veel gaat veranderen hoe meer we gaan weten van onze hersens en hoe we die technieken kunnen toepassen in de informatica.

Zijn nog wel een aantal "revoluties" nodig ten opzichte van de huidige weg denk ik.
Met alleen meer silicon computer power er tegen aan gooien gaan we het niet redden.

Ik heb net ook een Kendryte K120 microcontroller voor een paar dollar gekocht, deze kan ook al een getrained AI netwerk behuizen. Gezichtsherkenning in een microcontroller!! Wie had dat ooit gedacht. En het kost geen drol. https://www.antratek.nl/sipeed-maix-bit-kit (Ook nog eens samen met een Risc-V processor )

Ben benieuwd hoe goed die is .

[CodeCaster]

Immutable schreef op maandag 20 juli 2020 @ 12:15:
Maar hebben jullie dan wel eens een AI gezien die dit soort "menselijke" tekst kan begrijpen en om kan zetten tot GUI + Logica ?? Is hier dan niemand die hier van onder de indruk is???
https://twitter.com/sharifshameem/status/1284815412949991425

Ik kan maar bijzonder weinig vinden over de ondeliggende technieken, dus nee, daar is niks indrukwekkends aan!

Ik geloof niet dat ze die AI een boek over HTML, CSS en React hebben gevoerd en dat het ding de rest zelf heeft uitgevonden, dus ergens zal iemand met de hand de koppeling tussen "button" en een bijbehorende bak HTML aan uitvoer hebben gelegd.

En dan nog, als de AI dat zelf kan (zoals de AI die op basis van de manual zelf een aardig potje Age of Empires kon spelen), dan nog is het weinig indrukwekkends of vernieuwends.

Ik kan in een paar uur ook wel een app bouwen die UI-elementen bij naam herkent (button, header), die kan tellen en kleuren kent, en die van een bepaalde input een bepaalde output kan maken, dat is kinderspel.

Juist de reden waarom dit indrukwekkend zou kunnen zijn, blinkt (in de tweets waarnaar je linkt) in ieder geval uit in aanwezigheid.

Neem ook deze onzin, waar Stack Overflow een half jaar geleden een blog aan heeft gewijd: "Opiner", een scraper die API's/packages een rating geeft op basis van Stack Overflow-posts die getagd zijn met de betreffende API of package.

Wat daar het resultaat van is, is dat een vraag over library X, met daaronder een comment à la "library X solved the bug I had with library Y", als een minpunt voor X, want "bug" is een negatief woord.

Ik ben daar alles behalve van onder de indruk.

Nu snap ik ook wel dat random blogjes over random projecten van random studenten niet representatief zijn voor de hele staat van de markt van de AI, maar dat zijn de dingen die ik tegenkom. Ik zou er graag meer over leren, maar van demo's zoals deze en die op Twitter word ik warm noch koud.

Mugwump schreef op maandag 20 juli 2020 @ 13:02:
[...]


Wat versta je onder 'systeem programmerings'?

Volgens mij is de definitie van een "systems programmer" iemand die werkt aan OS'en, drivers en low-level API's.

[ Voor 12% gewijzigd door CodeCaster op 20-07-2020 13:17 ]

[Mugwump]

CodeCaster schreef op maandag 20 juli 2020 @ 13:09:
[...]

Ik kan maar bijzonder weinig vinden over de ondeliggende technieken, dus nee, daar is niks indrukwekkends aan!

Ik geloof niet dat ze die AI een boek over HTML, CSS en React hebben gevoerd en dat het ding de rest zelf heeft uitgevonden, dus ergens zal iemand met de hand de koppeling tussen "button" en een bijbehorende bak HTML aan uitvoer hebben gelegd.

En dan nog, als de AI dat zelf kan (zoals de AI die op basis van de manual zelf een aardig potje Age of Empires kon spelen), dan nog is het weinig indrukwekkends of vernieuwends.

Ik kan in een paar uur ook wel een app bouwen die UI-elementen bij naam herkent (button, header), die kan tellen en kleuren kent, en die van een bepaalde input een bepaalde output kan maken, dat is kinderspel.

Juist de reden waarom dit indrukwekkend zou kunnen zijn, blinkt (in de tweets waarnaar je linkt) in ieder geval uit in aanwezigheid.

Aan de voorbeelden die ik aanhaalde te zien kan de API ook wel degelijk op basis van een verzoek in natuurlijke taal programmeercode uitspugen, al zijn deze voorbeelden natuurlijk niet heel spannend:

Q: Write one line of Ruby code to reverse an array.
A: ary.reverse

Q: Write one line of Ruby code to count how many X's are in an array.
A: ary.count { |x| x == 'X' }

[...]

Volgens mij is de definitie van een "systems programmer" iemand die werkt aan OS'en, drivers en low-level API's.

Ja, ik weet dat dat soort dingen onder de definitie vallen, maar ik ben vooral benieuwd waarom dat soort zaken buiten de mogelijkheden van zo'n NLP API zouden vallen. "Hier zijn de specs, bouw een driver" is ook gewoon een opdracht in natuurlijke taal.

[Hydra]

Immutable schreef op maandag 20 juli 2020 @ 12:15:
Maar hebben jullie dan wel eens een AI gezien die dit soort "menselijke" tekst kan begrijpen en om kan zetten tot GUI + Logica ?? Is hier dan niemand die hier van onder de indruk is???
https://twitter.com/sharifshameem/status/1284815412949991425

Nee. Om twee redenen. Ten eerste is het overduidelijk dat het enorm beperkt is in wat het kan. En het 'kunnen' van die laatste 20 procent gaat 80% van de tijd kosten. Ten tweede is er al een manier om in detail specificaties in een computer-readable manier uit te drukken; code.

Hij heeft gewoon een human-readable programmeertaal gemaakt en al dit soort dingen falen op dezelfde issues.

[gekkie]

Hydra schreef op maandag 20 juli 2020 @ 13:43:
[...]
Nee. Om twee redenen. Ten eerste is het overduidelijk dat het enorm beperkt is in wat het kan. En het 'kunnen' van die laatste 20 procent gaat 80% van de tijd kosten. Ten tweede is er al een manier om in detail specificaties in een computer-readable manier uit te drukken; code.

Meestal ook de meest consciëntieus en kort mogelijke omschrijving van de probleem oplossing (en al haar uitzonderings situaties). Het zal toch ook niet voor niets zijn dat men ook in niet programmeeromgevingen toch van lieverlee jargon gaat ontwikkelen, een eigen specifieke taal aangepast aan het probleemdomein.

Hij heeft gewoon een human-readable programmeertaal gemaakt en al dit soort dingen falen op dezelfde issues.

Mjah een feestje als het iets ingewikkelder wordt dan simpel.
Het ding zal dan op z'n minst vragen terug moeten gaan stellen om meer duidelijkheid te krijgen, specs van iemand krijgen en dan iets maken zonder vragen te kunnen stellen wil zelden leiden tot iets al te robuusts.

[Woy]

Hydra schreef op maandag 20 juli 2020 @ 13:43:
[...]


Nee. Om twee redenen. Ten eerste is het overduidelijk dat het enorm beperkt is in wat het kan. En het 'kunnen' van die laatste 20 procent gaat 80% van de tijd kosten. Ten tweede is er al een manier om in detail specificaties in een computer-readable manier uit te drukken; code.

Hij heeft gewoon een human-readable programmeertaal gemaakt en al dit soort dingen falen op dezelfde issues.

Inderdaad, een DSL specifiek voor het ontwikkelen van een UI, of een designer is veel efficiënter. ( Dat is iets wat Low Code omgevingen natuurlijk ook doen ).

Ik geloof nooit dat die "AI" zo slim is dat hij echt nieuwe concepten gaat maken. Ik snap het punt wel dat UI's maken niet perse door een die-hard software ontwikkelaar gedaan hoeft te worden, maar dat kan prima met normale tooling ondervangen worden. De toegevoegde waarde van de brug naar natuurlijke taal snap ik hier ook niet zo goed.

[Hydra]

Woy schreef op maandag 20 juli 2020 @ 14:24:

Ik geloof nooit dat die "AI" zo slim is dat hij echt nieuwe concepten gaat maken.

Het is een 'machine learning' gegetraind met bestaande applicaties. En ik denk met heel veel handmatig werk. Dus dit ruikt een beetje naar oplichting. Zal niet de eerste keer zijn dat er te hoge verwachtingen geschapen wordt met "low code" platformen.

[Mugwump]

Woy schreef op maandag 20 juli 2020 @ 14:24:
[...]

Inderdaad, een DSL specifiek voor het ontwikkelen van een UI, of een designer is veel efficiënter. ( Dat is iets wat Low Code omgevingen natuurlijk ook doen ).

Ik geloof nooit dat die "AI" zo slim is dat hij echt nieuwe concepten gaat maken. Ik snap het punt wel dat UI's maken niet perse door een die-hard software ontwikkelaar gedaan hoeft te worden, maar dat kan prima met normale tooling ondervangen worden. De toegevoegde waarde van de brug naar natuurlijke taal snap ik hier ook niet zo goed.

Kijk, het is een leuke gimmick. Ik heb ook een eens een tooltje geprobeerd dat mijn geklieder op een whiteboard om moest kunnen zetten in HTML / CSS, maar daar valt het resultaat ook vaak nogal tegen als het wat complexer wordt.

Het lukt mensen al niet om natuurlijke taal ondubbelzinnig te interpreteren, want die natuurlijke taal is van zichzelf al helemaal niet ondubbelzinnig.

[CodeCaster]

Mugwump schreef op maandag 20 juli 2020 @ 13:39:
[...]


Aan de voorbeelden die ik aanhaalde te zien kan de API ook wel degelijk op basis van een verzoek in natuurlijke taal programmeercode uitspugen, al zijn deze voorbeelden natuurlijk niet heel spannend:


[...]


[...]


Ja, ik weet dat dat soort dingen onder de definitie vallen, maar ik ben vooral benieuwd waarom dat soort zaken buiten de mogelijkheden van zo'n NLP API zouden vallen. "Hier zijn de specs, bouw een driver" is ook gewoon een opdracht in natuurlijke taal.

Natuurlijke taal zit natuurlijk bomvol redundantie en ruis, ik mag aannemen dat ze daarom dat framework gebruiken. "I would like a web app that has one red button on the left and a blue one on the right" lijkt door die tool geanaliseerd en vertaald te worden naar "button, left, red" en "string 'one', right, blue", en daar poept de code generator dan keurige, vooraf ingestudeerde HTML en CSS voor uit. En dat is dus bijster weinig indrukwekkend, dat ontstijgt niet het niveau van chatbots die ik tig jaar geleden schreef en die veel bedrijven nog steeds lijken te gebruiken op hun sites. (Niet dat ik die dus gebouwd heb, maar de gemiddelde Billy of Nancy wil ik na twee zinnen te hebben uitgewisseld kunnen shibboleeten door te zeggen "geef me maar gewoon een persoon aan de lijn").

Maar dat zijn niet bepaald de scenarios waar een gemiddelde webbouwer mee te maken krijgt, en succes met het parsen van "this shitty website doesn't work on my iPhone", laat staan het oplossen.

[ Voor 12% gewijzigd door CodeCaster op 20-07-2020 14:58 ]

[Mugwump]

CodeCaster schreef op maandag 20 juli 2020 @ 14:51:
[...]

Natuurlijke taal zit natuurlijk bomvol redundantie en ruis, ik mag aannemen dat ze daarom dat framework gebruiken. "I would like a web app that has one red button on the left and a blue one on the right" lijkt door die tool geanaliseerd en vertaald te worden naar "button, left, red" en "string 'one', right, blue", en daar poept de code generator dan keurige, vooraf ingestudeerde HTML en CSS voor uit. En dat is dus bijster weinig indrukwekkend, dat ontstijgt niet het niveau van chatbots die ik tig jaar geleden schreef en die veel bedrijven nog steeds lijken te gebruiken op hun sites.

Maar dat zijn niet bepaald de scenarios waar een gemiddelde webbouwer mee te maken krijgt, en succes met het parsen van "this shitty website doesn't work on my iPhone", laat staan het oplossen.

Die tool gooit voor zover ik het begrijp de toch echt gewoon een natural language query richting de API. Het is geen zelfgebouwd tooltje dat wat basale parsing doet. Ik had een verzoekje ingediend om toegang om eens te kijken hoe flexibel het is.

[gekkie]

CodeCaster schreef op maandag 20 juli 2020 @ 14:51:
Maar dat zijn niet bepaald de scenarios waar een gemiddelde webbouwer mee te maken krijgt, en succes met het parsen van "this shitty website doesn't work on my iPhone", laat staan het oplossen.

Hangt er vanaf welke constraints je de AI geeft.
Een "send nuke to iphone" kan een prima out of the box AI oplossing zijn

[Koenvh]

WordPress en Joomla hebben ook veel invloed gehad op de werkgelegenheid. Nu heeft je kapper/pizzeria/bakker geen programmeur meer nodig; met één druk op de knop heb je WordPress geïnstalleerd, en kun je je hele website bij elkaar klikken. Voor €20/maand betaal je geen programmeur.

Maar volgens mij zijn de meeste programmeurs daardoor niet zonder werk komen te zitten, dus ik verwacht ook niet dat dat wel zo zal zijn als de oppermachtige AI komt

[Ed Vertijsment]

Ik heb ook niet de indruk dat ai programmeurs zonder werk gaat zetten. Maar who knows. Wat ik, in mij beperkte ervaring ervaren heb is dat het moeilijkste vaak is is om requirements duidelijk te krijgen. Dan is het dus simpelweg niet genoeg dat een AI die kan omzetten in code. Het formuleren van die vraag is iets wat de klant nog zelf moet doen, maar die kan dat (redelijk vaak) niet alleen zonder begeleiding.

En zelfs dan heeft een klant het voor elkaar gekregen om een functionaliteit uit te leggen in een zin:

"Ik wil een blauwe homepage met het logo links en rechts een foto van ons team en onder onze visie."

dan moet de AI iets fabriceren wat de corporate branding toets van marketing doorstaat. Om dat te doen kan de zin dan weer aangepast worden naar:

"Ik wil een blauwe homepage met het logo links, met daaromheen witruimte van die gelijk is aan de hoogte van het logo en rechts een foto van ons team met een slagschaduw en daaronder onze visie in het juiste lettertype."

Je bent al snel CSS aan het opschrijven in een natuurlijke taal... Weinig meerwaarde.

Verder ben ik vrij sceptisch over het volgende:

Een AI leert doorgaans, en dus vermoed ik dat over tijd dezelfde input (vraag) kan leiden tot een verschillend resultaat. Dat maakt het dus lastig om reproduceerbare build te onderhouden en te innoveren op het zelfde moment.

Dat is natuurlijk wel een beetje een beetje een aanname en misschien sla ik hier de plank mis maar ik vermoed dat ai erg in de weg kan zitten, en daarmee fatsoenlijk om kunnen gaan vrij snel op de werkzaamheden van een programmeur kan gaan lijken.

Low code is ook een interessante ontwikkeling, ik vraag me alleen of het niet het nieuwe excel gaat worden waarin gigantische domein specifieke kennis in een file format wordt uitgedrukt die later niet goed meer te supporten is en gigantisch lastig te migreren als de oorspronkelijk auteur weg is bij het bedrijf.

[armageddon_2k1]

Vind Tesla een mooi voorbeeld hier.
Zij proberen full-autonomous-driving te maken middels machine learning en hebben daar al 1.9miljard kilometers opzitten om te trainen. De use-case is makkelijk want verkeersregels zijn aan te leren aan pubers en een auto kunnen ze in een paar weekjes besturen.

Echter, de waarheid is wat weerbastiger.

Programmeren is vele malen complexer, dus ik zie het niet zo snel gebeuren. Programmeurs moeten hun hele leven bijleren. Sommige taken zeker wel, zoals automatisch genereren van goede helperfiles of serializaties of weet ik wat nog meer.... maar verder.....ik moet het zien.

Famous last words natuurlijk.

[gekkie]

Meh Test Driven Development en er dan een GAN op zetten om het te brute-forcen.

Heb je alleen nog iemand nodig om de tests te schrijven, maarja details hou je toch en je kunt er ongetwijfeld een flinke zak onderzoeksgeld mee binnen hengelen en een paar jaar van hobby'en als je in de juiste kringen verkeerd.

[RayNbow]

Je moet gewoon zorgen dat je je programma automatisch kunt afleiden op basis van je type signatures.

[SPee]

Zeven jaar geleden werd er bij mijn werkgever al een tool ontwikkeld voor SMART requirements. Dat was ook een tool om van tekst (requirements) een applicatie te maken. Uiteindelijk is het maar door een paar klanten gebruikt.
Voor zover ik weet doet mijn werkgever er niets meer mee.
Ik weet wel dat een paar collega's zijn weggegaan om dit verder te ontwikkelen.
Die tool kon al meer wat ik in het voorbeeld zag. En ook daarvan was de hoop dat het de ontwikkelaars overbodig zou maken. Of iig sneller kunnen opleveren.

En dan heb ik het nog niet gehad over mijn stage, 16 jaar geleden. Dat bedrijf ontwikkelde een tool voor Model Driven Architecture. Door middel van UML modellen en code generators kon je ook een applicatie ontwikkelen. En guess what? Daar zijn ze mee gestopt! Er zijn zelfs vrij weinig tools die meer genereren dan code voor Dao en entities.

Dus laten we ons vooral niet bang maken.
Zolang de business niet de requirements (goed) weet op te stellen, er (ongedocumenteerde) non-functionals zijn en het oude systeem ook nog moet werken, zitten we goed.
Een anders komt vanzelf de vraag dat ze niet weten hoe die nieuwe tool werkt en of wij dat niet kunnen doen

[Wilf]

Zolang de meerderheid van de mensen niet eens simpele conditionals in Opdrachten of Bixby ingesteld krijgen en dat ook niet eens willen kunnen denk ik dat we nog wel veilig zitten in deze specifieke dienstensector

Bovendien heb ik als taalhobbyist vrij vroeg geleerd dat het leren, verstaan, spreken en schrijven van een taal iets anders is dan het wérkelijk begrijpen ervan.

Het is niet voor niets dat taalwetenschap ook een sociaal-culturele studie is.

[Mugwump]

armageddon_2k1 schreef op maandag 20 juli 2020 @ 20:17:
Vind Tesla een mooi voorbeeld hier.
Zij proberen full-autonomous-driving te maken middels machine learning en hebben daar al 1.9miljard kilometers opzitten om te trainen. De use-case is makkelijk want verkeersregels zijn aan te leren aan pubers en een auto kunnen ze in een paar weekjes besturen.

Echter, de waarheid is wat weerbastiger.

Programmeren is vele malen complexer, dus ik zie het niet zo snel gebeuren. Programmeurs moeten hun hele leven bijleren. Sommige taken zeker wel, zoals automatisch genereren van goede helperfiles of serializaties of weet ik wat nog meer.... maar verder.....ik moet het zien.

Famous last words natuurlijk.

Nou ja, complexiteit is ook "in the eye of the beholder" natuurlijk. Wij vinden schaken misschien ook een veel complexere taak dan wat dozen van verschillende formaten bij elkaar rapen in een magazijn en stabiel op een container stapelen, maar voor AI is dat eerder omgekeerd.

[Koenvh]

RayNbow schreef op maandag 20 juli 2020 @ 21:05:
Je moet gewoon zorgen dat je je programma automatisch kunt afleiden op basis van je type signatures.

Of je geeft gewoon aan aan welke condities je antwoord moet voldoen, en dan vindt 'ie zelf uit hoe die bij het antwoord moet komen.
Zou leuk zijn als ik een keer m'n Prolog-vaardigheden in de praktijk zou kunnen toepassen, maar tot nu toe heeft die situatie zich niet voorgedaan.

[Immutable]

Mugwump schreef op maandag 20 juli 2020 @ 14:59:
[...]


Die tool gooit voor zover ik het begrijp de toch echt gewoon een natural language query richting de API. Het is geen zelfgebouwd tooltje dat wat basale parsing doet. Ik had een verzoekje ingediend om toegang om eens te kijken hoe flexibel het is.

GTP-3 is voornamelijk een few-shot learning AI. Je geeft hem een paar voorbeelden, en kan uit die "paar" voorbeelden complete concepten leren. En dus daaruit allerlei zaken genereren.

Omdat GTP-3 de grootste AI model is dat er bestaat met de meeste parameters, komt deze AI dichtbij een volgende niveau van AI. Waar deze model "concepten" kan leren/onthouden in plaats van gewoon het patroon van een string kan herkennen.

Het is als volgt: Je zegt tegen een AI 1+1=2. En je hebt een simpele AI met weinig parameters. (Zie het als een dier met weinig neurons) hij kan dan het patroon herkennen van 1+1=2 alsof hij een string geparst krijgt. als "1+1=2".

Wat GTP-3 kan door zijn gigantische parameter set is, de complete CONCEPTEN van wiskunde leren waardoor hij ook nieuwe wiskundige problemen kan oplossen die hem voorheen niet zijn aangeleverd. Maar door het leren heeft hij in plaats van patroonherkenning het patroon/concept van echt wiskunde aangeleerd.

Met de programmeer voorbeelden heeft die Sharif Shameem maar enkele programmeer voorbeelden voorgeschoteld aan de AI. Het is namelijk een "few-shot AI" die met heel weinig voorbeelden, veel output kan genereren. Omdat GTP-3 veel beter is om op een soort hoger abstracter manier concepten te kunnen herkennen.

Dit is waar uiteindelijk AI naar toe gaat als we gigantische sterke computers hebben. Dit is ook waarom wij als mens anders zijn als dieren. Ooit je eens afgevraagd waarom wij anders zijn als dieren?

Ik ben best onder de indruk van dat we een AI hebben dat lijkt hogere concepten aan te kunnen leren, dan alleen simpel patroon herkennen. Niemand hier blijkbaar.
Het gaat echt niet onze baan vervangen, echter ik zie het als een krachtige hulp naast ons. Misschien wel in onze IDE. Als een soort "clippy 2.0". (heb ik het niet over clippy in de rust compiler)

[ Voor 12% gewijzigd door Immutable op 21-07-2020 11:25 ]

[Immutable]

gekkie schreef op maandag 20 juli 2020 @ 13:07:

Ben benieuwd hoe goed die is .

Niet zo goed, je kan gewoon met tensor flow lite trainen op basis van simpele patronen. Men noemt het AI, maar het is echter gewoon een stukje hardware waarin je een voorgetraind neural netwerkje laad welke je op je PC traint. Wil dit uiteindelijk gebruiken in mijn home automation en dan overal camera's in mijn huis plaatsen.

Ik wil dan 1. Hij moet mij herkennen en op basis van mijn herkenning bepaalde acties kunnen doen of dit als voorwaarde gebruiken in verdere logica.
2. Hij moet gestures kunnen herkennen, zoals bewegingen waar weer acties aan gekoppeld zijn.

Ben bezig nog met het opzetten van mijn Home Automation idee. Wil dit doen op basis van Eclipse Cyclone DDS als "distributed data space" En dan op basis van die distributed data space dat dan draait op verschillende ARM processors daar weer gedistributeerde applicaties laten draaien. (Jammer dat er geen DDS implementatie in Rust is...)

Wil echt heel graag alles in Rust programmeren, maar het ecosysteem in de embedded wereld is zo klein. Daar is alles in C / C++. Zit te kijken of er een Rust interface is met eclipse cyclone DDS. Of dat het misschien makkelijk is om op basis van FFI daar een koppeling tussen te maken.

Daarnaast als GUI wil ik graag Flutter gaan gebruiken, en deze via gRPC of FFI met Rust backend laten communiceren. (Flutter omdat het op Linux/Windows/OSX/iOS/Android & op het web kan draaien fia flutter-web) Ik wou eerst QT of Electron gebruiken, maar Flutter is breder toepasbaar en betere performance.

Veel te groot project eigenlijk majha. Daarom wil ik dus ook die "edge computing patroon herkenning"(Op microcontrollers) gebruiken om signalen te genereren naar ARM hoofdnodes die weer DDS draaien en die weer via een MESH netwerk met elkaar via distributed data space met elkaar praten. DDS heeft geweldige QoS.

Patroonherkenning is wel mooi voor homeautomation dus om signalen te genereren dus aan de "edge" van het home automation idee.

[CodeCaster]

Immutable schreef op dinsdag 21 juli 2020 @ 11:20:
Ik ben best onder de indruk van dat we een AI hebben dat lijkt hogere concepten aan te kunnen leren, dan alleen simpel patroon herkennen. Niemand hier blijkbaar.

Ik zie geen bewijs dat als je dat ding alle HTML van de wereld voert maar met radiobuttons uitgesloten, dat de AI zelf een radiobutton gaat bedenken. En wat voor nut heeft het om een AI foto's te voeren van een miljoen verschillende tafels, en dat 'ie op een gegeven moment plaatjes gaat genereren van iets met een soort van vlakke bovenkant en tussen de één en dertig poten? Waarom is "veel output" de heilige graal?

Een van de voorbeelden die ik vind op "few shot learning AI", is dat het een voorgeleerd netwerk heeft van hoe een hoofd eruitziet, en dat 'ie op basis van één of een paar foto's een realistische deepfake kan genereren van dat hoofd. Dát zijn leuke toepassingen, maar dat is nog steeds geen AI die je een miljard optelsommen geeft, en die zichzelf dan algebra gaat leren.

Er wordt een heleboel werk verricht in de AI-wereld, en ik volg dat vanaf de zijlijn en weet er nauwelijks iets van, dus neem mijn reacties met een flinke schep zout. Maar nee, zo lyrisch als jij kan ik er nog niet van worden.

[Mugwump]

Immutable schreef op dinsdag 21 juli 2020 @ 11:20:
[...]


GTP-3 is voornamelijk een few-shot learning AI. Je geeft hem een paar voorbeelden, en kan uit die "paar" voorbeelden complete concepten leren. En dus daaruit allerlei zaken genereren.

Omdat GTP-3 de grootste AI model is dat er bestaat met de meeste parameters, komt deze AI dichtbij een volgende niveau van AI. Waar deze model "concepten" kan leren/onthouden in plaats van gewoon het patroon van een string kan herkennen.

Het is als volgt: Je zegt tegen een AI 1+1=2. En je hebt een simpele AI met weinig parameters. (Zie het als een dier met weinig neurons) hij kan dan het patroon herkennen van 1+1=2 alsof hij een string geparst krijgt. als "1+1=2".

Wat GTP-3 kan door zijn gigantische parameter set is, de complete CONCEPTEN van wiskunde leren waardoor hij ook nieuwe wiskundige problemen kan oplossen die hem voorheen niet zijn aangeleverd. Maar door het leren heeft hij in plaats van patroonherkenning het patroon/concept van echt wiskunde aangeleerd.

Met de programmeer voorbeelden heeft die Sharif Shameem maar enkele programmeer voorbeelden voorgeschoteld aan de AI. Het is namelijk een "few-shot AI" die met heel weinig voorbeelden, veel output kan genereren. Omdat GTP-3 veel beter is om op een soort hoger abstracter manier concepten te kunnen herkennen.

Dit is waar uiteindelijk AI naar toe gaat als we gigantische sterke computers hebben. Dit is ook waarom wij als mens anders zijn als dieren. Ooit je eens afgevraagd waarom wij anders zijn als dieren?

Ik ben best onder de indruk van dat we een AI hebben dat lijkt hogere concepten aan te kunnen leren, dan alleen simpel patroon herkennen. Niemand hier blijkbaar.

Ik weet op hoofdlijnen wel hoe het werkt hoor. Vandaar ook dat ik altijd de grote beperkingen nog wel zie.
Allereerst maak je het onderscheid tussen 'simpele patronen' en 'hogere concepten'. Fantastisch die hogere concepten, maar hoe goed kan hij dat nou echt? Als ik de eerder door mij aangehaalde voorbeelden er weer bij pak, dan lijkt het nog wel tegen te vallen met dat 'echt begrijpen' van concepten.
Zo 'denkt' GPT-3 dat een potlood zwaarder is dan een broodrooster / tosti-ijzer. Dat geeft toch niet heel veel blijk van het begrijpen van concept als massa en dichtheid.
Zoals Lacker ook aangeeft lijkt het er nog meer op dat vooral het internet als knowledge base effectief wordt ingezet, maar echt abstract redeneren ontbreekt. Dat wordt al helemaal duidelijk bij dit soort voorbeelden:

Human: How many eyes does my foot have?

GPT-3: Your foot has two eyes.

Kijk het hele idee van patroonherkenning is uiteindelijk gewoon generalisatie naar onbekende gevallen. Zonder die stap zou het een waardeloos concept zijn. GPT-3 lijkt wel weer een paar stappen verder te zijn dan voorgangers, maar laten we ook niet doen alsof dit nu volkomen revolutionair is.

Het is ook altijd belangrijk om te kijken of we hier niet juist post-hoc projectie aan het doen zijn. Een AI die Go of Starcraft speelt kun je ook wel allerlei geniale strategische inzichten en tactieken toedichten, maar is dat echt het geval of is dat juist weer het patroon dat wij denken te zien? Als mensen namelijk ook ergens goed in zijn, dan is het wel in patronen zien waar ze er niet zijn.

[RayNbow]

Ben benieuwd of (wanneer?) zo'n AI een query als onderstaande kan beantwoorden:

Ik wil een (non-triviale) functie met als type Functor f => f (f a -> a) -> f a.

(Mocht men moeite hebben met het lezen van het bovenstaande type, hier is iets min of meer vergelijkbaars in C#:
Func<
  IEnumerable<Func<IEnumerable<T>, T>>
  IEnumerable<T>
>)

[begintmeta]

@Mugwump,

Human: How many eyes does my foot have?

GPT-3: Your foot has two eyes

Op zich kan dat best een correct antwoord zijn,zou ik zeggen (tenminste, ik denk wel wat interpretaties te zien die dat impliceren) maar ook incorrect, hangt allemaal af van zaken buiten dat vraag-antwoordkoppel, daar zou je dan over moeten doorvragen. Je zou GPT-3 dan ook vervolgvragen moeten stellen (waarom dat antwoord bijvoorbeeld), en ik denk dat het dan lastig wordt.

[ Voor 28% gewijzigd door begintmeta op 21-07-2020 12:02 ]

[Immutable]

Mugwump schreef op dinsdag 21 juli 2020 @ 11:51:
[...]


Ik weet op hoofdlijnen wel hoe het werkt hoor. Vandaar ook dat ik altijd de grote beperkingen nog wel zie.
Allereerst maak je het onderscheid tussen 'simpele patronen' en 'hogere concepten'. Fantastisch die hogere concepten, maar hoe goed kan hij dat nou echt? Als ik de eerder door mij aangehaalde voorbeelden er weer bij pak, dan lijkt het nog wel tegen te vallen met dat 'echt begrijpen' van concepten.
Zo 'denkt' GPT-3 dat een potlood zwaarder is dan een broodrooster / tosti-ijzer. Dat geeft toch niet heel veel blijk van het begrijpen van concept als massa en dichtheid.
Zoals Lacker ook aangeeft lijkt het er nog meer op dat vooral het internet als knowledge base effectief wordt ingezet, maar echt abstract redeneren ontbreekt. Dat wordt al helemaal duidelijk bij dit soort voorbeelden:


[...]


Kijk het hele idee van patroonherkenning is uiteindelijk gewoon generalisatie naar onbekende gevallen. Zonder die stap zou het een waardeloos concept zijn. GPT-3 lijkt wel weer een paar stappen verder te zijn dan voorgangers, maar laten we ook niet doen alsof dit nu volkomen revolutionair is.

Het is ook altijd belangrijk om te kijken of we hier niet juist post-hoc projectie aan het doen zijn. Een AI die Go of Starcraft speelt kun je ook wel allerlei geniale strategische inzichten en tactieken toedichten, maar is dat echt het geval of is dat juist weer het patroon dat wij denken te zien? Als mensen namelijk ook ergens goed in zijn, dan is het wel in patronen zien waar ze er niet zijn.

Klopt maar wij mensen herkennen ook hogere concepten en maken ook nog steeds fouten. Dus het ene sluit het andere toch niet uit ? Dat is ook het probleem bij AI in autonoom rijden. We willen dat het 100% correct reageerd. (Gaat niet gebeuren) maar zelfs een AI dat hogere concepten kan herkennen zal fouten maken. Of denk je dat dit niet los van elkaar staat?

Ben het eens dat het mogelijk kan zijn dat een AI een patroon ziet, die wij niet eens kunnen herkennen zoals bij de E-sports zoals jij aangeeft.

Het is inderdaad maar een "stapje", vond het wel een indrukwekkende stapje naar een nog indrukwekkendere toekomst waar het heen gaat. Nee het is geen revolutie, het is duidelijk een "flinke" evolutie. Helemaal met jou eens.

Maar het lijkt mij gewoon leuk dat ik tegen mijn home automation kan zeggen: "Huis, stel in wanneer ik thuis kom, lichten aan". Dat je je home automation kunt "programmeren" en dingen aanleren door er tegen te praten. In plaats van hoe het tegenwoordig werkt, waar alles voorgeprogrammeert moet worden via code en of door de programmeur bij "mercedes" in een mercedes.

[Mugwump]

Immutable schreef op dinsdag 21 juli 2020 @ 12:02:
[...]


Klopt maar wij mensen herkennen ook hogere concepten en maken ook nog steeds fouten. Dus het ene sluit het andere toch niet uit ? Dat is ook het probleem bij AI in autonoom rijden. We willen dat het 100% correct reageerd. (Gaat niet gebeuren) maar zelfs een AI dat hogere concepten kan herkennen zal fouten maken. Of denk je dat dit niet los van elkaar staat?

Het gaat ook niet om het 'nooit maken van fouten'. Het gaat om het echt begrijpen van concepten. Kijk, als je mij vraagt hoeveel ogen de rood-geel gevlekte zwaaistaartplarf heeft, dan is mijn antwoord 'geen idee, ik weet niet wat dat is', 'volgens mij verzin je dat beest ter plekke'. Als je me vraagt hoeveel ogen mijn linkerarm heeft, dan zeg ik gewoon nul. Ik snap de concepten 'linkerarm' en 'ogen' namelijk in de context waarin ze gebruikt worden. Deze AI overduidelijk niet.

Ben het eens dat het mogelijk kan zijn dat een AI een patroon ziet, die wij niet eens kunnen herkennen zoals bij de E-sports zoals jij aangeeft.

Het is inderdaad maar een "stapje", vond het wel een indrukwekkende stapje naar een nog indrukwekkendere toekomst waar het heen gaat. Nee het is geen revolutie, het is duidelijk een "flinke" evolutie. Helemaal met jou eens.

Maar het lijkt mij gewoon leuk dat ik tegen mijn home automation kan zeggen: "Huis, stel in wanneer ik thuis kom, lichten aan". Dat je je home automation kunt "programmeren" en dingen aanleren door er tegen te praten. In plaats van hoe het tegenwoordig werkt, waar alles voorgeprogrammeert moet worden via code en of door de programmeur bij "mercedes" in een mercedes.

Natuurlijk, we willen allemaal zo'n Star Trek AI die gewoon doet wat we zeggen als het 'menselijk begrip' van zaken heeft.

[Mugwump]

begintmeta schreef op dinsdag 21 juli 2020 @ 11:57:
@Mugwump,

[...]

Op zich kan dat best een correct antwoord zijn,zou ik zeggen (tenminste, ik denk wel wat interpretaties te zien die dat impliceren) maar ook incorrect, hangt allemaal af van zaken buiten dat vraag-antwoordkoppel, daar zou je dan over moeten doorvragen. Je zou GPT-3 dan ook vervolgvragen moeten stellen (waarom dat antwoord bijvoorbeeld), en ik denk dat het dan lastig wordt.

In welke context zou dit een correct antwoord zijn volgens jou?

[gekkie]

Immutable schreef op dinsdag 21 juli 2020 @ 11:40:
[...]
Ik wil dan 1. Hij moet mij herkennen en op basis van mijn herkenning bepaalde acties kunnen doen of dit als voorwaarde gebruiken in verdere logica.
2. Hij moet gestures kunnen herkennen, zoals bewegingen waar weer acties aan gekoppeld zijn.

Met de gordijnendicht spannende dansjes uitvoeren ?
Anders belt de niet helemaal AI ingevoerde buurvrouw de GGZ nog, verwarde man gesignaleerd

[gekkie]

CodeCaster schreef op dinsdag 21 juli 2020 @ 11:47:
[...]
Waaom is "veel output" de heilige graal?

Als je dan goed zoekt zit er vast wel wat acceptabele output tussen waar wij weer een mooi patroon en esthetiek in zien. Die indruk krijg ik bijvb bij de proza-schrijvende AI.

[Wilf]

Uiteindelijk blijft AI bouwen ook mensenwerk en zullen (sowieso voorlopig) de concepten van de maker ook de concepten van de AI zijn. Dan komen we weer uit op taal.

Waarom zijn de verzonnen talen in Star Wars en Star Trek zo gelijkend aan Engels? Waarom is er gezichtsherkenningssoftware die alleen blanke gezichten weet te herkennen? Waarom zou AI wel het concept van Westerse kleuren kennen (in sommige talen/culturen zijn bepaalde kleuren non-existent en zien mensen die dus ook anders / niet) en niet de conceptuele en culturele betekenis van kleuren in andere culturen (zoals in China)?

AI gebaseerd op tools die wij als mens hebben gecreëerd zijn een afspiegeling van ons als mens omdat wij ons verhouden tot de wereld als mens en in die hoedanigheid ook concepten definiëren; wis- en natuurkunde, taal, cultuur, zintuiglijke waarneming (ons bekende spectra) en de communicatie onderling (ook tussen AI en ons) zijn daardoor per definitie gekleurd en beïnvloed door de cultuur van de AI-programmeurs en hun beeld van de wereld en concepten. Dit maakt AI (voorlopig) zeer eenzijdig en minstens zo dom als wij.

[begintmeta]

Mugwump schreef op dinsdag 21 juli 2020 @ 12:21:
[...]


In welke context zou dit een correct antwoord zijn volgens jou?

Als je veronderstelt dat alle delen die met elkaar een lichaam vormen (direct of eventueel indirect, via het geheel) van elkaar zijn.

Ik denk dat ik zelf als ik de vraag zou krijgen zou vragen wat de vraagsteller bedoelt, maar als ik een antwoord zou moeten geven, kan ik me voorstellen dat dat 'geen of 2' zou kunnen zijn (maar, toegegeven, waarschijnlijk niet zal zijn). Maar goed, dat is zonder er enorm over te hebben nagedacht...

[ Voor 5% gewijzigd door begintmeta op 21-07-2020 13:52 ]

[Mugwump]

begintmeta schreef op dinsdag 21 juli 2020 @ 13:32:
[...]

Als je veronderstelt dat alle delen die met elkaar een lichaam vormen (direct of eventueel indirect, via het geheel) van elkaar zijn.

Ik denk dat ik zelf als ik de vraag zou krijgen zou vragen wat de vraagsteller bedoelt, maar als ik een antwoord zou moeten geven, kan ik me voorstellen dat dat 'geen of 2' zou zijn. Maar goed, dat is zonder er enorm over te hebben nagedacht...

Ik weet niet, dat is toch geen interpretatie die ik iemand met semantisch begrip ooit zou zien maken. Als ik vraag hoeveel wielen een autostuur heeft, zal er ook niemand vier antwoorden.

[begintmeta]

Mugwump schreef op dinsdag 21 juli 2020 @ 13:49:
[...]


Ik weet niet, dat is toch geen interpretatie die ik iemand met semantisch begrip ooit zou zien maken. Als ik vraag hoeveel wielen een autostuur heeft, zal er ook niemand vier antwoorden.

De vragen verschillen ook een beetje qua impliciete context. Bij "Als ik vraag hoeveel wielen een autostuur heeft," zit geen impliciete context van een samenhangend geheel, een auto. Het zou een autostuur kunnen zijn dat gewoon ergens op een tafel ligt.

Bij "How many eyes does my foot have?" is de context om 'foot', in ieder geval als ik de vraag stel, duidelijker gegeven. Dat het over voeten en ogen in de context van mijn lichaam (in plaats van die op sterk water in de kast) zou gaan is wat plausibeler.

Maar dat zou niet zo'n grote rol spelen denk ik. De context waarin ik degene die vraagt zie zou misschien relevanter zijn.

Als iemand van wie ik een sterk vermoeden heb dat diegene weet hoe auto, autostuur en wielen normaalgesproken aan elkaar gerelateerd zijn me zou vragen hoeveel wielen een autostuur heeft, zou ik me vooral afvragen waarom diegene mij die vraag stelt. En dat dan vervolgens vermoedelijk vragen/vragen hoe de vraag bedoeld is. (of, vermoedelijk, '0' zeggen)

Als ik ervanuitga dat iemand geen idee heeft wat een autostuur of wielen zijn, zou een direct antwoord '0' veel voordehandliggender zijn.

Als ik de vraag stel en iemand geeft een voor mij onverwacht antwoord, zou ik vooral geneigd zijn om na te gaan waarom iemand mij dat antwoord heeft gegeven. En dus navragen waarom dat antwoord gegeven is. Ik zou dus geneigd zijn om GPT-3 te vragen waarom het dat antwoord gegeven heeft. (en dan vermoedelijk ook weer een niet direct navolgbaar antwoord krijgen)

Als ik de vraag stel zonder dat ik een idee heb van wat stuur of wielen zijn, en dus geen verwachting zou hebben ten aanzien van het te geven antwoord, zou ik me waarschijnlijk pas echt kunnen afvragen of het antwoord juist is als ik intersubjectieve inconsistenties waarneem (bijvoorbeeld door zelf een autostuur (en eventueel wielen) te zien en niet meer snap waarom het antwoord 4 gegeven is, of als iemand anders 0 heeft gezegd...)

[CodeCaster]

We kunnen allemaal wel blijven inhaken op die ogen, maar speculaasies zijn voor bij de koffie. We weten niet hoe dat ding tekst verwerkt.

For all we know heeft dat ding een handleiding ingeslikt voor afdekzeil, waar zich per strekkende meter zeven ogen om touw aan vast te knopen in bevinden. Hoeveel ogen per voet? Nou, twee.

Ik vond deze ook wel interessant:

[ Voor 26% gewijzigd door CodeCaster op 21-07-2020 14:23 ]

[begintmeta]

CodeCaster schreef op dinsdag 21 juli 2020 @ 14:21:
We kunnen allemaal wel blijven inhaken op die ogen, maar speculaasies zijn voor bij de koffie. We weten niet hoe dat ding tekst verwerkt.
...

Precies, en daarom zou GPT-3 dan volgens mij ook om verheldering moeten worden gevraagd. Waarom dat antwoord?

Ik weet ook niet hoe een ander mens tekst verwerkt, maar opgrond van ervaring denk ik er redelijk vanuit te kunnen gaan dat dat grotendeels overeenkomt met hoe ik dat doe. Echter, als er vermeende inconsistenties zijn, zit er weinig anders op dan nagaan waarom die er zouden zijn. En navragen is daarbij ook in dat geval een voordehandliggend middel.

[armageddon_2k1]

Waarom ben ik in mijn werk hartstikke pragmatisch maar in mijn hobbyprojecten een architectuursalafist?

Moeilijke complexe problemen lossen we op werk incrementeel op en dat gaat vrij goed, en ook mijn individuele taken doe ik goed.

Maar ik ben bezig om mijn eigen financieen-appje te maken en ik stuiter al maanden van de ene taalkeuze naar de andere architectuurkeuze en weer terug:
- Kotlin backend en Kotlin/JS frontend
- Scala backend en Scala.js frontend
- Scala backend en React frontend
- Puur Kotlin met Ktor webserver die gewoon HTML rendert
- Eventjes Rust
- Kotlin backend maar weer en Kotlin/JS frontend, maar nu functioneel

Nu ik opeens aan het lezen ben over Kleisli composition besef ik me dat ik weer iets te ver doorgeschoten ben.....

[wackmaniac]

armageddon_2k1 schreef op woensdag 22 juli 2020 @ 13:06:
Waarom ben ik in mijn werk hartstikke pragmatisch maar in mijn hobbyprojecten een architectuursalafist?

Omdat het kan Op het werk zit er druk op, bij mijn hobby-projecten niet. Ik kan ook weken alleen maar nadenken over hoe ik iets het mooist/slimst/best/meest elegant kan oplossen om het uiteindelijk in een uurtje te implementeren. Is voor mijn persoonlijk juist de charme van hobby-projecten.

[armageddon_2k1]

Okee, dan heb ik zojuist een nieuw top idee bedacht.

Een dienst die je in kan huren om je te bellen en net te doen alsof ze een klant zijn, of een sales persoon en de druk opvoeren op je hobbyprojecten. "Ja, 1 augustus willen we een demo laten zien.... je had gezegd dat het snel klaar zou zijn" of "Ik heb voor een aanbesteding functie X nodig, wanneer denk je die te hebben? Oh, ik moet het volgende week hebben". Een dienst voor developers om hun hobbyprojecten vooruit te helpen.

Ik noem hem: "Crunchtime, the masochistic service for fundamentalist solo developers."

[Tjolk]

Just leaving this here...

[Hydra]

armageddon_2k1 schreef op woensdag 22 juli 2020 @ 13:06:
Waarom ben ik in mijn werk hartstikke pragmatisch maar in mijn hobbyprojecten een architectuursalafist?

Ik vind m'n 'CTO' rol die ik nu heb naast m'n gewone werk daarin wel leerzaam. Je gaat met een hele andere bril naar dit soort dingen kijken, terwijl het toch volledig je 'eigen' project is. M'n primaire concern is; hoe krijg ik snel iets af zonder shortcuts te nemen waar ik spijt van krijg. M'n secundaire concern is kosten.

Het is dus 'gewoon' een Spring Boot service, in Kotlin (want productief) gedeployed op Google Cloud Run (want goedkoop). Security gaat via Firebase Auth; want security wil ik echt niet zelf bouwen.

Dit heeft me geholpen om ook in die mindset te kruipen voor andere projectjes. Beetje een "what would Jezus do" maar dan developer-Jezus met te weinig tijd

[PrisonerOfPain]

armageddon_2k1 schreef op woensdag 22 juli 2020 @ 13:06:
Waarom ben ik in mijn werk hartstikke pragmatisch maar in mijn hobbyprojecten een architectuursalafist?

In mijn ervaring gaan mensen aan het begin architecture bouwen als ze niet duidelijk weten wat ze moeten maken. Misschien gewoon zorgen dat je dat duidelijker voor jezelf hebt?

[armageddon_2k1]

PrisonerOfPain schreef op woensdag 22 juli 2020 @ 16:10:
[...]


In mijn ervaring gaan mensen aan het begin architecture bouwen als ze niet duidelijk weten wat ze moeten maken. Misschien gewoon zorgen dat je dat duidelijker voor jezelf hebt?

Dat klopt helemaal. Architectuur zijn de moeilijke beslissingen die je niet snel kan veranderen later, dus om die voorop te doen is sowieso niet goed. Ik ga het eens iets rustiger uitwerken :-)

Maar het is ook de technologie-ADHD waar ik elke keer iets nieuws wil proberen. Het is super leerzaam, dat wel, maar praktisch krijg ik niks voor elkaar.

[RagingPenguin]

armageddon_2k1 schreef op woensdag 22 juli 2020 @ 16:17:
Maar het is ook de technologie-ADHD waar ik elke keer iets nieuws wil proberen. Het is super leerzaam, dat wel, maar praktisch krijg ik niks voor elkaar.

Ligt het er dan niet aan dat je eigenlijk helemaal niet zo geïnteresseerd bent in je hobby projecten, maar in het uitproberen van nieuwe technologieën? Zelf heb ik dat ook, ik begin een project en zodra ik op het punt kom dat ik alle interessante uitdagingen heb overkomen stop ik er mee. Het gevolg is dat m'n hele github vol staat met dingen die super interessant zijn, maar ook allemaal half af zijn.

Wat ik tegenwoordig vaak doe is als doel stellen dat ik een artikel over technologie X wil schrijven wat mij dan dwingt om iig iets af te maken zodat ik het als voorbeeld kan gebruiken. Het maakt dan ook niet meer uit dat het geen heel project is, het is immers maar een barebone voorbeeld dat bij een artikel hoort.

[Matis]

armageddon_2k1 schreef op woensdag 22 juli 2020 @ 16:17:
Dat klopt helemaal. Architectuur zijn de moeilijke beslissingen die je niet snel kan veranderen later, dus om die voorop te doen is sowieso niet goed. Ik ga het eens iets rustiger uitwerken :-)

Maar het is ook de technologie-ADHD waar ik elke keer iets nieuws wil proberen. Het is super leerzaam, dat wel, maar praktisch krijg ik niks voor elkaar.

Ik herken me er ook wel in hoor.

Maar mijn gevoel heeft er vaak mee te maken, omdat het een eenmans-project is, je geen sparring partner hebt om het concept eerst goed uit te werken. Als je dezelfde flow zou aanhouden als zakelijk, dus eerst de requirements, dan de documentatie, dan de technische uitwerkingen, het opknippen, het inschatten, het bouwen, testen, opleveren etc etc dan zou je al veel "realistischer" je eigen werk kunnen vergelijken.

Daarnaast zijn (en nu spreek ik puur voor mijzelf) mijn eigen projectjes vaak zo klein, dat ze (bij wijze van spreke) gewoon in 1 sourcefile kunnen.
Maar omdat ik een architectuur "moet" gebruiken van mijzelf, krijg ik veel verschillende mappen met interfaces, abstracte en implementatie klassen. Testen (unit, integratie) en dat alles natuurlijk met 100% coverage.

Dat is, zakelijk gezien, gewoon not done om zo'n klein project zo groots op te zetten.

[armageddon_2k1]

RagingPenguin schreef op woensdag 22 juli 2020 @ 16:50:
[...]Zelf heb ik dat ook, ik begin een project en zodra ik op het punt kom dat ik alle interessante uitdagingen heb overkomen stop ik er mee. Het gevolg is dat m'n hele github vol staat met dingen die super interessant zijn, maar ook allemaal half af zijn.

Wat ik tegenwoordig vaak doe is als doel stellen dat ik een artikel over technologie X wil schrijven wat mij dan dwingt om iig iets af te maken zodat ik het als voorbeeld kan gebruiken. Het maakt dan ook niet meer uit dat het geen heel project is, het is immers maar een barebone voorbeeld dat bij een artikel hoort.

Dat is inderdaad exact hoe het is....

Goede tip om erover te schrijven! Misschien ga ik dat ook doen. Echter ik wil gewoon heel graag eens een applicatie zelf gemaakt hebben. Ik denk dat ik het wat gestructureerder aan moet pakken.

[Woy]

Voor mij moet ik gewoon een goed doel hebben. Ik heb ook veel projectjes die voortijdig sneuvelen, maar bijvoorbeeld met vrienden doen we ook aan bierbrouwen, en daar heb ik een temperatuur gecontroleerde gistkast voor gemaakt, en daar zat een deadline achter omdat we die nodig hadden om goed te brouwen. Zo'n projectje komt dan ieder geval wel in een werkende staat. Hoewel ook daar nog wel wat verbeterpunten in bijvoorbeeld de UI mogelijk zijn, maar dat zijn details

[wackmaniac]

Ja, het blijkt nogal wat discipline te vragen om projection af te ronden. Wat ik tegenwoordig doe is de repository publiekelijk toegankelijk maken op Github. Dat voel ik me eigenlijk verplicht om het geheel tot een goed einde te brengen. Of de repository weer private te maken ...

[Hydra]

RagingPenguin schreef op woensdag 22 juli 2020 @ 16:50:
Ligt het er dan niet aan dat je eigenlijk helemaal niet zo geïnteresseerd bent in je hobby projecten, maar in het uitproberen van nieuwe technologieën? Zelf heb ik dat ook, ik begin een project en zodra ik op het punt kom dat ik alle interessante uitdagingen heb overkomen stop ik er mee. Het gevolg is dat m'n hele github vol staat met dingen die super interessant zijn, maar ook allemaal half af zijn.

Wat ik tegenwoordig vaak doe is als doel stellen dat ik een artikel over technologie X wil schrijven wat mij dan dwingt om iig iets af te maken zodat ik het als voorbeeld kan gebruiken. Het maakt dan ook niet meer uit dat het geen heel project is, het is immers maar een barebone voorbeeld dat bij een artikel hoort.

Ja, precies. Dat doe ik dus met mijn blog (laatste tijd niet echt meer iets mee gedaan maargoed). Dat is dan een stok achter de deur om het klein te houden en af te maken.

[alienfruit]

Firebase Hosting is ook een drama zeg. Een domein aangemaakt nu zit mijn domein met tien andere domeinen (van onbekenden) in een SSL certificaat. Firebase Hosting is duidelijk niet bedoelt voor demo doeleinden.

[ Voor 4% gewijzigd door alienfruit op 23-07-2020 11:02 ]

[Voutloos]

Als er bespaard wordt op gratis certificaten, vraag ik me af waar het dan wel geschikt voor kan zijn.

[Woy]

alienfruit schreef op donderdag 23 juli 2020 @ 11:02:
Firebase Hosting is ook een drama zeg. Een domein aangemaakt nu zit mijn domein met tien andere domeinen (van onbekenden) in een SSL certificaat. Firebase Hosting is duidelijk niet bedoelt voor demo doeleinden.

Wacht, Google doet voor custom domains aan "Certificate Pooling" ( Term die ik net bedenk ), waar totaal ongerelateerde domains in de Subject Alternative Name? Of zijn het allemaal sub-domains van een google domain? ( Dan nog vraag je je af waarom ze er niet een wildcard domain voor gebruiken. )

[Creepy]

Pooling lijkt het inderdaad, mijn persoonlijke domein heb ik twee weken terug verhuisd en qua certificaat staat daar ook een ongerelateerde naam in als Common Name..

[alienfruit]

Nee, ik heb een domein app.bedrijfsnaam.com en komt een certificaat met 'DNS names` na 'Subject Alternative Name' met een hele berg domeinen, als je bijvoorbeeld naar https://eventl.ist gaat en de CA bekijkt.... En ze lijken Letsencrypt te gebruiken??

[ Voor 8% gewijzigd door alienfruit op 23-07-2020 11:40 ]

[Creepy]

alienfruit schreef op donderdag 23 juli 2020 @ 11:39:
Nee, ik heb een domein app.bedrijfsnaam.com en komt een certificaat met 'DNS names` na 'Subject Alternative Name' met een hele berg domeinen, als je bijvoorbeeld naar https://eventl.ist gaat en de CA bekijkt....

Common name daarvan is www.mietowy.pl.. lijkt me een ongerelateerd domain, net als bij die van mij. En ze gebruiken letsencrypt ja

[ Voor 3% gewijzigd door Creepy op 23-07-2020 11:41 ]

[alienfruit]

Ja precies, blijkbaar krijg je alleen een aparte CA als je betaalt voor Firebase

[Creepy]

En wat uitleg daarover: https://www.reddit.com/r/...hosting_ssl_certificates/

[Marc3l]

Het side project syndroom komt mij bekend voor al heb ik wel wat projecten afgemaakt.
Nadeel daarvan is dat (bijna) niemand er van gebruikt maakt, dat is ook weer zonde.
Kom niet verder dan een social media bericht, merk dat ik dan echt een developer ben i.p.v. een marketeer.

[Immutable]

armageddon_2k1 schreef op woensdag 22 juli 2020 @ 13:06:
Waarom ben ik in mijn werk hartstikke pragmatisch maar in mijn hobbyprojecten een architectuursalafist?

Moeilijke complexe problemen lossen we op werk incrementeel op en dat gaat vrij goed, en ook mijn individuele taken doe ik goed.

Maar ik ben bezig om mijn eigen financieen-appje te maken en ik stuiter al maanden van de ene taalkeuze naar de andere architectuurkeuze en weer terug:
- Kotlin backend en Kotlin/JS frontend
- Scala backend en Scala.js frontend
- Scala backend en React frontend
- Puur Kotlin met Ktor webserver die gewoon HTML rendert
- Eventjes Rust
- Kotlin backend maar weer en Kotlin/JS frontend, maar nu functioneel

Nu ik opeens aan het lezen ben over Kleisli composition besef ik me dat ik weer iets te ver doorgeschoten ben.....

Heb je eventjes geprobeerd met Rust te programmeren ? Waarom ben je daar niet mee verder gegaan?

[PrisonerOfPain]

Immutable schreef op donderdag 23 juli 2020 @ 15:38:
[...]


Heb je eventjes geprobeerd met Rust te programmeren ? Waarom ben je daar niet mee verder gegaan?

Borrow checker, wedden?

[armageddon_2k1]

Ik vind Rust gaaf ;-) Maar ik was daar niet voor mijn hobby project mee doorgegaan maar heb de eerste 50 Eulers weer gedaan, zoals ik in meerdere talen doe.

Als je gewoon gewend bent overal referenties neer te smijten dan is het wel even wennen ja.

[.oisyn]

Ok, deze moet ik hier even delen

We hebben de laatste tijd wat last van spammers op tweakers, en een niet nader te noemen crewlid heeft een scriptje gemaakt om deze automatisch te detecteren en te bannen. Om hier toch wat controle op uit te kunnen oefenen, plaatst het script een post onder een speciaal daarvoor aangemaakte user in een crewforum. Met linkjes erbij en alles.

Nou heeft dat script alleen zijn eigen user gebanned, omdat het een nieuwe user betrof die de hele tijd linkjes postte

[hackerhater]

ROFL.
versie 1.1: uitzondering voor het botje zelf

[Matis]

.oisyn schreef op vrijdag 24 juli 2020 @ 16:41:
Ok, deze moet ik hier even delen

We hebben de laatste tijd wat last van spammers op tweakers, en een niet nader te noemen crewlid heeft een scriptje gemaakt om deze automatisch te detecteren en te bannen. Om hier toch wat controle op uit te kunnen oefenen, plaatst het script een post onder een speciaal daarvoor aangemaakte user in een crewforum. Met linkjes erbij en alles.

Nou heeft dat script alleen zijn eigen user gebanned, omdat het een nieuwe user betrof die de hele tijd linkjes postte

Wij van WC-eend verwijderen WC-eend

[Matis]

hackerhater schreef op vrijdag 24 juli 2020 @ 16:46:
ROFL.
versie 1.1: uitzondering voor het botje zelf

Of je antedateert die gebruiker

[Immutable]

armageddon_2k1 schreef op donderdag 23 juli 2020 @ 17:36:
Ik vind Rust gaaf ;-) Maar ik was daar niet voor mijn hobby project mee doorgegaan maar heb de eerste 50 Eulers weer gedaan, zoals ik in meerdere talen doe.

Als je gewoon gewend bent overal referenties neer te smijten dan is het wel even wennen ja.

Over web & rust gesproken. Ben zelf met Rust bezig om te spelen met STM32 Microcontrollers low end met een HAL... en #![no_std]. Ben meer een embedded persoon.

Had al eerder stukjes gelezen over Webassembly, maar daar is dus een soort bibliotheek genaamd YEW. Eerst nog niet naar gekeken, omdat ik dacht dat webassembly nog heel ver in de kinderschoenen stond en er geen directe toegang was tot de DOM api en andere api's. Wrong... dingen zijn al verandert.

Je kan nu dus volledig Rust gebruiken.. Acitx-web + YEW .. Ben er zelf ff niet mee bezig maar er kriebelt weer een projectje. Je kan ook echt (bijna)ALLES met rust he... niet normaal hoe Rust mij continu blijft verbazen.

Rust is een taal dat straks naast C kan staan (C parity) zelfs op Microcontrollers ... tot aan front-end. Er is volgens mij geen enkele taal die zo breed inzetbaar is en performant is als Rust. Nog wel allemaal in de kinderschoenen(Taal + Ecosysteem), maar het begint toch wel bijna eruit te stappen.

[.oisyn]

Immutable schreef op vrijdag 24 juli 2020 @ 17:29:
Er is volgens mij geen enkele taal die zo breed inzetbaar is en performant is als Rust.

C++

[KabouterSuper]

.oisyn schreef op vrijdag 24 juli 2020 @ 16:41:
Ok, deze moet ik hier even delen

We hebben de laatste tijd wat last van spammers op tweakers, en een niet nader te noemen crewlid heeft een scriptje gemaakt om deze automatisch te detecteren en te bannen. Om hier toch wat controle op uit te kunnen oefenen, plaatst het script een post onder een speciaal daarvoor aangemaakte user in een crewforum. Met linkjes erbij en alles.

Nou heeft dat script alleen zijn eigen user gebanned, omdat het een nieuwe user betrof die de hele tijd linkjes postte

Da's een mooie. De fix is duidelijk, even de where clause aanpassen

code:

and upper(username) not like '%CREW%'

[Koenvh]

Marc3l schreef op donderdag 23 juli 2020 @ 14:58:
Het side project syndroom komt mij bekend voor al heb ik wel wat projecten afgemaakt.
Nadeel daarvan is dat (bijna) niemand er van gebruikt maakt, dat is ook weer zonde.
Kom niet verder dan een social media bericht, merk dat ik dan echt een developer ben i.p.v. een marketeer.

Heel herkenbaar helaas
Daarom doe ik ook meestal dingen voor mezelf, dan zie ik 't als bonus als anderen 't ook waarderen

[kenneth]

.oisyn schreef op vrijdag 24 juli 2020 @ 17:32:
[...]

C++

Dat is geen taal, dat is een opeenvolging van talen in één spec gepropt

[Koenvh]

kenneth schreef op vrijdag 24 juli 2020 @ 18:33:
[...]

Dat is geen taal, dat is een opeenvolging van talen in één spec gepropt

Da's Engels, toch?

[Matis]

Koenvh schreef op vrijdag 24 juli 2020 @ 20:01:
Da's Engels, toch?

[PrisonerOfPain]

.oisyn schreef op vrijdag 24 juli 2020 @ 17:32:
[...]

C++

Ik gebruik inmiddels dus 2-3 jaar full-time Rust, en alleen Rust terwijl ik daarvoor jaren C++ gebruikt heb enneh, als het evan kan ga ik ook nooit C++ meer doen ook.

Het is zo fijn om een taal met safety guarantees te hebben waar je gewoon in kunt refactoren zonder bang te zijn dat je nog runtime crashes mag gaan fixen daarna. Of dat je een obscuur stukje spec verkeerd begrepen hebt, of dat je uberhaupt uren met makefiles of cmake aan het klooien bent om uberhaupt weer iets werkend te krijgen.

[Douweegbertje]

.oisyn schreef op vrijdag 24 juli 2020 @ 16:41:
Ok, deze moet ik hier even delen

We hebben de laatste tijd wat last van spammers op tweakers, en een niet nader te noemen crewlid heeft een scriptje gemaakt om deze automatisch te detecteren en te bannen. Om hier toch wat controle op uit te kunnen oefenen, plaatst het script een post onder een speciaal daarvoor aangemaakte user in een crewforum. Met linkjes erbij en alles.

Nou heeft dat script alleen zijn eigen user gebanned, omdat het een nieuwe user betrof die de hele tijd linkjes postte

Heerlijk. Wel fijn dat er even lekker "agile" er iets aan wordt gedaan. Het was mij namelijk ook opgevallen dat de hoeveelheid spammers nogal groeide.

PrisonerOfPain schreef op zaterdag 25 juli 2020 @ 16:16:
[...]


Ik gebruik inmiddels dus 2-3 jaar full-time Rust, en alleen Rust terwijl ik daarvoor jaren C++ gebruikt heb enneh, als het evan kan ga ik ook nooit C++ meer doen ook.

Het is zo fijn om een taal met safety guarantees te hebben waar je gewoon in kunt refactoren zonder bang te zijn dat je nog runtime crashes mag gaan fixen daarna. Of dat je een obscuur stukje spec verkeerd begrepen hebt, of dat je uberhaupt uren met makefiles of cmake aan het klooien bent om uberhaupt weer iets werkend te krijgen.

Maar ik ben dan vooral benieuwd: wat maak je?

[ Voor 30% gewijzigd door Douweegbertje op 25-07-2020 17:43 ]

[Koenvh]

Ik vroeg me af waarom bij GitLab de statistiek "storage" vele malen groter was dan "files".



Blijkbaar bewaart GitLab de artefacten van elke keer dat de pipeline gedraaid heeft, en da's ondertussen bijna 100GB . Geen idee waarom ze dat allemaal bewaren, van mij mogen ze, maar lijkt me wel zonde van de ruimte

[ Voor 9% gewijzigd door Koenvh op 26-07-2020 02:59 ]

[Scott]

Koenvh schreef op zondag 26 juli 2020 @ 02:58:
Ik vroeg me af waarom bij GitLab de statistiek "storage" vele malen groter was dan "files".

[Afbeelding]

Blijkbaar bewaart GitLab de artefacten van elke keer dat de pipeline gedraaid heeft, en da's ondertussen bijna 100GB . Geen idee waarom ze dat allemaal bewaren, van mij mogen ze, maar lijkt me wel zonde van de ruimte

Is die 840MB aan files niet alleen maar die van de meest recente commit? Met bijna 1000 commits is er natuurlijk ook een redelijk significante geschiedenis die opgeslagen moet worden.

[whoami]

Het gaat over die 88GB 🙂

Ik ben geen gitlab gebruiker, maar azure DevOps user. Kan je nergens aangeven dat een build/release al of niet voor altijd moet behouden blijven?

[Matis]

Koenvh schreef op zondag 26 juli 2020 @ 02:58:
Ik vroeg me af waarom bij GitLab de statistiek "storage" vele malen groter was dan "files".

[Afbeelding]

Blijkbaar bewaart GitLab de artefacten van elke keer dat de pipeline gedraaid heeft, en da's ondertussen bijna 100GB . Geen idee waarom ze dat allemaal bewaren, van mij mogen ze, maar lijkt me wel zonde van de ruimte

Volgens mij kun je bij de pipelines ook aangeven of en hoe lang ze bewaart moeten worden. Bijvoorbeeld alleen bij failure.

Daarnaast vind ik het zonde om "alles" te bewaren. Als je alles goed getagged hebt, moet je altijd naar dezelfde omgeving terug kunnen op basis van commit.

[Koenvh]

Ik kan op basis van m'n commits sowieso m'n artefacten opnieuw genereren, maar als GitLab(.com) dat wil bewaren, vind ik dat ook geen probleem. Kan vast wel aangepast worden, maar dat kost moeite, en loont voor mij niet. Ik snap alleen niet waarom GitLab dat als standaardinstelling heeft, lijkt me vrij kostbaar om alles standaard op te slaan.

[PrisonerOfPain]

Douweegbertje schreef op zaterdag 25 juli 2020 @ 17:43:
Maar ik ben dan vooral benieuwd: wat maak je?

GPU Benchmarking software en games

[Douweegbertje]

Koenvh schreef op zondag 26 juli 2020 @ 20:32:
Ik kan op basis van m'n commits sowieso m'n artefacten opnieuw genereren, maar als GitLab(.com) dat wil bewaren, vind ik dat ook geen probleem. Kan vast wel aangepast worden, maar dat kost moeite, en loont voor mij niet. Ik snap alleen niet waarom GitLab dat als standaardinstelling heeft, lijkt me vrij kostbaar om alles standaard op te slaan.

https://gitlab.com/gitlab-org/gitlab/-/issues/5634

En als je het zelf draait is het ook jouw zaak om het zelf op te schonen. Mede omdat er verschillende storage types gebruikt worden, dan heb je dat meer zelf in beheer (my 2 cents daarover overigens).

[RayNbow]

* RayNbow heeft laatst iets gemaakt wat achteraf niet zo haalbaar was...
Het verwerken van een enkele foto zou 9.5 uur duren.

[gekkie]

Meh, als het een tera-, peta-, exa-, zetta-, yottapixel foto is van een of andere telescoop, who cares ?

[Matis]

Ik ben bang dat GitLab zichzelf een beetje aan het overgroeien is.
Als ik kijk hoeveel issues / tickets er open staan en hoe weinig er daadwerkelijk gefixt wordt, is dat zorgwekkend.

---

* Matis is zojuist op Corona getest
Ik vond het alles meevallen en in de teststraat in Tilburg had ik geen wachtende voor me. Gisteren rond de middag gebeld voor een afspraak.

[kwaakvaak_v2]

Matis schreef op maandag 27 juli 2020 @ 15:43:
Ik ben bang dat GitLab zichzelf een beetje aan het overgroeien is.
Als ik kijk hoeveel issues / tickets er open staan en hoe weinig er daadwerkelijk gefixt wordt, is dat zorgwekkend.

Ach bij Gitlab is dat in tegenstelling tot de andere Git as a Service platformen inzichtelijk en open toegankelijk. Iedereen kan ze aanmaken, maar dat wil niet zeggen dat ze ook allemaal opgepakt moeten of gaan worden

[RayNbow]

gekkie schreef op maandag 27 juli 2020 @ 15:03:
Meh, als het een tera-, peta-, exa-, zetta-, yottapixel foto is van een of andere telescoop, who cares ?

Net geen 136 MP...

...maar het helpt alleen niet dat er meestal in de orde van 1000 lufo's moeten worden verwerkt.

(plus dat tegenwoordig de foto's over de 200 MP gaan)

[ Voor 9% gewijzigd door RayNbow op 27-07-2020 17:31 ]

[Matis]

RayNbow schreef op maandag 27 juli 2020 @ 17:30:
Net geen 136 MP...

...maar het helpt alleen niet dat er meestal in de orde van 1000 lufo's moeten worden verwerkt.

(plus dat tegenwoordig de foto's over de 200 MP gaan)

Misschien mis ik de grap, maar wat is in hemelsnaam een lufo?

[Mugwump]

Matis schreef op maandag 27 juli 2020 @ 17:49:
[...]

Misschien mis ik de grap, maar wat is in hemelsnaam een lufo?

Dat zal een luchtfoto zijn?

[Matis]

Mugwump schreef op maandag 27 juli 2020 @ 18:45:
Dat zal een luchtfoto zijn?

Dat klinkt aannemelijk. Dan is mijn opmerking met hemelsnaam niet eens zo slecht

Dus als ik het goed begrijp worden er 1000 foto's van 200MP per stuk platgeslagen tot één foto/afbeelding van 136MP?

[ Voor 9% gewijzigd door Matis op 27-07-2020 19:00 ]

[RayNbow]

Matis schreef op maandag 27 juli 2020 @ 18:59:
Dus als ik het goed begrijp worden er 1000 foto's van 200MP per stuk platgeslagen tot één foto/afbeelding van 136MP?

Nee, de (oude) foto waarop ik m'n implementatie op testte was 136 MP. Tegenwoordig zijn ze eerder 200+ MP per stuk. Het probleem is dat niemand zit te wachten op meer dan 9 uur * 1000 >= 9000 uur verwerkingstijd.

(M'n implementatie voerde meer dan 900 matrixvermenigvuldigingen per 4x4 pixels uit om een oplossing van een optimalisatievraagstuk te vinden. )

[Matis]

RayNbow schreef op maandag 27 juli 2020 @ 19:08:
Nee, de (oude) foto waarop ik m'n implementatie op testte was 136 MP. Tegenwoordig zijn ze eerder 200+ MP per stuk. Het probleem is dat niemand zit te wachten op meer dan 9 uur * 1000 >= 9000 uur verwerkingstijd.

(M'n implementatie voerde meer dan 900 matrixvermenigvuldigingen per 4x4 pixels uit om een oplossing van een optimalisatievraagstuk te vinden. )

Misschien trap ik open deuren in.

Maar zoiets lijkt me uitermate geschikt om te parallel te doen op bijvoorbeeld een GPU?

[RayNbow]

Matis schreef op maandag 27 juli 2020 @ 19:16:
[...]

Misschien trap ik open deuren in.

Maar zoiets lijkt me uitermate geschikt om te parallel te doen op bijvoorbeeld een GPU?

Misschien, al is dat wel risicovol aangezien die competentie (OpenCL/CUDA) een is die ik noch andere collega's beheersen.

[gekkie]

Met bijvb numba (is wellicht ook wel zoiets voor andere talen) zou je wellicht al een eindje kunnen komen ipv gelijk die-hard cuda te gaan hacken ?

[Matis]

RayNbow schreef op maandag 27 juli 2020 @ 19:34:
Misschien, al is dat wel risicovol aangezien die competentie (OpenCL/CUDA) een is die ik noch andere collega's beheersen.

Dat begrijp ik, al kun je misschien die kennis inkopen/uitbesteden.

Ik heb ooit, lang geleden, een deinterlacer ontwikkeld in CUDA. De enige reden dat we het toen niet real-time kregen was het feit dat de data niet snel genoeg ingelezen en weggeschreven kon worden. Een luxe welke we, voordat het algoritme in CUDA lag, niet hadden

[RayNbow]

gekkie schreef op maandag 27 juli 2020 @ 19:41:
Met bijvb numba (is wellicht ook wel zoiets voor andere talen) zou je wellicht al een eindje kunnen komen ipv gelijk die-hard cuda te gaan hacken ?

Misschien. Zag bijv. ILGPU toen ik wat aan het zoeken was en heb dat op de Should-Try-Sometime List geplempt.

Matis schreef op maandag 27 juli 2020 @ 19:45:
[...]

Dat begrijp ik, al kun je misschien die kennis inkopen/uitbesteden.

Voorlopig hebben we in plaats van betere oplossing (kwaliteit) maar voor een zeer snelle benadering gekozen. Deze snelle benadering hadden we al liggen in een legacy-project (in x86 asm) wat niet echt meer onderhoudbaar was. De nieuwe C#-implementatie is weliswaar iets trager (maar niet belemmerend traag) en doet er iets van 12 seconden over per 136 MP beeld. (Dat is tenminste te overzien i.p.v. 9.5 uur.)