Use the wrong tool for the job
buttondown.email
buttondown.email
In the end we both have a finished project. But the professional would be a fool not to specialize their kit and I would be a fool if I did.
But we needed a native app on iOS for irrigation control, so we had to tool up with Swift. I would love to do a solid cross platform thing, but there isn’t one in mobile space for user rich experiences that do Bluetooth, mapping, etc. We tried. So Kotlin has to be added to the mix so we could use the only right/available tool for native Android app job. The embedded stuff? Needed C code. The control node that runs our edge stuff needed to run on little Linux computers and support self hosted development. C wasn’t going to work, nor was Kotlin or Swift. Python it is. We needed a highly threaded cloud bridge sevice. Python was out for that. I guess I could have tried server Kotlin or Swift, but I went with Elixir instead and just wish I could use that everywhere.
So if you’re just doing web stuff, I guess you can just use consistent whatever. Though isn’t the whole argument of node/deno that since you have no (real) choice but to use JSON the front side, you might as well use it as the wrong tool for backend as well?
Same here! I would say, I'm in the similar camp as your colleagues but about Elixir. I'm glad to choose the right tool for the job as long as it's Elixir :)
* Bluetooth and maps libraries are available for Xamarin, [1] [2]
* Control server could be written in C# using the .NET core worker template [3] and deployed as a SystemD service and then the SDK deployed as a package to enable local development.
* Cloud bridge deployed as a service or website using raw sockets, SignalR or Azure IOT hub (depending on requirements).
You'd end up with 2 languages instead of 5 and I suspect you'd be able to factor some code out into libraries as well...
[1]: https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user...
[2]: https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le
[3]: https://devblogs.microsoft.com/dotnet/net-core-and-systemd/
I don’t have lots of direct experience with these in particular. I have played with the BLE shim libraries provided for Dart, React-Nativ, and Cordova back in the day. All were maybe ok for single characteristic rare interaction. But as you go up in connection frequency, characteristic count, or update frequency, things degrade in robustness quickly. I spent a solid couple of weeks getting our Kotlin/Android version up to being able to handle 1000 reconnects without hanging the chip. BLE is hard.
Given that even with the native map stuff, we had to jump through some “clever” hoops to get the kind of map overlay feedback we were looking for and at tolerable update speed, I remain skeptical that yet another abstraction layer wasn’t going to be an additional hindrance.
> * Control server could be written in C# using the .NET core worker template [3] and deployed as a SystemD service and then the SDK deployed as a package to enable local development.
We have limited flash space. It’s too small to accommodate the gcc toolchain. If/when we want to do that, we used a mounted sd card to accommodate the space needed for doing hosted development. It’s pretty cumbersome compared to having Python right there. I would guess that if gcc wasn’t much of an option, c# was going to run into similar issues.
> * Cloud bridge deployed as a service or website using raw sockets, SignalR or Azure IOT hub (depending on requirements).
My choice to use Elixir here would be the most arguable. The nature of how we do MQTT communications securely (uniquely secured by each connection path) dictates either a single threaded many-socket mqtt client (we’d have to do this from scratch) or just use lots of threads, one per client connection. It is not uncommon to have 20,000 threads active in our current solution. Based on some peers comments, that would be a lot. But at that point, I guess we’d pursue the many clients on less threads approach. Which could have been in whatever. I really just wanted an excuse to take Elixir for a spin, and this was an area it could/did shine.
It’s still a bit disappointing that there wasn’t any mention or consideration for becoming familiar with more tools as a solution.
You don’t need to be familiar with everything, but to extend the author’s metaphor it’s better to have a variety of tools in your toolbox than to be a one-trick pony.
Not all arguments between the individuals and the workplace translate because the workplace is a dynamic set of individuals. So any decision made for the workplace has to work for the people currently at work but also for future people you will onboard.
Besides, if you are large enough for this to be a problem, you are large enough that everybody doesn't have to know everything.
This article had a good impact on how I do typing nowadays (applies to any language): https://dusted.codes/the-type-system-is-a-programmers-best-f...
Why?
No, it's not the kind of "problems" that real programmers do ;)
This confusion arises because “programming” is a broad, poorly-defined term. There are plenty of examples of projects which foundered because someone did what you described OR the inverse, because the underlying program is some combination of mismatched skills, incentives, and situations. There are people who’ve generated more business value with a labyrinthine Excel workbook than a room full of “real programmers”, and it’s always worth considering why.
So it's about matching the impedance. It's about reducing the impedance mismatch between systems, not about reducing the impedance.
Maybe wavelength of light and a filter is actually having the same thing happening underneath, and is used often in common talk: if two people "are of the same wavelength", they can talk to each other. The closer they are, the easier. That's not physical, of course, but is an analogy for physics: if the receiving system has a colour filter on its input, the light you're sending needs to be of that wavelength (or frequency, since that's directly related) or close enough to get through.
So if you want to maximise that two people are a match for each other (the "right tool"), you want to minimize the "difference in wavelength".
But then I think there is more to it than just the wavelength: it's also about the characteristics of the sending object. An amplifier and speaker pair needs to have about the same impedance for the amplifier to be able to output sound of a fair volume level through the speaker. Such systems are coupled bidirectionally (the speaker can divert the energy back into the amplifier), and that's where I think it gets complicated to a level where you and me zone out unless we study the math.
Given this, the “wrong tool (technology or language) for the job” simply complicates the already complex?
TFA talks about artificial vs essential complexity, with the term "impedance" being used to talk about artificial complexity introduced by the tool being used, typically the programming language. As the author notes, the tool being chosen is partly a political choice.
The paradox they talk about, is that e.g. doing CGI in C is "wrong", but on the other hand if you are extremely good at C, you might be more productive than using, say Perl. Between the lines of TFA, you read because productivity. The "wrong" tool is a local optimum (of your all-C shop). If you want to go after the global optimum, you need training. And that's another political decision - which can be tough to make, because as typically don't have expertise in the field, you don't know what's right and are likely to fall for fads or new hires that supposedly brings that expertise to you.
(The MCAS system would have been different or even absent if pilot retraining was done anyway.)
Basically, they tried this approach but didn't recognise they crossed the threshold where letting go of old flight characteristics makes sense.
Where I’ve seen gratuitous complexity introduced by the technical staff it’s been a situation where a 1.5x programmer thought they were being 10x when they larded up the architecture early, leaving the project behind schedule seemingly without enough time to fix it. The problem wasn’t the average programmer but letting the one a bit above average set the direction.
But it is unlikely to be simpler. In fact, it is likely to have some fairly hairy "sleight of hand," to achieve its ends.
I've been at this a while. I know what I'm doing. Making the decision to rewrite the codebase, as opposed to fixing the existing one, was fraught. It was not a "snap" judgment at all. I agonized over it for some time. I'm sailing out of port[0]. There are circumstances that allow me to do this, and I'm grateful, but I am also setting myself up for a lot of work. A great deal of the "cruft," in the old codebase, is called "bug fixes." I'll have to deal with the same stuff that caused the patches. This time, I will be better able to anticipate them.
One of my favorite activities, when writing applications, is throwing away code. It gives me great pleasure to consolidate a bunch of classes or structs, into a common handler, and toss out all the unique files, etc.
Of course, one of my most powerful refactoring tools, when doing this, is OOP. In particular, polymorphism <cue a spooky rendition of Toccata and Fugue in D Minor>. It's an outstanding way to factor out common functionality. It is possible to use things like protocol/interface defaults to do this (and I use them frequently), but protocol defaults have their own issues[1].
It's highly unlikely that an inexperienced developer (especially one not fairly advanced in Swift) would be able to take over my codebase, despite the elegance of its design, and its effectiveness. I would likely hear cries of "overengineering!", and statements like "Why didn't they do this in React Native, or Xamarin?", or "I could bang the same thing out in SwiftUI, in two days!", etc. ad nauseam.
Fair 'nuff, but I an an advanced Native Swift developer. It's the tool I know best, and I know it better than most. I have also been severely burned, in many ways, by being too "bleeding edge," and playing Buzzword Bingo. I know of several major projects, where the company decided to write their next version, using the latest tools, only to have to clean up the mess, and revert to the classics, when it all went pear-shaped.
[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...
[1] https://littlegreenviper.com/miscellany/swiftwater/the-curio...
The problem is not too many programming languages lol. How the hell could the difference between 15 and 3 be the problem!
The problem is the terrible division of laber between projects, between libraries, between kernel space and user space, and between hardware and software.
The problem is Conways law, or zoomed out, incremental evolution on the industry scale promotes biology-like over-complexity.
The solution is planning, and the first step of planning is seeing what the hell is going on.
The key ingredient for that first step is Nixpkgs.
"Oh! Drain pipe for the faucet? I know, I'll just use leftover air vent ducts, that's what I'm already familiar with anyway!" (Using nails to join everything of course, how's that for a leaky abstraction?)
As he proclaims the "first sprint" done he walks up to you, demanding a 100K/year salary. When you decline, because the house is falling apart, he angrily mutters something about how "tech debt" is wrecking this industry (he's blaming the failure on you for not giving enough time to address it) and that he was thinking about finding another job anyway, since he was already working for you close to a year now.
Unlike with carpentry, when it comes to programming languages there actually are multiple options that can be used for such a wide range of purposes that it's possible to built entire projects/products using just the single one you prefer, which is of course less likely to be feasible when it comes to using a single tool like a hammer.
Every language has unique strengths and weaknesses and it's absurd to pretend they're all kinda the same. I wouldn't write a website in C. I wouldn't write a robot arm driver in PHP. I wouldn't write anything more complicated than a throwaway script in bash.
I don't mean to be disrespectful, and perhaps I didn't read your reply right. But it seems to me if you don't differentiate languages, then you either don't have enough knowledge of and exposure to various programming techniques and language design ideas, or you're making an argument in bad faith.
> I wouldn't write a website in C.
With appropriate libraries, why not? The safety issues might be a problem, but you could sandbox it.
> I wouldn't write a robot arm driver in PHP.
I would. It's general-purpose enough to speak binary protocols without too much hassle, though it'd be more fun to use something else.
Ok, go ahead use air ducts as water pipes. Just "sandbox" it with some plastic wrap.
Web sites are full of strings, and C doesn't really grok strings. Not in the way WUFFS doesn't grok strings (there are no strings in WUFFS, it has no string type, it's not a general purpose language it's not for that), more like the way New Forest ponies don't grok traffic laws.
Jesus, we’re talking about primitive CRUDs here, not tegen engines.
I don’t know for 100% if that (hammer in a screw) was intentional or not, but it was beautiful.
Sometimes, you can salvage parts. Maybe the frame is still good when the customer reveals they actually want a minivan instead of a car. Maybe you can reuse the engine and wheels and transmission and seats. But the other stuff has got to be replaced.
Why is our industry so against rewriting? There seems to be a massive focus on building stuff so generic such that it is magically extendable into anything. Hint: it never is. It never will be.
Write specialized code, which is always smaller, clearer, easier to understand code against the heavily abstracted bullshit you'd otherwise get.
And yes, sometimes that means the "bicycle wheel" library/framework/language needs to be replaced in your shop.
You stare in horror at your new GoLand house with GoLand(tm) roof, floor, tiles and windows. At least it isn't Node you reassure yourself as the AWS bills roll in.
Which is to say, using the "right" tool is nice, but not always in the budget. R or Julia may be a better language for data science than Python, but if you're the only one using them, you're just making things harder for the rest of your team. A Python shop has probably invested in coding standards, linters, test infrastructure, common libraries, and has expectations for how code runs "in production". Expect that you'll need to clear at least some of that bar for a new tool you introduce. Expanding towards tools that better fit problems is good, but unless you're doing 100% green field development it needs to be intentional and measured.