[Oberon] Use of resources.

[Frans-Pieter Vonck]

I really appreciate Dijkstra idea's about programming and some of the 
ewd's, especially the polemic ones, I understand. However, my students 
are not Mozarts, they are schoolkids, 12 13 years old. They make 
animated postcards in Scratch, program an NXT robot, blink a led on an 
Arduino, write some HTML, experiment with Javascript  learn LUA for 
Minecraft and try to understand the difference between tabs and spaces 
in Python. All this they do because they enjoy it, not because an adult 
said so.

The stepwise refinement is not how they (and myself) think. Stepwise 
refinement it is a way of discovering and communicating the logic of 
their creative product, a program.
And I'm convinced that along with his beloved MontBlanc, Dijkstra was 
also carrying a pencil and an eraser with him.

Besides my humble efforts to teach my students some programming, they 
have classes in Latin, Greek, French, English, Dutch, Math. If a student 
has a problem in learning one of these languages he or she gets 
elementary grammar lessons. A sort of Universal Grammar of European 
languages.

Teaching Oberon could have the same function - it gives insight in the 
logic structure behind programming languages like Python, Javascript, 
Lua, C.


Greets,
Frans-Pieter


Jan de Kruyf schreef op 2015-12-16 19:36:
> hallo Frans-P
> 
> To me the issue is the thinking patterns needed for effective software 
> design.
> After all that is why they come to school, to learn!
> 
> One helpful way of thinking is "separation of concerns."
> see
> 
>  https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html
> 
> When you search for "Dijkstra separation of concerns" you will find
> more links. The wikipedia article is unfortunately a bit advanced and
> so it obfuscates the essence.
> 
> Another helpful thinking pattern is "progressive refinement". Wirth
> tried to teach that way.
> The green Oberon book has examples and there is a paper from him on
> the 8 queens problem where he tries to highlight the thinking pattern.
> 
> so if I must speak for my muddy self: Often I dream up some seemingly
> useful structure to start from, but then as I progress I might find
> that "it just looks too complex" mostly because I did not think things
> through to the very esssence of it, or beause
> i try to do 2 things at once, and none gets done right. So back to the
> drawingboard and with the experience gained we start all over again,
> etc.
> 
> 
> cheers,
> j.
> 
> 
> 
> 
> 
> On 12/16/15, Frans-Pieter Vonck <fp at vonck.nl> wrote:
>> Yes, one page per module seems ridiculous, and one page per procedure
>> seems fair.
>> 
>> What strikes me is that my students show me piles of listings of code
>> that reminds me of the windings green lineprinter paper I walked 
>> around
>> with in the eighties. Pascal on the VAX. The programming projects of 
>> my
>> students are self chosen, extracurricular activities and the need for
>> structured programming emerges naturally in their learning path. By 
>> the
>> way, I'm happily surprised they still feel a need to actually print
>> their code on paper.
>> 
>> So the idea is the let them discover a sort of 'rule of thumbs' for 
>> the
>> intellectually manageability of programs. (Wirth - On the composition 
>> of
>> Well-structured programs). And then show them the wise steps to refine
>> their code.
>> 
>> Also, as I scrolled through the Project Oberon book I found that the
>> definition listings of the modules were around one book page.
>> Tomorrow I will make a hard copy of the Oberon book and to get a 
>> feeling
>> of the intellectually manageability of Project Oberon.
>> 
>> Greets,
>> Frans-Pieter
>> 
>> Chris Burrows schreef op 2015-12-15 22:40:
>>> 'One page per procedure' possibly but definitely not 'one page per
>>> module'.
>>> I don't recall seeing a quote but I have always used a *rule of 
>>> thumb*
>>> that
>>> if you can't see all of a procedure at once then you should 
>>> *consider*
>>> refactoring it. Hence what might have been 'a page' in the past might
>>> now be
>>> 'a screenful'. This is deliberately vague e.g. if I regularly use one
>>> of my
>>> widescreen monitors in portrait orientation with a relatively small
>>> font I
>>> can see a lot more than otherwise might be posible.
>>> 
>>> However, you should be very careful when communicating guidelines of
>>> this
>>> sort to inexperienced programmers to make sure they they don't
>>> interpret
>>> them as commandments set in stone. Otherwise they might arbitrarily
>>> break up
>>> large procedures into smaller illogical chunks just because they have
>>> been
>>> given a rule to follow. You should give some examples of horror cases
>>> that
>>> obviously need splitting up and other examples of procedures that are
>>> large
>>> for a good reason (e.g. a case statement with many cases),
>>> 
>>> Regards,
>>> Chris Burrows
>>> http://www.cfbsoftware.com
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>>>> Frans-Pieter Vonck
>>>> Sent: Wednesday, 16 December 2015 7:09 AM
>>>> To: oberon at lists.inf.ethz.ch
>>>> Subject: Re: [Oberon] Use of resources.
>>>> 
>>>> Hello Paul, Peter and all other oberonneurs,
>>>> 
>>>> one of my former highschool students is writing a Python programmes
>>>> that have very long listings. Despite the structured nature of 
>>>> Python
>>>> his programmes become to complex to explain to me.
>>>> Now I think I remember a quote from Niklaus Wirth where he states
>>>> that every module that is longer than one page should be rewritten 
>>>> in
>>>> separate modules.
>>>> Did anyone remember this quote? And, do you think this adagium is
>>>> only valid for the Main Module or is it also applicable for, say 
>>>> math
>>>> library modules?
>>>> 
>>>> Greets,
>>>> Frans-Pieter
>>>> 
>>> 
>>> 
>>> --
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>>> systems
>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
>> systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>