<div dir="ltr">So let me be the devil's advocate:<div><br></div><div>I program embedded stuff. And for lack of integration of Oberon into main line engineering </div><div>I am forced to use another language. I chose Ada because it is relatively easy to understand </div><div>the syntax when you first start out.</div><div>At the same time it is bulky and slow in use. The paranoid security of it hampers the readbility and does</div><div>not really improve the bug situation.  The code is as efficient as GCC can make it. </div><div>Which is pretty good, but at a price.</div><div><br></div><div>For Oberon to be a real alternative I would minimally need:</div><div>1. single bit variables.</div><div>2. packed arrays of those.</div><div>3. if at all possible multi bit variables (2, 3, 4, 5 etc.)</div><div>4. packed records of single and multi bit variables.</div><div><br></div><div>The single bit stuff I did many years ago in Oberon-0 for AVR and it was not difficult.</div><div>All the OOP stuff as in C++ and Ada only confuse me further so I have no use for them. <br></div><div>There are other ways of sane thinking that give the same benefits. I am very</div><div>much in agreement with NW on that.</div><div><br></div><div>In any case: then there is item 5:</div><div>  An Oberon front end for GCC. so we have a proper Application Binary Interface and</div><div>can hang some libc onto it. And have an interface to other languages. AND use any </div><div>controller for which GCC has a back end. And have industry standard load files that can </div><div>used where ever.</div><div><br></div><div>To think that we must forever and in eternity use hand-crafted compilers that become, </div><div>after time, most difficult to maintain is to me plain religious lunacy.</div><div><br></div><div>So I am open to suggestions from the group. The GCC stuff must be done first. </div><div>The rest can be discussed over time.</div><div><br></div><div>Enjoy the summer holidays all.</div><div><br></div><div>j.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 16, 2018 at 10:02 AM, Diego Sardina <span dir="ltr"><<a href="mailto:dsar@eml.cc" target="_blank">dsar@eml.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Aug 16, 2018, at 9:23 AM, Tomas Kral wrote:<br>
> On Thu, 16 Aug 2018 08:38:04 +0200<br>
> Jan de Kruyf <<a href="mailto:jan.de.kruyf@gmail.com">jan.de.kruyf@gmail.com</a>> wrote:<br>
> <br>
> > The spirit of Edsger Dijkstra is still haunting us. 😠 Rational<br>
> > western man or not.<br>
> <br>
</span><span class="">> Modern trends usually are very complex, the spirit of Oberon is quite<br>
> the opposite, keep it simple minimal, and leave out the fancy.<br>
> <br>
<br>
</span>Just some days ago I (casually) found in my old hard disk an interesting<br>
paper by Hoare about language design, it's still available on the web:<br>
<br>
<a href="http://web.eecs.umich.edu/~bchandra/courses/papers/Hoare_Hints.pdf" rel="noreferrer" target="_blank">http://web.eecs.umich.edu/~<wbr>bchandra/courses/papers/Hoare_<wbr>Hints.pdf</a><br>
<br>
Briefly, Oberon fullfills all of Hoare's requirements:<br>
<br>
"A good language design may be summarized in five catch phrases: simplicity, security, fast translation, efficient object code, and readability."<br>
<br>
--<br>
Diego Sardina<br>
<div class="HOEnZb"><div class="h5">--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>