Hacker News Reader

Comment by m463 | Hacker News Reader

I'm pretty sure a lot of the popularity of oop actually came from modularity which came with it (although I do find inheritance useful, just not multiple inheritance).

I think C would be 10x more useful language if it ditched include files and had "import" like python

View on HN

> I think C would be 10x more useful language if it ditched include files and had "import" like python

I'm trying to imagine this, and I'm at a loss. How do you mean? The namespaced part of the import, where you can pick and choose what you get? Or the managed part of the import, where all your libraries live in a language-version-specific folder?

One of the great joys, to me of C, is it's insane flexibility. Include files are a hassle, but I don't feel they're something I've ever had to work around. I can't say the same for /usr/lib/pythonX.Y or in particular the way things like 'pip --user' work.

> I'm pretty sure a lot of the popularity of oop actually came from modularity

That's one area where C could be better, in my opinion. I don't need inheritance or friend classes or any of that, what I _really_ want is to namespace the methods that are meant to work on a single struct _with_ that struct itself.

Effectively, I would love to write my C structs the way C++ coders write the POD types.

> The namespaced part of the import.

To me this is the primary benefit (although the file mapping is convenient).

As to python... it is impossibly more flexible than C. I have done silly stuff like reading all the files in a directory, then i imported all the python files I found.

I think C is not very deep, but it is very well known.

That's an apples to oranges comparison. Python is interpreted, and can guess what the programmer wants much better than a compiler that has to output actual machine code.

> I think C is not very deep

Depends on what you're using it for, I suppose. For low level stuff I enjoy the fact that I can largely tell the shape of assembler from C code. What does Python really execute when I do `f = open('file', 'rb')`?

Not just modules, but classes too. I argue that the biggest benefit of OOP is encapsulation. It just makes it easier to compartmentalize concerns.

No, the biggest benefit is first-class modules. This is a feature that for example FP languages have struggled to incorporate. "Encapsulation" with OOP is a bit of a misnomer, as state is not encapsulated, it is just hidden. Such hidden state then interferes with composition. With true state encapsulation, a function can use mutation on the inside, but appear pure on the outside.

I'm interested in this, since I thought the concept of encapsulation is maintaining, and hiding, state inside of an object. What's the difference between mutating state on the inside and hiding state on the inside? Aren't they practically the same?

> What's the difference between mutating state on the inside and hiding state on the inside? Aren't they practically the same?

You can mutate state on the inside, but still provide a "pure" mathematical function on the outside. For example, a root finding solver. The general problem/feature with objects, is that when a method returns, the object may be in a different state (and often is). Such state changes are hidden but not "encapsulated" as they still contribute to the global state of your application. In other words, the global variables are still there, you've just organised them into modules.

I don't understand your reasoning. What does prevent you from having hidden state within a first-class module? It's simply encapsulation at module level.

Objects don't have to have mutable state. And even if they do, it can be unobservable. This is true "state encapsulation" but the OOP definition of encapsulation does not require this. Such objects are still very useful as "first-class modules", i.e. modules that can be passed around and switched at runtime.

On the subject of modularity, one aspect of OOP that bothers me is the conflation of namespacing (for organizing code that operates primarily on one object) with encapsulating the method as a class/object member. One could do the former without doing the latter! Basically a module containing structs and functions which act on it. In cases where the method(s) act on multiple objects, there might be other places/modules for them to naturally live.

Or garbage collection:

> The real significant productivity advance we’ve had in programming has been from languages which manage memory for you automatically. It can be with reference counting or garbage collection; it can be Java, Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of scripting languages.

https://www.joelonsoftware.com/category/reading-lists/top-10...

(Grep for "Automatic Transmissions Win the Day")

What does that mean? Import for C doesn't make sense to me because 1) C code is never executed during compilation, and 2) C doesn't even support bare code, everything has to exist inside a function. So what would be the desired behavior from import in C?

I can take a stab at it. I think what trips many new C people is the fact that include is just what it says on the tin, include. You can put anything in there and it is subject to the pre-processor. Many books/faqs/stackoverflow/videos however implicitly tie library include and headers together. So the idea that include means include this library comes somewhat from that. It tripped me up some 27+ years ago when I started on C. The actual include a library comes from a different part of the system, the linker. The includes just handily have the bits needed to have the external references to it so the linker knows what to do. You do not need them in the include to do that. Since they were including those they usually have predefined bits in there.

Like you say pythons import is a different beast and it can run code at runtime when it comes across that statement. Some training is not clear on that. Like you point out import does not just import the file it runs the thing. If the file only contains def's then it effectively just defines a bunch of functions/objects and does nothing else But it can. C is not like that. It is more copy the whole file here and apply the current state of pre-processor rules.

yes, includes are pretty much all syntactic, no semantic.

disclaimer: I'm a Rust dev.

* ability to reference other files in a manner other than copy/pasting

- allowing the compiler to understand when it should cache what it already knows, instead of having to set up and deal with precompiled headers for large projects

- ability to treat a header file as a single unit and not leak preprocessor defines

* treating many files as a single compilation unit, leaving LTO to only be needed when linking to a library

Reply on news.ycombinator.com