
45 years since its creation. The C language still very popular - kiyanwang
http://www.javadepend.com/Blog/?p=2372
======
hyperpape
Every so often, I think about the meme of the 100 year language. The idea is
that we need to start working towards the languages we'll use in 100 years.
Instead, I wonder how many we already have.

Fortan: 59

C: 43

C++: 33

Python: 25

Php: 21

Javascript: 20

Java: 20

It's still a long time until any of those languages reach 100. But longevity
seems to be the rule, not the exception. How many languages that were
widespread actually died?[0] I don't pretend to know all the languages that
have ever been popular, but not many that subsequently died come to mind.
Cobol, maybe some lisp dialects, if you don't count Common Lisp as their
successor? Is PL/1 dead? Was APL big enough to make the list?

Probably some of the languages I listed above will die before they're 100.
Others might be niche, like Fortran already is. But I wouldn't guarantee it.

[0] Where dead doesn't rule out someone being paid to maintain ancient code.
By that standard, it's unclear whether anything will ever die
([https://www.snellman.net/blog/archive/2015-09-01-the-most-
ob...](https://www.snellman.net/blog/archive/2015-09-01-the-most-obsolete-
infrastructure-money-could-buy/))

~~~
philwelch
Pascal is a good example of a dead language that used to be fairly popular.

~~~
analognoise
Join us: [http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)

Pascal isn't dead! Native binaries produced (much less garbage overhead), fast
compilation, kick-ass open source IDE and standard library, cross platform,
free (as in freedom, as well as beer).

JOIN US.

~~~
philwelch
Wow, I stand corrected. Lazarus is a great name though since it calls out the
fact that Pascal _was_ dead ;)

~~~
analognoise
Yes, it was dead. Now though... please try it. You'll be impressed.

------
rm_-rf_slash
C is the Latin of programming languages. The general syntax is easy to learn
and communicates well across derivatives as diverse as Java and and Ruby.
Before I learned Lisp and Haskell, I didn't even think non-C-style syntax
existed.

~~~
njharman
Forth and Prolog are diverse. Ruby and Java are not. They are both algol (C)
derived syntaxes. People only think they are much different because the lack
exposure to languages from other (or no) heritages.

~~~
rm_-rf_slash
It doesn't matter how diverse the syntax is, just think of the vastly
different worlds of people programming in C derived syntaxes:

The enterprise app developer writes Java for her day job, and spends her
nights creating iPhone apps in Objective-C. Her apps connect with an API on
the website she built using Ruby on Rails, and handles front-end interaction
in JavaScript.

All four languages are syntactically similar, but each has vastly different
application domains.

~~~
njharman
Do you anything about Forth and Prolog and the languages you mention? Three
are the same paradigm, the other two are very much not. This has nothing to do
with syntax or "application domains".

------
yoodenvranx
I admire C for everything it teached me about programming, but nowadays I
actually hate writing it.

For all my personal projects I switched over to Python years ago because I
just don't want to waste a single more minute dealing with basic stuff like
strings in C.

I love the batteries-included mentality of Python because it lets me
concentrate on implementing actual solutions to my problems instead of
fighting against the build system or reliably converting strings into
integers.

If there would be some kind of batteries-included version of C then I would
certainly look into it again, but for now Python is just my preferred tool to
get stuff done.

(yes, C++ is better in this regard than C, but it is still to cumbersome for
my use case of rapidly playing around with new ideas).

~~~
krisdol
Hmm... Rust might be in that ballpark. Certainly more "batteries included"
than c and at about the same level of abstraction overall. It depends of
course on how cumbersome you consider the ownership system

~~~
yoodenvranx
Rust is on my Todo list!

At the moment I do a lot of image and audio processing via SciPy/matplotlib
and I think that Rust is lacking in that department at the moment.

------
blueatlas
C should be the defacto language for 1st year CS students. It is not highly
abstracted from hardware, and much easier to grasp Assembly knowing basic C.
The syntax uptake is pretty quick, and would allow students to focus on the
problem at hand (e.g. algorithms) rather than language nuance. Not to mention
the advantages to the graduate starting their career in software development.

It's also easier to go up the stack to object oriented languages, particularly
Java. The second chapter, first edition, of David Flanagan's Java in a
Nutshell is still, in my opinion, the best intro to Java after having some
experience with C.

~~~
pcwalton
> The syntax uptake is pretty quick, and would allow students to focus on the
> problem at hand (e.g. algorithms) rather than language nuance.

I don't agree. What's the benefit in having to painstakingly write trivial
string operations using string.h and manually allocated buffers? What's the
benefit in learning the ins and outs of undefined behavior?

~~~
guyzero
"What's the benefit in learning the ins and outs of undefined behavior?"

To force people to learn that making assumptions based on undefined behaviour
is dangerous and that computers are not mind-readers.

And you force people to write buffer manipulation code so they realize how
good people using other languages have it.

~~~
CJefferson
Except, undefined behaviour seems like mostly a C, and C derivates, concept.

I teach C, and every year I have a number of students nearly in tears, because
somewhere in the huge program they accidentally malloced sizeof(T*) instead of
sizeof(T), but of course that causes a crash 10 minutes later in a totally
different piece of the code base.

My hope (it's not quite there yet, but getting closer) is that things like
clang's sanitize modes will reach a point where any undefined behaviour
immediately causes an abort. Then students can still figure out what they did
wrong, but have a chance of finding the source of their bug.

~~~
9248
Speaking as a past student I'm really glad I started with C.

In the beginning, the fear of getting some random Segmentation fault out of
nowhere actually taught me more than any textbook, school or best practices
blog could ever do. It also forced me to learn how to use debuggers :)

~~~
CJefferson
That's what I tell my students, it's "character building", in the same way
playing sports in the rain was as a child for me.

Also, many students previously did a course on Java, and clearly never really
understood the basics, it's much easier in Java to play "keep tweaking and
fixing the exceptions until it works, then don't touch it", particularly for
introductory-level projects.

------
fauigerzigerk
C was my first language, but I hadn't used it (outside of C++) for a long
time. In recent days it suddenly crashed my little "use new cool languages for
the heck of it" party.

I was experimenting with Swift, trying to make it fit my rather
performance/memory critical string processing needs. As it turns out, you can
use C code from Swift about as easily as you can use Java code from another
JVM language.

So I implemented a variant of the short string optimization in a few lines of
C code. It's amazing how well C fits the bill as a lingua franca for code that
does questionable things to bits and/or is meant to be used from other
languages.

There's very little competition for C in that role.

------
throwaway2016a
I love working with C. The power it gives me allows me to write hyper-
optimized applications in terms of memory usage. Using it we process terabyte
files ridiculously fast using less than 1K of non-program memory.

However, when I don't need to hyper-optimised it is not my first choice due to
being way behind other in languages in terms of package management and I'd
rather not deal with pointers if I don't have to.

~~~
pnathan
Have you looked at Rust? It is very good for those design cases.

~~~
throwaway2016a
Rust is definitely on my list of things to learn. I haven't gotten around to
it, unfortunately.

------
pcwalton
> [referring to Microsoft Word 1.1] It seems that this code is from a C
> project created recently in GitHub. No sign that’s a code from 25 years ago.

I wouldn't necessarily say that. At a glance, there are some questionable
idioms: assignment inside a function argument (especially problematic since
argument evaluation order is unspecified), old-style argument declaration, a
custom Boolean type, less-than-descriptive variable naming, etc. I wouldn't
let any of that pass code review today. :)

> The power of C is its stability over years, it remains basic, no advanced
> mechanism was introduced to the language, the code still simple to
> understand and maintain.

Not when you take the arcane undefined behavior rules into account. C
semantics are anything but simple.

~~~
gajjanag
> Not when you take the arcane undefined behavior rules into account. C
> semantics are anything but simple.

Maybe, but note that simplicity should be viewed in a relative sense.

I am curious as to which language you think has simpler semantics than C. For
example, I have not found Python, Julia, MATLAB, C++, Verilog, or shell script
simpler than C. Same goes for my initial explorations of Rust.

Even if one includes the arcane corners, the spec is < 200 pages (excluding
the stdlib).

~~~
pcwalton
If you don't count the unsafe sublanguage, Rust, SML, OCaml, Scheme, Java, and
Lua all have simpler semantics than C, and that's just off the top of my head.
It's debatable, but I would even argue that Haskell and Swift do. Undefined
behavior is really subtle, and there are parts of the spec that compiler
developers haven't even come to consensus regarding the meaning of.

~~~
tikhonj
Standard Haskell (ie Haskell 2010[1]) certainly is. Most of its features are
just syntax sugar over a tiny core language with simple (although not 100%
formalized) denotational semantics. The language itself isn't very big and
it's pretty well-specified.

GHC Haskell with all extensions... euh, I don't know. Many extensions are
either syntactic sugar or straightforward changes to the base language,
sometimes even making it simpler. But I'm not confident about _all_ of them,
and I'm not sure how the semantics of some low-level libraries (ie for
concurrency) work out.

I've written code in essentially just the standard subset and it's a pleasant
language—there aren't any extensions that you absolutely must use in real
projects. That said, people use lots of them anyhow because most make the
language _nicer_ without adding too much complexity.

Since the extensions aren't organized in a unified way and have to be split up
(since they can generally be enabled or disabled independently), it's hard to
figure out how complex they make the semantics of the language as a whole.

[1]:
[https://www.haskell.org/onlinereport/haskell2010/](https://www.haskell.org/onlinereport/haskell2010/)

------
elliotec
C is nearly inaccessible to me. It really is like the Latin of programming
languages, insofar as JavaScript is the new English of programming languages
which is the world I have been living in for some time now.

Its like you can see the Latin roots of a lot of English, but reading it is
like reading lorem ipsum. Same with C vs. JS with me.

~~~
derekp7
Just out of curiosity, which elements make C inaccessible compared to other
C-like languages? The base structure is identical to the later derivatives
(if/else, for, while, operators and precedence, use of curly braces). Is it
the manual memory management (malloc/free)? Or is it keeping aware of a
variable's data type, knowing when and when not to use pointers and
references? Or is it the limited number / scope of functions included in the
standard libraries? (I'm mainly curious, as C seems to be the most comfortable
language to me since I've known it for the last 25 or so years).

~~~
elliotec
> Is it the manual memory management (malloc/free)? Or is it keeping aware of
> a variable's data type, knowing when and when not to use pointers and
> references?

Yes, both I think. These are ways of thinking that simply don't seem to apply
in JS or any other dynamically typed higher level language.

Also, just sort of the conventions of naming things, like malloc or memcpy or
in the example of the article, all those crazily shortened abbreviations that
may just be saving bits or the developers style, but make it very unreadable
for me. I'm used to stuff like:

    
    
        function getDataFromServer(){
          var data = response
          //blah blah etc
        }
    

and it may just be a thing that you have to get used to with experience, but I
can read and write Python, Ruby, JS, Clojure and other lisps, and have
experience with C#, but something about C I just struggle with, and I wish
that wasn't the case.

~~~
asynchronous13
I'll agree that memory and type issues are more of a barrier, but the variable
naming is just convention of the programmer. There is a lot of legacy code
where brevity in naming was emphasized, but that was just the convention of
the time, nothing inherent in the language. it doesn't need to be that way.

Your example looks like completely valid C code to me (except for the lack of
semi-colon).

~~~
elliotec
oops. Thanks for calling me out on the semi-colon. I also forgot to pass
response as an argument. I should be ashamed of myself. Must've been late.

------
michaelwww
I will go to my grave loving C, from that first day when I read about it in
Byte magazine as the high speed language of every new exciting computer
application, to the day when C++ took over and began to assert it's high
falutin notions of what a language should be.

~~~
prewett
I can't help myself from rewriting your post, it's so close :)

I will go to my grave loving C, from that first day when I read() about it in
unsigned char magazine as the high speed language of every malloc() exciting
computer application, to the day when C++ took over and began to assert() its
high falutin' notions of what a language should be.

~~~
rbonvall
I loved it, let me add:

    
    
        I will goto my_grave loving C, from that day[0] ...

~~~
prewett
I knew I was missing something, nice!

------
alistproducer2
One of my favorite jokes on HN was in a typical language wars thread where a
guy wrote "real men write in C....without the standard library." That still
makes me laugh.

~~~
rat87
Obligatory link to the Story of Mel:

[http://www.catb.org/jargon/html/story-of-
mel.html](http://www.catb.org/jargon/html/story-of-mel.html)

~~~
andreapaiola
Ah! I've thought instead to MEL (ancient Maya scripting language)

------
jasonpeacock
My manager (a long-time-ago former dev) once told me:

"I can write C in any language."

And it's true. He could write beautiful C code in Perl, Java, Ruby, etc -
whichever language the current project was using - when he needed to hack
something (usually gathering data for business metrics).

~~~
codemac
We used that quote as a joke for not learning new languages well enough. Do
you mean that he would write C and link it to each implementation?

~~~
jasonpeacock
He'd just stick to the basics and write C-style code in the given language, he
had no knowledge of any of the language idioms and didn't need them if he kept
his code simple enough.

Basically only using if/for/while and function/return constructs.

It was strange to open a Perl script and see "C" code, with single-letter
variables (declared at the top), etc.

~~~
gbrown
In some languages (e.g., R), the performance penalty for such code is
enormous.

~~~
disgruntledphd2
Yes and no. While typically vectorised code will run faster than a loop
(because its a loop in C) i.e. rowSums is faster than a typical apply call,
there actually isn't that much difference between a for loop over columns to
sum and apply over columns to sum.

The real performance penalty is growing objects as you go. If you preallocate
a list or vector of the appropriate length, then there typically isn't much
difference.

That being said, you'll pry lapply(x, fun) from my cold dead hands (lapply(x,
function (x) g(f(x)) is even better :) )

------
jcadam
I learned C via this excellent book:
[http://www.amazon.com/dp/067230399X/?tag=stackoverfl08-20](http://www.amazon.com/dp/067230399X/?tag=stackoverfl08-20),
which I picked up from a local bookstore on a whim. I had just started high
school, and up until that point my programming experience had been limited to
BASIC-type languages (starting with Apple ][ basic when I was 6, then AMOS on
the Amiga 500, then QBasic on DOS... actually that last one was a bit of a
downgrade from AMOS :) ).

C was my introduction to "real" programming -- it forced me to actually learn
memory management, pointers, etc. Funny thing, I only took one C course while
I was in college. By the time I started college, Java was the new hotness, and
I was in the first incoming freshman class to get Java instead of Pascal in
our introductory programming course. I took an immediate disliking to Java
back then (and still don't like it), so naturally it's the language I have to
use at work :O

------
gravypod
C has kind of become the evident defacto standard. There isn't anything we can
really do to change that. It just did what it was meant to do very well with
all of the flashy bells and whistles removed.

The underlying instructions generated by the compilers are simple to follow.
Reasoning about what will be generated is an easy enough task (so long as
optimization is turned off).

------
pjmlp
"Although the first edition of K&R described most of the rules that brought
C's type structure to its present form, many programs written in the older,
more relaxed style persisted, and so did compilers that tolerated it. To
encourage people to pay more attention to the official language rules, to
detect legal but suspicious constructions, and to help find interface
mismatches undetectable with simple mechanisms for separate compilation, Steve
Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned
a set of files and remarked on dubious constructions."

[http://www.netzmafia.de/skripten/unix/chist.html](http://www.netzmafia.de/skripten/unix/chist.html)
\-- Dennis M. Ritchie

------
kensai
Lua + C == welcome to C in the 21st century. :)

Seriously enough, Lua adds all those scripting high-level aspects that are
missing from C. I know it's another language but its interplay with C gives
strength to both of them. A good alternative of the C + Lua paradigm is of
course Python.

~~~
fanf2
Tcl + C == welcome to C in the 1990s :-)

------
cm2187
Most popular and most used are not exactly the same thing. Half of the
population pay their taxes, I don't think one can claim taxes are very
popular.

------
komali2
My first serious introduction to programming was through Harvard's online
CS50x course, which uses C. I think it was a fantastic way to introduce a
newbie like me to what programming languages are doing under the hood with
memory allocation, pointers, value vs ref, etc.

------
peter303
You can backpropagate "modern" CS techniques like modularity an encapsulation
to most ANY language like C or LISP or FORTRAN. But if have language and
compiler support for these, it makes it easier and more reliable.

~~~
gp7
Encapsulation is done better and is easier to manage in C than it is C++.

~~~
ArkyBeagle
Yes. I have entire code bases where the interface to a "capsule" ( because en
_capsul_ ation, see :) is one function with void parameter and void return.

Of course there's a central data store. But that's okay.

~~~
nickpsecurity
That's funny about capsules. More consistent when people discuss
encapsulation, though. Far as OOP in C, it's definitely doable with quite a
few approaches and even books dedicated to it. Example:

[https://www.cs.rit.edu/~ats/books/ooc.pdf](https://www.cs.rit.edu/~ats/books/ooc.pdf)

Many think C++ with its benefits and problems are relevant to OOP in C but not
entirely. That's because they think C++ was about adding OOP to C. It wasn't.
Stroustrup used safe, OOP languages like Simula that he wanted more of. He
intended to leverage C's popularity and tooling but transform it into
something with benefits of other languages. So, the result is C-like but not
quite C and complex.

Just doing OOP in C, on other hand, is much easier and cleaner problem to
solve. ;)

------
georgeglue1
Also note that nearly every computer science or electrical engineering grad of
the last 30 years has taken multiple courses in C.

This obviously gives it a big leg up for employer demand, etc.

------
witty_username
> The C language still very popular

The C language is still very popular

------
sverige
Hey, now hold on a minute. Are you people telling me that there are languages
people actually use other than C !?

------
ape4
Why would it go away? We still need to write low-level or fast applications.

------
enjones
No school like old school!

