On 19/11/2011 06:30 AM, Darren New wrote:
> On 11/18/2011 1:43, Invisible wrote:
>> Well, yeah, and Haskell has defence contractors, investment bankers,
>> cryptographers and IC designers using it. AND NOBODY GIVES A DAMN. :-P
>
> Sure. But average people don't see that. It's easy to point to the phone
> system and say "See? Doesn't crash." :-)

Is it actually true that the /entire/ phone system is Erlang? I know 
Ericson use it, but is it really running *everything*?

>> And hence, I thought you might be interested to see how a couple of tools
>> approach [or ignore] the problem. I know I was...
>
> Indeed I was. Thanks for that.

NP.

>> On the plus side, this is Haskell. Sometimes the type signature is
>> enough to
>> actually tell you WHAT THE CODE DOES. That's a pretty amazing property,
>> which few other languages have.
>
> Actually, I think perhaps Hermes does even better, in some senses,
> because it has typestate. So you can say things like "This returns a
> record where either the array of results has more than one entry and the
> error code hasn't been assigned, or the error code has been assigned and
> the rest of the results have not." Maybe you can do that with the Maybe
> bit of Haskell or something, tho.

Well, it depends how far you want to go. There are people who have built 
things like a library that statically checks that your client and server 
speak an identical protocol, and there can never be a message mismatch. 
Trouble is, the type signatures became insane, and it gives the compiler 
a bit of a headache.

It's a question of degree, though. You already have the IO type, which 
means "this function might perform arbitrary input/output operations", 
the ST type which means "this function might use mutable state, but 
cannot communicate with the outside world or other running threads", and 
the STM type, which means "this function might use shared mutable 
variables, but cannot perform I/O". You can take this further, if you 
desire. Most people don't.

>> On the other hand, sometimes the type signature DOES NOT tell you what
>> the
>> code does. And then not having any *real* documentation utterly sucks.
>
> That's always the problem yes.

I should think that /any/ system is eventually going to come to a point 
where you need real documentation. There are those who say "the source 
*is* the documentation". But looking at Yesod, with almost 100 packages, 
I wouldn't want to have to read all that lot to try to /guess/ what the 
designer's intensions were. :-P

>> Also, Haskellers have this bizarre perversion where some people think
>> that
>> describing the axioms that a structure satisfies as the same thing as
>> explaining WHAT IT DOES, WHY THAT'S USEFUL or HOW YOU USE IT. :-P
>
> Not uncommon. I prefer both, myself. Lazy vague prose doesn't work as
> documentation either.

You could say

   "The fmap function must satisfy fmap id == id and fmap (f . g) == 
fmap f . fmap g". Or you can say "fmap applies a function to every 
element of a container without affecting the structure of the container 
itself". The latter tells you what the function is *for*.

>> I've never heard of a system which actually /compiles/ templates.
>
> Any template system written in a compiled language, like ASP.NET.

It's also news to me that ASP.NET is compiled. I thought it was just 
another scripting language.

> Heck, GWT takes Java code and compiles the half that runs on the browser
> into optimized javascript.

That's pretty hardcore, right there.

>> I'm not seeing how type erasure is in any way related to the ability or
>> inability to dynamically load new code.
>
> If you don't know what types are in the code you're loading, how do you
> load it?

Doesn't seem to stop C. :-P

>> Well, yeah, the Yesod scaffolder sets things up so that if you change any
>> code, and then restart the server, it recompiles anything first.
>
> Right. I'm saying ASP.NET does the Erlang thing, where it lets existing
> transactions finish with the old code while new transaction (i.e., hits)
> gets the new code. You don't have to restart anything, lose any session
> state, close any database connections, etc.

Well, yeah, being able to smoothly transition from one to the other is 
much nicer. I suppose you might perhaps be able to do that by having 
multiple physical servers and bouncing them one at a time? (I'm just 
trying to think of obvious ways that might go wrong...)

>> But yeah, it's probably quite nice for final deployment. I'm unsure what
>> it's like for development.
>
> Depends how fast it restarts. At least it isn't GWT, which takes 5
> minutes to recompile a simple page even given 1000 machines to compile
> on. :-)

Compiling is pretty instant. /Linking/ seems to take a while. (Then 
again, it's linking a 37MB binary...) I'll have to see what it runs like 
interpretted.

>> I'm not sure I follow.
>
> If "you have to restart the entire server to update" is a problem, then
> you're screwed. You either have few enough customers that a few seconds
> of down-time isn't a problem, or you're out of business at the first
> hardware failure.

Right, I see.

>>> Or the user dicks with the URL and bypasses something in your code you
>>> thought would be enforced.
>>
>> No, that's kind of the point. Each URL is checked against the list of
>> valid
>> URL structures. If it matches one, it gets passed off to that chunk of
>> code.
>> If it matches none, it's 404. (That includes checking that, say, the
>> user ID
>> *is* a valid number, and *isn't* negative, and so forth.)
>
> As long as you can check everything the type system agrees to enforce
> (which, thinking on it, I guess you can), then sure. As long as the user
> doesn't change the user ID to the number of some other user, or a
> deleted user, or something like that, or you can catch such a thing.
> I.e., it's not a panacea.

Sure. It removes one level of stuff that can go wrong. There's still 
plenty of other stuff that can break.

(I'm assuming here that you're only using a user ID in the URL to allow 
people to view somebody's public user profile. You should NOT be using 
this for actual authentication or anything like that...)

> Yep. That's what a good powerful type system can do for you that even
> "strongly" typed machine-level (vs application-level) typing can't do.

Indeed.

>> Of course, desktop interfaces have always worked like this. It's news
>> to me
>> that anyone has ever successfully implemented this for a web interface,
>> however.
>
> It's pretty frighteningly gruesome.

Required XKCD quote: http://www.xkcd.com/934/ [Esp. the alt. text.]

> Yeah. Old stuff was like that. Newer stuff makes it easier. Just sayin'.
> :-) Glad you're getting into it now, and I feel sorry for you if you
> ever *have* to get into it. Because it means you've been sucked into the
> "web-app" world, which is by far the kludgyest environment ever invented.

IMHO, the entire concept of trying to make an "application" using a 
document description language and a document access protocol is 
fundamentally flawed. But WTF do I know?

>> And yet, everybody seems to think that a database is just a flat file,
>> but better...
>
> Only *most* people. :-)

Perhaps I've spent too long on The Daily WTF.

I did see a guy on the Oracle forum once asking how to write a certain 
DB query. It seems their application was a Java thing that used the Java 
object serialisation thingy to turn its data into a binary blob to store 
in the DB. And the guy was asking how to do a query against this data. 
Oracle's answer being "you've been a very silly boy, haven't you?"

>> I'm definitely not Google. o_O
>
> I mean, everyone writing code thinks they are going to be able to
> overwhelm a 96-processor 16TB RAM SQL server machine with their app, to
> the point where they need nosql storage for ACID data.

I am *definitely* not one of those people. I doubt I'll ever write 
anything that actually gets hit by more than 2 users concurrently.

>> It did amuse me how Yesod says that "by being non-relational, we gain
>> more
>> flexibility and the ability to avoid the overhead of table joins".
>
> Yep. *And* you're actually doing the joins. You're just doing it
> manually, so you're not really avoiding any overhead. If you need the
> result of a join, you're doing the join when you store instead of when
> you fetch.

Quite.

> The only time nosql really works is when you have data that you can
> shard very specifically. When you have one user's emailbox for example,
> and you can deal with that ACIDly, and not worry about the other users.
> Stuff like accounting? Nope.

Dude, accountants *invented* the concept of "transactions"! :-D

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message