Ask HN: Are there senior devs who liked switching from static to dynamic typing? | Hacker News Reader

Ask HN: Are there senior devs who liked switching from static to dynamic typing?

39 pointsjoeldo81 comments

I'm curious if there are any senior engineers who have swapped from using statically typed languages to dynamically typed languages later in their career and prefer this way of working?

I've met many senior engineers (myself included) who have made the opposite transition (dynamic -> static) and now the thought of using a dynamic language for anything outside of small scripts is uncomfortable.

View on HN

My preferred language (Ruby) happens to be dynamic, but at this point in my career (Staff-level) I've come to believe that the whole static vs. dynamic argument is way overblown.

90% of the issues that come up on the teams I've been a part of are caused by developers who are lacking architecture (and related) skills, regardless of the language we're working in. They struggle to find the core metaphors for the problem space they're working in, they struggle to name things, they struggle to find clear and effective refactor points, they struggle to consider the medium and long term implications of their decisions, they struggle to organize code well, etc.

(The other 10% of issues are constantly changing business requirements.)

Static vs. Dynamic has nothing to do with those problems — they all exist in both worlds.

Personally, my most recent stint with a statically typed language (Swift) was hella frustrating. I felt like I was fighting the type system all the time. (Several of my biggest complaints have been address since I moved on from Swift, to be fair). But some people just love it — and good for them!

For me, Ruby is the closest language to how my brain works. It has the least friction between Idea and Running Code. I hope to write in Ruby (or similar) for the rest of my life.

If I really want a static analyzer for my Ruby, I can try Sorbet. If I desperately need to be running a compiled binary for speed or flexibility, I'll have to choose something else. These are just the tradeoffs.

The world is a big place. I'd want everyone to be able to find a niche where you can write the code you want in the language(s) you want.

Thanks

I am at a similar level / write a lot of Ruby. I have pretty mixed feelings. I do enjoy writing Ruby and echo the low friction between an idea and running code.

However, on very large Ruby projects I have inherited I do see a common flaw of a large (often insane) amount of exceptions being thrown due to type errors. Undefined method blah on nil class. Some of these apps have had 100s of developers working on them of various skill levels. For mission critical code paths I am often the biggest proponent of Sorbet.

While my personal projects involve heavy use of meta programming and taking advantage of duck typing, I have altered my writing style and opinions for large projects.

Part of my frustration with Ruby type system could be explained by the fact great Ruby developers are becoming pretty hard to come by and I have often had to work with developers who are picking it up.

> core metaphors for the problem space they're working in

> find clear and effective refactor points

> organize code well, etc.

> Static vs. Dynamic has nothing to do with those problems — they all exist in both worlds.

It's interesting because, having converted from Python to Haskell, I find a powerful static type system helps tremendously for those three things.

absolutely love ruby. beautiful language. so easy to write clean code with.

Typing is also documentation. If you are documenting your code you’ll need to document the types for it to be useful so why not just type it and save yourself a whole bunch of runtime errors?

I'm a polyglot, and I reach for the appropriate tool for the task at hand. I've done basic(s), Perl, python, Ruby, lisp; C, C++, Java. For some tasks, static typing can turn into a huge chore, but my favorite there is C++ because templates provide enough flexibility that you can hand-wave a solution and the compiler will figure it out (or scream). Dynamic typing reduces the character count, and can get a prototype out the door quicker, but in many languages that comes at a cost to performance. I find that I have about the same number of bugs in any language; and I've even had stupid type failures that only crop up at runtime in C++ (sometimes hand-waving at your type system has pitfalls).

Watching juniors at work, I find that it takes them less time to complete a task in dynamic languages, but I think they get better results when the language forces them to think a bit harder.

I'm in a bit of a minority on gradual typing. Give me static types or none at all. Python's approach to typing gives me the heebie-jeebies.

None of the listed langs have good type systems.

Okay.

Not sure if I qualify as senior having been programming for just a little more than a decade but I fall into that category. The first language I learned was Java and it was the first language I wrote for a living as well as C++. Nowadays I mostly work in Python and Clojure (including on sizeable codebases) and I greatly prefer it. I've come to like Lisps more and more the longer I program and a lot of the power they afford you comes from their dynamic features.

Interesting to see Clojure brought up quite a bit in this thread. Looks like something I'll need to invest some time into!

No, a decade does not count as senior, except on business cards.

Okay.

I spent a couple of decades with static typing (mostly Java) before spending another 5 years doing nothing but JavaScript. I definitely, I initially like the freedom of dynamic typing and one could argue that as long as you have sufficient tests in place, one is not better than the other. In practice, when working on a team, dynamic typing tends to fall short because it's difficult to enforce the patterns that are needed to actually have a maintainable code base. With dynamic typing different opinions about what patterns should be used in dynamic typing has lead to chaos where each team has to invent their own versions of accepted patterns meaning that each development team becomes an island of their own invention. Human progress relies on organizing many individuals with the same purpose and same way of doing things, which is very difficult to do with dynamic typing.

Can you give an example where static typing enforces a pattern? I feel like that problem exists at the human level, where language would not make a difference, but maybe I'm overlooking something.

Programming to interfaces not implentation is at least encouraged if not outright enforced.

Java doesn't count. Neither does C, Pascal, etc. Languages where the only role of types is bondage-and-discipline are not meaningful for comparison.

lol, I find that metaphor apt for quite a few languages I've worked with!

But "bondage-and-discipline" is the only advantage in my opinion. It's because you have new-grads, juniors, people rushing through tasks, people new to the code base, new to the language, that's why on larger projects at companies forced "bondage-and-discipline" languages are hard not to use.

Which languages count?

When you’re charged with making product iteration in your org more efficient (as a senior dev might be), a lot of what you end up doing is lifting certain things from hard-coded to config and DSL driven. Carefully and selectively introducing dynamism to overall statically typed and compiled codebases. These are almost always interpreted by our statically typed codebase though. We would never run a dynamic language runtime by itself in prod.

I use Go at work but mostly Python for personal projects currently, and am pushing towards Clojure for personal projects in the future. But that’s because personal programming for me is a cathartic escape from the straitjacket of zero abstraction power and the tedium of manual error handling; I care about my own satisfaction more than I care about scalability to a team of varying skill levels in that context.

This is a constant dilemma of mine. In Clojure I can trivially build such dynamic applications that lift part of the problem from static hard-coded logic for each use-case all the way to first-class, reified dynamic constructs that can be created from config, DSLs or from API calls for self-service use.

But with constant attrition, only being able to mostly hire juniors, with the mid/senior hires lacking knowledge of Clojure, there's a risk in doing so with Clojure. If there's half the team familiar and knowledgeable in it it can sustain onboarding, but Pandemic has caused a 90% refresh, so we lost our pipeline for training people to Clojure.

Doing the same with statically typed languages is possible, Java + JSON will get you there for example, but it's a lot more tedious and roundabout, and simply less pleasant. On the other hand, people unfamiliar with a language and generally still with lots to learn about proper abstractions, code structure, meta-models, and dynamism will struggle to ramp-up and produce good code, a catch 22.

I've done so, if I can choose, Clojure is now my language of choice, which is a dynamic language.

I'd happily use Elixir as well, another dynamic language, if I had that option and couldn't use Clojure.

Only when I can't use those would I go back to Java, Kotlin, Scala, C# or C++ (all which I have prior experience with).

I've found that it's a chore to maintain large-scale software written in dynamic and static languages for different reasons. Large projects written in dynamic languages have turned into insane messes because people with varying levels of ability can not develop with confidence unless the unit test coverage is high and everyone is generally consistent and disciplined in their usage of language features. Sooner or later velocity goes down significantly because the value of the code has increased due to business growth and there is a very high level of anxiety about the ability (or lack thereof) to reason about far-reaching code changes, or even medium-sized code changes.

With static languages, on the other hand, writing routine things becomes a chore and people end up needing crutches in the form of advanced IDEs to generate boilerplate code that is a pain to read because of templating and such. Of course, error messages when templating/generics becomes involved are just horrible. Without generics you tend to lose a bit of the benefit of statically typed languages.

At the end of the day it's the size of the codebase, team discipline, and an emphasis on simplicity that matters more.

It is my experience, though, that people start out enamored of dynamically typed languages because of their expressivity and high productivity but then end up gravitating towards statically typed languages for large codebases, because they are more willing to trade convenience and coolness for safety and reliability the more senior they are.

If at your organization, "people end up needing crutches in the form of advanced IDEs", and use them "to generate boilerplate code", they are Doing It Wrong.

(There is probably no choice if your "static language" is Java [0]. But Java is always a choice: you can always quit and go where Java isn't, especially nowadays where everything is remote.)

A powerful static language (i.e. not Java, C, or their analogs) in a well designed system involves no boilerplate and can be a joy to use.

[0] https://blog.plover.com/prog/Java.html : "I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product."

For better or worse, most organisations choose Java as the statically typed language, and not everyone has the luxury of saying "I'll not use Java". Even MJD, no slouch when it comes to technical chops, admits that he ended up writing Java.

Java is definitely like this and it also emerged in an era of overengineering because microservices weren't a thing. However, I'm willing to bet that Go will soon go this way with generics. Most average programmers do not care about programming with types, type traits and so on, and are simply not equipped to deal with byzantine compiler errors (gcc/clang error messages and warnings about C++ templates were the ugliest things I have ever seen), and this is where the tradeoff is facilitated with pre-written libraries and code generators that take away the need to deal with these things explicitly. They are not going away, and relying on them is not Doing Things Wrong. It's just doing things and getting on with life, period.

I think Mark Dominus writes Haskell nowadays.

"Byzantine compiler errors" is what I guess you have come to expect from (mis-)use of pre-C++20 templates. But the overwhelming majority of type operations in actually high-level languages like C++ and Haskell cannot result in compiler error messages, and simply perform useful busy-work you therefore need not.

What languages are we talking about here? I mean, we use Go, but I would definitely consider it a C analogue. It is also very tedious, and all the measures we have for managing that tedium are code generators. (Though in Go world, culturally, these are build time rather than IDE based tools).

C++, Haskell, OCaml, even Rust.

As we used to say, "you can code FORTRAN in any language", and code in those languages can be as unpleasant as anywhere. But they don't have to be.

I started in CPP and now mostly write Python. Honestly, it is just so much easier. Gone are the insane number of helper functions and custom types you have to wade through to make a tiny change. The reality is that boundary-level checking is all done with validation libraries (like Pydantic) anyway, and invalid types traversing an interface between sections of the codebase, in an unexpected way, happens so infrequently as to be almost a non-issue.

Based on some of the comments you see on HN and Twitter sometimes, people seem to think that invalid/unintended types being passed around are like a non-stop nightmare or something. I almost never see these issues. Even unexpected nil objects/values happen no more often than when I was using Swift. Not sure what makes people think this is such a big deal.

(I'm a Rubyist)

Static typing eliminates an entire category of runtime errors.

With type-hinting etc it’s getting better now, but they’re still a big problem in dynamic languages.

Honest question: which category(ies)?

Having written extensively in several statically typed languages, it was still possible to send messages to nil and end up crashing, or just be lazy and not deal with every possible conditional when parsing incoming data from an API and end up crashing, etc. (I use these examples because these seem to be what people reference the most — perhaps you are referring to something else).

Like, it just does not happen (in my experience, to be fair), that someone is passing a Car into a method expecting a Flower. It's nice that the compiler would flag that for me, but it's just so rare in my experience.

Yes this! I've worked so much with static typing and I always think this when people talk about all the bugs that it prevents. I do from time to time wonder why stuff isn't working while I'm building it in a dynamic language just to find that I have a typo somewhere and I might get annoyed but then I think about all the types I would have to write and maintain and I'm happy again. I'm convinced that most of the time there is not enough ROI to justify the added complexity and mental burden of adding something that does nothing for the problem you're trying to solve.

Types don't just guard against catastrophically stupid errors like Cars instead of Flowers. You can use them proactively to tag and refine data, excising a considerable deal of logic from your code.

If you are dealing with priority lanes, all of the methods could be written to only accept Carpool types, even if a Carpool struct has the exact same fields as a Car. Then you only need to parse a Car to a Carpool once and never worry about validating the passenger count after that.

Static typing only seems like a verbose straightjacket in the context of verbose languages like Java and Go. In reality it can help you write way less code. I don't expect the world to switch to Haskell, but I am excited by the direction TS is heading. I think "parse don't validate" will become common wisdom eventually.

Also, the crash cases you mention could be avoided elegantly with Option types.

I need to spend some time with Haskell.

Amusing to hear Go described as verbose. Given that it was intended to not be verbose! Do you care to elaborate? To me, having done lots of Python, I find Go irritatingly lacking in batteries included, lack of classes stumps me, and Go seems certainly no more succinct than Python. I find Go seems possibly less verbose than C++, definitely better than Java ( that wouldn't be difficult ;) but perhaps harder to read. However, I've only dipped my toe in with Go, so possibly approaching it completely wrong and need to learn the Go mindset....

Error handling in Go feels tedious after doing error handling in Rust.

As the sibling comment alludes to, checking errors is a major pain and needlessly repetitive if you expect any exception in a chain of computations to be handled the same way.

I can't speak for Rust, but in Haskell you can just do something like

   f >=> g >=> h

in the context of Either or whatever.

All of this has nothing to do with Go's specific typing discipline or syntax around it, of course. I was just commenting on how the most popular static languages probably aren't the prettiest or most reliable examples of the approach. Plus Go is far more likely to shit the bed at runtime in spite of its typing.

It also is a form of documentation. I love when someone doesn’t type code but then ends up adding the types in the doc string, why wouldn’t you just type it then?

Agree 100%. However... since nowadays we all do TDD (right? ;). I hope so! ). and write thorough unit tests, this should be less of an issue. I remember years ago when switching from the likes of C++ and Java, to Perl and Python. Indeed there were problems that occurred in these otherwise-nicer-to-use-dynamic-langs which would've been caught by a compiler, but that was before TDD being so standard.

> ... since nowadays we all do TDD (right? ;). I hope so! ).

Everything in moderation. TDD is good, but I've watched people write extensive tests before writing a line of code to test, and it often ends badly -- not too badly, they usually just needed to rewrite the tests once they figured out that they had the wrong API (oops, at least one example was a case for DOD, because the API was perfectly obvious from that lens) but sometimes that can trigger multiple refactors along the way. I've seen the same thing happen with documentation-first. I've seen top-down problems and bottom-up problems and code that ships before tests or docs were ever written/validated. In my not-even-remotely humble opinion, people need to be familiar with all the design patterns, and figure out which is best at project inception.

I like regular JS or python over more typed alternatives. Catching bugs in your IDE still means you made them, and there are other ways to catch and resolve them later in the chain. In the meanwhile, I find that strongly typed setups can devolve into verbosity and get in the way of shipping.

For context, I usually work in <50 size engineering dpts, if not companies. If you're scaling to thousands you can spare the scale, probably.

I feel more comfortable with statically typed languages, but in the end they're all just different tools for the job. I switched from years of C# and Go (back to) to JavaScript recently. I use TypeScript wherever I can, but it's not always feasible and that's alright. In the end I definitely favor static typing as a personal preference, but don't have any aversion to writing vanilla JS either. It's just different approaches for different things.

I am a 53 years old C# developer by hart. I have been working in .net world since the first beta long time ago. I don't mind writing in dynamic languages. In my case that will be typescript / javascript but I wouldn't want to write dynamic language full time. It is not because of the dynamic nature of the language that I don't want to do it full time. It is the editor support especially when it comes to refactoring. I am so used to the amazing tool that Visual Studio (full, not code) is. Hit F2. Rename something and you can almost with absolute trust that the refactoring changed what needed to be changed in the correct places. I dont have the same level of confident in vs code / type script. Too often one needs to perform a risky search and replace.

Then there is the debugging support in Visual Studio Full. Yes, there is debugging in vs code / typescript, but it is far away from how easy it is to debug a C# application in Visual Studio. Too often I have to resort to printf type of debugging to gain insight into which code line was the last line to run before the error.

Yes, I like dynamic languages because some of your things you can do with them are freaking awesome, but at the end of the day I like the comfort feeling that Visual Studio and a static language provides.

With all the talk of Microsoft EEE-ing C#, do you think there's a future for C# outside of niches like games and banking? I like what Microsoft has done in terms of performance, but, I'm not too fond of having the rug pulled out if/when they start locking parts behind a proprietary license.

What does EEE mean?

In the context of Microsoft strategy: Embrace, extend, extinguish

https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

I don't think they are EEE-ing C#. I think what is going on is that there are middle management in the Visual Studio Full team that are very protective about the product they have help made and these manager are the ones that have a hard time adjusting to open source. Their salary is probably based on that VS has to make a profit or they simply don't understand open source of the benefits you (can) get. I dont think MS upper management has a formal EEE strategy. I simple it is some stupid middle management that f. up things

I dont know if c# has a future outside of games and big corps. I face palm everytime I see Microsoft launch something open source and cross platform and leave linux out of it and instead say that "the community must create something amazing for linux". If Microsoft starts to build the first version of shiny new thing for linux and launch it at the same time as the launch it for windows, mac, android, then i cam move outside those niches because doing that will create good will

For the moment, would you personally recommend building a web-server C#/.NET stack or would it be better to look elsewhere?

Absolutely I would. Everyone has their opinion about Microsofts products, but the platform and frameworks that underpin them are rock solid, long-time battle-tested in production, and easy to work with as a developer.

A .net stack comes with the comforting knowledge that this technology will never be made obsolete. It will undergo active development and will have support for many years to come. One day, long into the future, it will be super seeded by something else. When that happens, you know there will be a migration path because Microsoft has based their own business on it, and they need it for themselves, and all of their customers need it. .net does not go away tomorrow because something shinier showed up. That's nice to know.

You will find that you will have a very stable and mature stack that is well integrated with Azure making deployment and testing easy.

Was I to build a microservice application, I would not choose Kubernetes. I would choose the Microsoft Service Fabric Actor model over anything else that is out there.

Service Fabric is Microsoft Secret Sause. It is the technology that underpins the Azure Platform itself. Service Fabric has a beautiful actor model that makes the development of cloud-based applications as simple as writing a single threaded console application.

Service Fabric and Kubernetes: community comparison [1]

The Actor Model [2]

[1] https://docs.microsoft.com/en-us/archive/blogs/azuredev/serv...

[2] https://www.youtube.com/watch?v=7erJ1DV_Tlo

Service Fabric sounds like something too take into consideration. And It's certainly reassuring that .NET has staying power. But a major concern I have is whether .NET will run as well on an AWS Linux instance as it would on Azure.

So far what's caught my interest is Blazor as a Node.Js replacement. If you have had any experience, what's working with Blazor been like? How do you think it compares to other server-side frameworks like Node, Django, Pyramid, or Spring in terms of performance, feature-set, and maturity?

I don't know tbh. I work with big corps and it is mostly aspnet + angular I come across.

Different tasks, different languages.

I'm happy to use Python for a lot of stuff. I also use C or C++ for a lot of stuff. It's usually pretty obvious what the right choice is.

Using a more dynamic language for larger projects takes more discipline, and that effort reduces the productivity that is otherwise the hallmark of dynamic typing. There's a point where static typing becomes a net win.

For me, Python's type annotations extend that cross-over point. Both as documentation for humans, and driving IDE or CI-based type checks, I think they've made Python more scalable.

If I've been doing heavy C++ work for a while, switching back to Python is like throwing off a whole lot of bureaucratic overhead: it feels like you can turn ideas into running code almost effortlessly. Going from Python to C++ feels like being super defensive and precise: every single thing is nailed down hard, and has to be just 100% lined up. It's satisfying, gratifying, solid, in a way Python code isn't.

Different projects, different goals, different timescales. Both can be good.

If coding C++ feels like fighting "bureaucratic overhead", I promise you are Doing It Wrong. The type system should be performing the overhead, on your behalf, at compile time, leaving your attention for the actual problem.

C++ coded like C or like Java will be exactly as miserable as coding C or Java, but that is entirely a matter of choice.

What do you see as the difference between C++ and Java that lets C++ be less miserable?

The type system in C++ as in Haskell, and to lesser degree Rust, is not just for checking arguments. It can do useful work, and routinely does in better libraries.

The work to have the type system do stuff for you doesn't happen for free. You need to define a whole bunch of scaffolding to support the application functionality. Sure, once it's set up, using it can be pretty painless, but the design, implementation and testing of the supporting code is a non-trivial effort.

In contrast, Python (and other dynamically-typed languages) avoid all of that.

In addition, the compile-time cost of all this is significant. Cup-of-coffee builds are a definite burden on productivity.

I just switched over from Haskell to Typescript.

I spent a lot of time in Haskell and the type system is great, the issues I ran were the stuff around it: an ecosystem often missing libraries available in other languages, Haskell solutionism, and working on code bases where Haskell language experts were empowered (not necessarily the best software engineers), which caused the company to re-invent a lot of services we could have just bought.

I really do think Haskell is the world class typed functional programming language, but I'm also not convinced using typed FP is the panacea some claim it to be. Typed FP doesn't make up for bad architecture or poor dev practices, and it's still 100% possible to code your applications into a mess even with outstanding and talented devs.

So right now I like Typescript, JS, the nvim support that took 20 minutes to set up and the incredible amount of libraries and dev tools. I've only been using typescript for a month or two, so maybe my opinion will change...

It depends on the task at hand and what I have to deal with in terms of data inputs (ambiguously typed JSON comes to mind) and size of project. Generally though I lean for statically typed, compiled languages just because the development experience and tooling taking advantage of it feels a lot smoother and ends in a more performant product in terms of execution overhead. I think it's important to write as many tests as you would for something written in a statically typed language as you would to cover for losses incurred by a dynamically typed one, so often (project size dependent) it kinda evens out in terms of effort you need to put into it.

What's most important also is making sure that you take away and learn from every language you work in and apply those lessons to other languages as well. Type hints on otherwise dynamic languages are a great middle ground.

The dynamic vs static argument seems to always revolve around bugs. Dynamic typing people say their code is not buggy. I too do a fair amount of javascript and I don’t think my code is particularly buggy either.

What static typing offers you though is the ability to refactor large project with much greater ease.

I spend most of my time refactoring a large C# codebase (10m+ loc) while other people are actively working on the code as well.

This just wouldn’t be possible without some kind of static typing. If there is a type that is used in 500 places and you have to update all uses, static typing gives you some form of insurance that you’re not breaking much.

I'm sure there are such devs, but just yesterday I had a scenario where hours of time would have been saved by just having the "compiler"/build-tool tell me that I'd misspelled a property in some javascript code (in QML in fact, so the property name was defined at the C++ level - perhaps there are IDEs that could have flagged this automatically but mine didn't). That was enough to remind me static typing is virtually always preferable.

Static typing is machine and human readable documentation that is tightly integrated in the development loop. Like all documentation, it requires devs to spend a bit more time upfront create.

In large constant systems, code is read more times it is written. Documentation is usually worth the pain.

In small, transitory, or experimental systems, documentation may not be worth the additional burden.

I started with dynamic languages, ruby is my favorite, and I use it everywhere where it’s suitable. As I observe, over years static languages getting abit more dynamic or less explicit (as they can), and dynamic languages getting some support for type checking. I guess having both in one language would be a best thing. So when code gets larger or I want to be more confident in some part I can add type validation (it could be a code that run as shared library, or communication between modules)

I also think that parameter strong typing and splitting code into service helps to design better, more clear messaging between components. Having done that for some time we can train ourselves to always pay attention to it, and it will help up to build larger code bases in a maintainable way. (I think larger code bases are more efficient from “time spent” point of view)

I often see people do same mistake: they trying very hard not to repeat themselves, and the highly reusable functions become very dangerous piece to refactor. I would rather have code copied in different modules, unless it’s very general thing that never change like array sorting or date formatting

Once I was impressed with Java.

Then I started Ruby and was carried away by amazing devx even though missed static typing sometimes.

Then I discovered Typescript.

Typescript has found the perfect balance between flexibility and type checking.

Now i feel literally pain when I have to deal with static languages. It’s like im thrown to jail.

Not to mention terrible devx of the most of them.

This sort of preloads the term "senior". Nowadays, every new grad gets to put "senior" on their business card, and it means exactly that much.

So, probably the question should be for people with, explicitly, 20 years' professional experience, if it is to mean anything.

Me: dynamic -> static

What did I feel during the transition: Feel like an insulted because of the under-expressiveness. Everyday I find some ideas that are natural to me and non-tech people couldn't be codified directly.

Although statically typed languages are getting better each year, I still think there's a trade-off among three camps:

1. Dynamic (Ruby, JavaScript)

2. Under-expressive static (Java, C#)

3. Expressive static (Scala, TypeScript)

I worked on a full-stack project and people have different backgrounds and have to switch from time to time, here's my impression:

- Most "underexpressive-static -> dynamic" people hate dynamic programming, because they mostly lose typing for nothing - they usually don't leverage the expressiveness because that is how they were coding all along.

- Some "dynamic -> underexpressive-static" people liked the discipline, while some hated the under-expressiveness, it depends.

- The "Expressive static" was the new thing. Everybody need to learn some part. Usually, there's a learning curve, some people like the challenge while some people hate it. That also depends on how steep the curve is (TypeScript is very smooth but not Scala).

Even though I think it's still trade-off, I can see the balance is shifting toward the "expressive static" camp:

- People get more familiar when they're exposed to the concepts. Higher-order functions like map/filter/reduce were considered exotic in the 90s, but now they're everywhere. Monadic-like programming like Promise or Optional is also popularized, they're not hard at all once "everybody else" learned that. Advanced type systems are no different.

- Language creators have more experience in choosing trade-offs that makes sense. Scala was getting a bad rap during its day, but Kotlin didn't. In other words, the creators are getting better at spending their "novelty budgets"[0] to yield optimal results.

P.S. I still couldn't wrap my head that Dart spent NO "novelty budget" whatsoever... They have zero chance against TypeScript if there was no Flutter or other Google platforms that use Dart.

[0] https://shimweasel.com/2018/08/25/novelty-budgets

I switched from Java to Python and liked it. The downside was mostly navigating existing code bases. But in general, well designed code trumps static/dynamic. Also, when I think back to products I have worked on, I mostly think of what the code did, not so much about what language I used.

https://henrikwarne.com/2014/06/22/switching-from-java-to-py...

Static and dynamic langs both can be nice to work with IMHO. Not a big difference these days. The thing I really don't like very much, as it does weird unpredictable hard-to-test things, is asynchronous programming. Maybe I'm stupid or not-yet-good at async programming but I'm not the only one. But with JS, seems you're stuck with that.

I have been programming in statically typed languages for 40+ years and have tried quite a few times to use dynamic languages (Ruby,Clojure,JS). However I always switched back. I am currently playing around with Typescript and it might be the best of both worlds because you can use the “any” type when that makes sense and strong types when that makes sense.

I’ve switched around a lot, basically don’t care if static or dynamic, what is important is the discipline of the programmer and the quality of what they produce. Static vs dynamic have trade offs, however not normally the deciding factor when choosing a language for a project.

Yah. I started in Java, and really enjoyed delving into Ruby, and then Clojure--the latter being my favorite.

I switched from Pascal to Python. I believe gradual typing (Python/Typescript/Dart) is the right path forward. Today static typing systems are not helpful for database programming.

What do you think of types/classes like Django’s QuerySet?

Never use that. But it looks good. I prefere SQLAlchemy approach.

There’s no one language that can rules them all. Different languages are suitable for different tasks not only because of the traits of the language itself but also the ecosystem.

Yep! I switched from C# to Ruby in 2018 and haven't looked back. I'm a web developer and the Rails framework is just so much easier to work with than ASP.NET MVC.

you can write absolutely incredible messes in either type of language, especially with statically typed languages that support reflection. i've switched back and forth multiple times. (i'm using golang these days.)

i will say that mocking/stubbing is much easier to do with dynamic languages, but this, in theory, forces cleaner integration points in static languages (i.e. accept interfaces, return types)

for some projects I prefer static, for some others dynamic.

recently I regretted using C for a big library as I had to tack on dynamic-like features, like huge hash tables for all it's objects and methods, so that I can dispatch dynamically. in a proper dynamic language the project would be 10x smaller and safer.

Most of the cost of systems comes from maintenance. Most maintenance effort is spent reading code and trying to understand it. Types are documentation that speed up reading and comprehending. They're documentation that cannot get out of date because they compiler checks them. Don't think of type signatures as boilerplate or extra verbosity. Think of them as electromagnets waiting to accelerate future you.

Professionally, over about 12 years, I have used Java, C++, Golang, Rust, Dart, Python, Perl, and Swift. Since learning Rust, every other type system seems slightly broken. Fixing a red-underline takes a few seconds. Debugging runtime errors takes 10-times as long. And debugging runtime errors in a long CI run can take 100-times as long. Because static types let us catch errors earlier, they speed up writing and changing code.

Reply on news.ycombinator.com