Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

I programmed quite a bit in Modula-2 before C.

It didn't teach me enough to recognize the silliness in C.

I believe that this is an aspect of C popularity that hasn't received a lot of recognition. Programmers were sucked away from cleaner languages into C, because the users of the cleaner languages had neglected to acquire the body of rationalizations for why those languages are that way which could have helped them stick.

C looked good in naive ways. "Hey, look at all the things you can easily do with memory and pointers! Wow, look at that slick syntax: you can stuff several increments and an assignment into an expression, and use that as the test of a loop, ... man I'm never writing foo := foo + 4; again!"

Modula 2's memory management is basically malloc/free though. While the language could save you from array overruns, it is basically defenseless against leaks and use-after-free bugs, as well as uses of unchecked null pointers under OOM:

See:

http://www.modula2.org/reference/isomodules/isomodule.php?fi...

Look, the allocator works with generic pointers, has an explicit DEALLOCATE, and ALLOCATE returns NIL when there is no memory!

Modula 2' standard also has a SYSTEM module which adds C-like things: pointer arithmetic, casting and whatnot.

http://www.modula2.org/reference/isomodules/isomodule.php?fi...

Is that just "C envy", or is there perhaps need for those things, know what I mean?

I came to C from Turbo Pascal (3, 5.5 and 6.0), so it already looked primitive to be back then.

Fortunately on the same year I got to learn C++, which allowed me to use most of the features I already knew from Turbo Pascal, alongside better safety if cared about it.

Eventually I only used pure C when required to do so at the university and on my first job after the university. Everywhere else the choice between both languages was always C++.

Regarding C, when coding in it, I always adopted a Turbo Pascal style by using translation units as if they were modules. With data structures designed as ADTs, without any direct access to its internals, defensively programming and eventually with a little bit of design by contract.

> Modula 2's memory management is basically malloc/free though. While the language could save you from array overruns, it is basically defenseless against leaks and use-after-free bugs, as well as uses of unchecked null pointers under OOM:

Yes, but there is already a bit list of errors that Modula-2 and similar languages saves one from:

- Buffer overruns (unless disabled, of course)

- Out parameters being null

- Implicit conversions of enumerations into integers

- Implicit conversions between numeric types

- Strings without terminating null

> Is that just "C envy", or is there perhaps need for those things, know what I mean?

Of course those features are needed in systems programming, but there is a big difference being safe by default and making explicit use of unsafe code, or just being unsafe everywhere.

For example, in Modula-2 if a module imports SYSTEM you already know that module is doing something fishy. In Oberon and Modula-3, like .NET, one could forbid unsafe modules from being loaded.

Whereas in C, even code that looks harmless can be doing strange things to the memory state.

Reply on news.ycombinator.com