sifoobar
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.
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.
But THERE ARE NO SHORT CUTS.
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.
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 don't know. Great artists know when to stop. I can't help but feel that this discussion crossed that line some time ago.
Go almost got it right [0]; and then blew it with opaque, mandatory preemptive threading.
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.
Watching it was very painful, to say the least. Having to go through it is one thing, having your nose rubbed in it another.
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.
Which is just about where we are right now in many countries, at the point where that coin drops collectively.
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.
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.
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.
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].
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.
https://www.bimmerfest.com/forums/attachment.php?attachmenti...
Bu xie, my pleasure.
~Nikola Tesla
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.
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?
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.
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.
And solving the same kind of problems without polymorphism (be that multiple dispatch, type classes or otherwise), is a struggle.
While Common Lisp's CLOS is often referred to as OOP, it's definitely less coupled than single dispatch.
The holy grail is cooperative multitasking and always-on, opt-out async [0] if you ask me.
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.