Comparing Dynamic and Static Language Approaches to Web Frameworks [pdf] | Hacker News Reader

Comparing Dynamic and Static Language Approaches to Web Frameworks [pdf]

cs.kent.ac.uk

29 pointstelemachos14 comments

Hate to be mean, but this is just waxing poetic over the basics. Author is comparing syntax, froth; no actual productive parts of web development is discussed.

I have written web apps in Common Lisp for 2-3 years, and in Java (with Play! Framework) for a year now: routes, templates and form submission are the most standardized parts of all framworks. My Lisp code to do those things is identical to the way it's done in Java.

If you want to compare web frameworks start by comparing their database & Model substrates: ORM, migrations, validation .. those are where you will become unstuck. (if you don't consider those an integral part of the web-framework, then we haven nothing to discuss, pedal your big-wheel away)

Are you still on Play 1.2.x ? What do you think about Play 2?

(I personally would prefer Play! to just try to be the perfect Rails-like experience in Javaland, instead of something much bigger).

Essentially, my own fork of 1.2.3. The later versions broke multiple file uploads. I have no intention of using Scala for work, don't wanna dick with massive changes for the sake of changes .. so no, no Play2 for me either.

It should have been named "Comparing Rails with Yesod". Even though other dynamic languages are somewhat similar to ruby, it's hard to say that haskell is just another statically typed language. Inclusion of other languages and frameworks would have really improved this talk.

Or "Why I Like Yesod Better than Rails". Which is fine, but be up front about it.

Agree. I'm using Spring MVC (Java) as my web application framework of choice. Using Yesod as an ostensive definition for a static-language approach to web frameworks (as the title alludes to) is misleading: comparing the concepts presented in these slides with static-language Spring MVC, I couldn't find significant similarities between Yesod and Spring MVC.

I don't know much about any of the Java web frameworks-- my only experience with a web framework on a statically typed platform is with ASP.NET MVC. ASP.NET MVC makes heavy use of reflection, and runtime errors are common -- something that's also true of the common ORMs for .NET. So even though you're on a statically-typed platform, you sometimes aren't getting the classical 'perks' of static-typing, particularly the compile-time errors.

I've got a casual interest in Haskell and flipped through Learn You A Haskell's earlier chapters, but I can't scan snippets of fancy Meta-Haskell well, so some of the specifics here are probably lost on me. The text of the slides does seem to admit that the author is also kind of new to Yesod. (I've never met a Yesod expert...)

With all of that said, I think that part of the premise was that while Yesod's not a typical 'web platform for a static language', it's an interesting case study because it (apparently) tries harder to maintain compile-time benefits static typing everywhere. (I understand this is true of the persistence layer as well)

I agree that the content isn't what you'd expect given the title, but I get why the author's interested in Yesod and why it was chosen to represent the 'static' side.

I don't think it is misleading. I think it is misleading to pretend java is a reasonable example of static typing. Java does tons of dynamic typing (hello null pointer exceptions), and would best be described as half way between static and dynamic typing.

I found this article pretty light on substance, but I agree with the <tl;dr>:

Dynamic languages: faster to write something, less code, no time wasted waiting for compilation, but harder to maintain and a bitch to refactor. Need more unit tests.

Static languages: more boilerplate, slower write time, but man it's nice to get compile-time vs. run-time errors...

> no time wasted waiting for compilation

Fwiw, this is less and a less a problem with static languages. In the Scala ecosystem, for example, on-the-fly compilation is available with Play, or any framework that uses SBT [1] (Lift, Scalatra, etc). Edit, save, and your edits (and only your edits) are automatically recompiled and reloaded.

> more boilerplate

Not sure about that. Lift at least (maybe Play too, not sure) is about the same lines of code as Rails, less if you include tests.

1. github.com/harrah/xsbt

Interesting. I've never used Lift or Play -- thanks for the info.

Some info on on-the-fly compilation:

https://github.com/harrah/xsbt/wiki/Triggered-Execution

http://cookbook.liftweb.net/Developing+using+a+text+editor.h...

https://github.com/liftstack/lift24-s29-blank.g8#readme (still a work in progress, not debugged, but you can test the sbt "~ compile" continuous compilation directive)

Play supports dynamic compilation for Java as well.

Yes, through sbt too, I just realized:

http://www.playframework.org/documentation/2.0/SBTSettings

Reply on news.ycombinator.com