<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div> I find myself on the other side of this. </div><div> There are many people on both sides. </div><div><br></div><div> There are countless examples. </div><div><br></div><div><br></div><div> Here are two. </div><div><br></div><div><br></div><div> People don't like operator loading. </div><div><br></div><div> They don't want me to write </div><div><br></div><div> string operator+(string, string); </div><div><br></div><div><br></div><div> but nobody seems to mind: </div><div> </div><div> </div><div> float f = 1.0 + 2.0; </div><div> int i = 1 + 2;</div><div><br></div><div> why is + ok on floats and ints, overloaded, but not user defined types such as string?</div><div> </div><div> </div><div> People don' t like type inferencing. </div><div> </div><div> auto a = 1.0 + 2.0; </div><div> auto b = 1 + 2; </div><div> </div><div> Modula-3 has this more than C and C++98 already, so maybe people here don't mind. </div><div> </div><div> VAR a := 1.0 + 2.0; </div><div> VAR b := 1 + 2; </div><div><br></div><div> In either case, nobody seems to mind temporaries without explicit types in function calls or more generally subexpressions. </div><div><br></div><div> F(1 + 2); </div><div> F2(1.0 + 2.0); </div><div><br></div><div><br></div><div> - Jay</div><div><br></div><div><br></div><div>> Date: Tue, 28 Jun 2016 22:15:25 +0200<br>> From: wagner@elegosoft.com<br>> To: rodney.m.bates@acm.org<br>> CC: rodney_bates@lcwb.coop; jay.krell@cornell.edu; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] cm3 llvm backend?<br>> <br>> On Tue, 28 Jun 2016 11:40:06 -0500<br>> "Rodney M. Bates" <rodney_bates@lcwb.coop> wrote:<br>> <br>> > On 06/27/2016 08:03 PM, Jay K wrote:<br>> > > > A teacher of mine called this behavior "version junkie".<br>> > ><br>> > ><br>> > > There are at least two big reasons for this.<br>> > ><br>> > > - The language really is improving. Programs<br>> > > written in the newer language are easier to read<br>> > > and often easier to optimize and sometimes easier<br>> > > to implement a compiler for.<br>> > <br>> > Sometimes so, sometimes not. Sadly, many language "features" reflect<br>> > an implicit but very misguided belief that fewer keystrokes/characters<br>> > means increased readability. Or at least that writability is more<br>> > important than readability. So often, this means actual code is less<br>> > explicit. But this makes maintenance far worse.<br>> > <br>> > E.g., Ada decided use parentheses for both actual parameter lists to<br>> > function calls and subscript lists to arrays. Along with optional<br>> > implicit operations like dereferencing, there are somewhere in the<br>> > teens of possible meanings for the innocent looking "f(x)". I have forgotten<br>> > the exact number, but once had to do the semantic analysis. That was<br>> > Ada 83. Maybe more have been added since. For the poor schmuck who<br>> > gets called at 3:00 AM to fix a bug in half a million lines of code<br>> > she didn't write, this is a readability disaster. The savings of<br>> > keystrokes in not making the operations explicit is penny-wise and<br>> > million-pound foolish.<br>> <br>> I couldn't agree more with this. My focus seems to have moved away from<br>> programming to reading and analyzing code, too. Often it is almost next<br>> to impossible for me to find the exact meaning or definition of an<br>> expression or call without knowing all the other code which is not<br>> obviously related to the location in question.<br>> <br>> I would favour longer explicit syntax and clear meaning above<br>> shorter expressions any time.<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com <br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br></div> </div></body>
</html>