Things I Was Wrong About: Types • Hacker News Board

Re: Things I Was Wrong About: Types

#281

Post by mannykannot » Sun, Sep 27, 2020, 6:12 PM UTC

deckard1 wrote: post #220

mannykannot wrote: post #166

Earlier quoted context omitted.

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…

This has always been the case. Emacs could do all this decades ago. Genera/Lisp, Smalltalk, etc. to various degrees did this. And they all failed to make their case. Time after time. Hiding context has always been bad for understanding code. The same reason dynamic scoping went out of style the moment lexical scoping was invented. Or that GOTO is considered harmful. Or that we all prefer simple, small functions rathe…

Showing all the context has never been feasible, and abstraction is about how to deal effectively with that constraint. Types are abstractions, and consequently explicitly declaring a variable's type does not provide all the context.

The original C++ 'throw' declaration is an example of an ill-conceived attempt to provide and use more context, and an example where tools provide a better solution than piling on the syntax.

Re: Things I Was Wrong About: Types

#282

Post by SebastianKra » Sun, Sep 27, 2020, 6:13 PM UTC

ysavir wrote: post #225

billisonline wrote: post #212

Earlier quoted context omitted.

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime

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…

These features are now available in all common text editors.

Also keep in mind that you're missing out on many other arguably essential tools such as debuggers, smarter shortcuts, and other static analysis.

Therefore, yes, I think it should be expected of a programmer to pick the right tools for the job, in the same way that it can be expected of a designer to be able to work with Adobe files.

If classic VIM doesn't offer these features, then it isn't sufficient as a code editor anymore.

Re: Things I Was Wrong About: Types

#283

Post by marktangotango » Sun, Sep 27, 2020, 6:16 PM UTC

cannabis_sam wrote: post #277

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…

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…

I agree with this 1000%. Projects (note not programs or individual source files!) are simply easier to grok (maintain, enhance, debug, refactor) with statically (and strongly) typed languages than dynamic IMO.

Five years ago when switching jobs I’d pursue “full stack” positions because I’d done a fair amount of front end dev in the past. No more, me personally, I’m backend all the way. Dynamic typing (vanilla js) is just harder; more time consuming more cognitive load, IMO.

Re: Things I Was Wrong About: Types

#284

Post by jt2190 » Sun, Sep 27, 2020, 6:23 PM UTC

mettamage wrote: post #257

throwaway894345 wrote: post #138

Earlier quoted context omitted.

I've often felt that some people dislike types because they expect to be able to write code in a certain way that they know will make some very narrow happy path work now and they get really frustrated when the compiler tells them that there are other paths in the code that don't work. "Why is this stupid compiler slowing me down?!". This frustration betrays the programmer's indifference toward the broader quality of…

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 teach the topic, and I’m “hand-waving” on the fly. I either find a way to build on the student’s existing knowledge or I “park” the topic for discussion when the student has enough knowledge to give a correct answer.

Re: Things I Was Wrong About: Types

#285

Post by ysavir » Sun, Sep 27, 2020, 6:26 PM UTC

SebastianKra wrote: post #282

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…

These features are now available in all common text editors. Also keep in mind that you're missing out on many other arguably essential tools such as debuggers, smarter shortcuts, and other static analysis. Therefore, yes, I think it should be expected of a programmer to pick the right tools for the job, in the same way that it can be expected of a designer to be able to work with Adobe files. If classic VIM doesn't…

> These features are now available in all common text editors.

It's not just a matter of whether they're available, it's a matter of whether it's a fair expectation.

I've been developing for a decade and never found that I'm "missing out on many other arguably essential tools". Typically I'm as productive or more productive than my peers.

I get that you think usage of these features is a fair expectation. Can you provide your argument for why you think that's a fair expectation?

Re: Things I Was Wrong About: Types

#286

Post by vlovich123 » Sun, Sep 27, 2020, 6:27 PM UTC

jenscow wrote: post #175

mannykannot wrote: post #166

Earlier quoted context omitted.

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.

A lot of tools can put the type inference result for all variables when you are reading code (pycharm does it during runtime but IntelliJ + rust did it dynamically as I typed if I recall correctly)

Re: Things I Was Wrong About: Types

#287

Post by dynamite-ready » Sun, Sep 27, 2020, 6:31 PM UTC

rswail wrote: post #154

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…

The focus of industrial development for a long time has been focussed on the processes, or the verbs, not the things, or the nouns. Focusing on the Nouns and the types of those Nouns lets you understand what states they can be in and more importantly, the ones they cannot be in. By using types as much as possible to express those invariants and constraints, you can make sure that the processes don't do something that…

As long we can both agree, that at an elementary level, it's faster to write code in a dynamic language, than it is with a strongly typed one, then there will always be a trade-off to consider. Like the trade-off between using glue and nails.

Being able to change things quickly, or describe things creatively is occasionally going to be more helpful than immutability guarantees in some product domains. That practical focus is the very reason why dynamic languages are so popular. They facilitate rapid iteration, which is a quality which also certainly can lead to positive results when programming.

A focus on 'process' is really an understanding that the 'noun' is subject to change, as requirements so often do in engineering and product development. I suspect the modern dynamic languages are a response to this focus on practicality, with Ruby probably being one of the bests illustrations of this idiom (I don't write much Ruby at all, but respect it for what it is).

However, this purely practical focus is not always the most desirable quality in a programming language, and in those domains where you know your requirements are written in stone, then an effort should be made to describe requirements as formally as possible.

But a myopic preference for only one approach to writing software, will probably introduce some flaw into your program, no matter what language you are using.

Every single language is an abstraction after all.

We moved away from Assembler in an effort to focus attention on expressing what tasks computers should perform. Dynamic languages are a logical result of that focus.

Re: Things I Was Wrong About: Types

#288

Post by ysavir » Sun, Sep 27, 2020, 6:31 PM UTC

bdavis__ wrote: post #252

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…

i tend to agree with you. maybe more than just agree. if any of these "IDE's", or "tools", or whatever they are called actually provided a universal improvement in software quality and development time, then i would change my view. experienced developer, the tools don't make a difference. VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal.

> VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal.

Exactly. If specific tools allow specific people to work better, great. I completely support them. But it's unfair to say that what works for some will work for all.

My goal when adapting practices is to adapt the practices that allow each developer on the team to work in the way that's best for them, and to avoid rules that limit developers in their choices.

Always willing to update when a clear case is made, though. Recently I stopped my rule of "80 characters per line max" because I don't think 80 character wide screens are common enough to warrant my consideration. Now I limit line length based on what makes that line of code most easily digestible--whether 30 characters, 80, 140.

Re: Things I Was Wrong About: Types

#289

Post by joshuamorton » Sun, Sep 27, 2020, 6:33 PM UTC

couchand wrote: post #190

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.

Ad hoc and structural polymorphism can coexist. You can define an object that contains a customerid and an invoiceid, and they won't get mixed.

Re: Things I Was Wrong About: Types

#290

Post by lolinder » Sun, Sep 27, 2020, 6:41 PM UTC

marktangotango wrote: post #283

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…

I agree with this 1000%. Projects (note not programs or individual source files!) are simply easier to grok (maintain, enhance, debug, refactor) with statically (and strongly) typed languages than dynamic IMO. Five years ago when switching jobs I’d pursue “full stack” positions because I’d done a fair amount of front end dev in the past. No more, me personally, I’m backend all the way. Dynamic typing (vanilla js) is…

It's not perfect, but TypeScript goes a long way toward making frontend feel as safe as backend. You still have the potential for weird bugs when interacting with external JavaScript, but your internal code is pretty safe. Also, TypeScript's type system is impressively flexible, and I often find myself missing features (like unions) when working with other languages.