<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Denis,<br>
Rather than asking for changes in the language I suggest that you
master the language.<br>
I also suggest that you use the Windows based BlackBox/Component Pascal
<br>
(super set of Oberon-2) which is *very* stable.<br>
<br>
The easy of development and simplicity of the language *far* out weight
any<br>
(perceived) limitations.<br>
<br>
Here are a few things I do *not* want in the language:<br>
<br>
o Generic procedures - I used those for many years with the language<br>
called MAINSAIL. When one looks at such a language with generic
procedures<br>
one has no idea what a procedure might be doing. One must go back to
each<br>
category supported and read the code. This takes human time and effort.<br>
<br>
o Macros - for the same reason one does not want to redefine language
constructs.<br>
One can not read the code but again must go back to the definitions.
Again, a massive<br>
time waster. I used to pride myself on being able to write complex
macros and missed them<br>
initially when I hit Oberon. But now I see the virtue of not having
them and do not miss them<br>
in the least.<br>
<br>
o Initialization of variables - syntactically it is elegant to be able
to write the definition<br>
(or is it declaration, I can never remember) of variables (arrays)
along with their intial<br>
values, BUT using a different initialization set to values then becomes
hard whereas<br>
a set of procedures that initialize variables can be dynamically chosen
at run time.<br>
Much more flexibility than static initialization.<br>
<br>
o Compiler built in functions - what you like may not be what I like.
Make it as simple as<br>
possible but not simpler. If I want a slightly different behavior then
Oberon allows me to <br>
implement it the way I want it to be. In a paraphrase of a dictum at
Xerox Parc says<br>
"Don't mode me in!".<br>
<br>
-Doug Danforth<br>
<br>
<br>
<br>
spir wrote:
<blockquote cite="mid:20100711211228.006ff277@o" type="cite">
<pre wrap="">On Sun, 11 Jul 2010 10:28:49 -0500
<a class="moz-txt-link-abbreviated" href="mailto:Aubrey.McIntosh@Alumni.UTexas.Net">Aubrey.McIntosh@Alumni.UTexas.Net</a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- no literal notation for arrays and records/objects (center := Point{x:=0,y:=0};)
</pre>
</blockquote>
<pre wrap="">I don't understand how this notion is unsatisfactory for you:
center := ThisP ( 5.0, 7.5 )
</pre>
</blockquote>
<pre wrap=""><!---->[...]
</pre>
<blockquote type="cite">
<pre wrap="">PROCEDURE ThisP(x, y : REAL ) : PointPtr;
VAR
aux : PointPolarPtr;
BEGIN
aux.mag := Math.sqrt(x*x + y*y);
aux.angle := Math.arctan( y / x );
RETURN aux
END ThisP;
</pre>
</blockquote>
<pre wrap=""><!---->
Because it is not builtin, indeed. Why have arrays, & indexing, then? Why records, & extensible types? Why operators at all? We can hand-code all of this, cannot we? Why sensible abstractions like automatic dereferencing, too?
Builtin means:
* No need to code it / reinvent the wheel.
* No need to re-code it each time, for detail differences: here one needs one init proc for _every_ type.
* It is very probably done the right way.
* It is reliable.
* It is a *shared* feature.
The latter point is often overlooked, but in my sense the most important one: the whole Oberon programming community share the feature; everyone knows, or will soon know, perfectly its precise semantics.
And there are things we simply cannot build on top of a language as is. I would be pleased to contribute a module, if the language gave me the means to do it. But literal notation magic happens on the compiler side, thus I'm helpless (and can only complain ;-)
All of this makes me sad for the following reason: when I first discovered Oberon-2, I was very surprised such a design quality in a super-hype field (OO) can even *exist* in our all-marketing time. And wondered why this language did not happen to challenge and offer prgrammer with higher quality expectations ("resistants") a sane & sensible alternative ("counter culture" ;-) in front of the all-C (C++,C#,java) power... exactly like Pascal one generation before. Reasons I read in an interview of Niklaus Wirth are certainly true: marketing, precisely, and not the right time for a new language.
Maybe there is more on the topic. Namely: is it a wished perspective? I would love to see an active and enthusiastic eco-system around such a great language. Among other things, this requires a tiny minimum of agile tools & abstractions; ones that would not make the language less elegant, on the contrary (and let more place to the joy of programming instead of wasting our time and energy with administrative tasks). What do the language creators, promotors, users want?
(Sorry for taking your reply as an oppurtunity, Aubrey. And sorry for the mood to all.)
Denis
________________________________
vit esse estrany ☣
spir.wikidot.com
--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
</blockquote>
</body>
</html>