[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!
crossd at gmail.com
Fri Sep 1 13:12:41 AEST 2017
On Thu, Aug 31, 2017 at 9:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> > > On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > > So what chaps my grumpy old hide is why the heck do a whole new
> > > when you have one that is pretty good? Suppose we took C and added a
> > > dialect via options:
> > >
> > > --no-ptrs // use arrays and indices, you get bounds checking
> > > --strings // system managed memory for strings, like tcl
> > > --perlisms // if (buf =~ /re/) and unless (it_worked())
> > Such a language would stop being C.
> Indeed. But it builds on C.
Not only would such a language be C-based but not C, it would beg the
I saw a very interesting presentation a few months back by someone on the
C++ standards committee. He was describing *how* the standards process
works, but at one point described some of the upcoming features. If I
recall, one proposal was to add list comprehensions, more or less because
"Python has them." I couldn't resist asking in the Q&A, "Why?" The idea
being that if I want Python, I know where to get Python (or Haskell, for
that matter). Why does every language need to evolve to be every other
language and in so doing grow into an uncontrolled and uncontrollable mess?
I wasn't trying to be confrontational (I phrased my question somewhat more
politely than what I just wrote here) but the answer was a tad defensive.
As I recall, something along the lines of, "well, that's what the kids
coming out of schools that teach Python expect these days, and we need them
to stay relevant." I don't find that particularly compelling: languages are
kind of like tools, and as such, often serve different purposes. If I want
to solve a problem that is best suited to C, then I'll use C; if I want to
solve some problem that's best suited to a different language (stronger
type system, a richer set of built-in abstractions, first-class concurrency
primitives, etc) then I'll reach for that instead. Why is that
controversial? If I want to drive a screw, I reach for a screwdriver, not a
Anyway, I for one am perfectly content for C to remain the high-level
assembler that it mostly is. Call me a heretic, but I don't particularly
want to write large programs in it anymore. That said, I also don't want it
to grow too large, because then it makes it harder to use for low-level
things. For example, I'm a little nonplussed about thread support in C11:
what if I want to work in a world where a pthread-like thread isn't the
concurrency model? Similarly with the semantics around atomics. Is
compliance with the language standard going to force something on me that
makes it hard to experiment with new ways of doing things?
Anyway, I like the idea of multiple languages that occupy different niches.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS