For a very recent one-man project, this language has very good design choices.
I like "CoffeeScript for C" type languages that add things that C is missing (better syntax, safety, modern stdlib, easy concurrency, compile-time code generation) but without the bloat.
Very importantly, it's a major alternative to Go politically, being a grass-roots project that's not a subtle advertising campaign for one of the most evil organizations in the world today!
I really don't get why every C based languages like to clutter up blocks with {} ALGOL did just fine with an END statement, and there are nice syntaxes that use whitespace to designate what block you're in. Just a pet peeve of mine to look at ugly over cluttered languages. Otherwise it seems like a nice project this guy put together.
I tend to prefer Python/Nim-like OSR, I can tolerate curly braces, and I find the "end" lines most annoying. But it's mostly a matter of personal taste.
What we need is programming languages with modular compiler components and multiple parser front-ends / "syntax skins", which can parse different syntax styles into the same AST. That means you can have multiple syntax modes (ex. Python-like, C-like, Go-like, Perl-like, BASIC-like with "end" lines, etc, etc, etc) without fragmenting the rest of the language tooling, compiler back-end, module ecosystem, etc. You can also have a code formatting tool that converts from one syntax style to another. Then everybody wins.
With the AST that's kind of what the .net setup was attempting to do. I'm actually not the biggest fan of what came about because of it. Too many people want it to do too many things.
I personally think having a language convert to .c covers that fairly well.
But, as for style converting front end. I'd say that would be a fairly good idea if you didn't get into the perl paradox where nobody could read anybody else's code. Not to mention if the algorithm is converting from something like haskell to algol you've have a small nightmare with trying to figure out if the person who wrote it was in their right mind or not. Imperative to imperative and functional to functional seems like it'd be ok. But, I don't see the swap between the two working out so cleanly.
5 comments
0 u/libman [OP] 22 Jun 2019 19:50
For a very recent one-man project, this language has very good design choices.
I like "CoffeeScript for C" type languages that add things that C is missing (better syntax, safety, modern stdlib, easy concurrency, compile-time code generation) but without the bloat.
Very importantly, it's a major alternative to Go politically, being a grass-roots project that's not a subtle advertising campaign for one of the most evil organizations in the world today!
0 u/boredTech 22 Jun 2019 21:42
I really don't get why every C based languages like to clutter up blocks with {} ALGOL did just fine with an END statement, and there are nice syntaxes that use whitespace to designate what block you're in. Just a pet peeve of mine to look at ugly over cluttered languages. Otherwise it seems like a nice project this guy put together.
0 u/libman [OP] 23 Jun 2019 01:36
I tend to prefer Python/Nim-like OSR, I can tolerate curly braces, and I find the "end" lines most annoying. But it's mostly a matter of personal taste.
What we need is programming languages with modular compiler components and multiple parser front-ends / "syntax skins", which can parse different syntax styles into the same AST. That means you can have multiple syntax modes (ex. Python-like, C-like, Go-like, Perl-like, BASIC-like with "end" lines, etc, etc, etc) without fragmenting the rest of the language tooling, compiler back-end, module ecosystem, etc. You can also have a code formatting tool that converts from one syntax style to another. Then everybody wins.
0 u/boredTech 23 Jun 2019 02:55
With the AST that's kind of what the .net setup was attempting to do. I'm actually not the biggest fan of what came about because of it. Too many people want it to do too many things.
I personally think having a language convert to .c covers that fairly well.
But, as for style converting front end. I'd say that would be a fairly good idea if you didn't get into the perl paradox where nobody could read anybody else's code. Not to mention if the algorithm is converting from something like haskell to algol you've have a small nightmare with trying to figure out if the person who wrote it was in their right mind or not. Imperative to imperative and functional to functional seems like it'd be ok. But, I don't see the swap between the two working out so cleanly.
0 u/libman [OP] 23 Jun 2019 03:09
Yeah, businessy VM-based ecosystems like Java and .NET have this ability. We need something similar for native systems languages.