sifoobar

Surreal.

I guess the good news is that this level of dysfunction should take care of the other Electron issues all by itself if we just wait a little while.

Definitely.

What could also be taken into account is that I used to be up there preaching the static typing gospel. And then I gradually got fed up with the ceremonies, since they didn't pull their own weight and couldn't keep up.

It's all compromises. The claim is that in return for following rigid rules, they guarantee this and that. Sort of the same deal the state has pushed down our throats since forever. And for a while it seems reasonable, until you pull hard enough to notice the chains around your ankles.

Because someone claimed that they're not arrays, which they are. So the posted article is correct in that sense; and not wrong about everything, which was also claimed.

I call my little Printf Snigl [0], but (s)he's been telling me the same story.

Can't do it any more, I have no more fucks to give about saving the world and awesome profits.

https://gitlab.com/sifoo/snigl

Says who?

I occasionally smoke Nicotiana Rustica, or farmers tobacco; which is plenty stronger than regular tobacco. And it's less addictive, even helps some people to quit because their bodies finally get all the nicotine they've been craving. And not surprisingly it's forbidden to sell it in most countries.

Someone fucked around with regular tobacco, that seems pretty obvious from here. It's basically designed to hook you more effectively and make you sicker by raising the nicotine levels really quick and then dropping them like a stone.

Which I assume is exactly what they're doing with the vaping liquids/salts as well. Profits, returning customers; who gives a shit about the world?

For a while, yes. I know from experience that going the other way is a struggle as well. Habits die hard and change takes effort.

There's nothing superior about these type systems, they're simply two of the most static and rigid systems in circulation right now.

Try writing C, Lisp and Forth until it clicks. Then we can sit down and have an informed discussion about missing features.

I'm pretty sure Python's list type is implemented as a dynamic array, otherwise random access wouldn't work very well.

Maybe try to not identify so hard with language choice? That way you gain the capability of processing critique without loosing your marbles.

Had the same deal with a guy running a startup factory. I'm pretty sure he couldn't program his way out of a paper bag without frameworks, which is why the alternative wasn't even on his radar. With people like that running the show, it's really no wonder we're going downhill fast.

The same trick is often pulled in C++, but mostly for another reason: to prevent name clashes with methods since they're in the same namespace.

Judge me by my size do you?

Some things are better said in one chunk, there are no rules. I often write longer functions while figuring things out, when I need more context in front of me to stay in flow.

Then I wait, and wait; until I can't stand it any more, at which point I usually know enough to substantially improve the code.

Assuming it survived that long. Refactoring code that you're going to throw away is not very constructive. And the more effort put into making code pretty, the harder it will be to let go when that's the right thing to do.

None of this works in a corporate setting, where there's never enough time or money to do anything properly. There are no awesome short term profits to be made from prototyping and keeping code in good health. Corporations also usually prefer rigid rules over competence and intuition, which means whatever cure they come up with will be worse than the disease. And as a result, corporate code is usually crap code.

Forgive them, for they know not what they do.

The people running this site though. The whole thing is designed to make life very difficult for anyone who steps out of line. And yes, it does seem to get worse and worse from here.

This is just a reflection from recent work on interpreter internals, but I figured it could be relevant to someone walking the same paths.

Allocating registers for all local vars statically means scopes have different sizes, which in turn complicates slab allocation and/or reuse. In return for being easier to reason about (except for the main scope issue) and saving space.

I opted for a fixed number of linearly assigned registers per scope in Snigl [0]; once the limit is reached, remaining variables are stored in a table. Which means I sort of get both, since additional scopes may be added using {} (it could make sense to add a scope: keyword to Python) if that becomes an issue.

It's all compromises, all the way down.

[0] https://gitlab.com/sifoo/snigl

Did I mention kernels anywhere? I simply shared my experience.

If that doesn't fit neatly into your delusions it's really not my problem.

It will put more pressure on the allocator when running, doing that a lot will likely have some kind of cumulative consequence down the line. I know from experience [0] that even reusing allocated memory rather than bouncing it back to malloc can have dramatic effects.

[0] https://gitlab.com/sifoo/snigl/blob/master/src/snigl/pool.h

Does it matter? I have a hard time thinking of a worse company to entrust with personal information. The reach of Google makes Facebook look like a joke. At least when it's leaking they're not making more money.

There have been several cases of bullying people to commit suicide where it's not obvious how the same thing could have been accomplished without without the leverage Facebook provides.

I'm grateful I didn't have to live through this as a teenager, it's a shark pool.

So how long do we keep pretending that allowing this to go on is a viable way forward?

Nice to hear! That's what I try to tell people who are asking for the right type theory book or the right dispatch method or whatever before even having a look. It's the same old problem solving; and here are always multiple solutions, each with it's own set of compromises. Claiming the one true way of doing anything related to software is delusional. We're barely scratching the surface.

Edit: While we're here; may I ask how you break out of the dispatch loop? Do you test an end-condition on each iteration? If that's the case, the longjmp trick might be worth trying. The condition will mostly be false, so it might make sense to pay more when it happens instead. You may find the essence of it in sgl_run at the bottom of sgl.c [0].

[0] https://gitlab.com/sifoo/snigl/blob/master/src/snigl/sgl.c#L...

No harm done; I don't do pride any more, it kept getting in the way of truth. But there's a clear tendency, especially on HN if you ask me; to blindly trust research by whatever authority and beat people over the head with so called best practices; while completely disregarding personal experience.

Sometimes the reason no one finds a better solution for a long time is that no one believes it's possible. Let's say it's 50/50, believing it's possible is still the superior alternative.

I have no idea what Python uses for regular dispatch; the linked thread just says that their computed goto solution is faster, which comes as no surprise given that was the reason they switched.

I posted the link since I learnt a lot from it, and since it echoes my own experience.

Better him than me. I wouldn't be so quick to dismiss relevant coding experience, it doesn't get old. Much of his reasoning about locality still holds, to an even greater degree today.

I've implemented more or less the same interpreter using computed goto and various variations on dispatch loops; and this is the fastest solution I've managed to come up with, and the nicest code to work with. Still too many parameters, my point is that I have plenty of experience pointing in that direction which is better than nothing. It's not a mystery to me. Using computed goto will involve some kind of lookup to get the relevant labels, I'm using pointers to actual instructions as jump targets. And since I'm longjmp'ing out, which means I don't need a loop condition; the loop is reduced to a single regular goto.

Like I said, better than nothing. There is no such thing as perfection in this world. I've spent quite some time [0] micro benchmarking different features to get a fair comparison.

[0] https://gitlab.com/sifoo/snigl/tree/master/bench

My own baby, Snigl [0], does always-on cooperative concurrency and asynchronous IO.

Just ask if you need help finding your way around.

https://gitlab.com/sifoo/snigl

For the longest time, I swore by computed goto as well. But it has its share of problems; it's not very portable; it forces the code into a rigid, non-extendable format; and it's not as efficient as commonly assumed. I'm far from the first person to notice [0], so don't bother shooting the messenger.

My latest project [1] simply calls into a struct via a function pointer for each instruction. With a twist. Since it returns the pointer to the next operation and uses longjmp to stop the program, which means I can get away without lookups and without a loop condition. And as an added bonus the code is much nicer to deal with and more extendable, since the set of operations isn't hardcoded any more.

Comparing language performance is tricky business, but it mostly runs faster than Python3 from my tests so far. My point is that computed goto is not the end of the story.

I'll just add that there are many different ways to write a VM; the one posted here is very low level, the one linked below reasonably high level. Using physical CPUs as inspiration is all good, but there's nothing gained from pretending in itself unless you're compiling to native code at some point.

[0] http://www.emulators.com/docs/nx25_nostradamus.htm

[1] https://gitlab.com/sifoo/snigl

Thank you, that would have helped.

Still, it's just too many layers of complexity for my taste. Nailing performance problems in C is a Sunday walk in the park in comparison.

Live and let live, I was just sharing my experience of going back and forth.

I would be very, very careful about assuming that any observed behaviors are fundamentally human. Leave people alone to do their thing and you would get an entirely different set of behaviors. There's no question that the internet amplifies our worst tendencies, with a little help from the psychopaths on top of the big tech pyramid. It will tip over, because it's not viable in the long term.

No harm done; I'm doing this with or without, because it has to be done.

I practiced Chinese once a week for two years, unfortunately never got a chance to use it since so it's been aging badly. The thing that many seem to have issues with when it comes to speaking/understanding Chinese is that the tone carries more meaning than in western languages. In Chinese; the same word has several, often completely unrelated, meanings; all depending on intonation. It's a new level of awareness, like learning a new programming paradigm.

Right, if the discussion isn't going your way you can always side track by making up faults and projecting agendas.

How is this helping us go anywhere worth going?

I was talking about std::shared_ptr, which is the closest thing to reference counting that STL offers.

I found The Humane Interface by Jef Raskin illuminating back in the days, if my memory serves most of the content is just as relevant today. Edward Tuftes books also contain plenty of wisdom and examples of good design.

STL smart pointers are all fun and games until you start using threads, at which point you realize that automagically flipping the (now atomic) counter back and forth behind the scenes every time the pointer can't be safely passed as a reference is a performance disaster.

Manually referencing and de-referencing exactly when needed avoids most of this. Sometimes it's perfectly safe to pass the same reference through several layers without changing the number of references.

As an added bonus YOU get do decide which references, if any, need to support multiple threads.

I have the same experience from implementing an interpreter [0] in C++ and later rewriting from scratch in straight C. The popular advice to use C with classes and skip the rest doesn't hold, for me it always turns into a constant loosing struggle to keep the code clean of fancy abstractions. And like the author mentioned, fixing performance problems suddenly means replacing STL features, which is a lot more work than simply writing what you need. Assuming you can figure out which knob needs turning in the first place, that is.

I first came across Turbo C++ back in 1995; it was the third language I learned, several years before I started my C journey. But I've gradually come to the point where I consider C++ to be a bad compromise, period. For low level fundamentals, C works better; and for higher level code there are plenty of more convenient options.

[0] https://gitlab.com/sifoo/snigl