tomasGiden

I’ve seen some projects succeed with (because of?) visual programming languages and others fail because of them.

My general feeling is that a visual programming language excels as domain specific languages where the domain is quite visual.

Ive seen two problems with visual programming languages which are quite severe in my opinion.

1. Merging sucks. Merging visuals are not straight forwards. I’ve seen companies do trunk based development before it is was hip just to get around it.

2. As with all high level languages, without an understanding about the overhead of different constructs, it is easy to create very inefficient solutions. On cloud systems it may be easy to throw more processing power at the problem. On embedded systems, less so.

Did you wake up early this morning? Can you always answer that by a clear yes or no? When do you draw the limit between them? At 7:30? So if you woke up at 7:29:59 you would answer Yes and later No.

Instead you could put a distribution (but NOT a probability distribution) for belonging in the set of early that would look something like this.

If you wake up before 6:30 it would definitely 100% be early and at 8:30 it would. Or at 8:30 it would not at all, 0%, be early. Between there we would put some kind of partly belonging to Early rises.

In probability it is either or, but lack of knowledge makes us, but put a probability on what it is. In fuzzy logic, it is a bit of both at the same time.

Gas from Russia maybe? Big pipelines being built in the Baltic Sea.

Ericsson has another philosophy where there connect multiple repos at ci/cd-time. They have open sourced a tool for that called Eiffel [1]. There is also a book [2] written by the author of Eiffel that is quite good. One of his argument is that when, as an enterprise, you buy a company with a big mature code base, you can’t just move it into another common repo with all custom tooling (also very anti agile to force everyone into the same suit). A big difference though might be that Ericsson deals with a lot of custom hardware for telecom networks. So their ci tooling might be more complex than google’s. Also, continuous deployment is not really an option for them. Then it is better to just have each piece sent out events on what’s happening (builds, test runs etc) and let event listeners in other parts of the ci/cd pipeline work out what to do.

(I have worked for Ericsson previously for 7 years but that was before Eiffel)

[1] https://eiffel-community.github.io/

[2] https://www.amazon.com/Continuous-Practices-Strategic-Accele...

Whenever I see articles like this or about frameworks like the Cynefin framework I cannot help but to see it like any mathematical optimization problem. If the solution is simple to see you just jump to the solution. If it is more complicated but you have good practices / know the gradient (“know in what direction you are going”) and the problem is well behaved, you can iterate quickly and reach and expect to find an optimum. But if it is more complex and you don’t know I what direction to go / don’t have a gradient you need to do try lots of different experiments in parallel also.

And the more costly an iteration is the more important it is with multiple perspectives to get as much data into the different experiments from the beginning as opposed to randomly selecting things to try out and seeing what happens.

Predictions

1. Dark silicon will push us even further into heterogeneous computing. Major cloud providers will build their own silicon and proprietary software stacks for things like databases and other common computing tasks.

2. Nationalists focusing on Making their own country great will keep doing nothing about climate change. This will in turn create the inevitable need for people from poorer countries to become climate refugees. This will in turn create even more nationalism and fortresses build around rich countries.

3. The push towards sustainability will come from the economics of clean energy actually becoming cheaper than dirty energy. It is still too late to limit us to 2 degrees.

4. Speciality vehicles will reach level 4 and go driverless. Ie trucks in mines will be totally driverless. Long distance trucks will be driverless on highways and run to depots outside cities where drivers will jump in and take the wheel.

5. Most embedded control systems where correctness is more important than latency and computation/watt will move to Linux from microcontrollers and get a standard software stack. Probably built first by a cloud vendor for IoT devices. Thus making embedded systems will be far less work (and less interesting engineering problem).

6. There (finally!) will be a remote work solution which makes it economical to have most teams remote most of the time. Economical as in the the decrease in productivity for complex (see Cynefin model for definition) problems in remote work will be less than the increase in productivity given by removing commuting and the ability to get the best people no matter where they live. This in turn (past 2030) be the thing that starts to decrease traffic around cities, maybe even start people moving to smaller cities or villages closer to nature.

7. Mainstream microwaves will go solid state and stop making that annoying sound!

8. A standard to electrify roads (highways) will be set.

9. 6G will be released. Will allow sending and receiving on the same frequencies simultaneously.

10. AR/VR glasses will not become a thing for the general public.

11. Remote surgery (with VR glasses and robots) will become a thing where specialists in a few major hospitals will serve smaller local hospitals for specialist surgery. (Past 2030 for it to become the norm)

12. Same with Air control. Smaller local airports will be controlled by air controllers in a few hubs by standard.

13. Tech for the care of the elderly will spawn a unicorn.

14. Meatless meat will overtake meat in a few European countries.

It is easy to make a case for either synchronous or asynchronous communication just as easily as making cases for on collocation or remote work or office landscapes or individual rooms. But what is most often missing us the context. And it is quite naive to believe one way is always better than the other.

I can recommend the work on Dynamic work design by Nelson P. Repenning to make a case for both in what context either is best but even more importantly, when and how to move back and forth between different work modes. Here is a good introduction: https://sloanreview.mit.edu/article/a-new-approach-to-design...