On 12/3/2014 9:21 PM, Guy Sotomayor wrote:
On 12/3/14 8:05 PM, Josh Dersch wrote:
On 12/3/2014 6:45 PM, Johnny Billquist wrote:
40 years ago would never dream of doing since
they would be thinking
of how this translates into machine code much more.
So in the end, with people getting less proper education, a stricter
language is our only hope. But for people who are good at
programming, the obstacles of stricter languages becomes annoying
and reduces productivity, for much less gain.
I've not found this to be true in my experience -- what "obstacles"
are you speaking of?
In the end, no one size fits all.
Agreed, but not for the reason you use above; if I'm reading your
statement right your sizes are: "C: for people who are good at
programming" and "stricter languages: for people who need help." No
one size fits all in that some languages are suitable for certain
tasks, and some are more suitable for others. The discussion here is
mainly that C is applied in many areas where it is not the best choice.
What is being missed in this discussion is that stricter languages (by
their very definition) tend to be
more complex and require more complex runtimes. Also remember that
the languages/runtimes are
also implemented in something and usually *not* the language that is
being presented, so the language
may present a somewhat less error prone environment to be written in
but it doesn't mean that the
compiler/interpreter/runtime are free from nasty bugs that show up in
strange and unexpected ways
that can be just as dangerous as the problems being discussed earlier
in this thread.
Sure, there are bugs in compiler/interpreter/runtime implementations,
just like anything else, but the benefit is that once the bugs are
worked out of that, then everyone benefits from that point on. e.g. the
Java Garbage Collector only has to be perfected once (for a reasonable
approximation of "perfected") whereas manual memory management in C or
Reference Counted objects C++ are implemented over and over and over
again by every developer who needs to allocate memory. Bounds checking
only needs to be implemented correctly once in the runtime, whereas in C
every time a developer makes a fencepost error when indexing into an
array, an exploit is born.
No language is going to prevent all bugs. Not all languages are
suited for all purposes. Yes, heavily
typed languages *help* in discovering bugs at compile time. However,
there are situations where
not having a heavily typed language is the proper choice. For example
I wouldn't try and write RTL
in Scheme or Go; I'd use Verilog or VHDL.
I think we're all in furious agreement on this particular point, and I
think it's the crux of the argument being made here for higher level
languages.
- Josh