In my humble opinion it is the only language which truly allows people to choose the best approach to a task without some unnecessary divide between more object-oriented and more functional approaches.
Looking at the languages which claimed something like this before, I can basically see two competing language design camps:. The ones from the object-oriented side which saw that functional programming gained some traction lately and thought "Well, we don't really understand that functional thingie, but let's add some fancy syntactical sugar to our language, so we can claim it is functional too! Then the ones from the functional side, who thought "Well, our functional approach is far superior to anything else and that object-oriented nonsense is annoying, but let's put some additional keywords into our language, that will make our language escape academia for sure!
Scala's designers unified many approaches coming from both sides and created some well-designed language, which is - in my humble opinion - the biggest difference to other languages, which decided to take the "Frankenstein" approach to programming language design.
Having done only smaller things with Lift yet and only superficial experience with Rails and Django, I have to admit that most of the time when I wondered why something in Lift worked differently from what I expected, this was due to the fact that my expectations were flawed and Lift's approach superior.
Lift is certainly no "easy introduction to Scala" but learning how Lift works was almost as rewarding as learning Scala before it. The ability to have a "clean" view without any logic in it is a great improvement to other frameworks which claimed the same, but fell short of it. Scala's XML literal support makes it possible to verify the well-formedness of your response: The compiler will prove at compile time that you only emit well-formed XML to a client.
Lift is viable technology and at the moment the only real approach if you want to build web applications which look, feel and behave like "real" desktop applications without writing insane amounts of code yourself. I'm working on my second Lift app at the moment - it's very strongly in Lift's sweet spot - very realtime, lots of concurrency.
That maximized the existing knowledge of our team and made it possible to make deadline. But the hot code reloading pretty much stopped happening once our project got moderately large kept running out of PermGen - it's an ongoing problem with Scala compilation pretty much anywhere , and the manual juggling of things like method call parameters and location security in different places in the website got quite cumbersome.
This time we've been committed to just working out how Lift does what it does, and the right ways to do things. This has meant a lot of casual browsing through the mailing list discussions that are several versions old are often still relevant , and most importantly a new ethos for the team. It's been necessary to internalize very strongly the motto:.
So far Lift has never disappointed us. I'm not talking, by the way, about stuff like the Sitemap and list concatenation syntax - you MUST have a pretty good handle on functional Scala, or you just won't be able to read the source code or even configure your app.
That said it's not crazy IO monads or anything, just some common idioms that you'd pick up in a few weeks of Scala anyway. The biggest problem for us has been a slow compile cycle. It takes about 20 seconds to jetty:run our project, which is a different feeling to Play which when it's working hot compiles all your stuff. On the other hand, we actually timed that the other day when one of our devs complained about it, and it worked out that although Play technically hot compiled it, the page still took 12 seconds to load in Dev mode.
So there's not a huge loss, it just feels a bit slow to have to hop out to the command line. Lift lets you do a great deal, and there are many places in our app where because it's available , we've said "Yeah, we really WOULD prefer to have that live updated immediately to all viewers of that page, instead of them discovering later that they're out of date think of all the times you've posted simultaneously to someone on SO, with the same answer.
COMET is everywhere, it turns out - it's not a specialist use case, it's the way things should work. And Lift makes it really easy. We also love the strong, programatically configurable, security model - once we switched our mindsets to "We have to whitelist every location, and specify the necessary entrance conditions", we never saw another session problem - you know, those ones where you assumed that the user would have traversed a certain path, and thus would know a whole bunch of parameters?
Like, a valid username, and an area of interest or whatever? I'm being intentionally vague. That can be one of the awkward things about a stateful framework, that you're going to want to have usable state when the user hits a page, instead of for instance just demanding that all the state gets carried along at each request.
With the impending release of Lift 2. When can we expect the beta; the final release? David Pollak : Lift 2. The error messages in development mode are much better. Lift 2. Other Lift 2. DZone: Foursquare recently shifted their website on to Lift. Can you tell us a few of your thoughts and experiences surrounding that high-profile use case? David : Yeah All of a sudden, FourSquare is getting a lot of press, etc. Then I get a note from HarryH that goes something like, "you know how you say that you prioritize issues for production sites I mean what if there were scaling problems with Lift and FourSquare turned into a disaster.
It's been a great experience to work with HarryH and his team. Interestingly, Novell and their Pulse product are also built on Lift. The demos I've seen have blown my mind in the "Geez DZone: In your opinion, what's the most interesting and relevant storyline in the Scala ecosystem right now? David : The number of people who know about Scala is the biggest story. Those who are interested can find the slide deck here:. Also, btw, that 1 per second post rate was at the time our rate of incoming "checkins" more or less foursquare's equivilant of a tweet.
It's not the requests per second our site sees in general. I cant believe. I thought its Please Rob me. The people behind Please Rob Me are either incredibly funny or incredibly foolish. The site, helmed by Boy von Amstel sounds like an alias et al, started the site to basically take pot shots at people who use too much Twitter — and sort of combined this obsession with Twitter-ing, and a game called FourSquare, in which people try to find other people using clues they broadcast.
The idea is that if people broadcast where they're at all the time, they aren't home, and are that much more susceptible to robbery — and the average robbery will mean getting payday loans to repair the damage and losses.
Search this site:.
0コメント