4 ms·

I am starting to ignore syntax when I read code now. It doesn't register in my mind most of the time unless I see a sudden paradigm shift or odd dependency beha

I am starting to ignore syntax when I read code now. It doesn't register in my mind most of the time unless I see a sudden paradigm shift or odd dependency behaviour(I think this causes me to snap more than language syntax. Dependencies don't have clear code navigation guidelines, proper structure or docs than the language they are in). From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. If there are more js developers, then that means you can hire more for less overall. Obviously things are more complicated. If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Anything trendy will get too many breaking changes or fixes. Heck, having visible source code can be liability too in future. I may as well choose something that will be hard to decompile. Not to mention the external dependencies that you will need to mirror or even maintain. I think most businesses that are dependent on tech can be divided into short lived and very long lived ignoring certain type of software and industries. For short lived businesses or customers, your stack shouldn't matter much compared to the responsiveness of development. What incentive are there to provide quality software to companies that will live 5 years at best? (Note - quality here refers to ideal stack/code that programmers expect. Eg - unnecessarily performant, kubernetified, micro architecture) None. For long term businesses, software is an ongoing cost. They can afford to renew their software every 10 years so why should you write something that is expandable, easy to migrate and another team to take over. Beside, their requirements change drastically over time. It will end up being a monolith. I don't have to work right now but if I ever do, I am gonna work on the interesting bits while hiring someone in a third world country to outsource parts that I don't from my job. I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language.

dlkf 7y ago
I like your post a lot. I don't disagree with anything in it per se, but I think there are a couple qualifications worth making. > From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. > If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Roughly speaking I agree. However, two comments: 1. This is a very broad critique. You can say exactly the same thing about python, bash, perl, etc. It applies to Ruby, but it's not endemic to Ruby. 2. Not everyone is looking at the same time scale. If you are building software for an enterprise that's been around for a few decades, I can totally see the argument for eg Java. But in many cases, the landscape 10 years from now is the wrong thing to optimize for. For some, building a software product that actually lives long enough to have dependency issues is an amazing problem to have. > I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language. I could have been more explicit in my original post. What I'm lauding about Ruby is more than pretty syntax. I'm arguing that the the whole language dovetails really well with the application framework, both in terms of routing and in terms of db operations. Particularly the latter. There was a recent thread here that was something like "What should I learn in 2020?" and hands-down the winner was "Learn how to use a DB." I think that Rails is a powerful way to approach this.
- thrwaway69 7y ago
  Yeah, my original comment is disorganised. Essentially, I meant to distinguish between two business sides (there are others) rather than making point for any language or situation. The compiled language part was an example to long standing businesses where you are aware of many details like software sweeping cycles, culture, goals, requirement changing tendencies, etc. > That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. Yes, see this puts you into short standing business bucket. > Syntax doesn't provide enough value on its own in a general programming language. I actually didn't mean this literally. I think of tools as a means to move around and give shape to a product, team, business or yourself. Syntax can be relevant to that while relying on syntax in seldom is a bad idea. Examples: People who like ruby syntax and are attracted to it is a different bunch than those who are attracted to java. While you may prefer to use java, you don't necessarily want programmers attracted to java in your team. Using statically typed language may provide more friction to think about the structure or slow you down a bit which may be important for shaping the product. In short, you don't want tools to decide your fate. Sometimes, using less than the 'best' is a better choice.
- DarkWiiPlayer 7y ago
  > I think that Rails is a powerful way to approach this. I strongly disagree with that thought. AR is the best tool to get around properly learning SQL. That's both its greatest strength and it's most fatal weakness. IMO it's still worthwile learning AR after learning and understanding SQL, but the other way around will just be a headache.
microcolonel 7y ago
> From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. I honestly think there's a sweet spot. I have seen brilliant people expertly build massive systems in Java, but there is no doubt in my mind that if they had attempted those in almost any other popular high level language, they would have been more productive. I know I've been very productive in Clojure, for things that I can afford to write in it (performance-wise), and much more productive than I have been in languages I have a lot more experience with.
- thrwaway69 7y ago
  Definitely. Your comment proves my point though. You don't need experienced 'java' programmers but simply experienced programmers.
  - skohan 7y ago
    The more time I spend in the industry, the more I tend to believe you should just hire programmers who have a demonstrated ability to produce a high-quality product. Any product. Programming languages and domain-specific knowledge can be learned quickly, and all the best practices and process controls in the world can't replace talent and experience solving problems.
    - microcolonel 7y ago
      Those things can sometimes be learned quickly, but it takes time. If your company can't have, or doesn't want, productive developers to be spending a lot of time mentoring, then it can be worth it to hire people trained in your working language, possibly even familiar with your style of program or library ecosystem (if you have one of those).

dlkf 7y ago

I like your post a lot. I don't disagree with anything in it per se, but I think there are a couple qualifications worth making. > From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. > If I want to write software that is going to be used for a long time, then I am going for strongly typed compiled language that will have certain percentage of developers 10 years later than focusing on how beautiful the language is syntactically or how it reasons well. Binaries are easy to distribute and can still be used after source code is no longer available for odd reasons. Roughly speaking I agree. However, two comments: 1. This is a very broad critique. You can say exactly the same thing about python, bash, perl, etc. It applies to Ruby, but it's not endemic to Ruby. 2. Not everyone is looking at the same time scale. If you are building software for an enterprise that's been around for a few decades, I can totally see the argument for eg Java. But in many cases, the landscape 10 years from now is the wrong thing to optimize for. For some, building a software product that actually lives long enough to have dependency issues is an amazing problem to have. > I want to solve problems and reach goals. Syntax doesn't provide enough value on its own in a general programming language. I could have been more explicit in my original post. What I'm lauding about Ruby is more than pretty syntax. I'm arguing that the the whole language dovetails really well with the application framework, both in terms of routing and in terms of db operations. Particularly the latter. There was a recent thread here that was something like "What should I learn in 2020?" and hands-down the winner was "Learn how to use a DB." I think that Rails is a powerful way to approach this.

thrwaway69 7y ago
Yeah, my original comment is disorganised. Essentially, I meant to distinguish between two business sides (there are others) rather than making point for any language or situation. The compiled language part was an example to long standing businesses where you are aware of many details like software sweeping cycles, culture, goals, requirement changing tendencies, etc. > That's fair. But exactly how much you ought to worry about the hiring landscape depends on your situation. At the beginning of a lot of software projects, there is "you" and "your laptop" and "no money." In these cases you should pick the tool that is going to help you get off the ground fastest. You can worry about the hiring landscape if/when you're lucky enough to get there. Yes, see this puts you into short standing business bucket. > Syntax doesn't provide enough value on its own in a general programming language. I actually didn't mean this literally. I think of tools as a means to move around and give shape to a product, team, business or yourself. Syntax can be relevant to that while relying on syntax in seldom is a bad idea. Examples: People who like ruby syntax and are attracted to it is a different bunch than those who are attracted to java. While you may prefer to use java, you don't necessarily want programmers attracted to java in your team. Using statically typed language may provide more friction to think about the structure or slow you down a bit which may be important for shaping the product. In short, you don't want tools to decide your fate. Sometimes, using less than the 'best' is a better choice.
DarkWiiPlayer 7y ago
> I think that Rails is a powerful way to approach this. I strongly disagree with that thought. AR is the best tool to get around properly learning SQL. That's both its greatest strength and it's most fatal weakness. IMO it's still worthwile learning AR after learning and understanding SQL, but the other way around will just be a headache.

microcolonel 7y ago

> From my perspective, choice of language matters very less compared to the number of experienced programmers you can get at x price. I honestly think there's a sweet spot. I have seen brilliant people expertly build massive systems in Java, but there is no doubt in my mind that if they had attempted those in almost any other popular high level language, they would have been more productive. I know I've been very productive in Clojure, for things that I can afford to write in it (performance-wise), and much more productive than I have been in languages I have a lot more experience with.

thrwaway69 7y ago
Definitely. Your comment proves my point though. You don't need experienced 'java' programmers but simply experienced programmers.
- skohan 7y ago
  The more time I spend in the industry, the more I tend to believe you should just hire programmers who have a demonstrated ability to produce a high-quality product. Any product. Programming languages and domain-specific knowledge can be learned quickly, and all the best practices and process controls in the world can't replace talent and experience solving problems.
  - microcolonel 7y ago
    Those things can sometimes be learned quickly, but it takes time. If your company can't have, or doesn't want, productive developers to be spending a lot of time mentoring, then it can be worth it to hire people trained in your working language, possibly even familiar with your style of program or library ecosystem (if you have one of those).