[erlang-questions] Erlang is the best choice for building commercial application servers

[Michael Turner]

"In CS, the aim is to contribute to knowledge.  If you have failed to
communicate clearly, you haven't (yet) done your job as a computer
scientist.  IT, however, has short horizons."

To complete Richard's thought:

"... If you have failed to communicate clearly, your IT job is that much safer."

Up to a point, anyway. ;-)

-michael turner

On Wed, Mar 14, 2012 at 11:26 AM, Richard O'Keefe <ok@REDACTED> wrote:
>
> On 14/03/2012, at 1:23 PM, Shahrdad Shadab wrote:
>> Joe pointed to a very important fact, Java/J2ee is industry (so is c# and .net) but Erlnag is a language.
>>   Each time I have to look at a WSDL or XML schema to fix a production bug in a J2ee application is I ask why Erlang shouldn't be industry? Just compare the simplicity and in particular the beauty of distributed Erlang with awkwardness of webservice / JMS communications. Quite frankly folks, they are really ugly! So are their .net siblings. This is not because I love Erlang, I just follow the same sense of beauty that guided mathematicians and theoretical physicists for years when they come up with innovative ideas. As Hardy used to say "There is no place for ugly mathematics". Why IT is missing (or ignoring) such a sense? I don't think what we do is more abstract than pure math (Manifold theory for instance). Maybe because IT is too young but still we need to start sometime from somewhere.
>
>
> http://c2.com/gci/wiki?BeautyIsOurBusiness
>
>        BeautyIsOurBusiness is for me an empirical observation,
>        not a philosophical position.
>        When a junior programmer tells me that it's ugly but it works,
>        it is very tempting to reply simply: "No it doesn't."
>        --AndersMunch
>
> See http://www.amazon.com/Beauty-Our-Business-Birthday-Monographs/dp/0387972994
>
> There is a big difference here between CS and IT.  IT is about business, first, last,
> and all the time.  In CS, the aim is to contribute to knowledge.  If you have failed
> to communicate clearly, you haven't (yet) done your job as a computer scientist.  IT,
> however, has short horizons.  Pushing complexity from development to maintenance
> always seems like a good idea when you are doing development.  (Of course, when you
> are doing maintenance, you have another opinion.)
>
> I was about to say what my favourite bug is at the moment, then realised I was
> wrong.  My favourite bug *symptom* concerns the T-stick we got yesterday from
> Telecom New Zealand, an HSUPA USB Stick Model MF 190, made by ZTE Corporation.
> It's supposed to work with both Mac OS and Windows.  Plug it into the side of a
> MacBook Pro [bug 1: it is too wide, so I _can't_ have my 1.5TB Time Machine
> drive _and_ the 3G modem plugged in at the same time], the Telecom Connection
> Manager application starts automatically, click on the "Connect" button in the
> "Internet" panel, and it crashes.  Every single time.  Completely reliable failure.
> How does an Internet connection kit that crashes every time you try to connect
> to the internet *ever* get through any serious testing?
>
> So my *second* favourite bug is in Mono, specifically in
> System.IO.StringReader.ReadLine().
> The default method in System.IO.TextReader.ReadLine() is fine,
> but in order to go faster, this one basically does
>        - use low level code to look for the end of the line
>        - grab out a substring
> The problem is that thanks to Windows copying DOS which copied CP/M
> which copied (DEC?), lines might be terminated by CR+LF; thanks to
> Unix (which followed the original ASCII-63 suggestion that LF could
> be a line terminator all by itself), lines might be terminated by LF;
> and thanks to classic MacOS, lines might be terminated by CR.
> So the code goes
>        - find the next CR, if any.
>        - find the next LF, if any.
>        - which is earlier?
>        ...
> The result is that if you have a string of length b containing LF terminators
> only, you search the whole string for a CR.  So if the next line is n characters,
> it costs O(b) time to find it, not O(n).  And that means that reading lines is
> O(b^2) instead of O(b).  All because someone decided to be clever.
> "It looks ugly, but it works."  "Yes, but the performance is ugly too."
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions