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

171–180 of 468 posts

Re: Things I Was Wrong About: Types

#171

Post by chousuke »

knocte wrote: post #67
chousuke wrote: post #29

For my use cases, the vast majority of errors with dynamic languages boil down to being able to run scripts that have undefined variables; I'm prone to (mental) typos, so if I had a dialect of Python that failed before runtime when undeclared references exist, I could probably cut the number of iterations I need to arrive at a working script by at least half. I've never found a valid use case for allowing undefined r…

Just make the jump for once: https://github.com/knocte/2fsharp/blob/master/python2fsharp.... (yes you can write scripts with this language).

I most often choose Python because it's what's available, and it's good enough for the things I need to use it for. Other people can generally understand my code, too.

F# probably is a good language, but I haven't had a good enough reason to use it.

Re: Things I Was Wrong About: Types

#172

Post by igouy »

mantap wrote: post #59

A good static type system is better than dynamic typing. But, dynamic typing is better than a bad static type system. A bad static type system will slow you down, forcing you to appease its irrelevant complaints, and pervert your code into a form that no sane programmer would choose to write it in, if it weren't for the type system looking over their shoulder. I won't mention any names, but suffice to say such langua…

good is better than bad !

Re: Things I Was Wrong About: Types

#173

Post by loup-vaillant »

jondubois wrote: post #84
alkonaut wrote: post #80

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

Abandoning a feature just because it enables a misuse is the wrong way to do it in my opinion. Yes, some inexperienced, stubborn, stupid, or hurried developers will pass around complex types when they really shouldn't. But no, this drawback does not nullify the massive advantages of (good) static typing.

Sure, interfaces should be kept small. Let's to just that, then! Recognise that we want our classes/functions/modules to be deep (small interface/implementation ratio), and frown upon shallow instances in code reviews.

No need to give up static typing.

Re: Things I Was Wrong About: Types

#174

Post by marcosdumay »

kybernetikos wrote: post #147
marcosdumay wrote: post #131

Earlier quoted context omitted.

There's a lot of things, some about old-school types (Java, C), other about modern ones. I don't think most are fundamental, even though some are common experiences today. #1 is fundamental. (Yet people somehow live with the JS ecosystem that's slower than GHCi.) It's supposed to evolve into always becoming a smaller problem, since computers are always getting faster; but I don't think we've put everything we can int…

> #2 and #3 are about old-school types. There absolutely are approaches to this that don't fall foul of my complaints, but when you say 'old-school types' I think you're talking about Java and non inferred types. I was including other more modern languages in my criticism. Scala for example ends up with pretty hairy types very quickly for higher level code. So much so that they made the documentation system lie about…

Yes, I meant types systems like Java's.

I was thinking about unusable code, caused by the need to write way more down in brittle types than anything you save on coding. In fact there are problems with complex types.

Re: Things I Was Wrong About: Types

#175

Post by jenscow »

mannykannot wrote: post #166
jenscow wrote: post #125

Earlier quoted context omitted.

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

But that doesn't mean hide everything from view just because it can be accessed via a keyboard short-cut or mouse movement - my eyes are faster and easier to move. Also, code isn't read exclusively in an IDE, nor the same IDE that I use.

Re: Things I Was Wrong About: Types

#176

Post by cconroy »

TeMPOraL wrote: post #141
cconroy wrote: post #99

Earlier quoted context omitted.

"statically, strongly typed Lisp that still doesn't sacrifice its flexibility and expressive power" SML

... with sane (i.e. s-expression based) syntax. :). But I'll check out SML. That's Standard ML, right?

Yeah.

ML syntax is very pleasant, and roughly, sexprs w/o all the punctuation noise.

I don't believe it has a macro capability like lisps though, but you gain a sophisticated type helper.

Definitely worth looking into!

Re: Things I Was Wrong About: Types

#177

Post by withinboredom »

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…

To expand on that, the options also have trade-offs. They can both be just as right or wrong, and the trade-offs be the deciding factor.

Re: Things I Was Wrong About: Types

#178

Post by adnzzzzZ »

pansa2 wrote: post #170
williamdclt wrote: post #111

Earlier quoted context omitted.

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

I think the same. This is especially true for games where you're absolutely running the game again for everything you change, and in case anything is wrong it's generally very obvious visually.

Re: Things I Was Wrong About: Types

#179

Post by stevelosh »

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…

> However, the CL type system is very much lacking compared to Rust or Haskell. 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.

https://github.com/stylewarning/coalton looks promising, and stylewarning has recently said he's still working on it.

Re: Things I Was Wrong About: Types

#180

Post by lights0123 »

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…

All the major Rust IDEs (VS Code, IntelliJ, and probably Vim + others) show the variable type inline when you don't provide it explicitly: https://i.imgur.com/96Wfukl.png

The white text on a gray background is provided by my IDE.

Post reply on HN