Or, like one of the companies I worked for, you could exercise your options, wait for a large Fortune 500 to buy them up, but then get told that your bylaws have a special provision that if the sale doesn't clear a certain amount, everyone's common shares are liquidated.
As in we got zero. Nothing. And this software is still in use in a major product.
So no, please don't trust options or exercised shares at any private company to be worth anything.
You want to get paid? Negotiate salary and laugh in their faces when they offer you options.
I have considered it deeply. Many of our enterprise systems are Java-based, so JRuby's ability to call Java methods directly without implanting services would be a huge pragmatic boon. But every time I consider that I have to balance it against being able to use a constellation of gems in Rails. For example, nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, but that isn't the issue. Rather I would have to reimplement or find replacements for everything we use that depends on that without introducing side-effects. In my experience that's really hard unless it's a toy application without many dependencies. (Read: opposite of most enterprise Ruby apps)
Also, as a gem author I've tried to support jruby along with MRI, but it requires jumping through a lot more hoops. Of course any cross-platform code requires more work to support, but it's a pressure on small devs. If no one needs it, no one helps support it, so then it becomes another gem that is effectively MRI-only. Kind of a viscous cycle.
Rubygems forms an ecosystem of libraries on top of Ruby. Most gems are dev/tested within MRI, some work across other Rubies, some do not. It's difficult to tell which is which. This means most teams choose MRI in much the same way that most Ruby teams choose some form of unix -- compatibility.
Ruby also suffers from the lack of a formal VM, so other implementations are merely similar rather than being guaranteed to run all programs. This is not the same with JVM vendors, where choice of IBM vs Oracle is largely based on extrinsic features rather than intrinsic compatibility. (Or at least you have to get in really deep to find differences-- in Rails you usually find incompatibilities that stop you from even starting the app).
The Ruby community is always likely to prefer MRI because that's the core that the majority of gems support.
So, yes, on the surface of it, this particular Ruby build might appeal to people looking for performance.
But from a language research position it is interesting to decouple concepts like GC from the language so that they can be studied and optimized as a pattern and then be potentially reapplied to any language runtime.
I agree that some concepts might be pulled into MRI Ruby 3, but OMR may be a powerful testbed for language researchers to debate GC strategies and measure effects in various languages before committing to a single language integration.
Consider part of the reason work takes so long is the constant stream of updates. Updates have killed more than one conference presentation.
Yet, when companies are faced with evidence that people don't like updates, they force more, bigger, faster. Why don't they invest in fewer, more meaningful, careful updates?
Treasure the customer's device as you would their home.
Yes, but the software may be based on symbolic reasoning, in which case the computer can 'use' a description of process symbolically and unexhaustively just as a human would.
Unlike other environments where everything is an integration with yet another library or tool chain, DarkBasic is refreshingly monolithic. Everything is simply in the language.
This makes it really easy for beginners to get started. Take a look!
In my mind, refactoring public policy is going to be like refactoring business processes in enterprise code.
The perception is that all these "horrible" duplications and inefficiencies exist.
The reality is that the duplications are actually slightly different business cases that are are difficult or impossible to generalize (it was easier to copy/mutate) and that seemingly irrelevant code has potentially far reaching and damaging consequences (oh, that was important?)
The essential problem is that we look at these individual lines of code instead of realizing that they grew as part of a dynamic system.
Refactoring code isn't a good analogy.
Try refactoring DNA.
It becomes quite tragic (or hilarious) when teams try to simplify such systems and instead end up breaking lots of business process that was ugly, but worked.
DNA/evolution is orders of magnitude more messy than that, but it gets things done more safely and efficiently than some refactoring efforts I've seen.
Are you saying the process that creates risk is ending or that we are simply hitting a boundary condition (i.e. The edge of the Petri dish)?
TFR is synthetic based on population behavior (I.e. Not solely intrinsic, such as genetic).
My point is that there is a feedback-loop at work here. Educated women self-select against reproduction because the consequences are more obvious. But under-educated women still have high TFR-- they will need to hit hard boundaries (starvation, dieback).
I don't think the process of overpopulation is ending, just clamped.
It's also interesting that the pair vs TDD divide is often based on the solution space.
Service/backend programmers often extol TDD because it is easy when working in a single language where your only IO is strings (i.e. Undergrad CS)
Front-end programmers may use TDD in certain established contexts, but pair may be more important when there are numerous integrations across unsupported toolchains. For example, when was the last time you used TDD with CSS? Oh? Too hard to verify that the CSS for a page makes it so that you can't click a button or print a page? Oh? Market bug isn't your responsibility?
Yeah, I see a lot of defensiveness when TDD is impossibly hard, so it's not "all that". But, use it if it makes sense. Know your tools and use the right tool for the job.
That's a bit rough. I think you are missing the other value proposition for SO: in a world of poorly documented interfaces, it gives cogent, vetted examples of what works. And you still need to have expertise to know which solutions are crap vs gold.
In the 'old days' you had maybe one or two languages and the language was the thing (not vast libraries like Java or .NET .. oh excuse me, the guys who used to get teased for the size of the CMS VAX reference are barely a man page in comparison to modern libraries) -- and now we have a proliferation of languages. Any web dev these days has to know at least 5, maybe more. Any old-timer has had to learn dozens during their career.
So no, I'm not going to use my precious grey-storage to remember an arcane Perl invocation when I can find it easily on SO.
Perhaps I don't meet your definition of 'programmer', but I've seen many junior devs get trapped in SO 'solutions' and wonder how I can possibly glance through 30 solutions and categorize them: "crap, crap, doesn't know what they are talking about, cargo cult, ... ah, there it is.. that's what we should try."
“Curiously enough, the only thing that went through the mind of the bowl of petunias as it fell was: 'Oh no, not again.'"
[edit: ok, so it is cool, but I'm not sure it's secure, and I'm not crazy about web pages from other domains being able to setup local discovery on my network. Seems like a massive security problem. Uuids sounds like obfuscation, not security. ]
I can sympathize, and there are areas of computing that are tiresome and never seem to get better, but there are just way too many things on my bucket list: unbiased rendering, physics, AI, mathematics education, visualization, theory of computation...
Heck, there are so many research projects out there completely changing what it means to compute (i.e. Bret Victor), let alone rediscovery of what the founding scientists (i.e. Turing) had for their original vision (did you know Turing generated music from his computer? Decades before the first synthesizer?! or Bell Labs, or PARC.
There is so much to know and so very little time to even scratch the surface. Maybe I'll get bored later, but right now there are things to do!
Except you describe the kinds of problems you typically solve (placing a button in a row) which are the smallest/simplest case of the problems that we're talking about, so it seems that you might not know about the problems that other devs face in composition of business logic, layering of complex build chains, etc or see a reason why solutions to these problems would ever be useful. Fair enough, but then you probably aren't the target market, so it doesn't make much sense to ask for a pivot to something else.
Must be a server-side dev. Java client-side trainwrecks include: struts, tempest, Java Server Faces, AWT, Swing.
True it's unfair to blame Java alone for these, because client side is more difficult-- we've been searching for solutions for decades in a variety of languages.
Modern front-end is a mush of dozens of tools/contexts, etc. Way more complex than TeX, and way less reliable and with minimal debugging context. But as the Eve guys have said, we're using the same layering of precompilers and interpreters we've always done. It's a mess because it's not just Java (or Python or Ruby) it's CSS HTML JS XML JSON, and the whole rest of the alphabet soup.
It's about time we reconsider platform as a whole again rather than merely a sum of fragments. That's why I find Eve interesting.
As in we got zero. Nothing. And this software is still in use in a major product.
So no, please don't trust options or exercised shares at any private company to be worth anything.
You want to get paid? Negotiate salary and laugh in their faces when they offer you options.