Hacker News Reader

"Unfortunately I forgot the exact quote and the author. (If anyone knows please let me know)."

I said something similar in 2018[1], "You haven't mastered a tool until you understand when it should not be used."

[1]: https://twitter.com/kelseyhightower/status/96342809329245798...

Yes this is exactly the one I was referring to. Thanks!

Progress doesn't follow a linear pattern, it's more like a jagged line slowly trending upwards.

Recently (as in the past few years), it feels more like it's not trending upwards anymore, just jumping around an equilibrium point and maybe even slowly declining.

Junior engineers don't know these trade offs, they end up using sophisticated hammers for their screws.

They also end up making hammer factory factory factory factories.

(http://web.archive.org/web/20150106004241/http://discuss.joe...)

>They also end up making hammer factory factory factory factories

Funny but accurate article! I did not know they saw that as a problem in 2005, which means it could be a lot more factories by now.

And also, the idea of "architecture astronauts", in the text written almost 20 years ago:

https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

"Why the hell are people so impressed by boring architectures that often amount to nothing more than a new format on the wire for RPC, or a new virtual machine? These things might be good architectures, they will certainly benefit the developers that use them, but they are not, I repeat, not, a good substitute for the messiah riding his white ass into Jerusalem, or world peace."

"Remember that the architecture people are solving problems that they think they can solve, not problems which are useful to solve. Soap + WSDL may be the Hot New Thing, but it doesn’t really let you do anything you couldn’t do before using other technologies — if you had a reason to. All that Distributed Services Nirvana the architecture astronauts are blathering about was promised to us in the past, if we used DCOM, or JavaBeans, or OSF DCE, or CORBA."

Note: that kind of "selling points" was "promised to us in the past" even then.

Also, not even distributed anything is necessary for architecture astronauts, one can "architect" any task:

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

The oldest form of "architecture astronauts" food I personally had to fight against was Grady Booch's "Object Oriented Analysis and Design With Applications" from 1991/1994. It resulted in many enterprises wasting immense amount of time even in the nineties.

You are making a lot of ageist remarks. There are plenty of Senior engineers making wrong decisions. For example the istio project moved from microservices to monolith - https://blog.christianposta.com/microservices/istio-as-an-ex... and none of those engineers are "junior engineers" by any means.

"You are only an expert in a given technology when you know when not to use it"

This is such a great quote. I would also love to know the origin.

I'll also bite on the when not to use static typing bit. Not using static typing is a bit of a misnomer because you can use a statically typed language and just use `String` (or `Bytes`, `Object`, `Value` or whatever the equivalent is in your language). The question is more of whether to use one of these catch-all structures or to use a more structured domain-specific type. And the answer here is when you don't need all of the structure, don't want to force the whole thing to validate, etc. For example, maybe you have JSON getting read into some complex customer data structure. If you only need a single field out of the structure, and haven't already parsed it into the customer data structure for some other reason, it might be best to just reach in and grab the field you need. You can think about it kind of as the principle of least context but in a data parsing scenario.

> I would also love to know the origin.

FWIW, there's a very old Russian joke that goes like "a novice doesn't know how to do it, a pro knows how to do it, and an expert knows how to avoid doing it".

>when not to use static typing

I'll bite. When should static typing not be used?

(Note: I agree with your general point)

When I’m throwing together a quick script, or maybe some minor piece of automation, Python is my go-to language.

For any decently large project, though, I prefer static typing.

I'd kinda prefer it then, too. If it's short and I'm just scripting stuff up it's probably mostly calls to existing code (libraries) so almost all the static typing would do is tell me when I'm screwing up and give me hints for valid arguments with types and names, with little or no added overhead. It'd be very nice.

Consuming types in that context is nice, defining them is what's generally a PITA / extra boilerplate / overhead.

To take a concrete example that could go both ways: Say you want to parse a JSON blob for some task. On the one end, you could access it through dynamic typing, or tools like jq, that don't need a schema for the entire data format. At the other extreme, you could make typescript definitions defining a schema for the entire format.

The more the same data gets (re)used, the more worthwhile taking the time to define a full schema is. But to download and add type definitions (often out of date and in need of further tweaking) for every once-off API request? Way more effort than it's worth.

Most static type systems do not force you to say what’s the entire shape of the data, just what the shape of the data you need is.

In fact its a good practice to do in general. So that when processing the json blob you tell what only your processing requires.

What you get is that if for example you do your validation, but then by chance you touch more data that you’ve checked for, the types will tell you you are dangerous waters, and you can go update the validations.

This is especially useful if you’re not the original author or if you’ve written it several months back and don’t remember the details.

Static types are really cool that way, and can be treated as just a faster to write and faster to run and always up to date unit test.

When the communication loss (visual noise) from the added static typing info is of bigger impact than benefit type safety offers you.

All of which depends on a lot of variables.

My heuristic is that if anyone else will ever read the code, it should be statically typed (or be written in a language like shell where the language is essentially limited to one type).

Most people disagree, but then they end up writing giant python monoliths with layers of implementation inheritance, dependency injection and functional programming paradigms.

In the end, they try to port it to pretty much any other language, but at that point it’s too late.

Python has a pretty good type checker.

For me it's where I'm developing a task to do stream processing and classify the data by an arbitrary subset of the data and don't want to model the entire structure to avoid losing/changing the original data structure.

I'm sure there's better ways to do this, but that's an example I'll throw in.

Many AAA games implement their engines in C++ but use something like Lua for game logic.