LOL, this hits close to home. My company had a modeling specific VM set up to run our predictive modeling pipelines. Typical pipeline is about 50,000 to 5 million rows of training data. At best, using an expensive VM, we managed to get 2x training speed from lightgbm on the VM vs my personal work laptop. We tried GPU boxes, hyper threaded machines, you name it. At the end of the day, we decided to let our data scientists just run models locally.

After that we colo'd 4 big Xeon servers for about $1,600/month total. Looking back on it now it's just so insane...$30,000? no way.

There's just so many better things for your company to be spending the money on.

We don't let pencil pushers with MBAs anywhere near what we're doing, and it's going great.

I know this isn't the most usual configuration but if undervaluing my skills and trying to bottom dollar on them is going to be their rules, then I'm just going to do my own thing, and they're just going to have to scrape the bottom of the barrel for talent.

I hope the zeitgeist changes any time soon. God knows how many unicorns have been sacrificed with that kind of paradigm which could be successful companies by now.

I don't know how that changes the equation. No one is undervaluing your skills; it's would you rather spend your time driving to a colo center to replace a RAID array or working on $product.

With AWS you are outsourcing an IT team, not just processors and how you approach pricing should reflect that.

If you’re doing colocation to save money, you’ve also figured out that going to the datacenter sucks and it’s a terrible place to do work.

You’re not building your own servers from scratch, you’re generally purchasing them from a vendor who offers a warranty and optional on-site service.

Or you’re leasing them from a hosting company who will take care of those pesky RAID alarms for you.

You (or your hosting providers) have likely outfitted your server with remote out-of-band access to allow you to get into BIOS or the RAID controller without physically being in front of the server.

And finally, you have remote access to power cycle the server (or a batphone at your hosting provider to do it on your behalf).

I want to say that these datacenter-visit-prevention techniques have been near standard practice for a decade-and-a-half.

Or is it just me and my circle that do this?

Nope, this seems to be the norm. I've worked on a couple colo servers that nobody at the company had ever actually seen in person. They figured out colo in Germany was the best deal, so they had some servers delivered straight to the DC and the staff there installed them and plugged them into an IP KVM. Not sure if this is a standard service most providers offer, but I'm sure a big enough cheque would convince most - and considering the cost of transporting both the hardware and engineer to install it, that cheque can be quite large.

Take all those things you just talked about, and expand them horizontally and vertically up the stack, and you have 'AWS'.

So not just 'a guy to replace the hardware' - but now it's software configurable, has all sorts of other, fancy things.

Time is money, and it's expensive to pay people to mess with things if they don't have to.

It's like this:

If your company needs 3 cars, you rent/lease them. You do not hire your own mechanics, even if technically speaking "we could change the oil for so much less!"

If your company is in the business of transportation, and you have thousands of trucks, you may want your own repair/maintenance team etc. instead of paying some service company a fat margin to change the oil.

Our in house data centres we visit more often, usually to add new equipment, doesn’t take long to walk down stairs.

I can’t think of the last time a hard drive failed

For most things 'local prem' is an optimization that usually needs on some degree of scale to justify, or, you have a peculiar setup i.e. a couple of well versed hardware and networking guys who have no problem with a bit of a physical setup. Which can be a bonus.

"I hope the zeitgeist changes any time soon."

No, it won't, it's going in the 'other direction' forever, because the 'economies of scale' at Amazon, it's incredibly difficult for individual engineers to compete with those efficiencies.

Just the opposite of 'being a problem for startups' , the 'cloud' has basically made entire swaths of types of startups possible where they wold not otherwise.

Like everything, you have to use think about it a bit but their costs are really, really transparent (imagine Oracle trying to do it ...).

What a glib and senseless follow up.

Also, it's not peanuts. How many extra developers are $28400 per month?

No, actually they don't. In the time I've been there they've 10x the size of the company. Maintained majority control through multiple rounds of funding. Significantly increased salaries. Provided a great work life balance. Etc.

Why are developers obsessed with how many additional developers they could hire with hypothetical savings?

This then means that while op wouldn't immediately add 1M ARR, the original dev and the new devs could soon add 5M ARR (stupid extrapolation, it won't be as much in practice, at least normally)

According to my napkin calculus, you could get about 4.5-9 developers (for 1-2x minimum wage) onboard here in France for 28k€/month. I'm betting in other countries with low salaries and a vast talent pool, 28k€/month would get you even more employees.

In Austria, the "IT Kollektivvertrag" [0][1] (think contract for the whole IT collective/unions) demands a minimum of €2503 brutto (before taxes) per month for developers (those are normally falling under ST1 category), and that 14 times a year, and that's for entry level (as in, not first job but starting at a company). Note also the 14 times a year, where the last two extra salaries (Christmas pay for December and vacation pay for June) is taxed much less (note, we can get bonuses on top of that too).

[0]: https://www.wko.at/service/kollektivvertrag/kv-abschluss-inf...

Note for above PDF (only the short money table the full one can be easily found via searching "Austria IT Kollektivvertrag 2022"):

- The ST1 is for devs, and LT1 for leadership roles.

- "Einstiegsstufe" is Junior, "Regelstufe" is "normal" and "Erfahrungsstufe" is Senior

So if you get hired as senior in a leadership role you'd be entitled to €5521 Brutto salary, 14 times a year, or more depending on your experience/knowledge and your negotiation skills.

In France a young developer easily costs €100k/year to employ, even if he earns a third of that before taxes.

It will be an interesting next few years.

ARR could be whatever. They are not interchangeable or mutually exclusive.

8 channels of DDR4-3200 only provide 200GB/s bandwidth. RTX 3090 has 936GB/s. So even 4 socket Xeon won't catch up.

Many if not most other algorithms are iterative. Hell, even sorting is.

GPUs are like heavy flywheels. Getting them up to speed takes some time (copy data, compile and copy the kernels, kickstart everything, etc.), so you need to start them once to get the performance benefits. Otherwise CPU is much more nimble since they're closer to RAM and made to juggle things around.

I guess it's time to invent a blockchain that trains ML models as PoW :)

As a sidenote, I have rented servers with GeForce cards from multiple providers in multiple countries, so this rule doesn't seem to be respected very much. And since it's part of the driver EULA, nvidia can't legally go after server providers, since they don't install any drivers, just build and rent out the hardware. For all they know, all their customers are running noveau.

[0] https://www.datacenterdynamics.com/en/news/nvidia-updates-ge...

There are some data sets where you really do need big-data tools, but it's for when you have petabyte-scale data, not megabyte/gigabyte-scale data.

However the complexity of the algorithm many times scales with the size of the dataset, either the full corpus or the size of individual examples.

It get's you ~10x speedups for batch predictions, more if your model is big. It's not complicated, it ended up being <1K lines of Python code. I heard a couple of stories like yours, where people had multi-node spark clusters running LightGBM, and it always amused me because by if you compiled the trees instead you could get rid of the whole cluster.

[1] https://github.com/AnotherSamWilson/miceforest

AWS EC2 has a VT1 instance family that enables high-speed A/V encoding via a Xilinx media accelerator card.

I think data scientists just aren't really hugely concerned with programming optimizations or bottlnecks or whatever. Most of them are just intermediate-level python programmers, and that's completely fine until they think they need a hadoop cluster for whatever they're doing and the costs start piling up.

At least to me, the big advantage of static typing is not that it (allegedly) reduces bugs, but that it aids my understanding and helps in navigating the program. It's a tool for thinking and communicating.

My working day jobs have been mostly C++, and these days C#. Periodically, I will temporarily inherit some of my younger colleagues' projects, if they move on to greener pastures in different companies, with the charter of "can you do something about the long-running issues this software has been having?" My go-to solution is to go through their typescript and add return types to their functions, and replace their anys with interfaces. After having done that, I fix the bugs that revealed, and then I'm usually done. Recently when I did that, I came across a central class/data structure, which turned out to exist in no less than 5 slightly different variants. i.e. different parts of their code adhered to 5 different assumptions about what fields would exist and be populated (but all expressed on the blank canvas of 'any').

The problem is, other people with just as many credentials as you have the opposite experience. From an outsider's perspective, two people with equal authority say opposite things, what can they possibly do except an independent study?

Also, note that there's a reason anecdotal evidence is not always reliable. E.g. the famous story about fighter pilots and the "regression to the mean" hypothesis.

In this scenario, I honestly don't think it matters whose objectively right. Software is not a clean, normalized and organized set of use cases after all, maybe static typing works for person X and doesn't for person Y because of their background, or preferences, or codebase requirements, and so on.

Maybe one day we can conclusively prove that on aggregate static-typing/{insertThingHere} is overall less buggy, but even if we did, it'll still change depending on circumstances.

On the other hand, though: have you worked with large, thoroughly tested projects in a dynamic language? Personally, I find that good tests catch 99% of the bugs that static types do, plus quite a lot of other bugs as well. Arguably, you ought to write tests anyway to find those other bugs. Since they also find your typos etc, you get to enjoy the ergonomics boost of dynamic typing almost for free.

That's my (also anecdotal) argument for doubting static types.

Removing traffic lights and stop signs actually reduces accidents because drivers are more careful when driving through intersections which reduces speeds and drivers become more alert.

Developers will adapt to their toolset. If you have a statically typed language, you trust it will deal with type related issues and you become more lax with testing things related to types. When you develop in non-typed languages like Ruby, you tend to write more tests and not trust your compiler (because you don't have one). This is why you will find most Ruby developers are really good at writing tests and embracing TDD.

A type system can keep you from having to write those tests.

The claim is true: a type system _can_ prevent null-related issues and eliminate the need to account for them in tests. That's not the same as saying every type system does.

Static typing gives you assurances and tools with which to test your assumptions in the code, for those times when reading the whole stack is cumbersome, and you need to defend against less careful developers. It also transfers a bit of knowledge between developers in a trivial way that would otherwise be a pain to communicate.

In my experience similar arguments hold for software developers. Especially caring can be a big factor; i.e. the "move fast, break things" mentality.

I've been back and forth between typed and untyped languages (somewhere in the range of haskell and tcl) and personally prefer less typing when hacking things together and more typing for high quality software. I'm currently working an infra job where we use both ansible and terraform. They're not direct competitors, but I tend to prefer terraform over ansible when possible, as terraform gives me more "static" guarantees, which translates to more confidence when we apply our code.

Where this falls apart, the more verbose writing style hasn't been proven to convey more information or in a better way. That's an assumption still tossed around.

And typed or untyped, you’re only ever reasoning about the types in the context you’re working in, not the entire program.

A Python function can be called from within or from outside of your codebase with different callsites passing different types.

This can make it much harder to actually reason about the code, while making it seem easier to reason about. Most people would agree w/ your reasoning on a short piece of logic, which then at runtime spectacularly fails because the inputs don't adhere to the types you expected. In a statically typed language you would not even have gotten it to compile and while it might not feel like a bug is being prevented and actually feel tedious, every time your IDE (or compiler) tells you that the type on something is wrong, you've prevented a potential bug.

Let's say we compare Javascript and Typescript (as they're so close but one has static typing.

    const myFunc = (param) => {
        doSomethingWith(param?.property);
    }

Now let's take something that is almost equal but slightly longer to read and write, same thing in Typescript. I've had to define the types of these things somewhere once. Big deal.

    const myFunc = (param: SomeType) => {
        doSomethingWith(param.property);
    }

Now syntax will be a little bit different, but I would argue the exact same thing in say Java or Kotlin is equivalently short and readable (yes even in Java!) while benefiting from even more type safety:

    public myFunc(SomeType param) {
        doSomethingWith(param.getProperty());
    }

But these are super simple example. It get can arbitrarily complex.

But Java, Kotlin, and Typescript types are very weak sauce. When types can do more, we can do more with them.

I associate verbosity with object-oriented programming, whether statically typed or not.

Here's something I can express with static typing that I can't express with dynamic typing: "this function returns a function which returns an integer for every input". There's no test you could write to verify this property. So I'm inclined to say that static typing is more expressive, since it gives me a way to express and verify properties like this.

Without compile-time types, you are not equipped to express serious compile-time work.

And yet, per TFA, it’s not; at a minimum it’s clearly not “self evident”.

Why do we developers value our personal experience above studies, while dunking on average citizens for doing the same?

Guess we’re just as human as the rest of humanity; subject to the same urge to trust our own beliefs over contrary evidence.

Cold shower attempted, but the plumbing was busted?

Such studies invariably wholly miss the point: when you have a language with powerful type support, error checking is the least valuable work you get out of them. Types do serious heavy lifting expressing semantics.

And at the end of the day you have to contend with being in a work environment where politics and personalities rule, not science (or engineering).

That said I do wish more devs would take an interest in the available quality literature. Unfortunately I'm far more likely at work to run into an Uncle Bob recommendation at work, than a recommendation of ACM's Digital Library.

However, refactoring code in C# is much easier than refactoring ruby because you can lean on the type system there. However writing new code in C# is often much harder to do in C# because of the constraints of the type system. So really, it ends up being a wash for me.

If you have not seen them, the reason is probably that the code was tested well enough before you looked for the bugs.

That's the point though. With dynamic typing you would only (hopefully) catch this with manually written tests. With static typing you get that feedback for free at build time.

How would that pass any code review, regardless of static or dynamic typing?

What kind of clown show of a programming org are you working at?

This is morally equivalent to "There's no point to having a safety on a gun, because the safety won't stop you from bashing someone in the face with the gun." If you really want to, you can throw exceptions or crash the process or call exit() or call system("shutdown -h now") anywhere in your codebase. That has nothing to do with a type system.

See, When I'm throwing together apps to clean up configurations, I am Pythonifying XML often. And when handling different return values, reshaping it into the useful components I need and trying to analyze data (and dealing with different return formats depending on number of results, aka a dict if there is one value, or a list(dict) if there are more) I have to constantly remember if I am going to be getting a list(dict(dict(dict(str)))) or just a dict(dict(string)), and so on. But that's me cobbling together scripts and not understanding the API by heart well enough.

This is false.

TypeScript, Swift, and Rust are commonly used and support non-nullable references.

> those languages, don't help you because you are dealing with real world data where inputs to your system can be null or not so you end up using some type system escape hatch anyway.

You don't need escape hatches to deal with "real world data" that may be missing some values. This blog post is my favorite detailed comparison of handling "real world data" in static vs dynamic languages: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...

Rust's serde_json docs on "Operating on untyped JSON values" are also a pretty good description of working with "real world data" where you want to examine an arbitrary document: https://docs.serde.rs/serde_json/#operating-on-untyped-json-...

The only requirement for working with "real world data" in a static non-nullable language is to choose whatever kind of behaviour you want when working with the data. Everything you can do with null references, you can do better with option types; there is nothing that null references uniquely permit.

1. Python with mypy has `strict_optional`. On by default.

2. C, being “portable assembler” is not really statically typed.

3. Java has had Optional for years, although it’s not the most pleasant to work with it does exist. And JVM languages like Kotlin go well beyond this.

4. C++ has `not_null`.

5. C# supports type-system enforced non-nullable types since 8.0.

You said:

> languages that disallow nulls, if you are one of the 10 programmers on earth working in one of those languages

I hope it’s clear that you are simply incorrect. There are plenty of tools to eliminate nullable references in modern mainstream languages.

Most importantly in C++ only pointers can be null. You can return value types that are not nullable.

There have been people writing at least two of those languages everywhere I've worked for a while. Most of my professional colleagues can write at least one of these comfortably. I'm extremely confident in being able to hire programmers for all of these. They're all in use at every major tech company.

If you really want to stick your head in the sand and cry about how nothing can be better until they're literally top of the charts, I can't stop you, but they're certainly not rare. There's good stuff out there. Lots of people are using it. You can too.

If you'd rather trade links to charts, I trust Stack Overflow's developer survey's methodology a lot more than TIOBE's. 30% of respondents said they've worked with TypeScript, and that jumps to 36% in the professional developer subset. Rust is 7%/6%. That's a hell of a lot more than 10 developers.

https://insights.stackoverflow.com/survey/2021#technology-mo...

They also got 15% of developers who aren't using TypeScript want to use it, and 14% for Rust:

https://insights.stackoverflow.com/survey/2021#most-loved-dr...

My country has about 15% black people about about 7% asian people. My country has about 4% LGBT people, and my city has about 15% LGBT. It would be really weird to hear someone say that black, asian, and LGBT people are not common, especially after knowing and working with plenty of them.

You clearly have little experience with such languages, then.

It makes you actually have to consider scenarios where a variable can be none or not and try to push the validation up closer to where it entered the system.

Also in the opposite direction, many dynamically typed language allows specifying types if you want to including python.

x still has static type, the compiler just infers it based on the assignment, the type information is still there. Agree that implicit/unsafe casting is still and issue in some languages though.

I suppose it's not even necessary to argue about experience fixing them or not, just the fact that those are runtime errors rather than compile-time (and so we presume not shipped) shows it reduces bugs doesn't it?

And Unlike typescript my code doesn't need to be transpiled at all since it is already vanilla JS.

I want a shirt with this on it.

It may not be very comprehensive static typing but it is static typing none-the-less.

These are two very different outcomes.

If the remaining bugs are unrelated to the class of bugs that were eliminated entirely, then the difficulty in finding them has little bearing on the outcome, since we’re now talking about an entirely different class of bugs.

It seems you're describing an orthogonal issue, and it's unclear why type checking is a Bad Thing or even related to the NPE at all.

Let's say I work on an assembly line, and must place physical parts into a machine that assembles a larger part. There are many ways this machine can break down - I could put the wrong parts in, leading to a complete failure, or some part of the machine could malfunction independently.

- We could implement part validation on the assembly machine to make sure it's impossible to insert the wrong parts. This eliminates failures related to incorrect part insertion.

- Unrelated to this, a drive belt starts to wear out and slips every so often, leading to a slight slowdown in a conveyor belt, which ultimately leads to a botched item.

The way I read your argument, you would say that part validation is bad, because it's easier to diagnose a meltdown when incorrect parts are inserted by the operator than it is to determine that the drive belt is slipping.

Except the drive belt slipping is not related to operator error, and would have happened whether part validation was happening or not.

This is hopefully obviously nonsensical - better to reduce the overall error rate by implementing part validation than to leave two avenues for error. Before part validation, the machine could fail because of operator error (common) or drive belt failure (uncommon). After part validation, only the uncommon error occurs.

This is better than no validation at all, even if drive belt failure is harder to identify than the machine screeching to a halt when the wrong parts are inserted.

What am I missing?

All the other claims from readability to understandability to refactoring to less bugs, all come with an “it depends” caveat. Sometimes the claims are true, sometimes they’re not. It’s also not possible to say “but in most cases claim X holds”.

The thing I’ve never understood yet in this debate is in my experience, the people who have argued about correctness have universally been below par at getting to the bottom of requirements. Which leads to “great, you correctly built the wrong thing. And you took forever to do it.” Which isn’t doing our profession any good in the eyes of other professions who depend on us.

Static typing reduces bugs because it aids your understanding.

Not sure though.

I remember working 2012 on a SaaS app, and I wasn't the only guy anymore doing frontend stuff with JS. I knew my objects, but my colleagues did not. How to you document object APIs? TypeScript really shines in large projects with lots of devs.

    def add_item_to_cart(item)

    void add_item_to_cart(IItem item)

I guess you now need to read through the implementation or docs. The first is much easier to read incorrectly.

The only citation I have is the tenuous grip I have on my own sanity - I could have more correctly talked about the incredible amount of mental overhead this has _for me_, but read the rest of the thread and you’ll see that this isn’t an uncommon experience. As I said, if you can work around this then you have my respect.

Of course you could say the same thing about sane naming dynamic naming conventions for your declarations in a dynamically typed language - and you wouldn’t be wrong, but a compiler won’t help you in the case of human error. All I’m interested in is offloading as much complexity onto the tools at my disposal, so I can focus on what’s important.

On my citation … that was tongue in cheek and I thought it was obvious. I don’t have a citation, this is all my own experience. For the third time, if you can work your way around this you have my respect.

That definition is rarely as accessible as an explicit type though. For example take an API response or any third party library. Determining the data type isn't as quick as simply scanning a function for the object definition.

- Dynamically typed languages are very popular so it seems that many developers can work their way around dynamic typing.

As someone who has spent a fairly even mix of their career using typed/untyped languages, I think this is due to a few reasons:

- Lower initial learning curve.

- Lower barrier to entry.

Those are real benefits, but I would argue most projects quickly hit a point where they benefit from static analysis.

Having worked with 100s of devs at this point, I'm yet to meet one that after learning a typed language and using it for a sufficient period of time (more than a few months) wants to use an untyped language for anything outside of small scripts.

You're confusing Java-type extreme (and also mostly strawmanned) application of OOP with static typing.

Not every type in your program has to be AbstractFactoryProxyBeanInterface, and if you don't write code like that it's either obvious or some kind of extension interface for non-core code.

You've never worked with vaguely named variables? What you are suggesting is guessing the data type based off the name.

- What type of object? The type that can be added to a cart.

Okay sure, but what precisely is that?

- Nobody just throws random objects at a function.

I couldn't agree more - so the follow up question is what is the fastest way to get familiar with what type of input or output this function returns?

- They are familiar with the code in general and they know what to do.

For very small projects with very small teams after some onboarding time perhaps, but outside of this I would disagree.

Code changes over time, parts that you use to know intimately get changed subtley and erode knowledge away. Having types in place highlights these changes if your assumptions are incorrect.

It doesn't matter "what precisely" is the the thing that you are adding to the chart, and a static type system won't tell you that either. There could be be any of 1000 things that implement IItem. And probably half those things just throw exceptions for methods they aren't actually able to implement.

    addItemsToCart(items)

    Type ItemCode: string;
    Type ItemDetails = {...};
 

 
    addItemsToCart(items:ItemCode[])

    addItemsToCart(items:Record<ItemCode, ItemDetails>)

EDIT: please excuse formatting, I'm on mobile and cannot get it to add spaces before the last code block

You need the same tests from a typed system in a non-typed. You _don't_ need all the tests from a non-typed system in a typed system.

Writing tests to enforce types just hand-rolls a type system, in my experience.

You do though, because invariably people violate the LSP and just "throw Unimplemented" in the methods required by the interface they can't figure out how to implement. In other words all system are duck typed in reality.

Not sure what typing system you're referring to, but it sounds very half-baked at best. I'm using Rust fwiw.

I cannot access any field or method that does not exist. Even dynamic traits are compile time enforced, but i think we can largely have this discussion around static dispatch.

You can do that with Python (sometimes) because many libraries have type hints today, so even if you don't use types yourself, the type checker can infer them in your code and help you out.

The same way Rust checks for object lifespans with the borrow checker, which is distinct from the compiler and type system.

The same way valgrind for C can check for use after free.

The same way errorprone can look for null checks in Java.

This is a well tested and proven technique. Static code analysis is a staple of the industry, when it comes to automated code analysis.

All of the examples you gave are from static languages, where the information is known at compile time (except for valgrind, which requires a runtime). The parent to my original post was claiming that you can have the same tooling for Ruby.

Also, you're wrong about Rust. Lifetimes are part of the type system.

  void add_item_to_cart(auto item)

And when we understand this, we can weigh it up with alternative tools for thinking and communicating!

Would this 10 line shell script be better in a statically typed language? Well maybe not because I can hold all of 10 lines in my head, there's nothing else to communicate.

Would this CRUD app using Django/Rails be better with static types? Well the framework has defined a structure that communicates properties of the code to me, I don't need types written down because I already know them.

Would this complex parsing process of untrusted data into a trusted and verified format benefit from static types? Yeah probably, testing will be tricky and code review for security is hard, types will help reason about the possible states of the system.

There are lots of alternatives to static types: documentation, testing, frameworks, design patterns, code review, pair programming, error messages, and so much more. I'm generally a fan of static types and find them very useful in a lot of development, but they are a tool in a big toolbox.

In a sense "type coverage" is analogous to test coverage.

function myFunction(user, security) { }

good luck finding out what user and security actually is. In static typing, it's all there.

That’s a dynamic typed language with comments

It’s only hype because it’s imprecisely stated. Static type systems make entire classes of bugs impossible at runtime. The stronger (read less permissive) the type system, the more classes of bugs cannot occur.

Everything's a trade-off, the question is which approach is best for your application. Your average website doesn't warrant as much rigor as a Mars rover.

1) Statically typed languages with inference don’t require time spent writing signatures.

2) I know I’ve spent time chasing down bugs in dynamically typed software that would have been caught by a type checker.

3) I also know I’ve spent time writing tests for conditions in dynamically typed code that wouldn’t pass a type checker.

Type checking also introduces its own set of additional bugs by the virtue of object incompatibility, that do not exist at all in dynamically typed languages (or are handled correctly every time by the compiler/interpreter automatically).

Take as an example exchanging objects over sockets, rest, files, etc. Whenever the object definition changes in another piece of the software stack the statically typed parts will crash upon receiving the updated objects, even if it's just one new param added that would've been fine otherwise if dynamically typed (or say change from a float to a double which can be irrelevant). A nightmare in systems with lots of moving parts.

One might say that's working as intended, and it of course is, but it also forces you to fix and recompile all of that for no real net gain. Hence the longer dev time I mentioned.

I've spent years working with statically typed languages, and I honestly don't think I'll ever go back to them in any professional capacity.

Anecdotally, this is not true for C++ using JSON or msgpack, since those are self-describing formats where extra fields are safe to ignore.

And it's not even true for Rust using serde, which writes the serializing / de-serializing code for you. serde_json will also ignore unknown fields when parsing, and you can preserve the original object as a `serde_json::Value` in case you want to pass unknown fields downstream as opaques.

Protocol buffers and Flat Buffers also have solutions to this, and all 4 of these formats are pretty popular in both static and dynamic languages.

Even if you write a custom TLV format, this is not that hard to deal with.

Was this common in the static code you worked with? You weren't just casting objects to `char *` and doing a `memcpy`, I hope?

Now, being able to assert that a field is present in an object is a basic and valuable use-case for static typing. However, the developers felt that even this basic level of static type checking added too much friction whenever they had to update systems.

https://capnproto.org/faq.html#how-do-i-make-a-field-require...

You appear to completely misunderstand what static typing means. Runtime crashes due to type mismatches are exactly what static typing prevents.

(Well you could, but then you'll be introducing a whole set of problems if the other system has a static type system that behaves differently from your application's static type system)

What are some strong examples of this? Haskell does an amazing job with it. Java technically supports some amount of inference, but it doesn’t reduce verbosity by all that much. Apart from those I haven’t run into it.

Dynamic typing only increases development speed for the first few thousands lines of a solo programmer project. After that it is, in my personal experience, a significant drag on development speed.

Furthermore, dynamic typing makes modifications and new features significantly harder to write. Turning compile-time bugs into runtime bugs is a catastrophic decrease in development speed.

That’s my personal experience at least. YMMV.

> dynamic typing makes modifications and new features significantly harder to write

Depends on what you're doing I suppose.

Adding a parameter to an object? With dynamic typing you just add it to the object in literally any location, no issues. With static typing you might just need to refactor half your codebase if you have lots of interfaces. Have fun resolving merge conflicts with your team.

Not only that, but (in Java as an example) serialization codes for objects will change unless you planned for that previously (you didn't), making old objects impossible to load. A completely new bug that's created solely by static types. And it's not the only one.

Maybe it's an issue with Java. In Rust if I add a new field, I just wrap it in an Option.

When de-serialized, old objects have a None, new objects with the field have a Some. When serializing it's just `Some (5)` instead of `5`, if it's an int.

No runtime crashes from nulls, either.

I am not sure that that is correct. Type inference significantly decreases development time imho, and access to compiler errors means significantly less testing time because a certain class of errors is avoided.

Personally, I find that my productivity w/ Haskell was significantly higher than with python exactly because of the type system even though I have 3x the experience in years w/ Python.

I have inherited (hah) a project at work and had to introduce all sorts sanity checks (mypy, pylint, etc) as pre-commit hooks to make my life easier wrt bug hunting.

Aaaahg it burns. I basically am going through and first annotating, then upgrading.

Interestingly enough, py2 was smart enough to automatically load things in the correct format. Loading a binary file? Get bytes. Loading a text file? Get a string. Py3 has worse functionality now, all for the sake of consistency.

To use that review as an authoritative statement is ingenuous, to say the least.

> Shower: Researchers had programmers fix bugs in a codebase, either with all of the identifiers were abbreviated, or where all of the identifiers were full-words. They found no difference in time taken or quality of debugging.

That's a very weird take on the statement. The downside of using abbreviations is probably dominated by the difficulty of fixing the bug. The problem I have with abbreviations is that they just become another thing that you have to spend your mental resources on. “What is this variable exactly? Oh, I see.” is just wasted effort.

Usually it doesn't matter WHAT things are, I need to know WHY you have a variable, and what it's intended use is. That can be explained in the variable name a lot of the time.

I have the same argument against the no-comments evangelists, and wanting to squash all commits into one when they're merging. Yes you can read the code diff, but that only tells you what, not why, something was changed. Why did the API endpoint change? Why do we have to call the payment processor before this event rather than after all of a sudden? Why did the add to cart button move up one div? All very useful information when you have to come back to fix things.

For the no-comments evangelists, I understand the idea is to make the code as self-documenting as possible, and that's awesome, but you can still miss out on the why, and sometimes the Why is entrenched in external business requirements that aren't in the code.

This stuff all feels better suited for a commit message. Conversely if I found all this in code I'd delete it.

I'm an almost never comment person (I use them when things are weird or inconsistent, but otherwise view them as noise) but I've been persuaded by John Ousterhout that code cannot adequately describe abstractions, and you need comments to fill in the gap.

Similarly with variable names, if you don't know i is index, please don't try working on this code. I get some code is a soup of inscrutable variable names and flow control to the degree it looks decompiled, but that's a higher level composition problem, not a "use more nouns" problem.

For me it's more about not wasting people's time. Names are opportunities to divulge minor contextual information that you spent time figuring out, and it would be going backwards to then compress that into shortened names.

i for index is fine, but if you have nested loops or multiple loops it gets annoying.

An example of a comment I'd value is something like a "why bother" at the top of a file doing a lot of in-depth algorithmic work, like a note accompanying a Chesterton's Fence. It makes some sense (though I quibble with this all the time) to design things so as to be as understandable as possible, and then only start optimizing when necessary, and when that happens it's useful to put a "this is pretty complicated, but it cuts CPU time down by 30%. [here](link) are the tests, and [here](link) is the naive equivalent implementation".

Usually I don't have long loop bodies, so if the loop body fits in 24 lines, `i` is perfect for the index.

If I'm locking a mutex, doing something, and quickly unlocking it, `l` for the lock guard is fine.

But if it won't fit on screen, it needs a longer name.

And if there's something like a top-level `App` struct, I just call it `a` because its scope is really just `main`, even though its _lifetime_ may be the entire process.

Like, isn't it fine to change:

    var basicAuthenticationController = new BasicAuthenticationController()

    var ctrl = new BasicAuthenticationController()

wait what. I live in SF and everybody just says SF

https://thebolditalic.com/don-t-call-it-frisco-the-history-o...

I doubt it would be controversial if programmers adopted a similar convention.

Names evoke ideas, and this is very subjective. So "self-documenting names" can turn into "misleading names" in a hurry. The name "x" never misleads because it evokes nothing.

This matches my experience. People say otherwise might need to put more effort on writing better tests.

That said static typing usually catch minor problems like typo faster. But for dynamic typing it's going to catch by tests a bit later. But usually tests run faster with dynamic languages, so it's a tradeoff.

My favorite approach is the mixed approach like TypeScript:

1. Faster feedback loops: Usually statically typed languages compiles slower thus slower feedback loops. But languages like TypeScript can skip type check and emit only to the runtime, making test watcher very fast - as soon as I hitting Cmd-S I can see the result.

2. Optional typing: Sometimes a function signature is going to be 10x larger than the body, which is really a hassle. Sometimes I just skip them, or skip typing module private functions as long as it's properly tested.

Another thing: people working with dynamic typing often forget that often times they are interacting with a system with extreme opinions on types, namely their relational database, which is often times literally the heart of the business. If your language of choice has typing, you can sync that type info (smart ORMs, codegen), and thus reduce friction. With that said, I develop in Ruby and my understanding of where there might be "type friction and potential for bugs" has improved a lot over the years, so I don't mind the lack of types until we get optional typing sorted out.

Shower: keybored, your shower is not cold enough to induce stress and you are too lazy to modify the showering experience in any way

Caveats: Other people may be anti-lazy enough to modify the showering experience

Notes: Check yourself

https://en.m.wikipedia.org/wiki/Diving_reflex

Edit: This is also the time of year to do this, while the tap water is probably warmer and your house is warmer. I wouldn't try to acclimate in winter.

Edit: looked it up. 30min-2hr for hypothermia at that range. Typically I take a 15-20 minute shower, so only flirting with hypothermia.

I love a hot, hot shower. Best advancement in technology in the last thousand years

Interestingly, one of the theories behind why cold showers might be good for you is that they induce a heat shock response, same as a very hot shower.

Granted this is personal experience and I may be simply not careful enough to do untyped refactoring, but few people I talked about that shared the experience.