"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.
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.
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.
- 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.
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...
(However, I do think this question is a bit of a red herring: I don't see any obstacles to pulling in a different database in Pedestal.)
Apologies if this is all covered in the full docs
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.
> In this episode, I talk with my close friend Tim about what Pedestal is, why we wrote it, and what makes it so interesting.
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:
http://pedestal.io/documentation/
Much better. I still wish the sample chat app had more documentation, but if I have time I'll try to contribute that myself.
- Ryan @ Relevance
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.
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
Also, this is very alpha stuff, so many of the details are yet to be worked out.
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.
It's a PDF file with a mangled filename, rename with .pdf on the end.
via https://twitter.com/pedestal_team/status/314520340711759873
Why is the creation of a WAR file more complex than it is currently with lein-ring?
.fixed { position: relative; }
body { padding-top: 0; }
What if 100 pending requests and a few stalled connections (third-world wifi/GSM?)
It is not illegal to be a purist.)
I'm just digging into pedestal myself.
Pedestal Services have a balled up implementation that transmits the data from the server side.
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?
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.
AFAICT, Leiningen is the living proof that you can build an all-encompassing architecture without renouncing to simplicity.
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 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.)
By this standard, Common Lisp is a "ruined" Lisp. Source: http://en.wikipedia.org/wiki/Common_Lisp#Data_structures
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.
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.
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)
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.