4 ms·

"Applications written in higher-level, dynamic languages (like Python and Ruby) are always going to be more ‘intelligent’ than those written in low-level, stati

"Applications written in higher-level, dynamic languages (like Python and Ruby) are always going to be more ‘intelligent’ than those written in low-level, static languages (like C and Java)." He positions this as a given, and moves on with his only justification being that websites feel "smoother to use" when written with Django or Rails. "One has nearly 10 times as many files, and 10 times as many lines of code as the other. Can you guess which one?" In addition to being snarky, I think the lines of code written as a metric for software quality is as about as useful as selling software with "smoother to use" printed on the box.

zacharyvoase 17y ago
Actually, the justification is given later on: tools like these, which do a lot of the commonly-repeated work for you, make it easier for you to focus on the purpose of your application as opposed to overcoming the limitations of the tool itself.
- evdawg 17y ago
  Zack, I'm directing this straight at you since I see you're the author of this post. Honestly, posts like this are just detrimental to both communities. They're immature and show a complete lack of understanding of software development. Choosing the right tool for the job is rarely easy as "high level" and "low level". Git was created to solve a specific need: Distributed development of the Linux kernel. The fact that it's been adopted by so many developers outside of the Kernel community shows that it is at minimum an adequate tool for the job. I'd go ahead and say, for those developers, Git > Mercurial. That's why they choose it. For the developers who choose Mercurial, Mercurial > Git. That's why they've chosen Mercurial. Please, before you publish stuff like this, remember that we're all on the same team. Next time, advocate Mercurial by talking about how it's improved your workflow. Talk about why Mercurial is better than Git for you, perhaps talk about the technical differences of the underlying implementations on a conceptual level. That way, maybe you could help someone make an informed choice about what to use, instead of basing their decision on something as silly as the language it's written in.
  - silentbicycle 17y ago
    Contributing patches is an option, too. There's a shortage of people in the open source world who are good at UI design.
- johnbender 17y ago
  Even this comment is a higher level of detail than that which was provided in the article. In the end I think what you're saying is relatively intuitive but the internet needs less arguments based on value judgments, and more discussion centered on things we can point to, at the very least, as generally agreed upon facts.
evgen 17y ago
Lines of code is not an absolute metric for quality but it is a good rule of thumb (unless raw speed us the characteristic you are optimizing for.) Less code means the program or routine will be easier to read and understand and have fewer places for bugs to hide. Of course, this means lines of code in the syntax and standard libraries of the language: a program that calls a third-party library should be viewed as one that counts the lines in this library as well.
- tspiteri 17y ago
  Well, git is written for speed.
mechanical_fish 17y ago
So, if Python and Ruby are "intelligent", and C and Java are "low-level", what are Perl and shell scripts? Because git's original user interface was, in fact, built out of shell scripts and Perl. Whatever. It's remarkable how the intelligence of the programmer never seems to enter into this guy's calculation of how "intelligent" an application is. [EDIT: Actually, having now dug through git's source repository and looked through git on my machine, it appears that the whole command-line UI is still written in Perl and shell. Thank god! For a minute there I thought that git wasn't "intelligent"! ;]

zacharyvoase 17y ago

Actually, the justification is given later on: tools like these, which do a lot of the commonly-repeated work for you, make it easier for you to focus on the purpose of your application as opposed to overcoming the limitations of the tool itself.

evdawg 17y ago
Zack, I'm directing this straight at you since I see you're the author of this post. Honestly, posts like this are just detrimental to both communities. They're immature and show a complete lack of understanding of software development. Choosing the right tool for the job is rarely easy as "high level" and "low level". Git was created to solve a specific need: Distributed development of the Linux kernel. The fact that it's been adopted by so many developers outside of the Kernel community shows that it is at minimum an adequate tool for the job. I'd go ahead and say, for those developers, Git > Mercurial. That's why they choose it. For the developers who choose Mercurial, Mercurial > Git. That's why they've chosen Mercurial. Please, before you publish stuff like this, remember that we're all on the same team. Next time, advocate Mercurial by talking about how it's improved your workflow. Talk about why Mercurial is better than Git for you, perhaps talk about the technical differences of the underlying implementations on a conceptual level. That way, maybe you could help someone make an informed choice about what to use, instead of basing their decision on something as silly as the language it's written in.
- silentbicycle 17y ago
  Contributing patches is an option, too. There's a shortage of people in the open source world who are good at UI design.
johnbender 17y ago
Even this comment is a higher level of detail than that which was provided in the article. In the end I think what you're saying is relatively intuitive but the internet needs less arguments based on value judgments, and more discussion centered on things we can point to, at the very least, as generally agreed upon facts.

evgen 17y ago

Lines of code is not an absolute metric for quality but it is a good rule of thumb (unless raw speed us the characteristic you are optimizing for.) Less code means the program or routine will be easier to read and understand and have fewer places for bugs to hide. Of course, this means lines of code in the syntax and standard libraries of the language: a program that calls a third-party library should be viewed as one that counts the lines in this library as well.

tspiteri 17y ago
Well, git is written for speed.

mechanical_fish 17y ago

So, if Python and Ruby are "intelligent", and C and Java are "low-level", what are Perl and shell scripts? Because git's original user interface was, in fact, built out of shell scripts and Perl. Whatever. It's remarkable how the intelligence of the programmer never seems to enter into this guy's calculation of how "intelligent" an application is. [EDIT: Actually, having now dug through git's source repository and looked through git on my machine, it appears that the whole command-line UI is still written in Perl and shell. Thank god! For a minute there I thought that git wasn't "intelligent"! ;]