Oberon vs. C++ (1994) | Hacker News Reader

Oberon vs. C++ (1994)

modulaware.com

26 pointsnetworked18 comments

> argument saying that "VAR v: POINTER TO x;" is better than "struct x * v;"

Meh, each to their own I guess, but I definitely prefer C++ over that bloated syntax, where "x* v;" is sufficient by the way.

While Oberon is a bit verbose, the C/C++ declaration syntax is a train wreck. Consider the declaration of signal(), which does not have a very complicated type:

    (*signal(int sigcatch, void (*func)(int sigraised)))(int);

I can't think of any C-derived language (other than C++) that uses C-style declarations.

I basically just typedef away the ugly syntax. It basically works. Though I wish you could use typedefs in prototypes, like

    typedef int signal_func(int sigcatch, raised_func f);

    foo.h:
    signal_func* p_handler;


    foo.cc:
    signal_func my_handler {
      ...
    }

This would avoid a lot of repetition and is easier to read IMO.

Yes, C works if you know how to avoid the gotchas. It'd be nicer if the gotchas weren't there. It's not as if they add value to the language. (C++ OTOH seems to have too many gotchas to learn them all...)

Seems to? How can you even know how to comment on the gotchas if you don't know them?

The statement is about the viability of learning all gotchas of C++, and to make a credible point on this you just need to know there exists a large number of them.

(Indeed knowing all, or merely many, of the gotchas would speak against the conjecture.)

Every language has gotchas...

Scott Meyers seems to have made a career out of documenting them in his books.

That's for function pointers though, which is a bit different...

> [Garbage collection] is a necessary prerequisite for robust and reliable extensible software systems that will become more and more important in the future.

In retrospect, that seems somewhat naïve.

And that syntax... avoiding that horrible verbosity is one of the reasons that I preferred C to Pascal. It just feels really clumsy.

Most of the "deficiencies" in C++ have been corrected in time, and it took over the world. This shouldn't be a terrible surprise - the practical people get stuff done while the academics argue that their design is superior. Since language use for actually getting stuff done determines "winning" in the language wars, the pragmatic languages keep winning. They steal where the academics actually had better ideas, and they ignore the rest. And so the academics get left in the dust over and over...

I wasn't here in 94, but I get the feeling C++ took over the world THEN its deficiencies got mostly fixed.

Well, at the time the article was written, cfront was still the C++ implementation, so this was a really long time ago. C++ was arguably as bad as the article said... then.

I'd say that C++ being fixed and becoming more popular took place in parallel. As it got used more, people saw more things that needed fixed, and as more things got fixed, it became more useful for more people.

Why did things get fixed nearly as fast as they got identified as problems? Because there was an arms race between Borland and Microsoft to have the best C++ compiler, primarily. That competition did wonders for the language (neglecting the horror of Microsoft's incompatible and ugly extensions...)

"In retrospect, that seems somewhat naïve."

Why? One doesn't need to take a very strict view of what "robust and reliable extensible software system" means to conclude that we do not have such systems at the moment.

As to the pragmatists vs the scientists: IMO, with hardware becoming faster and faster, the scientists will eventually take over. Pragmatists will build kludges such as lint and typescript, but eventually, somebody will take a step back and decide that the world is better of if the elementary parts of such tools get included in the language and IDE (for example, nobody in his right mind writes C with implicit int's; some BSDs have banned gets)

> Why? One doesn't need to take a very strict view of what "robust and reliable extensible software system" means to conclude that we do not have such systems at the moment.

No. But we do have garbage collected languages, and we still don't have robust and reliable extensible software systems. So claiming that garbage collection is going to get us there does seem naïve.

But the original claim was that garbage collection is a prerequisite - not sufficient, but necessary. I still think that's naïve. But maybe, once we figure out how to do it, then we can figure out what language elements are necessary, and then we can see if garbage collection is on the list.

My bet: Garbage collection can help, but it's not essential.

None of deficiencies have been corrected. Just are added tons and tons of new features, leaving the old-cruft there.

The article called out specific things as being deficiencies in C++. It cited a lack of a Boolean type. Now C++ has bool. It cited lack of modules (name spaces). C++ now has this. It cited the lack of run-time type information. C++ now has RTTI.

But it sounds like you have a different list of "deficiencies" than the article...

In what bizarro world do C++ namespaces qualify as modules?

There are rumors that Apple's clang developers are working on something in that direction, but until that vaporware is done and standardized, C++ programmers have to use the C preprocessor's automated text copy-and-paste mechanism in lieu of a proper module system.

Edited to add: an article and video about the clang C++ modules work-in-progress

http://isocpp.org/blog/2012/11/modules-update-on-work-in-pro...

The article said that (Oberon) modules and C++ namespaces were similar features. You may have a different definition of modules, or you may think that the article is wrong to compare the two. That's fine. But I'm just the messenger here; go shoot somebody else.

Reply on news.ycombinator.com