I've always wondered, and maybe you can clear this up, why? What about static typing is "worse", so to speak?

Fundamental difference between static and dynamic: static typing disallows writing a certain set of perfectly valid programs while also having the advantage of disallowing many invalid programs. So the question becomes: how badly do you want to work in that space that is not permitted by static systems?

And that space is where your data itself is highly dynamic. When you just want to represent data as maps, do generic operations on maps, then spit out more maps back to something else. This description applies to many many real world systems, particular in the more business-type domains.

Another space where dynamic really shines is dealing with relational data in a relational way. Relations are just sets of maps, the most natural thing in the world to work with dynamically. In a dynamic language I can just write code that peaks into the map, transforms certain fields, then passes the whole thing on down the line. I don't care what combination of selects and joins got me that relation, and in reality there will be many, I want to reuse my functions regardless. Although this is where more structural type systems can help ease the pain over nominal type systems.

I feel like this is a great blog post talking about the downsides of static typing in a real world system: https://lispcast.com/user-wizard-scenario/. I appreciate that the author has real world experience with both Haskell and Clojure and comes from that perspective.

Ultimately I'd say that if a program can be written in a static language, it should be, however some programs deal with information that just defies fitting into your type system without herculean efforts. Just like static languages will look down on dynamic languages for reimplementing poor ad-hoc type checking, dynamic languages can also look down on static languages for poorly reimpelmenting dynamic behavior with a bunch of functions mapping Any to Any.

Thanks for the link. Finally somebody using actual comprehensible examples to build a case.

Hard to explain. It's more verbose and restrictive. Ruby is the complete opposite, you can do anything you want. I know what people say about Monkey Patching but what Rails did with ActiveSupport is mostly beautiful. I can see the advantages in types I'm not denying them. I am just so comfortable with Ruby/Rails and js I never bothered looking deeply into anything else. The Java I did in college, and then the experiments I did with Spring framework a couple of years ago (tried a couple of todo apps) made it clear to me it's not my thing. Ruby/Rails made programming actually fun. It may have improved since then but I think even getting a shell (like Rails console) was difficult with Spring. Maybe if I stuck to Spring for months or years I would have felt differently, impossible to tell most of the time because we usually stick to what we like and avoid delving too deep into what we don't like. Spring was just a massive complicated thing, or at least that's the impression I got. People go on and on about Rails being magical, I suspect most of them have a very vague understanding of how Spring actually works under the hood. Not to mention those hundreds of Beans you need to get to know, I dread those! I can see myself doing Go or Swift, something not too verbose, but again, I don't really care for performance (it's not at the top of my wish list as a web developer) that much or types. So to sum it up: I just like Ruby/Rails and not a big Java fan. I know there are many other static languages to choose from but life is short, I am happy doing my thing with Ruby. If I have to jump ship it will probably be to Python.

I absolutely disagree with the assertion that static typing is restrictive. It's not, though of course you need to be more verbose. But you are doing this largely for correctness so it's a worth tradeoff. Needing overly generic types or no type restrictions is very strong code smell.

Yeah this might be true of Java, but I think for modern languages with good type inference it adds a lot to readability without much cost in terms of verbosity.

After working with more strongly typed languages, it actually seems crazy to go back to JS or Python and not have type information in function signatures. Like how are people supposed to read code and understand what this function is allowed to take?

Functional programmers also say "how can I go back to mutable state and OOP". The fact is people get stuff done in many different ways and paradigms. You found what works for you and that's good, stick to it. Others found theirs.

You can annotate types in Python and Typescript.

Before that large companies like Google got around it by annotating in the comments. It may be an inferior solution but huge codebases serving hundreds of millions of users have worked this way.

Huge code bases serving hundreds of millions have been written in wasm, so...? Bad argument

There was no argument, the commenter was just asking “how”.

Modern Java is not what people may remember. It has var keyword for local type inference, lambdas, etc.

Except that very verbosity may make it easier to read, as the types themselves may supply further information to the reader about what the variable actually means.

I think this is noisy.

  f(x: a, y: b): c = ...

I think this is nice.

  f :: a -> b -> c
  f x y = ...

Signatures are useful as self-documentation, and keeping them separate makes that easy to scan.

It also comes down to the compiler. If you're "annotating" your code with type "sugestions," but don't get any ironclad guarantees from it, then it's reasonable to question whether it's even worth the effort. I may be misremembering things, but "typed" versions of Python and Scheme aren't particularly rigorous.

Verbosity aids readability a lot of the time.

> A static type system requires the programmer to think about the types.

Dynamic code requires the programmer to think about the same things; what static typing requires is communicating that thought to the type-checker through a constrained language (in the best cases, with robust type inference, this can be no additional cost for substantial fractions of a code base, though). On the other hand, it also provides fairly immediate feedback on the correctness of the information so communicated, and cam leverage it in dev tooling, so there is a benefit with the cost.

Like others have said, dynamically typed languages still require you to think about the types, except that now you don't have the automatic hints the IDE can provide you, the guarantee of safety once your code compiles etc.

Typed codebases are far better to return to than untyped ones. Anyone who doesn't think so has probably not tried a good, typed language with a good IDE.

Because the claim "you're not thinking about types" is absurd. You can't pass a LoggedInUser to a thing expecting a URL. You can't pass a AccountIterator to a thing expecting a UUID. You can't pass a function closure to a thing expecting a string. And so on.

You have to be thinking about types, because the computer can't. Since your programs work (I assume), and computers can't be doing this for you, by process of elimination, you're the one thinking about types.

What is actually happening is either that you've so deeply internalized it you don't realize it any more than you think about individual muscle contractions while walking, or you don't recognize what "thinking about types" means. For instance, I imagine an obvious riposte to my first paragraph would be "But if the code expects a URL and I pass it an LoggedInUser, I can set it up so the LoggedInUser can yield or function as a URL", which is in fact precisely "thinking about types" because you just changed the type of your LoggedInUser.

(You want to see someone who is truly "not thinking about types", go help someone learn programming for the first time, who truly innocently tries to pass a User to something expecting a URL and is truly surprised when that doesn't work because they truly, deeply thought the program would just figure out how to turn that into some URL they had in their head for the user, but never explained to the code. That's "not thinking about types". It is nonfunctional.)

As others have said, dynamic code requires you to do more thinking about types, not less, for two reasons: One, the compiler isn't doing it for you, and two, you have a lot more things to juggle in a dynamic language than in most static ones precisely because they give you more power. You shouldn't be fighting this idea, you should be embracing it; it is precisely the fact that they make you think more about types and leave more of the decisions to you that gives you the additional power in dynamic types you are enjoying.

But that additional power irreducibly comes with more responsibility. You can't claim you've obtained the power yet somehow dodged the responsibility of managing it. You are holding a lot more state in your head that has no existence in your source code than you would be in an equivalent static program. You can't claim you've got that state in your head but you're somehow not "thinking" about it.

You're thinking about types all the time. Your complaint is more than you like a programming style that involves very complicated type ideas that are difficult to express in a static language. (Or, possibly, that you haven't taken the time to learn to express in a static language. There are some static languages that work better with this style than others.) Or that you don't want the constraint of having to express them. So you stick to an environment that loads the work on to you instead in return for the power of those more complicated things you never have to lay out for the compiler. But the work is getting done somewhere. It has to be, or your program wouldn't work.

> I'd like to know why you think either one is (syntactically) required for programming

Taking the concept of interface, it would be difficult to program something with objects if you did not know the methods, properties, events. Just knowing the type name without any of the knowledge about the interface of the object would make programming close to impossible. The opposite however, knowing the methods and properties but not the type, is enough information to write a program.

In one python program I wrote I created a proxy object for a third-party library. The library only supported a single process, and I needed multiprocessing. The proxy object allowed me to take every call to the object from process B to be pickled and forwarded to process A, with the return value being sent back to B. No function needed to be made aware of the proxy object, the third-party library behaved just as it was a single process program and everything just worked. The proxy object did not need to have any information about the call signatures or method names of the third-party library objects.

It would be interesting to see such proxy object being written in a statically typed language that maintain the type checks when the proxy object get used inside a third-party library. Requirements would be that the proxy object should be independent implemented without being effect by the call signatures and method names in the third-party library. It sounds a bit fun trying to get the compiler to resolve what the type and signature should exist at compile time, through that might just be implementing a dynamic-like language through macros and compiler tricks.

What you'd end up doing is copying and pasting a lot of code. You'd need to define one kind of proxy object for one type in the third-party library, and another kind for another type, and so on. Each would need to implement all the methods, with correct type signatures.

Perhaps you could parse the source code to the third-party library and generate matching proxy objects from that.

No number of compiler tricks would allow you to define a single object that can be a proxy for anything using a statically-typed language.

Exceptional comment, thank you.

You can pass a LoggedInUser to a thing expecting a URL in a dynamic language if the LoggedInUser has the same methods as defined in the interface of an URL. It called ducktyping. In the same line of thought, you should even actively avoid checking if LoggedInUser is of the type URL because a different type sharing the same interface as URL should be equally accepted as URL. Two objects with the same interface should not be treated different unless very special circumstances.

If the code only expect the interface of an URL, the type of the object being sent in is irrelevant, and thus the programmer do not need to think about the type. Instead we are thinking about interfaces.

Programming in a dynamic language do allow a programmer to not think about types, but they do need to think about interfaces. Programming in a static language require the programmer to think about types, but they also need to think about interfaces. Having types does not eliminate the obligations to think about interfaces regardless of programming style.

If we want to use TypeScript as an example, a type is a data type of either Any Type, Built-In Type, and User-Defined Type. The Type System in TypeScript is responsible for checking the data type of any value taken before it can be provided as an input to the program.

Interface in TypeScript: An Interface in TypeScript is a syntactical obligation that all entities must follow. It can only contain the declaration of the members and is responsible for defining the properties, methods, and events. In a way, it is responsible for defining a standard structure that the derived classes will have to follow.

(above taken from https://www.geeksforgeeks.org/what-is-the-difference-between...)

Is a type, as defined above, required for all programming? No. Interfaces? Yes. Interfaces are also more similar to customer requirements in that they define behavior. Do the object has an absolute path method. Do it has an UUID property. Can it be used to call open on. Those questions are not type questions, and so I do not think about type when answering them.

> Two objects with the same interface should not be treated different unless very special circumstances.

...until you accidentally pass the ClientsTable object to the delete_supplier() function, which expects a Supplier object. Unfortunately, the delete_supplier() function calls the delete() function of the passed object, which is helpfully provided by ClientsTable. Bummer. Eh, just restore it from backups, right?

You've completely missed the point: A powerful static type system helps prevent many types of logic bugs.

No, it won't prevent every conceivable bug or error, but nobody claimed it does. Automatically ruling out a large class of bugs at compile-time is still very valuable. Don't let the perfect be the enemy of the good.

In almost 20 years of writing programs I have yet to write a delete function that dynamically call delete based on the object type. Having a delete_supplier() function that assumes Supplier object is a pattern that has direct security issue baked in.

The closest I would ever have gotten to the above scenario would be the time when I wrote an array of function pointers to be called in a parallel process. A bit of rather complex C code, and if I recall a bunch of void pointers.

If you intend to provide examples or bugs being caught with type checking, it would be useful if those examples actually occurred and were caught by the type checking.

You sure seem to be thinking about types a lot for somebody who claims to not have to think about types. Which is the entire point everybody is trying to make you understand.

You seems to insist on that a lot, but can't seem to show it.

And with dynamic ts the programmer is not required to think about it? You don't think anymore if you return a number or a string or a map? I doubt it. Static TS require you to think correct (and occasionally write it down - depends on the language) before you run the code.

Here is a real life example. I have a library that communicate with an API that extract information, and now I want it to also grab an additional field and extract it to a database. The goal is to figure out which functions in the code accesses the field, where the best spot is to extract the information, and what the best way to call into the database without adding too much code in places where it shouldn't be. In addition I need to keep the information synced over time.

Do I care what the different functions in the library return? No. The field could exist in everything from an XML object, a dict, a string, a byte array, or a custom object made for easy interaction. What I need to know is where in the flow I can best inject my new code, and in order to do so I need to know when and where the information can be accessed. In an optimal world I would have written a shell script, and in that case every function has a single return type which is string.

I can't answer your question. You may care since you may not want to break other code within the library that depends on what is returned by the function (depends how it looks like).

Otherwise I don't know why you would particularly care more about types with st than otherwise You'd just follow the same pattern as you did when extracting the other fields. E.g. if the fields to extract are listed in a list like structure, you're just going to add the extra field to the list. And in case of static typing, you'll get soonish feedback if you messed something up.

The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming.

> The return type thing was just an example to show that you care about return types regardless of static typing, not that you care about return types during every act of programming.

If we both agree that you do not need to care about types during every act of programming, then lets follow that thread and see where it leads. When do you need to care about types, and how big portion of a programmers time is spent on thinking about types?

My own expensive provides the answer "rarely" and "as little as possible". The few times I do care about types is when interacting with third-party functions, and in those cases I read the manual to figure out what their functions are returning and what I can expect to use. I do not however write test that verify that a function that is documented to return a string actually do return a string (or expect my compiler to do it for me). If the documentation is incorrect then I treat that as a bug, just as if it was a logic bug.

It would however be interesting to hear how much others spend time on it, and in what kind of acts of programming.

I think about types (almost?) every time I write a function. What type of data does the function expect, and what type of data am I supposed to transform this data to?

For instance, if I calculate the time that has elapsed between two points in time: - what does my input look like (e.g. two objects that look like XY) - in what form should I return the difference? Time in seconds (i.e. number), again an object that looks like XY ? ...

I can't imagine saying I would care about types rarely.

Another nice benefit of st langs is that you have to read manuals less often. IDEs so a way better job showing you the type of every variable (and result of an operation) as well as the options you have at your hand for a given type (including their documentation and example code). Yes I know dt languages and their tools try to catch up.

> or expect my compiler to do it for me). If the documentation is incorrect then I treat that as a bug, just as if it was a logic bug.

Well, I don't expect that with Dr languages as well, but I am glad that the compiler does this (or in DT languages at least the IDE due to type hints). I mean, it saves a lot of time (money) later on ... even if you notice it right away the first time you use the code

Interesting, let me do the same example and see how my thought process differ.

I would first ask, should I write a function or maybe have this as an property of the object that has the original data. I want the intended interface to influence my design.

What methods does my input has? Does it already implement what I want or have a helper function that makes writing the transformation easier? Is there built in functions or third-party libraries that do time differences calculations.

Within python I would apply some minor assumptions about types. If something is a time it is either a string or an object with a time interface, and so I might need to cast it to a time-like object. Preferable this already occurred as close to the edge of the program as possible so in the rest of the program I don't need to put any thought about the type. If its a date, it should be a an object with a time interface. If time strings are floating around in the data flow, just as with byte strings, I should try to fix that as early and close to the edge of the program.

There seems to be a similar view about unicode. You don't want to have every function check if the input is of the type unicode. Instead what people do is when they read a byte string, they turn it into unicode as everything else assume the unicode interface.

Thanks for confirming

This. I was wondering if it's because I'm a web dev that I rarely care/think/debug typing issues or what. I hear the stories I'm just not sure what everyone is talking about. I did have that in js a bit (the good old == vs ===) but not with Ruby.

If you do not care about the type, and indeed do not do anything special with it other than pass it through to somewhere (that may or may not care about it), then there are types that let you do that.

A good typed language will allow you to be more or less strict about what you accept (eg. a specific literal string, a set of strings, any string, any string like object, any object...)

If there are types that allow you to not care about the type, then why have a type?

People argue that they need types to very that you do not add in programming errors, and in order to easier read what the code does. In the environment I operate in and the jobs I do, types do not achieve those things. All they do is add unnecessary information and restrictions that need to be worked around.

Shell is an interesting environment in that there really is only one type: string. There are no int, no floats, barely any arrays (rare enough that I don't ever use them). You run a program with string inputs and you may get an string output in return. The majority time writing a shell script is spent on manuals, understanding how different programs interact, and data flows. This remain mostly true for dynamic languages. For static typed languages some of the time get redirected on dealing with types, declaring types ahead, and making sure the type declarations and castings are correct.

    If there are types that allow you to not care about the type, then why have a type?

The type represents a set of properties about the inhabiting values so if you have an opaque value you don't want others to inspect, wrapping it in such a type makes that explicit throughout the rest of the program. That information is not available if every value in your type has the same type. Presumably though you will actually attempt to do something with the contained value at some point so you must have some expectation about what it is.

You're making an entire argument about something you clearly haven't properly tried. It sounds like you have your own misconceptions about what static typing is and how types work. Your premise is flawed so it's difficult to have a conversation.

I would encourage you to try typescript for a while, it's very approachable and has excellent tooling.

One can measure the quality of a discussion in how often people refer to the arguments, and how often they refer to the person. You're making... you have your own misconceptions... Your premise is flawed... encourage you to try...

I have worked with 10+ different languages, multiple different IDE's, some types and some dynamic, some like shell which doesn't really have the concept of types at all.

If you are encouraging me to try typescript because you think its great, then I would encourage you in return to test python in combination with system and integration tests. It makes for a very safe environment where you know your code is working.

You can maintain that if you like.

I don't want to speculate why you feel so attached to static languages. I worked with python in 15 years, you in 17. I have done low level embedded C code. I done web development, and shell scripts. Tried lisp, and programmed in Ada. If you have also worked with similar amount of languages and reach a different conclusion then either your work is very different from mine, or you as an other person have a different experience than mine.

When it comes to keeping simple thing being simple, static languages has never delivered for me. In embedded system I live with that aspect, but that's the nature of such environments. The primary question when working with dynamic language is: "is there already a library that does what I want, and how do I modify it to work in my use case". Instead of thinking about structure and types, I am thinking about interfaces.

I will conceit one example where a static typed language is much better than a dynamic typed, and it illustrate the environment where such language aspect shine. SQL. SQL with dynamic types would be horrible and any database which treat types some-what dynamic is a horror to work with. SQL does not make simple things simple, and database exceptions are quite harsh in every aspect. There is also few if any interfaces, so its types or nothing.

Douglas Crockford, "Javascript: The Good Parts" (2008):

  "But it turns out that strong typing does not eliminate the need for careful testing.  And I have found in my work that the sorts of errors that strong type checking finds are not the errors I worry about."