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

161–170 of 468 posts

Re: Things I Was Wrong About: Types

#161

Post by mplanchard »

TooCreative wrote: post #150
mplanchard wrote: post #116

Earlier quoted context omitted.

Most type systems also provide information about what’s in the array, like Array or int[]

That is just another piece of metadata. But it does not help either. Now you know you get an array of strings. But you still don't know what is inside of the strings. It might be ['headers'=>'...','body'=>'...' ] or ['status'=>'...','response'=>'...'] or god knows what. And you are back to reading the function body.

Is that like a hashed array you’re implying? In that case, the type wouldn’t be string anyway, but something like HashMap, Object, Dict, etc. More commonly though, something like HTTP options would be its own type, with defined properties, which you could browse via autocomplete or your IDE’s hover/peek functionality. That type would then specify the types of its values, so you can be certain that options.status is an integer, for example.

You’d generally only use an otherwise untyped array of strings when you can’t know beforehand what their values can be.

Re: Things I Was Wrong About: Types

#162

Post by karmakaze »

eru wrote: post #128
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…

Sum types even work when you actually have the multiple of the same return types. (Ie in Haskell `Either String String` works just as well as `Either String Int`; the types don't have to be distinctive.)

That follows from the definition being tagged 'Left'/'Right':

  Either a b = Left a | Right b

Re: Things I Was Wrong About: Types

#163

Post by tluyben2 »

kybernetikos wrote: post #149
tluyben2 wrote: post #139

Earlier quoted context omitted.

> Yet people somehow live with the JS ecosystem that's slower than GHCi. I think a lot of people, including the parent, seem to equate speed of ecosystem and iteration with web development and instant reload of web pages. When other systems allow fast iteration, it goes unnoticed unless it's for web dev. Luckily, a bunch of those 'impossible' systems have to now too, like [0]. [0] https://ihp.digitallyinduced.com/blo…

Web development is an example. Fast iteration is the thing that I like. I have so far associated fast iteration with dynamic languages, and it is certainly the case that my experience is that most fast iteration systems are dynamic. But maybe that simply reflects a concern of the relevant communities. If strongly typed language systems start adding fast iteration approaches to things and are able to achieve a similar…

> Fast iteration is the thing that I like

> haskell since 2000,

Things changed a lot in 20 years.

Thanks for noting down something about your age; I have always been a bit ageist about 'fast iteration' as I never met someone close to my age (been devving professionally for 30 years this year) that cares too much about it. I am not a very good programmer, but a very experienced one and i'm consistently faster at delivering than my 'fast iterating younger peers' as I simply know what i'm going to type beforehand, I don't need too many iterations to get it right and I have enough experience to know that i'm close to what we need after it compiles. The people who just type/run 1000 times/minute get stuff done, but it's not the way I would ever like (or liked) to work.

> It will necessarily be slower,

GHCi is fast but other avenues can be explored as well, like creating a real interpreter just for development , like Miri for Rust. Only for faster iteration of logic, you forgo some of the type benefits, but when you are done iterating, you compile and voila. I guess the merging of incremental compilation, jits, interpreters etc will evolve in something that might not run optimally but gives blazingly fast iteration up to perfect performance after deployment. And anything in between.

Re: Things I Was Wrong About: Types

#164

Post by rswail »

withinboredom wrote: post #158

I work on the big data side of Automattic, so I tend to work with PHP, Typescript/JavaScript, Python, and Scala, but I also work with C# for fun. When you work with and without types often, you realize that it doesn't matter. Types are great for expressing constraints on the code, but you can do the same thing with conventions in non-typed code. IMHO, type-less provides some resiliency. If you write code for a "strin…

Using interfaces/traits/protocols don't preclude strong typing.

If you write code for a type that "has" stringiness, as expressed by a trait, then anyone can build a variant of their types that expresses that trait.

Re: Things I Was Wrong About: Types

#165

Post by musingsole »

withinboredom wrote: post #158

I work on the big data side of Automattic, so I tend to work with PHP, Typescript/JavaScript, Python, and Scala, but I also work with C# for fun. When you work with and without types often, you realize that it doesn't matter. Types are great for expressing constraints on the code, but you can do the same thing with conventions in non-typed code. IMHO, type-less provides some resiliency. If you write code for a "strin…

Those who argue strongly for one method over the other are likely to not understand the one they're against. Which sucks, because if you do know both, there's rarely a reason to have strong feelings one way or another. So, once again the naive but vocal voices get all the decision power.

/Too many arguments at work are over dogma and I have to spend a lot of my time reminding people that there are options. That's all. There are options. Your kneejerk response to a problem might be fine -- might be right -- but there are always options.

Re: Things I Was Wrong About: Types

#166

Post by mannykannot »

jenscow wrote: post #125
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…

Personally, I prefer the type names to be at the start of the line, so I don't need to scan to the end of the line (or guess based on a function name). But I agree, it's a waste to type it all out. So I use an intelligent IDE that reduces the repetitive typing: So typing `Person.var` gives me `Person person = new Person();` or typing `Person person = ` will suggest `new Person()` Sure, it doesn't look as appealing wh…

I think you are making a good case for a somewhat different point: we have long reached the point where the tools we use for writing and reading programs can give us all sorts of semantic information on demand, and language syntax design should take advantage of the fact that everything the programmer needs to know need not be forced into just one flat page-of-text view of the code.

Alan Kay made essentially this suggestion when the requirements for the language that became Ada were being debated, but it was not taken up at that time.

Re: Things I Was Wrong About: Types

#167

Post by loup-vaillant »

asiachick wrote: post #83
loup-vaillant wrote: post #51

Earlier quoted context omitted.

Statically typed languages (or at least the good ones) are disciplined so the programmer doesn't have to. If you can work reliably with dynamic typing, that means you are very disciplined about giving the right data to the right function, in exactly the right form. That you are very disciplined about tests, possibly including fairly stupid-looking unit tests (which aren't actually stupid, at least in a dynamic contex…

how many times have you not used bash/dos/pwsh scripts because it's not typed? Maybe there's a place for both?

I can say what I do use Bash for: create files & directories, and simple string replacements in files. Anything more involved goes into a proper program. Usually OCaml, though I can fall back to more mainstream languages (Python, C) if I need a wide audience to be able to read it, and the program is simple enough that types aren't really a problem to begin with.

Re: Things I Was Wrong About: Types

#169

Post by hn_throwaway_99 »

I'll add a 4th thing to his list based on my experience moving from Java to Typescript:

Nominally-based type systems like Java (where you can only write Foo f = new Bar() if Bar has Foo somewhere up it's static type chain or interface hierarchy) are way more of a pain in the ass than structurally-based type systems like TypeScript (where you can say f: Foo = new Bar() as long as TypeScript determines Bar has all the required fields of Foo).

Primarily this makes refactoring much easier because you don't have to necessarily change things up a (potentially brittle) type hierarchy. Instead, you can just add new properties to your type to fulfill the set of properties required on the target type.

Re: Things I Was Wrong About: Types

#170

Post by pansa2 »

williamdclt wrote: post #111
loup-vaillant wrote: post #51

Earlier quoted context omitted.

Statically typed languages (or at least the good ones) are disciplined so the programmer doesn't have to. If you can work reliably with dynamic typing, that means you are very disciplined about giving the right data to the right function, in exactly the right form. That you are very disciplined about tests, possibly including fairly stupid-looking unit tests (which aren't actually stupid, at least in a dynamic contex…

> I found that static typing actually speeds up my development. It's less work, not more. It's a point that comes back often, and that I totally agree with so it's worth reiterating. In addition to the improved dev tooling (autocompletion, hinting, refactoring), being able to write large swathes of code without actually running it and being 100% confident that it's all _valid_ (not bug-free of course) just takes a hu…

> being able to write large swathes of code without actually running it and being 100% confident that it's all _valid_ (not bug-free of course) just takes a huge load off my mind.

I've heard similar things before, e.g. "static typing allows you to find bugs in your code without even running it".

Perhaps the reason I'm a fan of dynamically-typed languages is that I don't see the benefit of this. Maybe my workflow is unusual, but I don't write code without running it - I run tests every time I add a few lines.

Post reply on HN