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." :-)

> 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.

> 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.

> 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.

> 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.

>> This is how most systems that compile templates work, including Java and
>> ASP.NET.
>
> I've never heard of a system which actually /compiles/ templates.

Any template system written in a compiled language, like ASP.NET.

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

> 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?

>> And ASP.NET even notices
>> the executable changed and reloads it (or notices the source changed and
>> recompiles it and reloads it), letting existing transactions finish and
>> new transactions power up the new code.
>
> 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.

I'm not sure it works if you assume a new database schema, mind.

I'm sure both systems have their plusses and minuses. Don't read this as 
"Ha, ASP.NET is better!"  I'm just pointing out that much of what you're 
talking about isn't conceptually new, so don't embarrass yourself by talking 
about this cool new Haskell stuff with an ASP.NET programmer. :-)

>> Very convenient for deployment, you must exist. If you're writing an
>> application (like, a wiki manager say), distributing it this way is an
>> excellent way of doing it.
>
> "You must exist"? What, I post, therefore I am? ;-)

You must admit, is what I meant to type.

> 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. :-)

>>> It also means that any time anything in any template changes, that
>>> template
>>> must be recompiled, and then the entire program relinked. And then you
>>> have
>>> to shut down the running server and fire up the newly compiled on.
>>
>> Generally not a problem, really.
>
> Well, assuming you're not hacking up changes on your production box. (Why
> would you *ever* do that?)

If you can't afford downtime, but you only have one server, you're screwed 
more than your development environment will ever screw you.

>>> All of which seems... a bit strange, to me. Then again, if you want to
>>> use
>>> Apache, you can build your application for Fast-CGI instead. Then only
>>> the
>>> application logic and presentation templates get linked into a giant
>>> binary
>>> blob, and you don't have to restart the entire server to update. It still
>>> seems like a rather heavyweight approach.
>>
>> If you need better than that, you're probably doing it wrong anyway. Or
>> you should be using something like Erlang instead.
>
> I'm not sure I follow.

If restarting the server is a problem, and you don't have a second server 
capable of taking care of the load while the first one restarts, then you're 
utterly screwed the instant the power goes out, the hard drive dies, or the 
power supply makes your RAM act flakey.

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.

>>> worst thing that can happen is that you say UserProfile 138, and there
>>> *isn't* a user number 138 at the moment.
>>
>> 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.

> What it does mean is that you can take a string, insert it into a small HTML
> template, insert the small HTML template into a larger HTML template, and
> bolt on some other templates. The original string gets escaped before
> insertion. The HTML does /not/ get escaped when inserted into the rest. And
> so forth. All of which you /could/ keep track of manually, but it would be
> really easy to get it wrong...

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.

> Yesod claims to be "RESTful". I have literally no idea WTF that actually
> means. (As best as I can tell, it's a philosophy, not something more concrete.)

Kind of, yes. REST means "Representative State" or something like that. 
Basically, a URL refers to some "object" or "document", and the links to 
other objects are embedded as URLs inside that document. I.e., the way HTML 
and HTTP works. Rather than the way (for example) RPC works.

> 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.

>>> Again, I'm unconvinced of how well
>>> it really works, but I admire the idea.
>>
>> Given that pretty much everyone in the world does it this way, yah, it
>> seems it's an idea that's here to stay. :-)
>
> Again, I've never seen it done on the web.

It's relatively recent stuff, and it takes an entire complex IDE cooperating 
with the software stack to make it usable. But yah, it's common at the 
"enterprise" level.

> 1. Every system I've seen makes it unnecessarily hard to use cookies.
> 2. I haven't seen a system which actually applies cryptography to the problem.

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.

> ...which is why this is an interesting point to discuss.

Yep. Just making sure you realize that *was* what I meant, and now you're 
experiencing it first-hand, as it were.

> This is precisely my point, and it seems to be lost on most people.

Agreed.

> If you want to store just the data your application uses, go ahead. Knock
> yourself out. You can just dump it all into a flat file. That works, right?
> And you can structure that file in whatever way is most efficient for your
> particular application.

That's what bugs me about all the folks that insist the flat files that UNIX 
offer are the only thing you'll ever need, because everything else can be a 
library. Because they never actually used a system that offered more and 
realized that the universality of it was useful.

> And yet, everybody seems to think that a database is just a flat file, but
> better...

Only *most* people. :-)

> 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.

> 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". Well, you
> know what? Table joins have overhead in time. But denormalised data has
> overhead in space. And redundancy. And you know what else? Every half-sane
> RDBMS optimises the **** out of table joins. You can even cache the result
> on disk if you want. And you know what? Then you have denormalised data,
> without any of the runtime overhead, but the database MANAGES THE REDUNDANCY
> FOR YOU! Whereas the alternative is to store all your data denormalised, and
> manage the redundancy yourself, manually. Oh, I hope you don't make a
> mistake. Because, let's face it, there's lots of opportunities to get it
> wrong...

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.

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.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message