Hacker News Reader

Not the parent, but I think it's possible to simultaneously believe two things:

1) It is completely understandable that, considering how easy it is to for a new programmer to get started in a dynamically-typed language (and that those languages are pushed very hard as beginner-friendly), many developers have a hard time grasping the idea of static typing and how to apply it to code, because their mental model just never included that, and changing mental models is hard for everyone.

2) It is absolutely horrifying that this is the state of new-developer education (or the lack thereof) in our industry, and I would put this on the (long) list of reasons why software in general is so unreliable.

I give the OP a lot of credit for writing about his journey, and by doing so making himself vulnerable to criticism. And it makes me really happy that he was able to not only eventually see the benefits of typing, but concretely articulate some of the benefits he found helpful[0]. That, IMO, is a sign of a solid developer who is willing to expand his skills and change his mind when given new information. But from a structural standpoint, I wish he had better mentorship when he started out and had never fallen into the "typing is bad" camp in the first place.

[0] "Making impossible states impossible" is something that I sometimes still struggle to impress upon developers with years of experience under their belts. The compiler is there to help you and catch your mistakes before you even check in the code, if you give the type system enough information to do so.

In the end, and in the big picture scheme of things, what is programming about? It's about providing value. There are plenty of systems and tech built that do not use types, yet they do provide value. And those systems may seem horrific to you, but none the less they provide value. These systems were built by hacking/mashing things together, but the fact that they work, still remains. You might hate for example WordPress, but it powers tons of web and those websites might not exist if it wasn't for WordPress.

Imagine a case where you can start to be productive with WordPress within few months, but if you were to learn the whole thing, it might take few years, the value provided would be a lot lower.

I went 4-5 years of my career without knowing anything about types, yet I believe I was able to provide software that benefitted the world.

It's not that black and white.

>The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget.

Respectfully, its really hard for me to wrap my head around this mindset.

When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types. You know the basic OOP lessons where they teach that a Dog is a type of Mammal which is a type of Animal, etc. Typing was ingrained in me before I wrote any meaningful code. So from my perspective (and the perspective of anyone who learned similarly), typing is basic, foundational knowledge, and programming without an understanding of types is akin to running before you can walk

I think a lot of the developers learning nowadays are learning to code only on JS. And on JS you can do a lot without ever thinking about types. So they get stuck in the mentality that typing isn't necessary, and don't ever put in the effort to learn types.

Learning about types isn't that hard. But if you've been conditioned into thinking that typing is esoteric (perhaps due to modern coding courses completely glazing over types), then you're likely going to find it very challenging.

A move at my alma mater to switch the introductory course from Java to Python was criticized on the same grounds. The students had a hard time in successive levels of coursework.

It seems to be a lot harder to get people who learn dynamic typing first to learn static typing, than the other way around.

It's dangerous to assume that the same number of people will continue programming if you start people on dynamic vs static typing. Maybe the static first programs weed out more people?

The anecdotal information I heard was that in general there were less people adjusting to later coursework successfully, in absolute numbers.

From a pedagogical standpoint, if the point of an undergrad education was to produce people with well-rounded abilities in their field, I don't know that switching introductory courses to Python was the best move.

Personally, I'm thankful that the first program I was enrolled in allowed me to "fail" fast, so that I quickly figured out that I shouldn't really waste more time and energy into the program and switched into CS. It's a lot easier to pivot as a freshman in your second semester than as a junior finishing the academic year. (And I knew people who took that long to switch majors, who either spent way more time and money or dropped out.)

I've been thinking about this (and will probably try to put together an essay about it at some point). I think that the types you learn in programming 101 and the advanced types (the kinds of things written about in type theory books and papers) are related, but different beasts.

If we drop down to the lowest level, basic-programming-types are about one thing - interpreting what is otherwise a pile of bits in memory. Without any notion of the difference, how would you interpret the difference between characters and integers and floating points? There is nothing about the ones and zeroes to tell you. So the first thing you learn is to write something like `char a = 'b';`

Dependent types (and related type theory constructs) do get used for this in languages built from the ground up with that as a theoretical foundation, but they have their basis in ideas that are more related to formal verification and logic.

And that's where the divide comes in.

Using types to pick a codec for some bytes and using them to verify systems are very, very different mindsets.

And we simply call both "types".

That's an excellent point. "Do we interpret these 8 bytes as a 64-bit integer or a double-precision floating point value?" is "typing", but it's hugely different from defining a typeclass that describes a monad and then implementing it for a list type.

The opposite for me. Typing makes zero sense. I know what I'm doing with my variables so why do I need to specify a type? Why can't the computer figure this out? Isn't that what computers are good at?

Well, as the author of the code, you should be able to tell the function what type of variable you expect (string, int, or business entity e.g Book, Bookstore).

That way if you later try to call the function passing an int when it expected a Book, you have an early warning system at compile-time. Not run-time.

The computer can indeed find out. Most statically typed language can infer types nowadays.

The evidence from a whole lot of code written by a whole lot of people seems to indicate that, for the most part, a given developer actually may not know "what [they're] doing with [their] variables".

For everything else, there's type inference.

> Respectfully, its really hard for me to wrap my head around this mindset.

> When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types.

Well, that's great for you. When I wrote my first line of code, almost 20 years ago, the first thing I learned was string interpolation. Then a long, somewhat embarrassing course in what happens when you interpolate strings that weren't of the same "type". If you're introduced in any kind of self-taught way to programming, and you start with dynamically typed languages, you're doing stringly typed stuff.

> When I wrote my first line of code, almost 10 years ago, one of the very first concepts I learned was types.

Lucky for you. Not everyone did.

It's very hard to remember what it felt like to not know something and likewise hard to remember how hard it was to learn something once you do.

> This comment and many others in this thread seem to be missing something.

I think they're also shoehorning their experiences. Some coders are cogs in giant tech companies that emphasize code quality, others are on teams in large business in an unrelated field, others are solo hobbyists, and still others are the only tech guys at their medium or small business. Some write code to run a business, others write code to probe the mysteries of the universe. Some write life or death firmware that'll survive for decades, others create landing or promo pages that will be deleted next month and are subject to the whims of the marketing department. Those are all vastly different contexts for a programmer and each requires its own set of trade offs vis a vis typing.

For example, I couldn't care less about strong vs weak or static vs dynamic typing at my current frontend job because the stakeholders don't know what they want, stuff changes rapidly, and there's little I can reuse from one request to the other but I was a full blown static typing crusader at my last job where I worked on a payment system that had to deal with schizophrenic regulations.

> I think they're also shoehorning their experiences.

Yup, agreed. I first learned to program in the late 80s (when I was around 7 or 8 years old) using BASIC, and my first part-time programming job in college was a mix of C and Java. All of my EE and CS programming coursework was done in C, C++, or (pre-generics!) Java.

It is really hard for me to put my feet in the shoes of someone who switched careers in their 20s or 30s by joining a bootcamp that teaches node, HTML, and CSS, and helps them find web dev jobs.

Their journey is so different from mine that I have very little ability to guess as to what should be easy or hard for them to do as they grow in their career.

Having said that, I still do believe that everyone who wants to write code should learn about static typing eventually, and the sooner they're introduced to the concept, the easier it will be for them to integrate it into their mental model of how software works.

I switched careers at 33 (currently 35) from structural engineering to a full stack JS career after attending a bootcamp.

Reading your comment, I wish I was in the former group of learning to code early on, taking CS and SE courses in university, etc... I work feverishly to learn as much as I possibly can about networking, Linux, hardware, SQL, etc.. along with all the JS related topics I need to learn for my job.

I just wanted to add to the conversation by saying that there are people in the later group who really want to become well rounded and not just be JS developers.

> This is the key advantage of dynamic types. You can make a computer do useful things without having to invest the large effort required to learn how static types work.

That's one key advantage of dynamic types, but it's not the only one.

Sophisticated dynamic type systems like Julia's are difficult to model statically. Some idioms would require dependent types if they're even possible at all.

Yes, there's historically been cases for dynamic typing that went beyond "writing type annotations is hard", although as time has progressed, computers have gotten faster, and compilers have gotten better, the scope has gotten smaller and smaller. (I think a language in Python's niche that was created today would have a simple type system with extensive inference, just because someone developing such a language today would find it technically feasible.)

Another case is what Alan Kay calls "extreme late binding" in a messaging-oriented language, as seen in Smalltalk and Erlang.

> I think a language in Python's niche that was created today would have a simple type system with extensive inference

How do you think a “simple type system”, suitable for a Python-like language, would look?

The type systems that have been developed for Python itself, for example MyPy, are far from simple.

>The author isn't claiming to have had an informed opinion of types. They're saying that they found learning about types to be difficult and stressful. That's a real problem that I think people who understand types forget.

I don't understand how one can be a great (or even half-decent) SWE with such an aversion to learning something so common and foundational as types.

After working in the industry for many years, I have aversions to learning many things. Usually, it's clearly a failed recycled idea with a small twist, poor approach to a problem, or someone selling new shiny.

I have no aversion to learning something when it shows potential value, but you must explain the value without gimmicks. Maybe typing hasn't been well sold to this person. The new thing I learn should make my life easier, not harder. If you don't apply a filter, cargo cult and marketing nonsense will sweep you away in a world hidden in unnecessary complexity to make a few bucks.

If learning and using something new adds more stress and difficulty and little-to-no benefit than life without it, I'll pass. When it comes to typing... I don't think that's the case. Typing can be annoying when you first use it (I'm sure I complained a lot) but it's well worth it when you need a stable maintainable codebase.

I get your point, but I think it's misplaced. Types are not new, in fact from a CS perspective they are very old.

I think it's a shame that learning about (even just basic) types is being taught as some new thing that can help to make your code better, rather one of the fundamentals that we should be learning from the beginning, which can still provide benefits even when writing in dynamically typed languages.

Perhaps it's just a case of bad marketing and lazy educators.

I'd be willing to bet money that if you were to list all your skills and non-skills, I could find at least one thing that you don't know that other SWEs would consider just as "common and foundational".

Could be any of: data structures and algorithms, complexity analysis, operating systems, parsing, compilers, databases, networking, user interface programming, OOP, FP, MVC, markup languages, the web, graphics, manual memory management, pointers, computer architecture, etc.

Around the world millions of people learn Java as their first programming language. It is not hard to learn how to use types or generics.

What appears to be difficult is to go from an untyped language to a statically typed one. Which is why everybody should start with a statically typed language so that the psychological barrier never develops.

This is wrong. Dynamically typed languages still have types that need to be understood by the developer. They are only checked at runtime and not at compile time.

Values have types, but variables do not. All programmers have to think about the former, but only statically typed programmers need to reason about the latter.

> a very admirable job explaining what's going on in their head

As someone who followed the author's path, this is spot on, and also what I recognized in the article. Everything else you said is spot on too, I just wanted to call this out as part of the article's would-be audience.

> They're saying that they found learning about types to be difficult and stressful

No, they're saying that types (which they don't understand) are "over-engineering". This is, frankly, not acceptable to me.

They're describing how they felt before learning about types.

Yes. Like I said.

> I'm glad the author was able to move on from this, but it is utterly pervasive in some parts of our industry.

It's entirely possible you have a language barrier, but you should know that there's a meaningful difference between past and present tense when you're representing what other people said.

(Edit: added clarification of which speaker's tense was important)