Hacker News new | past | comments | ask | show | jobs | submit login

What a clear way to describe the difficulty with manual memory management.

So like Lisp, C might end up being a solo programmer’s tool too. But not because it is a breeding ground for DSLs but because everyone is adhering to different conventions in the absence of the compiler enforcing one.




I don't think that the composability/interface-boundary/memory-mgmt argument stands for C and much even less so for C++. There's nothing difficult about it nor ambiguous.


Did you actually watch the linked presentation? If so, I would be curious in an earnest rebuttal: I very much stand by my conclusions -- and even more so after having spent the years since on Rust-based systems and C/Rust hybrids. Specifically, I have not seen a BTree implementation in C that I would consider to be composable; can you point me to one?


I did not watch the presentation, sorry. Depends what the definition of composability you have in mind so if you share what you mean by "composable BTree" implementation, I would be happy to give my opinion. I ask because there's no much I can see about the composability of a b-tree implementation other than supporting multiple types, and this is certainly doable although not as elegant as in C++.


While I appreciate your candor, you may want to know what argument, exactly, you are putatively refuting? (Specifically: the argument is not about types -- it's about ownership.) If it's not too much to ask, take two minutes to watch the linked clip. As for the composable BTree implementation, I actually am not asking for your opinion -- I'm asking for a link to the implementation itself. The details here matter (and indeed, that's the whole point).


I watched the video now and it is literally what one of the parent comments paraphrased and what I was responding to.

What you said is:

> I can write C that frees memory properly...that basically doesn't suffer from memory corruption...I can do that, because I'm controlling heaven and earth in my software. It makes it very hard to compose software. Because even if you and I both know how to write memory safe C, it's very hard for us to have an interface boundary where we can agree about who does what.

And I stand by my point. Single-responsibility principle will get you covered, yes, even in C.

> I actually am not asking for your opinion --

You could show some respect.

> I'm asking for a link to the implementation itself. The details here matter

B-tree btw is a silly example which particularly is not among the hard design problems out there and there are dozens of implementations laying around. Obvious examples to look for would be in transactional database systems implemented in C.

> (and indeed, that's the whole point).

... and the point not being quite clear, even after politely asking for a clarification, so perhaps next time you don't try to play the authority but try to provide an actual example to support your otherwise questionable claim. I'm sure Rust community will profit from individuals like yourself.


I’ve only played around with lisp a little bit, what about it makes it a solo programmer tool?


I saw it expressed by multiple people whose language of choice was Lisp but the only one that I specifically remember is Ron Garret’s recent post called Lisping at JPL Revisited[1]:

  All this is a reflection of the so-called Lisp curse, the fundamental problem with Lisp -- its great strength is simultaneously its great weakness.  It is super-simple to customize Lisp to suit your personal tastes, and so everyone does, and so you end up with a fragmented ecosystem of little sub-languages, not all of which (to put it mildly) are particularly well designed.
He doesn’t specifically say here though that this makes Lisp a solo tool. I can’t find a source for that right now unfortunately.

[1] http://blog.rongarret.info/2023/01/lisping-at-jpl-revisited....


Mainly, the online opinions of people who have no Lisp experience, solo or collaborative, but have read something to that effect somewhere.


Lisp is the most powerful and elegant language. That is a problem because you're giving weak, fallible monkeys phenomenal cosmic powers. Now, many monkeys are well-behaved and disciplined, so they create reasonable, pleasant codebases. But some monkeys go bananas.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: