228 karma · joined November 3, 2018
Comprehensions are just plain faster, especially if you perform say filter and map at the same time.
That and a lambda implementation that only a mother could love, lack of tail call optimization etc.
What bothers me about comprehensions is they come with a separate set of rules, like LOOP in Common Lisp or templates in C++; but I'm pretty sure the restrictions are part of what makes them fast.
And I agree, the sum of 0-7 is still 28 :) Another typo.
Thanks again, this really helps. The plan is to turn all examples into actual tests and generate the README using Snigl eventually, but the required features are not quite there yet.
Thanks for taking the time!
You're welcome!
I hear you, it's very much a crash course so far. I've tried to keep the examples nimble enough to allow decoding any foreign constructs. This is unfortunately the level I'm operating at, because it's exactly where I need to be to write the code. Any contributions along those lines would be most welcome.
War is peace? Now where did I hear that one before...
The reason I'm tracing is that it's the only way I've found to prove anything of value in such a formless language; even Lisp knows which arguments belong to which function call, in Forth that depends on what came before.
And it fits well with an interpreted language, since a slow compile often defeats the purpose of compiling in the first place. The tracing I've implemented so far is instant in comparison.
There's plenty of Bullshit Do out there, no doubt. But there is also plenty of useful knowledge and experienced teachers that you miss if you assume that everyone who came before you was a complete idiot.
Many martial arts were honed into more or less perfection over hundreds of years by people just as intelligent as you and me, but with generations of experience from actual mortal combat. Living another day is a pretty good motivation for training and evolving.
Much of that is still around, but it's not being marketed. Because it's not what most people are looking for, it's too real and ego-killing. Because it's barely allowed; you can't spar out in the open with real knives or swords for example, you'll end up in a cell before you know what happened. And because it's been Disneyfied, by people like Jack Mace and Master Wong.
Once you've spent tens of years really training martial arts, as opposed to sports or pretending in silly uniforms; there's not going to be much to prove any more. If there is, you're doing it wrong. I prefer not fighting, people get hurt best case. So I can't really show you anything that looks like MMA, because that's just not how we train. And we don't do competitions; because there are no winners; just two banged up idiots, one happy and one sad. But for whatever it's worth this is me with a private student 3 years ago:
Just wanted to mention some alternatives to LuaJIT, since I don't think it's a viable way forward for languages of this scale.
Likewise!
Can't stop smiling these days when I see people fighting over which language will rule them all. I spent tens of years searching for that language myself. Time I would rather have spent solving real problems using the best tools.
I spent the last two years more or less full time trying out ways of making interpreters of similar complexity go faster without making the same mistake.
One method that seems really promising so far is AOT tracing [0], making guarantees and removing redundant code ahead of time based on incomplete semantic models. It's different from a full compiler in that it only tries to improve the situation and will back out and leave code alone where the semantic model is insufficient. And since it acts as a transformation on VM code, it's fairly transparent and easy to debug. The complexity of the models is a three way compromise between faster tracing, faster code and implementation complexity.
Once the VM code is reasonably optimal, further compiling to C by generating the interpreter code inline becomes even more attractive. Which also leads to native executables as a bonus feature.
If an implementation provides offsetof and it doesn't work, that implementation would go out of fashion in a heart beat.
Where is the practical use of this information?
How is this even an argument?
Wrapping your legs around your opponent's waist and rolling around on the ground for minutes ceases to be a good idea the second you leave the ring. While breaking fingers, ribs, poking eyes, punching throats and kicking knees and groins suddenly become viable options. In most cases; the sooner you can get the hell out of there the better, because the risk of getting into trouble increases fast in a street fight.
Basically everyone outside of their little communist bubble know what the Clintons are all about. More power, at any cost. But it's ending any second now, mark my words. The stuff that's been trickling out so far is the tip of the iceberg.
sgl_baseof uses offsetof with a valid struct type and a valid field name, so where is the UB? Unless you feed it an invalid pointer, but then all bets are off.
But in 30 years, I have yet to come across a piece of corporate software that's not crap. Established companies, consultants, startups; all crap. Different kinds of crap, it's not all rounding errors; but none of it would survive in most open source projects.
Because quality is only an issue as far as it increases short term profits, and that's not a very successful heuristic for writing good software.
I knew well enough, but the system was already approaching a million lines of semi-working floating point workarounds by the time. And since it was all my crazy idea, I would have been held responsible for every single rounding error from that point on, had I managed to get the ball rolling at all. Life is too short and too precious.
I was thinking language designers mainly; but user preferences are shaped by habits, which means that anything but floats will take more effort to communicate and popularize.
edit: Observe how popular this comment is for even floating (take that!) the idea. Plenty of people have serious issues when it comes to floats, that much is obvious. I'm guessing its mostly avoiding change at any cost, so good luck to us all.
It's not going to happen much until we stop pushing floats as the standard solution for dealing with decimals. I'm pretty sure they are more commonly abused than used at this point, and most cases would be better off with fixpoints, rationals or bignums in increasing order of flexibility and complexity.
Lisp and Perl6 get it more or less right. My own baby, Snigl [0], only supports integers and fixpoints so far. I might well add floats eventually, but I intend on hiding them well enough to not encourage anyone who isn't motivated.
The whole point of writing C is to keep it simple and only build exactly what's needed. No other language I've tried comes close to supporting the same level of custom fitting. This is also the reason it's potentially really fast; more because it encourages simple, direct solutions than anything else.
Virtual dispatch is a function pointer, either embedded directly in the value or together with others in a shared vtable. A type id may be added to the vtable if needed. Avoid inheritance tricks, composition is mostly the right answer in C. Downcasting is a solved [0] problem [1].
[0] https://gitlab.com/sifoo/snigl/blob/master/src/snigl/type.c#...
[1] https://gitlab.com/sifoo/snigl/blob/master/src/snigl/util.h#...
Just make sure that the cure isn't worse than the disease. It's all to easy to slip into identifying with C++ because of the substantial effort it takes to master.
Should you, like me and many others; eventually find yourself spending more time and effort on taming C++, don't hesitate to let go. It's a tool.
The Clinton's Uranium deal with Rosatom is a nice example of how this works; of course you can't just give politicians piles of money, it needs to come with a bedtime story for the voters.
The academic approach doesn't look very constructive to me, never did. Once you have a language nailed down so hard that errors aren't possible, the complexity of dealing with it will be more or less the same as dealing with the errors in the first place.
I would much prefer a focus on more powerful tools that fit into the current "unsafe" ecosystem while offering a more gradual and flexible path to improved safety.
How to become a better programmer makes some kind of sense, though the short answer is similar: write more code.
Which leaves no time to fill the ether with noise, so it's a double win.
How does this end up on the front page in the first place?
Typically, you need to move back and forth a number of times before it clicks. So you have all these people on the net fighting over which end of the spectrum is the Right one, and next month they're on opposite sides.
They're tools, hammers, screw drivers whatever; it doesn't make any kind of sense to identify with them. Unless your goal is to be a tool, I guess.
As opposed to US politicians like the Bushes, Clintons and Obamas? Or any of the countless corrupt puppet dictators that the US installed around the world?
Listen, I know they're pushing really hard for a war right now; but unless you're right up there at the top of the pyramid, war is hell.
The only thing that will ever get us out of this hole is truth, and truth starts with not spreading BS.