On 18/11/2011 04:07 AM, Darren New wrote:
> On 11/17/2011 6:21, Invisible wrote:
>> Erlang has Wings 3D.
>
> Errr, no. Erlang has the north american telephone switching system. :-)

Well, yeah, and Haskell has defence contractors, investment bankers, 
cryptographers and IC designers using it. AND NOBODY GIVES A DAMN. :-P

>> this becomes an interesting instance of Darren's "static typing is
>> pointless" problem.)
>
> Indeed, this is exactly the point I was making.

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

>> an API reference document generator
>
> And that is why documentation sucks these days. Those aren't
> documentation generators. Those are documentation extractors. If you
> don't put the documentation in before you run it, you don't get any
> documentation out.

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.

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.

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

>> Yesod does it differently. Templates are Haskell source code. They can
>> be in
>> separate files or inline in your main program, but either way, every
>> template gets compiled into executable machine code.
>
> 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.

>> damned time you change anything in any template anywhere, you have to
>> recompile that template, and relink the entire executable.
>
> Except that because Java and .NET don't do type erasure, you don't have
> to actually relink anything but the one script.

I'm not seeing how type erasure is in any way related to the ability or 
inability to dynamically load new code.

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

Alternatively, you can run it in an interpreter. But I don't know what 
performance would be like...

>> By default, the Warp web server is used. Since this is written in
>> Haskell,
>> the end result is that the web server, application logic, presentation
>> templates and static files are all compiled into one giant binary
>> executable. When you run this, it opens a TCP port and starts
>> listening for
>> HTTP requests.
>
> 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? ;-)

But yeah, it's probably quite nice for final deployment. I'm unsure what 
it's like for development.

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

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

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

>> Similar to all this, Yesod uses the type system to distinguish between
>> raw
>> text which needs to be escaped before being inserted into HTML / CSS / JS
>> (with the correct escaping rules for each one), and text which is
>> already in
>> such a format (and must /not/ be escaped, because that would mangle
>> it). So
>> there's one syntax for inserting stuff into a web page, and the type
>> system
>> detects whether it needs to be escaped first.
>
> *That* is the sort of thing static typing is good for. That's the
> problem hungarian naming conventions were trying to solve for languages
> that couldn't distinguish "integer number of elements in the array" and
> "integer value of blue component of that pixel".

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

>> Amusingly, there's a system to run a template, take an MD5 hash of the
>> inputs to it, and save the output to disk so it can be cached on the
>> server
>> side for faster delivery, and on the client side for reduced server load.
>
> I was doing that many, many years ago. Before HTML had <FORM> tags.
> Indeed, if you look up "REST" interfaces, that's basically what they're
> about.

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

>> widget concept handles taking lots of widgets and putting all the CSS
>> in one
>> place, all the JS in another place, etc.
>
> And GWT takes Java, compiles it into javascript and CSS and HTML,
> compresses each of those, and bundles it into one big file. Same idea.

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.

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

>> There's also a "session" feature which lets you store key/value pairs
>> in a
>> cookie. The interesting part is that the cookie is encrypted with a
>> key only
>> the server knows (so clients can't see what's in it), and signed (so
>> clients
>> can't change the contents). It adds overhead, but I don't think I've ever
>> seen it this easy before...
>
> ASP.NET. It's exactly that. You just tag the variables you want to store
> there, and when the user posts back, the framework fills in those
> variables, then gives you notifications as if it's a desktop app and the
> user just typed new values in.

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.

>> The interesting question, of course, is "what happens if the schema
>> changes?" It seems Yesod is *assuming* that the schema will never change
>> unless Yesod changes it. (I presume I don't need to point out how
>> jaw-droppingly flawed such an assumption is.)
>
> That's the other half of the "static typing isn't that useful" rant, you
> see. That's exactly what I was talking about there, if you go back and
> read again. :-)

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

Yesod has gone one step further than simply ignoring the problem. But 
only one small step.

> Exactly. Almost nobody who builds these things ever thinks as the
> database as soemthing other than a convenient place to store their data.
> All the "NoSQL" people who don't need ACID all assume they are the only
> application using the database. As soon as sales and manufacturing and
> shipping and warranty returns and customer billing are all updating the
> same database, you probably don't want to be randomly changing the schema.

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

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.

What's that? Now you want somebody *else* to be able to access it too? 
Oh dear, that's just too bad. :-P

This is exactly what a real database engine allows. It lets you query 
data in /arbitrary/ ways, not just the ways that the application 
designer considered. It lets multiple applications use the same data at 
once. It lets you change the physical storage of the data, without 
changing its logical appearance. It lets different applications see 
different logical views of the data, so you can change one app without 
needing to change them all. And so on and so forth.

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

>> Still, given the current crazy for "no-SQL databases" (i.e., "we don't
>> need
>> no stinking coherent theory of operation!"), I guess this point is
>> lost on
>> most designers...
>
> Everyone thinks they're google. :-) Funny thing is, even the nosql data
> storage at google has schemas, because you couldn't even manage it
> otherwise. "Why is my database suddenly 3x the size it should be?"

I'm definitely not Google. o_O

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

Yes, relational databases are just unnecessary overhead. :-P

Post a reply to this message