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.
getting the majority to e good will require 3 million good developers.