4 ms·
One thing I've only come to appreciate during my professional development is that there are huge differences in the kinds of software people write and what's go
by JunkDNA 13y ago
One thing I've only come to appreciate during my professional development is that there are huge differences in the kinds of software people write and what's good in one scenario isn't necessarily good in another. A lot of people around here fall into the trap (myself included) of thinking that web programming is the entire universe of programming. That's not so, and the difference matters greatly.
If you're going to write a physics simulation, you're really going to benefit from some language features over others. I would argue that you especially benefit from static types because you control a lot of your stack and type checking can make your code very robust. On the other hand, if you're going to write a webapp, think about what you're doing: essentially slinging text around and taking random inpust from users, casting all of it to actual types, and shoving it into a data store (casting it again sometimes). What is the type system providing you in that scenario? Everything is cast at runtime somewhere.
- gnuvince 13y ago> What is the type system providing you in that scenario? Though the data flowing in and out of a web application is usually in string form, that doesn't mean that it needs to be treated as such in your application. You'll convert the string to a richer, more specific datatype and the static type system will help you correctly manipulate the data. A nice blog post on the subject is [1] where the author explains how you can represent different kinds of strings (raw strings, SQL strings, etc.) using the type system. [1] http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html http://blog.moertel.com/posts/2006-10-18-a-type-based-soluti...
- JunkDNA 13y agoThanks for that post, I think the point I was making was slightly different. I'm arguing that with web programming you lack the end to end control you might have in a closed system. You depend on all sorts of input from users, your data is stored in a database or nosql store that is outside your program's (and compiler's) complete control. It can change underneath you at any time. The argument that static typing can help you know that your code is correct is weakened in this environment. Internally you of course construct your code in a way that uses types and can verify that you are internally consistent. However, I'm saying that at a fundamental level, in a data-driven web app, the system as a whole is only marginally improved by this because your whole universe starts out with a bunch of typecast operations as the gateway to your codebase. These always are happening at runtime and are one "ALTER TABLE" (to pick just one example) away from failing spectacularly in production. I'm not arguing one way or another that static typing is/is not good in this scenario. I'm just pointing out that the foundation of the system as a whole is not as solid as other programming scenarios where you have much more control.
- hannibal5 13y agoI have done fair amount of numeric programming and I have not seen any significant benefits from type checking. For me, only these increase robustness: 1. Ability to minimize the amount of code you write. Code you don't write is code without bugs. this means either writing problem specific libraries or having them in the system (Matlab creates more robust code than writing it all by yourself) 2. ability to minimize boilerplate. This is where dynamic languages often win. 3. Ability to change code easily and test or run frequently (not necessarily unit testing). Rewriting usually makes code more robust. Time and money always runs out. Always. The only constant law for selecting programming language for numeric programming is: IF YOU DON'T HAVE TO SPEND SIGNIFICANT TIME OPTIMIZING YOUR CODE AFTERWARDS, YOU ARE USING TOO LOW LEVEL LANGUAGE. If you don't have to optimize for speed, it means that you have been micro-optimizing your code everywhere without even noticing it. This is why C, C++ or Fortran should never be the main programming language you use. Use Python, Common Lisp, Matlab, Haskell, whatever and when you hit performance bottleneck, you write minimal amount of C or C++ code to get over it.