Almost half the comments here are just to remind everyone that C can/will never be replaced. Is that really the most insightful we can be? Is HN so pedantic now that we can't analyze an interesting language idea, but just nitpick at its existence?
1. Make a language and compiler that fills the same niche as C but does it significantly better, taking into account all the lessons we've learned in the last 44 years.
2. Make a build tool that competes with autotools, cmake, make, etc. Similar to Python build.py, you'll have a build.zig, import a library and use it. The library does everything configure/make does except better.
3. Package management on par with NPM and Cargo. Minimal overhead to publishing reusable code. Although I don't plan to have a central repository, rather the ability to put a URL or source control URL with a hash.
4. Zig can import and export .h files, and you can target .o files that are compatible with the rest of your C codebase.
5. Now there is minimal cost to replace bits and pieces of your codebase with Zig.
All of those points sound fantastic and zig is one of the most interesting things I've seen on HN in a while.
Still I can't help but ask one question: Your points 2 and 3 (build tooling and package management) seem like they would have the biggest, immediate impact for most current c/c++ users.
Did you ever consider separating the build tooling and dependency management effort from the core language?
I, for one, would be extremely interested in sane build tooling and dependency management for c/c++ (and what you describe sounds great). I would give it a try in no time. However, I'd be much more hesitant to consider a new language for a serious project. Even if the language is tip top, I would still be concerned if it is likely too be around and still relevant in X years. I think build tooling has less of a chicken-and-egg problem to adoption because you could always switch to another tool later. And once somebody uses your build system you're already half the way there to using the full thing.
Plenty of us know it can be done, and is an extremely worthwhile goal; keep up the fantastic work!
Zig may be the language I've been waiting for, so I'll make it the next language I learn, although I realise it's not even reached a first release.
2,3: Or just use make and use OS package managers. Don't make the users learn yet another tool.
The niche of C is Unix, which is here to stay. C is a part of Unix, it's interfaces are defined in terms of C, and plethora of libraries written in it. If a random library X is impemented in C, it is easily usable in many languages via FFIs. Programs written in C are easily portable to most popular platforms, and C knowledge is transferable from supercomputers to tiny embedded devices. C translates nicely to assembly, and it maps easily to mechanics of computing. These are the areas where languages like Zig need to penetrate.
> Or just use make and use OS package managers. Don't make the users learn yet another tool.
OS package managers fulfill a different task than development package managers that are bundled with programming languages.
The OS package manager provides a consistent set of libraries that is required to run the applications that ship in the OS.
A development package manager is used to bundle all your dependencies and pin them to specific versions so the build is reliable and reproducible. This sometimes involves things like being able to have several versions of a library in your dependency graph. Or sticking to a specific older version of a library you need (because their release schedule might not align with yours).
A development package manager might also take care of the compiler/interpreter version(s) of your programming language, for languages that develop rapidly. Heck, I'd even want this for "slow moving" languages like C, where I sometimes end up requiring a recent-ish compiler version for some extensions/intrinsics I might be using.
Apart from some fundamental libraries (say, OpenSSL, Xlib, libc), you should not rely on your OS package manager if you wish to reliably and reproducibly be able to build your software. The rest you should probably link statically or bundle with your app binaries depending on how you distribute your software. If your software ends up being packaged for a distro, it's up to the package maintainers to ensure that it'll build and run with the other libs in the OS.
I do agree that it is a nuisance to have a package manager for every language, but so far no-one has stepped up to try to make a unified package manager that works with many languages.
Points 1, 4 and 5 are exactly the same in C++ too. What makes you think you can do better than the guys who are driving C++ development? (Honest non-rhetorical question.)
Points 2 and 3 don't really belong in a programming language.
To the contrary, I believe that process improvements around a programming language will be more important than bare language features going forward.
If I were to build a language, a headline feature would be a package repository that enforces best practices (e.g. it should outright refuse to publish a minor version upgrade that breaks the ABI).
So what happens if you have a project that uses more than one programming language? (And what project nowadays doesn't? E.g., Python + C++ + Javascript + HTML + CSS is as simple as it gets for a larger-scale project today.)
Any 'process improvement' scheme will necessarily need to be language-agnostic to achieve popularity.
> Almost half the comments here are just to remind everyone that C can/will never be replaced.
As far as I can tell, this view is completely consistent with this PL's author's view.; he aims to leverage existing C code based and gradually switching parts over where possible; that's embracing C rather than shunning it.
Most of which from people that never used anything else and think C was some kind of wonderful invention by two guys at AT&T that just want to have an easy way to implement a compiler, by ignoring what everyone else has done before.
Had UNIX been a commercial OS instead of having the source code available for free, C would just be another footnote on the history of system programming languages.
No this is not about separating the work from the man. We're not talking about personal stuff.
In his capacity as a senior leader of a major silicon valley company, he actively worked to limit people's employment opportunities. That tarnishes his record as a great leader.
Except lucb1e's critique was actually entertaining, because I stopped reading the post myself because it was just so much fluff. All that high school college la-di-da stuff.
That's a very negative opinion of human nature, and a big reason I thought Wall-E was bullshit.
Humans enjoy their bodies. We play sports because it's fun and feels good. We enjoy the burn of a good run. We like to look in the mirror and see something vaguely attractive. We like to fuck. And we want to fuck people we find attractive.
> Humans enjoy their bodies. We play sports because it's fun and feels good. We enjoy the burn of a good run. We like to look in the mirror and see something vaguely attractive. We like to fuck. And we want to fuck people we find attractive.
Please excuse the low effort comment, but I've seen far more people who treat their body terribly, and who become overweight/obese compared to the number of people who do anything close to keeping in shape with sports, running, and so on. Not that that stops people from fucking, but the proportion of athletic, attractive people fucking is far lower than you might make it out to be.
A lot of that is because, in the current world, staying fit is difficult. I, for example, would be in great shape if I could exercise. I like exercise. Exercise is, in fact, how I discovered that I have joint problems. I unfortunately don't have time to go to a pool every week, which is basically the only exercise I can handle, and so I have trouble with fitness. On larger scales, there are entire towns that don't have access to fresh fruit or vegetables; google "food desert". There are people that don't have enough money to buy anything other than pure calories per dollar without paying any attention to health. There are people whose household water is barely potable and drink soda all the time because it's cheaper than bottled water. There are people that grew up in households that drank soda and have sufficiently shitty jobs that they can't summon up the willpower to change that habit. Then you've got people that simply rolled badly on the genetic lottery or inherited bad intestinal flora and can't be fit no matter what they do.
Removing stresses on time, money, social interaction, culture, and mortality will make the population more healthy, not less healthy.
> Please excuse the low effort comment, but I've seen far more people who treat their body terribly, and who become overweight/obese compared to the number of people who do anything close to keeping in shape with sports, running, and so on.
Research has shown that a lack of "psychological bandwidth" degrades impulse control.
Being excessively poor, having to take care of children or elderly parents, having a crappy job, etc. all take their toll on your ability to execute on things like exercise, cleaning, saving, etc.
Removing the problem of "daily living expenses" from someone's plate is a HUGE step toward helping them improve their situation both physically and mentally.
All the articles on Magic Leap are short of details. All their YouTube clips have had some questionable element. All we have are breathless investors, a couple of reporters, and the due diligence we assume was behind the $500+ million they received.
Until they show something to the public, I'll give them zero credence of having really advanced the state of the art.
Why is BASIC totally left out? An entire generation was inspired by power-on basic in C64 and other platforms. More than just "inspired"... Some huge amount of today's technology wouldn't exist otherwise.
I know I'm stuck in the past, but that's what I want for my kids. Flip open the laptop and boom, theres my programming environment, except now with easier graphics/sound APIs.
Anyone know how to get this, without buying a c64 + CRT monitor?
It's really hard to do something like that with kids today. They have so many options now between consoles, iPads, etc. There's way too much instant gratification. You're never again going to see a generation that has the patience to type in the source code to a game published in a magazine.
People have been saying "you're never again going to see a generation that has the patience to X" for generations, when really X is just no longer a thing anyone wants to do.
When was the last time you typed in source code from a magazine? These days we all expect software to be more complex than what you can fit on a printed page. People have patience for the things they find exciting: nobody is excited by dinky type-in games any more.
Untrue, at least in the case of my 9 year old. He loves writing Javascript "apps" from bitsbox (bitsbox.com). I learned by poke'ing on an Apple ][ because that was the tech of the day. Apps are the tech of the day for kids and he loves seeing the things he can create.
I have a little side project in this vein: http://akkartik.name/post/mu (apologies for the spam; I already posted my link elsewhere in this thread). No graphics or sound yet, unfortunately. I've been using it to teach long-distance, so the way we work is by running it on a VPS over a shared tmux. So it's completely text-mode. But in text mode you can do a lot with just raw cursor mode and 256 foreground/background colors. One of my students just built a card game with it.
(Another interesting feature of it: the programming environment is itself built in the Basic-like language. So there's a large example app that comes with the repo, along with a few small ones.)
Most platforms don't have a power-on equivalent, but BASIC derivatives with better sound/graphics/etc. APIs [0] are widely available (the particular selection will depend on platform, e.g., RFO-BASIC for Android.)
[*] well, maybe not better in all cases; for lots of simple things, some of the 1980s home computer BASICs had pretty good simple sound synthesis APIs.
One of the great things about C64 BASIC was that it didn't do too much hand holding. It had syntactic simplicity, but you had to deal with the underlying machine. Want to draw a circle? There was no "circle" command, you had do the math and flip bits with peeks & pokes & apply Boolean logic to retrieved values.
As a kid ~12 or so programming the C64, that did a few things that I think languages like those being presented here miss: 1) the computer didn't talk down to me as "being for kids", yet was simple enough to get me started without large amounts of previous technological background required; 2) the computer had more advanced capabilities that I could tackle as I gained experience (i.e. the aforementioned having to deal with memory manipulation); 3) Because it wasn't built for me (a kid), it didn't have to pretend to keep me entertained... there was a mystery to it all that as I progressed, I became more ensconced in deeper levels of knowledge that was earned, not given.
Sure I wasn't doing brain surgery, or even software engineering, but those early lessons gave me the fundamentals of why certain things mattered and how to solve problems that weren't child proofed.
Have a look at Kano on the raspberry-Pi even if you don't buy the kit you can download the image. It is a really well put together package which I can't recommend highly enough.
http://blog.kano.me
Terry Davis (creator) likens it to the C64, though you're writing in CPP/ASM:
"The vision for TempleOS, however, is a modern, 64-bit
Commodore 64. The C64 was a non-networked, home computer
mostly used for games. It trained my generation how to
program because it was wide open, completely hackable.
The games were not multimedia works of art, but generated
by non-artist."
That is awesome. I always joked with my wife that if we ever get our kid a computer early on, it wouldn't be an iPad, etc. that I'd figure out how to only give him exactly the sort of thing I had when I was a kid (a C64) and if figured that out, he'd be OK. The joke now becomes reality! :-P
There's also the FUZE and FUZE BASIC, a retro-y keyboard case and BASIC dialect for the Pi. https://www.fuze.co.uk/
I would also second the suggestion of the PICO-8, which is a Lua-based retro virtual console complete with its own built-in dev environment. http://www.lexaloffle.com/pico-8.php
I've been building a very simple development "portable" PC using a 7" TFT display, wireless keyboard, and a Raspberry Pi. At the moment, it just boots into a Linux login shell, but you can program it to boot into a desktop environment if you want (and if you have the power luxuries!). Of course, the Linux environment may be too much for kids, but this might be close to what you want. Also a decent overall price: altogether so far, I've paid a little less than $100 for this whole setup ($30 for the display, $35 for the RPi, $25 for the keyboard), though you could get it for much cheaper using a Raspberry Pi Zero ($5!) and a cheaper keyboard.
Get either FreeBASIC+IDE, BlitzMax, BlitzPlus, FnxBASIC, Browser BASIC or MonkeyX and place a shortcut to the program in the Startup folder on Windows.
What was it on the C64? I would have thought you would have had to write a program to do it. What is the command to spawn a zombie on the C64? Or to display a gif? Or to download data from an Internet service?
