Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> Just get the machine to do it.

Exactly. Many people already use IDEs, or programs which provide auto-completion or hinting of the types a function accepts when writing out a function name - the type does not need to be explicitly written for the machine to identify the type of the function.



sort by: page size:

With good IDE support, writing types isn’t that much of a burden. Either write a function call first and use "assign return value to new variable", or use autocompletion where you only type the initials of a multi-word type name. Plus IDE refactoring actions when a parameter or return type needs to be changed.

To me, if you feel compelled to start putting type information in the variable names, function names, etc., what you're showing is that you really want a type system.

> That's easy.

For code that is not yours, or code that you open a year later, I think it's easier to specify the type. Exactly as when you see something like "var x = some_function();" and you need to know the type.


If you don't have types you still might not know what to pass in. I mean if it says function( id, filePath, newStudent) is id a number or a string. Or say filePath perhaps you have a defined class for that instead of passing in a string. Sure you could write it as function( idNumber, filePathString, newStudentClass) but you're just reimplemting types as a naming scheme that isn't able to be checked compile time.

A seriously important point you make.

The little bit of time it takes to annotate the type that the function returns will save a lot of time when other people take over the codebase.

Humans are not great compilers and spending time try to figure out what the hell is returned from a function


Exactly. The parent post claimed:

> Once you are able to comfortably read type signatures, it is trivial to see what a function is supposed to do

Typing gives minimal insight into what a function actually "does".

The solution is intention revealing naming, available in all languages.


Why? The compiler knows what the type is, the ide can tell you the type if you need to know - it’s redundant for you to have to type it out.

> With a good editor, this documentation is right at your fingertips. When you type a function's name, a call-tip will remind you of the expected arguments. If you've added type annotations, the types will be there, too.

Without type annotations, the types will be there too for a language with type inference. The editor just has to ask the language implementation "hey, what is the type for this function?" and show the result back to the programmer.


> Indeed. Type signatures mean that the code is naturally self-documenting.

Really? Knowing that a function takes two ints and returns a function is documentation?

And to think that I spend my time worrying about what a function does.


Fortunately, your IDE can use inference to add a type signature with a keystroke.

This is contrary to my experience. For instance if the types of function parameters aren't specified, the IDE won't have any way of knowing what the types of those parameters are and will therefore not be helpful with completions.

It depends on the situation. Using the 'auto' keyword makes things more generic. It can also save long type names from making expressions difficult to read. An IDE that can follow the auto to its actual type is also helpful.

If a type name is small then being explicit about the type name can be much more clear since it can save someone having to hunt down what type each function might return.


> Being able to search for functions/libraries by type signatures is very, very useful.

I can't remember the last time that I wanted to find a function that took two ints and returned a function.

I can remember the last time I wanted a function that did a particular operation.


I like explicit types on functions too.

However, it might be what I’m used to.

Do you think this would be less of a problem with editor/IDE support? Using colors, or other visuals, to infer and show the types while editing might overcome this desire.


One of the nice things about explicit types is that you can make sense of the code even when the person who wrote it wasn't the best at variable naming. I tend to distrust relying on convention.

That said, presumably one solution for such an issue is that have IDEs that can easily tell you what the type of an auto variable is.


Well, you could put the types on these days.

But also, there’s nothing stopping the code from being much clearer about its intention than this weirdly contrived example (I have a lot of code and most the function names are pretty unique). And surely you want to search for ‘foo(‘ to find invocations.


Does does my IDE know what functions should be called without types?

I mean it can be gradual. There already are ways of compiling functions which require type annotations, just make those less of a pain in the ass.

Agreed, better to use an IDE to insert the full type of a variable automatically so the code is readable in any environment afterwards.

Inferred types feels like an invention for people who don’t like IDEs, that somehow forces everyone _else_ to use an IDE.

next

Legal | privacy