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

321–330 of 468 posts

Re: Things I Was Wrong About: Types

#321

Post by ysavir »

dcre wrote: post #307
ysavir wrote: post #225

Earlier quoted context omitted.

Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be wr…

You can use these features very easily in Vim with ALE. Map a shortcut to :ALEHover and that's it. https://github.com/dense-analysis/ale

Upvoting so that people who need this may see it and benefit from it.

However, it's not that I'm not aware of features available to my editor of choice, it's that I specifically don't want an editor with those features. I don't want that functionality as part of my workflow. I prefer to reduce the noise and distraction so that I can keep concentrating on what's currently important to me.

Bringing this back to what the root parent was talking about, a significant part of code maintainability comes down to how we design our classes, services, etc. It's not so much about static or dynamic typing--both can experience their fair share of problems--it's about approaching our code in a way that makes it easiest for future readers and maintainers to pick up where we left off. That's a difficult task, but one that makes a huge difference. Saying that specific editors can alleviate some of those problems misses the point: that the underlying code itself is not well designed. What I meant to add is using these editor tools not only fails to fix the underlying problem, but that it also forces developers into tools they may not want to use.

Re: Things I Was Wrong About: Types

#322

Post by jkoudys »

temporallobe wrote: post #130
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…

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…

I did Java dev for a while, after being C before then. I felt like everything needed a pile of typecasting in front of it to work, even though these were often objects for classes you'd think should all play nicely. I realized only after dealing with it for so long that Java wasn't supposed to work that way, but how things can work when well written, vs old apps where half the code is written by a long line of 4-month co-op students, are two very different things.

Ultimately I think people just weren't given any credit for making good, reusable types, because then the next dev who submits a better feature faster using your work gets a raise, but you look like a kook ranting about best practices who doesn't do anything "business".

Re: Things I Was Wrong About: Types

#323

Post by noema »

jondubois wrote: post #75
dynamite-ready wrote: post #27

Types are useful, but they are currently trending, so now, they might often be forced into situations where they might not be needed. Programming languages and their type systems are tools, at the end of the day. Occasionally, an overwrought system of types will slow you down, or quite possibly make simple changes impossible. On another day, some other type declaration could save you hours of debugging, or speed up y…

Type hype is real. It almost seems like job-creation propaganda at this stage. When I judge things, I look at practical outcomes; and the fact is that I produce better software with more features within the same timeframe if I use JavaScript rather than TypeScript and the product in both cases is equally robust. This has been true for me both independently and as part of a team. With JS, I can write more code and mor…

This doesn't conform with any of my experiences in non-trivial JS codebases. Migrating to TS tends to reveal previously overlooked implicit typing issues. Also, I find the "upfront productivity loss" of TS to be overstated: adding in annotations here and there doesn't take much time at all, and pays dividends quickly. Many hours have been lost tracking down some elusive runtime bug stemming from a typo in a vanilla JS property access.

Re: Things I Was Wrong About: Types

#324

Post by Consultant32452 »

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…

My second job had a lot of VERY old C code. They were viciously strict about enforcing Hungarian notation for variable names. This is a workaround for your concerns, but I prefer types any day.

Re: Things I Was Wrong About: Types

#325

Post by remexre »

throwaway894345 wrote: post #249
thurn wrote: post #219

Earlier quoted context omitted.

I agree with this for really large codebases, but I think you can get a surprising amount done before your program becomes "non-trivial" using a good dynamic language. For example, the website you are writing this comment on has been perfectly maintainable in lisp without any static typing for the past 15 years.

I get the feeling that lisp doesn’t produce as many runtime type errors as Python or JS and I’m not really sure why that would be. Maybe there’s something to a functional style of programming that improves quality even apart from type checking?

Arc "feels" a lot more Scheme-like than Common Lisp-like, but pg is a CL guy afaik; my observations on the two:

Scheme avoids type errors by writing programs which could be given static types with a sufficiently powerful type-checker. If a Scheme programmer needs to define two aggregates, both of which have a property "name," they're likely to define two different functions, foo-name and bar-name, to get at them. This, though it's noisy, makes type errors more obvious.

CLOS helps avoid type errors too, since it encourages thinking not about how code interacts with a single type, but instead how it interacts with a whole _protocol_ of methods. I think multimethods in general are a powerful design tool that help avoid type errors in a dynamic setting, but I haven't had a chance to try them out in a language other than CL.

Many CL implementations also have static type-checking. For example, when I try to define a function with a type error in SBCL:

  * (defun f (x) (+ 1 x (car x)))
  ; in: DEFUN F
  ;     (CAR X)
  ;
  ; caught WARNING:
  ;   Derived type of X is
  ;     (VALUES NUMBER &OPTIONAL),
  ;   conflicting with its asserted type
  ;     LIST.
  ;   See also:
  ;     The SBCL Manual, Node "Handling of Types"
  ;
  ; compilation unit finished
  ;   caught 1 WARNING condition
CL's philosophy here differs a bit from most typed languages: SBCL will emit a warning (not an error!) for code it can statically show is impossible to run without getting a type error, while e.g. GHC gives an error for any code it can't statically show doesn't get a type error. However, in my experience, many type errors are obvious enough that SBCL warns about them (e.g. passing a vector where a list was expected, a string where a symbol was expected, nil where a non-nil value was expected, etc.), so this helps quite a bit, especially when combined with the interactive editing one gets through SLIME/slimv.

One can also attach type annotations to functions [0], and SBCL (and probably other implementations) will add a runtime CHECK-TYPE [1] unless you tell it to optimize for speed enough.

[0]: http://www.lispworks.com/documentation/HyperSpec/Body/d_ftyp...

[1]: http://www.lispworks.com/documentation/HyperSpec/Body/m_chec...

Re: Things I Was Wrong About: Types

#326

Post by scubbo »

mumblemumble wrote: post #314
cannabis_sam wrote: post #277

Earlier quoted context omitted.

It’s honestly embarrassing to hear all the worthless arguments against types. The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load??? It’s just so endlessly easier to prog…

Here's my split personality: I love love love Python for data science, in part because it's dynamically typed. I can bang things out quickly without worrying about the engineering bits, and, since I'm working in an interactive coding environment, it's generally easy enough to just inspect the values of my variables to figure out what they are. I hate hate hate Python for ML engineering, in part because it's dynamical…

This is absolutely it. Untyped languages are great for glue-scripts, for exploration (of an API, a dataset, whatever), for quick-and-dirty things. As soon as your logic grows beyond "what can be appropriately expressed in <5 files" and/or "this is going to have a second developer", types become helpful.

Re: Things I Was Wrong About: Types

#327

Post by 5n »

mumblemumble wrote: post #314
cannabis_sam wrote: post #277

Earlier quoted context omitted.

It’s honestly embarrassing to hear all the worthless arguments against types. The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load??? It’s just so endlessly easier to prog…

Here's my split personality: I love love love Python for data science, in part because it's dynamically typed. I can bang things out quickly without worrying about the engineering bits, and, since I'm working in an interactive coding environment, it's generally easy enough to just inspect the values of my variables to figure out what they are. I hate hate hate Python for ML engineering, in part because it's dynamical…

IMO dataframes are the reason why dynamic typing fits data science so well. It's certainly possible to represent a single dataframe as a static type; but representing all the slicing, column removal, joins, etc. is actually pretty hard without dependent tricks. So bypassing types for data frames is preferable. On your ML engineering point, the other side of it is that once your dataframe's schema is finalizes it really should be statically typed so that assumptions can safely be made about what is/isn't inside of it

Re: Things I Was Wrong About: Types

#328

Post by still_grokking »

zabzonk wrote: post #312
throwaway894345 wrote: post #295

Earlier quoted context omitted.

C++ has only recently acquired type inference, as have most of the others in the prior generation of statically typed languages.

Almost 10 years ago is "recently"?

Time flies. :-)

Re: Things I Was Wrong About: Types

#329

Post by krzat »

bo1024 wrote: post #199
skohan wrote: post #187

Earlier quoted context omitted.

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

This kills me about python. So many times I cannot figure out what exactly a functions expects and what it returns, sometimes even from reading the documentation! Matplotlib is especially bad.

This is the most ridiculous thing about dynamic languages, I don't understand how people can be productive in such environment. Meanwhile I just press few keys and IDE shows my all about I need to know about that function. Oh, and it also runs 100x faster.

Re: Things I Was Wrong About: Types

#330

Post by sporkland »

jkoudys wrote: post #315
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…

My personal favourite omnipresent php vars are `$data` and `$value`. Like, no shit, what else are you storing in variables?

Early on at the company I'm at now they decided to exclusively use $params for param passing to functions as the one true way to do things. It supports easy default params, named params, an easy passing of config through to deeper layers without needing to know about it at intermediate layers.

What it doesn't support is any sort of readability as a code base scales. It's often hard to know how the function you're calling will behave because the param can tweak some flag and totally change the behavior.

Post reply on HN