Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!news.glorb.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail Date: Thu, 21 Jul 2011 16:38:00 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 Newsgroups: comp.lang.java.programmer Subject: Re: Arithmetic overflow checking References: <015aeb15-57db-48ab-9cd4-77f8448b632f@w24g2000yqw.googlegroups.com> <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 84 Message-ID: <4e288e2c$0$316$14726298@news.sunsite.dk> Organization: SunSITE.dk - Supporting Open source NNTP-Posting-Host: 72.192.23.157 X-Trace: news.sunsite.dk DXC=V<\8>BH?`d7IE=Lc_\oXE4YSB=nbEKnk;XjhVkob8B`6JPe3\kP5EU1KBm9cfh9BS4M2;kT<[:>[1;R2I\gZi?I9ef1ekjYXb44 X-Complaints-To: staff@sunsite.dk Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6348 On 7/21/2011 5:41 AM, Arved Sandstrom wrote: > On 11-07-15 11:00 AM, Patricia Shanahan wrote: >> On 7/14/2011 10:14 PM, MikeP wrote: >>> Patricia Shanahan wrote: >>>> On 7/6/2011 8:35 AM, rop rop wrote: >>>>> If I want to have arithmetic-overflow checking in all parts of an >>>>> application, >>>>> what is the most practical, simple, efficient way to achieve this? >>>> >>>> Write the application in Ada. >>>> >>>> Patricia >>> >>> But C# is very Java-like and has "checked" and also the compiler-level >>> equivalent, so C# would be the better alternative. (And yes, I do know >>> you were just kidding about Ada). >> >> No, I was not really joking, though I did not attempt to find all the >> languages that would meet the stated requirement. >> >> I'm very strongly of the opinion different languages should provide >> different features, making different trade-offs, and programmers should >> pick the language for a job based on its requirements and those features. >> >> The alternative a lot of programmers follow seems to be to pick one >> language, ignore all the others, and then complain when there is a >> mismatch between that language's features and their current requirements. >> >> I have no problem with pushing minor changes and additional features >> within the general framework of a language, but if the basic framework >> is not a good match for a job, the solution is to pick a language that >> is more suitable. > > I agree 100 percent. > > I'll add this observation: this state of affairs is largely a result of > the mediocrity of most programmers. The pressure to conform to a very > few mainstream languages - and there is real pressure to this effect, > unless you are dabbling, or are in some odd niche - may come from > managers, from business, from customers, or from developers themselves - > ultimately stems from this pervasive mediocrity. And this state of > affairs will not change so long as software development remains > unprofessional. > > How many languages should be in a programmer's toolkit? Well, at least > half a dozen. Preferably a dozen. These would be languages that cover > the entire spectrum, and that the programmer is at least competent in. > > To add insult to injury you don't even often see most mainstream > programmers taking advantage of the realistic constrained possibilities > offered by real-world working environments. For example, developers who > usually will find themselves working with .NET on the CLR, or Java SE/EE > on the JVM. The C# programmers don't often consider that maybe judicious > interop with some F# code will be a better solution, or that they could > contemplate IronRuby on the DLR, and you don't often see enterprise Java > programmers (or their bosses) willing to think of using some Scala or > Clojure or Groovy. And the practise of taking advantage of one's larger > platform, and writing shell or Powershell scripts (or Python or whatever > programs) to handle other tasks connected with a larger project in Java, > is both frowned upon and rare. > > The blanket excuse used to justify all this is standardization of > skillsets. Although candid hirers and managers will tell you that this > is mandated by widespread mediocrity. They acknowledge that a very good > programmer does do better if they can choose their tools, but they are > worried about the ability of 90 percent of the developers out there to > maintain and extend the code that the good programmers write. > > This is the real world, and it'll take a long time to change it. You can hardly blame the managers from making decisions on tools based on what their developers actually know instead of what they should know. mediocre developers => mediocre code But if we say that there are 10 million developers of which 2 million is good, 6 million is mediocre and 2 million is hopeless, then just getting the majority to e good will require 3 million good developers. They will not show up tomorrow by magic. Arne