"There's nothing magic about these function names. There are no required names here. One of our design principles in Pedestal is that all the connections between parts of your application should be evident. You should be able to trace functions from call to definition without any “magic” or “action at a distance” metaprogramming."
Excellent. This is something that has irritated me greatly about a framework I've been working with, and it seems to be unduly popular.
What pain-points of Leiningen and Compojure does this framework aim to solve?
I'm sure its an excellent framework, but there way too much for me to consider using it right now. My concerns:
How difficult would it be to switch out Datomic for PostgreSQL?
What if I don't want ClojureScript at this moment?
What happens if I want to switch X with Z or drop ABC?
How hard will it be to minimize and erase all the things I don't want?
Why are there so many extra words needed for the routing templates?
I've always felt Clojure would get a boost from a Rails-like framework, but I'm concerned that a large, opinionated framework will break the very promise of Clojure: flexibility and easy DSL creation. Once we are faced with something that needs to be reverse-engineered or broken, then this promise is ruined.
I'm all for new frameworks and ideas, but its a little funny to think that Noir was dropped, in part, for being too large and complicated.
Despite my "not-for-me" criticisms, I do hope that you have some nice success in this framework and it attracts people to Clojure.
I was at Clojure/west today where Pedestal was unveiled. Here are some answers that I picked up:
- Pedestal doesn't deal with the DB. I just grepped for datomic on the codebase and found nothing. Relevance is one half of Datomic so it's not surprising they've used it in their example docs.
- The idea is to use clojure across the entire stack. As a clojure developer, this is fantastic. It also uses EDN as it's wire format.
- I'm not sure how far the composability goes but I get the impression that it's one of their design goals.
- The routing syntax looks pretty simple to me.
I don't get the opinion that this is Rails for Clojure. It's dealing mainly with asynchronous real-time client server communication with some great client additions. It doesn't enforce any kind of DB integration such as DB migrations which have always been one of Rail's killer features to me.
> What pain-points of Leiningen and Compojure does this framework aim to solve?
There are no problems with Leiningen solved. It's based on it like other Clojure libs with project templates etc.
With Compojure it's another story, it only gives you a handler function. Pedestal makes a routing table available, enabling reverse routing. The route definition is data based. It's less repetitive to define routes.
> I'm sure its an excellent framework, but there way too much for me to consider using it right now. My concerns:
How difficult would it be to switch out Datomic for PostgreSQL?
Not difficult at all? Have you looked at the datomic tutorial? It does nothing besides setting up a connection and querying the database. What dbs do not support that?
>What if I don't want ClojureScript at this moment?
What happens if I want to switch X with Z or drop ABC?
How hard will it be to minimize and erase all the things I don't want?
Well, you go through and pick the libraries you want to use?
> Why are there so many extra words needed for the routing templates?
It's a comprehensive description of all aspects of the flexible routing dsv, including the programatic inteface to define routes at runtime.
> I've always felt Clojure would get a boost from a Rails-like framework, but I'm concerned that a large, opinionated framework will break the very promise of Clojure: flexibility and easy DSL creation. Once we are faced with something that needs to be reverse-engineered or broken, then this promise is ruined.
It's not rails. We've all seen where that got.
> I'm all for new frameworks and ideas, but its a little funny to think that Noir was dropped, in part, for being too large and complicated.
It's a set of libraries, not a framework.
Also, it doesn't add state for everything everywhere. Instead it takes the current concept of Clojure web apps and takes it to the next level.
In Compojure you define lots of routes, mostly calling separate handling functions, only passing out the routes parameters. That what pedestals routing does by default. That's just one example of many.
"How difficult would it be to switch out Datomic for PostgreSQL?"
Seen that Datomic can be backed by many different types of storage, including SQL DBs, this sounds like a very weird question... I mean: if you want SQL, just use SQL as the backing store for Datomic.
The benefits of Datomic are too huge to go to the old crappy way of designing DBs...
Is there any easily digestible information regarding what Pedestal actually provides? Beyond the general statements on the front page, I didn't see a concise overview of what Pedestal is giving me.
full disclosure: I'm a Relevance employee and have been working on this a great deal.
Pedestal provides a few distinguishing values in this space overall:
- Same language on the client and on the server. You can get this with something running on the native OS in both locations, or with javascript and node, or with clojurescript and clojure. ClojureScript and Clojure can sit on top of the browser platform like javascript. We're opinionated and would rather solve problems with Clojure than with Javascript.
- A server-initiated communication mechanism that can send data to those clients without parking a thread or process in order to maintain all the information for managing the communication. Our Server Sent Events mechanism lets clients initiate HTTP connections to the server and hold the connection open. On the server side, we can park those connections without eating a thread to do it, and pick up the connections to send new data down to clients as appropriate.
- A pretty powerful set of libraries for developing client applications in ClojureScript. The libraries let you isolate the scope of change to HTML document trees so that changes to underlying data reflect small changes up to the presentation layer. This foundation has created lots of interesting abilities, like being able to record a set of interactions and replay them with a new presentation layer, or being able to replay specific sets of data being sent from the server to clients.
There's a lot more that we've built up, based on our experiences trying to solve problems for people in Clojure, but I think these are three things we do that deserve giving us some of your time for evaluation.
Regarding client-server communication, are you using an existing library (socket.io, sockjs, etc) for the client->server communication, did you roll your own, or is this an "exercise left to the reader"?
Communication happens over HTTP at the wire level, and we use the Server Sent Events standard (http://en.wikipedia.org/wiki/Server-sent_events), and particularly browsers' EventSource implementations as the foundation on the client side.
Pedestal Services have a balled up implementation that transmits the data from the server side.
Even if it was covered in the full docs, you shouldn't apologize. Any new entrant in framework territory should be immediately explicit about what advantages it provides.
This looks very interesting -- I don't love the web development story in Clojure/ClojureScript right now, so I'm excited for anything that makes it easier. And I get that this is an alpha.
That said, one of my biggest pain points with Clojure is poorly documented libraries. This NEEDS a high-level description of what is provided and where, and the example app needs a lot more documentation so I can figure out what it's doing.
EDIT: Whoops, I found the link to the full documentation:
Duly noted. It's been a real whirlwind getting this stuff out the door in time for Clojure/west and better documentation is one of our major goals following the release.
Thanks Ryan. I've read through more of the documentation, and I like what I am seeing. The client-side state management and push rendering looks especially cool.
My play Clojure / Clojurescript stack is a weird combination of libraries like Noir (+ Chris Granger's Clojurescript libraries) / Lobos / Korma / Hiccup / stuff I ripped from Clojurescript One.
The example explains how to use Datomic with Pedestal, and I notice you're using Domina for DOM manipulation. Is that basically the minimal stack for a database driven app? It'd be nice to see an explanation of what the rest of a Pedestal app might look like, what libraries Pedestal might replace (especially something that integrates with Postgres / MySql).
Congrats on the release and a sincere thank you to you guys at Relevance for all of your Clojure work.
It weirds me out that nowhere in the docs does it just list the libraries it builds on. Browsing through, I see Domina, Ring, Datomic, something called "slf4j", and a bunch of functions within the Pedestal namespace... and it never really explains what those external libraries are.
Definitely doesn't seem targeted at newer Clojure users. Also, the use of Datomic as a default data store rubs me the wrong way, mainly because I've never even seen it outside of a few HN articles :p
Well ring is the clojure equivalent of ruby's rack, nearly every clojure webapp uses it, and slf4j is an extremely common logging facade in java, also unsurprising. Diatomic is a weird choice though, I'd have gone with sqlite and korma
I just listened to a pod cast with Tim Ewald (recorded March 8) where he talks for 60+ minutes on Pedestal(http://thinkrelevance.com/blog/2013/03/18/pedestal-podcast-e...) and it sounds good, but I bet the learning curve will be steep. I am fetching the chat example right now to read the code.
My takeaway from the presentation at Clojure West is that Pedestal is a generic perception library, and rendering UIs is just one of many things it will be used for.
Also, this is very alpha stuff, so many of the details are yet to be worked out.
Really? In the podcast they say it's similar to what they used for over a year in production, made available to get feedback from others and that's why it's released as alpha.
Ryan from Relevance here. It is true some of the ideas behind pedestal have been around for a couple years, but always as tweaks and hacks over top of existing frameworks. Every project has had its own unique and most importantly, local, implementation.
Pedestal is a culmination of those efforts into a new set of libraries. Some of the code from other projects inspired what there is today, but an even greater portion was created from scratch to make it more generally applicable. We haven't had the chance to use this incantation of the ideas in production yet, but we wholly intend to. We hope this experience, and that of the community, can help us bring this to beta or fully production ready.
but the question is: is it a guitar? Or is it a choose-a-phone? It's got a lot of stuff! How can we tell if they're frets or if they're miles of random patch cables?
Well, I probably don't mean complicated in the "complected" sense - but there's a lot of parts and a lot of new vocabulary for a lot of new types of parts and a lot of different possible ways to fit them all together and it wasn't clear at all how to decide when to use which ones, and I simply could not get the big picture in my head from all the description of all the minutia
> Well, I probably don't mean complicated in the "complected" sense
Huh, funny you should say that because that's exactly how it struck me. Why is a URL route generating library and a new way of framing middleware-like functionality bundled under the same name as a vocabulary for expressing state transformations for the DOM?
Any sense of how easy it is to swap these pieces out? I would hate to have a Django-like scenario where it is, technically speaking, possible to swap out things like the ORM, templating, routing etc, but doing so pretty much ruins the benefits of using Django in the first place
I believe spanning disparate concerns doesn't necessarily add complexity - only size is certain to be added. Which isn't particularly wrong as long as the concerns are not coupled.
And maybe this stuff will become the new atoms that we build applications out of, and I'm just balking at all the unfamiliarity. I can't be sure, but initial impression is that they are not that - that they're just too oddly shaped to be generally useful.
Today, though, Rich's keynote was about the necessity of the restriction of choice to allow creativity to be possible. I don't know how to integrate that idea with the idea that very large cardinality isn't a problem. (Some of his examples of bad design were pieces of hardware with too many knobs or inputs)
For the record, my initial impression about Pedestal isn't particularly positive either. But I don't think one can judge its complexity only in terms of familiarity.
Probably the problem with "too many knobs" isn't the cardinality itself (how many is too many?), but that it typically is a sign that the designer hasn't realised the commonality and composability of the knobs/features.
Some thoughts on complication and number of components. Isn't it a one of main paradigms of LISP and functional programming, that 100 functions over 1 dataset is better then 10 functions over 10 datasets?
Funny... No latter than yesterday I used something very similar to Lisp macros to add function profiling to Clojure functions. Took very few lines of code, like you'd expect from a Lisp.
Parenthesis serves the purpose of homoiconicity and it looks like Clojure is homoiconic... sexp / lambda expressions / HoF / macros / etc.
You know: "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."
Regarding people like you, the "haters gonna hate" type of people, here's what Rich Hickey has to say:
"Life is too short to spend time on such people. Plenty of Lisp experts have recognized Clojure as a Lisp. I don’t expect everyone to prefer Clojure over their favorite Lisp. If it wasn’t different in some ways, there’d be little reason for it to exist."
I'd add that you're commenting on a board created by a real Lisp hacker who created its own Lisp and, if I'm not mistaken, who's now recommending Clojure has the Lisp dialect to learn for Lisp newcomers.
The whole point is that it isn't like duck. The general evaluation rule with few special cases is broken, it is a whole bunch of special cases. Adding data-structures to a Lisp ruins it. It become a mess of a wired syntax, various comprehensions and unnecessary explicit conventions.
The beauty and elegance of a Lisp lies in that there is nothing to remove - a few selected ideas put together - and one common for code and data underlying list structure. This leads to a compact, readable code with relatively easily "maps to" machine code, because the memory is flat.
I don't care what Rich Hickey said. For me he is much better salesman, than engineer. He is very clever at selling, no doubt. But the whole Java scam is about clever selling of unnecessary complications from the very first days.
Moreover, those Lisp experts I have learned from didn't even mention Clojure.)
In Clojure the data structures work consistently across the language, which to me is one of many reasons why Clojure is a better Lisp than Common Lisp (but CL has its place).
> Moreover, those Lisp experts I have learned from didn't even mention Clojure.
On the contrary, Clojure is and has since its inception been praised and often adopted by prominent users of Scheme and Common Lisp (the list is too long, but for example the late Daniel Weinreb declared Clojure the future of Lisp). The Clojure conference in Portland this last few days is a perfect example of the cross-fertilization between the Racket/Scheme logic programming subcultures and the Clojure logic programming subcultures.
Come on. Arrays are absolutely necessary for certain algorithms, so, they are here, so are efficient hash-tables. Structures (records) were standardized, but they are nothing but a bunch of macros. And that is good-enough.)
I'm a virtual student of prof. Brian Harvey (and reader of pg and Norvig).
And there is nothing special in trying to "port" the ideas form the "old" Lisp world to Clojure and present them as a new. Simple trick. All those logic programming buzz is from karen, query language of datatomic is from old expert systems, etc.
"There's nothing magic about these function names. There are no required names here. One of our design principles in Pedestal is that all the connections between parts of your application should be evident. You should be able to trace functions from call to definition without any “magic” or “action at a distance” metaprogramming."
Excellent. This is something that has irritated me greatly about a framework I've been working with, and it seems to be unduly popular.