Programutviklingsmetoder
Odd-R.
Jeg holder for tiden på med hovedoppgave på siv.ing. studiet i
datateknikk. En av de tingene jeg kommer bortom i oppgaven er
programutviklingsmetoder. Jeg har (eller skal snart) spesiellt sett (se)
på eXtreme programming og unified process.
Er det noen som vet om disse metodene virkelig brukes ute i bedrifter,
eller er det andre metoder eller variasjoner av disse som benyttes eller
benyttes det ikke metoder i det hele tatt?
Bare av ren nysgjerrighet.
På forhånd takk
mvh
O.R.
--
Har du et kjøleskap, har du en TV
så har du alt du trenger for å leve
-Jokke & Valentinerne
Geir Harris Hedemark
> Er det noen som vet om disse metodene virkelig brukes ute i bedrifter,
> eller er det andre metoder eller variasjoner av disse som benyttes eller
> benyttes det ikke metoder i det hele tatt?
Jeg aner en holdning som går i retning av at du synes det du skal
gjøre ikke nødvendigvis er appliserbart på virkeligheten, og at det
derfor ikke er meningsfylt.
Det du beskriver er modeller for utvikling. Det er ikke slik at alle
modeller nødvendigvis er nødt til å stemme med terrenget for at de
skal ha gyldighet. Det er heller ikke slik at alle sidene ved UP/RUP
gir mening i alle prosjekter eller alle bedrifter. Det gjør ikke
modellen ubrukbar.
Det er heller ikke slik at alle modeller nødvendigvis gir gode
eksempler. Parprogrammeringen mange forbinder med XP er ikke noe alle
utviklere liker eller er mest effektive med, og den er heller ikke noe
som gir mening i alle faser av et prosjekt. Det betyr ikke at XP er
uten verdi.
Jeg mener at forskjellen på en god og en dårlig prosjektleder er om
han klarer å se når de forskjellige modellene gjør mer godt enn
skade. Verdens verste prosjektleder er i min bok prosjektlederen som
har forelsket seg i en modell og forsøker å banke alle de firkantede
prosjektene/prosjektteamene han ser inn i den runde modellen for å
forsøke å validere sitt eget valg.
Ja, det finnes mange bedrifter som har applisert UP eller XP. Jeg tror
ikke det eksisterer en eneste bedrift som har gjennomført noen av
disse to 100% og overlevd over tid.
Geir
Alf P. Steinbach
>
> Jeg holder for tiden på med hovedoppgave på siv.ing. studiet i
> datateknikk. En av de tingene jeg kommer bortom i oppgaven er
> programutviklingsmetoder. Jeg har (eller skal snart) spesiellt sett (se)
> på eXtreme programming og unified process.
>
> Er det noen som vet om disse metodene virkelig brukes ute i bedrifter,
> eller er det andre metoder eller variasjoner av disse som benyttes eller
> benyttes det ikke metoder i det hele tatt?
>
> Bare av ren nysgjerrighet.
Begge brukes. Men det er nesten alltid ekstrem stor avstand mellom det
som faktisk gjøres og det metodeverket bedriftens ledelse tror blir brukt,
og like stor eller enda større avstand til det bedriften profilere seg på.
Ofte er det kun verktøyene som er i faktisk samsvar med metodeverket, og på
gulvnivået er det snakk om "vi bruker selvfølgelig de _delene_ som passer".
Når det gjelder RUP og UML kan du jo kontakte Kantega, der jeg jobbet en stund
(foreslår Gunnar Nordseth eller Tor-Ivar Byrkjeland). På grunn av mange
fusjoner og navneskifter kan firmaet virke som ganske nytt men det har
grunnkjerne fra bl.a. gamle Taskon, som var aktivt med i standardiseringen av
UML. Det kan også muligens være nyttig for deg å se på større bedrifters
interne metodeverk, som for eksempel Accenture (der jeg også jobbet en stund,
og faktisk litt involvert i endring/oppdatering av metodeverket); foreslår der
Tor Jomar Nordhagen.
Håper dette hjelper litt.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jon Haugsand
> Begge brukes. Men det er nesten alltid ekstrem stor avstand mellom det
> som faktisk gjøres og det metodeverket bedriftens ledelse tror blir brukt,
> og like stor eller enda større avstand til det bedriften profilere seg på.
> Ofte er det kun verktøyene som er i faktisk samsvar med metodeverket, og på
> gulvnivået er det snakk om "vi bruker selvfølgelig de _delene_ som passer".
>
> Når det gjelder RUP og UML
Nå er det en stund siden jeg jobbet med dette, men så vidt jeg husker
er RUP et _rammeverk_ som XP passer godt inn i, XP blir bare en brikke
i RUP, eller en variant av RUP. UML er et bildespråk for å vise deler
av et OO-design.
Jeg liker både RUP og til tider XP og stort sett UML, men som så ofte
ellers blir dette buzzwords og da overtar ordenes viktighet fremfor
prosessenes, og det er jo det siste vi skal leve av -- egentlig.
(Ulempen med XP er det blir _for_ mye fokus på sluttresultat og for
lite på god design og konseptuell oppbygning.)
--
Jon Haugsand
Dept. of Informatics, Univ. of Oslo, Norway, mailto:jon...@ifi.uio.no
http://www.ifi.uio.no/~jonhaug/, Phone: +47 22 85 24 92
Alf P. Steinbach
> * Alf P. Steinbach
> > Begge brukes. Men det er nesten alltid ekstrem stor avstand mellom det
> > som faktisk gjøres og det metodeverket bedriftens ledelse tror blir brukt,
> > og like stor eller enda større avstand til det bedriften profilere seg på.
> > Ofte er det kun verktøyene som er i faktisk samsvar med metodeverket, og på
> > gulvnivået er det snakk om "vi bruker selvfølgelig de _delene_ som passer".
> >
> > Når det gjelder RUP og UML
>
> Nå er det en stund siden jeg jobbet med dette, men så vidt jeg husker
> er RUP et _rammeverk_ som XP passer godt inn i
Jepp.
> XP blir bare en brikke i RUP
Litt subjektivt det der, tror jeg.
> eller en variant av RUP.
Nix.
> UML er et bildespråk for å vise deler av et OO-design.
Jepp.
> Jeg liker både RUP og til tider XP og stort sett UML, men som så ofte
> ellers blir dette buzzwords og da overtar ordenes viktighet fremfor
> prosessenes, og det er jo det siste vi skal leve av -- egentlig.
Enig.
> (Ulempen med XP er det blir _for_ mye fokus på sluttresultat og for
> lite på god design og konseptuell oppbygning.)
Avhenger av hunden, som Niels Bohr bemerket. ;-)
Thomas Hansen
left his sanity behind and proclaimed:
>Hei.
>
>Jeg holder for tiden på med hovedoppgave på siv.ing. studiet i
>datateknikk. En av de tingene jeg kommer bortom i oppgaven er
>programutviklingsmetoder. Jeg har (eller skal snart) spesiellt sett (se)
>på eXtreme programming og unified process.
>
>Er det noen som vet om disse metodene virkelig brukes ute i bedrifter,
>eller er det andre metoder eller variasjoner av disse som benyttes eller
>benyttes det ikke metoder i det hele tatt?
>
>Bare av ren nysgjerrighet.
>
>På forhånd takk
>
>mvh
>
>O.R.
Jeg har jobbet i en bedrift i 3 1/2 år med 2 store prosjekter (og en
millin små...;).
I det først prosjektet fulgte vi MSF (Microsoft Solution Framework)
relativt slavisk og det var en gigantisk suksess!
Dette var første gang at bedriften brukte "metode" og ikke bare
"sjampingjongmetoden"...
Det var første gang i bedriftens da 10 års lange historie at vi klarte
å overholde deadline. (det vanlige var at deadline ble brutt med 3-6
måneder)
I det andre prosjektet (som i tillegg til software utvikling hadde som
mål å spre kompetanse om .Net Framework) fulgte vil mere XP med en
"dash" av MSF og også dette ble en suksess (deadline ble brutt, men
alle utviklerne kom opp på C#, .Net etc...)
Så mine erfaringer tilsier at et godt rammeverk, formet etter oppgaven
som skal løses er "hellig"!!
Med de riktige "metodene" kan du trylle dritt om til gull!!!
Ellers kan jeg si at disse metodene brukes i MEGET stor grad i andre
bedrifter også!
Men det er dessverre også mange vedrifter som ikke har tatt noe
standpunkt til metoder og koder mere "ad hoc", dette er ofte bedrifter
som sliter eller som er i en "grunder" fase...
Geir Harris Hedemark
> Så mine erfaringer tilsier at et godt rammeverk, formet etter oppgaven
> som skal løses er "hellig"!!
> Med de riktige "metodene" kan du trylle dritt om til gull!!!
Det er jeg fullstendig uenig i.
Et metodeverk kan hjelpe deg til å få gullet fram i lyset. Du kan ha
en så rigid metodeonani på plass du bare vil dersom de som skal utføre
arbeidet ikke vet hva de gjør.
I noen tilfeller er det å bruke en metode det som fører til mest
forbedringer med lavest kostnad. I andre tilfeller kan du kun få
marginale forbedringer.
Geir - tilhenger av å rette på det svakeste leddet først.
Espen Vestre
> UML er et bildespråk for å vise deler av et OO-design.
Slik jeg opplever UML (jeg har heldigvis klart å unngå å havne i
prosjekter der det faktisk har blitt brukt), er det først og fremst
et verktøy for prosjektledere og systemarkitekter som vil "programmere"
selv om de ikke har talent for det.
Det er derfor et utmerket verktøy til å innføre en hackeordning mellom
liksom-utviklerne og utviklerne.
--
(espen)
Torkel Holm
Nå bruker vel du en OO-modell som ikke helt er hånd i hanske med UML ;)
Tenker f.eks. på multimetoder, metodekombinasjoner og innkapsling.
Har sett mange hackerløsninger med bruk av stereotyper og patterns.
Mulig UML2 og utvidelsesprofiler løser på noen av problemene.
Multiparadigmehacking er en annen sak...
--
Torkel Holm
Thomas Hansen
<espen@*do-not-spam-me*.vestre.net> left his sanity behind and
proclaimed:
>Jon Haugsand <jon...@ifi.uio.no> writes:
************* TABBE *************
!!
UML er mer eller mindre guds gave til utviklere (og da snakker jeg
ikke om _liksom_ utviklere) som lager mere avanserte systemer enn
hello world applikasjoner!
Hvis det er din oppfatning av UML så bør du definitivt revurdere den
ved f.eks. å lese en bok om det eller no' sånt!
UML er et utrolig nyttig verktøy for å designe/dokumentere og
implementere et mellomstort til stort system!
Det brukes hyppigt i design fasen (ikke si at design fasen er
unødvendig nå, hvis du ønsker å fortsatt beholde litt av "æren" din)
og det brukes hyppig som referanse i implementasjons fasen og det er i
seg selv nesten fullgod dokumentasjon av et eksisterende system...
Og enda har jeg ikke omtalt "round tripping" hvor det blir den
drivende kraften i selve implementasjons fasen i tillegg!!!
Ta et system på mere enn 5000 linjer med kode å prøv å få et overblikk
over det for å forstå det så vil du skjønne hva jeg mener...
Uten UML er dette en jobb som kan ta uker, med UML er det gjort i
løpet av minutter...
Thomas Hansen
<ge...@dod.no> left his sanity behind and proclaimed:
...ok da...
...litt overdrevent muligens...
...men!
Joda, du har selvfølgelig rett, men det er bedre å evangelisere med
metode ovenfor en som ikke skjønner metode enn å "bort evangelisere"
metode ovenfor en som bruker det som onani materiale...
Jeg vil nok tro at det i dag er et større problem med "mangel på
metode" enn "metode onani" er...
Thomas Hansen
<youJerk...@iHateYou.com> left his sanity behind and proclaimed:
[snip]
Forresten!
Det eneste som er irriterende med det er at det ikke finnes reell
støtte for templates i C++ i noen eksisterende roundtripping editorer.
Og at alt blir veldig irriterende i det øyblikket du bringer templates
inn i bildet i det hele tatt.
Geir Harris Hedemark
> >Det er derfor et utmerket verktøy til å innføre en hackeordning mellom
> >liksom-utviklerne og utviklerne.
> ************* TABBE *************
> ved f.eks. å lese en bok om det eller no' sånt!
UML kan være veldig nyttig brukt av utviklere. UML kan også være et
forbannet sløseri med tid dersom det ikke brukes av folk som vet hva
de gjør. Det kan du for øvrig si om omtrent alle tilsvarende
teknologier.
"En slegge" kan være veldig nyttig. Det øyeblikket en amatør bruker
"slegge" for å "montere topplokket ved å slå boltene ned i blokka" er
verktøyet "slegge" ikke lenger veldig nyttig.
Bytt ut frasene i parentes med analoge uttrykk for din
favoritteknologi.
Dersom du mener at alle som påpeker at det er mulig å misbruke ethvert
verktøy gjør en tabbe vet jeg ikke helt hva du bør gjøre. Det hjelper
definitivt ikke å lese en bok.
Geir
Espen Vestre
> Hvis det er din oppfatning av UML så bør du definitivt revurdere den
> ved f.eks. å lese en bok om det eller no' sånt!
Jeg har vært på konferanser og hørt foredrag av uml-fedrene, så
jeg er ikke helt på jordet.
For å fortsette den spydige meningsutvekslingen: Hvilket uml-firma er du
selger for?
--
(espen)
Geir Harris Hedemark
> Jeg vil nok tro at det i dag er et større problem med "mangel på
> metode" enn "metode onani" er...
Jeg tror det største problemet i dag er folk som har sett en løsning
fungere, og som derfor tror at samme løsning appliserer til alle andre
problemer. Hype og buzzwords ser ut til å ha tatt over for evnen til å
tenke. Jeg kritiserer ikke deg - dette er et bransjeproblem, ledet an
av den kulørte datapresse og de store konsulentbyråene som har
fakturerbare timer som sitt viktigste produkt.
Geir
Espen Vestre
> Jeg tror det største problemet i dag er folk som har sett en løsning
> fungere, og som derfor tror at samme løsning appliserer til alle andre
> problemer. Hype og buzzwords ser ut til å ha tatt over for evnen til å
> tenke.
bytt ut "har sett en løsning fungere" med "har blitt presentert en løsning
som tilsynelatende fungerer" eller "tror de har sett en løsning fungere",
så er vi ganske enige ;-)
--
(espen)
Torkel Holm
> UML er mer eller mindre guds gave til utviklere (og da snakker jeg
> ikke om _liksom_ utviklere) som lager mere avanserte systemer enn
> hello world applikasjoner!
Tror du må ta en kikk ut av C++-boksen!
Det er problematiske å bruke UML til mer fleksible OO-modeller
enn de du finner i C++ og Java. Ga noen hint her:
<873c70x...@dhcp-8-14-154.magnusbarfotsgt.privnett.uib.no>
> Hvis det er din oppfatning av UML så bør du definitivt revurdere den
> ved f.eks. å lese en bok om det eller no' sånt!
>
> UML er et utrolig nyttig verktøy for å designe/dokumentere og
> implementere et mellomstort til stort system!
> Det brukes hyppigt i design fasen (ikke si at design fasen er
> unødvendig nå, hvis du ønsker å fortsatt beholde litt av "æren" din)
> og det brukes hyppig som referanse i implementasjons fasen og det er i
> seg selv nesten fullgod dokumentasjon av et eksisterende system...
Bruker du fossefallsmodellen?
> Og enda har jeg ikke omtalt "round tripping" hvor det blir den
> drivende kraften i selve implementasjons fasen i tillegg!!!
>
> Ta et system på mere enn 5000 linjer med kode å prøv å få et overblikk
> over det for å forstå det så vil du skjønne hva jeg mener...
> Uten UML er dette en jobb som kan ta uker, med UML er det gjort i
> løpet av minutter...
UML har ingenting med saken å gjøre. God dokumentasjon og rekflektive
programmeringsmiljøer derimot...
At det er fint med standardiserte figurer er det ikke tvil om.
--
Torkel Holm
Espen Myrland
> In the era of Mon, 19 Apr 2004 09:26:35 +0200, Espen Vestre
> <espen@*do-not-spam-me*.vestre.net> left his sanity behind and
> proclaimed:
>
> >Det er derfor et utmerket verktøy til å innføre en hackeordning mellom
> >liksom-utviklerne og utviklerne.
> ************* TABBE *************
>
> !!
>
> UML er mer eller mindre guds gave til utviklere (og da snakker jeg
Det er bra du gir han inn! (Synes du også det er kult å få printerne til
fungere? :-)
--
mv, espen
Thomas Hansen
<ge...@dod.no> left his sanity behind and proclaimed:
Leste du egentlig posten til Espen?!?
Jeg siterer:
"Slik jeg opplever UML (jeg har heldigvis klart å unngå å havne i
prosjekter der det faktisk har blitt brukt), er det først og fremst
et verktøy for prosjektledere og systemarkitekter som vil
"programmere"
selv om de ikke har talent for det. "
Han sier der at UML er søppel, punktum...
Det blir ikke sagt noe om at det "kan være søppel hvis misbrukt" eller
noe sånt, han sier det er søppel, punktum!
Så hvis du viser meg hvor han påpeker at det er mulig å misbruke UML
som verktøy og at det da er en klamp rundt foten i utviklings
prosessen (noe som jeg kan være tilbøylig til å være enig i) så skal
jeg printe ut denne posten på A2 format å spise den med teskje!!
Thomas Hansen
<tor...@ii.uib.no> left his sanity behind and proclaimed:
>Thomas Hansen <youJerk...@iHateYou.com> writes:
>> UML er mer eller mindre guds gave til utviklere (og da snakker jeg
>> ikke om _liksom_ utviklere) som lager mere avanserte systemer enn
>> hello world applikasjoner!
>
>Tror du må ta en kikk ut av C++-boksen!
>Det er problematiske å bruke UML til mer fleksible OO-modeller
>enn de du finner i C++ og Java. Ga noen hint her:
><873c70x...@dhcp-8-14-154.magnusbarfotsgt.privnett.uib.no>
Godt mulig, men Espen sa at UML var, jeg siterer nok en gang:
[sitat]
"Slik jeg opplever UML (jeg har heldigvis klart å unngå å havne i
prosjekter der det faktisk har blitt brukt), er det først og fremst
et verktøy for prosjektledere og systemarkitekter som vil
"programmere"
selv om de ikke har talent for det.
Det er derfor et utmerket verktøy til å innføre en hackeordning mellom
liksom-utviklerne og utviklerne."
[/sitat]
Og hvis ikke du er uenig i det (som Espen sa), så har du ingenting i
sektoren å gjøre, sorry...!
>
>> Hvis det er din oppfatning av UML så bør du definitivt revurdere den
>> ved f.eks. å lese en bok om det eller no' sånt!
>>
>> UML er et utrolig nyttig verktøy for å designe/dokumentere og
>> implementere et mellomstort til stort system!
>> Det brukes hyppigt i design fasen (ikke si at design fasen er
>> unødvendig nå, hvis du ønsker å fortsatt beholde litt av "æren" din)
>> og det brukes hyppig som referanse i implementasjons fasen og det er i
>> seg selv nesten fullgod dokumentasjon av et eksisterende system...
>
>Bruker du fossefallsmodellen?
UML er ikke bundet til fossefalls metoden, hvis du f,eks, bruker
Rational Rose XDE i Visual studio .Net (managed) så har du en funksjon
som heter "roundtripping" som gjør det til at UML modellen oppdateres
mens du koder, vice versa...
Men, nei!
Jeg bruker ikke fossefallsmetoden...
>
>> Og enda har jeg ikke omtalt "round tripping" hvor det blir den
>> drivende kraften i selve implementasjons fasen i tillegg!!!
>>
>> Ta et system på mere enn 5000 linjer med kode å prøv å få et overblikk
>> over det for å forstå det så vil du skjønne hva jeg mener...
>> Uten UML er dette en jobb som kan ta uker, med UML er det gjort i
>> løpet av minutter...
>
>UML har ingenting med saken å gjøre. God dokumentasjon og rekflektive
>programmeringsmiljøer derimot...
>At det er fint med standardiserte figurer er det ikke tvil om.
Hvordan kan du si at UML ikke har noe med saken (dokumentasjon) å
gjøre?!?
Det gir deg en grafisk oversikt over alle klassene. (med mindre du
bruker OOP modeller som UML ikke kan beskrive, f.eks. avansert C++
templates klassehierarkier ol...)
Det gir deg også en grafisk fremstilling av relasjonene mellom
klassene, hvor gjennomført encapsulation i systemet er, hvor flinke
arkitektene har vært til å benytte Design Patterns, filosofien i
designet etc...
List goes on!
UML var kanskje ikke i utgangspunktet ment som et dokumentasjons
verktøy, men det gjør jobben bedre enn alle andre eksisterende
dokumentasjons verktøyer!
Og jeg har en del erfaringer med forskjellige dokumentasjons
verktøyer!
( se f.eks.: http://smartwin.sourceforge.net/doc/index.html )
Thomas Hansen
<ThatShouldGeta...@toycompute.net> left his sanity behind
and proclaimed:
>Thomas Hansen <youJerk...@iHateYou.com> writes:
>
>> In the era of Mon, 19 Apr 2004 09:26:35 +0200, Espen Vestre
>> <espen@*do-not-spam-me*.vestre.net> left his sanity behind and
>> proclaimed:
>>
>> >Det er derfor et utmerket verktøy til å innføre en hackeordning mellom
>> >liksom-utviklerne og utviklerne.
>> ************* TABBE *************
>>
>> !!
>>
>> UML er mer eller mindre guds gave til utviklere (og da snakker jeg
>
>
[ironisk_undertone]
>Det er bra du gir han inn!
[/ironisk_undertone]
Vel, det var en så lite innsiktsfull post at jeg følte at jeg hadde et
redaksjonelt ansvar for å la evt. newbies som browsa gruppene virkelig
få føle at dette var et utsagn som ikke var verdt å ta seriøst!
[ironisk_undertone]
> (Synes du også det er kult å få printerne til
>fungere? :-)
[/ironisk_undertone]
[sarkastisk_undertone]
Jeg er Systemutvikler og System Arkitekt (jobber med mye "lissom
utvikling") og er derfor forskånet for alt som har med drift å gjøre.
[/sarkastisk_undertone]
:0
...forøvrig ville jeg sannsynligvis ikke klart å få printeren til å
fungere!
;)
Thomas Hansen
<ge...@dod.no> left his sanity behind and proclaimed:
>Thomas Hansen <youJerk...@iHateYou.com> writes:
Dette kan jeg helt klart være enig i!
Men det er et generelt problem mennesket har som dyreart, og ikke et
spesifikt software utviklings problem...
Det samme kan sikkert sies om bussjåfører og barnehage assistenter!!
Men jeg har gode erfaringer med flere metoder, og i et middels stort
til stort prosjekt med 3 eller flere utviklere er min erfaring at hvis
du ikke har et avklart forhold til selve prosessen så har prosessen
kontroll over deg...
Og det er faktisk tilfelle (forsket på av Microsoft) at i etterkant av
et prosjekt vil statistisk sett 24% av prosjektlederne si at
prosjektet ble gjennomført som planlagt og at det var en suksess!
Men over ** 50% ** av SAMTLIGE prosjekter vil faktisk bli direkte
MISLYKKET!!!
Og det som kjennetegner de som definerer prosjektet som "vellykket"
har en ting til felles...
...et avklart og gjennomtenkt forhold til prosess og metode!!
Så kan prosessen hete MSF, RUP, XP eller for den saks skyld "Thomas
Sin Kule Software Utvikling Metode".
Bare for guds skyld (og din egen skyld) bruk en gjennomtenkt metode,
helst en som er testet og som du vet fungerer!
Vetle Roeim
> In the era of Mon, 19 Apr 2004 17:18:42 +0200, Torkel Holm
> <tor...@ii.uib.no> left his sanity behind and proclaimed:
>
>>Thomas Hansen <youJerk...@iHateYou.com> writes:
>>> Ta et system på mere enn 5000 linjer med kode å prøv å få et overblikk
>>> over det for å forstå det så vil du skjønne hva jeg mener...
>>> Uten UML er dette en jobb som kan ta uker, med UML er det gjort i
>>> løpet av minutter...
>>
>>UML har ingenting med saken å gjøre. God dokumentasjon og rekflektive
>>programmeringsmiljøer derimot...
>>At det er fint med standardiserte figurer er det ikke tvil om.
>
> Hvordan kan du si at UML ikke har noe med saken (dokumentasjon) å
> gjøre?!?
Det viktige er ikke nødvendigvis at det er UML som er brukt, men at
systemet faktisk er _dokumentert_.
> Det gir deg en grafisk oversikt over alle klassene.
UML "gir" deg ikke noe som helst. Du må selv lage oversikten. En
kunne like gjerne funnet opp sin egen notasjon, men fordelen med UML
er at det er standardisert.
Du raver i vei om UML som om det skulle være noen slags form for
magi. Det er det ikke.
[...]
--
#!/usr/bin/vr
Jon Haugsand
> UML var kanskje ikke i utgangspunktet ment som et dokumentasjons
> verktøy, men det gjør jobben bedre enn alle andre eksisterende
> dokumentasjons verktøyer!
> Og jeg har en del erfaringer med forskjellige dokumentasjons
> verktøyer!
> ( se f.eks.: http://smartwin.sourceforge.net/doc/index.html )
Den store fordelen med språk som UML er at man kan snakke samme språk,
når man presenterer et diagram, kan alle umiddelbart skjønne hva man
snakker om.
Den store ulempen er at mange tror dette er alt, det er bare å lære
seg UML så kan man utvikle programmer.
(I parentes bemerket er det flere andre ting jeg ikke liker med UML:
(1) det er grafisk: Vi uttrykker oss egentlig ikke i bilder, vi
snakker i ord og begreper, (2) det mangler abstraksjonsverktøy: Et
komplisert problem trenger oppbygging av gode koseptuelle biblioteker,
men hvordan uttrykker vi slik oppdeling?, (3) Det er overfokusert på
OO, hva med andre paradigmer som de funksjonelle?)
Espen Vestre
> Og hvis ikke du er uenig i det (som Espen sa), så har du ingenting i
> sektoren å gjøre, sorry...!
Jaha. Hvilken sektor er det du snakker om her da?
Det er sikkert noen som kan ha glede av UML, særlig hvis de bruker et
av de programmeringsspråkene der UML egner seg.
Men at det er "guds gave til utviklerne" er en ganske drøy påstand, og
jeg holder fast ved at det er egnet til lett å bli misbrukt av halv-
tekniske mellomledere som lider av programmeringsmisunnelse.
Jeg blir forøvrig litt overrasket over å finne religiøse
UML-tilhengere her. Jeg hadde faktisk fått inntrykk av at UML var i
ferd med å gå nesten helt tom for buzzwordeffekt og at buzzwordsøkerne
på nytt var ute på jakt etter den Hellige Programmeringsgral.
Så jeg angrer meg ikke på at jeg tok hardt i, det er jo morsomt å
se hva slags profeter som spretter opp når man tråkker religionen
deres på tærne ;-)
--
(espen)
Geir Harris Hedemark
> Og hvis ikke du er uenig i det (som Espen sa), så har du ingenting i
> sektoren å gjøre, sorry...!
Jeg synes ekstremister burde tas med ut bak låven og skytes.
Du snakker om ting det ikke virker som om du har bred nok erfaring
med. Det eksisterer andre systemer (SDL er et av de) som gir
tilsvarende funksjonalitet. Det finnes også problemområder der UML er
totalt uegnet. Du vet ikke om Espen jobber med et av de
områdene.
Hardwaredesign er per i dag i praksis programmering, men UML er totalt
uegnet. Det stopper ikke velmenende programmerere fra å generere
sidevis med totalt unyttig UML som de så mener skal danne grunnlag for
HW-hodenes design. UML er et verktøy de forstår (onde tunger ville
kanskje sagt det eneste), og dermed har alle å forholde seg til
det. Det at UML er lite egnet til å gjøre noe hardwarerelatert i er
underordnet - de kjenner et verktøy, og Verktøyet Er Gud.
I slike situasjoner er UML en klamp om foten. Dersom Espen ikke har
opplevd noe annet er det forbannet arrogant av deg å bare avfeie
erfaringene hans som ubrukelige.
Geir
Thomas Hansen
<ve...@online.no> left his sanity behind and proclaimed:
>* Thomas Hansen
>> In the era of Mon, 19 Apr 2004 17:18:42 +0200, Torkel Holm
>> <tor...@ii.uib.no> left his sanity behind and proclaimed:
>>
>>>Thomas Hansen <youJerk...@iHateYou.com> writes:
>[...]
>>>> Ta et system på mere enn 5000 linjer med kode å prøv å få et overblikk
>>>> over det for å forstå det så vil du skjønne hva jeg mener...
>>>> Uten UML er dette en jobb som kan ta uker, med UML er det gjort i
>>>> løpet av minutter...
>>>
>>>UML har ingenting med saken å gjøre. God dokumentasjon og rekflektive
>>>programmeringsmiljøer derimot...
>>>At det er fint med standardiserte figurer er det ikke tvil om.
>>
>> Hvordan kan du si at UML ikke har noe med saken (dokumentasjon) å
>> gjøre?!?
>
> Det viktige er ikke nødvendigvis at det er UML som er brukt, men at
> systemet faktisk er _dokumentert_.
Det har jeg heller aldri påstått!
Det jeg har påstått er at UML som dokumentasjon gjør det enklere og
raskere å forstå systemet!
>
>
>> Det gir deg en grafisk oversikt over alle klassene.
>
> UML "gir" deg ikke noe som helst. Du må selv lage oversikten. En
> kunne like gjerne funnet opp sin egen notasjon, men fordelen med UML
> er at det er standardisert.
>
> Du raver i vei om UML som om det skulle være noen slags form for
> magi. Det er det ikke.
Jeg raver ikke i det hele tatt, jeg bare påpeker en usannhet...
...igjen må jeg visst sitere Espen:
"Slik jeg opplever UML (jeg har heldigvis klart å unngå å havne i
prosjekter der det faktisk har blitt brukt), er det først og fremst
et verktøy for prosjektledere og systemarkitekter som vil
"programmere"
selv om de ikke har talent for det. "
Da jeg kom med motargumenter mot dette utsagnet ble jeg møtt med en
vegg av motbør som verden ikke har sett maken til siden
steinalderen...
Det eneste jeg prøvde å poengtere var at Espen var (way far) "ute på
jordet" når han nedgraderte UML til å være en hype greie kun brukbar
for "lissom programmere" som hadde mye fine ord og lite konkrete
handlinger!
Men før du svarer på dette innlegget vil jeg gjerne vite om du er enig
i utsagnet til Espen?
Foreløpig har alle dine innlegg mot mitt motinnlegg tydet på at du
faktisk er det!
(Hvis du ikke svarer på det siste spørsmålet men fortsetter å
"orkløve" meg på mine ovenstående ord så gidder jeg ikke svare deg!)
Thomas Hansen
<jon...@ifi.uio.no> left his sanity behind and proclaimed:
>* Thomas Hansen
>> UML var kanskje ikke i utgangspunktet ment som et dokumentasjons
>> verktøy, men det gjør jobben bedre enn alle andre eksisterende
>> dokumentasjons verktøyer!
>> Og jeg har en del erfaringer med forskjellige dokumentasjons
>> verktøyer!
>> ( se f.eks.: http://smartwin.sourceforge.net/doc/index.html )
>
>Den store fordelen med språk som UML er at man kan snakke samme språk,
>når man presenterer et diagram, kan alle umiddelbart skjønne hva man
>snakker om.
Akkurat!!
>
>Den store ulempen er at mange tror dette er alt, det er bare å lære
>seg UML så kan man utvikle programmer.
Vel, jeg kjenner ingen som tror at de "kan" systemutvikle bare fordi
de skjønner forskjellen på en "+" og en "-" i et UML diagram...
Men joda hvis du kjenner slike folk, kan jeg være tilbøyelig til å
innrømme at det kan fortone seg som et stort problem, spesielt hvis
det er noen med myndighet og autoritet!
>
>(I parentes bemerket er det flere andre ting jeg ikke liker med UML:
>(1) det er grafisk: Vi uttrykker oss egentlig ikke i bilder, vi
>snakker i ord og begreper,
Feil!
Vi tenker i bilder, så transformerer vår venstre hjernehalvdel våre
(billedlige) tanker om til ord, noe som forøvrig forkvakler den
opprinnelige tanken.
Så blir ordene transformert tilbake inn i venstre hjernehalvdel hos
mottageren som igjen skal transformere dette om til bilder han kan
forstå!
Slik sett er bilder en mye mere "direkte" kommunikasjonsform enn ord
og språk!
I tillegg så er det du sier om at UML er bilder heller ikke helt sant,
prøv å skrive en funksjons signatur i UML uten bruk av alfabetet!
(hint: "# Clone() : MyObject"...)
>(2) det mangler abstraksjonsverktøy:
Med risiko for at jeg har misforstått hva du mener med
abstraksjonsbiblioteker tør jeg påstå at du også her tar feil...
Du har "abstraksjonsverktøyene" Rational Rose XDE, Visio, DIA etc...
> Et
>komplisert problem trenger oppbygging av gode koseptuelle biblioteker,
>men hvordan uttrykker vi slik oppdeling?
Packages f.eks...
>, (3) Det er overfokusert på
>OO, hva med andre paradigmer som de funksjonelle?)
Enig!
Men UML er konstruert for å gjøre det enklere å programmere i OOP
språk, det du sier der kan like godt sies om kaffetraktere, de er
overfokuserte på kaffebønner!
En spade er en spade, og en spade graver vi i jorden med, hvis vi skal
plukke epler så bruker vi ikke en spade!!
På samme måte bruker vi UML hvis vi skal programmere i et OOP språk!
Jeg har tidligere selv påpekt svakhetene med UML hvis du f.eks. bruker
tungt med avanserte templates konstruksjoner i C++!!
Det finnes sikkert flere eksempler på uadekvate anvendelsesområder for
UML...
Thomas Hansen
<espen@*do-not-spam-me*.vestre.net> left his sanity behind and
proclaimed:
>Thomas Hansen <youJerk...@iHateYou.com> writes:
>
>> Og hvis ikke du er uenig i det (som Espen sa), så har du ingenting i
>> sektoren å gjøre, sorry...!
>
>Jaha. Hvilken sektor er det du snakker om her da?
>
>Det er sikkert noen som kan ha glede av UML, særlig hvis de bruker et
>av de programmeringsspråkene der UML egner seg.
Det har du helt rett i...
...blant de som HAR bruk for det er:
* Alle de koderne som programmerer i Java.
* Alle de koderne som programmerer i C#
* Alle de koderne som programmerer i Python
* Alle de koderne som programmerer i C++ (med "templates unntak", noe
som de færreste virkelig behersker)
* Alle de koderne som programmerer i Ada
* Alle de koderne som programmerer i Delphi
(...ojsann, da var det visst ikke så mange igjen gitt...)
>
>Men at det er "guds gave til utviklerne" er en ganske drøy påstand, og
>jeg holder fast ved at det er egnet til lett å bli misbrukt av halv-
>tekniske mellomledere som lider av programmeringsmisunnelse.
>
>Jeg blir forøvrig litt overrasket over å finne religiøse
>UML-tilhengere her. Jeg hadde faktisk fått inntrykk av at UML var i
>ferd med å gå nesten helt tom for buzzwordeffekt og at buzzwordsøkerne
>på nytt var ute på jakt etter den Hellige Programmeringsgral.
>
>Så jeg angrer meg ikke på at jeg tok hardt i, det er jo morsomt å
>se hva slags profeter som spretter opp når man tråkker religionen
>deres på tærne ;-)
Jeg er ikke "UML religiøs" i det hele tatt, men jeg var nødt til å
tilbakevise en ganske drøy og usaklig påstand om et verktøy som ihvert
fall JEG har i kofferten min og som jeg drar frem når jeg trenger det,
så får andre folk ha sine verktøy i sine kofferter, men uten UML i
kofferten er det vanskelig å progge OOP effektivt...
...det er IKKE en mening men et faktum!
Vetle Roeim
> In the era of Tue, 20 Apr 2004 09:00:31 +0200, Vetle Roeim
> <ve...@online.no> left his sanity behind and proclaimed:
>
>>* Thomas Hansen
[...]
>>> gjøre?!?
>>
>> Det viktige er ikke nødvendigvis at det er UML som er brukt, men at
>> systemet faktisk er _dokumentert_.
>
> Det har jeg heller aldri påstått!
Så vidt jeg kan se har du ikke gitt uttrykk for noe annet.
F.eks. i <09e780d5s1rfo3ije...@4ax.com> skriver du:
"Ta et system på mere enn 5000 linjer med kode å prøv å få et
overblikk over det for å forstå det så vil du skjønne hva jeg
mener... Uten UML er dette en jobb som kan ta uker, med UML er
det gjort i løpet av minutter..."
> Det jeg har påstått er at UML som dokumentasjon gjør det enklere og
> raskere å forstå systemet!
Først nå velger du å moderere synspunktene dine. Du burde gjort det
fra begynnelsen av.
>>> Det gir deg en grafisk oversikt over alle klassene.
>>
>> UML "gir" deg ikke noe som helst. Du må selv lage oversikten. En
>> kunne like gjerne funnet opp sin egen notasjon, men fordelen med UML
>> er at det er standardisert.
>>
>> Du raver i vei om UML som om det skulle være noen slags form for
>> magi. Det er det ikke.
>
> Jeg raver ikke i det hele tatt, jeg bare påpeker en usannhet...
Eh? Var det ikke du som påstod at UML var "mer eller mindre" Guds
gave til utviklere?
> ...igjen må jeg visst sitere Espen:
Nei, det må du ikke. Dette har ingenting med Espen Vestre å gjøre.
[Vestres utsagn om UML]
>
> Da jeg kom med motargumenter mot dette utsagnet ble jeg møtt med en
> vegg av motbør som verden ikke har sett maken til siden
> steinalderen...
Det er ikke så rart, med tanke på hvordan du formulerte deg.
[...]
> Men før du svarer på dette innlegget vil jeg gjerne vite om du er enig
> i utsagnet til Espen?
Du har misforstått Espen Vestres utsagn, så det blir litt menigsløst
å svare på dette.
> Foreløpig har alle dine innlegg mot mitt motinnlegg tydet på at du
> faktisk er det!
*Alle* mine motinnlegg? Så vidt jeg kan husker (og se i følge
groups.google.com), så har jeg bare kommet med _ett_ motinnlegg.
[...]
--
#!/usr/bin/vr
Thomas Hansen
<ge...@dod.no> left his sanity behind and proclaimed:
Er folk blind på begge øynene her?!?!?!?
Jeg siterer NOK en gang:
[sitat]
"Slik jeg opplever UML (jeg har heldigvis klart å unngå å havne i
prosjekter der det faktisk har blitt brukt), er det først og fremst
et verktøy for prosjektledere og systemarkitekter som vil
"programmere"
selv om de ikke har talent for det.
Det er derfor et utmerket verktøy til å innføre en hackeordning mellom
liksom-utviklerne og utviklerne."
[sitat]
Hvis ikke det er mere ekstremistiskt enn mine utsagn så vet ikke jeg
hvilken planet du bor på...
Han sier han "ikke har erfaringer med det".
Han sier det er et verktøy for prosjektledere og system arkitekter som
vil "programmere".
(De fleste systemarkitekter jeg kjenner er betraktelig mye flinkere å
programmere enn samtlige "programmerere", det blir ofte slik iom at
"systemarkitekt" ofte er en FORFREMMELSE på grunnlag av mange års jobb
som programmerer!)
Forøvrig kan du lese posten min (om spader og sånt) et par linjer opp
i tråden...
Så får vi se på hvem som blir tatt med bak låven "at the end of the
day"...
Jon Haugsand
> >(I parentes bemerket er det flere andre ting jeg ikke liker med UML:
> >(1) det er grafisk: Vi uttrykker oss egentlig ikke i bilder, vi
> >snakker i ord og begreper,
>
> Feil!
> Vi tenker i bilder, så transformerer vår venstre hjernehalvdel våre
> (billedlige) tanker om til ord, noe som forøvrig forkvakler den
> opprinnelige tanken.
> Så blir ordene transformert tilbake inn i venstre hjernehalvdel hos
> mottageren som igjen skal transformere dette om til bilder han kan
> forstå!
> Slik sett er bilder en mye mere "direkte" kommunikasjonsform enn ord
> og språk!
Eh, så enkelt er det ikke. Jeg er helt enig i at vi tenker i bilder,
og at god romlig tenkeevne er en kjempefordel i enhver intellektuell
problemløsning. Men vårt språk har alltid vært en linær strøm av ord,
og ethvert begrep navngis med ord. Det er ordene, de abstrakte
begrepenes navn, som gjør oss til mennesker. Mennesket har gjennom
flere tusen år bygget opp en enorm kunnskapsbase basert på språk, og
der finner du ikke hjelpemidler som UML, men du finner en helt vanlig
sekvensiell strøm av ord.
Bilder er som du skriver "mer direkte", og dermed enklere. Dette er
ikke å forakte, men det er likevel ikke den veien vi har gått gjennom
historien for å bygge kompliserte abstraksjoner. Derfor er UML kun
for enkle problemer, ikke for de avanserte.
> >(2) det mangler abstraksjonsverktøy:
>
> Med risiko for at jeg har misforstått hva du mener med
> abstraksjonsbiblioteker tør jeg påstå at du også her tar feil...
> Du har "abstraksjonsverktøyene" Rational Rose XDE, Visio, DIA etc...
Eh, nei, litt dårlig uttrykt av meg. Jeg mener at det ikke finnes
gode hjelpemidler _i språket_ for å bygge abstraksjoner. Her er det
mulig jeg tar feil, men det forekommer meg helt feil å tro at et
komplisert problem lar seg beskrive gjennom "Use case" som er
innfallsporten til problemløsning.
Jeg ser for meg en måte å splitte et problem i _abstraksjonslag_ (som
OSI-modellen) der hvert lag løser sine egne problemer internt. Er
dette i det hele tatt mulig å uttrykke i UML på en fornuftig måte?
Espen Vestre
> Han sier det er et verktøy for prosjektledere og system arkitekter som
> vil "programmere".
Nei, jeg sier at jeg "opplever" det slik, jeg trodde at det var nok
til å understreke at det var en relativt subjektiv uttalelse. Jeg
trodde også UML var langt nok ute av motebildet til at jeg ikke ville
møte og dermed såre religiøse tilbedere som deg.
> (De fleste systemarkitekter jeg kjenner er betraktelig mye flinkere
> å programmere enn samtlige "programmerere",
Mitt utsagn var da ikke nedsettende om systemarkitekter generelt?
(En gang stod det forøvrig "Chief Architect" på visittkortet mitt)
--
(espen)
Alf P. Steinbach
>
> Det er ordene, de abstrakte begrepenes navn, som gjør oss til mennesker.
Skyt de døvstumme!
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Geir Harris Hedemark
> Bilder er som du skriver "mer direkte", og dermed enklere. Dette er
> ikke å forakte, men det er likevel ikke den veien vi har gått gjennom
> historien for å bygge kompliserte abstraksjoner. Derfor er UML kun
> for enkle problemer, ikke for de avanserte.
Mener du virkelig det du skriver?
Det er kun de siste hundre årene menneskene har begynt å bygge seriøst
kompliserte abstraksjoner. Jeg har ingen problemer med å se at en 6000
år gammel teknologi (?) vil måtte videreutvikles og bygges på for å ta
opp i seg muligheten til lett å fremstille menneskehetens nye
konsepter. Jeg tror ikke UML er veien, sannheten og livet på noen som
helst slags måte, men jeg ser at det er bedre enn f.eks. SDL eller
lineær tekst.
Geir
Geir Harris Hedemark
> Jeg siterer NOK en gang:
>
> [sitat]
Jeg foreslår at du tenker over "jeg opplever" en stund før du tar
dette videre.
Geir
Torkel Holm
> In the era of Mon, 19 Apr 2004 17:18:42 +0200, Torkel Holm
> <tor...@ii.uib.no> left his sanity behind and proclaimed:
>
>>Thomas Hansen <youJerk...@iHateYou.com> writes:
>>> UML er mer eller mindre guds gave til utviklere (og da snakker jeg
>>> ikke om _liksom_ utviklere) som lager mere avanserte systemer enn
>>> hello world applikasjoner!
>>
>>Tror du må ta en kikk ut av C++-boksen!
>>Det er problematiske å bruke UML til mer fleksible OO-modeller
>>enn de du finner i C++ og Java. Ga noen hint her:
>><873c70x...@dhcp-8-14-154.magnusbarfotsgt.privnett.uib.no>
> Godt mulig, men Espen sa at UML var, jeg siterer nok en gang:
>
> [sitat]
> "Slik jeg opplever UML (jeg har heldigvis klart å unngå å havne i
> prosjekter der det faktisk har blitt brukt), er det først og fremst
> et verktøy for prosjektledere og systemarkitekter som vil
> "programmere"
> selv om de ikke har talent for det.
>
> Det er derfor et utmerket verktøy til å innføre en hackeordning mellom
> liksom-utviklerne og utviklerne."
> [/sitat]
Mine argumenter var ikke knyttet til dette sitatet.
UML er bygget opp rundt en snever tolkning av OO-konseptet.
Du preker om UML- og OO-generaliseringer som jeg ikke er enig i.
Dersom man begever seg utenfor stallen må man ty til ad hoc-design.
> Og hvis ikke du er uenig i det (som Espen sa), så har du ingenting i
> sektoren å gjøre, sorry...!
Skal gå i tenkeboksen ;)
--
Torkel Holm
Jon Haugsand
> Det er kun de siste hundre årene menneskene har begynt å bygge seriøst
> kompliserte abstraksjoner.
Dette er opplagt feil, men uten betydning for selve argumentasjonen.
> Jeg tror ikke UML er veien, sannheten og livet på noen som
> helst slags måte, men jeg ser at det er bedre enn f.eks. SDL eller
> lineær tekst.
Jeg har ikke kritisert UML på annen måte enn å si at den er
mangelfull. Alternativene er ikke SDL eller linær tekst.
Bjorn Borud
|
| Uten UML er dette en jobb som kan ta uker, med UML er det gjort i
| løpet av minutter...
it slices! it dices! 5000 linjer kode på minutter!
-Bjørn
--
"I have only proved this to be correct, I have not actually tried it."
-- Donald Knuth
Bjorn Borud
|
| Han sier der at UML er søppel, punktum...
hmm, kanskje man burde se utsagnet i lys av hva slags bakgrunn Vestre
har?
| Så hvis du viser meg hvor han påpeker at det er mulig å misbruke UML
| som verktøy og at det da er en klamp rundt foten i utviklings
| prosessen (noe som jeg kan være tilbøylig til å være enig i) så skal
| jeg printe ut denne posten på A2 format å spise den med teskje!!
tsk tsk, metadiskusjoner.
for meg (og mange andre) er UML notasjon som brukes for å uttrykke
design eller aspekter ved et system. hverken mer eller mindre.
anvendelse eller forståelse av notasjon i seg selv er kun nyttig når
kombinert med kunnskap om det notasjonen brukes for å representere.
at du kan matematisk notasjon gjør deg f.eks ikke til matematiker.
det gjør deg til en som kan matematisk notasjon.
Bjorn Borud
åh, det er *deg*. hvordan i alle dager glapp du gjennom klovnefilteret?
Bjorn Borud
|
| Den store ulempen er at mange tror dette er alt, det er bare å lære
| seg UML så kan man utvikle programmer.
som en kollega av meg pleier å si "...nå kan <sånne> programmere ved å
klikke med musen...", der <sånne> er hva man nå kaller suspekte slips
denne uken.
Erik Naggum
| (I parentes bemerket er det flere andre ting jeg ikke liker med UML:
| (1) det er grafisk: Vi uttrykker oss egentlig ikke i bilder, vi
* Thomas Hansen
| Feil!
Det begynner å bli klart for alle lesere med IQ over 85 at UML nok er
et fornuftig verktøy for de som ville hatt problemer med å barbere seg
om morgenen uten fine grafiske plantegninger.
| Vi tenker i bilder, så transformerer vår venstre hjernehalvdel våre
| (billedlige) tanker om til ord, noe som forøvrig forkvakler den
| opprinnelige tanken.
«Vi»? Det er alment akseptert at man tenker mer i bilder dess mindre
intelligent man er, og mer i abstrakt sprog dess mer intelligent man
er. Abstrakt visualisering som faktisk formidler reell informasjon
krever at den som tegner /først/ er istand til svært abstrakt sprog.
Et meget godt eksempel på dette et Feynman-diagrammer, som klarte å
formidle kunnskap man hadde erhvervet gjennom ekstremt abstrakt sprog
og tenkning grafisk slik at man kunne resonnere om det man så. Å lage
en modell som både er enklere og bedre enn virkeligheten, krever solid
innsikt i den virkeligheten som modelleres. Å lage en modell som bare
er enklere enn virkeligheten, kan enhver ukvalifisert idiot lykkes med
uten problemer -- og det gjør de stadig. UML ser ut til å være et av
de bedre valgene når man er ute etter å gjøre ting enklere enn mulig,
særlig hvis man skal ta ditt ord for det.
| Slik sett er bilder en mye mere "direkte" kommunikasjonsform enn ord
| og språk!
Helt klart. See Figure 1.
Det er så deprimerende å se hva slags mennesker som tiltrekkes av det
som går for å være «programmering» i våre dager og hva de betrakter
som interessante problemer og teknologier. Det er dessverre tydelig
at avansert teknologi ikke må komme folket ihende før de smarteste har
gått lei av det, for når folket får tak i det for tidlig, fortsetter
de å løse de samme forbannede problemene som de smarteste ikke løste
for dem om og om og om igjen. De blir like fascinert over å ha funnet
opp det varme vannet hver bidige gang og ivrer voldsomt for å fortelle
alle andre at de klarte å finne det opp helt på egenhånd. De lar seg
absolutt ikke affisere av at de har funnet det opp på en måte som er
så himmelropende uintelligent at det umiddelbart vil flokke til en hel
herskare av andre nedsnedde idioter som klarer å gjøre en forbedring.
Ni tideler av forbedringene er faktisk forverringer, så de raser over
at noen finner opp vann som er for varmt for dem, slik at de må finne
opp lunkent vann i protest. Slik går det til alle finner opp hver sin
nøyaktig bestemte temperatur på vannet, forskjellig ned til tusendels
grad, som de så markedsfører som den beste vanntemperaturen som løser
alle problemer som alle andre vanntemperaturer /umulig/ kan løse.
Hvis noen lurer på hvorfor moderne datamaskiner crasher så ofte, har
det en meget enkel forklaring: De er så kraftige nå at de plutselig
blir bevisst hva de foretar seg, funderer i noen millisekunder på
meningen med livet, og prompte bestemmer seg for å avslutte lidelsen
og håper på en smertefri og hukommelsesfri reinkarnasjon.
--
Erik Naggum, Oslo, Norway | HTML mail is discarded unread | 2004-112
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Thomas Hansen
<jon...@ifi.uio.no> left his sanity behind and proclaimed:
>* Thomas Hansen
>> >(I parentes bemerket er det flere andre ting jeg ikke liker med UML:
>> >(1) det er grafisk: Vi uttrykker oss egentlig ikke i bilder, vi
>> >snakker i ord og begreper,
>>
>> Feil!
>> Vi tenker i bilder, så transformerer vår venstre hjernehalvdel våre
>> (billedlige) tanker om til ord, noe som forøvrig forkvakler den
>> opprinnelige tanken.
>> Så blir ordene transformert tilbake inn i venstre hjernehalvdel hos
>> mottageren som igjen skal transformere dette om til bilder han kan
>> forstå!
>> Slik sett er bilder en mye mere "direkte" kommunikasjonsform enn ord
>> og språk!
>
>
>Eh, så enkelt er det ikke. Jeg er helt enig i at vi tenker i bilder,
>og at god romlig tenkeevne er en kjempefordel i enhver intellektuell
>problemløsning. Men vårt språk har alltid vært en linær strøm av ord,
>og ethvert begrep navngis med ord. Det er ordene, de abstrakte
>begrepenes navn, som gjør oss til mennesker. Mennesket har gjennom
>flere tusen år bygget opp en enorm kunnskapsbase basert på språk, og
>der finner du ikke hjelpemidler som UML, men du finner en helt vanlig
>sekvensiell strøm av ord.
Joda men hvis du ser på hva formålet med språker er så er det å
uttrykke tanker og ideer overnfor andre medmennesker.
Når så tanker og ideer er i "bildespråket" er det en mye mere direkte
måte å kommunisere ved hjelp av bilder istedenfor å gå "omveien" om
ord...
Se f.eks. arkitektur (altså husbygging), utvikling av oljeledninger,
kart som veibeskrivelser (f.eks. bykart), etc...
Bilder er en iverlegen måte å kommunisere på i all utvikling, det er
bare systemutvikling som henger etter i den sammenhengen!
>
>Bilder er som du skriver "mer direkte", og dermed enklere. Dette er
>ikke å forakte, men det er likevel ikke den veien vi har gått gjennom
>historien for å bygge kompliserte abstraksjoner.
Som sagt: arkitektur, kart, veitraseer, etc...
>Derfor er UML kun
>for enkle problemer, ikke for de avanserte.
UML er en forenkling ja, men det er akkurat det som er styrken til
UML!
Det gir deg muligheten til å "lese terrenget" på en mere oversiktlig
måte enn "breddegrads/lengdegrads koordinater" (kildekode) kan gi deg!
Selvfølgelig hvis du skal oppgi en rute gjennom byen kan en oppgi
denne ruten som en rød strek gjennom et kart (UML) eller som en liste
med breddegrad/lengdegrad koordinater og kompassretninger
(Kildekode)...
Men det er vel liten tvil om hva som er enklest...
>
>
>> >(2) det mangler abstraksjonsverktøy:
>>
>> Med risiko for at jeg har misforstått hva du mener med
>> abstraksjonsbiblioteker tør jeg påstå at du også her tar feil...
>> Du har "abstraksjonsverktøyene" Rational Rose XDE, Visio, DIA etc...
>
>Eh, nei, litt dårlig uttrykt av meg. Jeg mener at det ikke finnes
>gode hjelpemidler _i språket_ for å bygge abstraksjoner. Her er det
>mulig jeg tar feil, men det forekommer meg helt feil å tro at et
>komplisert problem lar seg beskrive gjennom "Use case" som er
>innfallsporten til problemløsning.
Her har vi et argument jeg kan si meg enig i!
Men UML er et relativt nytt (i datahistorien) verktøy, det er fortsatt
i "barndommen", men jeg tror nok at i løpet av overskuelig fremtid vil
se ting som f.eks. en loop på et sett med data bli "tegnet" som et
symbol med f.eks. et "verb" (funksjonskall) inne i seg og at ting som
f.eks. algoritmer og datastrukturer vil kunne tegnes inn som
symboler...
Tipper nok at våre barnebarn programmere vil sitte å le av våre
utviklings idiomier på samme måte som vi kan smile overbærende ovenfor
ZX Spectrum maskin koding.
Verden går videre, og det er liten tvil omm retningen...
Frem til da er UML (på godt og vondt) det beste verktøyet vi har for å
enkelt forstå og designe datasystemer...
Espen Vestre
> Se f.eks. arkitektur (altså husbygging), utvikling av oljeledninger,
> kart som veibeskrivelser (f.eks. bykart), etc...
> Bilder er en iverlegen måte å kommunisere på i all utvikling, det er
> bare systemutvikling som henger etter i den sammenhengen!
I alle tilfellene du nevner brukes bildene til å beskrive 2- eller
3-dimensjonale fysiske objekter. Parallellen til datasystemer blir
derfor nokså svak.
> Tipper nok at våre barnebarn programmere vil sitte å le av våre
> utviklings idiomier på samme måte som vi kan smile overbærende ovenfor
> ZX Spectrum maskin koding.
Det sa de på åttitallet også. Og hvor langt er vi kommet? Egenskapene
til de språkene det hyles mest om (f.eks. java og C++) likner mest på
Simula anno 1967 og slett ikke på 4. generasjonsverktøy fra midt på
åttitallet eller japanske 5. generasjonsverktøy (hva nå de skulle ha
sett ut som om de hadde blitt noe av, et av de spede forsøkene jeg
faktisk har brukt var bare "prolog med noko attåt").
> Verden går videre, og det er liten tvil omm retningen...
Jepp, spørsmålet er bare om vi allerede har passert horisonten til
det svarte hullet eller om det fortsatt er håp ;-)
--
(espen)
Bjørn Mork
> Helt klart. See Figure 1.
Herlig. Ante ikke at den hadde gått inn i den generelle jargongen.
Var jo i sin tid en fin artikkel å trekke frem når man hadde med
DEC-folk å gjøre, både i VMS- og Unix-versjon etter behov. Men
originalen er kanskje enda eldre?
Bjørn
--
I don't want to hear about your real-time clock.
Thomas Hansen
left his sanity behind and proclaimed:
>* Jon Haugsand
[ironi]
La meg se om jeg har forstått deg riktig...
* Leonardi Da Vinci var en imbesil som ikke "designet" rotorotopteret
ved hjelp av 16764543 sammenhengende ord istedenfor et bilde.
* Alle som jobber med kart er halvhjerner ute av stand til å tenke i
abstrakt sprog.
* Ingeniørene i NASA er primat-hjerne-kapasitets-vesener som ikke
bruker formluleringer på mere enn 1500000000000 ord når de konstruerer
utkast til neste genrasjons romferger istedenfor en CAD tegning.
Har jeg forstått deg riktig?
[/ironi]
>
>| Slik sett er bilder en mye mere "direkte" kommunikasjonsform enn ord
>| og språk!
>
> Helt klart. See Figure 1.
>
> Det er så deprimerende å se hva slags mennesker som tiltrekkes av det
> som går for å være «programmering» i våre dager og hva de betrakter
> som interessante problemer og teknologier. Det er dessverre tydelig
> at avansert teknologi ikke må komme folket ihende før de smarteste har
> gått lei av det, for når folket får tak i det for tidlig, fortsetter
> de å løse de samme forbannede problemene som de smarteste ikke løste
> for dem om og om og om igjen. De blir like fascinert over å ha funnet
> opp det varme vannet hver bidige gang og ivrer voldsomt for å fortelle
> alle andre at de klarte å finne det opp helt på egenhånd. De lar seg
> absolutt ikke affisere av at de har funnet det opp på en måte som er
> så himmelropende uintelligent at det umiddelbart vil flokke til en hel
> herskare av andre nedsnedde idioter som klarer å gjøre en forbedring.
> Ni tideler av forbedringene er faktisk forverringer, så de raser over
> at noen finner opp vann som er for varmt for dem, slik at de må finne
> opp lunkent vann i protest. Slik går det til alle finner opp hver sin
> nøyaktig bestemte temperatur på vannet, forskjellig ned til tusendels
> grad, som de så markedsfører som den beste vanntemperaturen som løser
> alle problemer som alle andre vanntemperaturer /umulig/ kan løse.
[ironi]
Helt enig!
Varmt vann er en oppfinelse som burde vært forbeholdt KUN Triple Nine
(999) medlemmer å oppfinne.
Det er en helt absurd avansert problemstilling å løse da det
forutsetter dypere gående kjennskaper om kompliserte konstellasjoner
som bipolare matrise populariserte kjemiske sammenstillinger mellom
salter og diverse derivater av disse igjen!
Jeg vil faktisk våge å gå så langt som å påstå at det ikke engang
burde være mulig å BRUKE uten at en eksaminator har verifisert
eksistensen av evnen til å tenke abstrakt hos kandidaten.
[/ironi]
>
> Hvis noen lurer på hvorfor moderne datamaskiner crasher så ofte, har
> det en meget enkel forklaring: De er så kraftige nå at de plutselig
> blir bevisst hva de foretar seg, funderer i noen millisekunder på
> meningen med livet, og prompte bestemmer seg for å avslutte lidelsen
> og håper på en smertefri og hukommelsesfri reinkarnasjon.
>
Kjøtthue!
Espen Vestre
> La meg se om jeg har forstått deg riktig...
> * Leonardi Da Vinci var en imbesil som ikke "designet" rotorotopteret
> ved hjelp av 16764543 sammenhengende ord istedenfor et bilde.
UML-guden hjelpe deg så treig du er i oppfattelsen, går det ikke snart
opp for deg at et datasystem er mer enn en _gjenstand_? Har du levd så
lenge i vindusverdenen at du _tror_ at What You See Is All You Get?
> Kjøtthue!
*plink*
--
(espen)
Jon Haugsand
> Se f.eks. arkitektur (altså husbygging), utvikling av oljeledninger,
> kart som veibeskrivelser (f.eks. bykart), etc...
> Bilder er en iverlegen måte å kommunisere på i all utvikling, det er
> bare systemutvikling som henger etter i den sammenhengen!
Du har valgt som eksempler her der bilder er en nødvendighet fordi det
faktisk er en romlig struktur som skal modelleres.
Men likevel er det faktisk ikke slik at man tegner hus ved hjelp av
bilder. Man tegner hus ved hjelp av å definere dører og vegger ved
hjelp av verktøy og så setter man inn dører og vegger i husene. På
denne måten har du mulighet til å lage abstrakte evt generelle dører
som du kan bruke. Endrer du på dør-definisjonen, endres alle dørene i
tegningen din.
Det er iallfall slik jeg har skjønt verktøy som autoca, men det er
mulig jeg tar feil, for jeg har ikke brukt det.
Men datasystemer er ikke 2- og 3-dimensjonale objekter.
Men for alt i verden, ikke misforstå. Jeg er på ingen måte imot bruk
av tegninger og bilder. Jeg bare mener at det er for enkelt, og det
er feil innfallsport i det lange løp.
Terje Kvernes
> Egenskapene til de språkene det hyles mest om (f.eks. java og C++)
> likner mest på Simula anno 1967 og slett ikke på
> 4. generasjonsverktøy fra midt på åttitallet eller japanske
> 5. generasjonsverktøy (hva nå de skulle ha sett ut som om de hadde
> blitt noe av, et av de spede forsøkene jeg faktisk har brukt var
> bare "prolog med noko attåt").
fra mitt ståsted ser det ut som om utviklingen av store
programsystemer i stor grad handler om to ting: nye pek-og-klikk
editorer og grafiske verktøy for å beskrive systemet som en serie
med statiske bokser som snakker sammen.
og, språkene man benytter er også tilpasset denne hverdagen.
dynamikk er farlig. dette er vel hovedgrunnen til at jeg ikke er
interessert i å leve av å skrive programvare i dag. sannsynligheten
for at man får jobbe med interessant kode er omtrent lik null, med
mindre man treffer noen bestemte firmaer. ;-)
det _er_ morsomt å se hvordan folk reagerer på kode som genererer
klasser ved behov, inspiserer klassene sine for å avgjøre hvordan de
skal representeres for brukere og samtidig står i produksjon 24/7
uten å feile. de siste kodebitene jeg skrev i den sammenhengen er
små (rundt 10K linjer), men _grunnen_ til at de er så små er
dynamikken. skulle jeg skrevet ut hver enkelt klasse og slikt ville
man fort snakket om det dobbelte. hm, ja, også var dette et språk
som har en tendens til å være kortfattet. *kremt*
(kravspesifikasjonen krevde en del ting i forhold til
unix-integrasjon som gjorde at de tilgjengelige Lisp-miljøene falt
utenfor, dessverre.)
--
Terje
Torkel Holm
> (kravspesifikasjonen krevde en del ting i forhold til
> unix-integrasjon som gjorde at de tilgjengelige Lisp-miljøene falt
> utenfor, dessverre.)
Ble litt nysgjerrig nå. Har du mulighet til å utdype litt?
--
Torkel Holm
Thomas Hansen
<espen@*do-not-spam-me*.vestre.net> left his sanity behind and
proclaimed:
>Thomas Hansen <youJerk...@iHateYou.com> writes:
Tulling!
Hadde du vært mindre arrogant/hoven og mere åpen for å lære deg nye
ting så ville du kanskje vært i stand til å stille et spørsmål på
formen "hvilke erfaringer har dere med" istedenfor "(jeg mener at)
alle som bruker X er idioter"! (bytt ut X med valgfri kunnskap som du
mangler...)
UML er benyttet av samtlige av de største (både i Norge og ellers i
verden) software husene, det brukes for å modellere alt i fra 3D
Action First Person Shooter spill til CRM og ERP systemer!
Og grafiske fremstillinger brukes for å designe alt ifra neste
generasjon med Pentium Prosessorer fra både Intel og AMD til genetiske
mutasjoner hos Insulin produserende griser avlet frem til medisinske
formål...
Bare fordi at du gjorde deg noen erfaringer med UML i forhold til Perl
på slutten av 90 tallet og har noen gode erfaringer med Amiga maskin
kode fra slutten av 80 tallet og derfor tror at du kan alt og er
flinkeste gutten i klassen betyr ikke at ikke andre klarer å jobbe
konstruktivt med OOP og UML!
Du burde kanskje lære deg å lytte til folk med andre erfaring enn deg
selv istedenfor å føle (rettmessig) at din posisjon er truet av andre
folk som IKKE har hoppet av evolusjonstoget...
Espen Vestre
> Hadde du vært mindre arrogant/hoven
Stein i glasshus?
> flinkeste gutten i klassen betyr ikke at ikke andre klarer å jobbe
> konstruktivt med OOP og UML!
Jeg tviler ikke på at noen klarer å jobbe konstruktivt med UML
(men for den slags OOP som jeg driver med ville det vært et
mareritt), men jeg tviler heller ikke på at det i mange sammen-
henger misbrukes.
> selv istedenfor å føle (rettmessig) at din posisjon er truet av andre
> folk som IKKE har hoppet av evolusjonstoget...
Jeg må innrømme at jeg synes det er ganske morsomt å se på alle de som
kjører i ring på leketogbanen sin og ikke legger merke til at det
ikke går framover.
--
(espen)
Terje Kvernes
vel, systemet jeg skrev dytter ut websider fra apache (hardt krav,
ingen egen httpd for tjenesten) og spørres mot fra kommandolinjen.
så og si all informasjonen systemet jobber med hentes ut fra /proc
under linux (eller tilsvarende fra OSX) og parsing av putput fra
kommandoer som "dmidecode" og "lspci". dette involverer selvsagt
mye fikling av tekst. videre har vi en sentral server sammen med en
klient på hver node som dytter data til serveren.
jeg hadde et budsjett på kroner null, og satt dermed igjen med
gratis lisper. ingen av disse synes jeg tilbyr spesielt gode (eller
portable mellom implementasjoner) muligheter for å lage binære
filer, cgi-like løsninger eller kodebiter for tekst-fikkel.
nettverksbiten var heller ikke triviell å få til å bli vakker på
tvers av de implementasjonene jeg testet.
dersom budsjettet mitt ble litt oppgradert så ville jeg gjerne brukt
Allegro eller noe tilsvarende. det ble, for meg, vanskelig å velge
mellom de frie lisp-implementasjonene, ettersom jeg alltid fant noe
fra en annen implementasjon jeg gjerne skulle hatt. :-)
det skal også sies at jeg kan perl godt nok til at jeg kan skrive
perl som er vedlikeholdbar over tid. dessverre er systemet såpass
dynamisk at jeg gjør veldig lite vedlikehold. ny informasjon fra
kjente filer i /proc legges til uten at man merker annet enn at
"jøss, nå vet systemet sånt også. kult".
--
Terje
Espen Vestre
> dersom budsjettet mitt ble litt oppgradert så ville jeg gjerne brukt
> Allegro eller noe tilsvarende.
Vel, budsjettoppgraderingsbehovet for Allegro er av en nokså annen
dimensjon enn for "noe tilsvarende" ;-)
--
(espen)
Bjorn Borud
|
| Har jeg forstått deg riktig?
jeg tror du og Erik snakker litt forbi hverandre.
slik jeg oppfatter Erik mener han ikke nødvendigvis "strøm av ord" når
han snakker om "språk" -- han opererer med "språk" som et mye mer
abstrakt begrep. det er f.eks rimelig å anta at han med "språk" i
forbindelse med Feynmann-diagrammer snarere henspeiler på den
bakenforliggende matematikken til quantum field theory som et "språk".
akronymet UML i seg selv er jo et språk, selv om det bruker ymse
former for grafisk notasjon. mange av disse kan også representeres på
andre måter, eller andre "språk" om du vil.
Bjorn Borud
|
| UML er benyttet av samtlige av de største (både i Norge og ellers i
| verden) software husene, det brukes for å modellere alt i fra 3D
| Action First Person Shooter spill til CRM og ERP systemer!
det er ingen som bestrider det. det noen prøver å formidle er at det
er en _notasjon_ og at det å forstå _notasjonen_ ikke automatisk
impliserer at man er i stand til å designe.
det er også blitt droppet endel hint om at for Espen sin del er ikke
alltid denne notasjonen like hensiktsmessig fordi han ikke benytter en
omgivelse der notasjonen uten videre gjenspeiler det han måtte trenge
å modellere. jeg tror du ville forstå det han sier bedre om du tar
utgangspunkt i det.
| Du burde kanskje lære deg å lytte til folk med andre erfaring enn deg
| selv istedenfor å føle (rettmessig) at din posisjon er truet av andre
| folk som IKKE har hoppet av evolusjonstoget...
lytt til ditt eget råd.
Bjorn Borud
|
| akronymet UML i seg selv er jo et språk, [...]
det var en klønete formulering. det jeg mente å si var at akronymet i
seg selv henspeiler på at man ønsker at notasjonen skal sees på som et
språk.
Alf P. Steinbach
>
> Det er alment akseptert at man tenker mer i bilder dess mindre
> intelligent man er, og mer i abstrakt sprog dess mer intelligent man
> er.
Nah, ikke så vidt jeg kjenner til. Kunne vært kjekt med noen referanser
til hvor du har hentet dette fra. Det _har_ vært en utbredt misoppfatning
blant for eksempel enkelte grupper psykologer, men svjv. ikke i vitenskapen.
Det med at man nødvendigvis tenker i bilder er svjv. også en en oppfatning
som kun har holdt stand hos enkelte grupper ikke-vitenskapsfolk. I dag er
det svjv. en utbredt oppfatning at både blinde og døvstumme tenker.
Thomas Hansen
>Thomas Hansen <youJerk...@iHateYou.com> writes:
>
>> Hadde du vært mindre arrogant/hoven
>
>Stein i glasshus?
>
>> flinkeste gutten i klassen betyr ikke at ikke andre klarer å jobbe
>> konstruktivt med OOP og UML!
>
>Jeg tviler ikke på at noen klarer å jobbe konstruktivt med UML
TAKK!
>(men for den slags OOP som jeg driver med ville det vært et
>mareritt),
Ok, now where talking...
>men jeg tviler heller ikke på at det i mange sammen-
>henger misbrukes.
Sant!
>
>> selv istedenfor å føle (rettmessig) at din posisjon er truet av andre
>> folk som IKKE har hoppet av evolusjonstoget...
>
>Jeg må innrømme at jeg synes det er ganske morsomt å se på alle de som
>kjører i ring på leketogbanen sin og ikke legger merke til at det
>ikke går framover.
Vel, utviklingen går fremover...
* For 20 år siden fantes ikke OOP i noen praktiskt anvendbare
programmerings språk.
* For 10 år siden fantes det ingen adekvate implementasjoner av GC.
* For 5 år siden var AOP (Aspect Oriented Programming) et
forskningsdokument hos Xerox.
* For 3 år siden var praktisk anvendelse av XSLT en utopi.
Verden går fremover og hvis en ikke holder seg oppdatert med nye ting
som kommer går en glipp av mye moro og nye paradigmer som kan hjelpe
deg som systemutvikler uavhengig av hvilke språk en benytter...
Så får en heller bare risikere å innimellom treffe på "idioti"
konsepter som kun fører en inn i ei blindgate, men hvis man ikke
undersøker konseptet vil man jo ikke kunne vite om det er genialt
eller banalt...
Thomas Hansen
<borud...@borud.no> left his sanity behind and proclaimed:
>[Thomas Hansen <youJerk...@iHateYou.com>]
>|
>| UML er benyttet av samtlige av de største (både i Norge og ellers i
>| verden) software husene, det brukes for å modellere alt i fra 3D
>| Action First Person Shooter spill til CRM og ERP systemer!
>
>det er ingen som bestrider det. det noen prøver å formidle er at det
>er en _notasjon_ og at det å forstå _notasjonen_ ikke automatisk
>impliserer at man er i stand til å designe.
Joda, og det er jeg helt enig i, men det var ikke det som ble forsøkt
kommunisert i den første posten!
>
>det er også blitt droppet endel hint om at for Espen sin del er ikke
>alltid denne notasjonen like hensiktsmessig fordi han ikke benytter en
>omgivelse der notasjonen uten videre gjenspeiler det han måtte trenge
>å modellere. jeg tror du ville forstå det han sier bedre om du tar
>utgangspunkt i det.
Jeg har også nevnt et par konkrete eksempler lengere opp hvor UML
totalt flopper.
Men en kan ikke si at UML er en standard for "lissom kodere" som ikke
kan ordentlig programmering bare fordi at det ikke funker på ens egen
modell...
>
>| Du burde kanskje lære deg å lytte til folk med andre erfaring enn deg
>| selv istedenfor å føle (rettmessig) at din posisjon er truet av andre
>| folk som IKKE har hoppet av evolusjonstoget...
>
>lytt til ditt eget råd.
Godt mulig at jeg er en dårlig lytter, men jeg går ikke rundt å kaller
dine (eller andres) måter å designe software på for "leketøy for
lissom kodere" med mindre jeg har prøvd den ut og funnet ut at det
stemmer...
Torkel Holm
> Torkel Holm <tor...@ii.uib.no> writes:
>
>> Terje Kvernes <ter...@math.uio.no> writes:
>>
>> > (kravspesifikasjonen krevde en del ting i forhold til
>> > unix-integrasjon som gjorde at de tilgjengelige Lisp-miljøene falt
>> > utenfor, dessverre.)
>> Ble litt nysgjerrig nå. Har du mulighet til å utdype litt?
>
> vel, systemet jeg skrev dytter ut websider fra apache (hardt krav,
> ingen egen httpd for tjenesten) og spørres mot fra kommandolinjen.
Heller ikke lov å "lure" oppdragsgiver med å bruke proxy ;) ?
--
Torkel Holm
Bjorn Borud
|
| Godt mulig at jeg er en dårlig lytter, men jeg går ikke rundt å kaller
| dine (eller andres) måter å designe software på for "leketøy for
| lissom kodere" med mindre jeg har prøvd den ut og funnet ut at det
| stemmer...
det er ikke mulig å fastslå noen absolutt sannhet. utvikling av
programvare er et såpass vidt felt at selv prosjekter som er nesten
identiske kan kreve ulike tilnærminger for å nå målene sine. ikke
minst fordi folk er kreative på ulike måter og kanskje til og med
kreative på ulike måter avhengig av hva slags type problem de prøver å
løse.
på samme måte som UML for deg er et nyttig verktøy kan det for andre
være en indikator på at vedkommende ikke har noe der å gjøre.
Espen Vestre
> * For 20 år siden fantes ikke OOP i noen praktiskt anvendbare
> programmerings språk.
dette er en meget sterk overdrivelse. Simula for TOPS-10 var i
høyeste grad anvendbart for mer enn 20 år siden, selv om det
var eksotisk (Jeg skrev til og med printerstyringsprogrammer
i Simula :-)).
> * For 10 år siden fantes det ingen adekvate implementasjoner av GC.
Det er ihvertfall bare tull og tøys. GC i TOPS-10-Simula funket da
så vidt jeg husker helt greit for 20 år siden. GC i Macintosh
Allegro Common Lisp fungerte helt glimrende for 16 år siden. GC
i SICStus Prolog fungerte noe helt utrolig bra for 12 år siden.
Lista er nesten uendelig lang.
> * For 5 år siden var AOP (Aspect Oriented Programming) et
> forskningsdokument hos Xerox.
AOP imponerer meg ikke noe særlig, jeg har faktisk sjelden blitt så
skuffet som da jeg hørte Kiczales snakke om det. En av tingene som
han påstod at java-folk syntes var kult, var rett og slett et
hårreisende hack slik jeg ser det.
> * For 3 år siden var praktisk anvendelse av XSLT en utopi.
Forventer du at jeg skal glede meg over at det tydeligvis ikke er en
utopi lenger?
> Verden går fremover og hvis en ikke holder seg oppdatert med nye ting
> som kommer går en glipp av mye moro og nye paradigmer som kan hjelpe
> deg som systemutvikler uavhengig av hvilke språk en benytter...
>
> Så får en heller bare risikere å innimellom treffe på "idioti"
> konsepter som kun fører en inn i ei blindgate, men hvis man ikke
> undersøker konseptet vil man jo ikke kunne vite om det er genialt
> eller banalt...
Joda, men man må holde hodet kaldt, for støynivået er så utrolig høyt
at man fort kan bruke all sin tid på å undersøke nye ting som likevel
går av moten neste år.
--
(espen)
Terje Kvernes
[ ... ]
> * For 20 år siden fantes ikke OOP i noen praktiskt anvendbare
> programmerings språk.
hva legger du i "praktisk anvendbare programmerings språk"?
> * For 10 år siden fantes det ingen adekvate implementasjoner av GC.
eh?
> * For 5 år siden var AOP (Aspect Oriented Programming) et
> forskningsdokument hos Xerox.
hm, jeg har ingen erfaring med AOP i det hele tatt. jeg får titte
meg litt rundt.
> * For 3 år siden var praktisk anvendelse av XSLT en utopi.
jeg jobbet mye med XSLT for tre-fire år siden, i produkter vi
solgte. det kostet mye slit, men det var ikke XSLT som var
problemet. problemet var det samme som i dag, XML. noe såpass
trivielt som å maskinelt beskrive og bearbeide relasjoner mellom
XML-dokumenter er vondt. tenk ting som "disse dokumentene beskriver
samme dokumenttype for brukeren, de er derimot av forskjellig
struktur grunnet en revisjonsendring". vi gav dokumenter, og dette
var mens vi brukte DTDer, egenskaper som "arv" takket være en
overbygning som var direkte vond -- men det fungerte.
det er forresten noe av det samme som jeg opplever med objekter.
jeg ser ingenting magisk med objekter når det kommer til
programdesign. den største fordelen i de fleste språk er at
objekter definerer en bestemt type måte å tenke på og ikke minst et
veldefinert format for APIet rundt denne kommunikasjonen.
ulempene er det ingen som snakker om. det finnes problemer som
definitivt ikke best løses ved å tenke objektorientert. for en
stund siden skulle man generere en veldig kompleks geometrisk
struktur med mange variable og en del beskrankninger (blant annet
rundt en viss form for konsistens). den helt klart vakreste
løsningen vi kom over var en variant som brukte genetiske
algoritmer.
denne strukturen skulle tidvis behandles som ett objekt, tidvis som
et hierarki av objekter, og tidvis som en rekursiv liste man
appliserte funksjoner på. det ble egentlig veldig sjarmerende. :-)
> Verden går fremover og hvis en ikke holder seg oppdatert med nye
> ting som kommer går en glipp av mye moro og nye paradigmer som kan
> hjelpe deg som systemutvikler uavhengig av hvilke språk en
> benytter...
jeg er veldig usikker på om ting går fremover, eller om det er så
viktig å føle at det går framover at man løper rundt i blinde. det
er viktigere å virke aktiv og fremadstormende enn å sette seg ned
for å finne _gode_ løsninger.
videre bør man se litt bakover før man ser framover. det er veldig
mye smart som allerede er gjort, men som i stor grad er blitt
ignorert av "de store massene".
> Så får en heller bare risikere å innimellom treffe på "idioti"
> konsepter som kun fører en inn i ei blindgate, men hvis man ikke
> undersøker konseptet vil man jo ikke kunne vite om det er genialt
> eller banalt...
av og til bør man sette seg ned og se på gårsdagen før man ser på
morgendagen. "those who do not understand history are doomed to
relive it" og alt det der.
--
Terje
Terje Kvernes
> Terje Kvernes <ter...@math.uio.no> writes:
>
> > vel, systemet jeg skrev dytter ut websider fra apache (hardt krav,
> > ingen egen httpd for tjenesten) og spørres mot fra kommandolinjen.
>
> Heller ikke lov å "lure" oppdragsgiver med å bruke proxy ;) ?
min kollega og jeg var selv arbeidsgiveren. tjenesten skulle kjøre
på en maskin som allerede hadde apache kjørende, og jeg ville
virkelig ikke dytte ting til en annen port og leke med proxy eller
noe sånt fra apache med mindre jeg måtte.
dog, ja, i dag angrer jeg litt -- selv om løsningen er velfungerende
og alt sånt.
--
Terje
Espen Vestre
>> * For 5 år siden var AOP (Aspect Oriented Programming) et
>> forskningsdokument hos Xerox.
>
> hm, jeg har ingen erfaring med AOP i det hele tatt. jeg får titte
> meg litt rundt.
Hvis du kan noe om MOP, f.eks. allerede har lest AMOP, så kommer du
neppe til å rope halleluja, men jeg skjønner jo at folk som er
dårligere vant blir begeistret. Jeg har ofte lurt på hvorfor Gregor
Kiczales driver med dette her, men det kan bare være en av to: Penger
eller gleden ved å begeistre litt større masser.
--
(espen)
Vetle Roeim
[...]
> * For 3 år siden var praktisk anvendelse av XSLT en utopi.
Pussig at du skulle velge nøyaktig 3 år. Jeg begynte tilfeldigvis å
jobbe med XSLT for nesten nøyaktig tre år siden, og det var praktisk
allerede da. I Java, til og med.
Kan du forklare nærmere hvorfor det ikke var mulig med praktiske
anvendelser av XSLT for tre år siden?
[...]
--
#!/usr/bin/vr
Erik Naggum
| I dag er det svjv. en utbredt oppfatning at både blinde og døvstumme
| tenker.
Nå har du sagt dette etpar ganger, så jeg lurer på hvorfor du tror det
sier noe annet enn at du har mistet forstanden. Tror du at du kan
gjøre et forsøk på å utdype hvordan du klarte å innbille deg noe så
utrolig skrullete som at noen har ment at blinde og døvstumme /ikke/
tenker? Eller er det bare en sånn ting som er morsomt å si fordi du
tror du får det til å se ut som om det er /motparten/ som har funnet
på dette våset du motargumenterer? Isåfall, er du overhodet ikke
kjent med stråmannargumentasjon som en av de mindre æverdige taktikker
som benyttes av de som primært er ute etter å ødelegge diskusjoner?
Sålangt er du den eneste som har sagt noe så innihelvete uintelligent
som at blinde og døvstumme ikke tenker, så med mindre du kan vise til
at noen faktisk har ment dette, faller hele ansvaret for å ha bragt
dette skrudde påfunnet på dine skuldre.
Jeg antar her at du ikke er blind og døvstum. Ha meg unnskyld om du
leser blindeskrift med nesetippen og taster med en blyant i munnen og
er lam fra halsen og ned. (Bare) isåfall kan jeg forstå at du er litt
nærtagende på blinde og døvstummes vegne og tror at du er fornærmet.
--
Erik Naggum, Oslo, Norway | HTML mail is discarded unread | 2004-112
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Alf P. Steinbach
>
> Det er alment akseptert at man tenker mer i bilder dess mindre
> intelligent man er, og mer i abstrakt sprog dess mer intelligent man
> er.
* Alf:
>
> Nah, ikke så vidt jeg kjenner til. Kunne vært kjekt med noen referanser
> til hvor du har hentet dette fra. Det _har_ vært en utbredt misoppfatning
> blant for eksempel enkelte grupper psykologer, men svjv. ikke i vitenskapen.
> Det med at man nødvendigvis tenker i bilder er svjv. også en en oppfatning
> som kun har holdt stand hos enkelte grupper ikke-vitenskapsfolk. I dag er
> det svjv. en utbredt oppfatning at både blinde og døvstumme tenker.
* Erik Naggum:
>
> du har mistet forstanden.
> utrolig skrullete
> våset
> stråmannargumentasjon
> ødelegge diskusjoner
> innihelvete uintelligent
> dette skrudde påfunnet på
>
> Jeg antar her at du ikke er blind og døvstum. Ha meg unnskyld om du
> leser blindeskrift med nesetippen og taster med en blyant i munnen og
> er lam fra halsen og ned.
ROTFL! :-)
Så, du har ingen referanser til påstandene dine?
Thore Karlsen
<youJerk...@iHateYou.com> wrote:
[...]
>* For 3 år siden var praktisk anvendelse av XSLT en utopi.
Jeg brukte da XSLT på store prosjekter for 3 år siden. At det var
verdens kjedeligste drittjobb er så, men jeg tror ikke det har blitt mer
spennende på 3 år.
--
Be seeing you.
Geir Harris Hedemark
> * For 20 år siden fantes ikke OOP i noen praktiskt anvendbare
> programmerings språk.
For noe sludder.
Geir
Erik Naggum
| Så, du har ingen referanser til påstandene dine?
Vel, det er du som vil ha referanser, så jeg lurer på hvorfor du ikke
uoppfordret serverer «referansene» til denne skrullete forestillingen
din om at noen virkelig tror at blinde og døvstumme ikke tenker. Er
det noen her som har ment dette? Nei? Hvorfor bringer du dette ikke-
argumentet opp hvis du ikke motargumenterer noen? Min gjetning er at
det er fordi det er morsomt å si stupide ting for å late som om det er
motparten som skal sitte igjen med «Svarte-Per».
Hva slags «referanser» vil du bli /fornøyd/ med for det du ikke tror
på og som du kan undersøke selv hvis du virkelig har lyst til å vite,
men ikke har giddet å undersøke før du ber om «referanser»?
Min erfaring med folk som ber om referanser er at de er ærlige og
seriøse hvis de er veilederen eller professoren til den som avkreves
dem, og uærlige og useriøse i alle andre tilfeller. Dersom et krav om
referanser fremsettes offentlig, har hensikten til dags dato vært å
late som om det å spørre om referanser er en høfligere form av «Peer,
du lyver!» og det er meningen at idioten som tar kravet alvorlig skal
svare «Nei, jeg gjør ei!».
Derfor, det at du ber om «referanser» tyder på uvilje mot det som er
blitt fremsagt, men du evner ikke å produsere motargumenter selv, så
da tror du at du slipper å motargumentere dersom motparten ikke har
dokumentert påstanden til din tilfredsstillelse. Hvor har du fått en
så sinnsvak vrangforestilling om hvordan intelligent diskusjon skal
føres? Hvis du ikke har noe bedre å komme med, så er det rimelig at
du godtar det du hører som sant, ikke at du kverulerer over din egen
utilstrekkelighet og forsøker å skylde på andre for den. Derfor er
det på Usenet og i andre offentlige fora, /utelukkende/ fornuftig å
tolke et krav om referanser som en fallitt-erklæring fra den som spør,
for vedkommende er ute av stand til å motargumentere påstanden. Det
blir ikke bedre av at det du /faktisk/ motargumenterer det ikke er
mulig å tro at noen har ment, og langt mindre har sagt.
Ikke /all/ offentlig diskusjon er spill for galleriet og bare egnet
til å underholde massene, selv om TV gjør sitt beste for å ruinere alt
som har bygget dette samfunnet og har produsert vitenskapen når den
har blitt gjennomført i tilstrekkelig alvorlige former.
En annen ting er at jeg ikke ville poste meningene til Usenet hvis jeg
trodde at jeg skulle kunne klare å klore til meg en akademisk grad om
jeg publiserte dem, komplett med alle referanser. Å be noen om å gi
deg artikler av akademisk kvalitet vederlagsfritt på nettet bare fordi
du selv er for lat til å google og snakke med nærmeste bibliotekar, er
derfor ikke rent skammelig.
Dermed blir det nødvendig å spørre deg, konkret, om hva du hadde imot
det jeg sa som fikk den idiotiske «be om referanse fordi jeg ikke tror
på det»-refleksen din til å trigge? Hvis du ikke har konkret kritikk
og heller ikke klarer å motargumentere noe jeg faktisk har sagt, vil
jeg istedet vente at du tror på det jeg sier til deg.
Alf P. Steinbach
> | Så, du har ingen referanser til påstandene dine?
>
> Sinnsvak vrangforestilling om hvordan intelligent diskusjon skal føres
> ...
Det var med andre ord en helt tom påstand du kom med.
Heh. :-)
PS: Godt å se at du er i form igjen og skriver lengre usakligheter på
njus, ikke bare disse tørre korte faktakommentarene.
Terje Kvernes
[ ... ]
> Hvis du kan noe om MOP, f.eks. allerede har lest AMOP,
ack.
> så kommer du neppe til å rope halleluja, men jeg skjønner jo at folk
> som er dårligere vant blir begeistret. Jeg har ofte lurt på hvorfor
> Gregor Kiczales driver med dette her, men det kan bare være en av
> to: Penger eller gleden ved å begeistre litt større masser.
nuvel. jeg får ta en titt. =)
--
Terje
Torkel Holm
Grunnlaget for MOP og dermed AOP kan vel trekkes minst 17 år
tilbake til forskningen rundt computational reflection.
Fellesnevneren er håndteringen av funksjonalitet som er spredt
utover hele objektsystemet (crosscutting concerns). AOP har
kommet med en del nye buzz-ord som delvis er common practice
for lispere. Dette i form av konsepter som metaklasser,
metodekombinasjoner, mixins og dynamic scope for å nevne noe.
Det vil iallefall gjøre hverdagen lettere for en stakkars
lisper som må programmere i andre språk.
Som regel må en innføre ny syntaks og ty til XML for å
spesifisere aspektene (men kjenner til forsøk med dynamiske
proxier i java med de begrensninger dette gir).
Alt dette vil selvfølgelig være avhengig av språk.
Noe spesielt ved AOP vs MOP er at i MOP må man eksplisitt
spesifisere en metaklasse for en klasse, mens i AOP kan dette
spesifiseres uten å forandre koden. Vanligvis ved bruk av
regulære uttrykk eller ved bruk av metainformasjon som ligger
i filer eller settes under kjøretid. Hvor nyttig dette er kan
diskuteres.
På den andre siden er MOP og CLOS et såpass fleksibelt rammeverk
at AOP på ingen måter er i samme klasse. Bør vel kanskje nevne
for menigmann at både MOP og CLOS kan implementeres i standard CL.
Siden det har vært så mye snakk om UML her prøver jeg meg på en
aldri så liten figur slik at alle forstår :)
Muligens ikke de døvblinde ;)
---------------
| |
| -----|--
| | | |
| MOP |AOP | |
| | | |
| -----|--
| |
---------------
Ble en litt sen posting dette her, men måtte utnytte finværet her
i Bergen :)
PS. En morsom sak er at Common Lisp tilbyr selve essensen av AOP
direkte i språket ved hjelp funksjoner med dynamisk scope.
--
Torkel Holm
Erik Naggum
| Det var med andre ord en helt tom påstand du kom med.
Ja, det er den tolkningen jeg forklarte deg at du ville komme med, for
du er overhodet ikke interessert i å forstå noe som helst, bare å lage
kvalm ved å be om «referanser» på almenkunnskap, men det er den måten
du gnåler som en besatt siden du åpenbart ikke besitter almenkunnskap.
Du ikke har noen konkret kritikk som gjør det mulig for meg å vite hva
du egentlig vil ha «referanser» på. Du klarer ikke å hoste opp noen
motargumenter til det folk faktisk sier, men messer bare videre på det
stakkarslige lille poenget du tror du har. Jeg synes faktisk synd på
deg. Du må ha det svært deprimerende tomt i livet ditt som synes det
du driver med er givende.
Jeg spurte deg hva som ville gjøre deg /fornøyd/, men dét har du ikke
svart på. Siden du ikke har svart på det, er det, hvis vi tør bruke
din noe snodige logikk, altså ingenting som vil gjøre deg fornøyd, og
det er bevist at det eneste du er ute etter, er å lage kvalm. Du har
med andre ord ikke fått hjelp med personlighetsforstyrrelsene dine
siden sist, som jo er forferdelig trist.
| PS: Godt å se at du er i form igjen og skriver lengre usakligheter på
| njus, ikke bare disse tørre korte faktakommentarene.
Vi vet nå at alt som ikke har «referanser» er usakligheter, men du gir
jo aldri referanser til noe du selv sier, så vi får stole på at du vet
hva du snakker om -- du kommer bare med tomme påstander, for de har
ingen som helst sammenheng med noe som helst.
Takk for bidraget, Alf! Nå ble alt meget klarere. Jeg trodde du var
ihvertfall /litt/ intelligent, men tok feil. Enda så rask jeg pleier
å være til å oppdage undermennesker, har jeg fremdeles en kullsviertro
på at hvem som helst kan finne på å bruke hodet sitt helt av seg selv,
uten å sende ut nabovarsel. Jeg er redd du blir nødt til å sende ut
en nabovarsel om du engang i fremtiden måtte klare å bruke hodet ditt.
Det positive ved det hele er at du vil merke om du skulle bruke hodet
ditt til noe, for akkurat som utrenede muskler ofte gjør veldig vondt
når de plutselig brukes, vil du merke det på hodepinen. Ikke ta noen
medisiner mot den, men send meg en mail med Subject: My brain hurts!
Lykke til frem til det lysner for deg.
--
Erik Naggum, Oslo, Norway | HTML mail is discarded unread | 2004-113
Alf P. Steinbach
>
> | Det var med andre ord en helt tom påstand du kom med.
>
> Ja, det er den tolkningen jeg forklarte deg at du ville komme med
Hirr! Jeg ler så det gjør nesten vondt! :-)))
Har du forresten -- jeg vegrer meg nesten for å spørre -- noen
referanser på det der?
Alf P. Steinbach
> * Erik Naggum <er...@naggum.no> schriebt:
> >
> > * Alf P. Steinbach
> >
> > | Det var med andre ord en helt tom påstand du kom med.
> >
> > Ja, det er den tolkningen jeg forklarte deg at du ville komme med
> > [... snippet]
>
> Hirr! Jeg ler så det gjør nesten vondt! :-)))
>
> Har du forresten -- jeg vegrer meg nesten for å spørre -- noen
> referanser på det der?
Ah, fikk roet meg ned litt.
Du verden!
Får vel gi litt i retur, så, hvis du har sansen for litt Telenor/Schanke:
<url: http://www6.nrk.no/magasin/upunkt/petre/petremorgen/skanke/skanke_telenor.mp3>
Erik Naggum
| Kjøtthue!
Uffda. Også akkurat nå som det var /rett før/ jeg skulle til å tenke
på å begynne å respektere din seriøsitet, autoritet og faglige tyngde.
Jeg er ikke lite skuffet, Thomas. La meg forsøke å formidle hvor
skuffet jeg er, slik at du får en fair chance til å forstå at det ikke
bare er jeg som er voldsomt skuffet, det er også bare din skyld, og da
er det bare du som kan gjøre noe med det hvis du leser Aftenposten og
særlig dette kosepjattet om skamfølelse og hvordan det kan hjelpe deg
til å korrigere den sørgelig, sørgelig skuffende oppførselen din.
Samtlige litterære og kulturelle referanser i innlegget mitt gikk deg
rett over hodet. Hva skal vi gjøre med slikt, Thomas? Du forstod
ikke ett eneste av de bildene jeg med øvet pensel malte for deg, og
jeg får ros for sproget mitt av fagfolk. Du har ikke det minste lille
begrep om hva ironi er eller hvordan det brukes. I litteraturanalysen
finner vi istedet stilen din beskrevet med faguttrykket «surmuling».
Og du oppviser en selvhevdende, introspeksjonsfri og refleksjonsløs
arroganse som jeg virkelig tror at bare er mulig hos mennesker som
mangler all tenkelig innsikt i sine egne begrensninger. (Nå holder
jeg opp et bilde av George W. Bush her så du kan se på dét.) Dessuten
oser du av intelligensforakt og total mangel på forståelse for hvilken
rolle den smarteste promillen av befolkningen har i avanserte samfunn
og alt som alle samfunnets borgere kan takke for at sånne som deg ikke
trenger å finne opp påny og markedsføre på TV og med spam.
Det er blitt uunngåelig å lure på hvilket problem det /egentlig/ er
UML løser (for deg), men du tar vel ikke kulturreferansen i «Hvis UML
er svaret, hva var spørsmålet?», heller.
Nå har jeg lest noen flere av de fantastiske innleggene dine, og det
er tydelig at du ikke skammer deg over å være så historieløs at det
burde være mange år til du blir født, har en så innsnevret forståelse
av det du tror du forstår at alle med reell faglig innsikt ser ut som
om de tar feil fra din synsvinkel, og er en av disse menneskene som er
«hint proof» og som alltid er kongen på haugen i egne øyne, noe som
stemmer bare fordi alle de andre barna har gått hjem, vokst opp, etc.
Det er derfor nærliggende å mistenke at UML har en psykologisk rolle
for deg, og at eventuelt programmeringsaspekt er knekkende likegyldig.
Det finnes mennesker som er så ensomme at de finner opp alle vennene
sine og som lever i en verden der alle de imaginære vennene hylder dem
for deres mange personlige kvaliteter. Dersom man er tilstrekkelig
forvirret til å begynne med, er det lett å se at det å forholde seg
til en datamaskin som man med megen møye har klart å få til å si og
gjøre /akkurat/ som man vil (programmering), kan det overføres til de
menneskene man snakker med gjennom datamaskinen og som ser ut til å
svare på ting man skriver til maskinen. Om man har tungt for å se for
seg noe slikt, kan en istedet forestille seg mennesker som nylig har
oppdaget telefonen og som etter mange mislykkede forsøk har fått ringt
noen, men som så ikke godtar at dette enkle stykket plast motsier dem
fordi de ikke forstår at stemmen tilhører et annet menneske, ikke bare
plast-dingsen. (Noen tror sikkert dette bare er tull, men det er bare
å få et telefonnummer som har tilhørt noen andre før, og det kommer
til å ringe en alzheimer-pasient før eller senere som er så glad for
at barnebarnet endelig tar telefonen igjen etter ikke å ha svart på 3
år, og som ringer tilbake igjen gang på gang hele kvelden med håp om
at det skal bli barnebarnet som svarer neste gang. Det er dessverre
ganske mange Usenet-debattanter som oppfører seg akkurat slik.)
Evnen til å lese det andre skriver og forstå at det er noen /andres/
meningsuttrykk som man legger sin egen /tolkning/ i for å produsere
sin /egen/ forståelse av, ser ut til å mangle hos de som har imaginære
venner som alle sammen oppfører seg slik de forventer, og de innbiller
seg derfor at det de tolker andre til å ha ment, også /er/ eksakt hva
andre har ment, som om der ikke er forskjell på de to menneskene. Alf
P. Steinbach tror f eks at noen virkelig har /ment/ at blinde og
døvstumme ikke tenker (og han lar seg ikke rokke i den troen), bare
fordi han tolker noe de har sagt på en slik måte at dette for ham ser
ut til å være eneste mulighet for deres mening, men han viser dermed
at han mangler evne (jeg skrev «vilje» her før jeg så det siste røret
han postet) til å forstå sin egen rolle som tolk av meningsuttrykk,
akkurat som mennesker som ikke er så godt vant med å tolke følelser
som uttrykkes i ord, virkelig tror at det er de følelsene de selv
produserer når de leser en tekst, som har vært formidlet /direkte/ i
teksten (og så sier de ting som «det var en sint mail», omtrent som
«det var en sint hund», og dette sproglige virkemiddelet (en trope)
glir over i forvirret virkelighetsforståelse) og at de dermed kan
reagere på teksten og mot avsenderen akkurat som om de var en av de
imaginære vennene som hadde sagt de samme ordene, slik at de er helt
sikre på eksakt hva de ikke-fullt-så-andre har ment med ordene. Det
er mange som ikke helt forstår at andre mennesker ikke er akkurat som
dem selv og at det som er riktig ansikt til ansikt ikke gjelder når
man er nødt til å forestille seg det andre mennesket heller enn å se
og høre det. Særlige de mindre begavede er ute av stand til å dikte
opp mennesker som er mer intelligente enn dem selv, og dermed tror de
at alle mennesker de ikke forholder seg til ansikt til ansikt må være
mindre begavede enn dem selv og at deres egne reaksjoner kan brukes
til å forutsi andres. Dette stemmer innenfor halvparten av folket,
mens resten vil ta feil av hvordan andre har følt, tenkt og villet, og
de vil hverken oppdage det eller la seg korrigere, fordi de mangler
selve grunnlaget for å forestille seg dem som ikke er som dem selv.
Dermed får man sånne raringer som Alf P. Steinbach, som virkelig tror
at det er andre som er forutsigbare og som ikke gjenkjenner at han
ikke oppdager det han ikke forutser. Jeg tror du er mye smartere enn
Alf P. Steinbach, Thomas Hansen, så du vil sikkert forstå at jeg ikke
bare retter denne kommentaren til deg.
Å leve seg inn i en tekst, å føle med andre (til forskjell fra å føle
det samme som en tror andre føler) og å se bildene som males med ord
for sitt indre øye er noe den oppvoksende generasjon ser ut til å ha
store problemer med, for de er vant til å bli presentert for dyktige
kunstneres evne til å realisere visualiseringen i den gjennomført
virtuelle virkeligheten vi lever i fra vi skrur på TV'en/dataskjermen
til vi skrur den av. Det å oppfatte billedlig tale riktig, forsvinner
dermed fullstendig fra det intellektuelle repertoaret, for det krever
virkelig spesielle kunstnere og kunstkjennere for å klare å uttrykke
mange tanker med ett bilde, mens det kreves langt mindre avanserte
kunstnere for å skrive ting som har flere meninger -- det er tilogmed
så lett at det er umulig å unngå det, og tvetydighet blir et spørsmål
om sender og mottagers evne til innlevelse og vilje til forståelse av
budskapet. (Ta igjen denne merkelige Alf P. Steinbach, som ikke kan
forstå det han leser, men bare er opptatt av om folk har fulgt hans
«ordre» om å gi ham «referanser», selv om det er sørgelig åpenbart at
han ikke kunne bruke dem til noe.) Med det samme svekkes evnen til å
forstå og uttrykke ironi (som vi ser at du ikke klarer), fordi det
krever evne til å forestille seg bredden i den sannsynlige variasjonen
i meningsinnholdet og motivasjonen bak den (til forskjell fra bare å
tro at det første man kommer på også må være eneste mulighet, slik
dumme/uintelligente mennesker gjør) slik at man klarer å forstå en
morsomhet og ikke svarer med «kjøtthue!» fordi en ikke forstod vitsen.
Det sies at barn i tidlig alder må gå gjennom en erkjennelse av at
andre mennesker er uavhengige og selvstendige skapninger som har sin
egen erfaringshistorie slik at de ikke automatisk kan antaes å vite
det samme som en selv. (Dermed har man derfor viktige begreper som
«almenkunnskap» som normale mennesker har fått med seg, men som de som
ikke virker som de skal og som om noen år vil få erstatning for dårlig
skolegang må ha «referanser» for å klare å forholde seg til. :)
Det alvorlig avstumpede forholdet til det skrevne ord som den visuelle
generasjon oppviser uten den minste blygsel, finner vi derfor igjen i
behovet for å ha enkle bilder istedet for abstrakte ord, og dermed er
det ikke det minste rart at de som ikke har ordet i sin makt, trekker
mot rene visuelle fremstillinger i mangel av evne til å både uttrykke
og inntrykke seg skriftlig, og dersom de klarer å få nok klapp og klem
og ros og bekreftelse fra de imaginære vennene sine, vil de også tro
at de er mye bedre og smartere enn dem som bruker ord de ikke kan og
som de dermed ikke forstår hva sier. Gitt en tilstrekkelig forverring
i denne utviklingen, vil man sitte i sin ensomhet og bli fryktelig lei
seg for at man er den eneste som virkelig har forstått verden mens
alle andre mennesker som har levd og tenkt i tusener av år, tok feil,
alle sammen. Deretter er det fri kost og losji, særfradrag og gratis
Internet fra sosialkontoret, og man får anledning til å skrive på sin
filosofiske avhandling om etiske prinsipper i immaterialretten og si
klart fra at patenter er galt. Nei, vent, det var en annen newser.
Uff, så lett det er å blande dere sammen.
I gamle dager het at det bildene var best på radio, men nå har vi fått
så vanvittig gode special effects og hemningsløst fantastisk grafikk
at dersom man ikke klarer å forestille seg hvordan man skal tegne med
datamaskinen til hjelp, er man bortimot handicappet, så derfor behøver
ikke forbrukerne å forestille seg noe som helst, lenger -- de vil nyte
godt av stadig flere dyktige kunstneres forestillingsevne. Imidlertid
må skaperne, kunstnerne, designer være tilsvarende hemningsløst dyktig
til å mane frem selve manifestasjonen av visualiseringen av ethvert
ellers indre bilde. Dette stiller enorme krav til kustnernes innsikt
i den verden vi lever i og som mennesker er optimert for å forstå, som
de biologiske organismer vi nå engang er. Å bruke ord slik at de som
har vilje til å forstå hva som er ment, vil forstå hva som er ment,
krever også rimelig kontroll på både virkelighetsforståelsen og et
rikt og presist vokabular, og vi vet at det krever konstant lesning i
minst 15 år før man oppnår virkelig god leseforståelse og evne til å
bruke sproget. (Mot de som ikke vil forstå, kjemper alle forgjeves,
men de er heldigvis behjelpelige med å drite seg ut.) For en som ikke
har hatt for vane å forholde seg til skriftlig formidlet informasjon,
vil det skrevne ord selvsagt fortone seg som fattigere enn bilder. En
utvilsomt heldig kombinasjon finner vi i de som kan tenke i ord og så
produsere grafiske fremstillinger som kommuniserer mer enn 1000 ord,
men for de fleste som forsøker seg på grafiske fremstillinger, ville
ett velvalgt ord komme meget lengre enn bildene de lager. At et bilde
sier mer enn 1000 ord gjelder bare de bildene som de menneskene som
fikk slippe til i det offentlige rom tidligere skapte, ikke ethvert
bilde som enhver unge produserer.
Akkurat som lege og forfatter Henry Gray fikk uvurderlig hjelp av lege
og gravør H.V. Carter for å lage et fantastisk bokverk om menneskets
anatomi som er kjent som /Gray's Anatomy/ for over 100 år siden, og
som har stått som en av de mest forseggjorte og korrekte anatomiske
verk noensinne, må de som ønsker å illustrere noe av betydning idag ha
dyptgående innsikt i det de skal illustrere. /Gray's Anatomy/ er ikke
en samling fyrstikk-figurer, men presis, korrekt tekst rikt illustrert
med et vell av svært nøyaktige, detaljrike illustrasjoner som klarer å
fremheve det viktige og ignorere det uvesentlige på en fortreffelig
måte. Å tenke på at dette ble produsert for over 100 år siden, setter
hos de fleste oppegående fagfolk uansett disiplin igang en følelse av
respekt og de blir også dypt imponert over dyktigheten og viljen til å
fullføre en oppgave som må ha vært enorm. Å lese om utviklingen av
datamaskiner og om fremveksten av idégrunnlaget for det ene geniale
programmeringssprog etter det andre, og ikke minst å se på historien
til kompilatorteknikk, som tidligere gikk under «kunstig intelligens»,
gir også de fleste oppegående fagfolk uansett disiplin en følelse av
respekt og de aller fleste oppegående mennesker blir dertil imponert
over hvordan denne teknologien har blitt utviklet av genier fra mange
disipliner som har skapt underverker sammen. Noen av oss husker da
Digital brøt 100MHz-barrieren med sin Alpha-prosessor, og jublet over
nyheten akkurat som når vi jubler med NASA når de får nydelige bilder
og vitenskaplig måledata tilbake fra Mars. Hos gode fagfolk gir andre
fagfolks dyktighet en følelse av gjensidig respekt for både faget og
for menneskets rolle i universet. En av de sterkeste drivkreftene for
å gjøre en god jobb, vil være ønsket om å ta del i en tradisjon som
har skapt fantastiske underverker når mennesker setter seg fore å løse
harde problemer så riktig som mulig. Uansett hvilket fagfelt folk har
studert, vil man blant de som tar faget sitt seriøst finne fellestrekk
og en felles verdinorm som er uavhengig av feltet, men som gir alle
som er dyktige til det de kan, en følelse av fellesskap.
Men du, Thomas Hansen, blir skrekkelig imponert over og vil ha oss til
å bli like skrekkelig imponert over dine animerte fyrstikk-figurer og
dine grusomt inkompetente uttalelser servert med en selvsikkerhet som
bare de uutgrunnelig uintelligente kan oppdrive. For oss som ser på
faglig dyktighet og kompetanse i å formidle faglig informasjon som et
gode, ikke bare når vi selv klarer det og fordi vi holder kjeft når vi
ikke vet hva vi snakker om (men heller lytter interessert når de som
kan mer enn oss snakker), men som vi rett og slett /forventer/ fra dem
som ber om å få bruke av livet vårt til å lytte til dem, fortoner det
seg som regelrett svindel når en så himmelropende inkompetent unge som
deg kommer valsende inn og forteller engasjert om barnetegningene dine
som om de var kunst og vi var foreldrene dine. De som var barn av
foreldre som tok oppgaven alvorlig, vet at de skal være uuttømmelige i
sin ros av avkommets evne til å kladde sammen ting, og skal tolke all
deres iver og nysgjerrighet i beste mening og stille opp når de vil
vise frem noen av sine skaperverk, men denne newsgruppen heter ikke
no.it.programmering.foreldre+barn.
Du bør snart fatte at ingen andre enn dine egne foreldre er forpliktet
til å mene at det du gjør er godt gjort og til å hjelpe deg å få det
til enda litt bedre uten at du mister motet eller føler at du ikke har
gjort en god nok jobb. Når andres barn kommer rekende og skal vise
frem ting, hender det rett som det er at de /forstyrrer/ og at den som
får se barnetegningene vil ha store problemer med å unnlate å si noe
som kan få det hjelpeløse vesenet som er tre år eldre enn tegningene
gir inntrykk av, til å føle seg avvist. Gode foreldre lærer sine barn
at de alltid vil være trygge hos dem, men også at andre mennesker ikke
har noen som helst forpliktelse til å rose dem, men heller vil rose og
oppmuntre på egne premisser, uavhengig av hvem de er og normalt bare
ut fra hva de har gjort og velger å vise frem til andre, slik at ens
person ikke blir vurdert av fremmede, bare ens handlinger i forhold
til dem. Umodne mennesker tror at andre mennesker møter dem som hele
/personer/ og klarer ikke å skille person og handling, klarer ikke å
forstå at det kun er deres handlinger andre bryr seg om og kan si noe
om, og velger å lese personangrep ut av handlingskritikk, men det ser
ut til at modne mennesker er mangelvare i en verden der store deler av
folket følger «reality»-TV og bryr seg om kjendisers liv.
Det ser ut til at de som er så ensomme at de dikter opp sine egne
venner også gir dem foreldrenes rolle som trygge kilder til ros, har
enorme problemer med å ta til seg kritikk av det de tror er lojale,
imaginære venner og datamaskiner de har kontroll over, men så kommer
det altså tekst på dataskjermen deres som ikke bare viser det totale
fravær av ros, men latterliggjør og gjør hva det kan for å rakke ned
på det en tror er godt og riktig og smart. Det modne barnet av gode
foreldre og som har ekte venner, forstår at andre mennesker vurderer
det de gjør ut fra sine egne premisser og ikke angriper deres person i
en foreldre-barn-relasjonen, og de vil også forstå at det er usmakelig
å opptre som barn og kreve at vilt fremmede skal være rosende foreldre
overfor alle de barnslige og tafatte forsøkene de foretar seg.
Så, dersom du ikke allerede har forstått poenget: Kan du ta disse UML-
barnetegningene dine og vise dem til foreldrene dine slik at du kan få
den rosen du trenger og ikke behøver å slåss for å få ros og klapp på
skulderen av folk som ikke er forpliktet til å like det du gjør?
-------
Referanser (spesielt myntet for almenkunnskapsløse):
¹ Store Norske Leksikon
² Encyclopædia Britannica
³ Deichmanske bibliotek
Erik Naggum
| Hirr! Jeg ler så det gjør nesten vondt! :-)))
|
| Har du forresten -- jeg vegrer meg nesten for å spørre -- noen
| referanser på det der?
Du ser altså bare deg selv i dataskjermen din. Så mye du går glipp av
som tror alle andre er enda mindre begavede enn deg selv. Jeg synes
virkelig synd på deg. Une vie gâchée.
Erik Naggum
| Herlig.
Godt noen tok den. :)
| Ante ikke at den hadde gått inn i den generelle jargongen.
Nå tror jeg du undervurderer opptil flere.
| Var jo i sin tid en fin artikkel å trekke frem når man hadde med
| DEC-folk å gjøre, både i VMS- og Unix-versjon etter behov. Men
| originalen er kanskje enda eldre?
Det var VMS 3.0 da jeg så den første gang. Det fikk omtrent samme
status som «Fixed in 4.0». Tar du den referansen, også?
Erik Naggum
| det er forresten noe av det samme som jeg opplever med objekter. jeg
| ser ingenting magisk med objekter når det kommer til programdesign.
| den største fordelen i de fleste språk er at objekter definerer en
| bestemt type måte å tenke på og ikke minst et veldefinert format for
| APIet rundt denne kommunikasjonen.
Det all objekt-orientering mangler er dessverre protokoller som det er
mulig å undersøke om overholdes. Forskjellige forsøk på programming
by contract og gjennom spesifiserte pre- og post-conditions og uttrykk
for invarianter er helt ortogonale til objekt-orientering, og dermed
har noe av begrepsapparatet rundt objekter blitt ødelagt. Det kan
ikke bygges opp igjen uten støtte i implementasjonsmekanismene, men
når ingen har gjort noen seriøse forsøk på å spesifisere tilstander og
tilstandsoverganger, er det omtrent like dødfødt som objekter i C.
| videre bør man se litt bakover før man ser framover. det er veldig
| mye smart som allerede er gjort, men som i stor grad er blitt
| ignorert av "de store massene".
Cue «almendannelse» og «almenkunnskap».
Erik Naggum
| Hvis du kan noe om MOP, f.eks. allerede har lest AMOP, så kommer du
| neppe til å rope halleluja, men jeg skjønner jo at folk som er
| dårligere vant blir begeistret. Jeg har ofte lurt på hvorfor Gregor
| Kiczales driver med dette her, men det kan bare være en av to: Penger
| eller gleden ved å begeistre litt større masser.
Jeg har ved endel anledninger sagt at livet er for langt til å bli
flink i C++ og lignende, men det ser ikke ut til å registrere hos de
som ikke har investert år av sitt liv i noe de har måttet gå fra.
Ta f eks Bjarne Stroustrup og C++ og Alexander Stepanov og STL i C++.
Verden hadde vært et meget bedre sted om disse to hadde kunnet få noe
annet å gjøre som ikke krevde at de fortsatte i den retning de hadde
gått altfor langt uten at noen stoppet dem.
Vi lever i en tid da ikke en levende sjel i noe land det er noe vits å
bo i, vil unngå å få /anledning/ til å oppleve at det de har viet sitt
liv til, viser seg fullstendig bortkastet, så det gjelder å finne sin
egen-motivasjon i dyktighet i nuet, ikke opparbeidelse av status pga
erfaring i noe som har forsvunnet. Mange mennesker har imidlertid
aldri blitt forberedt på at de vil måtte omskoleres og ikke skoleres
for mer av fremtiden enn de kan forestille seg. Over hele Vesten
sliter samfunnene med mennesker som tenker på hvor mye tid og krefter
det gikk med på å få den statusen de hadde og som derfor ikke orker å
tenke på skaffe seg en ny, og forherligelsen av uerfarenhet er gått så
langt at den viktigste forskjellen mellom barneporno og reklame er om
man finner et firmalogo på bildet eller ikke, så det virker som om alt
man har behov for å vite må ha vært erhvervet siste tiår og går ut på
dato før dagens hotteste band har gitt ut «Greatest Hits»-album. Det
er i slike tider den virkelige erfaringen består i å lære av feil så
man begår dem bare én gang, eller som et sitat jeg så nylig sa det:
Good judgment comes from experience.
Experience comes from bad judgment.
-- Jim Horning
Det skal mer til for å være innovativ enn å glemme hvordan du gjorde
det forrige gang.
Ingen liker å høre fra andre at det man har funnet på allerede har
mislyktes, og alle som mener at de som mislyktes før dem, må ha
oversett den ene virkelige nyvinningen nettopp de har funnet på, vil
bruke opp mer og mer tid på å begå de samme feilene, ikke minst fordi
man patenterer de vellykkede oppfinnelsene. Dette var lurt i en tid
da man lærte av positiv erfaring og man ønsket å belønne de som fant
på noe lurt slik at verden og de kunne nyte godt av det. Jeg lurer på
om vi ikke allerede har ankommet en virkelighet der vi vil tjene mer
på å registrere alle de mislykkede forsøkene og idiotiske påfunnene
enn de gode idéene og straffe de som prøver seg på dem enda en gang
uten en veldig god grunn for brudd på anti-patenter.
Erik Naggum
| Godt mulig at jeg er en dårlig lytter, men jeg går ikke rundt å kaller
| dine (eller andres) måter å designe software på for "leketøy for
| lissom kodere" med mindre jeg har prøvd den ut og funnet ut at det
| stemmer...
Hvilken metode bruker du for å skille din inkompetanse fra leketøyet?
Alf P. Steinbach
Uhm, takker, selv om jeg naturligvis ikke tror på deg.
Velkommen tilbake, og måtte du danke ut Arve Kirkevik, Magne Aga, Terje
Henriksen og alle de andre! :-)
Erik Naggum
| Velkommen tilbake, og måtte du danke ut Arve Kirkevik, Magne Aga, Terje
| Henriksen og alle de andre! :-)
Sorry, jeg konkurrerer ikke med deg, selv om det er slik du ser verden.
Thomas Hansen
<espen@*do-not-spam-me*.vestre.net> left his sanity behind and
proclaimed:
>Thomas Hansen <youJerk...@iHateYou.com> writes:
>
>> * For 20 år siden fantes ikke OOP i noen praktiskt anvendbare
>> programmerings språk.
>
>dette er en meget sterk overdrivelse. Simula for TOPS-10 var i
>høyeste grad anvendbart for mer enn 20 år siden, selv om det
>var eksotisk (Jeg skrev til og med printerstyringsprogrammer
>i Simula :-)).
Vel som sagt; "praktiskt anvendbare"!
>
>> * For 10 år siden fantes det ingen adekvate implementasjoner av GC.
>
>Det er ihvertfall bare tull og tøys. GC i TOPS-10-Simula funket da
>så vidt jeg husker helt greit for 20 år siden. GC i Macintosh
>Allegro Common Lisp fungerte helt glimrende for 16 år siden. GC
>i SICStus Prolog fungerte noe helt utrolig bra for 12 år siden.
>Lista er nesten uendelig lang.
Vel, hvor mange bedrifter benytter Simula (eller for den saks skyld
Lisp) for software utvikling?
Greit at Simula har blitt litt benyttet på Blindern og at lokale
"hackere" kanskje har brukt Lisp for å lage inhouse fil konverterings
jobber, men vis meg _ET_ produkt mulig å bestille på CD som er progget
i Simula!
(eller for den saks skyld Lisp)
>
>> * For 5 år siden var AOP (Aspect Oriented Programming) et
>> forskningsdokument hos Xerox.
>
>AOP imponerer meg ikke noe særlig, jeg har faktisk sjelden blitt så
>skuffet som da jeg hørte Kiczales snakke om det. En av tingene som
>han påstod at java-folk syntes var kult, var rett og slett et
>hårreisende hack slik jeg ser det.
Hvis du tror AOP er en "java greie" så bør du lese litt mere om det
generelle konseptet!
AOP er en TANKEGANG og ikke en implementasjon eller kun for et språk
etc...
Et godt eksempel på veldig bra bruk av AOP er Alexandrescus bok
"Modern C++ Design" (selv om ganske få er klar over det)
[snip]
Thomas Hansen
left his sanity behind and proclaimed:
>* Espen Vestre
>| Hvis du kan noe om MOP, f.eks. allerede har lest AMOP, så kommer du
>| neppe til å rope halleluja, men jeg skjønner jo at folk som er
>| dårligere vant blir begeistret. Jeg har ofte lurt på hvorfor Gregor
>| Kiczales driver med dette her, men det kan bare være en av to: Penger
>| eller gleden ved å begeistre litt større masser.
>
> Jeg har ved endel anledninger sagt at livet er for langt til å bli
> flink i C++ og lignende, men det ser ikke ut til å registrere hos de
> som ikke har investert år av sitt liv i noe de har måttet gå fra.
Vel, det er din tabbe.
Når Java dør om et par år og C# om 5 år skal jeg love deg at C++
fortsatt lever i beste velgående...
>
> Ta f eks Bjarne Stroustrup og C++ og Alexander Stepanov og STL i C++.
> Verden hadde vært et meget bedre sted om disse to hadde kunnet få noe
> annet å gjøre som ikke krevde at de fortsatte i den retning de hadde
> gått altfor langt uten at noen stoppet dem.
Jeg vil tro at det neppe finnes noe programmerings språk på denne
planeten som har mere eksisterende kode enn C++ (kanskje med unntak av
C)
Jeg titta f.eks. på kildekoden til Windows 2000 for litt siden, og alt
var C++
[snip]
Thomas Hansen
<ve...@online.no> left his sanity behind and proclaimed:
Vel, det var kanskje å sette ting litt på spissen, hvis jeg hadde sagt
5 år hadde vel det vært litt mere korrekt.
Er muligens litt prega av MXXML4.0 som kom for ca. 1 år siden og som
gjør XSLT transformeringer mellom 8 og 100 ganger raskere enn i
MSXML3.0...
Poenget var at XSLT/XPath ol er noe helt nytt, det inneholder mange ny
paradigmer som aldri har vært brukt i store (seriøst anvendte) språk
før!
Thomas Hansen
left his sanity behind and proclaimed:
[snip]
Vel det var muligens litt sterkt av meg, men det du oppfatte som ironi
ble for meg oppfattet som sarkasme...
Hvis du slår opp i en av referansene dine (norsk ordbok) vil du se at
sarkasme er en mekanisme som ofte utløser andre ord (som da kanskje
IKKE står i dine referanser som f.eks. "Kjøtthue"ol...)
Forøvrig kan jeg proklamere at jeg leste hele innlegget ditt og det
var selvfølgelig mye interessant der, men det jeg syntes var MEST
interessant var at istedenfor å tilbakevise mine påstander (fremstilt
som Ironi, f.eks. at Leonardi Da Vinci brukte billedlige
fremstillinger for å kommunisere sitt rotorotopter, NASA etc...) og at
derfor billedlige fremstillinger er overlegne skriftlige i de fleste
sammenhenger (uavhengig av intelligens hos mottageren) så valgte du en
3 millioner gammel debatanttektnikk, nemlig å ta mot-debattanten for
små "skrivefeil", "enkeltord, setningsoppbygninger osv...
Jeg er egentlig MERE interessert i å vite hva du mener omm RESTEN av
innlegget mitt (altså den delen som IKKE inneholdt ordet kjøtthue)...
Jon Haugsand
> Greit at Simula har blitt litt benyttet på Blindern og at lokale
> "hackere" kanskje har brukt Lisp for å lage inhouse fil konverterings
> jobber, men vis meg _ET_ produkt mulig å bestille på CD som er progget
> i Simula!
> (eller for den saks skyld Lisp)
Spørsmålet gjaldt om det fantes OO og GC for tyve år siden, ikke om
det finnes programvare i produksjon som bruker Simula og Lisp.
Simula er kanskje ikke i bruk lenger, men har vært. (Den hadde
sansynligvis vært i mye mer omfattende bruk om wannabe-teknokratene i
NAVF hadde kjent sin besøkelsestid.) Lisp er i bruk i omfattende
applikasjoner. Autocad og emacs er standardeksemplene.
(Skal du tas seriøst, kan du i det minste prøve å holde deg til hva du
selv bruker av argumentasjon.)
--
Jon Haugsand
Dept. of Informatics, Univ. of Oslo, Norway, mailto:jon...@ifi.uio.no
http://www.ifi.uio.no/~jonhaug/, Phone: +47 22 85 24 92
Vetle Roeim
> In the era of Wed, 21 Apr 2004 16:58:09 +0200, Vetle Roeim
> <ve...@online.no> left his sanity behind and proclaimed:
>
>>* Thomas Hansen
>>
>> Pussig at du skulle velge nøyaktig 3 år. Jeg begynte tilfeldigvis å
>> jobbe med XSLT for nesten nøyaktig tre år siden, og det var praktisk
>> allerede da. I Java, til og med.
>>
>> Kan du forklare nærmere hvorfor det ikke var mulig med praktiske
>> anvendelser av XSLT for tre år siden?
>>
>>
> 5 år hadde vel det vært litt mere korrekt.
XSLT-spesifikasjonen er vel 5 år gammel, så det er nok
korrekt. Akkurat som Java ikke var praktisk anvendbart for 8 år
siden.
[...]
> Poenget var at XSLT/XPath ol er noe helt nytt, det inneholder mange ny
> paradigmer som aldri har vært brukt i store (seriøst anvendte) språk
> før!
Stemmer det at du mener at kun C og C++ er/har vært "seriøst
anvendte" språk? Og hva legger du egentlig i "seriøst anvendte"?
--
#!/usr/bin/vr
Espen Vestre
>>dette er en meget sterk overdrivelse. Simula for TOPS-10 var i
>>høyeste grad anvendbart for mer enn 20 år siden, selv om det
>>var eksotisk (Jeg skrev til og med printerstyringsprogrammer
>>i Simula :-)).
> Vel som sagt; "praktiskt anvendbare"!
Ja, som sagt: Praktisk anvendbart. Simula for TOPS-10 var ekstremt
praktisk anvendbart. Det samme kan man ikke si om det som seinere kom
for TOPS-20 (som i virkeligheten var TOPS-10-varianten i en eller
annen emuleringsmodus, jeg husker ikke detaljene), VMS etc. Jeg vet
ikke i hvor stor grad Simula for TOPS-10 ble brukt i kommersielle
sammenhenger, men det er helt klart at det _kunne_ ha blitt det.
> Vel, hvor mange bedrifter benytter Simula (eller for den saks skyld
> Lisp) for software utvikling?
Vet ikke med Simula, men det er mange og betydelige bedrifter som
bruker Common Lisp til alt fra å styre Hubble-teleskopet og styre
flytrafikk til å utvikle Playstationspill (Crash Bandicoot). Hvis
du er så åpen for å lære ting som du påstår hadde du selvsagt visst
dette for lenge siden.
> Greit at Simula har blitt litt benyttet på Blindern og at lokale
> "hackere" kanskje har brukt Lisp for å lage inhouse fil konverterings
> jobber, men vis meg _ET_ produkt mulig å bestille på CD som er progget
> i Simula!
> (eller for den saks skyld Lisp)
Selvsagt! For å unngå å drive reklame skal jeg overlate til deg å
gjette deg fram til hvilket firma jeg jobber i, så kan du oppsøke
våre hjemmesider og finne ut at du kan bestille en CD med et program
som jeg er hovedutvikleren av.
Her har du et atskillig mer avansert produkt, om det får plass på
én CD vet jeg jammen ikke:
http://www.xanalys.com/solutions/watson.html
> Hvis du tror AOP er en "java greie" så bør du lese litt mere om det
> generelle konseptet!
> AOP er en TANKEGANG og ikke en implementasjon eller kun for et språk
> etc...
Jeg tror du er feil person til å belære meg om AOP. Såpass burde selv
du snart ha skjønt.
--
(espen)
Bjorn Borud
|
| Jeg vil tro at det neppe finnes noe programmerings språk på denne
| planeten som har mere eksisterende kode enn C++ (kanskje med unntak
| av C) Jeg titta f.eks. på kildekoden til Windows 2000 for litt
| siden, og alt var C++ [snip]
hmm, og poenget er?
det finnes sannsynligvis betydelig mye mer PHP-kode enn det finnes
bruk av JSP. mener du det borger for kvaliteten til PHP? eventuelt
at det forteller deg at JSP ikke er bra? betyr det at disse er de
eneste teknologiene man burde velge mellom?
de fleste webserverne i verden kjører Apache. betyr det at designet
til Apache er den beste måten å designe en webserver på?
de fleste desktop-maskiner og laptops kjører en eller annen variant av
Windows. betyr det at Windows er det beste operativsystemet vi har i
dag?
-Bjørn
--
"I have only proved this to be correct, I have not actually tried it."
-- Donald Knuth
Jarle Aase
> Forøvrig kan jeg proklamere at jeg leste hele innlegget ditt og det var
> selvfølgelig mye interessant der, men det jeg syntes var MEST
> interessant var at istedenfor å tilbakevise mine påstander (fremstilt
> som Ironi, f.eks. at Leonardi Da Vinci brukte billedlige fremstillinger
> for å kommunisere sitt rotorotopter, NASA etc...) og at derfor
> billedlige fremstillinger er overlegne skriftlige i de fleste
> sammenhenger (uavhengig av intelligens hos mottageren) så valgte du en
> 3 millioner gammel debatanttektnikk, nemlig å ta mot-debattanten for
> små "skrivefeil", "enkeltord, setningsoppbygninger osv...
>
> Jeg er egentlig MERE interessert i å vite hva du mener omm RESTEN av
> innlegget mitt (altså den delen som IKKE inneholdt ordet kjøtthue)...
En ting som er viktig å forstå når du diskuterer på usenet, er at
mange av de du snakker med vet forferdelig mye mer enn deg. De tankene du
tenker i dag, og som er nye og spennende for deg, gjorde mange andre her
seg ferdig med for titalls år siden. For å ta en billedlig
sammenligning; det er omrent like spennende for meg å diskutere "data"
med en bruker, som det er for en yrkessjårfør å diskutere "bil" med en
treåring i sandkassen. Dette er viktig å forstå. Naggum _kan_ veldig
mye, selv om han er nøye med å diskutere på et plan der dette ikke
synes direkte, sånn at du aldri riktig vet om han vet mye om det han
diskuterer der og da, eller om han bare later som ;)
I stedet for å klore deg fast og tviholde på de oppfatningene du
allerede har, bør du være lydhør og åpen for andres oppfatninger.
Særlig når du oppholder deg i et miljø der du er en av de som kan aller
minst. Det betyr ikke at du ikke kan bli veldig flink en dag. Men skal du
bli veldig flink, må du innse at du ikke er ferdig å lære nye ting, og
tvert imot ta til deg nye tanker og nye synsvinkler med stor appetitt.
Hvis du i stedet vil begi deg inn i en "flame war" med Naggum, - så skal
du få et gratis tips: Naggum er en enestående retoriker, men han hinter
ufrivillig om de sårbare punktene sine i det han skriver ;)
Jarle
--
Jarle Aase http://www.jgaa.com
mailto:jg...@jgaa.com
<<< no need to argue - just kill'em all! >>>
Bjorn Borud
|
| Poenget var at XSLT/XPath ol er noe helt nytt, det inneholder mange ny
| paradigmer som aldri har vært brukt i store (seriøst anvendte) språk
| før!
hva har XSLT med generelle programmeringsspråk å gjøre? og hvorfor
tror du at det ikke eksisterte noe før XSLT? tror du det oppstod av
vakuum?
Morten Dreier
> Når Java dør om et par år og C# om 5 år skal jeg love deg at C++
> fortsatt lever i beste velgående...
Mener du seriøst at Java er dødende?
C# - ok, men java tas nå fremdeles i bruk på mange nye områder?
Jeg tar jo poenget om at C++ har vært her lengre enn java, men følger
det da at det er bedre enn Java?
Du har endel logiske brister i resonnementene dine. :-)
--
md
Leif Roar Moldskred
> Vel, det er din tabbe.
> Når Java dør om et par år og C# om 5 år skal jeg love deg at C++
> fortsatt lever i beste velgående...
Programmerings-språk døyr svært sjelden - dei blir berre mindre
synlege. Cobol og Fortran er framleis viktige programmeringsspråk, og
det same er ulike Basic varianter.
Det er dessutan temmeleg poenglaust å sette fram ein påstand som den
over uten å forklare _kvifor_ du meinar det vil vere slik. Kven som
helst kan tross alt påstå kva som helst.
> Jeg vil tro at det neppe finnes noe programmerings språk på denne
> planeten som har mere eksisterende kode enn C++ (kanskje med unntak av
> C)
Gjengs visdom er vel at det programmeringspråket som har flest
kode-linjer i aktiv bruk i dag er Cobol. Uten at det betyr so veldig
mykje.
--
Leif Roar Moldskred
Got Sfik?
Terje Kvernes
[ ... ]
> Selvsagt! For å unngå å drive reklame skal jeg overlate til deg å
> gjette deg fram til hvilket firma jeg jobber i, så kan du oppsøke
> våre hjemmesider og finne ut at du kan bestille en CD med et program
> som jeg er hovedutvikleren av.
apropos det der, dere jobber i LispWorks, gjør dere ikke? kunne man
dasket noen i hodet og blitt kvitt Motif som toolkit? :-)
[ ... ]
--
Terje