Nullc: Fast C-like programming language with advanced features | Hacker News Reader

Nullc: Fast C-like programming language with advanced features

github.com

89 pointsblacksqr50 comments

> 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.

More interesting tidbits:

> 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.

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.

> without anyone discussing why

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 think the assumption is that all software developers produce output of equal quality.

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.

Not a great language to code anything not a toy in then.

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.

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 agree. This project is fascinating. It's unfortunate it doesn't have one of those cool websites with docs, examples and all.

There is a language spec and it's quite comprehensive -

http://svn.assembla.com/svn/SuperCalc/LanguageEN.html

> function overloading, operator overloading

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.

Exactly. I think some people complain about Go's limitations. But this gives back in readability.

Yes but then they created their own world of evil with the ducktyping aproach...

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.

Yes, but in my experience if your issue is operator overloading then you have bigger issues to worry about.

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.

Good points.

I accidentally replied to yours. I had intended to reply to preseinger.

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)))

Definitely not.

The former is in general preferable to the latter, though, because it makes it a little more clear that arbitrary computation is occurring.

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.

Those projects are doomed and I would urge anyone not to spend much of his career trying to delay the collapse.

I say that as a member of a team whose median tenure (three years ten months) is short enough to concern me a little.

> Those projects are doomed

Based on my experience those projects are 99% of all projects in commercial organizations. So, emphatically no.

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.

What you label "deeply dysfunctional" I see as "emphatically normal".

idk? if you have a choice about how this will work for your software, you can chooce not to create huge incentives against expertise.

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.

Ruby and Swift have those features and are fine languages. The reaction against those features originates from exposure to C++.

It's true that function overloading is often overused. operator overloading, too <cough>iostreams</cough>

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)

I'm curious how it implements GC but compiles to C source. Does it just emit the source for the entire VM as part of the output?

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.

I think the popular Nim language also does this.

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).

At the top of the first page of every “new language” link there should be some source code examples!

Garbage collection is the antithesisto C. Yuck! If you want to offer an operating system so do it

C gatekeeping!

what a strange charge

I read the above comments as tongue in cheek, but I see many arguments online that go like this for many different things.

I'm not gatekeeping apples by saying a grape is not an apple, I'm debating how to classify these things.

Not sure how I feel about this!

FYI: nullc is a long-time username of Gregory Maxwell (here on HN, on Reddit and elsewhere too).

Isn't this just a rebranded C++?

No, its C with Extra features, or lesser C++.

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.

Nitpick: break, return, import etc are statements, not expressions

Reply on news.ycombinator.com