Om å løse alt bortsett fra det egentlige problemet

“Problemet med Java er at det krever så mange abstraksjoner. Factories, proxies, rammeverk…” Min samtalepartner gjenfortalte inntrykket han hadde av de Java-programmerende kollegene sine.

Jeg måtte innrømme at jeg kjente meg igjen. Kulturen rundt Java-programmering har noen sykdomstrekk. Kanskje det minst flatterende er fascinasjonen for komplekse teknologiske løsninger. Et gjennomsnittlig Java-prosjekt har rammeverk (Spring, Hibernate), tjenestebusser - gjerne flere (OSB, Camel, Mule), byggverktøy (Maven, Ant, Gradle), persisteringsverktøy (JPA, Hibernate), kodegeneratorer (JAXB, JAX-WS), meldingskøer (JMS), webrammeverk (JSF, Wicket, Spring-MVC) og applikasjonsservere (WebSphere, WebLogic, JBoss). Og det er bare starten. Hvor kommer denne impulsen fra?

Jeg har hørt to teorier om hvorfor Java-programmerere ender opp med en kompleks hverdag. Den ene skylder på sjefene, mens den andre skylder på programmererne. Jeg vil ta for meg begge og peke på en vei ut av jungelen.

Teori 1: Steak and strippers

Zed Shaw, mannen bak “The motherfucking manifesto for programming, motherfuckers” skylder på IT-sjefene. Han mener at selgerne fra teknologiske giganter tar med IT-sjefer ut på strippebuler og kjøper biffmiddager til dem. Og vips så kjøper IT-sjefen inn et ubrukelig verktøy som programmererne er tvunget til å bruke. (Zed påpeker at det vil være positivt med flere kvinnelige IT-sjefer, ettersom de i det minste ikke vil være like interessert i strippebulene)

Ref: Zed Shaw: Control and responsibility (http://zedshaw.com/essays/control_and_responsibility.html). Zed Shaw: Programming, motherfuckers (http://programming-motherfucker.com/). Zed Shaw: Video - Steak and Strippers (http://vimeo.com/2723800).

Argumentet er underholdende, men forklarer bare en del av problemet. Mange av verktøyene som står bak kompleksiteten i Java-prosjekter er åpen kildekode og selges typisk ikke av selgere med fete representasjonskontoer.

Teori 2: Blinkende lys

Jeg tror en viktigere teori er at programmerere er opptatt av fancy ting som blinker. Enkle ting som firmaet tjener penger på er kjedelige. Å sette seg ned og flytte data fra databasen og putte det i en webside er kjedelig for en programmerere. Å lære seg et nytt rammeverk som gjør den samme jobben på en fancy måte er spennende. Å fjerne teknologier og lage en enklere løsning er kjedelig. Å innføre et rammeverk som skal skru sammen teknologien er spennende.

Alle foretrekker å gjøre det de synes er spennende. Jeg vet det, for jeg har vært der selv.

Grunnleggende sett tror jeg at Java-programmere selv har skaffet seg de problemene de ofte klager over med komplekse teknologier.

Veien ut av villmarken

For meg var det viktigste skrittet ut av villmarken foredraget jeg hold på JavaZone for to år siden. I foredraget bygger jeg og Anders Karlsen en webapplikasjon i Java uten å bruke webrammeverk. (Innbild deg at du hører et ironisk gisp her)

Jeg har øvet meg på å løse de problemene jeg har i prosjekter med å bruke enklere teknologier. Slik vet jeg hva de komplekse løsningen gjør. Og så langt er det nesten ingen løsninger som ikke innfører mer problemer enn de fjerner. Det de gjør er at de flytter fokuset fra den oppgaven programmet egentlig skulle løse over til alle de teknologiske delene som man skal få til å fungere sammen.

Jeg tror ikke programmerere er bedre eller dårlige enn andre mennesker når det gjelder det. Men vi har alle en tendens til å bruke tiden vår til å finne spennende problemer å løse i stedet for å løse det vi egentlig skulle på en naiv og enkel måte. Min far sa det egentlig best: Du bør ikke bruke en kalkulator før du kan løse de samme regnestykkene på papir.

Comments:

[@leftieFriele] - Sep 6, 2013

“finne spennende problemer å løse i stedet for å løse det vi egentlig skulle på en naiv og enkel måte”

Hvis jeg skal være djevelens advokat så vil jeg påstå at du selv gjør akkurat det samme som de du kritiserer. Du liker å skrive ting uten rammeverk fordi det er noe du personlig synes er en utfordrende faglig øvelse. Det vil for veldig mange virke som om du søker en spennende problem å løse, fremfor å løse en bruker eller kunde utfordring.

Når det gjelder faren din sitt råd, så var det sikkert vel ment da du skulle lære å regne. Han sa neppe dette da du skulle lære å kjøre bil: “Sønn, nå som du skal lære deg å kjøre bil så må du først forstå hvordan girkassa virker. Etter det så skal du få lov å gire, ikke før.” (riktignok kjenner jeg fedre som faktisk har sagt slike ting, men det er ikke noe de sier for barnets beste men for å få de til å bli mekanikere). Fordi det er ca hva jeg hører du sier når du snakker om at man skal “lage ting uten rammerverk”. Det er en øvelse som i hovedsak gjør deg som person bedre, mer enn at det handler om å løse et bruker/kunder behov. Selvsagt er det greit å gjøre det, men ikke pakk det inn som at det er en mer “nobel” måte å gjøre ting på.

[ebaxt] - Sep 6, 2013

“Seek simplicity, and distrust it.” – Alfred North Whitehead

De fleste rammeverk gjør en god jobb med å fremstå som enkle og forståelige, og det er derfor enkelt å bli lurt. Jeg er enig i at vi som utviklere er alt for dårlig til å vurdere nedsiden når vi velger å ta inn nye rammeverk og biblioteker, men jeg tror årsaken til at man gjør det er mer nyansert enn at vi alle liker ting som blinker.

Jeg tror årsaken til at Java miljøet er spesielt dårlig på dette, er at man bruker uforholdsmessig mye tid på å kjempe mot språket når man skal gjøre enkle ting, og at man derfor leter etter bedre alternativer.

Siden det i Java er vanskelig å lage små, komponerbare abstraksjoner, så ender man opp men å lage store rammeverk som gjør en rekke tradeoffs. Når man tar i bruk rammeverket, og støter på disse tradeoffsene oppdager man at abstraksjonen lekker, og at fordelen med rammeverket ikke nødvendigvis rettferdiggjør nedsiden.

Det er selvsagt mange årsaker til “kompleksitets kulturen” i Java, men jeg er overbevist om at språkets manglende evne til å skrive små, komponerbare abstraksjoner, er en del av årsaken. Derfor tror jeg det er verdt å investere tid på å lære seg nye språk, og andre paradigmer som har bedre støtte for dette.

Jeg er helt enig i at vi som utviklere bør bruke mindre tid på å lære oss nye rammeverk, som pynter på tidligere løsninger, uten å ta tak i de underliggende problemene. Men jeg er samtidig redd for at artikler som denne blir brukt for å rettferdiggjøre å ikke investere tid og penger på innovasjon og nytenkning som går dypere enn en ny variasjon av ORM, eller ett nytt webrammeverk.

[Bjørn Einar Bjartnes] - Sep 6, 2013

Dette er en diskusjon jeg ønsker å se i form av en paneldebatt eller tilsvarende. Kunne vi samlet litt folk og holdt noe sånt, kanskje en ettermiddag på Teknologihuset. Jeg synes den er utrolig spennende, og kan ikke bidra med noe annet enn løs synsing selv, men lar ikke det stoppe meg fra å synse litt. For meg har seks måneder permisjon med litt tid vekk fra C# (som lider av mye av det samme som Java) til kulturen rundt node.js og Go (kun på hobbybasis hjemme i perm) åpnet øynene mine. Og jeg sier kultur, for jeg tror det er vel så mye kultur som språk som ligger bak.

Jeg registrerer også at Christin Gorman er inne på samme tema http://vimeo.com/28885655, men da med ORM som eksempel og ikke webrammeverk. De største rammeverkene dukker jo gjerne opp i forbindelse med ORMer og webrammeverk. Og kanskje er det her vi lar oss irritere mest, fordi de har en tendens til å kludre til SQL og HTTP. Ting som virker abstraheres til noe som nesten virker.

En påstand som dukker opp til stadighet når man søker renhet er at man blir anklaget for kun å ønske og skrive sine egne rammeverk. Jeg tror også det er en fristende mulighet som dukker opp, når man ser muligheter for å generalisere så er man opplært til at det skal man. Skal det være noe i det å gjøre ting enklere, så er det jo nettopp at man ikke skriver sine egne rammeverk, men man må stå i mot fristelsen. Kanskje er ikke litt duplisering her og der det værste som kan skje. Man må i så fall kunne stå i mot fristelsen til å “trekke ut rammeverk” av koden sin om man ønsker å holde seg til filosofien om enkelhet. Det var jo nettopp komplekse rammeverk man søkte å unngå.

Skriv gjerne nyttige biblioteker, men la koden din lime dem sammen så rett frem som mulig.

Jeg ser mange artige eksempler på dette. Jeg er i perm, men følger med på interne diskusjoner på jobben om de er morsomme nok. Her var det 5-6 annotasjoner på en metode, og noe som ikke fungerte som det skulle. Når man da leser hva Christian Nesmark må klø seg i hodet over når rekkefølgene på to attributter ikke er satt riktig, så ser man at dette kan bli vrient. http://www.novanet.no/blog/christian-nesmark/dates/2013/8/authorize-and-requirehttps-attributes-in-mvc-with-claims-and-adfswif/

Kanskje er det ikke så galt å skrive god, gammeldags rett frem kode.

Jeg har lett litt etter Rob Pike’s filosofi, jeg tror det er noe av dette han forsøker å si. At i store prosjekter må man etterstrebe enkelhet. Det blir uansett ti- eller hundretusener av linjer kode i et stort prosjekt… Jeg har ikke funnet noe der han sier akkurat det jeg vil han skal si, dette er det nærmeste jeg har funnet. Jeg skal heller ikke legge noen ord i munnen på ham, så jeg fortsetter å lete litt. I mellomtiden så kan man lese det her http://commandcenter.blogspot.co.il/2012/06/less-is-exponentially-more.html

Jeg har ihvertfall blitt allergisk mot kode som ikke betyr noe konkret for meg. For å eksemplifisere igjen. En abstrakt kamel. Beklager. Du mister meg. Jeg tror jeg heller ville jobbet med mindre automagi og mer kode. Jeg er ikke sikker på at mer kode betyr mer feil, om den er enkel og forståelig for folk flest http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/component/bean/AbstractCamelInvocationHandler.html

Jeg kjenner at jeg har lyst til å forsøke meg på et større prosjekt der vi lar SQL være SQL og lar HTTP være i fred. Der vi skriver moduler og ikke rammeverk. Og der vi ikke er redd for litt duplisert kode her og der. Gjerne i Go, men ikke nødvendigvis. Om det ville blitt noe bedre? Hvem vet, det ville være eksperimentet.

[Bjørn Einar Bjartnes] - Sep 6, 2013

Her er listen over noen av dem jeg gjerne ville sett invitert til å “battle det ut” i en diskusjon.

- @ChristinGorman og kakeoppskriftene hennes (jeg kan godt hjelpe til med å bake kaker, uten kakemix). Det hadde vært funny å servere.

- Johannes (du startet det jo), eller kanskje du vil fasilitere

- En eller annen forkjemper for digre rammeverk (gjerne med skikkelig erfaring fra noen store offentlige IT prosjekter der det faktisk virker, en som kan bitch-slappe alle hipsterne med virkeligheten)

- Richard Feynman (dessverre død, kanskje man kan se noen videoer i stedenfor)

- Rob Pike (kanskje ikke han kommer…)

- Rich Hickey (han kan vi vel også se på video) http://www.infoq.com/presentations/Simple-Made-Easy

[Bjørn Einar Bjartnes] - Sep 6, 2013

Ja, og @substack

Johannes Brodwall - Sep 6, 2013

I’m in!

Jeg klassifiserer Scala-ister litt på samme måte som Spring-etikere, ESB-ister og AppServer-etikere - de er mer opptatt av de blinkende lysende enn av problemløsningen. Skal vi ha med en slik en?

Johannes Brodwall - Sep 6, 2013

Jeg lurer på om jeg egentlig har et skjult motiv….

Min erfaring med Spring er at det egentlig ikke løste noen problemer, all verdien lå i det jeg brakte selv. Altså “ta med treningsapparater til treningsstudio”. Tilsvarende viser det seg at når man bruker for eksempel JBoss i stedet for Jetty (eller Tomcat) er det for å bruke JPA, men det er jo bare å legge til en jar-fil. Og tilsvarende fjernet Scala-brukere 20% av linjene, men endret ikke på strukturen som gjorde problemet stort i første omgang.

Med Hibernate er situasjonen at man får NOE til å funke, og så bruker masse tid på å lazy-loading, fetch-strategier etc, etc. til å virke. Når jeg kom tilbake til JDBC innså jeg at det ble mindre kode og SPESIELT mindre flikking.

Avanserte programmeringsspråk kan tilsvarende gi færre linjer, men mer fikling per linje.

Så!

Metafortid!

Jeg bodde på Tøyen i mange år. Syklet, gikk eller tok bane til jobben. Så bestemte jeg meg for å kjøpe bil….

Selve bilkjøringen til jobb er raskere enn sykkel. Dersom det ikke er trafikk (som det er på samme tidspunkt som det er interessant å kjøre, nødvendigvis). Og dersom man ikke regner med tiden for å finne parkeringsplass. Og tiden til å gå fra parkeringsplassen som ble langt unna.

Så det er ikke girkassa før bilkjøring. Det er sykling før bilkjøring.

Dersom man ikke har hatt sykkelperspektivet før man starter å kjøre bil, vet man ikke når man skal bruke den og når man bare vil bli sittende i kø fra Oslo til Sandvika.

Johannes Brodwall - Sep 6, 2013

Et til vikariende motiv:

For meg har den trege kompilerings- og testsyklusen i Scala ødelagt all moroa jeg kunne hatt ved de kule språkfeaturene. Jeg velger feedback loop framfor features any day.

[Bjørn Einar Bjartnes] - Sep 6, 2013

Det er jo egentlig litt flere spørsmål i ett vi kommer inn på, tror jeg. Når det gjelder treg kompileringssyklus og kule features er det jo ganske morsomt å lese om golang. Det har jo nettopp strippet en del features for å kunne kompilere store prosjekter på et par sekunder. Og har ikke arv som i Java, så man skal unngå å bygge store type-hierarkier og snuble i dem etterpå. Til og med generics er strippet bort. Gutta bak sier at det er ikke der store prosjekter taper tid eller innfører feil. Det er andre ting som fører til at store prosjekter tar tid.

Men, det jeg skulle frem til, det er vel flere spørsmål som dukker opp, som man kanskje burde holde separat, ihvertfall om man skal få til en paneldebatt e.l. Jeg ser ihvertfall flere spørsmål 1. Språkdiskusjoner… Java/Scala/Clojure. Fokuserer vi på feil problem? Eller er det nødvendig å tenke nytt rundt språk for å få ned feil/øke effektiviteten osv…? 2. Rammeverk vs. biblioteker, kan vi slutte å bruke masse rammeverk, og heller hente inn biblioteker til å hjelpe oss med oppgaver der vi ser det er nødvendig/hensiktsmessig. 3. Innføring av fancy abstraksjoner… Har vi en kultur der vi er livredde for å gjenta oss selv, og heller lager unødvendig kompleksitet enn å skrive samme linje tekst to ganger? Kan vi la være å lage egne rammeverk også, kan vi kode ting mer rett frem og heller finne oss i at det blir noen gjentagelser. Blir det lettere eller vanskeligere å lese i praksis? 4. Hva er det _egentlig_ vi bruker for mye tid på i store prosjekter?

[Kaare Nilsen] - Sep 6, 2013

Stakkar.. Må være kjipt å ha et så dårlig forhold til et språk at hvert eneste argument slår tilbake på Scala. Selv om Scala ikke en gang har vært nevnt av andre enn deg selv så langt i diskusjonen.

Du fremstår for meg som en bitter og enfoldig utvikler med usagte underliggende motiv. Skulle gjerne tatt en ordentlig debatt om saken, men føler ikke for å bli med på en pissekonkurranse.

kthxbye

Johannes Brodwall - Sep 7, 2013

Oops. Det ble litt dårlig stemning. Det er mye meninger om hvor håpløst Java er fra f.eks. Scala evangelister, så jeg regnet med å måtte ha noen svar med energi. Beklager om du følte deg såret.

[Bjørn Einar Bjartnes] - Sep 7, 2013

Huffda, kan vi dele ut en Strawman til Johannes og en Ad Hominem til Kåre fra https://yourlogicalfallacyis.com/ og la det ligge der? Og så en eller annen badge til meg for å gjøre seg til dommer, men den fant jeg ikke i farten. Jeg er fortsatt motivert, og tror fortsatt kanskje at det er mulig, å få til siviliserte og interessante debatter rundt dette. Men det er en liten jobb å gjøre med tanke på å finne ut hvilke spørsmål som skal diskuteres og kan/bør holdes adskilt, hvordan formatet burde være med mere. Om noen fortsatt tror det kan la seg gjøre, hva om vi møtes til en kaffe/pils eller booker et møterom på f.eks. Teknologihuset en ettermiddag og diskuterer litt rundt hvilke temaer som kunne være interessante å diskutere og hva slags format som skal til for at det gir mening? En meta-diskusjon, så vi kan legge til rette for den gode samtalen og erfaringsutveksling. Om man vil krangle kan man alltids hive seg inn i valgkampen istedenfor…

Johannes Brodwall - Sep 7, 2013

Dette er en konstruktiv innfallsvinkel, Bjørn Einar.

Slik jeg tenker det, kan poenget mitt omformes til et “moderate proposal”:

  1. Prioriter læring av det du trenger før det som er kult. Ikke i stedet for, men prioritert. Så: Bruk to timer på å lære bedre SQL for hver time du bruker på å lære Hibernate. Dersom organisasjonen din har standardisert på Java, se på to foredrag om å bruke IDEA eller Eclipse bedre for hvert foredrag du ser på om å overbevise folk om å bruke Scala. Bruk mer tid på å lære HTML enn å lære JSF og bruk mer tid på å lære domenet du jobber med enn å lære å konfigurere WebLogic.

  2. Det er ikke noe feil å ha det gøy mens man programmerer plain Java. Med en bevisst fokus på å fjerne forstyrrelser (e.g. applikasjonsservere som krever minutter å redeploye til) er Java-programmering gøy. Kan Scala-tilhengere (spesielt!) slutte å fremstille det som om det er noe galt i å ha det åleit når man programmerer Java?

  3. Hvis du har lyst til å titulere deg som “Java-ekspert” er det kleint å si “Java er dødt/døende”.

[Bjørn Einar Bjartnes] - Sep 7, 2013

Denne likte jeg svært godt. Tilsynelatende litt tannløst, men det er egentlig ganske konkret. Kjenner selv at jeg synder litt i mot dette. Tenker å stjele det til en lyntale med påfølgende diskusjon internet, kommer sikkert til å bytte ut Java med .NET og Eclipse med Visual Studio, men ellers kommer jeg nok skamløst til å stjele “Johannes moderate forslag”.

Kjenner også at jeg synder en del mot dette, og tror at noe av grunnen er så enkel at jeg bruker svært mye av egen fritid til hobbykoding. Og da føler jeg at det er helt greit å bryte med alt dette. Det må være lov å gi full pri til det som er kult, om alternativet er å se sport på TV, være mer med familien eller gå på byen.

Johannes Brodwall - Sep 7, 2013

Superenig. Fritid er fritid. Og som programmerere er nye programmeringsspråk og teknologier.

Men jeg anbefaler å være litt forsiktig med å bruke fritid til å lære ting som du ikke bruker i hobbykoding eller på “hvordan selge inn teknologi X på jobben”. Ikke fordi det er feil, men fordi du kan lett skape frustrasjon for deg selv og andre.

[Kaare Nilsen] - Sep 7, 2013

Vanskelig å ikke ta det personlig når en blir sammenlignet med et lite barn som er mer opptatt av ting som blinker enn å løse problemer.

Når det er sagt, så var jeg nok i overkant drøy i min frustrasjon der. så beklager at jeg kom med dumme personkarakteristikker. Burde være klokere enn som så..

Jeg er nå, kanskje gammeldags, men av den oppfatning av at man ikke åpner for debatt med andre ved å kalle dem dumme, scalaister, evangelister eller for den saks skyld andre ord som er ment å få motparten til å virke ubetydelig eller dum.

Men jeg har jo igrunn blitt kallt værre ting før, Sist var fra c++ og c gjengen da en del av oss begynnte å se på Java. For ikke snakke om browseren som plattform for applikasjoner. Så jeg veit ikke helt hvorfor jeg gadd å bli provosert..

[leftieFriele] - Sep 7, 2013

Argumentasjonen og filosofien din er noe jeg også ser stadig mer av i framsie-miljøet også. Hvis man ikke bruker jQuery så er man automatisk en bedre utvikler og man har elevert til et høyere nivå av bevissthet. Rent bortsett fra at det stortsett betyr at man sier et digert Fuck You til alle brukere som ikke tilhører samme opplyste elite (ettersom hvem faen kan kode en site ned til IE6 og opp til Mobile Safari uten hjelp??) som aldri ville brukt IE7 om de fikk betalt. For all del er man blant de 2% som faktisk kan dette, så fortjener man all respekt i verden. Likevel gir det ingen rett til å snakke ned de som ikke er på samme plan eller blankt avfeie det de gjør som håpløst. Nå er det kanskje ikke slik at JDBC istedet for JPA har tilsvarende konsekvenser som framsie eksempelet, men holdningene som ligger til grunn er det samme.

Jeg føler argumentasjonen er innadvendt og selvsentrert på utvikleren selv. Ikke en eneste gang er det i artikkelen eller kommentarene nevnt at dette har noen positiv effekt for brukere eller kunder av hva-det-nå-er-man-lager. Det sier meg at dette her er faglig dekadense som har som hovedmål å fremheve noen og stigmatisere andre.

Jeg er ingen stor fan av altomsluttende rammeverk som låser deg inn og abstraherer deg vekk. Likevel så har de som elsker å bruke de sin plass i vår bransje på samme måte som de som behersker og skrive alt alene uten rammeverk. Å bruke tid på å stigmatisere og snakke ned kolleger i samme bransje som ser ting ulikt mener jeg er lite produktivt.

Johannes Brodwall - Sep 7, 2013

Mitt argument er ment fra kundeperspektivet (om ikke brukerperspektivet). Det jeg ser med mange rammeverk er noe jeg kaller 90/10 regelen: Rammeverket gjør 90% av jobben for deg, og gjør det 10 ganger så tidkrevende å løse det som står igjen. JDBC og JPA har ofte denne effekten. Dette er sløsing i teknologihenrykkelsens navn.

Når det gjelder jQuery er jeg helt enig med deg: Dersom det man lager ikke fungerer for de brukerne man har, så har man ikke løst oppgaven man ble satt til å løse.

Jeg observerer at noen føler seg støtt av argumentet mitt. Det er ikke min hensikt. Jeg ønsker kun å henge opp en vær-varsom-plakat for fancy teknologi som lover for mye. Jeg ønsker ikke å utvikle uten f.eks. Spring fordi det er kult å utvikle uten Spring. Jeg ønsker å gjøre det fordi jeg tror jeg kan produserer resultater raskere. Og jeg tror andre kan det også.

Johannes Brodwall - Sep 7, 2013

Jeg hopper over det andre og går til den interessante debatten i innlegget ditt: Analogien med C/C++.

Når jeg programmerte C++ brukte jeg mange søvnløse netter på å finne ut hvordan jeg kunne modellere noe som krevde en std::vector uten å lekke minne. Jeg fant at Java, uten templates (som det heter der), macroer, multippel arv og andre features i C++, lot meg løse problemer som jeg aldri hadde klart å løse uten å introdusere vanskelige feil i C++. Det er mange problemområder der jeg har brukt C eller C++ uten å savne en eneste feature fra andre språk. Men det er andre problemer jeg ikke har nok hjernekapasitet til å løse med C++.

Jeg opplever ikke at Scala, Groovy eller JRuby åpner noen nye problemområder for meg. De lar meg uttrykke de samme løsningene med færre linjer kode, men til gjengjeld bruker jeg gjerne mer tid per linje kode. Tidsforskjellen blir kanskje mindre med mer erfaring med språket, men jeg tror at for de aller fleste vil den fortsatt være der.

Okay, Ruby åpner noen problemområder som jeg ikke gidder å løse i Java: Scripting av operasjoner på filsystemet.

Lisp (og Clojure) åpner noen nye problemområder og unnslipper dermed denne kritikken. Men for meg personlig lukker de en del som jeg fikk til med Java (eller Scala) samtidig.

Bevares, Scala er en fint språk. Hadde det hatt samme utbredelse (og samme kompileringshastighet!) som Java i dag, hadde det vært helt kult for meg. Men ikke noe mer enn helt kult.

Jeg oppfatter Scala-tilhengere til å formidle å bytte programmeringsspråk er en essensiell sak for IT-verden i dag. Jeg oppfatter Scala-tilhengere til å formidle at de som mener de kan gjøre en god jobb med Java og ha det moro i dag ikke har fulgt med i timen.

Jeg mener begge deler er feil.

[jlous] - Sep 11, 2013

Gode poenger her, og jeg er enig i at det er noe spesielt med javakulturen på dette området. Men jeg savner at du tar opp nettopp det: hvorfor akkurat javamiljøet? Er det rent kulturbetinget eller har det faktisk noe med språket å gjøre?

Johannes Brodwall - Sep 12, 2013

Jeg tror mange opplever en betydelig forbedret feedback med for eksempel Scala fordi de får en unnskyldning til å kaste rammeverk som Spring og Hibernate. Når det gjelder Spring og Hibernate husker jeg at de ble solgt inn fordi “det er enklere enn J2EE”. Når det gjelder app-servere og ESB’en veit jeg ikke hvorfor de er så utbedredte i Java-miljøet,. BizTalk har marginal interesse i .NET. På den andre siden har .NET-utviklere SharePoint og IIS som en klamp om foten. Jeg tror nok at noe er en trang i alle miljøer.

[jlous] - Sep 12, 2013

Jeg tror i hvert fall ikke man helt uten videre skal avfeie innsparinger i kodelinjer som irrelvant. Ikke fordi tastetrykk egentlig er flaskehalsen i utvikling, men jeg tror likevel impulser av typen “tenk om jeg slapp å skrive alt dette rælet” har vært vesentlig både for opphav og opptak for rammeverkene. I et språk med mindre boilerplate kan det derfor hende at det er litt mer fristende å gjøre ting rett fram. Jeg husket godt at java kom og at det var en åpenbaring på mange måter, men jeg husker også at jeg og mange andre reagerte på hvor ordrik og redundant syntaksen var.

Johannes Brodwall - Sep 12, 2013

Jeg er primært interessert i super-lineær reduksjon i antall kodelinjer. Å redusere med 20% er ikke så spennende. Selv en reduksjon på 40% er ikke så interesssant dersom mesteparten av disse linjene er gettere og settere.

Man ville fått en større reduksjon i “antall linjer” i C# dersom man hadde gått over til Java-standard for plassering av krøllparanterer, så det er mer enn bare antall linjer som gjelder.

[Marius Kotsbak] - Sep 24, 2013

Det er vel ikke verre enn Java? Er problemet at kompilering tar lang tid? Hva med Play framework (uhm, eller var dette om å droppe framework :D), der er det jo bare å refreshe nettsiden?

Johannes Brodwall - Sep 24, 2013

Det er spesielt mye verre (men det er “større”) eller bedre (men det er “større”) enn Java. Men en diskusjon om vi skal bruke Scala kan fort bli en distraksjon fra viktigere temaer og dersom du bruker 2 dager på å lære Scala (bedre), mens du forsømmer å lære domenet til kunden prioriterer du dårlig.

Play er for magisk for min smak. :-)

[Marius Kotsbak] - Sep 24, 2013

Har det noe å si om man programmerer klassisk eller veldig funksjonelt i Scala? Ser for meg at kompilatoren tar en del tid på å nøste opp i funksjoner inni funksjoner.

Heldigvis ser det ut som de viktigste fordelene i Scala kommer inn i Java 8+. Noe jeg savner ganske mye i Java er å kunne referere til en funksjon (metode) uten å bruke en tekststreng som kompilatoren ikke kan sjekke, men dette tror jeg er løst i Java 7 eller 8.

Holder på å lese meg opp på Play, men det virker hyggelig i typiske webapplikasjoner (men kan godt være den også får deg i framework-fella).