On 2012.5.20 4:40 AM, Peter da Silva wrote:
> Smalltalk was also not low level enough to be used as an alternative to C.
> It wouldn't even fit in the PDP-11 they started with.
Never claimed it was.
>> The list was done evaluating C as a language we use and are heavily
>> influenced
>> by in 2012.
>
> And why is that? Why hasn't anything that's _genuinely_ better caught on?
Just because something is the default, or even a category killer, doesn't mean
it doesn't have some glaring faults. We should particularly look our defaults
straight in the eye and ask if we're using it because its great or because its
what we know. Understanding your tools flaws is as important as understanding
its strengths.
I'll have a go though.
The first is "the enemy of the best is good enough" and C was good enough...
for a time. It solved a problem (portable machine programming) better and
faster than its contemporaries and even much later languages.
The second is longevity. It's only been in the last ten years that hardware
has become so cheap and powerful that we no longer have to be concerned with
performance at every level (alternatively, that CPU and memory are no longer
the bottleneck). Thirty years is a long time to get entrenched and have the
entire industry wrap itself around a technology.
The third is distraction. For some reason every language which started out to
replace C gets distracted by dreams of being an application language. I'm
thinking Java (was originally supposed to run on set top boxes), Objective-C
and C++ It is particularly curious that we haven't had a serious attempt in
thirty years. There's something about writing a pure system programming
language that invites distraction.
The fourth is that for 99% of developers, C is not an issue. They've "solved"
the problem of C by writing in higher level languages and leaving it to a
handful of others to worry about writing their language or tool in C. There's
no great drive to fix the problem, for most folks it isn't a problem. This
isn't necessarily the most healthy way to manage your technical development,
see also IPv6.
Fifth, I think there's a broad overlap between "people who want to write at
the system level" and "people who want to be really close to the hardware", C
fits this mentality. The longer the two are wielded together, the more the
system programming community will think in C.
This is a personal observation, folks to code C like details of bits and
registers and hardware details and such. They like to feel in total control
(even if an advanced compiler means they're not). If your system language
tries to abstract this, a lot of systems people won't touch it. Myself? I'd
like to be able to work my languages and operating systems and databases
without having to care about hardware. But C won't let me do that, so I
ignore system programming.
Finally, C has a TOTAL lock on the subject. Application programming has
always been multilingual, and ready to accept new languages, but systems
programming is nothing but C. None of the disruptive technologies which have
created new niches for application languages (mobile, web, desktops, cheap
RAM, cheap CPU, Unicode, new operating systems, multiple CPUs, corporate power
plays) seem to be creating the new niches at the system level. Maybe they
just don't have as big an impact. Maybe system programmers are used to their
language being kinda clunky. Maybe C is just very adaptable because their
standard features and libraries are so slim. Probably a bit from all that.
It's very difficult to get a break in a decades old monoculture.
--
s7ank: i want to be one of those guys that types "s/j&jd//.^$ueu*///djsls/sm."
and it's a perl script that turns dog crap into gold.
