<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez <<a href="mailto:apalala@gmail.com" target="_blank">apalala@gmail.com</a>> wrote:<br>
> Then, if exceptions are going to be part of a type, there should be a way to express the semantics of them (like in Eiffel), so stack.pop();stack.push(x) doesn't have to catch StackFullException.<br>
><br>
<br>
That assumes atomicity. If you want an atomic "replace top of stack"<br>
that can never raise StackFullException, it's probably best to express<br>
it as stack.replacetop(x) rather than having something that might be<br>
interrupted.<br></blockquote><div><br></div><div>Ah! What to do with an exception in a concurrent context? Abort, or retry after a while?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">People do dumb things with exceptions, yes. Why does this mean that<br>
they are bad? I don't understand this. Exception handling (and stack<br>
unwinding) gives an easy and clear way to refactor code without having<br>
to daisychain error handling everywhere. How is throwing that away<br>
going to help people write better code?<br></blockquote><div><br></div><div>For programs that are recursive or multi-layered, exceptions are a clean and efficient way to unwind. </div><div><br></div><div>This PEG parser generator I wrote was made possible because Python exceptions are semantically clean and very efficient: <a href="https://github.com/neogeny/TatSu/blob/master/tatsu/contexts.py">https://github.com/neogeny/TatSu/blob/master/tatsu/contexts.py</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
But then, Golang also decided that Unicode wasn't necessary, and we<br>
should all deal with UTF-8 encoded byte sequences instead of text<br>
strings, so I'm fairly sure there are no ten foot barge poles long<br>
enough for me to touch it with. There are languages that have problems<br>
because of history (*cough*JavaScript*cough*), but for a new language<br>
to make multiple poor decisions just means it's one to avoid.<br></blockquote><div><br></div><div>The quest for a programming language in which _"anyone"_ can program, _without_ making mistakes, has never ended, and probably never will.</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div class="gmail_quote">"Alexa! Please write the software for a new Internet email system that overcomes the limitations of the current one!"</div></div></blockquote><div><br></div><div>Sometimes staying away is not an option.</div><br><div dir="ltr">-- <br><div dir="ltr" class="gmail_signature"><span style="color:rgb(0,102,0)">Juancarlo </span><b style="color:rgb(0,102,0)">Añez</b></div></div></div>