coldnebo
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.
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).
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.
If I had to guess at it:
Open Meta-Runtime
But I could see how that might be misinterpreted compared to their goals. Not all cap names are acronyms?
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.
For example, these systems solve indefinite integrals without having to apply numerical methods with an infinite number of steps: http://www.integral-calculator.com/ http://maxima.sourceforge.net/ https://www.wolfram.com/mathematica/
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!
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.
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.
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.
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."
Benefit of experience?
[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. ]
[edit: ok, well at least they've started thinking about it: https://wiki.mozilla.org/FlyWeb#Security
Would like to see this fleshed out some more. ]
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!
Cool!
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.
There are a lot of really interesting approaches there. I really like the ideas!
I think a lot of service devs (read: stateless) won't get it. But people who code front end and deal with business logic daily might find something to love in here.
Worth discussing if nothing else! You got my star!
Shall I list the componentization tech of yore? CORBA, OpenDoc, Java Server Faces, COM, DCOM (oh god, CORBA again!), SGML (the original component framework), XML zoo (oh god, CORBA a third time).. JSON zoo, (a flippin' fourth time, are you kidding?!)
componentization is something we're still figuring out. Alan Kay and SmallTalk were the closest to get to it (see previous comment about practicality though) and the mainstream just now is starting to think of JS and Ruby as "novel". NPM? Please.
We have a long way to go before componentization actually works. So yes, I guess I agree that it's simply easier to reinvent things to a specific context than solve the problem of sharing code context-free.
Many people focus on JSX or virtual DOM and muse about how that just duplicates the browser-- what's the point? But that isn't the point. It's componentization and encapsulation for large teams at scale, and for Facebook it works, it makes them more successful at pulling together disparate modules on a single page than their competitors, so there is some meat to this $NEWSHINY.
Now, if the browser itself had been properly designed years ago to be componentized and encapsulated, we'd have those features without inventing a new DOM or creating a new tagging language or isolating CSS. There is a web components standard that offers much of the same thing... It came out around the same time as React, but still isn't widely used outside of Google Polymer. Truth is these were developed in parallel before they knew of each other.
Anyway, React makes a lot more sense if you think of it as rewritting the browser from outside the browser. In the old days the stack that would have been hard to impossible-- you would have simply started your own browser. And people would have shamed you for not following existing standards, so you would have petitioned the W3C or served on committees to bring your real-world cases for years, being mostly ignored.
Now, devs have the ability to change the browser quickly and find things that work (and also create chaos and suffering).
Meh. Kids. ;)
This seems to be a central point that the "I can just do this in CSS/HTML/JS" crowd continually misses. It really doesn't matter that you can do it... It matters that you can dynamically compose your work with hundreds of other people.
IMHO, most expert devs don't meet this bar with pure web tech, but unlike the W3C, I don't blame the webdev for poorly composing solutions, I blame the web standards themselves for poorly defined compositional properties.
But the platform has at least risen to the level where we can define its behavior ourselves. So I think it's healthy for other sources to push innovation because React upped the ante for Web Components and Web Assembly. The W3C will eventually understand the need for composition and isolation at scale, but they would have taken a lot longer to recognize the use-case without a competing concept like React.
I.e., 'What' is just the top-level abstraction. 'How' is the functional composition underneath.
Non-trivial codes can either be consistent or complete, but not both (within a system of abstraction).
This explains Joel's "Leaky Abstractions" essay as well as the conjecture that code cannot be perfect.
However, "good enough" thinking is often just sloppy thinking. Even if mathematics has boundaries, it doesn't mean you just shrug and say "a nod is as good as a wink".
Craftsmanship and quality are perceived in terms of utility over time. "Good enough" often doesn't meet that bar.
Engineers overbuild to support capacity and plan for the worst. "Good enough" tends to under-build at or below capacity and hope for the best.
"Good enough" is a just reaction to over-engineering (the adding of unnecessary fixtures and 'perfection'), so the warning has value and there are some engineers who use it in this way.
But others often mistake over-building for over-engineering and cripple their organizations and products by seeking "good enough".
Sounds kind of like this was written to a certain audience that is in a bubble wrt the wider field.
When I was a contractor at IBM in the 90's we had something similar so we could work on OS/2 source code. The entire build project was made up of hundreds of other sub projects and it was way too big to fit on a single developer machine of the time. Plus the reality was that individual developers only edited small portions of any part, even though they needed the whole to build and test.
In later years, I've found myself thinking about ZFS for other big project scenarios. Like legacy enterprise websites that have gigs of static files and scripts that integrate with parts of webapps, etc. it's a pita to sync an 80gb mirror to every dev and a horrible waste of space. Much more efficient to simply mount the production mirror once and then store small edits locally.
Note that these kind of legacy sites are usually not checked into source control because they are too big.
I regularly out-pace guis. For example, the simple task of using google maps to go to work in the morning. This task is visually spread out with time-slowing animations that require constant active participation. It is like 5 taps made excrutiatingly long by the fact that my car is parked just far enough away from my home that wifi cuts out and the phone has to aquire 4g. Compare to Waze (also owned by Google) one tap, swipe and dialogs auto continue without needing to be "fed".
I love animation and motion graphics, but I've seen many motion devs fall into the trap of "oh this is so cool, but they won't see it unless I make it a bit longer" -- and unfortunately most of the JS animation frameworks do not encourage async interaction, so interaction phases are often held hostage to the animation cycles.
In these cases, I think motion design is rightly considered wasteful and not delightful.