[Oberon] Use of resources.

[eas lab]

>  ...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'.

That is the correct answer.
Computing is not about computers.
It's about HCI. Humans , cognition, eyes, seeing ...,screen-overflow..



On 12/17/15, Frans-Pieter Vonck <fp at vonck.nl> wrote:
> 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
>>>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>