3 ms·
I use dynamically typed languages maybe 90% of the time, and completely agree. But here's the thing: for most projects - including ones in production - it does
by m0th87 13y ago
I use dynamically typed languages maybe 90%
of the time, and completely agree. But here's the thing: for most projects - including ones in production - it doesn't matter because the app won't be large enough to not completely fit in a mental model.
If the app starts getting too large, then by all means rewrite it in a statically typed language. If you're getting to that point, a rewrite is probably warranted anyways; regardless of the language you choose, first versions are usually awkwardly structured and difficult to maintain anyways since features evolve faster than architecture.
- shangaslammi 13y agoI would also argue that you can get the benefits of a static type system with hardly any cost. Usually when people talk about dynamic vs static typing they imagine something like Ruby or Python vs Java, but there's no reason why you can't have a high-level, expressive language with static types. All you need is a sophisticated type-system and smart type-inference that works everywhere (not just locally) and you'll be able to be just as productive as with today's popular dynamic languages but get all the benefits of static verification.
- gnuvince 13y agoOCaml, F#, Haskell all come to mind. Regarding total type inference, I am not sure though that any of those can do completely away without some manual type annotations. I still like to declare type annotations (especially in Haskell, the syntax in ML is a bit too ugly) for top-level functions.
- gizmo686 13y agoI can only speak about Haskell here, but how often do you need to provide a type annotation. I have never been in a situation (outside of the interactive prompt) where the compiler failed to infer the type. I do provide many type annotations for the sake of readability, but as far as I am aware the only effect these actually have on the code is providing additional restrictions on where a function can be used (that is to say, intentionally making the type signature less generic than it could be).
- ibotty 13y agostandard ml (and thus haskell) has total type inference. the problem in haskell at least are extensions which ruin some inference.
- api 13y agohttp://stackoverflow.com/questions/3323549/is-a-statically-typed-full-lisp-variant-possible http://stackoverflow.com/questions/3323549/is-a-statically-t...
- api 13y agoI'd add: one way of dealing with this is to have lots of loosely coupled small systems. Easier said than done and sometimes not an option, but it's a strategy that can work with web app types stuff. The buzzword here's probably SOA.