BjartmarO

Staten er vel en litt tryggere arbeidsgiver enn en privat bedrift? Folk tenker sikkert på det også.

 

Helt sikkert.

Men, det er en slags omvendt korrelasjon der også. Det er ofte ikke de dyktigste som søker seg mest mot denne typen trygghet. De som er dyktigst vet at de kan få seg jobb "hvor som helst" og er derfor mindre interessert i å ta lønnskutt for å oppnå denne tryggheten.

Det finnes unntak... men jeg vil si at dette i alle fall er det generelle bildet.

Det betyr at staten trekker til seg folk som søker seg mot ekstra trygghet, som du sier. Men samtidig er dette ofte ikke de "kapasitetene" som man gjerne kunne ønske seg.

Det finnes idealister, som går på tvers av det som jeg her sier. Men, de er sjeldne, og det er langt mellom de.

 

Datamaskiner skriver jo allerede (nesten) all kode, i form av komopilerings-trinnet, som oversetter høyere nivå instruksjoner (skrevet av mennesker) til lavere nivå instruksjoner (tolket av maskiner).

 

AI som genererer kode er bare en høyning av grensen for hva som regnes som høyere nivå programmering.

 

Vi vil, dersom visjonene slår til, få et ennå høyere nivå - over det som vi i dag regner som høyere nivå - hvor utviklere forhåpentligvis vil kunne bruke ennå mer av tiden sin til å skape funksjonalitet, og ennå mindre av tiden til å kjempe med rene implementasjons-tekniske detaljer og boiler plate-kode.

 

Konsekvensen av dette, er kanskje at personer uten programmeringsbakgrunn selv kan lage applikasjoner, og på den måten gjøre en del programmerere arbeidsløse.

Nei, det er en slags "pipe dream", tror jeg...

Det egentlige problemet med å lage programvare er det å kunne ta et menneskelig problem, analysere det, og bryte det opp i mindre delproblemer som er oversiktlige, og som passer til å kunne implementeres i kode og mates til en datamaskin.

Dette vil fortsatt være jobben i fremtiden også, tror jeg, bare at det man mater til maskinen kanskje vil se litt annerledes ut enn det man mater den med i dag. Man vil måtte bryte ned problemene til delproblemer som egner seg til å kunne løses av en AI-løsning, i stedet for å bryte de ned til noe som kan uttrykkes i if-setninger og for-looper, som man gjør i dag.

Jeg tror ikke det å utvikle programvare vil bli noe enklere som følge av at man innfører AI-baserte verktøy. Om noe, så kan vel til og med det motsatte fort komme til å skje, tror jeg, at programvareutviklings-yrket blir enda mer komplisert og kompetanseavhengig enn hva det er i dag.

 

Datamaskiner skriver jo allerede (nesten) all kode, i form av komopilerings-trinnet, som oversetter høyere nivå instruksjoner (skrevet av mennesker) til lavere nivå instruksjoner (tolket av maskiner).

 

AI som genererer kode er bare en høyning av grensen for hva som regnes som høyere nivå programmering.

 

Vi vil, dersom visjonene slår til, få et ennå høyere nivå - over det som vi i dag regner som høyere nivå - hvor utviklere forhåpentligvis vil kunne bruke ennå mer av tiden sin til å skape funksjonalitet, og ennå mindre av tiden til å kjempe med rene implementasjons-tekniske detaljer og boiler plate-kode.

 

Kompilering er muligens en litt annen gren enn det vi tenker på når vi sier kunstig intelligens som programmerer, da kompilering er primitiv og deterministisk logikk, mens kunstig intelligens heller vil bli at man skaper ny informasjon ut fra det som står.

 

Jeg er enig i at en abstrahering til et høyere nivå kommer til å bli koding i 2040, og at man beskriver problemer, eller ønsket løsning til en datamaskin, og lar den finne ut selv hva som innebærer i å få dette resultatet.

Ja, i større eller mindre grad...

Det blir selvsagt ikke slik at man sier til datamaskinen at den skal "lage et fengende krigsspill som danker ut Call of Duty". AI-et vil, selv ikke i 2040, vite hva mennesker regner som "fengende"...

Men, ja. Jobben blir nok i større grad det å bryte opp problemstillinger i biter som gjør de spisbare for AI-baserte hjelpeverktøy.

Man bryter opp problemene, bruker AI på delproblemene, høster resultatene fra de AI-baserte beregningene, og setter det sammen på måter som til slutt løser eller dekker et menneskelig behov, enten det er at det skal være fengende, visuelt tiltalende, brukervennlig, effektivt eller annet.

Den gode nyheten er at disse jobbene vil være like tallrike som de jobbene vi i dag sitter og løser som utviklere. Jeg ser for meg at det stort sett vil dreie seg om en endring i måten som vi jobber på, hvor endringen vil være at vi får et kraftigere (og til dels mye kraftigere) verktøy i verktøykassen enn vi har hatt før.

Skynet-lignende fremtidsvisjoner om AI som selv finner ut hvilken programvare som bør lages, og som overflødiggjør programvareutviklere.... de tror jeg man kan beholde i skrivebordsskuffen en stund til...

 

Håpløst dårlig og feilinformerende artikkel. AlphaZero brukte ikke 4 timer på å slå Stockfish.

 

AlphaZero brukte fire timer på å lære seg selv å spille sjakk. Deretter spilte AphaZero 100 partier mot Stockfish der hvert rekk fikk ta maksimalt 1 minutt.

Resultatet av de 100 partiene ble 72 remi og 28 seire til AlphaZero. Det er ganske så imponerende, men AlphaZero vil slite betraktelig om tenketiden går opp til 2 minutter. Under denne testen fikk AlphaZero ganske så mye kraftigere CPU'er enn det Stockfish klarer.

Hva AlphaZero har i sjakkrating vites ikke, men de fleste kraftige computerne har over 3000..

http://www.computerchess.org.uk/ccrl/4040/

 

Hvis du leser artikkelen, så vil du se at dette ikke stemmer. Forskjellen i ELO-rating mellom StockFish of AlphaZero ser ut til å øke med lengre betenkningstid. De har omtrent samme rating rundt 0,5 sekund per trekk, og den blir større etter hvert. Dette er også logisk ut fra at StockFish søker "bredt" (nesten alle varianter X trekk fremover), mens AlphaGo søker "dypt" og følger mønster den finner interessante.

 

AlphaZero ser ut til å ha mellom 3300-3400ELO, men artikkelen er litt uklar der.

 

Selve treningen av AlphaZero er gjort på et monster av en maskin, totalt 5064 TPU prosessorer i fire timer. Den spilte imidlertid på en relativt moderat maskin med 4 TPUer. Litt vanskelig å sammenligne nøyaktig med maskinen som Stockfish brukte(kostnad, flops etc), men man snakker her om samme størrelsesorden.

Som et perspektiv kan det vel legges til at de 5064 TPU-enhetene til Google trolig har en ren hardwaremessig kostnad på opp mot en halv milliard kroner.

Opplæringen som tok 4 timer på dette clusteret ville trolig ha tatt i størrelsesordenen 100 år dersom man skulle ha kjørt det på en ordinær laptop CPU.

Prisen på selve spillmaskinen, med 4 Google TPU-enheter av andregenerasjons type, vet jeg ikke. Men, jeg tipper vel at den også ligger på noen hundre tusen kroner, i alle fall.

Datamaskiner skriver jo allerede (nesten) all kode, i form av komopilerings-trinnet, som oversetter høyere nivå instruksjoner (skrevet av mennesker) til lavere nivå instruksjoner (tolket av maskiner).

AI som genererer kode er bare en høyning av grensen for hva som regnes som høyere nivå programmering.

Vi vil, dersom visjonene slår til, få et ennå høyere nivå - over det som vi i dag regner som høyere nivå - hvor utviklere forhåpentligvis vil kunne bruke ennå mer av tiden sin til å skape funksjonalitet, og ennå mindre av tiden til å kjempe med rene implementasjons-tekniske detaljer og boiler plate-kode.

Har du utviklet mange systemer i dialog med kunder? Jeg kan forsikre deg om at normaltilstanden er at kunden ikke vet hva de vil ha. De kan gjerne tro de vet det, men det er nesten alltid feil.

 

Ja, og tilsvarende, så er normaltilstanden at utviklerne ikke vet hva kunden vil ha. De kan tro at de vet det, men det er nesten alltid feil.

Du kan si at kunden ikke skjønner teknologien, og at de dermed ikke vet på forhånd hva de vil ha. Jeg har ikke noe problem med akkurat det utsagnet.

Men, du må huske på at det oftest går andre veien også. Sett en ren programmerer og fagnerd til å designe en praktisk løsning på et forretningsmessig problem, og du får ofte en håpløst knotete greie... Utviklerne forstår ofte teknikken, men ikke det praktiske. Og kunden forstår det praktiske, men ikke teknikken.

Det er denne kløften som er problemet...

Man avhjelper litt med en slags iterativ tilnærming. Da unngår man f.eks. at utviklerne blir sittende måneder, kvartaler og halvår jobbende i en retning som kunden ikke er enig i.

Men, det man egentlig trenger i disse situasjonene er utviklere med kunde- og forretningsforståelse. Altså personer som kan utviklingsfaget og teknologien til fingerspissene (med andre ord som er eller har vært utviklere selv), og som samtidig evner å se utfordringene fra den andre siden av bordet. Utviklere som evner å se problemet fra kundens side, og å skjønne måten hans å tenke på.

Som 1J7HHBGW sier er denne typen fagpersoner litt å betrakte som enhjørninger. Men, om man får fatt i de, så er det mye mer effektivt enn å iterere mange runder med parter som egentlig ikke forstår hverandre. For å "se" de gode løsningene tidlig må man ha personer som klarer å ha dyp forståelse både av teknologien og av kunden sine behov. Først da ser man de egentlige mulighetene som ligger i prosjektet. Man må ha noen som klarer å "se på tvers", på en måte.

 

 

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

Jeg vet at det ofte vinkles sånn...

 

"Kunden forstod ikke sitt eget behov, derfor sitter vi i saksen."

 

Jeg mener at dette som regel er bullshit.

 

Det riktige er som regel at utvikleren ikke har forstått behovet godt nok, og/eller at utvikleren ikke har evnet å kommunisere sin egen (mangelfulle) forståelse av problemet godt nok til kunden før oppstart av prosjektet.

 

Det er ikke bare kunden sitt ansvar å fortelle utvikleren hva det er han vil ha. Det er like mye utvikleren sitt ansvar å spørre og grave, og å sørge for å skaffe seg tilstrekkelig informasjon til å kunne utforme en god løsning for kunden.

 

Kunden vet ikke hva han kan få. Han kjenner ikke det tekniske mulighetsrommet. Dermed vet han heller oftest ikke eksakt hvilken informasjon som kan være relevant i forkant av prosjektet. Det er dermed utvikleren sitt ansvar, som ekspert, å drive denne prosessen, og å sørge for at all relevant informasjon kommer på bordet.

 

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

Det viktigste for at et prosjekt skal bli vellykket er at man har en "gobetween" som virkelig KAN teknologien og virkelig FORSTÅR bedriften. Disse personene vokser ikke på trær, men om man er så heldig har man har denne personen involvert så er det helt uvurderlig. Har hatt privilegiet å oppleve dette fungere, og det er nesten som en drøm. Etter mitt syn er det denne kompetansen som det er størst mangel på i Norge.

 

Helt enig...

Jeg ser denne oppgaven som en integrert del av oppgaven til utviklingsteamet. Utviklingsteamet må sørge for å ha med seg minst en person som evner å kommunisere med kunden, og som evner å sette seg DYPT inn i hvordan kunden tenker seg å bruke systemet etter at det står ferdig.

Like viktig, evnene til å forklare den foreslåtte løsningen til kunden før man setter i gang med å implementere den, slik at man er sikker på at den endelige løsningen ikke kommer som en overraskelse på kunden. Eller i alle fall at man greier å minimere mengden av ting som kunden ikke er forberedt på.

Også, at man evner å holde kommunikasjonen i gang underveis i prosjektet, så man kan samle ny og forbedret informasjon om de delene av løsningen som krever en slags iterativ tilnærming.

Det viktige i denne rollen er at den besettes av folk som faktisk skjønner begge sider, som du sier. Altså, som både skjønner teknologien (og skjønner den GODT), og som har evnen til å sette seg inn i komplekse bruksmønster og behov hos kunden, og å forstå disse fullt ut. Det er "tverrsynet" som er det verdifulle her. Evnen til både å se hva som trengs, og å se hva som er teknisk mulig.

En del (spesielt offentlige) organisasjoner skjønner dette bare sånn delvis. De skjønner at de må ha en mellommann. Men de setter gjerne inn byråkrater som hverken skjønner teknologien, eller har evnen til å analysere og forstå bruksmønstrene hos kunden. Det er ikke selve det å ha en mellommann som er det verdifulle. Men det å ha en mellommann som evner å se på tvers. Disse rene byråkratiske mellommennene ender ofte opp med å bare gjøre vondt verre, etter min mening, fordi man da har personer som egentlig er MENT å skulle forvalte denne oppgaven, men som ikke er i stand til å gjøre det, rent kompetansemessig. Da faller ting ofte mellom to stoler, er min erfaring... Ingen blir sittende med ansvaret. Og man ender opp i situasjoner hvor man skylder på hverandre, og hvor man sier at "kunden ikke forstod sitt eget behov".

 

 

Men, som det står i artikkelen vil alle Bitcoinsen være utdelt innen 2040....hvem vil da stå for den enorme regnekraften som skal holde denne valutaen i gang?

 

Det er en feil i artikkelen. Riktig årstall er år 2140.

 

Det minerne får, er pr nå:

- 12.5 bitcoin

- Alle transaksjonsgebyrene for de transaksjonene de miner.

 

Antall bitcoin i mining reward (nå 12.5) halverer seg med jevne mellomrom, neste halvering er i år 2020. Dette konvergerer mot null i år 2140. Innen den tid regner man med at minerne må leve av transaksjonsgebyrene.

 

Men dette med mining er egentlig noe som regulerer seg selv. Blir det færre som miner, og blokkene kommer for sjelden, vil vanskelighetsgraden gå ned (det regulerer bitcoin-systemet ca. hver 14. dag), og det blir altså billigere å mine - og dermed vil flere igjen mine....

Er ikke hele tanken med mining å holde styr på transaksjonene? Hva mener du med at vanskelighetsgraden vil gå ned?

Formålet med miningen er vel primært å bestemme rekkefølgen på transaksjonene, så vidt jeg forstår, og å gjøre dette på en måte som ikke så enkelt lar seg hacke eller rigge utenfra.

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

Jeg vet at det ofte vinkles sånn...

"Kunden forstod ikke sitt eget behov, derfor sitter vi i saksen."

Jeg mener at dette som regel er bullshit.

Det riktige er som regel at utvikleren ikke har forstått behovet godt nok, og/eller at utvikleren ikke har evnet å kommunisere sin egen (mangelfulle) forståelse av problemet godt nok til kunden før oppstart av prosjektet.

Det er ikke bare kunden sitt ansvar å fortelle utvikleren hva det er han vil ha. Det er like mye utvikleren sitt ansvar å spørre og grave, og å sørge for å skaffe seg tilstrekkelig informasjon til å kunne utforme en god løsning for kunden.

Kunden vet ikke hva han kan få. Han kjenner ikke det tekniske mulighetsrommet. Dermed vet han heller oftest ikke eksakt hvilken informasjon som kan være relevant i forkant av prosjektet. Det er dermed utvikleren sitt ansvar, som ekspert, å drive denne prosessen, og å sørge for at all relevant informasjon kommer på bordet.

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

Hos min forrige arbeidsgiver var det i alle fall _en_ server som hadde brukernavn "administrator" og passord "password", husker jeg...

De lot humla suse, og den fikk ha dette logonet i årevis, husker jeg.

Jeg var ikke hos drift. Men, noe jeg stusset på der, var hvor enkel og lempfeldig omgang de virket å ha med passorddatabasen sin. Det fremstod som om så og si samtlige på drift hadde tilgang til denne databasen. Dvs. at dersom du visste passordet til den databasen, så hadde du effektivt sett tilgang til hundrevis av produksjonskritiske servere.

Jeg skjønte at de gjorde det av "pragmatiske" årsaker. Men jeg skjønte det likevel ikke, egentlig.

 

 

Søk har også fått en fremtredende rolle, og skal i mange tilfeller kunne erstatte det gamle paradigmet med navigasjonsknapper og menyer.

Beklager, folkens, men dette er helt forskjellige funksjonaliteter som ikke kan erstatte hverandre. Spesielt kan man ikke erstatte knapper og menyer med søk, fordi søk har null "discoverability". Mao søk fungerer bare når man allerede kjenner systemet. For å kjenne det, må man enten ha opplæring, eller lære det vha systemets "discoverability" - dvs knapper.

 

Hvorfor ble Windows 95 med WIMP så populært? Høy discoverability, som følge av menyer og knapper, som viser hva man kan velge. I motsetning til terminal-baserte programmer, der man må huske kommandoene og tastatursnarveiene.

 

Tenk deg å gå på en restaurant, men istedenfor å få utdelt en meny, får du et søkefelt, og må søke etter rettene for å oppdage dem!

 

Og mange kan ikke noe med det offentliges systemer. Det er gresk for dem. Så tenk deg nå at restauranten ligger i Hellas, og man må søke på gresk.

 

Hvordan klarte denne UX-designeren å bestå eksamen?

 

Jeg er kun inne på Altinn 2-3 ganger i året, men da vanligvis ifm skatteoppgjøret for å se på og levere inn dette, så tenkte ikke så mye på dette, men du har nok et poeng her.

Usikker på hvordan "de proffe" vil like dette? Hvorfor ikke begge deler?

 

Men det _jeg_ reagerte mest på, var at designet ser ut til å være veldig optimalisert for små skjermer, typisk pad e.l. 

Jeg måtte hele tiden scrolle, og alle feltene var unaturlig store, og at det er en enorm sløsing med plass.

Halve "start-skjermbildet"  var jo menyen og søkefeltet...

 

Skulle tro de aller fleste brukerne sitter på en PC, eller i det minste har et tastatur når de er inne på Altinn.

 

Det nye designet var fint, men slitsomt å navigere seg i....

 

Selv om det gamle designet, kanskje var litt "gammeldags", synes jeg dette var mye enklere å navigere i.

Jeg er litt enig...

Det virker som om de ha gått all in på såkalt "responsivt design" her. Altså, adaptive nettsider, hvor brukergrensensnittet tilpasser seg ulike skjermstørrelser på en dynamisk måte.

NRK sine nettsider er et eksempel på et tilfelle hvor dette (etter min mening) er gjort på riktig måte. Det ser korrekt designet ut på stor skjerm. Og det ser korrekt designet ut på liten skjerm (man kan se effekten på en desktopmaskin ved å endre bredden på nettleseren mens man har nettsiden oppe).

Altinn mener jeg kanskje har bommet litt. De har gjort nettsiden brukbar fra mobile enheter (som sikkert var hovedmålet med endringen, tipper jeg). Men de har kanskje slått babyen litt ut med badevannet når det gjelder desktop-opplevelsen, virker det som... Inntrykket av desktop-versjonen av designet er litt at det nå bare er en slags "oppskalert utgave" av den mobile versjonen av siden, bare med et par ekstra "bells and whistles".

Det er litt typisk, tror jeg. Man får litt tunnellsyn på oppgaven, som er å gjøre nettsiden mobilt tilgjengelig, og så glemmer man desktop-biten (for "den var jo allerede OK fra før").

Nordea virker som om de har begått litt av den samme tabben i sine nylige nettside-oppdateringer...

Ikke for det. Jeg var inne på Altinn nå i sted, fra en desktopmaskin. Jeg kan bekrefte at jeg fikk gjort det jeg skulle. Men, jeg tenkte omtrent det som jeg skrev ovenfor, nemlig at de kanskje hadde brukt noen kalorier for lite på det med desktop-opplevelsen. Det er kanskje litt spesielt dumt på Altinn, vil jeg si. Dummere enn dersom de f.eks. hadde gjort det på NRK sine nettsider. NRK blir jo tross alt kanskje aksessert minst 50% fra mobile enheter. Altinn er derimot en litt "tyngre portal", på et vis........... Det er få som rapporterer skatten sin eller momsen sin fra mobile enheter. Sikkert under 5% av brukerne, per i dag i alle fall, vil jeg tro. Man kan derfor stille i alle fall litt spørsmålstegn ved prioriteringen akkurat her, og ved måten som man har vektet den mobile og stasjonære brukeropplevelsen respektivt.

Bestått, vil jeg vel si det er likevel, men...

"Allerede nå er Renaults maskin på samme nivå som sjåførene når det kommer til å unngå hindringer i veien, skriver Hougard.

Det betyr i praksis at bilen klarer å unngå hindringer i like store hastigheter som testsjåføren. "

 

Dette er typisk for dagens holdning til autonomi og noe som irriterer meg skikkelig. Datamaskiner er sikkert mye bedre til manøvrering i høy hastighet og reaksjonstid, men det er jo ikke poenget. Poenget er menneskets evne til å kjenne igjen unormale situasjoner rett før de krever bremsing, ikke bare at vi oppdager en hindring som allerede er i veien. Tror det blir max Level 2 i mange år fremover.

 

Du fyrer vel autonomifolkene opp litt med vilje her, vil jeg tro...

Men, jeg er enig med deg. Folk har generelt sett litt for god tro på hvor langt man skal komme med tekonologien for selvkjørende biler, og på hvor kort tid det skal ta.

Man henger vel ikke igjen på nivå 2, som du sier... men jeg tror det er helt riktig at man ikke vil nå nivå 5 på noen meningsfull måte i løpet av de neste 40 årene i alle fall.

Det som trolig kommer til å skje, tror jeg, er at man redefinerer målene litt etter hvert. I stedet for visjonen om 100% selvkjørende biler som slippes ut i dagens trafikksystem, så vil man i stedet ende opp med en løsning hvor selve transportenettet også vil måtte tilpasses denne klassen av kjøretøyer. Altså, at man vil ha selvkjørende biler, men at man i tillegg vil få egne veistrekninger som er klassifisert for nettopp denne typen kjøring.

Når det gjelder visjonen om 100% selvkjørende biler som ikke trenger guidede eller tilpassede veistrekninger på noen måte, så kan dette i ytterste fall vise seg å være en teknisk umulighet, og noe som vi ikke en gang vil se innenfor et tidsperspektiv på 100 år.

Jeg støtter deg med andre ord i din misjon om å helle litt kaldt vann i årene på de mest blåøyde tilhengerne av denne teknologien... ;-)

 

Dataene er samlet fra en jobbsøkingstjeneste...

 

Det de viser er hvilke språk utviklerne tror vil kunne fremme karrieren deres, samt hvilke språk de tror vil kunne ha den motsatte effekten.

 

Så, undersøkelsen måler i stor grad hvilke språk utviklerne oppfatter som hippe og fremoverlente.

 

 

Jepp.

 

Jeg har uthevet det som er vesentlig her.

 

At ikke COBOL er med sier vel det meste kanskje?

COBOL må jo være utrolig bra språk å kode i

 

De opererte visst med noen slags cut off-verdier for hvilke språk de tok med i listen. De måtte ha mer enn 10.000 likes, eller hva det var. Og en lignende regel for dislikes...

Uansett, jeg kjenner noen (eldre) utviklere som jobber med Cobol hver dag, fortsatt. Det jeg kan si er at de ikke klager over språket. Tvert om, så skryter de vel av det, så fort de får anledningen. Det er visst nok et bra språk, for det det var bygget for.

Det finnes nok av språk som folk jobber med fordi de må, men som de ikke har spesielt mye godt å si om ellers. Java er vel kanskje litt i den kategorien. Java er et OK (og kraftfullt) språk, men du finner likevel ikke spesielt mange utviklere som skryter av det uoppfordret. Da er det flere som skryter f.eks. av C#, som språk...

Dataene er samlet fra en jobbsøkingstjeneste...

Det de viser er hvilke språk utviklerne tror vil kunne fremme karrieren deres, samt hvilke språk de tror vil kunne ha den motsatte effekten.

Så, undersøkelsen måler i stor grad hvilke språk utviklerne oppfatter som hippe og fremoverlente.

"Hvilke språk tror jeg det vil være gunstig for meg å ha på CV-en min i fremtiden."

Det er det denne undersøkelsen egentlig måler....

Man skal ikke underslå at det sikkert er en viss korrelasjon til hvilke språk utviklerne liker. Men denne er ikke sterk nok til å kunne si at det er dette undersøkelsen måler.

 

 

Jeg er rimelig sikker på at det vil være bruk for et mylder av software en lang stund fremover.....

 

 

Fra produsentenes perspektiv: Hva kan man selge som en app, som man ikke kan selge som en tjeneste? 

 

Hvis man sammenligner Android med Google Home eller Alexa, er det stor forskjell på hvordan man leverer innhold, og på Google Home har Google strengere kontroll med hvem som får tjene penger på plattformen.

Det betyr ikke at man ikke får ha apper, men at fokus på tjenester øker.  

 

Edit: feil forvrengte fremstillingen. 

Gi meg en pause fra "som en tjeneste". Ett av de mest irriterende buzz-wordene nå om dagen, synes jeg...

Alt skal være "som en tjeneste". Folk bruker det som om et slags banner for å fortelle omverdenen at de selv følger med i tiden.

Det næreste og grelleste eksempel for mitt vedkommende var da så og si alle avdelingene på jobben døpte seg om til "som en tjeneste" for to-tre år siden... Network as a service. Storage as a service. Platform as a Service. Etc.

Det eneste som slapp fri, så langt jeg kunne se, var vel kanskje ledelsen. Management as a service så jeg ikke. Mulig det stoppet når de merket at forkortelsen kom til å bli MAS eller MaaS...

Det er ikke tvil om at fremskrittene innenfor kunstig intelligens har vært imponerende...

Etter min mening er teknologien imidlertid litt oversolgt akkurat nå. Folk (og markedet) har litt for god tro på hvor raskt vi skal komme til et punkt hvor disse algoritmene kan sammenlignes med menneskelig intelligens reelt sett. Folk feilvurderer litt hvor "dumme" disse algoritmene fortsatt er, mener jeg.

Mange av eksemplene på bruk av kunstig intelligens har en viss WOW-faktor, slik som f.eks. de generative algoritmene i denne saken. Men når du ser på bildene, og når du analyserer tingene som algoritmene fortsatt bommer på, så ser du på en måte mellom linjene at algoritmene egentlig fortsatt er stokk dumme. De bommer på ting som selv ikke et ekstremt uintelligent menneske ville ha bommet på.

Jeg tror vi er omtrent på toppen av hype-kurven nå. Og at de kommende årene vil bli preget mer av kaldt vann i årene enn av økt hype...

(Ikke til forkleinelse for teknologien i seg selv, som er fantastisk i sin egen rett. Bare at den kanskje er et par knepp mindre fantastisk enn det den er solgt inn som akkurat nå.)

 

 

 

Trolig er det hydrogen, produsert på havet, som blir den dominerende energikilden i fremtiden.

Ein ting ert 100% sikkert – hydrogen kjem alltid til å vere "framtidas energibærar". I 2017 og i 2117. Enno sikrare enn at flytande havvind ikkje løner seg pr i dag (botnfast havvind løner seg derimot), er at det havvind ikkje vert meir lønsamt av å kaste vekk 3/4 av energien på hydrogenfjas. Her har artikkelforfattarane heilt rett. Hydrogen er ein daufødd draum frå dei som drøymer om ei framtid for fossil energi, og kjem alltid til å vere det.

Da lederen i Lastebileierforbundet ble intervjuet på Dagsrevyen for noen dager siden, var signalet at tungtransporten bare venter på fyllestasjoner for hydrogen langs transportveiene, så er de egentlig klare til å skifte fra diesel til hydrogen.

Det kan hende han signaliserte dette, men førebels finst det ikkje noko tungtransportkøyrety i verda med fornuftig rekkjevidde som går på hydrogen. Difor lyg han. Det finst ingen marknad for tungtransport på hydrogen. Om han trur det er ein god idé å kaste vekk milliardar på hydrogenstasjonar som ingen kan bruke, vonar eg han brukar sine eigne pengar.

 

Skal du ha tungtransport over på alternativt drivstoff med fornuftig rekkjevidde, må dei bruke batteri. Det er og svært mykje billigare. Hydrogen er minst like dyrt som diesel. Mykje dyrare når du reknar med ekstrakostnaden for infrastrukturen.

 

Hvorfor ikke bruke de 20 mrd. som er tenkt brukt til kjøreledninger langs E39 til fyllestasjoner for hydrogen?

Eg tykkjer køyreleidningar òg er ein dårleg idé, sidan induktiv lading i vegbana både er billigare og meir driftssikkert, men årsaka til at vi ikkje skal bruke pengane til å leggje til rette for ei vanvittig meiningslaus sløsing med energi (om nokon kunne bruke dei) bør vere opplagt! Alle veit at hydrogen er ein blindveg. Det er difor oljeselskapa, som for all del vil unngå eit skifte, brukar so mykje energi på å snakke om det. Merk at dei ikkje gjer noko, dei snakkar om hydrogen som ein avleiingsmanøver.

 

Vi har levd godt med bare 30% virkningsgrad i transportsektoren, så argumentet om at mye energi går tapt i prosessen med elektrolyse og kompresjon er noe søkt.

Sei meg, vart du litt vel ivrig no, eller trollar du?

 

I dag blir ikke energien fra vind og bølger på havet utnyttet i det hele tatt, så slik sett kan vi si 100% tap.

Bruk fire sekund til å tenkje over kvifor det er slik. Du kan få ti sekund om du er litt treg i toppen.

 

Det som betyr noe for bileierne er pumpeprisen, og med stor sannsynlighet kan hydrogen konkurrere med diesel når vi kommer noen 10-år frem i tid.

Hydrogen konkurrerer ikkje med diesel. Ikkje no, ikkje for 10 år sidan og ikkje om 10 år. Hydrogen konkurrerer med straum, og straum vil alltid vere billigare enn hydrogen, og hydrogen vil alltid vere dyrare enn både bensin og diesel. Det føl av termodynamikkens lover, delvis forklart i artikkelen.

 

Det billigste er å lade et batteri hjemme, men skal vi kjøre langt eller bruke tilhenger på bilen er hydrogen et alternativ.

Nemn ein hydrogenbil med hengarfeste.

 

Vi køyrde elbil i ti land i sommar. Eg er ikkje sikker på kor mange kilometer det vart, men elbil er definitivt tingen om du vil køyre langt. Mange av landa vi var innom har ikkje ein einaste hydrogenstasjon, men i alle var det vanleg med innlagt straum.

 

Biler med relativt stort batteri og brenselceller er sannsynligvis fremtiden.

Heilt sikkert ikkje. Mercedes lagde ein slik bil i 2000 eksemplar. Alle går på leasing i California pga krav om å levere hydrogenbilar der, og det til ein pris som Mercedes taper mykje pengar på. Slike bilar er uselgelege, både pga pris og plass i bilen. Hugs òg at platinaproduksjonen i verda berre held til å utstyre 7‰ av dagens årlege bilproduksjon med brenselceller. Elbilsalet er allereie langt over det nivået.

 

Vi blir nok ikke enige, og bare den som lever lenge nok vil få svaret.

 

Svaret har vi fått for lenge sidan. Salet av hydrogenbilar tok aldri av, og har gått nedover i årevis. Hydrogenbussar er i ferd med å forsvinne heilt og tungtransport på hydrogen er framleis på draumestadiet.

 

Salet av elbilar tek av over heile verda. Elbussar dominerer allereie i Kina, og spreier seg vestover. Verdas største produsent av trekkvogner lanserte nyleg ei batteridriven trekkvogn med lang rekkjevidde. Tesla skal òg snart lansere ei trekkvogn.

 

Det er ikkje noko å vente på. Hydrogen er daudt. Nokon prøvde hardt å få liv i bålet, men flammen døydde ut. Batteri har vunne med stor margin.

 

PS: Ja, eg veit at Asko har eit par spesialproduserte (konverterte) små lastebilar som går på hydrogen.

Du må ikke være så skråsikker, Sturle...

Husk, du bør alltid la det være en liten åpning for at du selv kan ha tatt feil, selv i saker der du føler deg granatsikker på å ha sett det endeligste og sanneste lyset.

Når du når et punkt hvor du ikke lenger diskuterer en sak for å opplyse og bli opplyst, men for å preke den eneste sanne lære, da kan du etter min menining like gjerne legge ned pennen (innenfor akkurat det temaet i alle fall).

Omskoler dere til leger... dere har jo mer enn vanskelig nok matte, men kanskje ikke bra nok snitt?

 

De har nok (for det meste) mer enn bra nok snitt til å kunne fungere som leger. Jeg tror ikke legeyrket er spesielt mye mer krevende eller vanskelig enn ingeniøryrket. Om noe, så er vel trolig ingeniøryrket mer intellektuelt krevende, tror jeg...

Å komme inn på selve studiet er jo en annen sak, det er vel kanskje det du sikter mest til her, tipper jeg.

Avslutningskommentaren til driftsansvarlig Rhino Thue, "jeg tror vi sier at dette [intervjuet] er over jeg, control alt delete!", fra promovideoen for JavaZone for noen år siden:

 

"EFN er grunnleggende imot DRM. Litt av samme grunn som at vi aldri har hatt kopilås på fysiske bøker."

 

Jaha...

 

Jeg tror jeg kan love Doctorow at det ville ha vært kopilåser på fysiske bøker dersom dette i det hele tatt var mulig.

Lest på de første sidene av en fysisk bok? Der står det faktisk et og annet om kopiering av boken.

 

Ja, men det er en forskjell på en copyright statement og en kopilås. Med kopilås mener Doctorow mekanismer som hindrer deg fysisk i på kopiere boken. Som han korrekt observerer, så finnes ikke dette... Når det gjelder årsakene til at det ikke finnes, så bommer han. Det var vel først og fremst det jeg prøvde å kommentere.

"EFN er grunnleggende imot DRM. Litt av samme grunn som at vi aldri har hatt kopilås på fysiske bøker."

Jaha...

Jeg tror jeg kan love Doctorow at det ville ha vært kopilåser på fysiske bøker dersom dette i det hele tatt var mulig.

> Hvorfor er den ene verdenskjent og den andre totalt glemt?

 

Dyktig markedsføring naturligvis, Det er forskjellen mellom de som lykkes og de som ikke lykkes. Se på Steve Jobs, det er bare menigheten som tror at Apple-produkter har høyere kvalitet enn alt annet, men han var et geni på markedsføring.

 

http://verdenogvi.blogspot.no/2017/01/meningsmalinger.html

 

Nei, det der er egentlig tull...

Det Steve Jobs hadde var den unike kombinasjonen av at han både forstod teknologien (i tilstrekkelig grad til å vite hva som var mulig og ikke mulig), pluss at han forstod hva markedet ville ha.

Om du ser på forskjellen mellom f.eks. Microsoft sin Zune (mp3-spiller) og Apple sin iPod, så var ikke forskjellen bare god markedføring. Forskjellen var i stedet at iPod var et bedre produkt. Mer teknisk avansert, og konstruert ut fra en riktigere forståelse av hva publikum ville komme til å like. Den var sikkert bra markedsført også. Men det var ikke dette som var Steve Jobs sitt geni, først og fremst.

Alt for høy pris. Og hvorfor er den ikke vanntett? Denne kunne jo ha hatt en del utendørs applikasjoner om den hadde vært vanntett (og billigere).

 

Og hvorfor følger det ikke med en tryllestav? Kanskje fordi det er versjon 1.0 av produktet?

 

Med unntak av den irriterende blekkostnaden så er 8600 en fantastisk skrivermodell. Så der må du skamme deg om hardware-uttalelsene. For den skriveren er bare helt feilfri så lenge på hardware-siden (hos meg).

Godt noen er heldige.

Jeg har ikke noe fra HP, men stort sett alt jeg har av "vennesupport" ang. skrivere/scannere er HP relatert. Både mekaniske ting og programvare.

 

Her er en greie fra da jeg prøvde å få en skriver til å takle mobiltlf ("eprint") hos noen venner;

https://h30434.www3.hp.com/t5/HP-Connected-Mobile-Printing-and-Cloud-Printing/eprint-Info-sheet-Error-500/m-p/4456618#M58401

Sånt er litt typisk HP, det er stort sett alltid noe som skrurrer.

 

Hadde senest en for et par uker siden hvor scanner trommelen tok kvelden (artifacts/striper ved scanning). Garantisak, men styrete. Ting knekker, hjul spinner.... i det hele tatt mye ræl.

Du burde kanskje ha luktet lunta når du følte at du måtte begynne å styre med XMPP, porter og overstyring av DNS...

Selv ikke HP sine konsumentprodukter legger jo opp til at man skal måtte drive med den type konfigurering for å få produktene til å fungere.

Jeg så at dere løste det med en slags soft reset til slutt... Det enkle er ofte det beste, som det heter. :-)

Ganske typisk at forslaget "Lysning" går videre, i alle fall...

Forslaget minner litt om Holmenkollbakken og Nytt Nasjonalmuseum. Begge disse vinnerforslagene gikk også (etter min mening) videre delvis pga. besnærende lyssterke objekter i presentasjonsmaterialene. Lysfontenen på toppen av bakken, for Holmenkollen sin del, og lysboksen på toppen av museet, for nytt nasjonalmuseum sin del.

Jeg synes det virker som om arkitektjuryene for ofte lar seg blende av effekter som ikke er reelle... Altså, "triks" i presentasjonsmaterialet, som ikke bærer noen tett relasjon til hvordan det endelige bygget faktisk kommer til å bli seende ut.

For at "Lysning" skal kunne leve opp til presentasjonsmaterialet må jo f.eks. samtlige av rommene lyses opp av en eller flere 5000 watts lyskastere. Og tilsvarende for de lyssatte uterommene...