Everyone have their opinions, that's fine, but who cares. It's a waste of time to write out your opinion or discuss them because they are just opinions.
Things I Was Wrong About: Types
371–380 of 468 posts
Re: Things I Was Wrong About: Types
#372Earlier quoted context omitted.
The correct thing is imho to pass an immutable SomeType or an interface that only exposes the parts of SomeType necessary for the calculation and doesn’t allow mutation of the object. Of course you don’t send around references to mutable objects and of course you only send to a function just what it needs - but that’s regardless of type system.
Sometimes this will be the best approach possible but adhering with this principle too strongly can overcomplicate the general design/architecture - It can give developers a green light to start passing around complex types all over the place and harms the separation of concerns principle. In terms of modularity and testability, the ideal architecture is when components communicate with each other in the simplest lan…
i think messaging is orthogonal to strong or weak typing (hence small/strongtalk, objc, self etc dont let you automatically coerce objects to different types than you expected) and those systems all use messaging
Re: Things I Was Wrong About: Types
#373Earlier quoted context omitted.
> Understanding other people's code is at least half the job of a programmer This was one of the pain-points when I was working more with node.js: the function signature told you nothing - like whether the function would even return or not would sometimes be a mystery. In very, very short scripts you can get away without types (like in a notebook for example), but once a project starts to get even medium size the tin…
> the function signature told you nothing - like whether the function would even return or not would sometimes be a mystery Yes! This drives me nuts about JavaScript! Untyped parameters are one thing, but having to read the entire function just to know if it returns anything is ridiculous.
To be fair, JS’s dynamic types aren’t solely to blame for this. There are dynamically typed languages that don’t require you to read an entire function body to know if it returns something. But, those are languages without statements, and all functions return something.
Re: Things I Was Wrong About: Types
#374Earlier quoted context omitted.
Here's my split personality: I love love love Python for data science, in part because it's dynamically typed. I can bang things out quickly without worrying about the engineering bits, and, since I'm working in an interactive coding environment, it's generally easy enough to just inspect the values of my variables to figure out what they are. I hate hate hate Python for ML engineering, in part because it's dynamical…
This is absolutely it. Untyped languages are great for glue-scripts, for exploration (of an API, a dataset, whatever), for quick-and-dirty things. As soon as your logic grows beyond "what can be appropriately expressed in <5 files" and/or "this is going to have a second developer", types become helpful.
I see it completely the other way around coming from the python, dynamically-typed side. For me, statically-typed languages have a benefit on the smaller-side of the scale, but absolutely bomb when the code-base grows. At that point everything is a FooFactory or an IInterface with no help from the IDE anyways because of IOC/DI/attribute reflection magic. And when it's that big, everyone argues over folder, package and inheritance hierarchies and the "right way" to refactor & reuse code, with the inevitable slide into yet another level of inheritance or interfaces. All the while peppered with Singletons, overloads and new abstract virtual base methods with complicated method override rules.
Obviously I exaggerate a bit, but we've all seen various incarnations of a lot of those issues.
Re: Things I Was Wrong About: Types
#375So basically, author likes type systems that are aimed around writing correct programs (haskell and rust) dislikes types when they are an implementation detail so the compiler knows how many bytes to reserve to store a variable (e.g. c).
The author didn't really change his mind, he just encountered a totally different type of type system with different goals.
Re: Things I Was Wrong About: Types
#376Earlier quoted context omitted.
I went a similar path, PHP to C#, and never looked back. When I had to switch to Node for one job I was pulling my hair out constantly (and quite literally) because of stupid things that would never have happened in what I called a “real” language (that being a typed, compiled one). I mean for $deity’s sake, there weren’t even any dependency injection options at the time and many many times it turned out a bug I intr…
If most business-side people actually knew what weak typed languages meant for their company, I can't imagine so many of them going for php/js as often as they do. You're always one expression with a `$contact` instead of a `$contract` in it away from a cancelled weekend trip or humiliating sales demo.
Honestly, I think there’s an equivalency there. Someone who is an expert in JavaScript means a couple of years. You can hire a high-end JS Dev for a lot cheaper than you could any other language or platform.
Re: Things I Was Wrong About: Types
#377I once told a JavaScript guru colleague of mine that I was spending my free time dabbling in Haskell. His response was 'lol, why would you do that?'. His point was that spending time learning things that you're not going to be using directly any time soon is a waste of time. My point was (and still is), that learning such things opens up a completely new way of thinking about problems and potential solutions.
Does he use Redux by any chance :-)
Oh, not popular.
To clarify the joke being Redux was inspired by Functional Programming.
Re: Things I Was Wrong About: Types
#378Earlier quoted context omitted.
I agree with this for really large codebases, but I think you can get a surprising amount done before your program becomes "non-trivial" using a good dynamic language. For example, the website you are writing this comment on has been perfectly maintainable in lisp without any static typing for the past 15 years.
I get the feeling that lisp doesn’t produce as many runtime type errors as Python or JS and I’m not really sure why that would be. Maybe there’s something to a functional style of programming that improves quality even apart from type checking?
This is partly right. FP approaches do tend to reduce the volume of mistakes, and reduce the kinds of mistakes you can make.
But that’s not because type errors are less likely. For dynamic functional languages they’re only less likely because the implicit contracts tend to be more general and the data structures tend to support a high degree of polymorphism.
The reason FP approaches tend to reduce mistakes is mostly that managing state is hard, and pure functions are easier to reason about.
Re: Things I Was Wrong About: Types
#379Earlier quoted context omitted.
> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime
I think yes. I do F# for a lot of time, and looking at past code I can't just figure some stuff. Not only their type system look alike dynamic, it make you build some stuff that is IMPOSSIBLE to get without a serious look at the types: And the types are invisible and behind abstracts constructs. With python, for example, I can't at first see what a function need but at least see the body give huge clues, because pyth…
F# lets you specify the types of function arguments and return values. If it will make your code easier to read and reason about, why not just do that?
I use Ocaml a lot, which is very similar to F# as you know... and I document the types of all toplevel values in my code. Not because the compiler needs it, but because it helps me navigate the code more easily.
Re: Things I Was Wrong About: Types
#380Earlier quoted context omitted.
Only annotations which can be checked by mypy or other linters. I think cpython doesn't check them at runtime.
And mypy is still very immature. You can’t denote a recursive type (e.g., a JSON type) or specify a callback that takes keyword arguments. Even getting it to load type annotations from third party packages is hard in many cases. Worse, it seems to be improving at a snail’s pace if at all.
A "JSON" type in Python is just an untyped dictionary. Is that not what you're looking for?
Also, python's type-hinting supports forward-references which are what you would use for recursive or "self-referencing" types.
Personally, I like the slow pace they're taking with the typing. It's touching the core usage of the language in a fundamental way and I don't think that can be rushed. We're seeing lots of community growth around the type-hinting, even using them at run-time, which is amazing to watch and marvel at.