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)
> 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.
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.
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.
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"
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.
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.
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.
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).
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?
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.
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.
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)))
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.
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.
51 comments
[ 3.0 ms ] story [ 120 ms ] threadNot 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.
> Language is type-safe and memory-safe.
> nullc library can execute code on a VM or translate it to x86 code for fast execution. It can also translate nullc files into C source files.
But sadly, although the project has been around for 11 years, development seems to have stalled since last year, at least going by GitHub activity.
This is just a terrible metric of software quality that became standard without anyone discussing why.
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"
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.
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'm not gatekeeping apples by saying a grape is not an apple, I'm debating how to classify these things.
http://svn.assembla.com/svn/SuperCalc/LanguageEN.html
I think Go took the right approach with calling those bugs to be avoided rather than features to be implemented.
Don't be clever. Be understandable to most readers.
If you make a function called add which actually subtracts, why is that any different to an operator overload?
Quickly onboarding novices is only helpful for throwaway work or teams with retention problems. Their work inherently needs more scrutiny until they become experts.
I accidentally replied to yours. I had intended to reply to preseinger.
The former is in general preferable to the latter, though, because it makes it a little more clear that arbitrary computation is occurring.
I say that as a member of a team whose median tenure (three years ten months) is short enough to concern me a little.
Based on my experience those projects are 99% of all projects in commercial organizations. So, emphatically no.
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.