Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

Post reply on HN
Print view View original

431–440 of 468 posts

Re: Things I Was Wrong About: Types

#431

Post by IshKebab »

chriskrycho wrote: post #256
IshKebab wrote: post #88

I don't understand why he thinks Typescript still isn't worth it, when all of his points are issues in JavaScript that are solved by Typescript.

I think you misread the post! I very much like TypeScript, am a core contributor to the TS work in the Ember.js ecosystem, and am actively involved in efforts to make TS a first-class supported language in my day job!

Oh, I was referring to this:

> If you talked to me about types in programming languages six or seven years ago, you would quickly have learned that I was not a fan.

> I was working with Python and JavaScript and simply didn’t miss types at. all

> I understand why I thought that types were worthless from 2012 – 2014. In fact, for the specific languages I had used up to that point, I continue to think that the types don’t really pay for themselves.

Re: Things I Was Wrong About: Types

#432

Post by kevinwcyu »

jt2190 wrote: post #284
mettamage wrote: post #257

Earlier quoted context omitted.

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…

Why do you need an analogy at all? Are your students deeply familiar with the construction characteristics of wood and brick already and ready to draw parallels to software? How do those things relate at all to the subject at hand, strings as “means of display” (data?) versus strings as “computational” (keywords, operators, etc?). Personally, I avoid analogies because they usually mean I don’t really know how to teac…

I appreciate analogies when I start learning something. Although it's not a perfect representation of what's being taught, it makes it easier for me to start thinking about the topic I'm learning. I can fill in the details later. I think it's useful for certain types of learners such as myself. Although I'm not deeply familiar with the characteristics of construction materials, I was more familiar with them compared to types when I was learning about them. So it would've been a helpful analogy for someone like me.

Re: Things I Was Wrong About: Types

#433

Post by higerordermap »

rswail wrote: post #159

A 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…

Also these days types are important for good IDE completion support, on-the-fly error checking and refactoring.

Re: Things I Was Wrong About: Types

#434

Post by nucleardog »

pavel_lishin wrote: post #410
jcranmer wrote: post #387

Earlier quoted context omitted.

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 Replacing Math.pow(2, 16) with 1 (It's been a while since I coded PHP, but my recollection is that PHP tries to pull a strings-are-integer tricks a few times).

> my recollection is that PHP tries to pull a strings-are-integer tricks a few times Yeah, the implicit casting in PHP is bonkers, especially when it comes to comparisons. The comparison table looks like the scribblings of a madman: https://www.php.net/manual/en/types.comparisons.php (though granted, Javascript acts very similarly.)

I have no hate for PHP, it’s been a tool in my toolbox for over a decade, I think it has a lot of good qualities, and it has made me a lot of money.

That said, after ten years of use, I still see something like:

    function_returning_false_or_int() > -1
And sometimes have the wrong intuition about what it does.

Now, nobody should write that shit in the first place, but turns out it’s equivalent to ‘!== false’.

‘(int)false’ is zero, but ‘false > -1’... is not true.

Re: Things I Was Wrong About: Types

#435

Post by Sammi »

eyelidlessness wrote: post #383
azangru wrote: post #370

Earlier quoted context omitted.

> 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 wo…

"F#, C#, Kotlin, Swift"

All tied in with one singular company each that calls all the shots - For good and for bad. You kinda get all their other stuff showed down your throat along with the languages and things can get bloated fast. But at least things are streamlined. Nodejs had an uprising with io.js in 2014-15 and is now governed by a foundation. I like that a lot. I sleep soundly knowing that no company can pull the rug from under me on a whim.

Re: Things I Was Wrong About: Types

#436

Post by reirob »

TeMPOraL wrote: post #72
echelon wrote: post #3

I followed a similar trajectory. Types were the bane of my early career. Hideous, extraneous. But really, they're the light at the end of the tunnel once you've worked your way though the dynamic / weak typing minefield. It took me a lot of Python, Javascript, and Ruby for me to get there, but now I'm way more comfortable on the other side. The correct type system is actually way more expressive than not having stron…

Same here! I've started with C++ and Java, learned to hate excessive typing, went through a long period of dynamic typing, and now I'm at the point you and the the author are. I still code a lot of Common Lisp on the side, but my Lisp code now looks entirely different than it looked just 3 years ago. The language standard does support optional typing declarations, and there's an implementation (SBCL) that makes use o…

> I'm hoping one day someone will make a statically, strongly typed Lisp that still doesn't sacrifice its flexibility and expressive power. I'd jump to that in an instant.

This part inspired me to look up the wiki page "Haskell Lisp [1], because I somehow remembered that some people were trying to make a Haskell that could be written in Lisp. But this page reveals even more interesting efforts:

> Shentong - The Shen programming language is a Lisp that offers pattern matching, lambda calculus consistency, macros, optional lazy evaluation, static type checking, one of the most powerful systems for typing in functional programming, portability over many languages, an integrated fully functional Prolog, and an inbuilt compiler-compiler. Shentong is an implementation of Shen written in Haskell.

> Liskell - From the ILC 2007 paper: "Liskell uses an extremely minimalistic parse tree and shifts syntactic classification of parse tree parts to a later compiler stage to give parse tree transformers the opportunity to rewrite the parse trees being compiled. These transformers can be user supplied and loaded dynamically into the compiler to extend the language." Has not received attention for a while, though the author has stated that he continues to think about it and has future plans for it.

But this page does not list everything and there is Hackett [2], which introduces itself with "Hackett is an attempt to implement a Haskell-like language with support for Racket’s macro system, built using the techniques described in the paper Type Systems as Macros. It is currently extremely work-in-progress." - though it seems that it didn't change since two years.

And finally there is Axel [3] - which introduces itself with "Haskell's semantics, plus Lisp's macros. Meet Axel: a purely functional, extensible, and powerful programming language."

Disclaimer: I never learned any Lisp, went from C/Java/JavaScript/Bash straight to Haskell and am a Haskell beginner for lifetime. Though I love the language and the fact that I will be learning it and surprised by it for the rest of my life.

[1] https://wiki.haskell.org/Haskell_Lisp [2] https://github.com/lexi-lambda/hackett [3] https://axellang.github.io/

Re: Things I Was Wrong About: Types

#437

Post by billisonline »

eru wrote: post #423
billisonline wrote: post #218

Earlier quoted context omitted.

Don't forget, much of that effort has now trickled down into the PHP language itself. We've long had scalar types for function parameters and return values, but with 7.4 and 8.0 we've added union types[1], nullable types[2], and typed properties[3]. While not a part of the language yet, generics can be annotated with the linting tools PHPStan and Psalm[4], and native support for these annotations is coming to the nex…

Coming from Haskell and Scheme, I'm now waiting for them to unify the syntactic handling of variables. At the moment, you have to put a $ in front of most variables, and no adornment for when you want to call something as a function. Reminds me of Common Lisp with its two name spaces for functions and other variables.

Yeah, the $ sigil for variables is a historical curiosity, but I don’t think it’s going anywhere. It would be an unacceptable BC break for codebases that have implicitly relied on this “two namespaces” behavior

Re: Things I Was Wrong About: Types

#438

Post by afiori »

Sammi wrote: post #435
eyelidlessness wrote: post #383

Earlier quoted context omitted.

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 wo…

"F#, C#, Kotlin, Swift" All tied in with one singular company each that calls all the shots - For good and for bad. You kinda get all their other stuff showed down your throat along with the languages and things can get bloated fast. But at least things are streamlined. Nodejs had an uprising with io.js in 2014-15 and is now governed by a foundation. I like that a lot. I sleep soundly knowing that no company can pull…

At least C# (and Swift too) is pivotal to that one big company offering. Free software and openness are important but they are not a silver bullet against bad management.

Re: Things I Was Wrong About: Types

#439

Post by _54qb »

slifin wrote: post #241
temporallobe wrote: post #130

Earlier quoted context omitted.

Even though I learned C/C++ in school, I started off my career with a typeless language, Perl. I loved it for its simplicity and power to quickly spool up working code, but realized it was problematic to use for large projects for many of the same reasons you state. I then switched to a Java project and was immediately frustrated with types because of how verbose it was, but after a while I came to appreciate just ho…

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…

I still can feel very lost when refactoring a complex clojure system as opposed to something like Rust, because you have very little information about all the places in your codebase where a certain assumption was made.

You can go crazy and spec everything, in fact that can help, but:

- In practise, nobody does it

- Specs come with no guarantees. They could even be wrong.

- The official implementation stubbornly insists on not checking return types, so half of your annotation may just be glorified documentation (although you can use third party libs like orchestra)

Just imagine: Add a new required field to a spec, and get a convenient list of source code locations that you need to review. That's the promise of a statically checked system. It's not a silver bullet, but not having this leads to what I like calling "refactor anxiety" (i.e.: did I handle all cases?)

I still love clojure no matter what. I think in practise you can express so much, so elegantly, and with far less code, that your project size is always sorta manageable.

Re: Things I Was Wrong About: Types

#440

Post by metters »

svieira wrote: post #142
aazaa wrote: post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

Once you get to Java 11+ you get `var`, so you can spell it `var me = new Person()`.

Just don't use it together with lombok.
Post reply on HN