4 ms·

Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...) Types keep things

Compile time types are nice to have, if they stay out of my way (type inference, the ability to easily opt out for certain "tricky" code...) Types keep things (except for database column names or JSON import...) from blowing up the very first time you try to run it, rather than stopping the compile. That's useful, as far as it goes. (as long as it saves me more time not fixing a typo and rerunning than it does generating stupid cluttered code) We have bigger problems (not that JS really addresses them, either). Mutable data, cyclic update graphs and temporal coupling. (at least JS makes it easier to do FP type programming and to freeze objects to force immutability if you need to). This is a paradigm change we probably won't see until after most of us raised in the C/Algol era are dead, sadly. Pet peeve: infix operators, and precedence rules. I have seen this bite badly in subtle ways, but it's a sacred cow of computing that you MUST have algebraic expressions. Lisp had it right - parens first, now you are trained. Now that we have effective garbage collection, can we please STOP writing (thinking) in Algol/Simula 67 dressed up with curly braces??? (which really isn't that much higher level than COBOL/CICS, especially when you look at most Java dreck)

tscs37 10y ago
I mostly agree, types are nice but they should not clutter code like in C++ or C. If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go. For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out. Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out. Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented. Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.
mahyarm 10y ago
Type inference is horrible. Mostly because as soon as your project gets large, type inference eats inordinate amounts of time during compiling and indexing and developer experience degrades. Combine that with operator overloading and generics and it gets even worse. Right now I'm suffering through it with swift with a +100k LOC project. The obj-c equivalent compiles and indexes 5-10x faster. If you can make type inference scale, then I would be all for it. If I'm restricted to a small LoC count, might as well use a dynamic language. Static typing is a scalable tool. It lets me avoid an entire category of bugs and unit tests. It make refactors easier as I just have to change my thing and then fix all of the obvious compile errors once. It helps me define parts of API contracts in code vs documentation and unit testing. And when a project gets large, the automated nature of static typing helps a lot!
- Roboprog 10y ago
  Operator overloading is doubly evil :-) FWIW, I mentioned that I think even the built it infix operators are a bad idea, rather than functions, such as variadic add(...), multiply(...), or(...), and(...). (subtract() and divide() really should only have 2 arguments, and not() just one)

tscs37 10y ago

I mostly agree, types are nice but they should not clutter code like in C++ or C. If the compiler can safely infer a type, it should do it, that's a no-brainer, modern compilers are very capable of doing just that. This is why I like languages like Rust or Go. For FP to some extend, I imagine Rust would be nice since mutability is opt-in rather than opt-out. Cyclic Graphs are always complicated, they're hard, some languages just do the hard part easier while others just gnaw their teeth out. Also agreed on LISP, LISP is probably the only good language ever, it becomes what you need it to be, if you want it's purely functional and in the next line it's object oriented. Modern Compilers will probably coerce languages into a superposition of types, tho there will still be two sides to it, some people will always prefer explicit (as in: type is forced and checked) typing and some will prefer implicit (as in: type is fluid) typing.

mahyarm 10y ago

Type inference is horrible. Mostly because as soon as your project gets large, type inference eats inordinate amounts of time during compiling and indexing and developer experience degrades. Combine that with operator overloading and generics and it gets even worse. Right now I'm suffering through it with swift with a +100k LOC project. The obj-c equivalent compiles and indexes 5-10x faster. If you can make type inference scale, then I would be all for it. If I'm restricted to a small LoC count, might as well use a dynamic language. Static typing is a scalable tool. It lets me avoid an entire category of bugs and unit tests. It make refactors easier as I just have to change my thing and then fix all of the obvious compile errors once. It helps me define parts of API contracts in code vs documentation and unit testing. And when a project gets large, the automated nature of static typing helps a lot!

Roboprog 10y ago
Operator overloading is doubly evil :-) FWIW, I mentioned that I think even the built it infix operators are a bad idea, rather than functions, such as variadic add(...), multiply(...), or(...), and(...). (subtract() and divide() really should only have 2 arguments, and not() just one)