3 ms·

The hard part of programming should be the problem you're solving. Fairly frequently, the hard part of programming is all the incidental crap that gets in the w

The hard part of programming should be the problem you're solving. Fairly frequently, the hard part of programming is all the incidental crap that gets in the way. You change the existing system slightly and a bunch of not obviously related parts fall over. Someone updates the OS on the CI box and now you're dealing with dependencies with dubious ideas about semver for the rest of the day. Nothing changed overnight but now the performance bot is reporting a regression.

atoav 3y ago
Yes and the problem you are solving is always about complexity. It is extremely rare that you have a problem where your solution can be a simple black box with a few inputs and one output. Most of the problems have many inputs, some of them malformed, many outputs, race conditions, multiple writers, time dependencies, weird edge cases, etc. If you really wanted to punish me you would force me to reimplement the good software I wrote in no-code tool. And I am a fan of node editors in VFX. I know how to wrangle complex node graphs efficiently. But in VFX you have a clear direction of flow and it is the simple black box described above. Structured text is a great and extremely efficient way of describing, editing and manipulating programs. Your node editor has to beat that for anything non-trivial — because even the simplest scripts I wrote for my employers had to handle any number of non-trivial cases. You are aware that dependency problem would be literally the same if your dependencies were made out of nodes and connections? Only now the debugging is harder. If you hate dependencies fucking your day up in code, you could always just not have them and write everything yourself. Like our fictional node wrangler would have to. I mean I can feel you. But nodes don't make these problems go away and structured text didn't create them. I meant what I said about complexity. This is not about code, it is about complex systems. A programmer who knows race consitions is also likely to be able to predict one in a completely peoples based procedure that doesn't involve computers. A programmer who knows about distributed systems will be likely to predict the same problems emerging from multiple distinct departments of a company, etc. If you want to tackle a problem involving complexity, you get people who know how to do that and you don't care whether they use nodes or structures text to do it as long as it gets the job done. Or you could make the tools look harmless and give that power to people who have no idea what they are doing. In many cases it might go fine, in many it will lead to much more complexity for when you finally hire aomeone to clean it up.

atoav 3y ago

Yes and the problem you are solving is always about complexity. It is extremely rare that you have a problem where your solution can be a simple black box with a few inputs and one output. Most of the problems have many inputs, some of them malformed, many outputs, race conditions, multiple writers, time dependencies, weird edge cases, etc. If you really wanted to punish me you would force me to reimplement the good software I wrote in no-code tool. And I am a fan of node editors in VFX. I know how to wrangle complex node graphs efficiently. But in VFX you have a clear direction of flow and it is the simple black box described above. Structured text is a great and extremely efficient way of describing, editing and manipulating programs. Your node editor has to beat that for anything non-trivial — because even the simplest scripts I wrote for my employers had to handle any number of non-trivial cases. You are aware that dependency problem would be literally the same if your dependencies were made out of nodes and connections? Only now the debugging is harder. If you hate dependencies fucking your day up in code, you could always just not have them and write everything yourself. Like our fictional node wrangler would have to. I mean I can feel you. But nodes don't make these problems go away and structured text didn't create them. I meant what I said about complexity. This is not about code, it is about complex systems. A programmer who knows race consitions is also likely to be able to predict one in a completely peoples based procedure that doesn't involve computers. A programmer who knows about distributed systems will be likely to predict the same problems emerging from multiple distinct departments of a company, etc. If you want to tackle a problem involving complexity, you get people who know how to do that and you don't care whether they use nodes or structures text to do it as long as it gets the job done. Or you could make the tools look harmless and give that power to people who have no idea what they are doing. In many cases it might go fine, in many it will lead to much more complexity for when you finally hire aomeone to clean it up.