11 ms·

Use the wrong tool for the job

97 points by BerislavLopac 4y ago

drewcoo 4y ago
[flagged]
- anonymoushn 4y ago
  > This is an article by the person who claims "syntax highlighting is a waste of information." This is not a correct summary of the linked article, and is closer to being completely opposed to the linked article, so it's weird that you cited it.
aryehof 4y ago
Rather than lazy programmers or evil managers, I think what primarily stops us keeping software simple is that we often seek to model complex systems, or code complex problems. Given this, the “wrong tool (technology or language) for the job” simply complicates the already complex?
- astrobe_ 4y ago
  Every time I have let complexity live, or increased it in a program, it was due to deadlines, bugs in third party software, artificial complexity in third party interfaces, fear of touching a part that's a "ball of mud"... Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. 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.
  - Beldin 4y ago
    This reminds me of the 737 MAX. It was deliberately designed to have a flight profile very close to the original 737 so as not to require retraining pilots. That worked adequately, but not good enough. (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.
  - acdha 4y ago
    > Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. 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.
- revskill 4y ago
  Because 10x programmers/architects tell us to do so.
travisgriggs 4y ago
I wish I could follow this guys advice. My colleagues are Microsoft camp guys. C# on the back end for anything they can. If your problem can’t be solved with a windows desktop app on whatever .net framework is trending, then it’s not a problem worth considering. 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?
- alexchantavy 4y ago
  I’m not familiar with the C# world but have you tried Xamarin? What are the gaps?
- manusachi 4y ago
  > but I went with Elixir instead and just wish I could use that everywhere. 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 :)
- owenm 4y ago
  As a thought experiment, this got me thinking what would a solution just using .NET core look like? Obviously I don't have all the details but I think you can do all of those things in .NET (with the exception of the embedded stuff probably). * 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-interface/map/ https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user... [2]: https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le [3]: https://devblogs.microsoft.com/dotnet/net-core-and-systemd/ https://devblogs.microsoft.com/dotnet/net-core-and-systemd/
ttr2021 4y ago
But is a programming language really a tool? I guess it's a tool that creates other tools..
- picture 4y ago
  A significant number of tools are created to create other tools
  - cdogl 4y ago
    And we use tools to create those too!
- wtetzner 4y ago
  I’d say programming languages are more like building materials than tools.
bruce343434 4y ago
Yet another software opinion article preaching mediocrity. Imagine a carpenter that only uses a hammer because learning other tools is too hard for them, and he'd have to bring his colleagues up to speed, and ah forget it we can use nails instead of screws anyway. "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.
- swores 4y ago
  The point isn't to use a hammer for everything, it's that you maybe don't need to get a new, slightly different sized, hammer every time you get a slightly different size of screw to hit in. And that when you want to pull a nail out you can use the other side on your claw hammer, rather than go hunting for a dedicated NailRemoverPro TM that you've heard will make your nail removal even smoother. 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.
  - bruce343434 4y ago
    Choice of language has much larger implications than you are implying. Yes, every language is turing complete. Now write a regex engine in pure "turing machine". Sucks, doesn't it? This is known as the "Turing Tarpit". 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.
AlchemistCamp 4y ago
The author repeatedly makes the case that people can handle more complexity when using familiar tools and that in many cases this can outweigh the costs of using familiar tools for tasks they’re poorly suited for. I completely agree! 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.
- azeemba 4y ago
  There is you the individual and there is the group at work. I think this article is talking more about making decisions that impact the workplace. 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.
  - deleted 4y ago
    [deleted]
  - marcosdumay 4y ago
    Groups can learn too. Ditto for future hires. Besides, if you are large enough for this to be a problem, you are large enough that everybody doesn't have to know everything.
Waterluvian 4y ago
This reminds me of an observation I’ve had: online when you see an expert tradesperson do something, they’ve got all kinds of specialized tools. Because they do the same kinds of things a lot and so those tools are worth buying and learning. But if you handed me those tools to do a job just once, I’d be much worse off than sticking to what’s in my workshop. 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.
- draw_down 4y ago
  Indeed, which is why “best tool for the job” is so painfully banal. What tool is best depends, and there’s the rub.
rwalle 4y ago
Just wonder why the font size is so large on my phone.
bazoom42 4y ago
I like this goes a level deeper than just the “keep it simple” mantra. Experienced developers know keeping complexity in check is critical but nevertheless keeping things simple is not always easy.
ChrisMarshallNY 4y ago
I'm in the process of rewriting an "accreted" codebase. The new one will be a lot more succinct, robust, customizable, localizable, accessible, and a hell of a lot faster. 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-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships... [1] https://littlegreenviper.com/miscellany/swiftwater/the-curious-case-of-the-protocol-default/ https://littlegreenviper.com/miscellany/swiftwater/the-curio...
Ericson2314 4y ago
I'm glad Hillel Wayne is getting into this, but as usual I am highly skeptical of the solution he is jesticulating towards. 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.
Consultant32452 4y ago
Technologists are better at understanding technology than business. If you are playing around with technology on your own dime, use the best tool for the job. If you are writing code professionally for a company, consider all the long term needs of the company. If you bring in a new language/framework/platform, they will have to staff for that. The default behavior should be to pick one of the most prolific technologies on the market and use that until it's no longer feasible.
pflanze 4y ago
I think OP is misunderstanding what "impedance" means? Impedance, at least in the context of electronics is describing resistance depending on frequency of the signal; if the incoming signal "vibrates" with a frequency that can make the receiver match it, energy transmission is large, otherwise low. Maybe I'm oversimplifying a bit, electronics or dynamic systems aren't my speciality. But the point is that two systems need to have the same impedance to move energy or a signal effectively. If the impedance matches, they "vibe" :) So it's about matching the impedance. It's about reducing the impedance mismatch between systems, not about reducing the impedance.
- rawgabbit 4y ago
  I never understood the impedance mismatch jargon. It still is unintuitive to me.
  - pflanze 4y ago
    I might actually go and track down and use the math on some example, and actually go through it myself for the first time--if I had the time. But I'm just barely non-busy enough to read HN at all right now. 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.
BerislavLopac 4y ago
As the old saying goes, "Python is the second best language for everything."
- ARandomerDude 4y ago
  Which really means “Python is a nice interface to whatever optimized code you’ll need to run.”
  - Spivak 4y ago
    Python is the language you want to write code in. Anything but Python is the language you want everyone else to use.
    - bbkane 4y ago
      I ameliorate this somewhat with strict CI/CD rules. Black + ruff + mypy can help keep Python sane.
      - guyrap 4y ago
        ha, I did not know ruff, used pylint until now. https://pypi.org/project/ruff/ https://pypi.org/project/ruff/
      - diarrhea 4y ago
        mypy still has some rough edges but in a couple years it’s going to be golden. My Python programs are already always fully typed and checked with strict settings. For all intents and purposes that’s 95% of the way of what a statically typed language provides anyway (if we ignore multithreading). 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-friend https://dusted.codes/the-type-system-is-a-programmers-best-f...
  - 082349872349872 4y ago
    After LISP, sh, TCL, and Lua all took a run at that fence, I'm glad something finally cleared it. cf https://news.ycombinator.com/item?id=34431984 https://news.ycombinator.com/item?id=34431984

97 points by BerislavLopac 4y ago

drewcoo 4y ago

[flagged]

anonymoushn 4y ago
> This is an article by the person who claims "syntax highlighting is a waste of information." This is not a correct summary of the linked article, and is closer to being completely opposed to the linked article, so it's weird that you cited it.

aryehof 4y ago

Rather than lazy programmers or evil managers, I think what primarily stops us keeping software simple is that we often seek to model complex systems, or code complex problems. Given this, the “wrong tool (technology or language) for the job” simply complicates the already complex?

astrobe_ 4y ago
Every time I have let complexity live, or increased it in a program, it was due to deadlines, bugs in third party software, artificial complexity in third party interfaces, fear of touching a part that's a "ball of mud"... Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. 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.
- Beldin 4y ago
  This reminds me of the 737 MAX. It was deliberately designed to have a flight profile very close to the original 737 so as not to require retraining pilots. That worked adequately, but not good enough. (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.
- acdha 4y ago
  > Rarely was it for technical reasons or because the problem domain was on the level of a PhD thesis - I would say they are "political" reasons. I think that's the daily life of the average programmer. 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.
revskill 4y ago
Because 10x programmers/architects tell us to do so.

travisgriggs 4y ago

I wish I could follow this guys advice. My colleagues are Microsoft camp guys. C# on the back end for anything they can. If your problem can’t be solved with a windows desktop app on whatever .net framework is trending, then it’s not a problem worth considering. 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?

alexchantavy 4y ago
I’m not familiar with the C# world but have you tried Xamarin? What are the gaps?
manusachi 4y ago
> but I went with Elixir instead and just wish I could use that everywhere. 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 :)
owenm 4y ago
As a thought experiment, this got me thinking what would a solution just using .NET core look like? Obviously I don't have all the details but I think you can do all of those things in .NET (with the exception of the embedded stuff probably). * 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-interface/map/ https://learn.microsoft.com/en-us/xamarin/xamarin-forms/user... [2]: https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le https://github.com/dotnet-bluetooth-le/dotnet-bluetooth-le [3]: https://devblogs.microsoft.com/dotnet/net-core-and-systemd/ https://devblogs.microsoft.com/dotnet/net-core-and-systemd/

ttr2021 4y ago

But is a programming language really a tool? I guess it's a tool that creates other tools..

picture 4y ago
A significant number of tools are created to create other tools
- cdogl 4y ago
  And we use tools to create those too!
wtetzner 4y ago
I’d say programming languages are more like building materials than tools.

bruce343434 4y ago

Yet another software opinion article preaching mediocrity. Imagine a carpenter that only uses a hammer because learning other tools is too hard for them, and he'd have to bring his colleagues up to speed, and ah forget it we can use nails instead of screws anyway. "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.

swores 4y ago
The point isn't to use a hammer for everything, it's that you maybe don't need to get a new, slightly different sized, hammer every time you get a slightly different size of screw to hit in. And that when you want to pull a nail out you can use the other side on your claw hammer, rather than go hunting for a dedicated NailRemoverPro TM that you've heard will make your nail removal even smoother. 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.
- bruce343434 4y ago
  Choice of language has much larger implications than you are implying. Yes, every language is turing complete. Now write a regex engine in pure "turing machine". Sucks, doesn't it? This is known as the "Turing Tarpit". 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.

AlchemistCamp 4y ago

The author repeatedly makes the case that people can handle more complexity when using familiar tools and that in many cases this can outweigh the costs of using familiar tools for tasks they’re poorly suited for. I completely agree! 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.

azeemba 4y ago
There is you the individual and there is the group at work. I think this article is talking more about making decisions that impact the workplace. 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.
- deleted 4y ago
  [deleted]
- marcosdumay 4y ago
  Groups can learn too. Ditto for future hires. Besides, if you are large enough for this to be a problem, you are large enough that everybody doesn't have to know everything.

Waterluvian 4y ago

This reminds me of an observation I’ve had: online when you see an expert tradesperson do something, they’ve got all kinds of specialized tools. Because they do the same kinds of things a lot and so those tools are worth buying and learning. But if you handed me those tools to do a job just once, I’d be much worse off than sticking to what’s in my workshop. 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.

draw_down 4y ago
Indeed, which is why “best tool for the job” is so painfully banal. What tool is best depends, and there’s the rub.

rwalle 4y ago

Just wonder why the font size is so large on my phone.

bazoom42 4y ago

I like this goes a level deeper than just the “keep it simple” mantra. Experienced developers know keeping complexity in check is critical but nevertheless keeping things simple is not always easy.

ChrisMarshallNY 4y ago

I'm in the process of rewriting an "accreted" codebase. The new one will be a lot more succinct, robust, customizable, localizable, accessible, and a hell of a lot faster. 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-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships... [1] https://littlegreenviper.com/miscellany/swiftwater/the-curious-case-of-the-protocol-default/ https://littlegreenviper.com/miscellany/swiftwater/the-curio...

Ericson2314 4y ago

I'm glad Hillel Wayne is getting into this, but as usual I am highly skeptical of the solution he is jesticulating towards. 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.

Consultant32452 4y ago

Technologists are better at understanding technology than business. If you are playing around with technology on your own dime, use the best tool for the job. If you are writing code professionally for a company, consider all the long term needs of the company. If you bring in a new language/framework/platform, they will have to staff for that. The default behavior should be to pick one of the most prolific technologies on the market and use that until it's no longer feasible.

pflanze 4y ago

I think OP is misunderstanding what "impedance" means? Impedance, at least in the context of electronics is describing resistance depending on frequency of the signal; if the incoming signal "vibrates" with a frequency that can make the receiver match it, energy transmission is large, otherwise low. Maybe I'm oversimplifying a bit, electronics or dynamic systems aren't my speciality. But the point is that two systems need to have the same impedance to move energy or a signal effectively. If the impedance matches, they "vibe" :) So it's about matching the impedance. It's about reducing the impedance mismatch between systems, not about reducing the impedance.

rawgabbit 4y ago
I never understood the impedance mismatch jargon. It still is unintuitive to me.
- pflanze 4y ago
  I might actually go and track down and use the math on some example, and actually go through it myself for the first time--if I had the time. But I'm just barely non-busy enough to read HN at all right now. 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.

BerislavLopac 4y ago

As the old saying goes, "Python is the second best language for everything."

ARandomerDude 4y ago
Which really means “Python is a nice interface to whatever optimized code you’ll need to run.”
- Spivak 4y ago
  Python is the language you want to write code in. Anything but Python is the language you want everyone else to use.
  - bbkane 4y ago
    I ameliorate this somewhat with strict CI/CD rules. Black + ruff + mypy can help keep Python sane.
    - guyrap 4y ago
      ha, I did not know ruff, used pylint until now. https://pypi.org/project/ruff/ https://pypi.org/project/ruff/
    - diarrhea 4y ago
      mypy still has some rough edges but in a couple years it’s going to be golden. My Python programs are already always fully typed and checked with strict settings. For all intents and purposes that’s 95% of the way of what a statically typed language provides anyway (if we ignore multithreading). 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-friend https://dusted.codes/the-type-system-is-a-programmers-best-f...
- 082349872349872 4y ago
  After LISP, sh, TCL, and Lua all took a run at that fence, I'm glad something finally cleared it. cf https://news.ycombinator.com/item?id=34431984 https://news.ycombinator.com/item?id=34431984