o-o-

Not to Claude – its own, old comments have helped me/it solve new issues on more than one occasion.

Yes some businesses are SaaS but here's the real problem: Many businesses' sole purpose is _leveraged buy-outs_ which really is the devil in disguise.

It goes like this: A VC specialising in veterinary clinics finds a nice, privately owned town clinic with regular customers and "fair" prices, approach the owners saying "we love the clinic you've built! We'll buy your clinic for $2,500,000! You've really earned your exit!".

So now the VC lends the money from the bank, buys the clinic, and here's the important part: _they push the debt onto the clinic's books_. So all of a sudden the nice town clinic has $2,500,000 in debt, raise prices accordingly, ~~burn out personnel~~ slim operations accordingly, and any surplus that doesn't go to interest and amortization goes straight to the VC.

Debt and collateral on the veterinary clinics.

Risk free revenue to the VC.

> The ad’s central message—that US allies should pay their fair share—remains a core principle of Trump’s foreign policy today. His longstanding skepticism of NATO, confrontations with international leaders, and demands for more financial contributions from allied nations all stem from the ideas he publicly expressed in 1987.

How. On. Earth. did you turn yourself around with those pre-conditions??

Nothing new here.

a) offers posting under anonymity, b) allows users to associate with exactly one physical passport, c) has no knowledge of who an account belongs to, d) allows for filtering on content by passport-authenticated users.

edit: s/an/and

I think you're making your route to market overly complicated by calling it autonomous. Just call it what it is – a drone with a AI navigation system. As long as a person commands it and monitors it (and thus _is responsible_), there's no reason to call it autonomous.

First video has 131 views – I hope this blows up.

These tools don't have a second-hand market. The expensive built-to-last ones do.

The "examples abound, in politics, economics, health, science, and many other fields" isn't a relationship between efficiency and outcome, but rather measuring and efficiency, or measuring and outcome. I think a better analogy is Heissenberg's uncertainty principle – the more you measure the more you (negatively) affect the environment you're measuring.

The... err... what?

A feature request is to allow the menu to ride along the cursor trajectory, effectively evolving the menu into a gesture GUI. I made an attempt at an svg implementation eight years ago: https://rawgit.com/lgrkvst/d3-sunburst-menu/master/demo/d3-s...

What I'm seeing however is nothing more than toothless, political pointing sticks.

Both IBM, Microsoft and Google have clearly at some point obtained total domination of their markets. Consequently they've all found themselves at the antitrust chopping blocks, however these companies have become so important to the economy that actual verdicts are reduced to a "carry on, just don't exert your dominance too much".

Or have I misunderstood antitrust laws?

Edit: s/excert/exert

If it’s not selected against, it wouldn’t spread at the cost of the tail gene.

Somehow, somewhere along the genome line, non-tailers overtook tailers.

I'm uncertain to what extent visual _representations_ of real code has anything to offer developers as a target group. I think it's the strive to have FBP represent already human-friendly code that gets in our way of thinking.

At the end of the day I want to define and execute logic without having to approach parallelism and asynchronicity as programming concepts. Instead the paradigm should transform such challenges into spatial ones. Instead the paradigm should transform such challenges into spatial ones. (Yes I wrote that twice for effect.)

I have yet to see such a system, but Drakon comes close.

I'm trying to wrap my head around the difference between execution models. On one hand we have real-time node systems like Unreal Blueprint, Modo or DaVinci Resolve, which depend heavily on state nodes, i.e. nodes whose sole purpose is to hold and serve information (a mesh, a transformation, an RGB matrix). These nodes act as complementary inputs to nodes in the main execution flow.

On the other hand we have Node Red and the likes, whose nodes rely on a single input. At first glance this approch might make sense from a UX perspective – simply connect your components and deploy. However with time I've come to see this as a major limitation to the extent that you're often better off writing code. After building a number of flows you start to notice certain patterns... Since nodes are uncapable of fetching data from other nodes ("state nodes" above), it's up to you as a developer to serve the node with the exact data structure it needs. The GUI gives you no hint as to the structure itself, so you're left reading the node's documentation: {payload, action, topic, subject} – different for every node.

At the core, this approach is the FBP version of polish notation in the sense that you first have to fetch all the operands before sending them to the operation. So what you're left with is a flow where every core node is surrounded by data shuffling nodes: "put this into 'action', put that into 'body', take 'payload' and store it away because the next node will overwrite it". As an effect of this "serial execution model", flows often stretch wide from the left to the right where two thirds of nodes are pure data transformations.

Somewhere around here the USP of FBP gets literally lost in the flow – the USP being to offload working memory. During building/debugging/revisiting flows, I often know right away what piece is broken. Nevertheless I spend a lot of time double-clicking on function, change, and switch nodes just to find that piece of code. The irony of it all is that I wanted to use FBP to _visualise_ logic. Instead the same paradigm hides it away.

So what you've accomplished is transforming code that goes from up to down into boxes that go left to right.

The thinking behind it all is that Node Red shouldn't make assumptions about the incoming data, however someone has to make those assumptions, and that someone is you, the developer.

It would be trivial to create a node that takes an arbitrary input (a sample message), analyses the message structure and exposes the appropriate output pins, however as long as Node Red persists with single input ports and the "message-based execution" it entails, it will take tolls on working memory and lag behind the Unreal model which I too consider state of the art.

I can think of two things that I believe would make a difference in any LargeCorp: First, a standarized way to visualise and execute business logic that allows developers and management to reason together. (The no-code movement is on the right track in fostering a common way to interface with code). And second, a responsible editor for each piece of code.

I think a key factor is that software historically hasn't enjoyed industrialisation to the degree of hardware (or construction for that matter). I can buy a standardized CPU of millions of transistors and integrate it into a standardized motherboard with just a snap. We have managed to standardize software up to the OS level, but after that it's up to the developer and her shortcomings.

https://www.codevalley.com/ does some interesting work.

Subsequently IKEA removed the corner holes. Globally, in the name of large-scale economics.

And speaking of subsequently, I've stopped buying bed linen at IKEA.

In essence a hacker would have to pay before attempting to hack the ssh endpoint. Of course the admin would have to pay too but the money would end up on his/her wallet.

Quite ingenious if you ask me.