undefined | Better HN

0 pointstheamk1mo ago0 comments

You mean, you are not worried about high complexity of codebase because you work with it every day for decades, so you know all this complexity by heart?

This basically requires one to be working solo, neither receiving not sharing the source code with others, treating third-party libraries as blackboxes.

I guess this can work for some people, but I don't think it would work for everyone.

0 comments

acuozzo1mo ago

> so you know all this complexity by heart?

No. It's that you've built up a personal database of libraries, best-practices, idioms, et al. over decades.

When you move on to a new project, this personal database comes with you. You don't need to wonder if version X of Y framework or library has suddenly changed and then spend a ton of time studying its differences.

Of course, the response to this is: "You can do this in any language!"

And you'd be right, but after 20 years straight of working in C alongside teams working in Java, Perl, Python, Scheme, OCaml, and more, I've only ever seen experienced C programmers hold on to this kind of digital scrapbook.

theamkOP1mo ago

I don't see how this can work.

You have your personal string library.. and you move to a new project, and it has it's own string library (it's pretty much given, because stdlib C library sucks). So what next? Do you rewrite the entire project into _your_ string library, and enjoy familiar environment, until the next "experienced C programmer" comes along? Or do you give up on your own string library and start learning whatever project uses?

And this applies to basically everything. The "personal database" becomes pretty useless the moment the second person with such database joins the project.

(This is a big part of Python's popularity, IMHO. Maybe "str" and "logger" are not the best string and logger classes in the world, but they are good enough and in stdlib, so you never have to learn them when you start a new project)

flohofwoe1mo ago

It's not the "string library" that's important, but standardized interface types - so that different libraries can pass strings to each other while still being able to select the best string library that matches the project's requirements.

In C this standardized string interface type happens to the poiinter to a zero-terminated bag of bytes, not exactly perfect in hindsight, but as long as everybody agrees to that standard, the actual code working on strings can be replaced with another implementation just fine.

E.g. a minimal stdlib should mostly be concerned about standardized interface types, not about the implementation behind those types.

1 more reply

flohofwoe1mo ago

> neither receiving not sharing the source code with others, treating third-party libraries as blackboxes.

Tbh, this is an intriguing idea. Determine the size of a library (or module in a bigger system) by what one programmer can manage to build and maintain. Let the public interface be the defining feature of a library, not its implementation.

j / k navigate · click thread line to collapse

0 comments

acuozzo1mo ago

> so you know all this complexity by heart?

No. It's that you've built up a personal database of libraries, best-practices, idioms, et al. over decades.

Of course, the response to this is: "You can do this in any language!"

theamkOP1mo ago

I don't see how this can work.

And this applies to basically everything. The "personal database" becomes pretty useless the moment the second person with such database joins the project.

flohofwoe1mo ago

E.g. a minimal stdlib should mostly be concerned about standardized interface types, not about the implementation behind those types.

1 more reply

flohofwoe1mo ago

> neither receiving not sharing the source code with others, treating third-party libraries as blackboxes.

j / k navigate · click thread line to collapse