9 ms·

Care to share more details of these companies including how the Ruby ones become profitable after a month with 4 guys on payroll? No offense but I've got to che

Care to share more details of these companies including how the Ruby ones become profitable after a month with 4 guys on payroll? No offense but I've got to check the facts these days.. :). Also, don't forget Fred Brooks article about the Second System. I betcha smart engineers on tight budget can hack in Java just as quick as those 4 guys and achieve the same result. My apology, Java today is as productive as Ruby on Rails. The difference between rewriting a Rails site to Java and an already written system un Java to a more modern architecture is huge. One can slowly move from old Java architecture to the newer one but it'll be trickier from Rails to something else... don't forget the accumulated Ops experience managing jvm based app server, the devil in details for those experienced engineers who have been there and done that...

lmm 12y ago
> Care to share more details of these companies including how the Ruby ones become profitable after a month with 4 guys on payroll? No offense but I've got to check the facts these days.. :). It was small industry, those were basically the only two companies in it, I don't feel I can. (I've already changed some small details e.g. it wasn't actually Ruby). In any case it's just one person's anecdote - but I bet it's happened a lot. > My apology, Java today is as productive as Ruby on Rails. Citation needed. In the programming language shootout Ruby still comes out much shorter than Java, and like I said, the only proven risk factor for bugs is number of lines of code. > One can slowly move from old Java architecture to the newer one but it'll be trickier from Rails to something else... When I worked at last.fm this was literally my entire job (well, from PHP). You're rearchitecting anyway, creating stable interfaces and putting load balancers in there because those are also things you need to do as you're scaling up. Changing languages is no harder. > don't forget the accumulated Ops experience managing jvm based app server, the devil in details for those experienced engineers who have been there and done that... You can hire the experience - Java is literally the easiest language to hire for (I mean, hiring is still hard, and there are a lot of crap java programmers around, but there is a bigger pool of experienced programmers out there than any other language). And you're going to need to hire anyway; your ops team will have to grow, your engineering team will have to grow more, and you absolutely cannot rely on the engineers who bought the first version still being around when the time comes to rewrite; the half-life of an engineer in a startup is not large. Twitter was the article's choice of example, not mine - and from a business point of view Rails worked really well there.
- unclebucknasty 12y ago
  >the only proven risk factor for bugs is number of lines of code. I'm sure you can cite that, but it feels wrong in this context. That is, given the same language, or equally verbose languages, it may be true and applicable. But, if comparing a more verbose language to one that is less so, then the former will naturally yield a higher LOC count. But, does this mean it's more bug prone? There aren't any more logical constructs, flow control mechanisms, etc. The language simply requires more lines to express the same intentionality. In fact, I wonder how a more verbose language would compare with a less verbose one if we normalized for some verbosity factor. So, let's say language A is twice as verbose as language B, such that when the LOC count of A is twice that of B, we consider them equal (call it the same "Effective LOC"). I actually wonder if, in this case, language B would have a higher bug count per effective LOC, owed to its terseness and/or reduced readability.
  - unclebucknasty 12y ago
    Downvotes (especially without comments) as an expression of disagreement are just plain silly. Are we eight-year olds?
    - fsloth 12y ago
      This behaviour - downvoting without explanation irritates me too when there is very lucid and concisely structured argument you can oppose. As such, I do not find your argument for verbosity normalizing convincing :) I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. For numerical algorithms, where a multiplication is just as verbose in any language then there is no difference. But when manipulating collections, for example in C I need to write int i; for(i = 0; i < someSize; i++){...} This has several places where the verbosity of language can make it easier to write bugs that slow down the progress a bit. If we add these tiny slowdowns throughout the lifecycle of the entire application the cost is not neglible if compared to a situation where these bugs would not appear at all. Some other language: for i in collection do:... Which does really have no place to shoot oneself in the foot unless the iteration logic itself does something funny.

lmm 12y ago

> Care to share more details of these companies including how the Ruby ones become profitable after a month with 4 guys on payroll? No offense but I've got to check the facts these days.. :). It was small industry, those were basically the only two companies in it, I don't feel I can. (I've already changed some small details e.g. it wasn't actually Ruby). In any case it's just one person's anecdote - but I bet it's happened a lot. > My apology, Java today is as productive as Ruby on Rails. Citation needed. In the programming language shootout Ruby still comes out much shorter than Java, and like I said, the only proven risk factor for bugs is number of lines of code. > One can slowly move from old Java architecture to the newer one but it'll be trickier from Rails to something else... When I worked at last.fm this was literally my entire job (well, from PHP). You're rearchitecting anyway, creating stable interfaces and putting load balancers in there because those are also things you need to do as you're scaling up. Changing languages is no harder. > don't forget the accumulated Ops experience managing jvm based app server, the devil in details for those experienced engineers who have been there and done that... You can hire the experience - Java is literally the easiest language to hire for (I mean, hiring is still hard, and there are a lot of crap java programmers around, but there is a bigger pool of experienced programmers out there than any other language). And you're going to need to hire anyway; your ops team will have to grow, your engineering team will have to grow more, and you absolutely cannot rely on the engineers who bought the first version still being around when the time comes to rewrite; the half-life of an engineer in a startup is not large. Twitter was the article's choice of example, not mine - and from a business point of view Rails worked really well there.

unclebucknasty 12y ago
>the only proven risk factor for bugs is number of lines of code. I'm sure you can cite that, but it feels wrong in this context. That is, given the same language, or equally verbose languages, it may be true and applicable. But, if comparing a more verbose language to one that is less so, then the former will naturally yield a higher LOC count. But, does this mean it's more bug prone? There aren't any more logical constructs, flow control mechanisms, etc. The language simply requires more lines to express the same intentionality. In fact, I wonder how a more verbose language would compare with a less verbose one if we normalized for some verbosity factor. So, let's say language A is twice as verbose as language B, such that when the LOC count of A is twice that of B, we consider them equal (call it the same "Effective LOC"). I actually wonder if, in this case, language B would have a higher bug count per effective LOC, owed to its terseness and/or reduced readability.
- unclebucknasty 12y ago
  Downvotes (especially without comments) as an expression of disagreement are just plain silly. Are we eight-year olds?
  - fsloth 12y ago
    This behaviour - downvoting without explanation irritates me too when there is very lucid and concisely structured argument you can oppose. As such, I do not find your argument for verbosity normalizing convincing :) I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. For numerical algorithms, where a multiplication is just as verbose in any language then there is no difference. But when manipulating collections, for example in C I need to write int i; for(i = 0; i < someSize; i++){...} This has several places where the verbosity of language can make it easier to write bugs that slow down the progress a bit. If we add these tiny slowdowns throughout the lifecycle of the entire application the cost is not neglible if compared to a situation where these bugs would not appear at all. Some other language: for i in collection do:... Which does really have no place to shoot oneself in the foot unless the iteration logic itself does something funny.