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.
Then why did you waste your time by writing this one?
Things I Was Wrong About: Types
381–390 of 468 posts
Re: Things I Was Wrong About: Types
#382Earlier quoted context omitted.
In the Clojure world we use clj-kondo, maps, and spec to solve these problems We get editor time feedback of mistakes with optional type hints + light inferance via clj-kondo and a data modelling system that we can export out as database schema, JSON schema etc And dynamic enough constraint system to express something like all human names must be "Tony" only on Tuesdays The same constraint that can be shared server s…
Ya, that's why I think each language kind of benefit to different levels of having static type checkers and of various features as well. You can't just blanket say all type checkers are bad, or all language without one are bad. Clojure is a good example here, it actually can be used with a very powerful static type checker core.typed, yet its users chose not too for reasons that say in JavaScript maybe a different ch…
Does anyone still use core.typed? My impression was that Circle CI's article announcing that it was moving away from core.typed was effectively a death blow to its community. One of Circle CI's founders later went on to use OCaml instead of Clojure on his next project (Dark) precisely for its static type system.
None of that is to say OCaml is "superior" to Clojure in some way. I disagree with a lot of the ways that the OCaml type system has evolved and I wouldn't be surprised to see people who have moved to Clojure from OCaml. However, having programmed professionally in Clojure (although it's been quite a few years so I'm not familiar with the latest advancements in e.g. spec) I still think a Clojure-like language could benefit from a static type system.
I don't think it'll work for Clojure itself because of a variety of patterns and choices in the standard library (which is in part why I think core.typed died, we also found core.typed painful to use in some of our experiments at my old job both in how it interacted with Clojure and the tooling around it). And philosophically Rich Hickey would probably kill Clojure before he ever considered designing Clojure around a static type system. However a programming language based off the same data driven ideas could maybe do it.
While a REPL and hot code reloading are absolutely huge productivity boosts, they are more or less orthogonal to the benefits provided by a good static type system (see e.g. hot code reloading with Elm or Purescript which comes quite close).
The thing that static type systems provide over tests and runtime contracts is the ability to constrain users of the API of a library. We use regression tests to make sure regressions in code we write doesn't happen again. Likewise types are effectively regression tests at the API level to make sure certain regressions in code that calls our code doesn't happen again. That is an extremely powerful capability that I consistently miss in dynamically typed languages.
Re: Things I Was Wrong About: Types
#383Earlier quoted context omitted.
Having spent the last several years working in Node/TypeScript environments (and being firmly in the “I was wrong about types” camp), I think “isn’t so bad” is an overstatement. It certainly isn’t as bad. And especially as TS improves, the possibility to move more and more toward the “not so bad” ideal is there. But there’s some truly awful stuff in the ecosystem; in the underlying language and the platform’s DNA; in…
> or to invest in learning another platform What other platform do you have in mind?
Honestly haven’t given it a lot of thought, as I’m not currently starting a greenfield project with my pick of platforms.
But I think off the top of my head, languages that I’d look at as first contenders include F#, C#, Kotlin, Swift. I’m sure there are other good choices, for the kind of space I tend to work, that are equally productive and have enough of a community for me to be comfortable adopting them, but I would need to spend some more time researching options to really say with confidence what else I would consider.
Re: Things I Was Wrong About: Types
#384Earlier quoted context omitted.
> will ever swing back. Does it need to swing back? Python/JS/PHP/Ruby are still plenty popular. And no, JS isn't typescript.
JS is losing out to TS long term. Python is getting Mypy. PHP (and Ruby) are dying much more rapidly than many of their peers of similar ages.
PHP’s type system has improved (and continues to improve) by leaps and bounds. See my comment here: https://news.ycombinator.com/item?id=24607891
Also the Laravel framework for PHP has the most Github stars of any server-side framework: https://twitter.com/denicmarko/status/1309714816290951168
Re: Things I Was Wrong About: Types
#385Earlier quoted context omitted.
I've often felt that some people dislike types because they expect to be able to write code in a certain way that they know will make some very narrow happy path work now and they get really frustrated when the compiler tells them that there are other paths in the code that don't work. "Why is this stupid compiler slowing me down?!". This frustration betrays the programmer's indifference toward the broader quality of…
Yea, I agree and for this reason when I teach type systems to new programming students, I tell them that a type is somewhat analogous to a building material. You have brick, wood, steel and iron. You want to build a house that has solid bedrock and has easy forest fires in the area. What material would you use? Most would say rock. Then I tell them about strings and ints. You can represent 66 both with strings and in…
If we think of variables as boxes and types as label on those boxes, does it makes sense to have labels on the boxes if complexity of opening the box just to see what is inside goes up?
Re: Things I Was Wrong About: Types
#386A lot of people are making comments about how they can code "faster" without types. But for the majority of the code we write, inital speed isn't that important. Understanding the code and maintaining it are orders of magnitude more important for any non-trivial code. Types are not only a way for the compiler to understand your code and impose constraints. They're also your API to other programmers. When they see a s…
For many enterprises, getting code out the door is a key win. So in an idealist conception, maintainability, correctness and good design are everything. In the practical reality of today, these often have to take a back seat to speed of implementation. What I'd like to see is a language that allows typeless programming to start but which is designed to allow the imposition of types at a later point.
Python’s type hinting is specifically designed for this use case: https://docs.python.org/3/library/typing.html
Also, TypeScript is designed to work the same way, as it can coexist with untyped JavaScript code as you introduce it to the code base (it still has to run through a compiler, of course).
Re: Things I Was Wrong About: Types
#387A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…
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…
The other issue with dynamically-typed languages is that the language sometimes "helpfully" fixes the types for you. I came across one JS project that said this:
for (var i = 1; i != Math.pow(2, 16); i Re: Things I Was Wrong About: Types
#388Re: Things I Was Wrong About: Types
#389Earlier quoted context omitted.
I was never sure what to think of dynamic typing, until I tried to implement a fairly simple Earley parsing algorithm in Lua. The thing was 50 lines, and I was lost . I only managed to get runtime errors such as "you can't add functions, you can't apply a number, this reference is null… That's when I understood where TDD came from: dynamically typed languages require so many tests to work reliably that we better writ…
> The thing was 50 lines, and I was lost. The key to writing type-less code is making it so simple that you could cry. Avoid being clever at all costs. However, it's almost the exact opposite when you have a nice compiler checking everything, you can be mighty clever and know that it will work. I'm lucky in that we can solve a problem in a myriad of languages, depending on if it needs to be "realtime", or can be prec…
> The key to writing type-less code is making it so simple that you could cry.
I can't help but interpret this as "the key to writing type-less code is choosing problems so simple that you could cry". In other words, dynamic typing doesn't scale.
When I have a very simple problem to solve, sure, I won't mind dynamic typing. For anything worth more than an hour of coding however, I'll definitely reach for more reliable tools.
Re: Things I Was Wrong About: Types
#390A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…
I had a love/hate relationship with types for a long time.
I loved them because, well the things you mentioned.
But I hated them because in C++ it was required to open a separate header file to declare them.