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

181–190 of 468 posts

Re: Things I Was Wrong About: Types

#181

Post by withinboredom »

rswail wrote: post #164
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.

Yeah, for sure. That's certainly possible, but I rarely see people build for it, at least when it comes to value types like strings, ints, etc.

One other thing that I DO like about type-less, is the ability to introspect, for example, in PHP:

``` foreach ((array) $my_class as $property => $value): ```

vs. a bunch of boilerplate and making sure types match up in most strongly-typed languages.

Re: Things I Was Wrong About: Types

#182

Post by tluyben2 »

TooCreative wrote: post #160
tluyben2 wrote: post #91

Earlier quoted context omitted.

Got that, but was triggered by ‘algorithmic structure’; that sounds a tad ‘over the top’ when you then come with some basic web request. However, I would not call your example particularly well typed. Array is still basically untyped. When I talk about types I mean things like; Either AddGroup(string GroupName, User[]? users) In this case I know what I am getting and I know the users are already, when reaching the we…

And now instead of $body = Http::request('GET', 'https://example.com')['body']; You have to do this? $body = Http::request(new Method('GET'), new URL('https://example.com'))->body; And you have cuttered the global namespace with "Method", "URL" and "Option"?

Why would they be in the global namespace? They would be in imported namespaces (something\Http for instance). That's rather normal.

And yes, now you have to make sure you are passing the proper and valid types, which is obviously the goal here:

    $body = Http::request(Method.GET, URL.Parse('https://example.com'))->body;
In other languages you can make it so that the static URL is validated at compile time even.

Re: Things I Was Wrong About: Types

#183

Post by mgkimsal »

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()`.

Was recently on a project that just migrated to java 11 (mid august of this year) from java 8.

Someone has started to try to introduce 'var' and is getting push back from others. "it doesn't match current style" and "could be confusing" were some 'concerns'.

When you're trying to do

    InternalFormatParserCustomForClientABCDEF customerFormatParser = new InternalFormatParserCustomForClientABCDEF(param1, param2);
you really start to hit readability limits, and formatting things like going over nominal line lengths and such.

    var customerFormatParser = new InternalFormatParserCustomForClientABCDEF(param1, param2);
is certainly easier on the eyes, and the compiler can still known and infer what type 'customerFormatParser' is.

Re: Things I Was Wrong About: Types

#184

Post by loup-vaillant »

musingsole wrote: post #165
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…

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 write those tests first so we're not tempted to omit them.

Anyway, I redid the whole thing in OCaml, and this time got lots of compile time errors. Which I could correct, and once the compiler was happy, well… my program was basically correct.

---

I still don't rule out that other people's brains are wired fundamentally differently. I don't expect it, it would surprise me, but I honestly don't know. What I do know is that dynamic typing is not for me. I'll suffer through it to get other advantages (Python's comprehensive library for instance), but that's about it. Dynamic typing and I are otherwise done.

Re: Things I Was Wrong About: Types

#185

Post by jenscow »

TooCreative wrote: post #153
jenscow wrote: post #115

Earlier quoted context omitted.

A better example for a typed function would be something like: function Request(string method, string url, RequestOptions options) : Result {...} or Result Request(string method, string url, RequestOptions options) {...} Here, we know `url` is a string (rather than the parsed object), we know all the supported options (they're members of the RequestOptions object/enum), and every value in the return value. Some might…

For the example I simply took to a random, recently updated file from Symfony: https://github.com/symfony/http-client/blob/master/HttpClien... And shortened it a bit. In the real example, as you can see, there are even more parameters, making it even harder to read.

Well, for me it's easier - perhaps because I'm used to reading parameters in type+name pairs.

The data type is right next to the parameter name - and it will be in the pop-up provided by my IDE when I use the function... I don't need to look at the docs or comment (which may not exist).

Re: Things I Was Wrong About: Types

#186

Post by chrismeller »

pavel_lishin wrote: post #118

A 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 introduced was because of simple typo in a camelcase property name.

I absolutely love Node for the ease of writing something quick and dirty. No dependency injection, no coding standards, nothing but a tool to quickly churn through a ton of data or to perform a single task really well. I also think there are some frameworks (using Typescript, like NestJS) that do JavaScript apps really, really well. I will still, never, ever, ever voluntarily write any kind of “real” application in a language that is not type safe again. The benefits just aren’t worth the perceived time savings...

Re: Things I Was Wrong About: Types

#187

Post by skohan »

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…

> 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 tiny amount of time you put into writing a type name explicitly here and there is more than made up for by the degree it helps with the structure and correctness of your program.

Re: Things I Was Wrong About: Types

#188

Post by mceldeen »

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…

> IMHO, type-less provides some resiliency. If you write code for a "string" anything that satisfies "stringiness" will still run just fine.

Things like that are actually possible to do in a light weight way in FP languages and many of them are part of the stdlib. (PureScript happens to be my favorite example.) Many times it brings back the same feelings I had working in Ruby (which I also happen to love), but with the added confidence of a strong type system.

Re: Things I Was Wrong About: Types

#189

Post by valuearb »

jondubois wrote: post #65
adnzzzzZ wrote: post #33

I don't really see most of my code being improved that much by types and I also see a lot of extra complexity that people in the sphere I am (indie games) have to deal with when using typed languages. It just doesn't seem worth it. When you have to spend a lot of time fighting your language, and handling numerous extra concepts that don't exist in an untyped language because they don't need to, it feels like the peop…

I agree. I think the downside of static typing is that it encourages developers to pass around complex types between functions instead of simple types and I think this is a mistake. If you have the option between creating a function which accepts a string (e.g. ID) as argument or accepts an instance of type SomeType, it's better to pass a string because simple types such as strings are pass-by-value so it protects yo…

In Swift Structs are immutable and passed by value, class objects are mutable and passed by reference.

Using a struct is infinitely preferable to a string.

Re: Things I Was Wrong About: Types

#190

Post by couchand »

hn_throwaway_99 wrote: post #169

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

That isn't always a benefit, though. When interfacing with a database schema that uses small integers for ids, I'm all the time defining types like `struct CustomerId(u32)` and `struct InvoiceId(u32)`. It's incredibly valuable that the compiler will not let me mix up a customer and an invoice, even if both of them are 42.
Post reply on HN