Re:The Concurnas Programming Language
by CyberDildonics on Wednesday May 27, 2020 @11:19PM
(#23333029)
> and waddayaknow, every language people actually use has that built in
The point was never that people don't use coroutines or recursion. It is that neither solves fundamental problems and are closer to syntax sugar in that are something that people can reach for instead of doing what they want directly.
> Using what primitives? Oh yeah, more library cruft that would have been more concise and less error-prone than if the language gave direct support.
If you synchronize using data structures, that would mean you aren't using primitives.
> Oh yeah, more library cruft that would have been more concise and less error-prone than if the language gave direct support.
Why would that be true? Lock free hash maps and queues can fit in single file zero dependency headers. You think that's cruft? What about an entire language to solve something you can do without tying yourself to a bare bones ecosystem that no one knows.
> As soon as you're relying on somebody else to solve the tricky problems, you're letting them define the language in which you express your own logic
Meaning you want to not use a different language and solve all your concurrency yourself? The whole idea is to not keep solving concurrency in ad hoc ways. Also guess what, the moment you step in to a new language, you are going to be solving a _TON_ of old problems yourself.
I am not sure why you are so upset and invested in this. You seem to be arguing against yourself with respect to your conclusions and the flimsy rationalizations for them. These aren't actually problems that take a huge number of lines to solve, they just have to be done well. Throwing out everything from syntax highlighting and completion to debugging, to IDE support to libraries written in the same language is always a painful experience. Including a few files for data structures and task graphs is much less so.
The point was never that people don't use coroutines or recursion. It is that neither solves fundamental problems and are closer to syntax sugar in that are something that people can reach for instead of doing what they want directly.
> Using what primitives? Oh yeah, more library cruft that would have been more concise and less error-prone than if the language gave direct support.
If you synchronize using data structures, that would mean you aren't using primitives.
> Oh yeah, more library cruft that would have been more concise and less error-prone than if the language gave direct support.
Why would that be true? Lock free hash maps and queues can fit in single file zero dependency headers. You think that's cruft? What about an entire language to solve something you can do without tying yourself to a bare bones ecosystem that no one knows.
> As soon as you're relying on somebody else to solve the tricky problems, you're letting them define the language in which you express your own logic
Meaning you want to not use a different language and solve all your concurrency yourself? The whole idea is to not keep solving concurrency in ad hoc ways. Also guess what, the moment you step in to a new language, you are going to be solving a _TON_ of old problems yourself.
I am not sure why you are so upset and invested in this. You seem to be arguing against yourself with respect to your conclusions and the flimsy rationalizations for them. These aren't actually problems that take a huge number of lines to solve, they just have to be done well. Throwing out everything from syntax highlighting and completion to debugging, to IDE support to libraries written in the same language is always a painful experience. Including a few files for data structures and task graphs is much less so.