> [complexity...] Author seems to imply that this is something unique to computing.
The unique part of computing is that complexity can grow way higher and faster than complexity in physical based engineering because it does not suffer from physical limitations and all the NN relations between pieces of shared code and data grow out of hand quick.
Creating something complex in physical realm is hard, and it essentially means doing more work to make something complex rather than simple. The common challenges are rather often about fitting the achieved complexity either in a small physical space (like an engine bay) or building it all out into large installments that look complex (like a nuclear plant). Yet many things in physical based engineering aren't inherently* hard but it will be hard to make it all into something that both fits in a practical enclosure and actually works reliably in practice.
But creating something complex in the realm of compute is rather the default offering. If you just put things together into a program then, in the classic rookie intern fashion, very soon you have something that mostly actually works but is implicitly so intertwined that nobody can understand the resulting interactions and can no longer start depicking the mahjongg of corner cases. Senior-level software engineering could actually be said to be primarily about managing complexity and whatever remains left after that effort can be used to build products and develop the trade. The reason we love abstractions is that they reduce complexity and make things manageable at all. There would be no progress in software engineering without abstractions.
If you were building an analog circuit that is, complexity-wise, on par with writing software systems you'd basically have to write software to design the circuit in somewhat manageable way. That's how software itself is written.
The project is theoretically a good idea but it's not really practical, and nobody is honestly suggesting it for real -- surely plans are cheap, and planning is even cheaper. But there are fewer than handful of railway lines crossing over the eastern border to Russia. Those can be blown up for good, for long enough distance that it's not feasible for Russia to rebuild track and reconnect to the main network should they, at some point, want to fall in love with Finnish rail. Other than that, the only other rail connection is to Sweden up north where there's already some arrangements to accommodate two gauges. At this point we run out of new reasons to change the gauge, Finland is effectively an island when it comes to European railway network. Surely it would be nice to standardise with the rest of the Europe but it's not much more than that.
> But there are fewer than handful of railway lines crossing over the eastern border to Russia. Those can be blown up for good, for long enough distance that it's not feasible for Russia to rebuild track and reconnect to the main network should they ...
There is no such thing as "blown up for good" for a railway line. And similar for "not feasible for Russia to rebuild". Destroying enemy-held (or soon-to-be-captured) rail lines was a thing, at scale, in WWII. On the Russian Front. Similar for rebuilding captured rail lines to convert them from "enemy gauge" to "our gauge". At best, using a different gauge and rail destruction are delaying & resource-draining tactics.
Trump recently stated that the US is eager to have massive amounts of trade with Russia. The most logical place to do that in that area would be Konigsberg, and exploit the Suwalki Gap.
> And types: he claims that 'typeless' languages allow for faster
> development because of fewer restrictions. This is, ofc, nonsense.
> The amount of restrictions you have is a function of your problem,
> not your language.
Unless you're implementing something that's already known, you're effectively carving out your problem when you're in the process of writing code. There are more unknowns than there are knowns. A strongly typed language forces you to focus on satisfying the types before you can do anything, at a point where you don't exactly yet know what you want to do. The right time to cast your data rigidly into types is gradually when your data structures settle in their own place one by one; in other words when you're pretty sure things won't change too easily anymore. This allows writing code that works first and then, depending on your needs, gets next correct and then fast, or next fast and then correct. You use the weakly typed or "typeless" style as a prototyping tool that generates snippets of solid code that you can then typefy and write down for good.
Solutions to any given problem are necessarily described with types. You can check those types at runtime or you can check them at compile time, but meaningful programs are typed. If you've got a function that takes a string and your type system lets you run a program where you pass an int to it... did it just allow you to 'quickly iterate'? Sure, you're running a program sooner, but you're going to run into the same type error (function expects string, not int).
Maybe in a larger code base you could argue that the effort involved in satisfying typechecks meaningfully slows down iteration, but even then it's clear that being able to compute the list of type errors you introduced elsewhere (via static typing semantics/analysis) is valuable.
Shouldn't be too hard to rewrite 2010 Facebook from scratch, and keep it like that. Follow what your friends are doing, and when you post yourself be certain that your friends will actually see your update.
I still see other content, even there, but it's still somehow manageable. I run out of updates very quickly though whereas I'd like to just start seeing older posts from friends that I've seen already.
Many have said that it's useful to delegate writing boilerplate code to an AI so that you can focus on the interesting bits that you do want to write yourself, for the sake of enjoying writing code.
I recognize that and I kind of agree, but I think I don't entirely. Writing the "boring" boilerplate gives me time to think about the hard stuff while still tinkering with something. I think the effect is similar to sleeping on it or taking a walk, but without interrupting the mental cruncing that's going in my brain during a good flow. I piece together something mundane that is as uninteresting as it is mandatory, but at the same time my subconscious is thinking about the real stuff. It's easier that way because the boilerplate does actually, besides being boring, still connect to the real stuff, ultimately.
So, you're kind of working on the same problem even if you're just letting your fingers keep typing something easy. That generates nice waves of intensity for my work. My experience regarding AI tends to break this sea of subconsciousness: you need to focus on getting the AI to do the right thing which, unlike typing it yourself, is ancillary to the original problem. Maybe it's just a matter of practise and at some point I can keep my mind on the domain in question eventhough I'm working an AI instead of typing boilerplate myself.
The friends feed is polluted these days also, not so badly as the infamous "feed" though. But it's bad enough overall that whatever feed/page I'm checking out on Facebook (which happens pretty rarely in the recent years) the absolutely first thing I check is who the post is from. If it's not a friend or a group I recognize as mine I just skip looking at the entire post.
I can imagine he wouldn't be interested in any of that. The joy of hacking only emerges when there are no external demands. That's why work sucks and you need to pay people to work for your demands.
Yes! I'm looking for ways to trick myself or otherwise convince myself to make progress on any of the bazillion totally awesome ideas I keep accumulating. Or one of the many projects I start and abandon midway
Question is what domain/field is the next virgin frontier for hackers, unspoiled of commercial greed and integrated and locked down solutions, where you can still not only buy things but also own them, and rebuild from parts what you bought when it breaks down?
There are all sorts of things like this, but one that springs to mind is drones, specifically FPV drones. You can build a very good drone from basically parts that runs on open firmware. The videos that you see coming out of Ukraine is clearly using flight control software that is basically the standard for non commercial drones. Nothing more cyberpunk than fighting fascists using open source software and commodity hardware.
What seems to be lacking is the path to accidental discovery that underlies these stories from the past. Is there a reasonable way people will find themselves building drones without being intentional about it?
The normal progression is that you had a commercially built one, and one of two things happened. 1. It was a prebuilt FPV drone and you need to repair it after smashing it into something at mach Jesus or 2. You bought a DJI, which is really a camera platform, and you want a drone that can fly at mach Jesus and do the cool aerobatics so that pulls you into the FPV genre where you buy a prebuilt or just build from scratch.
Drones are just an example, there are plenty of other areas where people might get sucked into DIY electroncisbuilding. E-skateboard/bike/scooter modification and fixing, keyboard hobbyists, cosplay, 3d printing, home automation etc...
Not accidental, but government restrictions are the main reason people built their own drones here. Government banned import of drones here back then. Only way to fly and have fun was build your own. build them part by part.
I have built them for dozens of non technical friends too. And then they themselves got into fixing them once they broke. Solder the wires. Get parts 3d printed etc..
Eg. Home Automation with custom LED strips + an ESP32 (via. tasmota, esphome etc...), Wireless sensors using the same, FPV Drones and RC toys/cars in general, 3D printers, Custom keyboards are the usual gateway hobbies in my experience. I haven't seen anyone who is into one of these and hasn't explored the others.
Using the C preprocessor is standard, available, compatible and the major usage patterns are "known". For a lot of cases, they're way easier to reason about rather than learning how an external generation tool is used to generate the code. In order to understand these macros all I need is to read the source code where they're used.
Nothing C++ related in the pattern though. This C preprocessor trickery is practically so classic you couldn't necessarily even call it a "trick".
The unique part of computing is that complexity can grow way higher and faster than complexity in physical based engineering because it does not suffer from physical limitations and all the NN relations between pieces of shared code and data grow out of hand quick.
Creating something complex in physical realm is hard, and it essentially means doing more work to make something complex rather than simple. The common challenges are rather often about fitting the achieved complexity either in a small physical space (like an engine bay) or building it all out into large installments that look complex (like a nuclear plant). Yet many things in physical based engineering aren't inherently* hard but it will be hard to make it all into something that both fits in a practical enclosure and actually works reliably in practice.
But creating something complex in the realm of compute is rather the default offering. If you just put things together into a program then, in the classic rookie intern fashion, very soon you have something that mostly actually works but is implicitly so intertwined that nobody can understand the resulting interactions and can no longer start depicking the mahjongg of corner cases. Senior-level software engineering could actually be said to be primarily about managing complexity and whatever remains left after that effort can be used to build products and develop the trade. The reason we love abstractions is that they reduce complexity and make things manageable at all. There would be no progress in software engineering without abstractions.
If you were building an analog circuit that is, complexity-wise, on par with writing software systems you'd basically have to write software to design the circuit in somewhat manageable way. That's how software itself is written.
reply