3 ms·

Upfront I want to be very clear that I'm not hating on any of the languages that he mentions in the article. okay, maybe secretly hoping that Ruby will go die

Upfront I want to be very clear that I'm not hating on any of the languages that he mentions in the article. okay, maybe secretly hoping that Ruby will go die in a fire somewhere, but let's put that aside. What grieves me as I read that article is that it seems like he had a perfectly good way of doing it simply and easily, but then decided to go for a much more complex and risky solution (with what _he_ describes as poor tooling) ... for what? Simply to increase the difficulty level? Take the analogy of a backyard pool. Instead of just running up to the pool and doing a bomb (or even a belly flop), he has to climb up on the roof of neighbours rickety garage, where he is going to attempt to do a triple twist half pike helicopter/superman maneuver in order to score higher from the judges. Problem is, he's got a real risk of either missing the pool entirely or cracking his head open on the concrete. I'm not saying we should never use new languages or techniques or tools. What annoys me is that given the choice of doing something simple, or doing something complex, he chose the complex way, and then piled on the risk, with a side order of complexity. From the article: "Shortly after working this out and drawing my architecture diagram (a pretty insane-looking tangle of boxes and arrows on a sheet of paper)" Shouldn't that have been a pretty big red flag? Sure he found some superstar programmer to pull it off for him, but I can't help but think that a little bit of darwinian natural selection would have been in order here. The annoying thing is that you see this all the time in the Enterprise. Time and time again someone with architect in their title goes and makes an appalling horrible mess of the design, leaving the poor bastards at the coal face to sort it out and try to make the abominable crime against nature, reason and common sense actually work.

fleitz 16y ago
If you're dealing with message passing architectures a language like Scala is a good way to go. Actors or Mailboxes in F# parlance fit perfectly with the way the architecture was described. His point about code fashion is also equally valid, what Seurat did with pointillism is impressive, printing a picture on on your inkjet is not, even though what Seurat did is essentially the same thing. Coming from an imperative background writing in a functional style has risk, coming from a functional background imperative style has risk. You can implement the lambda calculus on a UTM and implement a UTM in the lambda calculus, for all intents and purposes they are the same, however, in terms of elegance they are far different. (And there are arguments on both sides as to which is more elegant). I tend to agree with you particularly on 'enterprise architects' but the solutions are usually a reinvention of the wheel rather than marrying two disparate technologies that actually fit quite well together. Scala or another functional language is a great fit to a message bus architecture. Doing something for the difficulty of it usually doesn't attract a lot of smart minds, putting two things together that at first one wouldn't think of but that makes sense WILL pique the interest of a talented developer because he wants to see if it actually bears fruit.
- Stormbringer 16y ago
  I'm sorry, I think I don't understand the point you are trying to make. Are you really complaining that Java doesn't do messaging? Surely not, because that would be like saying that Lisp is okay, but it would be better with a heap more parenthesis. When you get down to it, pretty much any language with even a rudimentary ability to manipulate strings and connect to a socket can do messaging. But right from day one Java has had the capability of communicating with remote machines baked in. Oh wait, I just checked, I'm wrong. The Remote and Serializable interfaces date since Java 1.1, NOT since day 1. My bad. Of course 1.1 was released Feb 19, 1997 so RMI is almost exactly 14 years old at this point. So my conclusion is that if you've been living under a rock for exactly 14 years, you have an excuse when you say that Java can't do messaging. ---- Someone always comes along and says "what about $blindingly_obvious_thing and gets massive amounts of karma for doing so, so let me just say that yes, I am aware of... bugger it, I'll do it myself and reap the karma. Muahahahaha! ... ...dang, there's no reply to my own message option. (For obvious reasons) Oh well, we'll have to settle for option #2 which is that someone comes along and posts an objection which has nothing to do with any of the posts before it, and gets masses of karma for it. ---- Addendum: If you're implementing a messaging system in your handy dandy language with sockets and strings, and you want it to be robust, you will of course need to take into account this: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput... or a more in-depth look at them: http://www.rgoarchitects.com/Files/fallacies.pdf http://www.rgoarchitects.com/Files/fallacies.pdf cheerio, pip pip

fleitz 16y ago

If you're dealing with message passing architectures a language like Scala is a good way to go. Actors or Mailboxes in F# parlance fit perfectly with the way the architecture was described. His point about code fashion is also equally valid, what Seurat did with pointillism is impressive, printing a picture on on your inkjet is not, even though what Seurat did is essentially the same thing. Coming from an imperative background writing in a functional style has risk, coming from a functional background imperative style has risk. You can implement the lambda calculus on a UTM and implement a UTM in the lambda calculus, for all intents and purposes they are the same, however, in terms of elegance they are far different. (And there are arguments on both sides as to which is more elegant). I tend to agree with you particularly on 'enterprise architects' but the solutions are usually a reinvention of the wheel rather than marrying two disparate technologies that actually fit quite well together. Scala or another functional language is a great fit to a message bus architecture. Doing something for the difficulty of it usually doesn't attract a lot of smart minds, putting two things together that at first one wouldn't think of but that makes sense WILL pique the interest of a talented developer because he wants to see if it actually bears fruit.

Stormbringer 16y ago
I'm sorry, I think I don't understand the point you are trying to make. Are you really complaining that Java doesn't do messaging? Surely not, because that would be like saying that Lisp is okay, but it would be better with a heap more parenthesis. When you get down to it, pretty much any language with even a rudimentary ability to manipulate strings and connect to a socket can do messaging. But right from day one Java has had the capability of communicating with remote machines baked in. Oh wait, I just checked, I'm wrong. The Remote and Serializable interfaces date since Java 1.1, NOT since day 1. My bad. Of course 1.1 was released Feb 19, 1997 so RMI is almost exactly 14 years old at this point. So my conclusion is that if you've been living under a rock for exactly 14 years, you have an excuse when you say that Java can't do messaging. ---- Someone always comes along and says "what about $blindingly_obvious_thing and gets massive amounts of karma for doing so, so let me just say that yes, I am aware of... bugger it, I'll do it myself and reap the karma. Muahahahaha! ... ...dang, there's no reply to my own message option. (For obvious reasons) Oh well, we'll have to settle for option #2 which is that someone comes along and posts an objection which has nothing to do with any of the posts before it, and gets masses of karma for it. ---- Addendum: If you're implementing a messaging system in your handy dandy language with sockets and strings, and you want it to be robust, you will of course need to take into account this: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput... or a more in-depth look at them: http://www.rgoarchitects.com/Files/fallacies.pdf http://www.rgoarchitects.com/Files/fallacies.pdf cheerio, pip pip