---

Hej,

Jeg sidder og regner nogle opgaver, men er gået helt i stå.
Jeg skal løse følgende ligning, men kan ikke rigtig komme igang - Kan
nogen hjælpe? (Det skal lige siges at jeg ikke ønsker løsningen, men
blot lidt hjælp til at komme igang)

(z + 2j)/(3z+5+j)=1-j

--
Med venlig hilsen
Jonas Jalling

---

"Jonas Jalling" <jonas@jalling.dk.invalid> skrev i en meddelelse news:420274f0$0$29844$14726298@news.sunsite.dk...
> Hej,
>
> Jeg sidder og regner nogle opgaver, men er gået helt i stå.
> Jeg skal løse følgende ligning, men kan ikke rigtig komme igang - Kan
> nogen hjælpe? (Det skal lige siges at jeg ikke ønsker løsningen, men
> blot lidt hjælp til at komme igang)
>
> (z + 2j)/(3z+5+j)=1-j
>
Fidusen ved imaginære tal er at regning med dem er som
sædvanlig, blot man husker at j*j = -1.

Mvh
Martin

---

Martin Larsen <mlarsen@post7.tele.dk> wrote:

> "Jonas Jalling" <jonas@jalling.dk.invalid> skrev i en meddelelse
> news:420274f0$0$29844$14726298@news.sunsite.dk...
> > Hej,
> >
> > Jeg sidder og regner nogle opgaver, men er gået helt i stå.
> > Jeg skal løse følgende ligning, men kan ikke rigtig komme igang - Kan
> > nogen hjælpe? (Det skal lige siges at jeg ikke ønsker løsningen, men
> > blot lidt hjælp til at komme igang)
> >
> > (z + 2j)/(3z+5+j)=1-j
> >
> Fidusen ved imaginære tal er at regning med dem er som
> sædvanlig, blot man husker at j*j = -1.

Imaginære tal? Man plejer da at betegne det tal, hvis kvadrat giver -1
som /i/. Ikke som /j/.
--
Per Erik Rønne

---

Per Rønne wrote:
> Martin Larsen <mlarsen@post7.tele.dk> wrote:
>
>
>>"Jonas Jalling" <jonas@jalling.dk.invalid> skrev i en meddelelse
>>news:420274f0$0$29844$14726298@news.sunsite.dk...
>>
>>>Hej,
>>>
>>>Jeg sidder og regner nogle opgaver, men er gået helt i stå.
>>>Jeg skal løse følgende ligning, men kan ikke rigtig komme igang - Kan
>>>nogen hjælpe? (Det skal lige siges at jeg ikke ønsker løsningen, men
>>>blot lidt hjælp til at komme igang)
>>>
>>>(z + 2j)/(3z+5+j)=1-j
>>>
>>
>>Fidusen ved imaginære tal er at regning med dem er som
>>sædvanlig, blot man husker at j*j = -1.
>
>
> Imaginære tal? Man plejer da at betegne det tal, hvis kvadrat giver -1
> som /i/. Ikke som /j/.

Tak, begge to.
Og til dig Per, så er det meget forskelligt hvad man bruger - jeg er
blevet undervist i både at bruge j, og i at bruge i. Jeg har fået den
forklaring at el-folk normalt bruger j, for ikke at blande sammen med
enheden for strøm. Om det passer skal jeg ikke kunne sige.

--
Med venlig hilsen
Jonas Jalling

---

Scripsit spam@husumtoften.invalid (Per Rønne)
> Martin Larsen <mlarsen@post7.tele.dk> wrote:

>> Fidusen ved imaginære tal er at regning med dem er som
>> sædvanlig, blot man husker at j*j = -1.

> Imaginære tal? Man plejer da at betegne det tal, hvis kvadrat giver -1
> som /i/. Ikke som /j/.

I visse fagområder (vist hovedsagelig ingeniørdiscipliner) er der
tradition for at betegne den imaginære enhed som j. Man ønsker at
undgå forveksling med andre i'er. Men jeg kan ikke huske hvad det er
de andre i'er står for.

--
Henning Makholm "Khanivore is climbing out of its life-support pod."

---

Henning Makholm <henning@makholm.net> writes:

> Scripsit spam@husumtoften.invalid (Per Rønne)
>> Martin Larsen <mlarsen@post7.tele.dk> wrote:
>
>>> Fidusen ved imaginære tal er at regning med dem er som
>>> sædvanlig, blot man husker at j*j = -1.
>
>> Imaginære tal? Man plejer da at betegne det tal, hvis kvadrat giver -1
>> som /i/. Ikke som /j/.
>
> I visse fagområder (vist hovedsagelig ingeniørdiscipliner) er der
> tradition for at betegne den imaginære enhed som j. Man ønsker at
> undgå forveksling med andre i'er. Men jeg kan ikke huske hvad det er
> de andre i'er står for.

Indenfor kredsløbsteori (som det eneste) er jeg stødt på det. Der brugte
vi (såvidt jeg husker):

i: Tidsafhængig strøm
I: Strømmens amplitude evt. rms (efter sammenhæng[1])
j: Imaginær enhed

v og V skelnede vi mellem på samme måde.


Mvh.


Dennis Jørgensen


[1]Nogle steder bruges I og I_{rms} (Læses som LaTeX).

---

Jonas Jalling <jonas@jalling.dk.invalid> wrote:

> Hej,
>
> Jeg sidder og regner nogle opgaver, men er gået helt i stå.
> Jeg skal løse følgende ligning, men kan ikke rigtig komme igang - Kan
> nogen hjælpe? (Det skal lige siges at jeg ikke ønsker løsningen, men
> blot lidt hjælp til at komme igang)
>
> (z + 2j)/(3z+5+j)=1-j

Du kan ikke »løse« en ligning med to ubekendte, men du kan isolere en af
de to ubekendte. Multiplicer eksempelvis med nævneren på begge sider af
lighedstegnet, idet nævneren naturligvis er ≠ 0.
--
Per Erik Rønne

---

Jonas Jalling wrote:

> Jeg sidder og regner nogle opgaver, men er gået helt i stå.
> Jeg skal løse følgende ligning, men kan ikke rigtig komme igang - Kan
> nogen hjælpe? (Det skal lige siges at jeg ikke ønsker løsningen, men
> blot lidt hjælp til at komme igang)
>
> (z + 2j)/(3z+5+j)=1-j

Skynd dig at slippe af med brøken ved at at
gange med 3z+5+j på begge sider. Brug så
at j*j=-1.

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> wrote:

> Jonas Jalling wrote:
>
> > Jeg sidder og regner nogle opgaver, men er gået helt i stå.
> > Jeg skal løse følgende ligning, men kan ikke rigtig komme igang - Kan
> > nogen hjælpe? (Det skal lige siges at jeg ikke ønsker løsningen, men
> > blot lidt hjælp til at komme igang)
> >
> > (z + 2j)/(3z+5+j)=1-j
>
> Skynd dig at slippe af med brøken ved at at
> gange med 3z+5+j på begge sider. Brug så
> at j*j=-1.

Tidligere ville jeg have sagt, at han blot skulle flytte nævnere om på
den anden side af lighedstegnet, på samme måde som vi lærte det i 7.
klasse bogligt. Men det kan de jo ikke længere finde ud af. Går du på
teknikum, Jonas?

Jeg skal understrege at jeg ikke mener at det er elevernes skyld, når de
ikke kan det. Jeg har trods alt undervist som lærervikar i folkeskolen,
og selv de bedst begavede kan ikke klare det, fordi de ikke lærer det i
dagens enhedsskole {nogle ældre lærere kan dog godt lære eleverne det,
men de er altså ikke forpligtede til det}. I gymnasieskolen giver det så
store problemer, hvilket jeg som datalogilærer oplever.
--
Per Erik Rønne

---

Per Rønne wrote:

> Jeg skal understrege at jeg ikke mener at det er elevernes skyld, når de
> ikke kan det. Jeg har trods alt undervist som lærervikar i folkeskolen,
> og selv de bedst begavede kan ikke klare det, fordi de ikke lærer det i
> dagens enhedsskole {nogle ældre lærere kan dog godt lære eleverne det,
> men de er altså ikke forpligtede til det}. I gymnasieskolen giver det så
> store problemer, hvilket jeg som datalogilærer oplever.

Jeg plejer da ikke at have brug for ligningsløsning i datalogi-
undervisningen. Det vildeste er vist løsningen af Gauss'
sum-fra-1-til-1000-problem i forbindelse med indsættelsessortering.

I parentes bemærket gemmer jeg tildeling til efter jul; før
har vi ikke brug for det. Uden tildeling har man den kæmpefordel,
at man kan bruge en algebraisk stepper til at visualisere beregning:

<http://www.drscheme.org/tour/tour-Z-H-9.html#node_chap_8>

(bemærk, at man kan gå både frem og tilbage i en beregning)

Jeg benytter noter baseret på <http://www.htdp.org>.

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> wrote:

> Per Rønne wrote:
>
> > Jeg skal understrege at jeg ikke mener at det er elevernes skyld, når de
> > ikke kan det. Jeg har trods alt undervist som lærervikar i folkeskolen,
> > og selv de bedst begavede kan ikke klare det, fordi de ikke lærer det i
> > dagens enhedsskole {nogle ældre lærere kan dog godt lære eleverne det,
> > men de er altså ikke forpligtede til det}. I gymnasieskolen giver det så
> > store problemer, hvilket jeg som datalogilærer oplever.
>
> Jeg plejer da ikke at have brug for ligningsløsning i datalogi-
> undervisningen. Det vildeste er vist løsningen af Gauss'
> sum-fra-1-til-1000-problem i forbindelse med indsættelsessortering.

Jeg gav eleverne en opgave, hvor de i hhv Java {htx} og Delphi {almen
gymnasium} skulle forrente og afdrage et antal annuitetslån.

Der var en elev som i 3g {htx} som ikke var i stand til at isolere
afdrag i følgende ligning:

ydelse = afdrag + rentebeløb.

Programmet, der var en stor opgave, skulle naturligvis udvikles fuldt
objektorienteret og med et fornuftigt klassehierarki. Men i den metode
der for et lån skulle forrente og afdrage en termin, kunne han ikke
finde ud af noget så simpelt.
--
Per Erik Rønne

---

Per Rønne wrote:
> Jens Axel Søgaard <usenet@soegaard.net> wrote:
>>Per Rønne wrote:

>>>Jeg skal understrege at jeg ikke mener at det er elevernes skyld, når de
>>>ikke kan det. Jeg har trods alt undervist som lærervikar i folkeskolen,
>>>og selv de bedst begavede kan ikke klare det, fordi de ikke lærer det i
>>>dagens enhedsskole {nogle ældre lærere kan dog godt lære eleverne det,
>>>men de er altså ikke forpligtede til det}. I gymnasieskolen giver det så
>>>store problemer, hvilket jeg som datalogilærer oplever.
>>
>>Jeg plejer da ikke at have brug for ligningsløsning i datalogi-
>>undervisningen. Det vildeste er vist løsningen af Gauss'
>>sum-fra-1-til-1000-problem i forbindelse med indsættelsessortering.
>
> Jeg gav eleverne en opgave, hvor de i hhv Java {htx} og Delphi {almen
> gymnasium} skulle forrente og afdrage et antal annuitetslån.
>
> Der var en elev som i 3g {htx} som ikke var i stand til at isolere
> afdrag i følgende ligning:
>
> ydelse = afdrag + rentebeløb.

Det er naturligvis skuffende.

Hm - hvis han endnu ikke har lært det i 3.g, så er det snarere
mangel på fundemental forståelse end mangelfuld undervisning,
der er årsagen.

> Programmet, der var en stor opgave, skulle naturligvis udvikles fuldt
> objektorienteret og med et fornuftigt klassehierarki. Men i den metode
> der for et lån skulle forrente og afdrage en termin, kunne han ikke
> finde ud af noget så simpelt.

Af nysgerrighed: Plejer du at gennemgå syn/kontrol/model-måden at
konstruere programmer med grafiske brugerflader?

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> wrote:

> Per Rønne wrote:
> > Jens Axel Søgaard <usenet@soegaard.net> wrote:
> >>Per Rønne wrote:

> >>>Jeg skal understrege at jeg ikke mener at det er elevernes skyld, når de
> >>>ikke kan det. Jeg har trods alt undervist som lærervikar i folkeskolen,
> >>>og selv de bedst begavede kan ikke klare det, fordi de ikke lærer det i
> >>>dagens enhedsskole {nogle ældre lærere kan dog godt lære eleverne det,
> >>>men de er altså ikke forpligtede til det}. I gymnasieskolen giver det så
> >>>store problemer, hvilket jeg som datalogilærer oplever.

> >>Jeg plejer da ikke at have brug for ligningsløsning i datalogi-
> >>undervisningen. Det vildeste er vist løsningen af Gauss'
> >>sum-fra-1-til-1000-problem i forbindelse med indsættelsessortering.

> > Jeg gav eleverne en opgave, hvor de i hhv Java {htx} og Delphi {almen
> > gymnasium} skulle forrente og afdrage et antal annuitetslån.

> > Der var en elev som i 3g {htx} som ikke var i stand til at isolere
> > afdrag i følgende ligning:

> > ydelse = afdrag + rentebeløb.

> Det er naturligvis skuffende.

> Hm - hvis han endnu ikke har lært det i 3.g, så er det snarere
> mangel på fundemental forståelse end mangelfuld undervisning,
> der er årsagen.

I den gamle delte skole, var det lært i 6. klasse bogligt, svarende til
endnu tidligere tiders 1. mellem.

> > Programmet, der var en stor opgave, skulle naturligvis udvikles fuldt
> > objektorienteret og med et fornuftigt klassehierarki. Men i den metode
> > der for et lån skulle forrente og afdrage en termin, kunne han ikke
> > finde ud af noget så simpelt.

> Af nysgerrighed: Plejer du at gennemgå syn/kontrol/model-måden at
> konstruere programmer med grafiske brugerflader?

Opgaven kørte ikke grafisk, men helt traditionelt. Med editor og
udskrift til skærmen. Men gymnasieeleverne {ikke htx-eleverne} fik
senere mulighed for at omforme deres program til et grafisk program, med
brug af Delphis klassebibliotek.

Jeg ved ikke hvad du mener med syn/kontrol/model-måden, men jeg blev
også færdig med mit speciale for 14 år siden. I 1991. Det kan såmænd
også være at jeg kender den under et andet navn. Jeg har dog intet set
om en sådan i regelsættet for hverken htx programmering eller
studentereksamen datalogi. Ej heller konstateret det, når jeg har været
ude som censor.
--
Per Erik Rønne

---

Per Rønne wrote:
> Jens Axel Søgaard <usenet@soegaard.net> wrote:
>>Per Rønne wrote:
>>>Programmet, der var en stor opgave, skulle naturligvis udvikles fuldt
>>>objektorienteret og med et fornuftigt klassehierarki. Men i den metode
>>>der for et lån skulle forrente og afdrage en termin, kunne han ikke
>>>finde ud af noget så simpelt.

>>Af nysgerrighed: Plejer du at gennemgå syn/kontrol/model-måden at
>>konstruere programmer med grafiske brugerflader?

> Opgaven kørte ikke grafisk, men helt traditionelt. Med editor og
> udskrift til skærmen. Men gymnasieeleverne {ikke htx-eleverne} fik
> senere mulighed for at omforme deres program til et grafisk program, med
> brug af Delphis klassebibliotek.

Nåh - så er det bare mig, der ikke har fantasi nok til at indføre objekter.

> Jeg ved ikke hvad du mener med syn/kontrol/model-måden, men jeg blev
> også færdig med mit speciale for 14 år siden. I 1991. Det kan såmænd
> også være at jeg kender den under et andet navn. Jeg har dog intet set
> om en sådan i regelsættet for hverken htx programmering eller
> studentereksamen datalogi. Ej heller konstateret det, når jeg har været
> ude som censor.

På engelsk hedder det Model-View-Control ofte forkortet MVC.
(Jeg må indrømme, at jeg ikke er 100% sikker på den danske
betegnelse).

Ideen er at tredele ens program, model for sig, visning for sig,
og et bindeled kaldet kontrollen, som dels kan aflæse modellen,
dels sørge for at klik i brugerfladen udløser ændringer i modellen.

Fidusen ved at adskille model og visning er at programmet får
en pænere struktur. I dit eksempel ville det kun være visningsdelen,
der skulle omskiftes for at gå fra en tekstgrænseflade til en
grafisk grænseflade.

I praksis sørger jeg for, at eleverne laver modellen først
og afprøver den, inden de begynder på at lave en visning.

Jeg gættede på, at de objekter, der blev indført havde med
visningen at gøre.

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> wrote:

> Per Rønne wrote:
> > Jens Axel Søgaard <usenet@soegaard.net> wrote:
> >>Per Rønne wrote:
> >>>Programmet, der var en stor opgave, skulle naturligvis udvikles fuldt
> >>>objektorienteret og med et fornuftigt klassehierarki. Men i den metode
> >>>der for et lån skulle forrente og afdrage en termin, kunne han ikke
> >>>finde ud af noget så simpelt.

> >>Af nysgerrighed: Plejer du at gennemgå syn/kontrol/model-måden at
> >>konstruere programmer med grafiske brugerflader?

> > Opgaven kørte ikke grafisk, men helt traditionelt. Med editor og
> > udskrift til skærmen. Men gymnasieeleverne {ikke htx-eleverne} fik
> > senere mulighed for at omforme deres program til et grafisk program, med
> > brug af Delphis klassebibliotek.

> Nåh - så er det bare mig, der ikke har fantasi nok til at indføre objekter.

Hvis de skal kunne bruge deres programmeringserfaring til noget senere,
så er de vel nødt til at kunne lave nogle programmer der kører på en
grafisk grænseflade.

> > Jeg ved ikke hvad du mener med syn/kontrol/model-måden, men jeg blev
> > også færdig med mit speciale for 14 år siden. I 1991. Det kan såmænd
> > også være at jeg kender den under et andet navn. Jeg har dog intet set
> > om en sådan i regelsættet for hverken htx programmering eller
> > studentereksamen datalogi. Ej heller konstateret det, når jeg har været
> > ude som censor.

> På engelsk hedder det Model-View-Control ofte forkortet MVC.
> (Jeg må indrømme, at jeg ikke er 100% sikker på den danske
> betegnelse).

Jeg har aldrig hørt om den, så den må nok være kommet efter min
studentertid.

> Ideen er at tredele ens program, model for sig, visning for sig,
> og et bindeled kaldet kontrollen, som dels kan aflæse modellen,
> dels sørge for at klik i brugerfladen udløser ændringer i modellen.

> Fidusen ved at adskille model og visning er at programmet får
> en pænere struktur. I dit eksempel ville det kun være visningsdelen,
> der skulle omskiftes for at gå fra en tekstgrænseflade til en
> grafisk grænseflade.

> I praksis sørger jeg for, at eleverne laver modellen først
> og afprøver den, inden de begynder på at lave en visning.

> Jeg gættede på, at de objekter, der blev indført havde med
> visningen at gøre.

Det virker som om jeg i praksis alligevel har fulgt den model, jeg
aldrig havde hørt om. Måske fordi det er den eneste rimelige måde at
gøre det på?
--
Per Erik Rønne

---

"Per Rønne" <spam@husumtoften.invalid> skrev i en meddelelse news:1grhf1p.i5g3n81q1rq9gN%spam@husumtoften.invalid...
> Jens Axel Søgaard <usenet@soegaard.net> wrote:
>
> Hvis de skal kunne bruge deres programmeringserfaring til noget senere,
> så er de vel nødt til at kunne lave nogle programmer der kører på en
> grafisk grænseflade.
>
> > > Jeg ved ikke hvad du mener med syn/kontrol/model-måden, men jeg blev
> > > også færdig med mit speciale for 14 år siden. I 1991. Det kan såmænd
> > > også være at jeg kender den under et andet navn.

Den har tilsyneladende været i brug siden omkring 1980
http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

Mvh
Martin

---

Martin Larsen <mlarsen@post7.tele.dk> wrote:

> "Per Rønne" <spam@husumtoften.invalid> skrev i en meddelelse
> news:1grhf1p.i5g3n81q1rq9gN%spam@husumtoften.invalid...
> > Jens Axel Søgaard <usenet@soegaard.net> wrote:
> >
> > Hvis de skal kunne bruge deres programmeringserfaring til noget senere,
> > så er de vel nødt til at kunne lave nogle programmer der kører på en
> > grafisk grænseflade.
> >
> > > > Jeg ved ikke hvad du mener med syn/kontrol/model-måden, men jeg blev
> > > > også færdig med mit speciale for 14 år siden. I 1991. Det kan såmænd
> > > > også være at jeg kender den under et andet navn.
>
> Den har tilsyneladende været i brug siden omkring 1980
> http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

OK, til SmallTalk80, som jeg kun stiftede et perifert kendskab til.
--
Per Erik Rønne

---

Per Rønne wrote:

> Hvis de skal kunne bruge deres programmeringserfaring til noget senere,
> så er de vel nødt til at kunne lave nogle programmer der kører på en
> grafisk grænseflade.

Tjoh - jeg synes dog de har sværere ved at lære at tænke systematisk
når de udvikler modellen, end de har ved at sætte en brugerflade
på bagefter.

>>På engelsk hedder det Model-View-Control ofte forkortet MVC.
>>(Jeg må indrømme, at jeg ikke er 100% sikker på den danske
>>betegnelse).

> Jeg har aldrig hørt om den, så den må nok være kommet efter min
> studentertid.

Indrømmet, jeg faldt først over den, da jeg skulle til at undervise.

>>Ideen er at tredele ens program, model for sig, visning for sig,
>>og et bindeled kaldet kontrollen, som dels kan aflæse modellen,
>>dels sørge for at klik i brugerfladen udløser ændringer i modellen.

> Det virker som om jeg i praksis alligevel har fulgt den model, jeg
> aldrig havde hørt om. Måske fordi det er den eneste rimelige måde at
> gøre det på?

Det har du ret i

Men æh - jeg synes mange af de lærebøger, der bruges, har en tendens
til at få eleverne til at lave en knap først (som hører til visningen),
derefter at indsætte en variabel (hørende til modellen) ind i
visningsobjektet. Endelig sættes modellens udregninger ofte ind
i selve tilbagekaldsfunktionen (hørende til kontrollen), som kaldes, når
der klikkes på knappen. Tredelingen går dermed hurtigt fløjten, hvis
man ikke udvikler modellen først.


Med hensyn til fokus i undervisningen, så ligger jeg objekter
meget sent i forløbet. (Til gengæld ligger "records" meget tidligt).

Inspirationen til den fordeling kommer fra

"The Structure and Interpretation of the Computer Science Curriculum"

hvor Felleisen, Findler, Flatt og Krishnamurthi diskuterer, hvordan
et første kursus i datalogi skal se ud. Der er mange gode overvejelser i.

<http://www.ccs.neu.edu/scheme/pubs/fffk-jfp.pdf>

De er forresten ved at udvikle noget lignende med Java, som
underliggende sprog.

--
Jens Axel Søgaard

---

Jens Axel Søgaard <usenet@soegaard.net> wrote:

> Per Rønne wrote:

> > Hvis de skal kunne bruge deres programmeringserfaring til noget senere,
> > så er de vel nødt til at kunne lave nogle programmer der kører på en
> > grafisk grænseflade.

> Tjoh - jeg synes dog de har sværere ved at lære at tænke systematisk
> når de udvikler modellen, end de har ved at sætte en brugerflade
> på bagefter.

Ja, der har jeg nok styret dem en del. Men det er jo også temmelig
begrænset tid der er til rådighed, og med gymnasiereformen reduceres det
yderligere.

> >>På engelsk hedder det Model-View-Control ofte forkortet MVC.
> >>(Jeg må indrømme, at jeg ikke er 100% sikker på den danske
> >>betegnelse).

> > Jeg har aldrig hørt om den, så den må nok være kommet efter min
> > studentertid.

> Indrømmet, jeg faldt først over den, da jeg skulle til at undervise.

Det forklarer jo en de.

> >>Ideen er at tredele ens program, model for sig, visning for sig,
> >>og et bindeled kaldet kontrollen, som dels kan aflæse modellen,
> >>dels sørge for at klik i brugerfladen udløser ændringer i modellen.
>
> > Det virker som om jeg i praksis alligevel har fulgt den model, jeg
> > aldrig havde hørt om. Måske fordi det er den eneste rimelige måde at
> > gøre det på?
>
> Det har du ret i
>
> Men æh - jeg synes mange af de lærebøger, der bruges, har en tendens
> til at få eleverne til at lave en knap først (som hører til visningen),
> derefter at indsætte en variabel (hørende til modellen) ind i
> visningsobjektet. Endelig sættes modellens udregninger ofte ind
> i selve tilbagekaldsfunktionen (hørende til kontrollen), som kaldes, når
> der klikkes på knappen. Tredelingen går dermed hurtigt fløjten, hvis
> man ikke udvikler modellen først.
>
>
> Med hensyn til fokus i undervisningen, så ligger jeg objekter
> meget sent i forløbet. (Til gengæld ligger "records" meget tidligt).
>
> Inspirationen til den fordeling kommer fra
>
> "The Structure and Interpretation of the Computer Science Curriculum"
>
> hvor Felleisen, Findler, Flatt og Krishnamurthi diskuterer, hvordan
> et første kursus i datalogi skal se ud. Der er mange gode overvejelser i.
>
> <http://www.ccs.neu.edu/scheme/pubs/fffk-jfp.pdf>
>
> De er forresten ved at udvikle noget lignende med Java, som
> underliggende sprog.

Jeg brugte »Programkonstuktion med Delphi« fra TolstrupDATA til Delphi,
og »Java 2 bogen« til java. Sidstnævnte havde skolen indkøbt år tilbage,
og den er ganske elendig, og leder ikke naturligt frem til grafisk
programudvikling, lige som det ikke er en skole- men en hobbybog. Her
ville jeg i stedet anbefale Ilse Haugaards »Java Programmering« fra
systime.

Gymnasieholdet overtog jeg et stykke ind i skoleåret, så der var tale om
nødundervisning. Holdet endte dog med at ligge ret stærkt.
--
Per Erik Rønne