Invisible escreveu:
> It has been said that Haskell (and languages like it) will forever 
> remain an interesting curiosity until the day when large, real-world, 
> *useful* applications exist written in it. Only then will anybody 
> seriously take any notice.
> 
> Erlang has Wings 3D.

That's not quite a large app, but I digress.

> I have literally no idea what a "web framework" is. I don't know 
> anything about Ruby, and I have no idea what Rails actually does.

We all know how much you enjoy knowing nothing and still brag about it. :)

> (As it turns out, since the connection between web browser and web 
> server is untyped, this becomes an interesting instance of Darren's 
> "static typing is pointless" problem.)

I concur.

> http://www.yesodweb.com/book/
> 
> The results of my investigation were... interesting.
> 
> The next interesting thing is how content works. On a typical web 
> server, you have static pages and other resources, and then you have CGI 
> *scripts*, or possibly various kinds of templates that look like HTML, 
> but they go through a preprocessor which inserts external data into 
> certain places within the template.
> 
> 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 means 
> that template processing is lightning fast. It also means that every 
> single damned time you change anything in any template anywhere, you 
> have to recompile that template, and relink the entire executable.
> 
> 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.

Just imagine letting thousands of different users compiling their own 
"pages" into your single blob exec.

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

yeah, well, guess at some point in our lives we all did the pure C 
approach to web programming, just to better understand how it all works. 
  Blazing fast, but slow as hell workflow...

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

still better.

> The templates make use of Haskell's "quasi-quoting" feature.

quasi-quoting is a TM from Lisp industries... :)

> One of the features the manual makes a big deal of is "typesafe URLs". 
> Essentially, instead of using strings to refer to things, you create 
> data structures which represent valid URLs.
> And I *don't* mean that you 
> have a data structure which represents the parsed pieces of a URL. I 
> mean you have a dummy data type called "HomePage", and then a data type 
> called "UserProfile" with a user ID field, and then a "Topic" with a 
> topic ID field. And then you tell Yesod how to convert "UserProfile 42" 
> into a URL, and how to convert a URL into a UserProfile 42 again.

that is a fine feature.  But I still prefer regex. :)

> Yesod provides other goodies. For example, it has a "widget" concept. 

oh, how original.

> There's also a "session" feature which lets you store key/value pairs in 
> a cookie.

OHMY, php devs should sue them!

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

done.

> - ...which brings us to the fundamental problem with the whole design 
> here. It fundamentally assumes that the database is *only* for this one 
> application. Now it seems to have somehow been lost to history, but I 
> have C. J. Date on my bookshelf, and he tells me that part of the 
> definition of a "database" is that it is a store of data accessed by 
> MORE THEN ONE APPLICATION. So no single application should just blindly 
> alter the schema as it sees fit. That's why SQL databases have things 
> like views; it lets different programs see different parts of the 
> database, without having to rejigger every application every time the 
> data changes, nor alter the data when any application changes. That's 
> one of the fundamental reasons to use a proper database rather than a 
> plain flat file!
> 
> 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...
> 
> Given this assumption, it comes as no surprise that Yesod hasn't even 
> considered the possibility that a schema might change at run-time. But 
> then again, if it does, what can you actually do about it? Either the 
> tables and fields you need are present, or they aren't. If they aren't, 
> that's pretty much *got* to be a fatal run-time error.

every framework has their own way of doing things.  You either comply or 
go on your own.  Don't battle the tool, use it.

anyway, most frameworks have the same problems with databases.

> Then there's JMacro, which allows you to embed JavaScript directly in 
> your Haskell source file, and have it syntax-checked at compile-time. 
> (I.e., the final JavaScript sent to the web browser will never have 
> syntax errors; these errors are caught at Haskell compile-time.)

the amazing thing about these typesafe nuts are that they are so 
determined to the point of even basically writing syntax checks for 
foreign languages! o_0

but they are too lazy, why not also provide type safety for javascript? 
  Do not stop at syntax checks, go down to the guts of type checks as 
well! :D

> So there you have it. It seems there's quite a few web frameworks out 
> there now. And I just can't help noticing that *all* of the example code 
> I've looked at is really very, very long and difficult to follow, 
> considering the trivial amount of functionality it actually 
> implements... o_O

ruby on rails is simpler. :)

Post a reply to this message