sifoobar

I started working professionally in Delphi around 1998, and then spent 13 years evolving and maintaining a sprawling 2+ mloc reservation system.

They had a great thing going around that time, but then the pivoting and squeezing started. Instead of evolution we got enterprices, buzzwords and bit rot. By Delphi7, I'd say it was already as good as dead.

All owners so far share an unfortunate tendency to oversell half-baked solutions with no future, all the way up until the point where they pivot and push a brand new successor with no future while deprecating the previous attempt asap.

Their database, Interbase; was open source for about a month. Until the suits realized that no one would buy their shiny enterprice crap if they could simply download it for free, and it was closed again asap. Only now all the people who knew anything had joined effort in a fork called FirebirdSQL.

It was even released for Linux under the name Kylix, free for non-commercial use if I remember correctly. Until Microsoft bullied them into dropping the cross-platform game right now in return for cozy time with the centerfold creep and his side kick sweaty monkey. I just threw up a little in my mouth writing that so I'll stop here.

Told them to start acting human or sod off? I can wish, can't I?

Trying harder is never the answer to anything. People already are doing their best, whatever that means in a specific context. And however far from whatever expectations.

Pushing harder might very well lower productivity overall, since everyone now likes working there even less than before. And it's very difficult to regain trust and loyalty.

No one wants to hear that there are no short cuts, especially in today's messed up world where everything is fake and for sale.

But THERE ARE NO SHORT CUTS.

Regardless of language.

You'll have different kinds of bugs, but as long as there are programs they will contain bugs. Or the languages themselves will, or the libraries used, or the OS.

Assuming the presence of bugs/failures and providing powerful tools to deal with them like Erlang is a more realistic option if you ask me.

What is it with these people and controlling the choices of other, quite possibly more experienced, programmers?

Why is it not enough to offer better tools and let the rest take care of itself? Or to solve problems using a tool that fits your way of thinking? Why do you need a cult/marketing effort if the language is as good as it claims to be?

The more of this bullshit I'm confronted with, the less inclined I am to ever let Rust slip into a project I'm involved in.

I have a soft spot for Semitic Versioning [0] myself.

I don't know. Great artists know when to stop. I can't help but feel that this discussion crossed that line some time ago.

[0] https://github.com/ajalt/fuckitpy#versioning

Still too complicated.

Go almost got it right [0]; and then blew it with opaque, mandatory preemptive threading.

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

I would be careful with projecting that experience, everything is not about signaling; sooner or later mostly everyone will come to the conclusion that pretending isn't leading anywhere. Because it isn't.

Not depending on Instagram's algorithms and the opinions of its marketing department and your followers is _better_, for everyone. Dependency in general is rarely a good thing.

Judging is a different issue. But not giving a shit about what other people think usually goes hand in hand with not giving a shit about what they do either.

Funny story: I had just started working at a SV-based startup with mandatory surfing lessons and a fivefinger-wearing transhumanist CEO when Silicon Valley started.

Watching it was very painful, to say the least. Having to go through it is one thing, having your nose rubbed in it another.

Agreed; the others are nice and all, but nothing beats the Time Masheen:

https://www.youtube.com/watch?v=r3dhSnEtdWw

I've used Reddit since day 1.

The new website is a usability disaster, and one that they don't mind shoving down your throat at every turn.

Moderators are increasingly beating anyone who isn't politically correct enough over the head with their moronic code of conduct and banning users for simply disagreeing.

Most of the people who still hang around are very negative individuals who seem to be there more to project their hatred in general than to learn and/or share. Oppose their abuse and they'll invariable mob up on you and make sure your posts never see the light of day.

If I was Aaron Swartz, bless him; I would be turning in my grave by now.

They're also supposed to serve the people; and when they don't, it's the people's responsibility to remove them from power.

Which is just about where we are right now in many countries, at the point where that coin drops collectively.

It's one of those languages that does things differently to solve actual issues, not to check boxes.

From my limited experience, Erlang doesn't share data between processes; you throw it over the fence by sending to the process inbox, which is where the locking takes place.

Still, shuffling data between OS threads is an easier problem to solve than serializing between OS processes.

Processes by name, from Erlang.

They're implemented (in my mind so far) as preemptive threads, one per interpreter; which makes them slightly more heavy-weight than Erlang's NxM and a nice complement to purely cooperative multitasking.

I am aware, it's simply the most portable universal solution to the problem that I could think of. AIO comes with its own share of issues; Unix (and thus Posix) are pretty much dead; and it's not universal, I can't use it to open a database connection unless the database has support built-in.

From what I know, cooperative multitasking suffers significantly less from unpredictable performance than preemptive threading. The biggest source of uncertainty in Snigl is the preemptive IO loop.

The things is that I really don't feel like writing a concurrent runtime; been there, done that. I'm planning something along the lines of Erlang's processes and channels based on separate interpreters for those scenarios.

Some of those lessons have most definitely been used to improve the reference implementation.

It's not remarkably slow as long as you compare apples to apples, that is non-jitted vm-interpreters.

Jits pay a steep complexity- (and hence maintenance) price for their performance that should be taken into account when comparing.

Designing a significantly faster interpreter with comparable features is non-trivial from my experience [0].

https://gitlab.com/sifoo/snigl

Having recently been down this particular rabbit hole myself; I just want to note that there are other possible strategies, a GIL is not the only alternative to a fully concurrent runtime.

My own baby, Snigl [0]; doesn't even support preemptive threads, only cooperative multitasking; with a twist, since blocking operations are delegated to a background thread pool while yielding when multitasking.

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

I don't do quizzes, too much code to write to waste time on alpha bullshit. It's not up to me to prove either, plenty of people prefer C, plenty of them more experienced than you; calling them all stupid based on your quiz skills doesn't look very intelligent from here.

Here, let me fix that for you:

https://www.bimmerfest.com/forums/attachment.php?attachmenti...

Bu xie, my pleasure.

Yeah, we don't want any unconventional ideas to slip through; cause that might lead to changes, and evolution and all sorts of scary shit.

"It is paradoxical, yet true, to say, that the more we know, the more ignorant we become in the absolute sense, for it is only through enlightenment that we become conscious of our limitations. Precisely one of the most gratifying results of intellectual evolution is the continuous opening up of new and greater prospects."

~Nikola Tesla

Snigl [0] has statically typed function signatures, struct fields, bindings etc; but values still carry their type.

It also traces code before running it to eliminate as many type checks as possible.

The categories aren't very helpful from my perspective, same goes for compiler vs. interpreter. All it leads to is endless arguing about definitions and discouraging of novel approaches.

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

I used to own the book but left it at my desk when I quit a job in the hope that it would help the next poor victim for the same position.

Reading the whole thing, I'm again surprised at how much wisdom is hidden in there.

Shouldn't that be:

"Time for you to return."

though?

But that would still be single dispatch, right?

Multiple dispatch means functions are generic, and all arguments are considered when deciding which implementation to call.

Snigl supports both multiple dispatch and pattern matching, as does Common Lisp.

I didn't make the distinction, the post sort of did between the lines.

Go back to my original comment and you'll see that multiple dispatch is what got us here.

I never said anything about mutable/immutable data, I'm talking about polymorphism. But I did mention type classes as an alternative.

I frankly fail to see how this is leading anywhere.

The post drew a line between OOP and FP; for that line to mean anything, polymorphism would have to go with OOP. Which is what I meant by raw FP.

And solving the same kind of problems without polymorphism (be that multiple dispatch, type classes or otherwise), is a struggle.

I'll take structs and multiple dispatch [0] over both of those any day. Raw FP is too primitive and OOP mixes too many concerns, multiple dispatch strikes a nice compromise between the two and offers additional flexibility.

While Common Lisp's CLOS is often referred to as OOP, it's definitely less coupled than single dispatch.

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

Finding faults out of context is not really a skill; any moron can do that, and unfortunately many do.

The thing about Go is that you're always writing preemptively threaded code, with all of its issues.

The holy grail is cooperative multitasking and always-on, opt-out async [0] if you ask me.

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

I've read about D's compile time evaluation but have no personal experience. I know both Rust and C++ are pushing in the same direction.

From what I can see, it's simply an embedded interpreter for the same language; which means that it probably runs about as fast as interpreters in general (that is, significantly slower than D). I would love to be wrong and learn something new, though.

Starting from an interpreter means it's already there, the only difference is when code is evaluated. And embedding it simply means linking the interpreter library. Snigl and D are sort of approaching Lisp from different angles.