3 ms·

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

by 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.

by dlkf 7y ago

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.