4 ms·
After developing software for 20 years, hearing the argument of ‘X language is better than Y’ gets a bit boring. At the end of the day, you can write shit code
by dave_sid 8y ago
After developing software for 20 years, hearing the argument of ‘X language is better than Y’ gets a bit boring. At the end of the day, you can write shit code or good code in either language in the same way that you can build a shit house or a good house out of brick or stone.
No language will prevent a team of developers from building an un-maintainable mess no matter how good it is (and I have seen a few). Proper design skills and knowledge of ‘good’ software architecture will make or break a project every time. Stop getting hung up on languages.
Unless you’re being asked to develop in C (then I applaud you), then agree on a language that will still exist in 6 months time and then on with the difficult part...writing decent code.
- lllr_finger 8y agoTo play devil's advocate, a software craftsperson would ideally use the right tools for the job. You could fire up Groovy and Spring for a REST API that essentially takes JSON from a source/sources, transforms, and returns... but there are easier languages and frameworks and much more performant ones. The developers I've met with this argument have usually been doing one stack for many years and don't want to do anything new or uncomfortable. It's like watching someone try to cut brush with a butter knife.
- dave_sid 8y agoI agree with you that being comfortable with a stack is not a good reason to use it. Developers need to keep up with emerging languages. Team leads also need to be doing this and provide direction. But as I said, there is more to the success of a project that the language and I think people get hung up on this. Yes look at all the options, but agree on a language/stack and move on. Also, give just a tiny thought as to whether you will be able to hire any developers to support the thing in 3 years. Boring yes, but kind of useful.
- Scarbutt 8y agoAgreed, but do you think that a language that reduces lines of code considerably (lets say clojure vs java) is bike shedding or is part of using "good design" ?
- dave_sid 8y agoNo it's not bike shedding. The team should certainly choose the most appropriate language. Even if not all of them have experience in it. If they decide on clojure then go for it. But agree on something and move on. Also, saving lines of code isn't necessarily the end goal for me in a language choice to be honest. Get rid of boiler plate code yes, but what I'd like to aim for is code that is easy for the next developer to understand and support as quickly as possible, whether thats 10 lines or 20 lines.
- deleted 8y ago[deleted]
- dionidium 8y agoI've seen thoughtful, well-crafted ColdFusion and PL/SQL applications and I've seen Swift code that was incomprehensible and unmanageable. I've seen beautiful PHP and ridiculous Python. The amount that the language matters is way out of whack with how much we talk about how much it matters.
- hyperpallium 8y agoA language's ecosystem matters: libraries, afforable programmers etc. Reddit, which was inspired by PG, switched from lisp to python for reasons like this. ta;da intrinsics merits don't matter, only what's popular.
- w4tson 8y agoMaybe. But that’s also a race to the bottom. And it’s not like you need many developers to get stuff done. The right team and autonomy to choose their tools can be way more productive that a big team
- hyperpallium 8y ago> But that’s also a race to the bottom Only if you assume popularity is static. "Innovators", and then "early adopters" keep trying things to move it forward. Popularity is fickle and disloyal - i.e. dynamic.
- edem 8y agoI agree with most of this but each language is different and each language encourages different things. I think the most important thing to do as a software developer is to research the problem domain before writing a single line of code and pick the language which fits the project most. I happen to use Kotlin because out of the languages I have experience with this is the one I'm most comfortable with and the one which fits my problem domains best.