3 ms·

What I think is cool is getting computers to do things that are interesting. Types don't do anything. I find them hard to get excited about.

the_af 12y ago
What do you mean "types don't do anything"? Are you seriously going to argue that? I don't know many people in the programming or CS fields who believe that. What some people believe is that there are type systems too onerous for the benefits they bring (which is, of course, debatable). Following your line of thought, one could say that the textual representation of your program "doesn't do anything" either, and neither does the syntax or the IDE/editor you use. So none of it matters. But of course it wouldn't be true -- all those things are useful tools that help you write software that does cool things. edit: thought of an even better example: tests. Tests "don't do anything". They are not directly related to the cool stuff we want to do with our computers. But who is going to argue that we shouldn't write any tests?
- Dylan16807 12y ago
  I find it hard to get excited about normal testing.
  - the_af 12y ago
    You'll notice I only addressed the faulty assertion that "types don't do anything". I've purposefully left the excitement part out, because that's subjective. Some people are excited about testing methodologies, some about programming languages, some about their IDEs, etc. What you can bet is that absolutely no-one is excited about mission-critical software failing because of a bug that could have been caught by testing... or type checking.
- mtdewcmu 12y ago
  I guess I wasn't clear. You could say that a line of code does something if it generates instructions for the cpu. `x = y` would generate at least one instruction (probably some kind of mov on an intel system), which would instruct the cpu to do something, e.g. change the value in a register. If you scanned through a program looking for syntactic forms that represent types as such, you could find clear examples of such syntax in most programs; some programs would have more and some less, probably determined to a large extent by programming language. It would be things like variable declarations, class declarations, etc. -- essentially declarative scaffolding, which wraps and adds meaning and context to code that does things; the type code itself, though, generates no cpu instructions, because its purpose isn't to represent action, it's orthogonal to action. You could argue that type code causes actions to be performed, such as when types need to be casted, which may trigger some kind of transformation on the underlying data. But, even though the type helps trigger action (the data transformation), the type is not that action. I don't know if what I've written will make sense or sound like empty nonsense... but the article itself makes the point that you will generally not find types in machine code; at most you can find indirect evidence that they were there. You may say, "what difference does that make? Why make the distinction?" Well, machine instructions are what make the computer do observable things. Any code you have to write that doesn't produce instructions needs to be justified somehow. There are lots of ways of justifying such extra code. But it's orthogonal to actually doing things -- pretty much by definition. Edit -- to respond more directly: >>What some people believe is that there are type systems too onerous for the benefits they bring (which is, of course, debatable). I think that's a real risk. People tend to get attached to ideas about programming languages in quasi-religious fashion; I think it's healthy to stay in touch with an objective cost/benefit perspective, though. The user doesn't see the code, he/she only sees the results. And the experience of the user is what you should focus on as a programmer -- right? >>Following your line of thought, one could say that the textual representation of your program "doesn't do anything" either, and neither does the syntax or the IDE/editor you use. So none of it matters. But of course it wouldn't be true -- all those things are useful tools that help you write software that does cool things. I'm not sure I follow the distinction you're making, between the textual representation of the code and -- what? Clearly the text has to be written before the computer will do anything -- so it must be important. >>edit: thought of an even better example: tests. Tests "don't do anything". They are not directly related to the cool stuff we want to do with our computers. But who is going to argue that we shouldn't write any tests? I said types don't do anything, and that they don't excite me. I didn't say we should get rid of all types. Tests don't do anything, either (at least, they don't do what the program should do). Tests also don't excite me. That doesn't mean that testing is pointless. Testing can be costly and tedious -- but you have to weigh that against the risk of bugs getting through.
  - Dewie 12y ago
    An alternative to static types are runtime assertions - check that the two arguments to an add function are integers before performing the operation. Then the type system (strong, dynamic typing) is definitely part of the code of the program, if that's what you want. > Well, machine instructions are what make the computer do observable things. The typechecker is a program, and if the typechecker fails, you will see output.
    - mtdewcmu 12y ago
      You definitely see lots of things like (string? x) even in Lisp. It shows that some types are unavoidable. (Though frequently the type information is just used as additional information.) Typecheckers definitely do things. But are those things interesting?
      - Dewie 12y ago
        > Typecheckers definitely do things. But are those things interesting? That seems like asking "seat belts definitely do things, but are those things interesting?"
        mtdewcmu 12y ago
        If you could show that seat belts save lives, which I think you can, then that's kind of interesting. In any case, I meant the question to be rhetorical.

the_af 12y ago

What do you mean "types don't do anything"? Are you seriously going to argue that? I don't know many people in the programming or CS fields who believe that. What some people believe is that there are type systems too onerous for the benefits they bring (which is, of course, debatable). Following your line of thought, one could say that the textual representation of your program "doesn't do anything" either, and neither does the syntax or the IDE/editor you use. So none of it matters. But of course it wouldn't be true -- all those things are useful tools that help you write software that does cool things. edit: thought of an even better example: tests. Tests "don't do anything". They are not directly related to the cool stuff we want to do with our computers. But who is going to argue that we shouldn't write any tests?

Dylan16807 12y ago
I find it hard to get excited about normal testing.
- the_af 12y ago
  You'll notice I only addressed the faulty assertion that "types don't do anything". I've purposefully left the excitement part out, because that's subjective. Some people are excited about testing methodologies, some about programming languages, some about their IDEs, etc. What you can bet is that absolutely no-one is excited about mission-critical software failing because of a bug that could have been caught by testing... or type checking.
mtdewcmu 12y ago
I guess I wasn't clear. You could say that a line of code does something if it generates instructions for the cpu. `x = y` would generate at least one instruction (probably some kind of mov on an intel system), which would instruct the cpu to do something, e.g. change the value in a register. If you scanned through a program looking for syntactic forms that represent types as such, you could find clear examples of such syntax in most programs; some programs would have more and some less, probably determined to a large extent by programming language. It would be things like variable declarations, class declarations, etc. -- essentially declarative scaffolding, which wraps and adds meaning and context to code that does things; the type code itself, though, generates no cpu instructions, because its purpose isn't to represent action, it's orthogonal to action. You could argue that type code causes actions to be performed, such as when types need to be casted, which may trigger some kind of transformation on the underlying data. But, even though the type helps trigger action (the data transformation), the type is not that action. I don't know if what I've written will make sense or sound like empty nonsense... but the article itself makes the point that you will generally not find types in machine code; at most you can find indirect evidence that they were there. You may say, "what difference does that make? Why make the distinction?" Well, machine instructions are what make the computer do observable things. Any code you have to write that doesn't produce instructions needs to be justified somehow. There are lots of ways of justifying such extra code. But it's orthogonal to actually doing things -- pretty much by definition. Edit -- to respond more directly: >>What some people believe is that there are type systems too onerous for the benefits they bring (which is, of course, debatable). I think that's a real risk. People tend to get attached to ideas about programming languages in quasi-religious fashion; I think it's healthy to stay in touch with an objective cost/benefit perspective, though. The user doesn't see the code, he/she only sees the results. And the experience of the user is what you should focus on as a programmer -- right? >>Following your line of thought, one could say that the textual representation of your program "doesn't do anything" either, and neither does the syntax or the IDE/editor you use. So none of it matters. But of course it wouldn't be true -- all those things are useful tools that help you write software that does cool things. I'm not sure I follow the distinction you're making, between the textual representation of the code and -- what? Clearly the text has to be written before the computer will do anything -- so it must be important. >>edit: thought of an even better example: tests. Tests "don't do anything". They are not directly related to the cool stuff we want to do with our computers. But who is going to argue that we shouldn't write any tests? I said types don't do anything, and that they don't excite me. I didn't say we should get rid of all types. Tests don't do anything, either (at least, they don't do what the program should do). Tests also don't excite me. That doesn't mean that testing is pointless. Testing can be costly and tedious -- but you have to weigh that against the risk of bugs getting through.
- Dewie 12y ago
  An alternative to static types are runtime assertions - check that the two arguments to an add function are integers before performing the operation. Then the type system (strong, dynamic typing) is definitely part of the code of the program, if that's what you want. > Well, machine instructions are what make the computer do observable things. The typechecker is a program, and if the typechecker fails, you will see output.
  - mtdewcmu 12y ago
    You definitely see lots of things like (string? x) even in Lisp. It shows that some types are unavoidable. (Though frequently the type information is just used as additional information.) Typecheckers definitely do things. But are those things interesting?
    - Dewie 12y ago
      > Typecheckers definitely do things. But are those things interesting? That seems like asking "seat belts definitely do things, but are those things interesting?"
      - mtdewcmu 12y ago
        If you could show that seat belts save lives, which I think you can, then that's kind of interesting. In any case, I meant the question to be rhetorical.