Typesafety versus Worse is Better - was Re: Fwd: is there any word processing software for the pdp11?
derschjo at gmail.com
Wed Dec 3 23:45:19 CST 2014
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
More information about the cctalk