how relevant is C today?

[Mirco Wahab]

Hi Scott

your summary looks very concise and
good to read. I'd like to make some
minor additions,

C can express neither exceptions nor coroutines (nor their fancy cousin,
continuations), which could be and were expressed in assembly. Nor does
C provide memory management. A few library functions give you some
primitives to roll your own, but garbage collection is out of the
question (despite Hans Boehm), because the language does not carry
enough infrastructure to find type information through introspection.

So, al-imho, C 'abstracts out' some consistent
'von-Neumann' or 'Harvard-' machine from any
architecture where its ported to. And that
is - imho - the main strength of C.

It covers well most machine code vs. C instruction mapping (~1:1),
and RAM storage vs. coressponding data representation (1:1),
as you said partially.

It can't handle any aspect beyond these simple
mappings in its language core, this is where
more complex bulding blocks (libraries) will
come into play.

In exchange for these losses, the C programmer can write code that
executes in response to an external signal and yet does not create a
total hash of the internal memory structures. That kind of thing is
important in an OS, and something few languages (including C++) can do.
If you intend to study C++, study C first (it is easier to grasp), as
almost everything you learn in C can be used in C++. C++ is a "big"
language, while C is a "small" one; it will take much longer to "know"
C++ even though C++ started with the goal of being "C with objects."
If you are interested in languages, reading "the Design and Evolution
of C++" is a great base; it explains how C++ got the way it is from its
initial design goals.

I would say, from my own experience, that you wouldn't
use all C++ features in all C++ projects. Most people
I know would write C programs 'camouflaged' as C++,
that is: write clean & simple C - and use some C++
features e.g, class bound methods for interfaces -
but no inheritance at all (use compound objects) and
no exceptions (handle errors 'the olden way').

Regards

M.

 

[David Rasmussen]

I would say, from my own experience, that you wouldn't
use all C++ features in all C++ projects. Most people
I know would write C programs 'camouflaged' as C++,
that is: write clean & simple C - and use some C++
features e.g, class bound methods for interfaces -
but no inheritance at all (use compound objects) and
no exceptions (handle errors 'the olden way').

Of course. C++ is a hybrid language by design, not only an object
oriented language, not only a language with exceptions, not only a
language with compile time metaprogramming etc.

You don't have to use all the features of C++ to make a real C++
program. Even for writing C programs, C++ is still a better choice (in
my opinion). If you want to, you can keep things "simple", and plain
C-ish, and still benefit from better type safety etc.

In my everyday work, I am forced to use a C90 only compiler, and
everyday I miss some C++ feature that wouldn't make my program any more
complex, quite the opposite. These are features like "const", no default
extern linkage, more typesafe enums etc. You can put upon yourself to
program in a C style, but whenever you miss something, you can always
wrap that up behind an abstraction such as a class etc., and still
maintain C-like semantics.

Say I wanted an Ada-like integer type that only runs from 1 to 100. I
could make such a beast in C++, and then use it just as an ordinary int
in my C style program. I could even make this beast _be_ an ordinary int
in release builds when I was sure (yeah right) that the code was
bugfree. This gives expressibility and preciseness in specification. You
let the compiler do the work for you. And you still maintain
performance. You can't do this in C at all. And there are a million more
examples.

In practice, the combination of Python and C++ covers most of what I
need to do in most situations. But I still wish that C++ offered a lot
more of those zero-overhead features that it might as well offer, that
the compiler just as well can do. It could learn from Ada in this regard.

/David

 

[John Salerno]

At which level in the 'python challenge' did
you get stuck - and why?

Ugh, don't remind me!

I'm stuck on level 12, which is yet another image processing puzzle. I'm
getting tired of those, and I think it's really a shame that there is a
reliance on image puzzles rather than simply doing some coding to figure
out an algorithm, for example. (I really enjoyed writing my own function
to figure out the Morris sequence.)

Level 11 was an image puzzle that I flat-out cheated on to move forward,
and now here I am again at 12, another complex image puzzle, and I can't
find the answer for it. If anyone feels like emailing me with the
solution, I certainly won't be offended.

I just hope that later puzzles stop relying on PIL and start requiring
that you do some real coding with other modules, or even with just the
core language itself.

 

[gregarican]

Here are a few languages I recommend most programmers should at least
have a peek at:

1) Smalltalk - The original object oriented programming language.
Influenced anything from Mac/Windows GUI to Java language. Terse, clean
syntax. IDE rolled into an operating system rolled into a set of core
libraries.
2) Lisp - Along with FORTRAN, one of the oldest programming languages
still in use. Pure functional programming model that is extensible and
has many derivatives. Great for mathematical purposes. Easy to learn if
you can get past all of the nested parenthesis
3) C - The "Latin" of modern programming languages. Used in low level
tasks (e.g. - hardware drivers) as well as larger projects (e.g. -
operating systems and other programming languages). Logcal, explicit
flow albeit a bit wordy.

I have worked in C and Smalltalk for awhile now and just starting to
pickup Lisp. Knowing different languages can help you approach problems
with a fresh perspective. I prefer to code in Ruby and Python but can
use these languages a certain way given the angles I have picked up
elsewhere...

 

[Roy Smith]

Here are a few languages I recommend most programmers should at least
have a peek at:

1) Smalltalk - The original object oriented programming language.
Influenced anything from Mac/Windows GUI to Java language. Terse, clean
syntax. IDE rolled into an operating system rolled into a set of core
libraries.
2) Lisp - Along with FORTRAN, one of the oldest programming languages
still in use. Pure functional programming model that is extensible and
has many derivatives. Great for mathematical purposes. Easy to learn if
you can get past all of the nested parenthesis
3) C - The "Latin" of modern programming languages. Used in low level
tasks (e.g. - hardware drivers) as well as larger projects (e.g. -
operating systems and other programming languages). Logcal, explicit
flow albeit a bit wordy.

I have worked in C and Smalltalk for awhile now and just starting to
pickup Lisp. Knowing different languages can help you approach problems
with a fresh perspective. I prefer to code in Ruby and Python but can
use these languages a certain way given the angles I have picked up
elsewhere...

I would add to that list PostScript. Most people think of it as just
format for print files, but it's a a real general-purpose programming
language, and a cool one at that (with an clear similarity to FORTH). The
stack-based paradigm can be a bit mind bending if you're not used to it,
but bending your mind is the whole point of learning something new.

 

[Ray]

Ugh, don't remind me!

I'm stuck on level 12, which is yet another image processing puzzle. I'm
getting tired of those, and I think it's really a shame that there is a

This is EXACTLY why I am still stuck on level 12 for many months. The
first few ones are fun. That sequence thing is also particularly fun.

But after a while, it seems that it's an image after image after image
after image. I just got sick of PIL

<snip>

 

[Lawrence D'Oliveiro]

In my everyday work, I am forced to use a C90 only compiler, and
everyday I miss some C++ feature that wouldn't make my program any more
complex, quite the opposite. These are features like "const", no default
extern linkage, more typesafe enums etc.

"const" is in C89/C90. As for the others, how about hiding a copy of GCC
somewhere, just to use to preflight your code before actually building
it with your compulsory broken compiler?

 

[Lawrence D'Oliveiro]

Can anyone shed some light on the secret of Java?

Java and C#/CLR I class as "instant-software-bloat-just-add-water"
technologies. That is, they are very popular in corporate circles, where
the users don't get to choose what software they're running.

 

[Thomas Bellman]

"const" is in C89/C90.

Although with slightly different semantics from in C++... For
instance:

static const int n = 5;
double a[n];

is valid C++, but not valid C.

 

[Azolex]

Can anyone shed some light on the secret of Java? How is it that they
are so high on this list?

Sun invented a roundabout strategy to enroll programmers to Java by
first attracting the attention of the Wall Street Journal with Hotjava,
and thus the attention of the programmers' management.

 

[bruno at modulix]

Here are a few languages I recommend most programmers should at least
have a peek at:
(snip)
2) Lisp - Along with FORTRAN, one of the oldest programming languages
still in use. Pure functional programming model

Err... Even if Lisp is the father of functional programming, it is
definitively not a 'pure' FPL.

 

[gregarican]

Err... Even if Lisp is the father of functional programming, it is
definitively not a 'pure' FPL.

True. I couldn't referred to something like Haskell as being pure FP.
My bad

 

[Rune Strand]

1) Smalltalk - The original object oriented programming language.
Influenced anything from Mac/Windows GUI to Java language.

No. Simula is the "original object oriented programming language".

 

[John Salerno]

This is EXACTLY why I am still stuck on level 12 for many months. The
first few ones are fun. That sequence thing is also particularly fun.

But after a while, it seems that it's an image after image after image
after image. I just got sick of PIL

<snip>

And it is surprisingly difficult to find solutions anywhere! People
really want to keep them a secret!

 

[Philippe Martin]

Hi,

It is very hard to avoid C in embedded/low-level/industrial programming.

Philippe

 

[Scott David Daniels]

Here are a few languages I recommend most programmers should at least
have a peek at:

1) Smalltalk - The original object oriented programming language.
Influenced anything from Mac/Windows GUI to Java language. Terse, clean
syntax. IDE rolled into an operating system rolled into a set of core
libraries.

Simula actually is the "original o-o language (as Smalltalk's authors
freely admit).

2) Lisp - Along with FORTRAN, one of the oldest programming languages
still in use. Pure functional programming model that is extensible and
has many derivatives. Great for mathematical purposes. Easy to learn if
you can get past all of the nested parenthesis

The functional style is not what was unique to LISP. LISP was the first
language whose behavior was fully specified before it was implemented
(and that definition was completely machine-independent).

3) C - The "Latin" of modern programming languages. Used in low level
tasks (e.g. - hardware drivers) as well as larger projects (e.g. -
operating systems and other programming languages). Logcal, explicit
flow albeit a bit wordy.

--Scott David Daniels
(e-mail address removed)

 

[gregarican]

No. Simula is the "original object oriented programming language".

Thanks for pointing this out. I had read about references to Simula but
never looked beyond the term itself. Interesting stuff. Especially
since it was developed so long ago. Very interesting...

 

[David Rasmussen]

"const" is in C89/C90.

Although with slightly different semantics from in C++... For
instance:

static const int n = 5;
double a[n];

is valid C++, but not valid C.

There are other differences as well. In C, I can't do something like:

int f(void)
{
return 42;
}

const int i = f()

int main()
{
return 0;
}

/David

 

[David Rasmussen]

"const" is in C89/C90.

Broken const is. C++ const is different from C90 const.

As for the others, how about hiding a copy of GCC
somewhere, just to use to preflight your code before actually building
it with your compulsory broken compiler?

I can't do that. I compile for a special system with loads of special
libraries. The code can never compiler on a stock gcc compiler. Besides,
it doesn't help me to better and more precisely express notions in my code.

/David

 

[Lawrence D'Oliveiro]

Err... Even if Lisp is the father of functional programming, it is
definitively not a 'pure' FPL.

It _can_ be used as a pure functional language. An interpreter for a
pure-functional subset of LISP can be written in functional LISP, in
just a couple of dozen lines of code.