There's now a trend to add gradual typing and type hints to dynamic languages, while at the same time, "static" languages are incorporating ideas from dynamic languages. So the end result is a symbiosis, not opposition.
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?
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.
f(x: a, y: b): c = ...
f :: a -> b -> c
f x y = ...
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.
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.
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...)
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.
I would encourage you to try typescript for a while, it's very approachable and has excellent tooling.
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.
I know how to make python safe with TDD. It doesn't even sort of compare.
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.
If there are types that allow you to not care about the type, then why have a type?
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.
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.
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
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.
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.
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.
I have provided examples in other comments where types is about as far away from my mind when writing complex programs. In terms of guarantee of safety, system and integration tests do that. Types are not based on customer requirements, nor do they verify that the program do what I get paid to do. A type is simply a limited set of automatic restrictions and tests to very that those restrictions are followed.
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.
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.
...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?
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.
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 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.
You can do that in statically typed languages as well (though not in every). See C++. Rust actively decided against it, and makes it the users responsibility to say "yes I indeed want to give this type to this function, because it satisfies the trait like this".
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.
Interfaces in TypeScript just describe sets of types, so yes you are still thinking about types (about types of types). I'd like to know why you think either one is (syntactically) required for programming (as we know ASM doesn't have either of those) Further, I'd like to know how you don't think about basic types in JS. Finally, I'd like to know why you couldn't fall back to (mostly) duck typing in statically typed langauges.
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.
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.
"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."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.
If I may ask, what ideas are static languages incorporating from dynamic languages? Could you help clarify?
It's handy if you need to add interfaces onto code you don't control (say, library code) as you can avoid a whole layer of adapter types / functions that you need in true statically typed languages.
But I'm curious if its a great idea in the long run to have interfaces being "accidentally" implemented by objects. Doesn't seem like it would stand up well to refactoring or various other scenarios.
(that's a joke)
∃a.P(a)
----------------- Remove-Exist
∀b.(∀a. P(a)→b)→b
Something that quacks like an iterable cannot be used as an iterable, unless the trait is explicitly stated — unlike python, where it simply has to quack.
[1] https://channel9.msdn.com/posts/MDCC-TechTalk-Classes-Jim-bu...
I don't know much about C# but how is this dynamic? Are those methods often added at runtime?
This was discussed in 2011 in a StackOverflow question [0], including a link to a blog post by one of the language designers [1].
[0] https://stackoverflow.com/questions/6368967/duck-typing-in-t...
[1] https://web.archive.org/web/20120126033827/http://blogs.msdn...
Also, over the past 20 years what you've seen is big advances in the 'semi-static' world like the JVM, where it runs statically typed languages but they have the ability to eval code, redefine their own code on the fly, reflect themselves, they're garbage collected etc. This is kind of a middle ground. It's worth remembering that when Python and Ruby were new, there weren't really any great options if you wanted lightweight syntax with garbage collection. Nowadays there is Kotlin and you can write code that looks very similar to say Ruby, but which often has the performance of entirely statically typed languages.
Lisps and MLs offered this before Ruby and Python got popular. Unless you don't consider them great options?
I suspect one issue is that Lisp never seemed to be well supported on Windows and never came out of the box on Linux, except perhaps for Guile, but Guile never reached any kind of critical mass despite being promoted by the GNU project. Maybe one reason is the lack of learning materials. Even today, although Guile has an initially pretty and appealing website, clicking "tutorials" reveals a complete lack of interest in growing that community - there is only one single tutorial, which is about how to embed Guile as a scripting language into a C program!
https://www.gnu.org/software/guile/learn/#tutorials
I remember learning Python in the 1990s. The learning materials were excellent. Java was also famous for extensive tutorials and learning materials (they've lost that in recent years, the modern Java docsites are just piles of specifications, but when Java was interested in growth they had it). In the end these things matter more than the exact nature of a runtime or type system.
No ML was a realistic workable option back then at all. Haskell is fine now, but was barely introduced in 1993. OCaml has become a workable option almost entirely due to the gargantuan effort of Jane Street, but again, it wasn't then. Standard ML remains terrible. Library support is sparse, there is almost no community outside of academics, no consistent implementation of the standard basis, compilers are wildly different from each other. The REPLs tend to be great, but it's very difficult to get from a set of source files to a portable executable, whereas with Python and Ruby, just writing the source files already gets you that.
> OCaml has become a workable option almost entirely due to the gargantuan effort of Jane Street, but again, it wasn't then.
What do you mean by this? I'm aware of dune and opam, but people were using C and C++ without equivalents before without problems. Python's package managment and building is also not that good, even today. I don't have a strong grasp of the history of OCaml so maybe they released Core, Base and Async really early compared to batteries and Lwt? But outside of that, basic OCaml with a makefile doesn't sound worse than C/C++.
> Standard ML remains terrible. Library support is sparse, there is almost no community outside of academics, no consistent implementation of the standard basis, compilers are wildly different from each other.
That's fair, my point is more that I don't really understand why no big company ever picked it. Considering how much companies invested in their tooling (Google with Java, Go, Dart, Python, C++ ; Facebook with PHP and C++ ; etc), they could have made something great.
> it's very difficult to get from a set of source files to a portable executable, whereas with Python and Ruby, just writing the source files already gets you that.
Depends on your definition of portable executable. I've always found deploying and distributing Python and Ruby painful, at least to end users. The best in class experience here for me is Go, it's great for end users, great for servers, cross compilation works well.
That isn’t the case for F#, and I would say it’s questionable for Python for anything larger than a couple source files.