> nullc is a C-like embeddable programming language with advanced features such as function overloading, operator overloading, class member functions and properties, automatic garbage collection, closures, coroutines, local functions, type inference, runtime type information, modules, list comprehension, enums, namespaces, generic functions and classes
Not exactly what I would call C-like in that it does a whole lot more. It is C-like in the way many popular languages are, that the syntax resembles C but that superficial similarity isn't really worth noting. It may be good marketing to get people to look at a new language though.
Work on long term projects like this tends to go in bursts. Stalled activity for a year isn’t unheard of. This project had a lot of activity in 2011, stalled the better part of a decade, and then had a burst of 1600+ commits last year. This is the mark of a project that has renewed interest from its author.
Sure, but that's 99% of languages out there. If you are evaluating a language for a real project, it's best to stick to the top 50-100 languages on stack overflow.
Out here in the wild west of programming languages though, questions like "can I use this for anything real" aren't really material. Of course you can't, and the irregularity of the developer is just one reason out of many. Nonetheless, people find themselves drawn to these languages because they can actually offer something those top 50-100 languages can't -- fresh takes on programming language design and philosophy. True, we may never build anything more than a toy in these smaller niche languages, but still we can bring the insights gained back to our development practices in those top 50 languages.
Why is activity the measure of product quality? If I write something that works great and needs few updates is it inferior to something that’s broken and gets commits every day?
This is just a terrible metric of software quality that became standard without anyone discussing why.
Because programming languages are different from regular software: for a programming language to be useful, it needs an ecosystem of libraries, package management, and IDE support. It's not the 80s anymore, when everyone wrote their own libraries anyway, maybe shared them with friends or colleagues, and didn't expect anything beyond a small standard library.
Today, a new language has a small window of a few years, after which it either achieves escape velocity, or re-enters the atmosphere and burns up. A new language which hasn't received major updates for two years, is effectively dead. It's a social phenomenon, not a technical one.
Why does it need to be discussed? Not actively maintained says it is either "done" or abandoned.
It is also a (weak) proxy for popularity, meaning if I do run into an issue an active repo means I am more likely to get help.
A quick glance at the git repo shows that it has builds set up on travis that are failing, and an unanswered question in the issue tracker. Neither of these inspire confidence that it will "work great"
I can make a guess why this might matter. For something that's not already widely used, we start with the premise that it is not finished in that it hasn't been exercised enough to know it is. With that a lack of activity indicates that edges are not being found and fixed. There could be an argument made that the way the software is developed and tested finds and fixes inconsistencies but that would have to be illustrated and not accepted as a given by statement alone.
The README is mostly a changelog -- there is a "Language Reference" in the wiki: https://github.com/WheretIB/nullc/wiki/Language-Reference although it's still pretty terse and really just a catalog. Is there an introductory document anywhere?
The readers who matter should not have any issue understanding your code. You don't have to make the code understandable to most readers i.e. off the street.
If you make a function called add which actually subtracts, why is that any different to an operator overload?
The measure of a successful software project is how long it takes an arbitrary programmer who has intermediate proficiency with the language and a reasonable understanding of the business domain to understand and become a productive contributor to the codebase.
Learning curves bring payoffs. It's most important that an expert can quickly make changes that are obviously correct, concise, and performant to the other experts.
Quickly onboarding novices is only helpful for throwaway work or teams with retention problems. Their work inherently needs more scrutiny until they become experts.
Experts take a long time to make. Few stay on any project long enough that the investment pays off. It's more important to ramp new developers up quickly than to empower experts.
Is typing `combine(t1, t2)` instead of `t1 + t2` the largest issue your experts have to productivity? Most folks complain about a variety of factors beyond typing speed.
I picked up Lisp early on, and don’t care that much about t1 + t2 vs. (+ t1 t2) vs. t1.add(t2). But without method overloading and generics, changing the static type of anything requires editing everything.
Well for math matrix formulas it gets difficult to read. Like (A+B)/2 *C*(A-B)/2 is better than mulMat(skalardivide(addMat(A, B), 2),mulMat(C,skalardivide(subMat(A,B),2)))
That sounds like a measure for successful software projects at deeply dysfunctional large companies that have fresh grads maintaining almost all of their software after the authors vanished.
The whole attitude (and the Go programming language) is maybe downstream from the fact that perf/promo criteria punish people who maintain the software they write.
I want to create incentives against things that make things easier for experts if they also make things harder for novices. Successful projects aren't those which make their experts the most productive, they are those which make the onboarding experience easiest. This is proven time and time again, at least in all of the contexts in which I inhabit.
I scanned the readme.md and found a few c++ style features listed in one of the earlier changsets. it would be helpful to have some kind of statement regarding the intent (i.e. c++ with less bloat, or novel type system, or whatever it is)
If you use Cython to compile vanilla Python, it implements GC in the C source without the VM. I don't find that especially noteworthy... though I do wonder about the particulars of their GC implementation (though... ick, GC).
VM? if you use your own allocator its pretty straightforward to run C code on a GC. there is of course Boehm, but its .. really slow and pretty fussy. since you own the compiler in this case you can even support object relocation (compaction) which does really* help a lot in total performance as well as footprint.
Jokes aside, I might have a look at it over weekend, it would be nice to see some PR materials on their git repo. Why should one use it over C/Rust etc.
I always get curious about languages like this; but the only one that ever stuck with me was the Pike programming language (circa '94). Pawn seemed somewhat decent too.
Not exactly what I would call C-like in that it does a whole lot more. It is C-like in the way many popular languages are, that the syntax resembles C but that superficial similarity isn't really worth noting. It may be good marketing to get people to look at a new language though.