...our jobs are to make stuff that works in a predictable, less risky way. Do that.
This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.
You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.
> These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.
All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees. Certainly not in every situation, but enough that it doesn't make sense to dismiss them out of hand.
> Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.
with strongly typed languages it's harder to perform exploratory coding. This drives a kind of backpressure on the design stage of development where it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking than in, say, Javascript. On the other hand, strongly typed languages provide a lot of guarantees that have to be coded for in dynamic languages. This is why I prefer gradual typing - you get the best of both worlds.
> with strongly typed languages [...] it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking
Quite the opposite. With strongly typed languages, it becomes safer to make changes, because the compiler will catch mistakes. On top of that, with mature strongly typed languages, there is tooling which takes advantage of the types to help you avoid mistakes in the first place.
It's safer to make changes, but you can't rapidly mess around with different structures without having to perform housekeeping on your types. This primarily applies to OO code, which is primarily where I draw my experience from - I find FP code is easier to refactor even with strong types because it doesn't enforce as rigid a structure.
I love the idea that typed languages create backpressure. I have very little confidence in peoples' ability to create well-designed (in software architecture terms) projects.
This is not true in general. There is nothing intrinsic to static types that is incompatible with exploratory coding. If you want to turn all your type errors into runtime crashes, then some statically typed languages will even let you do this (e.g. deferred type errors in Haskell).
Python is a strongly typed language and language dynamism has no relationship to strong typing. you're likely thinking of static typing. With Python's type annotation feature as well as the work being done with MyPy, Python is also beginning to grow some static typing behavior as well.
First of all, zzzeek, thanks for your great software. While working on SQLAlchemy, have you ever run into situations where you really missed static typing? Do you ever see yourself wanting to introduce Python's static typing behavior into that project, and why or why not?
I did nothing but Java from around 1998 to 2002 and then again around 2006-2008, and there is definitely a deep satisfaction when you have built your giant statically typed castle and compile it and then it runs the first time. In Java though, obviously the verbosity that implies, particularly when I was using it pre-generics, most certainly erased any productivity gains and made for code that was very difficult for new people to understand, tests were in particular extremely hard to write. So at least with Java's widely criticized model, it was sort of nice-ish but hard to say it was worth it.
What Python is doing with typing I think is going to be amazing though. Just not sure if I'll have time to embrace it fully within my own projects.
Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.
The benefit they offer is fewer checks so you can deploy things faster.
It's the same benefit you can get if you take your car to a mechanic who doesn't bother to check the wheels are attached properly after they've changed the brake discs.
But one can add checks after the design/features settle; it's not all or nothing. Using the mechanic analogy, if you are requesting a custom car, the mechanic can shape the look and feel first, and then verify everything once you made up your mind.
Most CRUD (such as tracking applications) is just marshaling attributes around and about, not really doing much math on them. Forced type checks can be repetitive busy work and hogs screen real-estate.
>> You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.
Shouldn't that last sentence be "... if switching would improve the end product or service you are delivering." The focus should be on what people are paying you for. Better code doesn't always mean a better product, or be a smart business decision.
The two are equivalent in most cases. There's a relatively small set of problems where the choice of programming languages will have an effect on the product that doesn't come down to the code being more understandable and more amenable to change.
Pretty much speed is the only concern for the vast majority of web applications, it isn't really that big a concern for most web applications, and even then it's less about choosing the fastest language and more about limiting yourself to a still pretty broad set of "faster" languages.
Speed of development, or runtime speed? Language won’t matter for runtime speed except in the .1% of high load apps. In my experience speed of development will vary quite a bit based on language and quality of frameworks. I went from C# shop to Ruby/Rails and the pace increased substantially, though cultural differences are intertwined with language choices.
Runtime speed, as an example of one of the few considerations when choosing a language that isn't related to code quality and maintainability.
I agree though that it's not relevant for nearly all web applications (and even for those where it is, it doesn't require that everything is done in a performant language)
Sure, but the choice of language is rarely a factor in this, barring very specialized subdomains where library support is limited to a few languages. There's very few web applications that couldn't have been written in virtually any modern language.
I think ideally they are the same, but doing a re-write isn't cost free - opportunity cost as you're not doing feature customers care about, new bugs being created, old bugs re-appearing etc etc.
This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.
You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write.