321–330 of 574 posts
This artical makes the case for C as a low level language, I then offer Javascript as a functional-ish language for manipulating domain model data structures on the top.
Earlier quoted context omitted.
You're swapping definitions of unsafe. Earlier you were referring to the `unsafe` keyword. Now you're using `unsafe` to refer to a property of code. This makes it easy to say things like "It is also wrong to believe 100% of the C code is basically unsafe" but you're just swapping definitions partway through the conversation.
What I see is that antirez claims that absence of "safe" (as syntax) in C lang doesn't automatically mean that all of C code is unsafe (as property). There's no swapping of definitions as I see it.
Earlier quoted context omitted.
I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like we…
Love to see an AI agent to auto transpile C (sqlite, apache, nginx, mariadb, etc) into rust and run all the regression associated tests and perf benchmarks and produce report on the porting processes and perf delta.
Earlier quoted context omitted.
In my circles, there is one part of OOP seen as positive: encapsulation. Everything else, specially inheritance and partly polymorphism are seen extremely negatively. The hype is over. BUT: I still hear more often as I would like, some manager stating “of course we will use C++, because is THE OOP language, and everybody knows OOP and UML are the only right way of doing software” this is an actual verbatim statement…
I mostly agree with your assessment of how OOP is viewed today. In many technical circles, inheritance is seen as actively harmful, and polymorphism is at best tolerated and often misunderstood. The hype is largely gone. I’ve also heard the same managerial rhetoric you mention, where OOP and UML are treated as unquestionable defaults rather than design choices, so that part unfortunately still resonates. Where I disa…
I’m personally with you here. Just in my circle they see it positively. But I agree with you: as long as it helps modularity, great, but also have many downsides that you describe very well.
Your last paragraph also perfectly aligned with my views. I think you are coming from a functional PoV, which luckily seems to have some more traction in the last decade or two. Sadly, before you say it, often are underline the parts of functional programming that are not the most useful you address here… but maybe, some day…
Doesn't the language compiler write the code that checks if the array access is in-bounds? Why would you need to test the compiler's code?
The problem with articles like this is that they read a little like justifying a decision that has already been made. I've a feeling that if it was written in C++/Rust/Go/whatever, it would also be possible to justify that decision with similar reasoning.
I think the "lingua franca" argument for C and the points at the end about what they'd need from Rust to switch do go beyond merely justifying a decision that's already been made, though.
Earlier quoted context omitted.
How do you log or tell the world about the state of the program without allocating?
You don't have to allocate to print to stdout if that's what you're asking.
*C-API is the best. As a language, it's too basic. Almost every C projects try to mimic what C++ already has.
Ah, C has stable ABI unlike C++, never would get tired of unresolved std::__1 symbols.
First of all, ABI is a property of the OS calling conventions, which happen to overlap with C on UNIX/POSIX, given its symbiotic relationship.
Secondly, https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...
*C-API is the best. As a language, it's too basic. Almost every C projects try to mimic what C++ already has.
For big, fixed environments like Qt — sure. For embedded? Please no. Basic is good. Feel free to reimplement C++, your C library still will not have: most of STL as a dependency; unwind tables in all code (including C!); ctor/dtor arrays; insane kilobyte-sized symbols.
https://www.youtube.com/live/EIKAqcLxtT0?si=J82Us4zBlXLPbZVq
It is a matter of skill.
Earlier quoted context omitted.
Is it possible to have an OOP language which is also functional? Or is it impossible without imperative paradigms?
There's some muddiness in the terminology here -- OOP is really a design style, and "OOP languages" are generally imperative languages that have sematics that encourage OOP design. It is very possible, even encouraged, to represent state as "Objects" in many functional languages; it's just not really enforced by the language itself. A good example of this are the object systems in Scheme and Common Lisp (which are le…