coldnebo

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.

Re: jruby

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.

Doesn't seem to stand for anything (at least it's not defined in the project charter).

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?

https://projects.eclipse.org/proposals/omr

There is no Balance and no Art.

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.

I think the term stems from hearing two of these people interact at work: "what, are you guys married or something?" "Nah, he's just my work wife".

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.

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/

I liked DarkBasic: https://www.thegamecreators.com/product/dark-basic-pro-open-...

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.

Because math. <3

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."

Benefit of experience?

“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. ]

[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. ]

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!

Oh, I just realized that 'tagging' in this way is kind of an implementation of Minsky's k-lines. https://en.m.wikipedia.org/wiki/K-line_(artificial_intellige...

Cool!

But TFA isn't talking about 'the future', it's talking about the present. Why isn't there productive work for these people right now?

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.

I was initially confused by the "human" line too, but once I looked at the video and the examples I understood what you guys are trying to do.

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!

Software componentization never took off because every attempt at it either leaks abstractions like a sieve or is so purely functional as to be impractical for real world use.

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.

React is a lot more than it seems. The essential problem it tries to solve is componentization: how can you have a large team of varying skill work on separate parts of a page in a web application without one part breaking the others in hard to detect ways?

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. ;)

Yeah, unfortunately looking for advanced Rails answers means sifting through lots of silt: answers that were correct for version X but no longer, answers that avoid the question by doing something else, cargo cult solutions.

React is for scale, just not the way you think: React is designed to allow lots of journeyman web developers implement parts of a web page together, such that every component can work by itself and that one component's failure does not break other components, allowing pages consisting of multiple components that may have been dynamically assembled from dozens of different authors to work together.

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.

That's what it does, not how it works.

I.e., 'What' is just the top-level abstraction. 'How' is the functional composition underneath.

I think that might be paraphrasing implications of Gödel's Incompleteness Theorem.

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".

How is omega not equivalent to the time interval in common EC strategies. Also, saying that "EC" doesn't guarantee serializability sounds strange. It does, over t. And yes, CAP is widely misunderstood, but I'm not sure this is the fault of the academics.

Sounds kind of like this was written to a certain audience that is in a bubble wrt the wider field.

ZFS is also great for teams that work on ginormous code projects.

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 think there is also space in the middle for valid critique of gratuitous motion design. Hiding latenecy with a cute animation is fun the first time you do it. By the 100th time, it's usually just slow.

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.