[ANN, GSoC] A Common Clojure Source Metadata Model

[richard . moehn]

Hi all!

I'm one of this year's students accepted to the Google Summer of Code for 
doing
a Clojure project. (Thanks to Alex Miller for supporting my application!) 
For
those who like to decide from the first paragraph whether they will read on 
or
not: the goal of my project is to develop a model for Clojure source 
metadata
(most of them are documentation) and ways to capture and publish them. The
following two paragraphs are taken from my project proposal:

 ❧ To the joy of the community, the number of Clojure-based libraries is
steadily growing. To the dismay of the community, there is no agreed-upon 
way of
getting information about those libraries' APIs. We have API documentation
generators for individual libraries, like Autodoc or Codox. And we have big
overview sites like Grimoire and CrossClj. None of them are comprehensive. 
All
provide their information in a human-friendly way. Only some cater for the
computer.

The goal of this project is to develop a comprehensive and extensible model 
for
describing Clojure sources from an API perspective. I will also write a 
program
that analyses Clojure sources according to this model and outputs data
documenting their usage. This could be compared to Javadoc, but emitting 
data to
be consumed by other tools instead of HTML. In order to foster adoption, I 
will
provide extensive  documentation, including examples of such consumer 
tools, and
emphasize active communication with the community. ☙

The project idea comes from Alex Miller, who also is my mentor, together 
with
Reid McKenzie. Coding for the GSoC hasn't started yet. – Until 24 April 
we're in
the warmup phase called community bonding. I wanted to use this time for 
getting
ideas and feedback from you, so I've prepared some questions as a starting
point:

 - Who is interested in the project?
- What would you like to see?
 - Who has done/thought about similar things?
- What have you done?
- How have you done it?
- What have you found? – Difficulties, annoyances, surprises.
- What would you like to see?
- What is important to you?
- Have you built something that I might reuse?
 - What else comes to your mind?

There are many things out there which are more or less closely related to my
project:

 - cljs.info: https://github.com/cljsinfo
 - Autodoc: https://github.com/tomfaulhaber/autodoc
 - Codox: https://github.com/weavejester/codox
 - Grimoire: http://conj.io/
 - CrossClj: https://crossclj.info/
 - ClojureDocs: https://clojuredocs.org/
 - Clojure Atlas: http://www.clojureatlas.com/

I would be especially happy to receive input from the people involved in 
those
efforts.

Reading this might help not having to say things again that have been said
before: https://groups.google.com/d/topic/clojure/E1oxVE4UMxQ/discussion

I wish everyone a good summer!

Richard

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[richard . moehn]

I just saw that the plain text formatting is horrible. Sorry for that.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Zubair Quraishi]

Also Coils (https://github.com/zubairq/coils)

On Saturday, May 2, 2015 at 10:43:53 PM UTC+2, g vim wrote:
>
> I recently did some research into web frameworks on Github. Here's what 
> I found: 
>
>
> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> One could conclude from this that the Clojure community isn't that 
> interested in web development but the last Clojure survey suggests 
> otherwise. Clojure's library composition approach to everything only 
> goes so far with large web applications, as Aaron Bedra reminded us in 
> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower 
> means less momentum and more bugs. Furthermore, I have a hunch that 
> Clojure's poor adoption as indicated by Indeed.com maybe due to this 
> immaturity in the web framework sphere. Why is it that Elixir, with a 
> much smaller community and lifespan than Clojure's, has managed to put 4 
> times as much mindshare into its main web framework when its module 
> output, as measured by modulecounts.com, is a tiny fraction of Clojure's? 
>
> gvim 
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Embedded systems and transpiling Clojure to Nim

[adrians]

Alan, have you looked at Clasp? I'm not sure if CL is something you like, 
but maybe it has potential for your application.

https://github.com/drmeister/clasp


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Sven Richter]

So, what I gather from this discussion are the following points. Clojure 
"needs" a "webframework" that is

- fully documented
- easy for beginners to use
- opinionated about the libraries
- structured
- composable
- has something nice like django's admin backend
- a vibrant community support
- a shopping card (whereas I would see that fit into an external library)

I agree that we have almost everything we need in the form of single 
libraries. And I think a mix of leiningen templates and plugins is the way 
to go here.
The reason for the last statement is my experience with django. The admin 
UI is awesome and it fullfills 95% of your needs, but for the rest of it to 
make it work I had to start hacking my local django source, which is PITA 
obv.

I would refrain from doing some magic that only works in a specific 
context, but instead just generate code that is put into a fixed structure 
and works. The advantage is, one can change the code all the time if one 
needs to.

All in all this is basically the direction I want to go with closp and 
closp-crud. The intention is not to have a webframework, but to automatize 
steps that need to be done manually otherwise.

I am open for everything in that area, as long as it stays in the limits I 
stated above, so, if someone wants to join, he is welcome.

I would also go the other way around and put efforts into someone elses 
project, if that makes sense.

Am Montag, 4. Mai 2015 07:43:43 UTC+2 schrieb puzzler:
>
> On Sat, May 2, 2015 at 11:12 PM, Sven Richter  > wrote:
>
>> Reading through all the discussion I don't get which features you are 
>> actually missing. I love luminus and did a lot with it, however, for me it 
>> was missing some standard stuff, that's why I put together closp, which is 
>> just another leiningen template providing some more features out of the box.
>> I'd consider adding even more features if you would become more specific 
>> in terms of features.
>>
>
> For me, one of the killer features that keeps me coming back to 
> Python/Django for web development is the auto-generated admin interface 
> that lets non-programmers add new content to the database. 
>
> Clojure's Caribou is the only Clojure system I've seen to offer something 
> similar, but as I recall, Caribou is no longer being actively developed.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Colin Fleming]

Note that the shopping cart is just one specific example from my current
itch that needs scratching - it's a very common one, but I'm sure there are
plenty more reusable component types that people expect these days.

One problem I see with the composition approach (which I'm a huge fan of in
general) is the multiplicative complexity. Something like a shopping cart
needs access to the persistence layer. In Rails, this is very easy - you
use ActiveRecord and you're done because everything else uses ActiveRecord
too. However in the Clojure world we have N persistence libraries
implementing M persistence strategies - I've never tried to make a reusable
component that sits in the "middle" of the stack (i.e. not something that's
relatively trivial to make dependency-free like logging), but I can imagine
that it's very difficult. And of course, persistence is just one aspect,
there must be many more like authentication and so on. A big part of the
reason for Ring's success is that it's the only game in town - I'm sure we
wouldn't have so much great functionality built on top of it if we had 4
incompatible options to choose from.

Someone earlier in the thread wrote about how Ruby was the abstraction in
contrast to PHP where libraries were tied to a framework. I've never worked
with Rails seriously, but I find it hard to believe that libraries such as
shopping carts intended for Rails will work out of the box with some other
framework - is this the case? The ones I looked at (admittedly briefly and
some time ago) were all Rails-specific.

On 4 May 2015 at 20:41, Sven Richter  wrote:

> So, what I gather from this discussion are the following points. Clojure
> "needs" a "webframework" that is
>
> - fully documented
> - easy for beginners to use
> - opinionated about the libraries
> - structured
> - composable
> - has something nice like django's admin backend
> - a vibrant community support
> - a shopping card (whereas I would see that fit into an external library)
>
> I agree that we have almost everything we need in the form of single
> libraries. And I think a mix of leiningen templates and plugins is the way
> to go here.
> The reason for the last statement is my experience with django. The admin
> UI is awesome and it fullfills 95% of your needs, but for the rest of it to
> make it work I had to start hacking my local django source, which is PITA
> obv.
>
> I would refrain from doing some magic that only works in a specific
> context, but instead just generate code that is put into a fixed structure
> and works. The advantage is, one can change the code all the time if one
> needs to.
>
> All in all this is basically the direction I want to go with closp and
> closp-crud. The intention is not to have a webframework, but to automatize
> steps that need to be done manually otherwise.
>
> I am open for everything in that area, as long as it stays in the limits I
> stated above, so, if someone wants to join, he is welcome.
>
> I would also go the other way around and put efforts into someone elses
> project, if that makes sense.
>
> Am Montag, 4. Mai 2015 07:43:43 UTC+2 schrieb puzzler:
>
>> On Sat, May 2, 2015 at 11:12 PM, Sven Richter 
>> wrote:
>>
>>> Reading through all the discussion I don't get which features you are
>>> actually missing. I love luminus and did a lot with it, however, for me it
>>> was missing some standard stuff, that's why I put together closp, which is
>>> just another leiningen template providing some more features out of the box.
>>> I'd consider adding even more features if you would become more specific
>>> in terms of features.
>>>
>>
>> For me, one of the killer features that keeps me coming back to
>> Python/Django for web development is the auto-generated admin interface
>> that lets non-programmers add new content to the database.
>>
>> Clojure's Caribou is the only Clojure system I've seen to offer something
>> similar, but as I recall, Caribou is no longer being actively developed.
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send emai

Re: Clojure needs a web framework with more momentum

[John Louis Del Rosario]

Very interesting discussion going on here. As a beginner, what I'd like to 
see is not something like Django or Rails, but something like Flask.
Where someone can just (require 'someframework) and it works. Maybe it 
could have thin wrappers over compojure, etc., since it will need to be 
opinionated anyway. It's still very simple, but takes away a lot of the 
guesswork and the distributed docs across multiple projects problem.

Additional features can be done as libraries then, but specific for 
`someframework`, like what Flask has. e.g. `someframework-sessions`, etc.

Just my 2c.

On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>
> I recently did some research into web frameworks on Github. Here's what 
> I found: 
>
>
> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> One could conclude from this that the Clojure community isn't that 
> interested in web development but the last Clojure survey suggests 
> otherwise. Clojure's library composition approach to everything only 
> goes so far with large web applications, as Aaron Bedra reminded us in 
> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower 
> means less momentum and more bugs. Furthermore, I have a hunch that 
> Clojure's poor adoption as indicated by Indeed.com maybe due to this 
> immaturity in the web framework sphere. Why is it that Elixir, with a 
> much smaller community and lifespan than Clojure's, has managed to put 4 
> times as much mindshare into its main web framework when its module 
> output, as measured by modulecounts.com, is a tiny fraction of Clojure's? 
>
> gvim 
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Andrey Antukh]

This is something that I'm currently working on:
https://github.com/funcool/catacumba
It is still in alpha, but it has the same philosophy that you have mention.

Cheers.
Andrey

2015-05-04 12:06 GMT+02:00 John Louis Del Rosario :

> Very interesting discussion going on here. As a beginner, what I'd like to
> see is not something like Django or Rails, but something like Flask.
> Where someone can just (require 'someframework) and it works. Maybe it
> could have thin wrappers over compojure, etc., since it will need to be
> opinionated anyway. It's still very simple, but takes away a lot of the
> guesswork and the distributed docs across multiple projects problem.
>
> Additional features can be done as libraries then, but specific for
> `someframework`, like what Flask has. e.g. `someframework-sessions`, etc.
>
> Just my 2c.
>
>
> On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what
>> I found:
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS
>>
>> LuminusClojure28678
>> CaribouClojure 2275
>>
>> BeegoGolang991522
>>
>> PhoenixElixir  1241949
>>
>> YesodHaskell   1303722
>>
>> LaravelPHP2684421
>>
>> PlayScala   4176085
>>
>> SymfonyPHP113020914
>>
>> RailsRuby   269151000
>>
>>
>> One could conclude from this that the Clojure community isn't that
>> interested in web development but the last Clojure survey suggests
>> otherwise. Clojure's library composition approach to everything only
>> goes so far with large web applications, as Aaron Bedra reminded us in
>> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower
>> means less momentum and more bugs. Furthermore, I have a hunch that
>> Clojure's poor adoption as indicated by Indeed.com maybe due to this
>> immaturity in the web framework sphere. Why is it that Elixir, with a
>> much smaller community and lifespan than Clojure's, has managed to put 4
>> times as much mindshare into its main web framework when its module
>> output, as measured by modulecounts.com, is a tiny fraction of
>> Clojure's?
>>
>> gvim
>>
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Sean Johnson]

On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:

All in all this is basically the direction I want to go with closp and 
> closp-crud. The intention is not to have a webframework, but to automatize 
> steps that need to be done manually otherwise.
>

One potential problem with this "web framework" as app template approach is 
upgrade-ability.  When 2.0 of your "framework" comes out, what happens to 
an app generated from 1.0 that wants to benefit from the new capabilities?

It's not a showstopper to the approach. It's just something to think hard 
about. I've taken a couple of long lived Rails apps from Rails 1 to Rails 4 
and while there have been breaking changes with each major version change 
(and some minor versions) in general it's pretty easy to keep up with the 
latest versions and there are copious docs (even whole ebooks in some 
cases) to walk developers through the changes.

Cheers,
Sean

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Eric MacAdie]

I think what Clojure needs is a default. It doesn't matter if it is a "web
framework" like Rails, or "libraries strung together" like Luminus.

When a Ruby newbie asks how to make a web app, the default answer is to
look at Rails. In Python, the default answer is Django. Compared to that,
the default answer in Clojure to do it yourself can sound like "go jump off
a cliff".

= Eric MacAdie


On Mon, May 4, 2015 at 7:09 AM, Sean Johnson  wrote:

>
>
> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
>
> All in all this is basically the direction I want to go with closp and
>> closp-crud. The intention is not to have a webframework, but to automatize
>> steps that need to be done manually otherwise.
>>
>
> One potential problem with this "web framework" as app template approach
> is upgrade-ability.  When 2.0 of your "framework" comes out, what happens
> to an app generated from 1.0 that wants to benefit from the new
> capabilities?
>
> It's not a showstopper to the approach. It's just something to think hard
> about. I've taken a couple of long lived Rails apps from Rails 1 to Rails 4
> and while there have been breaking changes with each major version change
> (and some minor versions) in general it's pretty easy to keep up with the
> latest versions and there are copious docs (even whole ebooks in some
> cases) to walk developers through the changes.
>
> Cheers,
> Sean
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Sven Richter]

Am Montag, 4. Mai 2015 14:09:35 UTC+2 schrieb Sean Johnson:
>
>
>
> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
>
> All in all this is basically the direction I want to go with closp and 
>> closp-crud. The intention is not to have a webframework, but to automatize 
>> steps that need to be done manually otherwise.
>>
>
> One potential problem with this "web framework" as app template approach 
> is upgrade-ability.  When 2.0 of your "framework" comes out, what happens 
> to an app generated from 1.0 that wants to benefit from the new 
> capabilities?
>
>
I thought about it and all that came to my mind that there simply won't be 
an upgrade path. Once you generated your code / templates / whatever you 
are done and up to yourself. 
Having a supported upgrade path might be

1. to much for one or two persons to handle
2. Incompatible to the "generate" everything approach as one would have to 
make sure that old code, enriched with user code (which can be anything), 
still works with new code in whatever feature context that might be.
 

> It's not a showstopper to the approach. It's just something to think hard 
> about. I've taken a couple of long lived Rails apps from Rails 1 to Rails 4 
> and while there have been breaking changes with each major version change 
> (and some minor versions) in general it's pretty easy to keep up with the 
> latest versions and there are copious docs (even whole ebooks in some 
> cases) to walk developers through the changes.
>

I am curious, why did you upgrade your application over such a long time? 
Was this a product that got added new features over many years? Or was it 
more a "it's easy to do, so let's just stay up to date in case we might 
need it"?

Best Regards,
Sven

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Sean Johnson]

I thought about it and all that came to my mind that there simply 
won't be
an upgrade path. Once you generated your code / templates / whatever 
you

are done and up to yourself.
Having a supported upgrade path might be

1. to much for one or two persons to handle
2. Incompatible to the "generate" everything approach as one would 
have to
make sure that old code, enriched with user code (which can be 
anything),

still works with new code in whatever feature context that might be.


I think that's a very reasonable approach to take for the app template 
approach to a "web framework". I just wonder if it will ever meet the 
original posters presumed need for a web framework for the Clojure 
community. I think an upgrade path is probably table stakes (for many 
people, not all) for a web framework that will see wide adoption these 
days.


I am curious, why did you upgrade your application over such a long 
time?
Was this a product that got added new features over many years? Or was 
it
more a "it's easy to do, so let's just stay up to date in case we 
might

need it"?


It's the latter case, a few products that started 6+ years ago that 
continue to grow in usage and features. I can also add that the benefits 
that came along with each release (Rails 2, 3 and 4) have been critical 
in being able to add new features and modernize the app. Building 
features today with the tech we had in Ruby/Rails in 2009 would be very 
inefficient.


Cheers,
Sean

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Ernie de Feria]

I would like to echo the sentiment expressed by several posters in this 
thread, but with a slight twist. A few years back I picked up Ruby and Ruby 
on Rails as the language/framework to create a website with moderate 
complexity and functionality. I did this without any prior experience with 
the language of framework. What allowed me to quickly pick up both was the 
excellent documentation around the language and framework. For example, 
with the information from http://guides.rubyonrails.org and the canonical 
application built in https://www.railstutorial.org one can acquire the 
necessary knowledge to develop highly functional websites. Branching out to 
leverage "non-canonical" libraries/products then becomes a fairly easy 
exercise (MongoDB instead of MySQL, Mongoid instead of ActiveRecords, 
etc.). What allows that to happen is the momentum built around the Rails 
ecosystem via community participation and documentation. 

We have recently started to build our "back end" infrastructure in Clojure. 
Many times we have discussed the value and desire to unify our development 
efforts on and around Clojure. Inevitably we tally up all the functionality 
inherited from Ruby gems (that play nice with Rails - the Framework) that 
would have to be replicated in Clojure and there always shortcomings, not 
necessarily in the availability of libraries that perform these functions, 
but in the readily accessible documentation about how to best integrate 
them. 

The "composable libraries over framework" mantra is technically solid. What 
we're missing, in the "web development with Clojure" subset of the 
community, is the stewardship to create and maintain a canonical 
amalgamation of composable libraries and the best practices around them - a 
la https://railstutorial.org. This would lower the barrier of entry into 
the web development realm for Clojure developers. My 2+ cents.

On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote:
>
> I recently did some research into web frameworks on Github. Here's what 
> I found: 
>
>
> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> One could conclude from this that the Clojure community isn't that 
> interested in web development but the last Clojure survey suggests 
> otherwise. Clojure's library composition approach to everything only 
> goes so far with large web applications, as Aaron Bedra reminded us in 
> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower 
> means less momentum and more bugs. Furthermore, I have a hunch that 
> Clojure's poor adoption as indicated by Indeed.com maybe due to this 
> immaturity in the web framework sphere. Why is it that Elixir, with a 
> much smaller community and lifespan than Clojure's, has managed to put 4 
> times as much mindshare into its main web framework when its module 
> output, as measured by modulecounts.com, is a tiny fraction of Clojure's? 
>
> gvim 
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 14:34, Ernie de Feria wrote:

I would like to echo the sentiment expressed by several posters in this
thread, but with a slight twist. A few years back I picked up Ruby and
Ruby on Rails as the language/framework to create a website with
moderate complexity and functionality. I did this without any prior
experience with the language of framework. What allowed me to quickly
pick up both was the excellent documentation around the language and
framework. For example, with the information from
http://guides.rubyonrails.org and the canonical application built in
https://www.railstutorial.org one can acquire the necessary knowledge to
develop highly functional websites. Branching out to leverage
"non-canonical" libraries/products then becomes a fairly easy exercise
(MongoDB instead of MySQL, Mongoid instead of ActiveRecords, etc.). What
allows that to happen is the momentum built around the Rails ecosystem
via community participation and documentation.

We have recently started to build our "back end" infrastructure in
Clojure. Many times we have discussed the value and desire to unify our
development efforts on and around Clojure. Inevitably we tally up all
the functionality inherited from Ruby gems (that play nice with Rails -
the Framework) that would have to be replicated in Clojure and there
always shortcomings, not necessarily in the availability of libraries
that perform these functions, but in the readily accessible
documentation about how to best integrate them.

The "composable libraries over framework" mantra is technically solid.
What we're missing, in the "web development with Clojure" subset of the
community, is the stewardship to create and maintain a canonical
amalgamation of composable libraries and the best practices around them
- a la https://railstutorial.org. This would lower the barrier of entry
into the web development realm for Clojure developers. My 2+ cents.



Clojure needs its own Rails or Typesafe Reactive Platform otherwise I 
fear it will remain a niche player. What's to lose? The current approach 
will always remain an option.


gvim







--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Timothy Baldridge]

The thing that bugs me the most about these sort of conversations about
"best practices" is that they often present a set of solutions without
first analyzing the problem at hand.

If I came to this mailing list and asked "I want to write a websever in
Clojure..what should I use?". The response would most likely be Ring +
Compojure. Okay, not bad options, but that recommendation has been given
with absolutely no analysis of what I'm trying to accomplish. What if I
need async? What if I need web sockets? What sort of connection load am I
expecting? Will my system handle mostly persistent connections (like
websockets or SSE), or will it be more canned (and cacheable) data? If
someone recommends Ring to me, I may be pigeonholed into some system I'll
have to refactor later. Perhaps the best option is Aleph or Pedestal.

That's the real issue with canned responses like rails tutorial. They
assume my needs match your needs and match the needs of most people. That's
just not the best way to go about doing software development. And it's a
problem I've seen in so many areas of computing.

I've lost countless hundreds of hours of my life to frameworks that default
to bulky serialization formats (like XML or JSON), or frameworks that
assume LAN connections to the servers, or frameworks that assume I won't be
using multi-threading, or frameworks that assume I won't try to load 10k
rows on a single page, or frameworks that assume any number of things. The
thing I love the most about the Clojure community is that, more than any
other community I've been a part of, they try to ask you to think before
you jump.

So what I would recommend is more of a set of guidelines, and matrices.
List all the frameworks/libraries on one axis, and features on another, and
start commenting. Make a page like this: (
http://en.wikipedia.org/wiki/Comparison_of_video_container_formats)

Mention that Ring is well supported by the community, but doesn't work well
with fully async servers, mention that Aleph does all the async you need,
but is a bit non-standard. Mention that data.json is pure Clojure, but
cheshire is most likely faster.

Just present the options, and let the users make up their own minds. You
don't understand the needs of all of your users. So don't try to solve
their problems, instead present them with options and let them make up
their own minds.  I guarantee you that whatever tech you recommend to
someone, the won't like some aspect of it,  so better to present them with
all the options and let them choose, then they can only blame themselves if
it doesn't work out exactly like they expected.



On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria 
wrote:

> I would like to echo the sentiment expressed by several posters in this
> thread, but with a slight twist. A few years back I picked up Ruby and Ruby
> on Rails as the language/framework to create a website with moderate
> complexity and functionality. I did this without any prior experience with
> the language of framework. What allowed me to quickly pick up both was the
> excellent documentation around the language and framework. For example,
> with the information from http://guides.rubyonrails.org and the canonical
> application built in https://www.railstutorial.org one can acquire the
> necessary knowledge to develop highly functional websites. Branching out to
> leverage "non-canonical" libraries/products then becomes a fairly easy
> exercise (MongoDB instead of MySQL, Mongoid instead of ActiveRecords,
> etc.). What allows that to happen is the momentum built around the Rails
> ecosystem via community participation and documentation.
>
> We have recently started to build our "back end" infrastructure in
> Clojure. Many times we have discussed the value and desire to unify our
> development efforts on and around Clojure. Inevitably we tally up all the
> functionality inherited from Ruby gems (that play nice with Rails - the
> Framework) that would have to be replicated in Clojure and there always
> shortcomings, not necessarily in the availability of libraries that perform
> these functions, but in the readily accessible documentation about how to
> best integrate them.
>
> The "composable libraries over framework" mantra is technically solid.
> What we're missing, in the "web development with Clojure" subset of the
> community, is the stewardship to create and maintain a canonical
> amalgamation of composable libraries and the best practices around them - a
> la https://railstutorial.org. This would lower the barrier of entry into
> the web development realm for Clojure developers. My 2+ cents.
>
> On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what
>> I found:
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS
>>
>> LuminusClojure28678
>> CaribouClojure 2275
>>
>> BeegoGolang991522
>>

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 15:24, Timothy Baldridge wrote:

The thing that bugs me the most about these sort of conversations about
"best practices" is that they often present a set of solutions without
first analyzing the problem at hand.

If I came to this mailing list and asked "I want to write a websever in
Clojure..what should I use?". The response would most likely be Ring +
Compojure. Okay, not bad options, but that recommendation has been given
with absolutely no analysis of what I'm trying to accomplish. What if I
need async? What if I need web sockets? What sort of connection load am
I expecting? Will my system handle mostly persistent connections (like
websockets or SSE), or will it be more canned (and cacheable) data? If
someone recommends Ring to me, I may be pigeonholed into some system
I'll have to refactor later. Perhaps the best option is Aleph or Pedestal.

That's the real issue with canned responses like rails tutorial. They
assume my needs match your needs and match the needs of most people.
That's just not the best way to go about doing software development. And
it's a problem I've seen in so many areas of computing.

I've lost countless hundreds of hours of my life to frameworks that
default to bulky serialization formats (like XML or JSON), or frameworks
that assume LAN connections to the servers, or frameworks that assume I
won't be using multi-threading, or frameworks that assume I won't try to
load 10k rows on a single page, or frameworks that assume any number of
things. The thing I love the most about the Clojure community is that,
more than any other community I've been a part of, they try to ask you
to think before you jump.

So what I would recommend is more of a set of guidelines, and matrices.
List all the frameworks/libraries on one axis, and features on another,
and start commenting. Make a page like this:
(http://en.wikipedia.org/wiki/Comparison_of_video_container_formats)

Mention that Ring is well supported by the community, but doesn't work
well with fully async servers, mention that Aleph does all the async you
need, but is a bit non-standard. Mention that data.json is pure Clojure,
but cheshire is most likely faster.

Just present the options, and let the users make up their own minds. You
don't understand the needs of all of your users. So don't try to solve
their problems, instead present them with options and let them make up
their own minds.  I guarantee you that whatever tech you recommend to
someone, the won't like some aspect of it,  so better to present them
with all the options and let them choose, then they can only blame
themselves if it doesn't work out exactly like they expected.



A seasoned professional/Clojure guru like yourself will obviously prefer 
a customised approach but the beginner and mid-level developer faces a 
different problem - how to get something fully-featured up quickly and 
maybe get paid for doing a job within a limited budget & timescale where 
exploring all the options and how to fit them together just isn't an option.


I'm all in favour of library composition but not exclusively. In the 
Python world they have Django and a tradition of do-it-yourself 
lightweight options. I don't understand why we can't adopt a similar 
approach.


gvim








--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Luc Prefontaine]

+1

This exactly the kind of exercises that needs to done as part of a
product design. New potential needs have to be foreseen at this
stage, not 18 months after a first release.

This is why I hate frameworks, they assume some of these
decisions and it's not always stated clearly. Someone has to
discover the sad effects and if you are not lucky, you're the 'king of the
farce'.

They lure you in a trap pampered with 'easy', 'obvious'... Until
you have a need that cannot be met along the way.

I read several comments about how easy it is to upgrade Rails.

Either things have been improving at the speed of light or I am
a complete idiot. My last upgrades from 2.x to 2.y have been
nightmares, dependency hell multiplied by an unknown factor
above 100...

I would rather deal with an explicit dependency graph than
work with magic stuff that eventually breaks in obscure ways
after an upgrade and requires mods in remote places in foreign code.

Luc P.

> The thing that bugs me the most about these sort of conversations about
> "best practices" is that they often present a set of solutions without
> first analyzing the problem at hand.
> 
> If I came to this mailing list and asked "I want to write a websever in
> Clojure..what should I use?". The response would most likely be Ring +
> Compojure. Okay, not bad options, but that recommendation has been given
> with absolutely no analysis of what I'm trying to accomplish. What if I
> need async? What if I need web sockets? What sort of connection load am I
> expecting? Will my system handle mostly persistent connections (like
> websockets or SSE), or will it be more canned (and cacheable) data? If
> someone recommends Ring to me, I may be pigeonholed into some system I'll
> have to refactor later. Perhaps the best option is Aleph or Pedestal.
> 
> That's the real issue with canned responses like rails tutorial. They
> assume my needs match your needs and match the needs of most people. That's
> just not the best way to go about doing software development. And it's a
> problem I've seen in so many areas of computing.
> 
> I've lost countless hundreds of hours of my life to frameworks that default
> to bulky serialization formats (like XML or JSON), or frameworks that
> assume LAN connections to the servers, or frameworks that assume I won't be
> using multi-threading, or frameworks that assume I won't try to load 10k
> rows on a single page, or frameworks that assume any number of things. The
> thing I love the most about the Clojure community is that, more than any
> other community I've been a part of, they try to ask you to think before
> you jump.
> 
> So what I would recommend is more of a set of guidelines, and matrices.
> List all the frameworks/libraries on one axis, and features on another, and
> start commenting. Make a page like this: (
> http://en.wikipedia.org/wiki/Comparison_of_video_container_formats)
> 
> Mention that Ring is well supported by the community, but doesn't work well
> with fully async servers, mention that Aleph does all the async you need,
> but is a bit non-standard. Mention that data.json is pure Clojure, but
> cheshire is most likely faster.
> 
> Just present the options, and let the users make up their own minds. You
> don't understand the needs of all of your users. So don't try to solve
> their problems, instead present them with options and let them make up
> their own minds.  I guarantee you that whatever tech you recommend to
> someone, the won't like some aspect of it,  so better to present them with
> all the options and let them choose, then they can only blame themselves if
> it doesn't work out exactly like they expected.
> 
> 
> 
> On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria 
> wrote:
> 
> > I would like to echo the sentiment expressed by several posters in this
> > thread, but with a slight twist. A few years back I picked up Ruby and Ruby
> > on Rails as the language/framework to create a website with moderate
> > complexity and functionality. I did this without any prior experience with
> > the language of framework. What allowed me to quickly pick up both was the
> > excellent documentation around the language and framework. For example,
> > with the information from http://guides.rubyonrails.org and the canonical
> > application built in https://www.railstutorial.org one can acquire the
> > necessary knowledge to develop highly functional websites. Branching out to
> > leverage "non-canonical" libraries/products then becomes a fairly easy
> > exercise (MongoDB instead of MySQL, Mongoid instead of ActiveRecords,
> > etc.). What allows that to happen is the momentum built around the Rails
> > ecosystem via community participation and documentation.
> >
> > We have recently started to build our "back end" infrastructure in
> > Clojure. Many times we have discussed the value and desire to unify our
> > development efforts on and around Clojure. Inevitably we tally up all the
> > functionality inherited from Ruby gems (t

Re: Clojure needs a web framework with more momentum

[Thiago Massa]

My 2 cents:

I don't think the biggest problem is that the community is fragmented as
there is many options to choose, but that the attitude towards newcomers is
bad.

Let's say that I was learning clojure about 2 years ago and when I asked
about which web framework should I use, people started raising stuff about
the implementation of those frameworks like pedestal have some very strange
concepts like this one:

https://github.com/pedestal/docs/blob/master/documentation/application-overview.md

So I was like: WTF. I'm fucked. Forget that. Let's just go back to the
clojure book and write a factorial implementation.

So every once in a while I came back to clojure, did something. Studied
some clojurescript and finally I think that I can write some clojure... but
that took time and I still don't feel good about it. I feel sometimes that
there's a lot of very good people working in Relevance which knows
everything about clojure, but doesn't share anywhere. Maybe if we had a
couple of very good screencasts and proper documentation of how to write a
webapp in clojure available in the web. It could be very optioned(about
what libs to use), it could be even wrong... but getting something done
when you are beginning is way more important than to be concerned about if
you are doing the right thing.

But that might be just me.

On Mon, May 4, 2015 at 3:34 PM, Ernie de Feria 
wrote:

> I would like to echo the sentiment expressed by several posters in this
> thread, but with a slight twist. A few years back I picked up Ruby and Ruby
> on Rails as the language/framework to create a website with moderate
> complexity and functionality. I did this without any prior experience with
> the language of framework. What allowed me to quickly pick up both was the
> excellent documentation around the language and framework. For example,
> with the information from http://guides.rubyonrails.org and the canonical
> application built in https://www.railstutorial.org one can acquire the
> necessary knowledge to develop highly functional websites. Branching out to
> leverage "non-canonical" libraries/products then becomes a fairly easy
> exercise (MongoDB instead of MySQL, Mongoid instead of ActiveRecords,
> etc.). What allows that to happen is the momentum built around the Rails
> ecosystem via community participation and documentation.
>
> We have recently started to build our "back end" infrastructure in
> Clojure. Many times we have discussed the value and desire to unify our
> development efforts on and around Clojure. Inevitably we tally up all the
> functionality inherited from Ruby gems (that play nice with Rails - the
> Framework) that would have to be replicated in Clojure and there always
> shortcomings, not necessarily in the availability of libraries that perform
> these functions, but in the readily accessible documentation about how to
> best integrate them.
>
> The "composable libraries over framework" mantra is technically solid.
> What we're missing, in the "web development with Clojure" subset of the
> community, is the stewardship to create and maintain a canonical
> amalgamation of composable libraries and the best practices around them - a
> la https://railstutorial.org. This would lower the barrier of entry into
> the web development realm for Clojure developers. My 2+ cents.
>
> On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what
>> I found:
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS
>>
>> LuminusClojure28678
>> CaribouClojure 2275
>>
>> BeegoGolang991522
>>
>> PhoenixElixir  1241949
>>
>> YesodHaskell   1303722
>>
>> LaravelPHP2684421
>>
>> PlayScala   4176085
>>
>> SymfonyPHP113020914
>>
>> RailsRuby   269151000
>>
>>
>> One could conclude from this that the Clojure community isn't that
>> interested in web development but the last Clojure survey suggests
>> otherwise. Clojure's library composition approach to everything only
>> goes so far with large web applications, as Aaron Bedra reminded us in
>> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower
>> means less momentum and more bugs. Furthermore, I have a hunch that
>> Clojure's poor adoption as indicated by Indeed.com maybe due to this
>> immaturity in the web framework sphere. Why is it that Elixir, with a
>> much smaller community and lifespan than Clojure's, has managed to put 4
>> times as much mindshare into its main web framework when its module
>> output, as measured by modulecounts.com, is a tiny fraction of
>> Clojure's?
>>
>> gvim
>>
>>
>>
>>
>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to t

Re: Clojure needs a web framework with more momentum

[Sven Richter]

While I totally agree with you on the topic of composing things to solve a 
problem at hand I think you are talking about a different audience here 
than the audience such a "framework" is aiming for.
You are talking about experienced developers that know how to solve 
problems, that know advantages and disadvantages of certain patterns and 
tools.

I think these people can be found in the intermediat to above layer of 
programmer experience. All the rest will be stuck and overwhelmed by the 
choices that are offered (not only in clojure, but in many languages). So 
they are looking for a set of good documentation and an opinionated path to 
a valuable product that fullfills most of their needs.

Several years ago I was happy to find django and be productive in a short 
amount of time without having to think of which templating language to 
choose, but then, like I wrote above, I was hitting a hard edge which led 
me to search more. Still, I finished my project some years, which I may 
have never done without some guidance and the very good documentation of 
the django project.

Best Regards,
Sven

Am Montag, 4. Mai 2015 16:24:22 UTC+2 schrieb tbc++:
>
> The thing that bugs me the most about these sort of conversations about 
> "best practices" is that they often present a set of solutions without 
> first analyzing the problem at hand. 
>
> If I came to this mailing list and asked "I want to write a websever in 
> Clojure..what should I use?". The response would most likely be Ring + 
> Compojure. Okay, not bad options, but that recommendation has been given 
> with absolutely no analysis of what I'm trying to accomplish. What if I 
> need async? What if I need web sockets? What sort of connection load am I 
> expecting? Will my system handle mostly persistent connections (like 
> websockets or SSE), or will it be more canned (and cacheable) data? If 
> someone recommends Ring to me, I may be pigeonholed into some system I'll 
> have to refactor later. Perhaps the best option is Aleph or Pedestal. 
>
> That's the real issue with canned responses like rails tutorial. They 
> assume my needs match your needs and match the needs of most people. That's 
> just not the best way to go about doing software development. And it's a 
> problem I've seen in so many areas of computing. 
>
> I've lost countless hundreds of hours of my life to frameworks that 
> default to bulky serialization formats (like XML or JSON), or frameworks 
> that assume LAN connections to the servers, or frameworks that assume I 
> won't be using multi-threading, or frameworks that assume I won't try to 
> load 10k rows on a single page, or frameworks that assume any number of 
> things. The thing I love the most about the Clojure community is that, more 
> than any other community I've been a part of, they try to ask you to think 
> before you jump. 
>
> So what I would recommend is more of a set of guidelines, and matrices. 
> List all the frameworks/libraries on one axis, and features on another, and 
> start commenting. Make a page like this: (
> http://en.wikipedia.org/wiki/Comparison_of_video_container_formats)
>
> Mention that Ring is well supported by the community, but doesn't work 
> well with fully async servers, mention that Aleph does all the async you 
> need, but is a bit non-standard. Mention that data.json is pure Clojure, 
> but cheshire is most likely faster. 
>
> Just present the options, and let the users make up their own minds. You 
> don't understand the needs of all of your users. So don't try to solve 
> their problems, instead present them with options and let them make up 
> their own minds.  I guarantee you that whatever tech you recommend to 
> someone, the won't like some aspect of it,  so better to present them with 
> all the options and let them choose, then they can only blame themselves if 
> it doesn't work out exactly like they expected. 
>
>  
>
> On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria  > wrote:
>
>> I would like to echo the sentiment expressed by several posters in this 
>> thread, but with a slight twist. A few years back I picked up Ruby and Ruby 
>> on Rails as the language/framework to create a website with moderate 
>> complexity and functionality. I did this without any prior experience with 
>> the language of framework. What allowed me to quickly pick up both was the 
>> excellent documentation around the language and framework. For example, 
>> with the information from http://guides.rubyonrails.org and the 
>> canonical application built in https://www.railstutorial.org one can 
>> acquire the necessary knowledge to develop highly functional websites. 
>> Branching out to leverage "non-canonical" libraries/products then becomes a 
>> fairly easy exercise (MongoDB instead of MySQL, Mongoid instead of 
>> ActiveRecords, etc.). What allows that to happen is the momentum built 
>> around the Rails ecosystem via community participation and documentation. 
>>
>> We have recently started to

Why is Caribou unmaintained ?

[Luc Prefontaine]

Spawned from the other thread about web frameworks.

Can any of the original maintainers answer this one ?

Thank you
Luc P.


--
Luc Prefontaine sent by ibisMail!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Caribou unmaintained ?

[Fluid Dynamics]

On Monday, May 4, 2015 at 10:51:35 AM UTC-4, Luc wrote:
>
> Spawned from the other thread about web frameworks. 
>
> Can any of the original maintainers answer this one ? 
>

According to that same other thread, it has 2 developers on it, not 0. If 
it's feature-complete 2 might easily be sufficient to field the occasional 
bug report. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Christopher Small]

I've been enjoying this thread, but don't currently have the bandwidth to
read everyone's messages and figure out in my head what the distribution of
opinions is or who is on what side of this conversation.

Fortunately, I built a tool for this! It's called pol.is, and it uses real
time data visualization and machine learning to help make sense of large
scale conversations. It falls somewhere between an open ended survey and a
comment thread. Instead of getting more difficult to grok with the number
of people comments, it gets EASIER, because there is more data with which
the ML & stats make magic.

I started a conversation on the state of Web Development in Clojure:
https://pol.is/7scufp.

You don't need to create an account to log in and participate, but if you
connect a social account (twitter, facebook), we can show your avatar and
name where you fall in the conversation, so you can see where everyone else
stands in relation to yourself.

Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)

Chris

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Marcus Blankenship]

Ok, honestly, this is super cool.  Well done!

On May 4, 2015, at 8:19 AM, Christopher Small  wrote:

> I've been enjoying this thread, but don't currently have the bandwidth to 
> read everyone's messages and figure out in my head what the distribution of 
> opinions is or who is on what side of this conversation.
> 
> Fortunately, I built a tool for this! It's called pol.is, and it uses real 
> time data visualization and machine learning to help make sense of large 
> scale conversations. It falls somewhere between an open ended survey and a 
> comment thread. Instead of getting more difficult to grok with the number of 
> people comments, it gets EASIER, because there is more data with which the ML 
> & stats make magic.
> 
> I started a conversation on the state of Web Development in Clojure: 
> https://pol.is/7scufp.
> 
> You don't need to create an account to log in and participate, but if you 
> connect a social account (twitter, facebook), we can show your avatar and 
> name where you fall in the conversation, so you can see where everyone else 
> stands in relation to yourself.
> 
> Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)
> 
> Chris
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Best,
Marcus

Marcus Blankenship
\\\ Technical Coach, Startup Advisor, Calvinist
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Caribou unmaintained ?

[Luc Préfontaine]

There's been no activity since a year ago. This may give the impression that 
it's
dead and maybe it still quite alive.
If people want a framework this one looks to be very complete. It would be 
a shame not to reuse all that brain power.

More feedback ?


> On Monday, May 4, 2015 at 10:51:35 AM UTC-4, Luc wrote:
> >
> > Spawned from the other thread about web frameworks. 
> >
> > Can any of the original maintainers answer this one ? 
> >
> 
> According to that same other thread, it has 2 developers on it, not 0. If 
> it's feature-complete 2 might easily be sufficient to field the occasional 
> bug report. 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
--
Luc Préfontaine sent by ibisMail!

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

juxt/bidi ring question

[clifford]

Hi 

I am using juxt/bidi for route matching. 

with the following routes: 

> (def routes ["/" {"index.html" :index
> "articles/" {"index.html" :article-index
>  [:id] :article}}])


It correctly matches at the REPL.

> (match-route routes "/articles/4") 
> => {:handler :article, :route-params {:id "4"}}


However in the browser, when I hit the url, localhost:3000/articles/4 
It attempts to download a file with name "4", can anybody let me know what 
I'm doing wrong here?

Clifford 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Christopher Small]

Cheers, and thanks :-) It's free, so feel... free to use it :-)

On Mon, May 4, 2015 at 8:28 AM, Marcus Blankenship 
wrote:

> Ok, honestly, this is super cool.  Well done!
>
> On May 4, 2015, at 8:19 AM, Christopher Small 
> wrote:
>
> I've been enjoying this thread, but don't currently have the bandwidth to
> read everyone's messages and figure out in my head what the distribution of
> opinions is or who is on what side of this conversation.
>
> Fortunately, I built a tool for this! It's called pol.is, and it uses
> real time data visualization and machine learning to help make sense of
> large scale conversations. It falls somewhere between an open ended survey
> and a comment thread. Instead of getting more difficult to grok with the
> number of people comments, it gets EASIER, because there is more data with
> which the ML & stats make magic.
>
> I started a conversation on the state of Web Development in Clojure:
> https://pol.is/7scufp.
>
> You don't need to create an account to log in and participate, but if you
> connect a social account (twitter, facebook), we can show your avatar and
> name where you fall in the conversation, so you can see where everyone else
> stands in relation to yourself.
>
> Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)
>
> Chris
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> Best,
> Marcus
>
> Marcus Blankenship
> \\\ Technical Coach, Startup Advisor, Calvinist
> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/tA2_IbU0unE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

I am currently trying to  "redirect-after-post" with validation errors.  I
have already cooked up my way of validating maps.  However, i cant find a
straight forward way for pushing the errors in a 'flash' and then read them
in my template (am currently using freemarker.). I have seen the flash
middleware but it seems to set one flash value.  My solution so far has
been to set cookies and expire them when i read.A framework would
handle this common cases very easily Or am i missing something?

Thanks.

On Mon, May 4, 2015 at 6:34 PM, Christopher Small 
wrote:

> Cheers, and thanks :-) It's free, so feel... free to use it :-)
>
> On Mon, May 4, 2015 at 8:28 AM, Marcus Blankenship 
> wrote:
>
>> Ok, honestly, this is super cool.  Well done!
>>
>> On May 4, 2015, at 8:19 AM, Christopher Small 
>> wrote:
>>
>> I've been enjoying this thread, but don't currently have the bandwidth to
>> read everyone's messages and figure out in my head what the distribution of
>> opinions is or who is on what side of this conversation.
>>
>> Fortunately, I built a tool for this! It's called pol.is, and it uses
>> real time data visualization and machine learning to help make sense of
>> large scale conversations. It falls somewhere between an open ended survey
>> and a comment thread. Instead of getting more difficult to grok with the
>> number of people comments, it gets EASIER, because there is more data with
>> which the ML & stats make magic.
>>
>> I started a conversation on the state of Web Development in Clojure:
>> https://pol.is/7scufp.
>>
>> You don't need to create an account to log in and participate, but if you
>> connect a social account (twitter, facebook), we can show your avatar and
>> name where you fall in the conversation, so you can see where everyone else
>> stands in relation to yourself.
>>
>> Oh, and by the way, the ML engine behind this app is in Clojure. Enjoy :-)
>>
>> Chris
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> Best,
>> Marcus
>>
>> Marcus Blankenship
>> \\\ Technical Coach, Startup Advisor, Calvinist
>> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/tA2_IbU0unE/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+uns

Re: juxt/bidi ring question

[Fluid Dynamics]

On Monday, May 4, 2015 at 11:34:26 AM UTC-4, clifford wrote:
>
> Hi 
>
> I am using juxt/bidi for route matching. 
>
> with the following routes: 
>
>> (def routes ["/" {"index.html" :index
>> "articles/" {"index.html" :article-index
>>  [:id] :article}}])
>
>
> It correctly matches at the REPL.
>
>> (match-route routes "/articles/4") 
>> => {:handler :article, :route-params {:id "4"}}
>
>
> However in the browser, when I hit the url, localhost:3000/articles/4 
> It attempts to download a file with name "4", can anybody let me know what 
> I'm doing wrong here?
>
> Clifford 
>

What is the Content-Type returned by that URL? If it's not text/html and 
the URL doesn't end with ".html" the browser will do that, even if the 
server is in fact responding with the article page. I don't know why the 
Content-Type would be wrong (or missing) though. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: juxt/bidi ring question

[Fluid Dynamics]

On Monday, May 4, 2015 at 11:50:27 AM UTC-4, Fluid Dynamics wrote:
>
> On Monday, May 4, 2015 at 11:34:26 AM UTC-4, clifford wrote:
>>
>> Hi 
>>
>> I am using juxt/bidi for route matching. 
>>
>> with the following routes: 
>>
>>> (def routes ["/" {"index.html" :index
>>> "articles/" {"index.html" :article-index
>>>  [:id] :article}}])
>>
>>
>> It correctly matches at the REPL.
>>
>>> (match-route routes "/articles/4") 
>>> => {:handler :article, :route-params {:id "4"}}
>>
>>
>> However in the browser, when I hit the url, localhost:3000/articles/4 
>> It attempts to download a file with name "4", can anybody let me know 
>> what I'm doing wrong here?
>>
>> Clifford 
>>
>
> What is the Content-Type returned by that URL? If it's not text/html and 
> the URL doesn't end with ".html" the browser will do that, even if the 
> server is in fact responding with the article page. I don't know why the 
> Content-Type would be wrong (or missing) though. 
>

Addendum: you can test easily by saving the "4" file from the browser and 
opening it in Notepad. If it's the HTML of the article numbered 4 then the 
server is mostly working, but not setting Content-Type header appropriately 
on that route. If the file is something else, then something else is wrong. 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure Async/State Machine/Workflow Libraries?

[Tim Visher]

I think I may have summoned the wrong demons when invoking with the 
`Workflow` keyword. :)

I've found some resources on Event-Driven Architecture, mostly from Zach 
Tellman. Is his stuff the main source of that sort of thing?

I realized that prismatic's graph is basically what I'm looking for 
(especially with the addition of async into the model) so long as my edge 
predicates are always based on data availability, since graph is 
essentially what I'm talking about as far as a 'workflow' description where 
you talk about steps, but the transition predicates are implicitly defined 
by data availability, which I think at least models the current problems 
that I have.

Any further thoughts given that new information?

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CFP] JavaOne - Clojure submissions welcomed and recommended

[Ghadi Shayban]

Just as a (final) reminder, the CFP ends Wednesday night!

https://www.oracle.com/javaone/call-for-proposals.html


On Thursday, March 26, 2015 at 2:56:50 PM UTC-4, Ghadi Shayban wrote:
>
> Clojurists,
> The JavaOne conference, a huge gathering, is taking place in San Francisco 
> on October 25-29th.  The Call for Proposals is now open [1], and I 
> encourage you to submit a proposal related to Clojure.  There are many 
> different tracks and session formats available.  Specifically of interest 
> to you though:
>
> *Java and Emerging Languages*
>
> The languages track reviewers will be especially interested in submissions 
> that deal with new thoughts and experiments, rather than the typical 
> "introduction to my cool language" topics. Think, for example, of how the 
> language integrates with other technologies and what it has to offer to the 
> current hot topics in the programming scene.
>
>
> I've seen many wonderful presentations and speakers at previous Clojure 
> conferences, and many things that fit this bill, so propose something!
>
> Please contact speaker-services...@oracle.com (or me) if you have any 
> questions regarding the CFP.
>
> [1] https://www.oracle.com/javaone/call-for-proposals.html#general
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[Sean Grove]

I've been hoping someone would rebuild Codeq
, now that tools.analyzer (and friends)
is out and ClojureScript has made so much progress. Not only would it be
useful for diving into a new codebase (I've needed it several times when
working with a large, unfamiliar codebase), but generating both useful and
interesting docs from the structured data should be far easier than ad-hoc
analysis.

Just a thought, not sure that's the angle you want to take, but didn't see
it on your list and each of the items on the list would probably have
benefited from a revamped, well-documented, well-marketed Codeq.

On Mon, May 4, 2015 at 12:30 AM,  wrote:

> Hi all!
>
> I'm one of this year's students accepted to the Google Summer of Code for
> doing
> a Clojure project. (Thanks to Alex Miller for supporting my application!)
> For
> those who like to decide from the first paragraph whether they will read
> on or
> not: the goal of my project is to develop a model for Clojure source
> metadata
> (most of them are documentation) and ways to capture and publish them. The
> following two paragraphs are taken from my project proposal:
>
>  ❧ To the joy of the community, the number of Clojure-based libraries is
> steadily growing. To the dismay of the community, there is no agreed-upon
> way of
> getting information about those libraries' APIs. We have API documentation
> generators for individual libraries, like Autodoc or Codox. And we have big
> overview sites like Grimoire and CrossClj. None of them are comprehensive.
> All
> provide their information in a human-friendly way. Only some cater for the
> computer.
>
> The goal of this project is to develop a comprehensive and extensible
> model for
> describing Clojure sources from an API perspective. I will also write a
> program
> that analyses Clojure sources according to this model and outputs data
> documenting their usage. This could be compared to Javadoc, but emitting
> data to
> be consumed by other tools instead of HTML. In order to foster adoption, I
> will
> provide extensive  documentation, including examples of such consumer
> tools, and
> emphasize active communication with the community. ☙
>
> The project idea comes from Alex Miller, who also is my mentor, together
> with
> Reid McKenzie. Coding for the GSoC hasn't started yet. – Until 24 April
> we're in
> the warmup phase called community bonding. I wanted to use this time for
> getting
> ideas and feedback from you, so I've prepared some questions as a starting
> point:
>
>  - Who is interested in the project?
> - What would you like to see?
>  - Who has done/thought about similar things?
> - What have you done?
> - How have you done it?
> - What have you found? – Difficulties, annoyances, surprises.
> - What would you like to see?
> - What is important to you?
> - Have you built something that I might reuse?
>  - What else comes to your mind?
>
> There are many things out there which are more or less closely related to
> my
> project:
>
>  - cljs.info: https://github.com/cljsinfo
>  - Autodoc: https://github.com/tomfaulhaber/autodoc
>  - Codox: https://github.com/weavejester/codox
>  - Grimoire: http://conj.io/
>  - CrossClj: https://crossclj.info/
>  - ClojureDocs: https://clojuredocs.org/
>  - Clojure Atlas: http://www.clojureatlas.com/
>
> I would be especially happy to receive input from the people involved in
> those
> efforts.
>
> Reading this might help not having to say things again that have been said
> before: https://groups.google.com/d/topic/clojure/E1oxVE4UMxQ/discussion
>
> I wish everyone a good summer!
>
> Richard
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googleg

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

Not sure what you mean by "one flash value" — I’d expect you to have a map of 
"flash" scope data and that’s the way my FW/1 behaves: you assoc values into 
the "flash scope" and they’re restored on the next request.

On May 4, 2015, at 8:39 AM, Josh Kamau  wrote:
> I am currently trying to  "redirect-after-post" with validation errors.  I 
> have already cooked up my way of validating maps.  However, i cant find a 
> straight forward way for pushing the errors in a 'flash' and then read them 
> in my template (am currently using freemarker.). I have seen the flash 
> middleware but it seems to set one flash value.  My solution so far has been 
> to set cookies and expire them when i read.A framework would handle this 
> common cases very easily Or am i missing something? 


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

Thanks Sean. that makes sense.   I didnt want that map to be stored as one
cookie because it could potentially be big... (there is a 4kb limit per
cookie right?) . I will dig into it and check. If that works for me, then
all i need is compojure, ring and the awesome ring-defaults middleware.  No
need for a monolithic framework.

On Mon, May 4, 2015 at 8:49 PM, Sean Corfield  wrote:

> Not sure what you mean by "one flash value" — I’d expect you to have a map
> of "flash" scope data and that’s the way my FW/1 behaves: you assoc values
> into the "flash scope" and they’re restored on the next request.
>
> On May 4, 2015, at 8:39 AM, Josh Kamau  wrote:
> > I am currently trying to  "redirect-after-post" with validation errors.
> I have already cooked up my way of validating maps.  However, i cant find a
> straight forward way for pushing the errors in a 'flash' and then read them
> in my template (am currently using freemarker.). I have seen the flash
> middleware but it seems to set one flash value.  My solution so far has
> been to set cookies and expire them when i read.A framework would
> handle this common cases very easily Or am i missing something?
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 4, 2015, at 10:53 AM, Josh Kamau  wrote:
> Thanks Sean. that makes sense.   I didnt want that map to be stored as one 
> cookie because it could potentially be big... (there is a 4kb limit per 
> cookie right?) . I will dig into it and check. If that works for me, then all 
> i need is compojure, ring and the awesome ring-defaults middleware.  No need 
> for a monolithic framework.  

Depends on session-store, I believe. If you use in-memory, only the session ID 
is a cookie, the rest is in memory. Or you could use a data store for a 
distributed app (and, again, only the session ID would be a cookie).

Only if your session-store is cookie will everything be stored as a cookie.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Caribou unmaintained ?

[Mark Engelberg]

There was a thread a while back when (if my memory serves me correctly) one
of the creators said the company where Caribou was created is no longer
using Clojure, so he didn't think it was likely that he would be adding new
features, although he would happily address bug reports.

On Mon, May 4, 2015 at 8:29 AM, Luc Préfontaine  wrote:

> There's been no activity since a year ago. This may give the impression
> that it's
> dead and maybe it still quite alive.
> If people want a framework this one looks to be very complete. It would be
> a shame not to reuse all that brain power.
>
> More feedback ?
>
>
> > On Monday, May 4, 2015 at 10:51:35 AM UTC-4, Luc wrote:
> > >
> > > Spawned from the other thread about web frameworks.
> > >
> > > Can any of the original maintainers answer this one ?
> > >
> >
> > According to that same other thread, it has 2 developers on it, not 0. If
> > it's feature-complete 2 might easily be sufficient to field the
> occasional
> > bug report.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> --
> Luc Préfontaine sent by ibisMail!
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

@Sean, i wanted totally stateless backend.

On Mon, May 4, 2015 at 9:02 PM, Sean Corfield  wrote:

> On May 4, 2015, at 10:53 AM, Josh Kamau  wrote:
> > Thanks Sean. that makes sense.   I didnt want that map to be stored as
> one cookie because it could potentially be big... (there is a 4kb limit per
> cookie right?) . I will dig into it and check. If that works for me, then
> all i need is compojure, ring and the awesome ring-defaults middleware.  No
> need for a monolithic framework.
>
> Depends on session-store, I believe. If you use in-memory, only the
> session ID is a cookie, the rest is in memory. Or you could use a data
> store for a distributed app (and, again, only the session ID would be a
> cookie).
>
> Only if your session-store is cookie will everything be stored as a cookie.
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why is Caribou unmaintained ?

[Mark Engelberg]

Found the thread.  It was called "Is Caribou dormant?" and Justin Smith
said:

"I'm one of the core devs of the Caribou project.

Caribou has been less actively developed, but I still use it frequently.

We previously were funded to work on Caribou, but the company funding us
decided to discontinue using Clojure (except for supporting some clients
where Clojure code was deployed). Now we've all moved on to other
employment situations, and I'm the only one actively using Caribou out of
the core team. Bug reports and pull requests will be acknowledged, and
likely acted on. There has been some work quite recently on polaris, our
routing lib."

On Mon, May 4, 2015 at 11:07 AM, Mark Engelberg 
wrote:

> There was a thread a while back when (if my memory serves me correctly)
> one of the creators said the company where Caribou was created is no longer
> using Clojure, so he didn't think it was likely that he would be adding new
> features, although he would happily address bug reports.
>
> On Mon, May 4, 2015 at 8:29 AM, Luc Préfontaine <
> lprefonta...@softaddicts.ca> wrote:
>
>> There's been no activity since a year ago. This may give the impression
>> that it's
>> dead and maybe it still quite alive.
>> If people want a framework this one looks to be very complete. It would be
>> a shame not to reuse all that brain power.
>>
>> More feedback ?
>>
>>
>> > On Monday, May 4, 2015 at 10:51:35 AM UTC-4, Luc wrote:
>> > >
>> > > Spawned from the other thread about web frameworks.
>> > >
>> > > Can any of the original maintainers answer this one ?
>> > >
>> >
>> > According to that same other thread, it has 2 developers on it, not 0.
>> If
>> > it's feature-complete 2 might easily be sufficient to field the
>> occasional
>> > bug report.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clojure@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with
>> your first post.
>> > To unsubscribe from this group, send email to
>> > clojure+unsubscr...@googlegroups.com
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to clojure+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>> --
>> Luc Préfontaine sent by ibisMail!
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 4, 2015, at 11:08 AM, Josh Kamau  wrote:
> @Sean, i wanted totally stateless backend. 

Without a database? :)

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] [Book] ClojureScript Unraveled

[Andrey Antukh]

Hi!

We (my friend Alejandro and I) are happy to announce the first public
version of a ClojureScript book that we are writing.

The book is still a work in progress and many chapters are not available
yet. We are sure that the book has many spelling errors (we are not native
English speakers), so the wording improvements are very very welcome!

This books aims to serve as:

- a comprehensive introduction to the ClojureScript language and its
idiomatic usage, assuming no previous experience with Clojure or functional
programming;
- a detailed guide of the ClojureScript compiler and the tooling around it;
and
- a mixed bag of topics that are useful in day-to-day ClojureScript
programming.

Github: https://github.com/funcool/clojurescript-unraveled
Online version: http://funcool.github.io/clojurescript-unraveled/

Feel free to write any comments or feedback.

Cheers.
Andrey

-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Andrey Antukh]

Yes, without a database, serializing data using JWS or JWE...  I have done
similar thing with buddy-auth stateless backend. It not uses sessions but
the concept is the same.

Cheers.
Andrey

2015-05-04 20:17 GMT+02:00 Sean Corfield :

> On May 4, 2015, at 11:08 AM, Josh Kamau  wrote:
> > @Sean, i wanted totally stateless backend.
>
> Without a database? :)
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Fluid Dynamics]

On Monday, May 4, 2015 at 1:53:30 PM UTC-4, Josh Kamau wrote:
>
> Thanks Sean. that makes sense.   I didnt want that map to be stored as one 
> cookie because it could potentially be big... (there is a 4kb limit per 
> cookie right?) . I will dig into it and check. If that works for me, then 
> all i need is compojure, ring and the awesome ring-defaults middleware.  No 
> need for a monolithic framework.
>

Seems you can solve cookie size issues with a database table with two 
columns, a UUID (PK) and a BLOB with the "real cookie data", and setting a 
client side cookie with the UUID. This may also have security advantages, 
if the user can also be an adversary and shouldn't be able to hand-modify 
some things in the "real cookie data". (E.g. multiplayer online game, don't 
store any data clientside that the client can (decrypt and) alter 
unilaterally where such a capability would enable some sort of cheating. 
Keep the data, or at least the decryption key, on the server.)

Note that some databases perform more poorly with UUID PKs than with 
autoincrement PKs; however, autoincrement PKs have a severe security 
problem in this context, in that a user can predict valid keys other than 
their own and doctor their cookie to potentially view another user's data. 
There have been a number of notorious breaches that resulted from using 
predictably sequential numbers in cookies, URL query parameters, and 
similar things without any further authentication than "client knew the 
number".

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] [Book] ClojureScript Unraveled

[Angel Java Lopez]

Great work!

I really appreciate
http://funcool.github.io/clojurescript-unraveled/#tooling-compiler

Now, I started to understand the compiler process

Angel "Java" Lopez
@ajlopez


On Mon, May 4, 2015 at 3:20 PM, Andrey Antukh  wrote:

> Hi!
>
> We (my friend Alejandro and I) are happy to announce the first public
> version of a ClojureScript book that we are writing.
>
> The book is still a work in progress and many chapters are not available
> yet. We are sure that the book has many spelling errors (we are not native
> English speakers), so the wording improvements are very very welcome!
>
> This books aims to serve as:
>
> - a comprehensive introduction to the ClojureScript language and its
> idiomatic usage, assuming no previous experience with Clojure or functional
> programming;
> - a detailed guide of the ClojureScript compiler and the tooling around
> it; and
> - a mixed bag of topics that are useful in day-to-day ClojureScript
> programming.
>
> Github: https://github.com/funcool/clojurescript-unraveled
> Online version: http://funcool.github.io/clojurescript-unraveled/
>
> Feel free to write any comments or feedback.
>
> Cheers.
> Andrey
>
> --
> Andrey Antukh - Андрей Антух -  / <
> n...@niwi.be>
> http://www.niwi.be 
> https://github.com/niwibe
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Gregg Reynolds]

On May 4, 2015 7:16 AM, "Eric MacAdie"  wrote:
>
> I think what Clojure needs is a default. It doesn't matter if it is a
"web framework" like Rails, or "libraries strung together" like Luminus.
>

What Clojure needs is, well nothing. What the market MAY need is an
entrepreneur who will produce the framework the OP craves.  No takers so
far.  Conclusion: not a genuine unmet need.   But in the long run simple
economics say the Clojure approach will win.  You can't make your product
stand out by using the same framework everybody else uses.  The inevitable
trend, driven by basic economics, is toward bespoke stuff, which is where
Clojure excels.  My guess is that over the next 2-3 years we will see some
clojure frameworks emerge but they will not be like "traditional"
frameworks.  They'll be infinitely and easily customizable because they
wont force choices-they'll just make the easy stuff not only easy but
flexible. My 2 cents.

> When a Ruby newbie asks how to make a web app, the default answer is to
look at Rails. In Python, the default answer is Django. Compared to that,
the default answer in Clojure to do it yourself can sound like "go jump off
a cliff".
>
> = Eric MacAdie
>
>
> On Mon, May 4, 2015 at 7:09 AM, Sean Johnson  wrote:
>>
>>
>>
>> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
>>
>>> All in all this is basically the direction I want to go with closp and
closp-crud. The intention is not to have a webframework, but to automatize
steps that need to be done manually otherwise.
>>
>>
>> One potential problem with this "web framework" as app template approach
is upgrade-ability.  When 2.0 of your "framework" comes out, what happens
to an app generated from 1.0 that wants to benefit from the new
capabilities?
>>
>> It's not a showstopper to the approach. It's just something to think
hard about. I've taken a couple of long lived Rails apps from Rails 1 to
Rails 4 and while there have been breaking changes with each major version
change (and some minor versions) in general it's pretty easy to keep up
with the latest versions and there are copious docs (even whole ebooks in
some cases) to walk developers through the changes.
>>
>> Cheers,
>> Sean
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google
Groups "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
"Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: juxt/bidi ring question

[clifford]

Thanks @fluiddynamics your right on the money.

On Monday, 4 May 2015 17:34:26 UTC+2, clifford wrote:
>
> Hi 
>
> I am using juxt/bidi for route matching. 
>
> with the following routes: 
>
>> (def routes ["/" {"index.html" :index
>> "articles/" {"index.html" :article-index
>>  [:id] :article}}])
>
>
> It correctly matches at the REPL.
>
>> (match-route routes "/articles/4") 
>> => {:handler :article, :route-params {:id "4"}}
>
>
> However in the browser, when I hit the url, localhost:3000/articles/4 
> It attempts to download a file with name "4", can anybody let me know what 
> I'm doing wrong here?
>
> Clifford 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: juxt/bidi ring question

[Fluid Dynamics]

On Monday, May 4, 2015 at 3:21:19 PM UTC-4, clifford wrote:
>
> Thanks @fluiddynamics your right on the money.
>
> On Monday, 4 May 2015 17:34:26 UTC+2, clifford wrote:
>>
>> Hi 
>>
>> I am using juxt/bidi for route matching. 
>>
>> with the following routes: 
>>
>>> (def routes ["/" {"index.html" :index
>>> "articles/" {"index.html" :article-index
>>>  [:id] :article}}])
>>
>>
>> It correctly matches at the REPL.
>>
>>> (match-route routes "/articles/4") 
>>> => {:handler :article, :route-params {:id "4"}}
>>
>>
>> However in the browser, when I hit the url, localhost:3000/articles/4 
>> It attempts to download a file with name "4", can anybody let me know 
>> what I'm doing wrong here?
>>
>> Clifford 
>>
>
YW. Now, just to satisfy the curious (and maybe help anyone else who runs 
into a similar problem): what was causing the Content-Type not to be 
correct? 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ClojureScript] [ANN] [Book] ClojureScript Unraveled

[Marc Fawzi]

such an awesome effort!

thank you Andrey & Alejandro!

+starred +watched +favorited +retweeted :)

On Mon, May 4, 2015 at 11:20 AM, Andrey Antukh  wrote:

> Hi!
>
> We (my friend Alejandro and I) are happy to announce the first public
> version of a ClojureScript book that we are writing.
>
> The book is still a work in progress and many chapters are not available
> yet. We are sure that the book has many spelling errors (we are not native
> English speakers), so the wording improvements are very very welcome!
>
> This books aims to serve as:
>
> - a comprehensive introduction to the ClojureScript language and its
> idiomatic usage, assuming no previous experience with Clojure or functional
> programming;
> - a detailed guide of the ClojureScript compiler and the tooling around
> it; and
> - a mixed bag of topics that are useful in day-to-day ClojureScript
> programming.
>
> Github: https://github.com/funcool/clojurescript-unraveled
> Online version: http://funcool.github.io/clojurescript-unraveled/
>
> Feel free to write any comments or feedback.
>
> Cheers.
> Andrey
>
> --
> Andrey Antukh - Андрей Антух -  / <
> n...@niwi.be>
> http://www.niwi.be 
> https://github.com/niwibe
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I wrote a functional Lisp in Clojure. Come have a look

[eduardoejp]

The language is called Lux and it's inspired by Clojure, Haskell & ML

https://github.com/LuxLang/lux

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I wrote a functional Lisp in Clojure. Come have a look

[Raoul Duke]

re: lux -- keen! also, check out http://shenlanguage.org/, it has a
clojure target in the works.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: I wrote a functional Lisp in Clojure. Come have a look

[eduardoejp]

Shen is definitely a language I'm checking out!

It's sequent-calculus approach to types is really innovative and I'm a fan 
of the work of Dr. Mark Tarver.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A more flexible versio of -> ?

[Kaiyin Zhong]

Wouldn't be nice to have something like:

(->>> thing 
  (f1 ph arg2 arg3)
  (f2 arg1 ph arg3)
  (f3 arg1 arg2 ph))

;; ph is a place holder for thing

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Robert Levy]

I tend to agree with this Gregg.  Either it's a solution in search of a
need, or it's a legitimate need but no one has produced something
compelling enough that a critical mass (or even a small contingent) has
picked up on and said "yes, this feels like a significant improvement over à
la carte pieces".

Another thing worth mentioning that I don't see already mentioned is the
case for a web framework from a security perspective:
https://www.youtube.com/watch?v=CBL59w7fXw4 Having a lot of different
pieces without standard ways of putting them together can introduce
vulnerabilities that would not exist using an integrated framework.

On Mon, May 4, 2015 at 11:59 AM, Gregg Reynolds  wrote:

>
> On May 4, 2015 7:16 AM, "Eric MacAdie"  wrote:
> >
> > I think what Clojure needs is a default. It doesn't matter if it is a
> "web framework" like Rails, or "libraries strung together" like Luminus.
> >
>
> What Clojure needs is, well nothing. What the market MAY need is an
> entrepreneur who will produce the framework the OP craves.  No takers so
> far.  Conclusion: not a genuine unmet need.   But in the long run simple
> economics say the Clojure approach will win.  You can't make your product
> stand out by using the same framework everybody else uses.  The inevitable
> trend, driven by basic economics, is toward bespoke stuff, which is where
> Clojure excels.  My guess is that over the next 2-3 years we will see some
> clojure frameworks emerge but they will not be like "traditional"
> frameworks.  They'll be infinitely and easily customizable because they
> wont force choices-they'll just make the easy stuff not only easy but
> flexible. My 2 cents.
>
> > When a Ruby newbie asks how to make a web app, the default answer is to
> look at Rails. In Python, the default answer is Django. Compared to that,
> the default answer in Clojure to do it yourself can sound like "go jump off
> a cliff".
> >
> > = Eric MacAdie
> >
> >
> > On Mon, May 4, 2015 at 7:09 AM, Sean Johnson  wrote:
> >>
> >>
> >>
> >> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
> >>
> >>> All in all this is basically the direction I want to go with closp and
> closp-crud. The intention is not to have a webframework, but to automatize
> steps that need to be done manually otherwise.
> >>
> >>
> >> One potential problem with this "web framework" as app template
> approach is upgrade-ability.  When 2.0 of your "framework" comes out, what
> happens to an app generated from 1.0 that wants to benefit from the new
> capabilities?
> >>
> >> It's not a showstopper to the approach. It's just something to think
> hard about. I've taken a couple of long lived Rails apps from Rails 1 to
> Rails 4 and while there have been breaking changes with each major version
> change (and some minor versions) in general it's pretty easy to keep up
> with the latest versions and there are copious docs (even whole ebooks in
> some cases) to walk developers through the changes.
> >>
> >> Cheers,
> >> Sean
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you 

Re: A more flexible versio of -> ?

[Timothy Baldridge]

https://clojuredocs.org/clojure.core/as-%3E

On Mon, May 4, 2015 at 2:46 PM, Kaiyin Zhong  wrote:

> Wouldn't be nice to have something like:
>
> (->>> thing
>   (f1 ph arg2 arg3)
>   (f2 arg1 ph arg3)
>   (f3 arg1 arg2 ph))
>
> ;; ph is a place holder for thing
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Josh Kamau]

Another challenge is: There are alot of abandoned libraries and few reach
1.0. That makes selecting the libraries to compose abit difficult.

On Mon, May 4, 2015 at 9:59 PM, Gregg Reynolds  wrote:

>
> On May 4, 2015 7:16 AM, "Eric MacAdie"  wrote:
> >
> > I think what Clojure needs is a default. It doesn't matter if it is a
> "web framework" like Rails, or "libraries strung together" like Luminus.
> >
>
> What Clojure needs is, well nothing. What the market MAY need is an
> entrepreneur who will produce the framework the OP craves.  No takers so
> far.  Conclusion: not a genuine unmet need.   But in the long run simple
> economics say the Clojure approach will win.  You can't make your product
> stand out by using the same framework everybody else uses.  The inevitable
> trend, driven by basic economics, is toward bespoke stuff, which is where
> Clojure excels.  My guess is that over the next 2-3 years we will see some
> clojure frameworks emerge but they will not be like "traditional"
> frameworks.  They'll be infinitely and easily customizable because they
> wont force choices-they'll just make the easy stuff not only easy but
> flexible. My 2 cents.
>
> > When a Ruby newbie asks how to make a web app, the default answer is to
> look at Rails. In Python, the default answer is Django. Compared to that,
> the default answer in Clojure to do it yourself can sound like "go jump off
> a cliff".
> >
> > = Eric MacAdie
> >
> >
> > On Mon, May 4, 2015 at 7:09 AM, Sean Johnson  wrote:
> >>
> >>
> >>
> >> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
> >>
> >>> All in all this is basically the direction I want to go with closp and
> closp-crud. The intention is not to have a webframework, but to automatize
> steps that need to be done manually otherwise.
> >>
> >>
> >> One potential problem with this "web framework" as app template
> approach is upgrade-ability.  When 2.0 of your "framework" comes out, what
> happens to an app generated from 1.0 that wants to benefit from the new
> capabilities?
> >>
> >> It's not a showstopper to the approach. It's just something to think
> hard about. I've taken a couple of long lived Rails apps from Rails 1 to
> Rails 4 and while there have been breaking changes with each major version
> change (and some minor versions) in general it's pretty easy to keep up
> with the latest versions and there are copious docs (even whole ebooks in
> some cases) to walk developers through the changes.
> >>
> >> Cheers,
> >> Sean
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with
> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsu

Re: Clojure needs a web framework with more momentum

[blake]

I went from Ruby to Clojure in short-order and while I struggled mightily
with the functional aspect (after assiduously avoiding those concepts for
years), I much prefer every aspect of Clojure web programming to Rails.

The bible of rails programming is the Hartl book. In the edition I read,
before you got to any actual programming, you were introduced to
14—fourteen! I counted!—different domains, including things like RSpec and
Cucumber. And it was all treated with this, "Well, you can figure out what
this all does because, hey, it looks just like English" attitude, with a
patina of "you don't need to know what's going on under the covers".

The advantage of having an opinionated framework is that it saves one the
effort of having to make up one's own mind. This means you're trusting
someone with literally no understanding of your problem domain to make up
your mind for you. It's sort of amazing that this works at all, and that
there aren't =more= vulnerabilities turning up like the Rails XML hack.
​
This made me really uncomfortable with Rails.

My current Clojure web app is more sophisticated than anything I did with
Rails, though my Rails apps doubtless carried far more untapped potential.
But I know just about exactly what it does. I know because I added each
piece of middleware as I needed it, and this allowed me to understand what
going on. I needed access to Mongo and MS-SQL, so I added those. I needed a
front-end so I started with Hiccup, which is "obvious" (and remarkably
similar to Smalltalk's Seaside, which I've used), and then added in some
Javascript.

I'll turn the Javascript into Clojurescript, but I felt that was too much
to absorb at once. And unlike Rails, I didn't need to absorb every hot
library du jour to get going. (And damned if in Rails, each tutorial has a
different idea of which libraries are essential.)

Then I added authentication, and threading (which was ridiculously easy),
and so on. Each piece as needed, with an understanding of what was going
on. Now, I don't get ALL of it. But I know where my weaknesses are. I have,
now, an opinionated framework, but it's made of =my= opinions. And I made
those opinions by looking at what the libraries I'm using did, which is way
simpler in a shallow functional world than in an object-drill-down world.

In Rails, you don't know what you don't know.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 21:48, Robert Levy wrote:

Another thing worth mentioning that I don't see already mentioned is the
case for a web framework from a security perspective:
https://www.youtube.com/watch?v=CBL59w7fXw4 Having a lot of different
pieces without standard ways of putting them together can introduce
vulnerabilities that would not exist using an integrated framework.



See the first message in the thread. That was one of my concerns.

gvim

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 23:17, blake wrote:

I went from Ruby to Clojure in short-order and while I struggled
mightily with the functional aspect (after assiduously avoiding those
concepts for years), I much prefer every aspect of Clojure web
programming to Rails.

The bible of rails programming is the Hartl book. In the edition I read,
before you got to any actual programming, you were introduced to
14—fourteen! I counted!—different domains, including things like RSpec
and Cucumber. And it was all treated with this, "Well, you can figure
out what this all does because, hey, it looks just like English"
attitude, with a patina of "you don't need to know what's going on under
the covers".

The advantage of having an opinionated framework is that it saves one
the effort of having to make up one's own mind. This means you're
trusting someone with literally no understanding of your problem domain
to make up your mind for you. It's sort of amazing that this works at
all, and that there aren't =more= vulnerabilities turning up like the
Rails XML hack.
​
This made me really uncomfortable with Rails.

My current Clojure web app is more sophisticated than anything I did
with Rails, though my Rails apps doubtless carried far more untapped
potential. But I know just about exactly what it does. I know because I
added each piece of middleware as I needed it, and this allowed me to
understand what going on. I needed access to Mongo and MS-SQL, so I
added those. I needed a front-end so I started with Hiccup, which is
"obvious" (and remarkably similar to Smalltalk's Seaside, which I've
used), and then added in some Javascript.

I'll turn the Javascript into Clojurescript, but I felt that was too
much to absorb at once. And unlike Rails, I didn't need to absorb every
hot library du jour to get going. (And damned if in Rails, each tutorial
has a different idea of which libraries are essential.)

Then I added authentication, and threading (which was ridiculously
easy), and so on. Each piece as needed, with an understanding of what
was going on. Now, I don't get ALL of it. But I know where my weaknesses
are. I have, now, an opinionated framework, but it's made of =my=
opinions. And I made those opinions by looking at what the libraries I'm
using did, which is way simpler in a shallow functional world than in an
object-drill-down world.

In Rails, you don't know what you don't know.



Do the advantages you've pointed out apply to teamwork, though? That's 
supposed to be where frameworks make life easier.


gvim





--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Raoul Duke]

>> vulnerabilities that would not exist using an integrated framework.

fwiw, web + security always makes me think of http://liftweb.net/

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[gvim]

On 04/05/2015 23:49, Raoul Duke wrote:

vulnerabilities that would not exist using an integrated framework.


fwiw, web + security always makes me think of http://liftweb.net/



Can you elaborate? Lift got it right or was a disaster?

gvim

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Raoul Duke]

> Can you elaborate? Lift got it right or was a disaster?

oh! good question, sorry :-)

i believe it got it far more right than wrong.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[gvim]

On 05/05/2015 00:03, Raoul Duke wrote:

Can you elaborate? Lift got it right or was a disaster?


oh! good question, sorry :-)

i believe it got it far more right than wrong.



I've been pretty impressed with Scala's main framework, Play 2. There 
seems to be a lot of momentum behind their Typesafe Reactive Platform 
and, like Rails, plenty of resources to get new users up to speed.


gvim

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Sean Corfield]

On May 4, 2015, at 4:10 PM, gvim  wrote:
> I've been pretty impressed with Scala's main framework, Play 2. There seems 
> to be a lot of momentum behind their Typesafe Reactive Platform and, like 
> Rails, plenty of resources to get new users up to speed.

Yes, Play has overtaken Lift, not because it is necessarily better, but because 
TypeSafe are pouring marketing dollars into it, as part of their drive to 
encourage Enterprise uptake of Scala. They have a vested interest in Play being 
very successful as it will drive more business for them.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Kyle Cordes]

 
On May 4, 2015 at 3:51:23 PM, Josh Kamau 
(joshnet2...@gmail.com(mailto:joshnet2...@gmail.com)) wrote:
> Another challenge is: There are alot of abandoned libraries and few reach 
> 1.0. That makes selecting the libraries to compose abit difficult.  


I think this is a key source of trouble. There are so many things to choose 
from, yet so few of them are “done”.

I’ve thought about why this might be. Here is my theory, it is an accidental 
result of reasonable people doing reasonable things. I think the typical 
software developer contributing to open source is a reasonably nice person; 
unpleasant people generally don’t do a bunch of hard work and give away the 
results of their work. But being inclined to be nice can easily lead to this 
endless series of new incomplete projects.

The path is by this dynamic. Imagine friendly developer X wants to solve a 
problem. They look around and find various incomplete solutions to that 
problem. Now they have a choice: do I contribute to one of those existing 
solutions, or do I start my own? Aside from the natural tendency of many of us 
to want to solve problems our own way, I believe there is a social reason also 
pointing people in this direction. There are too many obvious downsides to 
contributing to someone’s existing, partly complete solution:

* Looking at the incomplete project, you wonder, what is left to be done? But 
the person who didn’t have time to finish it, probably also didn’t have time to 
write much about what was still to be done, nor to carefully maintain a list of 
open issues.

* Perhaps you go farther, and make a bunch of local edits. Do you offer these 
is a pull request? Perhaps, but a pull request whose contents are “replace a 
bunch of stuff in this project with my new stuff instead” could certainly be 
seen as not very nice, so perhaps better to just keep quiet about such a 
branch, and not push it, Not submit a pull request.

* Perhaps you want to just urge the existing project in a good direction. You 
find that the issue tracker has a little activity, and the issues already there 
aren’t getting much attention. Is it rational to spend time adding another? 
Probably not. Is it nice, and polite, to add more issues asking for activity 
from someone who obviously has no time to give it? No it is not, so perhaps 
better to just move on to the next project.

* Perhaps you have rather a lot of time, enough time to fork the project and 
drive it to completion. Do you fork? While there are several reasons not to 
fork. Firstly, it could be perceived as unfriendly. Secondly, even if your fork 
is spectacular, on the website where much of the open source ecosystem lives 
(GitHub), forks more or less perpetually appear a second class citizens. There 
is no good way, even if you look at the graph showing off forks, to figure out 
if the community has moved on to some particular fork. The starting point 
project seems forever the main one, even if it is abandoned. So perhaps it is 
better to not forget all.

* Now we’re left with the default position, just starting a fresh new project 
to solve the same problem. But quite often, the hypothetical friendly developer 
in this position does not have enough time to drive their fresh new solution to 
completion either.

Net result: over time we accumulate more and more projects, solving overlapping 
problems, a great many of them never getting close to 1.0.

While this all sounds pretty negative, but I think the factors here are 
actually overwhelmed by the large number of really smart people contributing 
stuff out there. I can mostly find that I look around and am able to solve 
whatever problems I have, often building on the good work of others. But I also 
find that I often pass on an opportunity to push some project closer to 
completion, for the reasons above.




--  
Kyle Cordes
http://kylecordes.com  


-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN, GSoC] A Common Clojure Source Metadata Model

[richard . moehn]

Am Dienstag, 5. Mai 2015 01:56:13 UTC+9 schrieb Sean Grove:
>
> I've been hoping someone would rebuild Codeq 
> , now that tools.analyzer (and friends) 
> is out and ClojureScript has made so much progress. Not only would it be 
> useful for diving into a new codebase (I've needed it several times when 
> working with a large, unfamiliar codebase), but generating both useful and 
> interesting docs from the structured data should be far easier than ad-hoc 
> analysis.
>
> Just a thought, not sure that's the angle you want to take, but didn't see 
> it on your list and each of the items on the list would probably have 
> benefited from a revamped, well-documented, well-marketed Codeq.
>

Oh, Codeq! I heard about it a long time ago on the Cognicast and it has 
been hopping across my mind now and then. I would also like it to come to 
life again. While it's not quite in the scope of my project, I think it 
could be one of the tools that can be (re)built on top of the metadata from 
my project. Maybe I'm remembering Codeq wrong, but I think it could "just" 
be recording the changes/snapshots of metadata according to my model over 
time by feeding them into Datomic.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Raoul Duke]

> Yes, Play has overtaken Lift, not because it is necessarily better, but 
> because TypeSafe are pouring marketing dollars into it, as part of their 
> drive to encourage Enterprise uptake of Scala. They have a vested interest in 
> Play being very successful as it will drive more business for them.


of course, there are folks who say Typesafe wears no clothes.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A more flexible versio of -> ?

[Daniel]

https://github.com/rplevy/swiss-arrows

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Embedded systems and transpiling Clojure to Nim

[Alan Moore]

All,

Looks like I have some more research to do... A year or so ago I looked
into going the Python/PyPy route but it's PPC support had previously
stalled. I was intrigued by it's interpreter/tracing JIT structure.

It seems to me that there would be a huge win, similar to the Clojure/JVM,
ClojureScript/Javascript bump, for targeting Python. This would allow
Clojure to integrate with many libraries for devops, big data, scientific
and non-traditional IT communities. Pixie looks pretty nice - maybe that
will work. TBD.

I think I'd prefer to stay with the Clojure dialect rather than CL/others,
partly because I am used to Clojure and partly because one of my use cases
requires the same exact code running in an embedded system and in the
browser, e.g. don't want to maintain separate versions of key algorithms.

Herwig - I like your suggestion re: rclojure. That seems like a harder but
more fruitful approach than other porting options. Do you have any
references to this kind of approach in other languages?

Fergal - I agree, many IoT projects are targeting Javascript which could
obviously use ClojureScript. I've been looking at the duktape javascript
library (supported by the AllSeen Alliance) but have yet to try it out on
our target or running ClojureScript generated code. I will also look
at Elixir.

Thanks for the feedback everyone. If anyone is interested in taking this
topic offline so as not to spam this group with our corner case, let's use
Chris' chat as a point of contact (if he doesn't mind):

For those who missed his link, here it is:

https://gitter.im/clj-bots/chat

See you over there.

Alan

On Mon, May 4, 2015 at 1:25 AM, adrians  wrote:

> Alan, have you looked at Clasp? I'm not sure if CL is something you like,
> but maybe it has potential for your application.
>
> https://github.com/drmeister/clasp
>
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
*"Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now."* - *Goethe*

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> And never has this author proven that programmers with bipolar 
personality are 
> programming more LISP then other languages. 

It's a metaphor. The author is not actually diagnosing Lisp programmers 
with bipolar disorder. The metaphor offers an image of a particular kind of 
student who starts stuff but doesn't finish stuff. 




On Sunday, May 3, 2015 at 2:52:22 PM UTC-4, Leon Grapenthin wrote:
>
> No, it isn't. And never has this author proven that programmers with 
> bipolar personality are programming more LISP then other languages. 
>
> Many larger libraries in the Clojure community are well documented and 
> "finished-off properly".
>
> Web frameworks have been tried and not been picked up. Users have chosen 
> the modular compose it yourself approach. Framework authors have simply 
> stopped maintaining what nobody wanted anyway or split them up into smaller 
> pieces. 
>
>
> On Sunday, May 3, 2015 at 8:25:22 PM UTC+2, larry google groups wrote:
>>
>>
>> > The web development industry as reflected in job postings at 
>> > Indeed.co.uk is still dominated by the likes of Rails, Django, 
>> Laravel, 
>> > Zend, Symfony & Spring so I'm not sure how you've concluded that 
>> there's 
>> > been a 15-year trend towards composition. 
>>
>> That is a good point, though I would also point out that, according to 
>> Indeed.com, the use of Clojure is also growing. To me, what's important is 
>> the growth of the Clojure community, rather than the growth of some 
>> sub-community focused on a particular niche. 
>>
>> However, I acknowledge you may have a point about the failure of any of 
>> the Clojure frameworks to take off. It's possible this is another 
>> manifestation of the Bipolar Programmer problem: 
>>
>> http://www.lambdassociates.org/blog/bipolar.htm
>>
>> "Brilliance and failure are so often mixed together and our initial 
>> reaction is it shouldn't be.   But it happens and it happens a lot.  Why? 
>> ...But brilliance is not enough.  You need application too, because the 
>> material is harder at university.   So pretty soon our man is getting B+, 
>> then Bs and then Cs for his assignments.   He experiences alternating 
>> feelings of failure cutting through his usual self assurance.  He can still 
>> stay up to 5.00AM and hand in his assignment before the 9.00AM deadline, 
>> but what he hands in is not so great.
>>
>> ...So BBMs love Lisp.  And the stunning originality of Lisp is reflective 
>> of the creativity of the BBM; so we have a long list of ideas that 
>> originated with Lispers - garbage collection, list handling, personal 
>> computing, windowing and areas in which Lisp people were amongst the 
>> earliest pioneers.  So we would think, off the cuff, that Lisp should be 
>> well established, the premiere programming language because hey - its great 
>> and we were the first guys to do this stuff.
>>
>> But it isn't and the reasons why not are not in the language, but in the 
>> community itself, which contains not just the strengths but also the 
>> weaknesses of the BBM.
>>
>> One of these is the inability to finish things off properly.  The phrase 
>> 'throw-away design' is absolutely made for the BBM and it comes from the 
>> Lisp community.   Lisp allows you to just chuck things off so easily, and 
>> it is easy to take this for granted.  I saw this 10 years ago when looking 
>> for a GUI to my Lisp (Garnet had just gone West then).  No problem, there 
>> were 9 different offerings.  The trouble was that none of the 9 were 
>> properly documented and none were bug free. Basically each person had 
>> implemented his own solution and it worked for him so that was fine.   This 
>> is a BBM attitude; it works for me and I understand it.   It is also the 
>> product of not needing or wanting anybody else's help to do something."
>>
>>
>>
>>
>>
>> On Sunday, May 3, 2015 at 9:51:15 AM UTC-4, g vim wrote:
>>>
>>> On 03/05/2015 14:39, larry google groups wrote: 
>>> > The industry has been moving against frameworks for 15 years now. The 
>>> > peak of the monolithic framework craze was Struts, back in 2000. After 
>>> > that, people started craving something less bloated. That's why the 
>>> > whole industry was so excited when Rails emerged in 2004. Bruce Eckel 
>>> > summed up the sudden change of mood in his essay "The departure of the 
>>> > hyper-enthusiasts": 
>>> > 
>>> > http://www.artima.com/weblogs/viewpost.jsp?thread=141312 
>>> > 
>>> > But after awhile, people began to feel that even Rails was bloated, 
>>> > which lead to the emergence of micro-frameworks like Sinatra. 
>>> > 
>>> > And then, continuing with the trend, we've seen the emergence of 
>>> > eco-systems, such as Clojure, that allow the trend to go further: 
>>> > Clojure supports such high levels composition that frameworks are no 
>>> > longer needed. And this is the direction the industry has been moving 
>>> > for the last 15 years. Clojure is simply out in front. Most languages 
>>> > don't allow this lev

Re: Clojure needs a web framework with more momentum

[larry google groups]

> While I agree that g vim's metrics aren't terribly meaningful, the 
conclusion he's arriving at is an important one. 

I think g vim's metrics have some impact with management. Certainly, its 
worth talking about. A few months ago I was talking to the woman at the New 
York Times who overseas the NYT store, and they had decided to go with PHP 
because it had the Magento shopping cart. Personally, I think Magento is an 
abomination, but Clojure would have been a tough sell there since it has no 
shopping cart app on Github. 





On Sunday, May 3, 2015 at 8:03:43 PM UTC-4, James Reeves wrote:
>
> On 4 May 2015 at 00:51, Jason Whitlark > 
> wrote:
>>
>> While I agree that g vim's metrics aren't terribly meaningful, the 
>> conclusion he's arriving at is an important one.  I've heavily used Clojure 
>> in production for years, and there have been a number of times where having 
>> to hand assemble everything cost lots of support from other engineers.  
>> Luminus is an improvement, but doesn't always generate correct code for 
>> specific sets of options, and is tricky to extend.
>>
>
> I don't disagree. Improving code generation was my motivation for writing 
> lein-generate, and my partial motivation for cljfmt.
>
> - James
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Embedded systems and transpiling Clojure to Nim

[Christopher Small]

Using clj-bots/chat is fine with me. If there ends up being much noise with
respect to this specific native compilation thread vs the project as a
whole, we can set up another gitter channel.

Cheers

On Mon, May 4, 2015 at 5:04 PM, Alan Moore 
wrote:

> All,
>
> Looks like I have some more research to do... A year or so ago I looked
> into going the Python/PyPy route but it's PPC support had previously
> stalled. I was intrigued by it's interpreter/tracing JIT structure.
>
> It seems to me that there would be a huge win, similar to the Clojure/JVM,
> ClojureScript/Javascript bump, for targeting Python. This would allow
> Clojure to integrate with many libraries for devops, big data, scientific
> and non-traditional IT communities. Pixie looks pretty nice - maybe that
> will work. TBD.
>
> I think I'd prefer to stay with the Clojure dialect rather than CL/others,
> partly because I am used to Clojure and partly because one of my use cases
> requires the same exact code running in an embedded system and in the
> browser, e.g. don't want to maintain separate versions of key algorithms.
>
> Herwig - I like your suggestion re: rclojure. That seems like a harder
> but more fruitful approach than other porting options. Do you have any
> references to this kind of approach in other languages?
>
> Fergal - I agree, many IoT projects are targeting Javascript which could
> obviously use ClojureScript. I've been looking at the duktape javascript
> library (supported by the AllSeen Alliance) but have yet to try it out on
> our target or running ClojureScript generated code. I will also look
> at Elixir.
>
> Thanks for the feedback everyone. If anyone is interested in taking this
> topic offline so as not to spam this group with our corner case, let's use
> Chris' chat as a point of contact (if he doesn't mind):
>
> For those who missed his link, here it is:
>
> https://gitter.im/clj-bots/chat
>
> See you over there.
>
> Alan
>
> On Mon, May 4, 2015 at 1:25 AM, adrians  wrote:
>
>> Alan, have you looked at Clasp? I'm not sure if CL is something you like,
>> but maybe it has potential for your application.
>>
>> https://github.com/drmeister/clasp
>>
>>
>>  --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> --
> *"Whatever you can do, or dream you can do, begin it. Boldness has genius,
> power, and magic in it. Begin it now."* - *Goethe*
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> Someone earlier in the thread wrote about how Ruby was the abstraction in 
contrast to PHP where libraries 
> were tied to a framework. I've never worked with Rails seriously, but I 
find it hard to believe that libraries 
> such as shopping carts intended for Rails will work out of the box with 
some other framework - is this the
> case? The ones I looked at (admittedly briefly and some time ago) were 
all Rails-specific.

I made that comment earlier. I am curious what gem is specific to Rails? 
Maybe something specific to RailTies? I am imagine you can find a few if 
you try, but I think they are rare. Stuff like ActiveRecord is not specific 
to Rails -- you can use ActiveRecord with Sinatra, or any other Ruby web 
framework. The same goes for Device (authentication) CanCan (authorization) 
and any of the HTML template languages that you can think of (too many to 
list). Middleware is handled by Rack. So you've got an ORM and HTML 
templates and authentication and authorization and all of that is general 
to Ruby, not to Rails. That is in contrast to PHP where the plugins are 
specific to particular frameworks. 

To my way of thinking, Ruby is better than PHP exactly because it allows a 
higher level of composability  and Clojure is better than Ruby because it 
allows a higher level of composability than Ruby. 



On Monday, May 4, 2015 at 5:47:35 AM UTC-4, Colin Fleming wrote:
>
> Note that the shopping cart is just one specific example from my current 
> itch that needs scratching - it's a very common one, but I'm sure there are 
> plenty more reusable component types that people expect these days.
>
> One problem I see with the composition approach (which I'm a huge fan of 
> in general) is the multiplicative complexity. Something like a shopping 
> cart needs access to the persistence layer. In Rails, this is very easy - 
> you use ActiveRecord and you're done because everything else uses 
> ActiveRecord too. However in the Clojure world we have N persistence 
> libraries implementing M persistence strategies - I've never tried to make 
> a reusable component that sits in the "middle" of the stack (i.e. not 
> something that's relatively trivial to make dependency-free like logging), 
> but I can imagine that it's very difficult. And of course, persistence is 
> just one aspect, there must be many more like authentication and so on. A 
> big part of the reason for Ring's success is that it's the only game in 
> town - I'm sure we wouldn't have so much great functionality built on top 
> of it if we had 4 incompatible options to choose from.
>
> Someone earlier in the thread wrote about how Ruby was the abstraction in 
> contrast to PHP where libraries were tied to a framework. I've never worked 
> with Rails seriously, but I find it hard to believe that libraries such as 
> shopping carts intended for Rails will work out of the box with some other 
> framework - is this the case? The ones I looked at (admittedly briefly and 
> some time ago) were all Rails-specific.
>
> On 4 May 2015 at 20:41, Sven Richter > 
> wrote:
>
>> So, what I gather from this discussion are the following points. Clojure 
>> "needs" a "webframework" that is
>>
>> - fully documented
>> - easy for beginners to use
>> - opinionated about the libraries
>> - structured
>> - composable
>> - has something nice like django's admin backend
>> - a vibrant community support
>> - a shopping card (whereas I would see that fit into an external library)
>>
>> I agree that we have almost everything we need in the form of single 
>> libraries. And I think a mix of leiningen templates and plugins is the way 
>> to go here.
>> The reason for the last statement is my experience with django. The admin 
>> UI is awesome and it fullfills 95% of your needs, but for the rest of it to 
>> make it work I had to start hacking my local django source, which is PITA 
>> obv.
>>
>> I would refrain from doing some magic that only works in a specific 
>> context, but instead just generate code that is put into a fixed structure 
>> and works. The advantage is, one can change the code all the time if one 
>> needs to.
>>
>> All in all this is basically the direction I want to go with closp and 
>> closp-crud. The intention is not to have a webframework, but to automatize 
>> steps that need to be done manually otherwise.
>>
>> I am open for everything in that area, as long as it stays in the limits 
>> I stated above, so, if someone wants to join, he is welcome.
>>
>> I would also go the other way around and put efforts into someone elses 
>> project, if that makes sense.
>>
>> Am Montag, 4. Mai 2015 07:43:43 UTC+2 schrieb puzzler:
>>
>>> On Sat, May 2, 2015 at 11:12 PM, Sven Richter  
>>> wrote:
>>>
 Reading through all the discussion I don't get which features you are 
 actually missing. I love luminus and did a lot with it, however, for me it 
 was missing some standard stuff, that's why I put together closp, which is 
 just another leinin

Re: Clojure needs a web framework with more momentum

[larry google groups]

> Very interesting discussion going on here. As a beginner, what I'd like 
to see is not something 
> like Django or Rails, but something like Flask.

Flask started off as a sort of joke -- a few Python programmers, responding 
to criticism of bloat in Django, said it should be possible to create a 
single file web app. And they succeeded. 

You can certainly create a single-file web app in Clojure, and I think 
there are several examples on the web, that are very much comparable to the 
simple examples given for Flask. But, again, I agree with those above who 
suggested that maybe this should be offered as a lein template. 




On Monday, May 4, 2015 at 6:06:46 AM UTC-4, John Louis Del Rosario wrote:
>
> Very interesting discussion going on here. As a beginner, what I'd like to 
> see is not something like Django or Rails, but something like Flask.
> Where someone can just (require 'someframework) and it works. Maybe it 
> could have thin wrappers over compojure, etc., since it will need to be 
> opinionated anyway. It's still very simple, but takes away a lot of the 
> guesswork and the distributed docs across multiple projects problem.
>
> Additional features can be done as libraries then, but specific for 
> `someframework`, like what Flask has. e.g. `someframework-sessions`, etc.
>
> Just my 2c.
>
> On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what 
>> I found: 
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>>
>> LuminusClojure28678 
>> CaribouClojure 2275 
>>
>> BeegoGolang991522 
>>
>> PhoenixElixir  1241949 
>>
>> YesodHaskell   1303722 
>>
>> LaravelPHP2684421 
>>
>> PlayScala   4176085 
>>
>> SymfonyPHP113020914 
>>
>> RailsRuby   269151000 
>>
>>
>> One could conclude from this that the Clojure community isn't that 
>> interested in web development but the last Clojure survey suggests 
>> otherwise. Clojure's library composition approach to everything only 
>> goes so far with large web applications, as Aaron Bedra reminded us in 
>> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower 
>> means less momentum and more bugs. Furthermore, I have a hunch that 
>> Clojure's poor adoption as indicated by Indeed.com maybe due to this 
>> immaturity in the web framework sphere. Why is it that Elixir, with a 
>> much smaller community and lifespan than Clojure's, has managed to put 4 
>> times as much mindshare into its main web framework when its module 
>> output, as measured by modulecounts.com, is a tiny fraction of 
>> Clojure's? 
>>
>> gvim 
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Luc Préfontaine]

I certainly have some personality disorders, but I am not bipolar :)
What am I ? Help ! :)

Luc P.


> > And never has this author proven that programmers with bipolar 
> personality are 
> > programming more LISP then other languages. 
> 
> It's a metaphor. The author is not actually diagnosing Lisp programmers 
> with bipolar disorder. The metaphor offers an image of a particular kind of 
> student who starts stuff but doesn't finish stuff. 
> 
> 
> 
> 
> On Sunday, May 3, 2015 at 2:52:22 PM UTC-4, Leon Grapenthin wrote:
> >
> > No, it isn't. And never has this author proven that programmers with 
> > bipolar personality are programming more LISP then other languages. 
> >
> > Many larger libraries in the Clojure community are well documented and 
> > "finished-off properly".
> >
> > Web frameworks have been tried and not been picked up. Users have chosen 
> > the modular compose it yourself approach. Framework authors have simply 
> > stopped maintaining what nobody wanted anyway or split them up into smaller 
> > pieces. 
> >
> >
> > On Sunday, May 3, 2015 at 8:25:22 PM UTC+2, larry google groups wrote:
> >>
> >>
> >> > The web development industry as reflected in job postings at 
> >> > Indeed.co.uk is still dominated by the likes of Rails, Django, 
> >> Laravel, 
> >> > Zend, Symfony & Spring so I'm not sure how you've concluded that 
> >> there's 
> >> > been a 15-year trend towards composition. 
> >>
> >> That is a good point, though I would also point out that, according to 
> >> Indeed.com, the use of Clojure is also growing. To me, what's important is 
> >> the growth of the Clojure community, rather than the growth of some 
> >> sub-community focused on a particular niche. 
> >>
> >> However, I acknowledge you may have a point about the failure of any of 
> >> the Clojure frameworks to take off. It's possible this is another 
> >> manifestation of the Bipolar Programmer problem: 
> >>
> >> http://www.lambdassociates.org/blog/bipolar.htm
> >>
> >> "Brilliance and failure are so often mixed together and our initial 
> >> reaction is it shouldn't be.   But it happens and it happens a lot.  Why? 
> >> ...But brilliance is not enough.  You need application too, because the 
> >> material is harder at university.   So pretty soon our man is getting B+, 
> >> then Bs and then Cs for his assignments.   He experiences alternating 
> >> feelings of failure cutting through his usual self assurance.  He can 
> >> still 
> >> stay up to 5.00AM and hand in his assignment before the 9.00AM deadline, 
> >> but what he hands in is not so great.
> >>
> >> ...So BBMs love Lisp.  And the stunning originality of Lisp is reflective 
> >> of the creativity of the BBM; so we have a long list of ideas that 
> >> originated with Lispers - garbage collection, list handling, personal 
> >> computing, windowing and areas in which Lisp people were amongst the 
> >> earliest pioneers.  So we would think, off the cuff, that Lisp should be 
> >> well established, the premiere programming language because hey - its 
> >> great 
> >> and we were the first guys to do this stuff.
> >>
> >> But it isn't and the reasons why not are not in the language, but in the 
> >> community itself, which contains not just the strengths but also the 
> >> weaknesses of the BBM.
> >>
> >> One of these is the inability to finish things off properly.  The phrase 
> >> 'throw-away design' is absolutely made for the BBM and it comes from the 
> >> Lisp community.   Lisp allows you to just chuck things off so easily, and 
> >> it is easy to take this for granted.  I saw this 10 years ago when looking 
> >> for a GUI to my Lisp (Garnet had just gone West then).  No problem, there 
> >> were 9 different offerings.  The trouble was that none of the 9 were 
> >> properly documented and none were bug free. Basically each person had 
> >> implemented his own solution and it worked for him so that was fine.   
> >> This 
> >> is a BBM attitude; it works for me and I understand it.   It is also the 
> >> product of not needing or wanting anybody else's help to do something."
> >>
> >>
> >>
> >>
> >>
> >> On Sunday, May 3, 2015 at 9:51:15 AM UTC-4, g vim wrote:
> >>>
> >>> On 03/05/2015 14:39, larry google groups wrote: 
> >>> > The industry has been moving against frameworks for 15 years now. The 
> >>> > peak of the monolithic framework craze was Struts, back in 2000. After 
> >>> > that, people started craving something less bloated. That's why the 
> >>> > whole industry was so excited when Rails emerged in 2004. Bruce Eckel 
> >>> > summed up the sudden change of mood in his essay "The departure of the 
> >>> > hyper-enthusiasts": 
> >>> > 
> >>> > http://www.artima.com/weblogs/viewpost.jsp?thread=141312 
> >>> > 
> >>> > But after awhile, people began to feel that even Rails was bloated, 
> >>> > which lead to the emergence of micro-frameworks like Sinatra. 
> >>> > 
> >>> > And then, continuing with the trend, we've seen the emergence of 
> >>> > eco-sy

Re: Clojure needs a web framework with more momentum

[Christopher Small]

And Flask was inspired by Sinatra, IIRC. Also, the rails folks thought that
Sinatra would be a joke and no one would take it seriously. They were
surprised. Ditto with Merb, which was a similarly more modular, and became
so popular that rails actually merged with it.

Clojure's Noir used to be similarly minimalistic, but it became deprecated
and split up into peices which live on today as lib-noir, and can be used
with (e.g.) Luminus.

Chris


On Mon, May 4, 2015 at 5:25 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

> > Very interesting discussion going on here. As a beginner, what I'd like
> to see is not something
> > like Django or Rails, but something like Flask.
>
> Flask started off as a sort of joke -- a few Python programmers,
> responding to criticism of bloat in Django, said it should be possible to
> create a single file web app. And they succeeded.
>
> You can certainly create a single-file web app in Clojure, and I think
> there are several examples on the web, that are very much comparable to the
> simple examples given for Flask. But, again, I agree with those above who
> suggested that maybe this should be offered as a lein template.
>
>
>
>
> On Monday, May 4, 2015 at 6:06:46 AM UTC-4, John Louis Del Rosario wrote:
>>
>> Very interesting discussion going on here. As a beginner, what I'd like
>> to see is not something like Django or Rails, but something like Flask.
>> Where someone can just (require 'someframework) and it works. Maybe it
>> could have thin wrappers over compojure, etc., since it will need to be
>> opinionated anyway. It's still very simple, but takes away a lot of the
>> guesswork and the distributed docs across multiple projects problem.
>>
>> Additional features can be done as libraries then, but specific for
>> `someframework`, like what Flask has. e.g. `someframework-sessions`, etc.
>>
>> Just my 2c.
>>
>> On Sunday, May 3, 2015 at 4:43:53 AM UTC+8, g vim wrote:
>>>
>>> I recently did some research into web frameworks on Github. Here's what
>>> I found:
>>>
>>>
>>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS
>>>
>>> LuminusClojure28678
>>> CaribouClojure 2275
>>>
>>> BeegoGolang991522
>>>
>>> PhoenixElixir  1241949
>>>
>>> YesodHaskell   1303722
>>>
>>> LaravelPHP2684421
>>>
>>> PlayScala   4176085
>>>
>>> SymfonyPHP113020914
>>>
>>> RailsRuby   269151000
>>>
>>>
>>> One could conclude from this that the Clojure community isn't that
>>> interested in web development but the last Clojure survey suggests
>>> otherwise. Clojure's library composition approach to everything only
>>> goes so far with large web applications, as Aaron Bedra reminded us in
>>> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower
>>> means less momentum and more bugs. Furthermore, I have a hunch that
>>> Clojure's poor adoption as indicated by Indeed.com maybe due to this
>>> immaturity in the web framework sphere. Why is it that Elixir, with a
>>> much smaller community and lifespan than Clojure's, has managed to put 4
>>> times as much mindshare into its main web framework when its module
>>> output, as measured by modulecounts.com, is a tiny fraction of
>>> Clojure's?
>>>
>>> gvim
>>>
>>>
>>>
>>>
>>>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/tA2_IbU0unE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> I've taken a couple of long lived Rails apps from Rails 1 to Rails 4 and 
while there have been breaking changes with 
> each major version change (and some minor versions) in general it's 
pretty easy to keep up with the latest 
> versions and there are copious docs (even whole ebooks in some cases) to 
walk developers through the changes.

Composable libraries instead of plugins avoids the biggest problems that 
Rails faces. In my experience, the toughest issue with upgrading old Rails 
apps is upgrading the plugins. I recall last year I was given the task of 
upgrading an old install of Redmine. I struggled with it for 2 days -- the 
app itself was easy to upgrade, but all the old plugins broke. I offered to 
fix them all by hand, but I estimated that would take me a week or two, at 
which point management decided that the problem was no longer worth it, so 
they decided to live with the old version of Redmine until such time as the 
whole thing could be replaced entirely. 

The world of Rails, and the world of Ruby, has evolved, and nowadays 
plugins are just gems that follow some conventions. Which is to  say, Rails 
has been moving in the direction that Clojure is already in. But Clojure is 
out in front on this issue. In the Clojure eco-system, if you use the word 
"plugin" you are probably talking about lein, or maybe Stuart Sierra's 
Component system. The conversation is happening at higher level than in the 
Ruby world. 

I think it is a sign of failure when you have to do what we did with 
Redmine -- give up any hope of upgrading it and instead wait till you can 
replace it entirely. At least so far, I have not see than come up in any 
Clojure project I've worked on, though I acknowledge Clojure projects don't 
have the age of old Rails projects. 

If, 10 years from now, Clojure has the reputation that upgrading rarely 
hits the "we must replace this entirely" problem, then I think we can say, 
in absolute terms, that Clojure is superior than Ruby. And this would also 
be true in the specific category of "web frameworks". 







On Monday, May 4, 2015 at 8:09:35 AM UTC-4, Sean Johnson wrote:
>
>
>
> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
>
> All in all this is basically the direction I want to go with closp and 
>> closp-crud. The intention is not to have a webframework, but to automatize 
>> steps that need to be done manually otherwise.
>>
>
> One potential problem with this "web framework" as app template approach 
> is upgrade-ability.  When 2.0 of your "framework" comes out, what happens 
> to an app generated from 1.0 that wants to benefit from the new 
> capabilities?
>
> It's not a showstopper to the approach. It's just something to think hard 
> about. I've taken a couple of long lived Rails apps from Rails 1 to Rails 4 
> and while there have been breaking changes with each major version change 
> (and some minor versions) in general it's pretty easy to keep up with the 
> latest versions and there are copious docs (even whole ebooks in some 
> cases) to walk developers through the changes.
>
> Cheers,
> Sean
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[Dmitri]

As others have pointed out the comparison isn't really valid. Luminus 
intentionally aims to leverage existing libraries that are maintained 
independently whenever possible. I've been doing web dev with Clojure for 
the past 4 years and overall I do prefer the approach of using composable 
libraries over monolithic frameworks. With the Clojure web stack it's much 
easier to tell what's actually happening during the request/response 
lifecycle as things tend to be explicit. With frameworks like Rails a lot 
of stuff happens implicitly and requires a lot of in depth knowledge to 
work with effectively.

However, there are a some downsides to the libraries over frameworks 
approach as well. The biggest issue is that it's difficult to track what 
libraries are actively maintained and which ones play nicely together. 
Since most libraries are maintained by individuals it's common for them to 
become abandoned. Another problem is that each app becomes a unique 
snowflake since there aren't a lot of established patterns for structuring 
them. Finally, security is an issue for Clojure web apps as a lot of it 
done in rather ad hoc fashion. While this works great for people who are 
well versed in the Clojure web ecosystem it's a huge barrier for newcomers.

I think that the best way to address the problem is via organizations where 
related projects are maintained by groups of contributors. This helps 
discovery of projects, and it helps spread the burden of maintenance for 
them. This approach is already working in the wild on GitHub with Ring, 
Reagent, and Luminus orgs. Meanwhile, Leiningen templates are a great way 
to provide reasonable defaults for different types of applications and can 
be used to address issues such as security.

Also, I'm certainly open to contributions for Luminus. I moved it to an org 
recently and new members would be very welcome. :)


On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote:
>
> I recently did some research into web frameworks on Github. Here's what 
> I found: 
>
>
> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>
> LuminusClojure28678 
> CaribouClojure 2275 
>
> BeegoGolang991522 
>
> PhoenixElixir  1241949 
>
> YesodHaskell   1303722 
>
> LaravelPHP2684421 
>
> PlayScala   4176085 
>
> SymfonyPHP113020914 
>
> RailsRuby   269151000 
>
>
> One could conclude from this that the Clojure community isn't that 
> interested in web development but the last Clojure survey suggests 
> otherwise. Clojure's library composition approach to everything only 
> goes so far with large web applications, as Aaron Bedra reminded us in 
> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower 
> means less momentum and more bugs. Furthermore, I have a hunch that 
> Clojure's poor adoption as indicated by Indeed.com maybe due to this 
> immaturity in the web framework sphere. Why is it that Elixir, with a 
> much smaller community and lifespan than Clojure's, has managed to put 4 
> times as much mindshare into its main web framework when its module 
> output, as measured by modulecounts.com, is a tiny fraction of Clojure's? 
>
> gvim 
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[larry google groups]

> I read several comments about how easy it is to upgrade Rails. 
> Either things have been improving at the speed of light or I am 
> a complete idiot. My last upgrades from 2.x to 2.y have been 
> nightmares, dependency hell multiplied by an unknown factor 
> above 100... 


I strongly agree. I think of upgrading as the major pain point in the Rail 
eco-system. It has gotten better, but as recently as last week I was trying 
to upgrade a gem and ran into version conflicts. Search StackOverflow for 
Bundler error messages and you realize this is still a huge point of pain 
-- there are thousands of people struggling to deal with cryptic version 
conflict errors, and unable to get Bundler to resolve the problem for them. 





On Monday, May 4, 2015 at 10:42:15 AM UTC-4, Luc wrote:
>
> +1 
>
> This exactly the kind of exercises that needs to done as part of a 
> product design. New potential needs have to be foreseen at this 
> stage, not 18 months after a first release. 
>
> This is why I hate frameworks, they assume some of these 
> decisions and it's not always stated clearly. Someone has to 
> discover the sad effects and if you are not lucky, you're the 'king of the 
> farce'. 
>
> They lure you in a trap pampered with 'easy', 'obvious'... Until 
> you have a need that cannot be met along the way. 
>
> I read several comments about how easy it is to upgrade Rails. 
>
> Either things have been improving at the speed of light or I am 
> a complete idiot. My last upgrades from 2.x to 2.y have been 
> nightmares, dependency hell multiplied by an unknown factor 
> above 100... 
>
> I would rather deal with an explicit dependency graph than 
> work with magic stuff that eventually breaks in obscure ways 
> after an upgrade and requires mods in remote places in foreign code. 
>
> Luc P. 
>
> > The thing that bugs me the most about these sort of conversations about 
> > "best practices" is that they often present a set of solutions without 
> > first analyzing the problem at hand. 
> > 
> > If I came to this mailing list and asked "I want to write a websever in 
> > Clojure..what should I use?". The response would most likely be Ring + 
> > Compojure. Okay, not bad options, but that recommendation has been given 
> > with absolutely no analysis of what I'm trying to accomplish. What if I 
> > need async? What if I need web sockets? What sort of connection load am 
> I 
> > expecting? Will my system handle mostly persistent connections (like 
> > websockets or SSE), or will it be more canned (and cacheable) data? If 
> > someone recommends Ring to me, I may be pigeonholed into some system 
> I'll 
> > have to refactor later. Perhaps the best option is Aleph or Pedestal. 
> > 
> > That's the real issue with canned responses like rails tutorial. They 
> > assume my needs match your needs and match the needs of most people. 
> That's 
> > just not the best way to go about doing software development. And it's a 
> > problem I've seen in so many areas of computing. 
> > 
> > I've lost countless hundreds of hours of my life to frameworks that 
> default 
> > to bulky serialization formats (like XML or JSON), or frameworks that 
> > assume LAN connections to the servers, or frameworks that assume I won't 
> be 
> > using multi-threading, or frameworks that assume I won't try to load 10k 
> > rows on a single page, or frameworks that assume any number of things. 
> The 
> > thing I love the most about the Clojure community is that, more than any 
> > other community I've been a part of, they try to ask you to think before 
> > you jump. 
> > 
> > So what I would recommend is more of a set of guidelines, and matrices. 
> > List all the frameworks/libraries on one axis, and features on another, 
> and 
> > start commenting. Make a page like this: ( 
> > http://en.wikipedia.org/wiki/Comparison_of_video_container_formats) 
> > 
> > Mention that Ring is well supported by the community, but doesn't work 
> well 
> > with fully async servers, mention that Aleph does all the async you 
> need, 
> > but is a bit non-standard. Mention that data.json is pure Clojure, but 
> > cheshire is most likely faster. 
> > 
> > Just present the options, and let the users make up their own minds. You 
> > don't understand the needs of all of your users. So don't try to solve 
> > their problems, instead present them with options and let them make up 
> > their own minds.  I guarantee you that whatever tech you recommend to 
> > someone, the won't like some aspect of it,  so better to present them 
> with 
> > all the options and let them choose, then they can only blame themselves 
> if 
> > it doesn't work out exactly like they expected. 
> > 
> > 
> > 
> > On Mon, May 4, 2015 at 7:34 AM, Ernie de Feria  > 
> > wrote: 
> > 
> > > I would like to echo the sentiment expressed by several posters in 
> this 
> > > thread, but with a slight twist. A few years back I picked up Ruby and 
> Ruby 
> > > on Rails as the language/framework to create 

Re: Clojure needs a web framework with more momentum

[larry google groups]

> My guess is that over the next 2-3 years we will see some clojure 
frameworks emerge but 
> they will not be like "traditional" frameworks.  

Or the space for "web framework" will always default to Rails. Clojure 
certainly has some great frameworks in other areas, such as distributed 
data processing: 

Avout

tessers

Onyx

Storm

Pulsar

Quassar

(Some of these are more Java than Clojure, but Java interop is one of 
Clojure's strengths.)





On Monday, May 4, 2015 at 3:00:54 PM UTC-4, Gregg Reynolds wrote:
>
>
> On May 4, 2015 7:16 AM, "Eric MacAdie" > 
> wrote:
> >
> > I think what Clojure needs is a default. It doesn't matter if it is a 
> "web framework" like Rails, or "libraries strung together" like Luminus.
> >
>
> What Clojure needs is, well nothing. What the market MAY need is an 
> entrepreneur who will produce the framework the OP craves.  No takers so 
> far.  Conclusion: not a genuine unmet need.   But in the long run simple 
> economics say the Clojure approach will win.  You can't make your product 
> stand out by using the same framework everybody else uses.  The inevitable 
> trend, driven by basic economics, is toward bespoke stuff, which is where 
> Clojure excels.  My guess is that over the next 2-3 years we will see some 
> clojure frameworks emerge but they will not be like "traditional" 
> frameworks.  They'll be infinitely and easily customizable because they 
> wont force choices-they'll just make the easy stuff not only easy but 
> flexible. My 2 cents.
>
> > When a Ruby newbie asks how to make a web app, the default answer is to 
> look at Rails. In Python, the default answer is Django. Compared to that, 
> the default answer in Clojure to do it yourself can sound like "go jump off 
> a cliff".  
> >
> > = Eric MacAdie
> >
> >
> > On Mon, May 4, 2015 at 7:09 AM, Sean Johnson  > wrote:
> >>
> >>
> >>
> >> On Monday, May 4, 2015 at 4:41:02 AM UTC-4, Sven Richter wrote:
> >>
> >>> All in all this is basically the direction I want to go with closp and 
> closp-crud. The intention is not to have a webframework, but to automatize 
> steps that need to be done manually otherwise.
> >>
> >>
> >> One potential problem with this "web framework" as app template 
> approach is upgrade-ability.  When 2.0 of your "framework" comes out, what 
> happens to an app generated from 1.0 that wants to benefit from the new 
> capabilities?
> >>
> >> It's not a showstopper to the approach. It's just something to think 
> hard about. I've taken a couple of long lived Rails apps from Rails 1 to 
> Rails 4 and while there have been breaking changes with each major version 
> change (and some minor versions) in general it's pretty easy to keep up 
> with the latest versions and there are copious docs (even whole ebooks in 
> some cases) to walk developers through the changes.
> >>
> >> Cheers,
> >> Sean
> >>
> >> -- 
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clo...@googlegroups.com 
> 
> >> Note that posts from new members are moderated - please be patient with 
> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+u...@googlegroups.com 
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=en
> >> --- 
> >> You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com .
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > -- 
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clo...@googlegroups.com 
> 
> > Note that posts from new members are moderated - please be patient with 
> your first post.
> > To unsubscribe from this group, send email to
> > clojure+u...@googlegroups.com 
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com .
> > For more options, visit https://groups.google.com/d/optout.
>  

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroup

Re: Clojure needs a web framework with more momentum

[Daniel Compton]

The Clojure community has a knack for looking at things and distilling them
to their essence. I think the discussion on whether Clojure needs a web
framework is another opportunity for that.

I don't think Clojure doesn't need a web framework, because Clojure is a
programming language and doesn't need anything except a nice, warm JVM.
Even if you reframe the question, "Do people need a Clojure web
framework?", I still don't think its the right question. People don't need
a web framework, they need what a web framework provides for them, and
different people have very different needs.

If we use the Jobs To Be Done
 theory we can see
what job different groups of people 'hire' a framework for:

"The Business"

The business hires a popular framework because
* It offers the promise of quick development on features, with less time
spent on the unimportant parts.
* They want the security that their development team are working with
something popular that will be supported, maintained, and used by lots of
people for a long time.
* They also like the benefit that there will be a relatively large hiring
pool of people able to step into their codebase and get up to speed quickly.

"Recruiters"

Recruiters like to be able to pick out a particular technology and match
you to their clients requirements. Like it or not, thats the world that we
live in. If there was a common framework that people used, this part would
be easier for them and the developer trying to get hired.

"The CTO"

The CTO shares many of the same concerns with the business, she also
* Finds the shared conventions (from the framework and the community)
useful for eliminating bikeshedding.
* The shared conventions let developers understand each others code more
easily.
* Using a popular framework means that they are able to pull in battle
tested libraries for critical things like auth, and be fairly confident in
their quality.
* Common concerns that every webapp needs, like templating and
pluralisation are also built in.

"The junior developer"

A popular framework is great for a junior developer, they hire it for
* A scaffold of how to build a web application.
* The ability to get a quick win and get a real web application running
without spending 10 hours banging their head against the keyboard.
* Lots of standard functionality and third party libraries that they can
pull in without necessarily understanding how to do it themselves (i.e.
login and authorisation).
* A large amount of documentation to learn from, and a community that is
well set up for teaching beginners.
* The ability to slot into a larger development team because the work they
are doing can be well defined and matched to their skill level.

"The senior developer"

A framework is least useful to the senior developer, as they are often
capable of combining libraries with the functionality they need to build
their own webapp. They may find themselves restricted by the framework if
they want to step outside of the bounds that the framework provides.

If you agree with my characterisations then you can see that a framework
provides many different things to many different people. Clojure doesn't
necessarily need a web framework, but in my opinion it does need to satisfy
each of the parties involved with the development process if it wants to be
used more commonly in web app development.

What this may look like for Clojure in 2015 is probably very different than
what it looked like for Ruby in 2004. It may be a traditional framework, a
lein template, a standard pattern of code, a set of conventions and loosely
coupled protocols, pretty much exactly what we have now, or something
entirely different.

On Tue, May 5, 2015 at 12:53 PM, larry google groups <
lawrencecloj...@gmail.com> wrote:

>
> > My guess is that over the next 2-3 years we will see some clojure
> frameworks emerge but
> > they will not be like "traditional" frameworks.
>
> Or the space for "web framework" will always default to Rails. Clojure
> certainly has some great frameworks in other areas, such as distributed
> data processing:
>
> Avout
>
> tessers
>
> Onyx
>
> Storm
>
> Pulsar
>
> Quassar
>
> (Some of these are more Java than Clojure, but Java interop is one of
> Clojure's strengths.)
>
>
>
>
>
> On Monday, May 4, 2015 at 3:00:54 PM UTC-4, Gregg Reynolds wrote:
>>
>>
>> On May 4, 2015 7:16 AM, "Eric MacAdie"  wrote:
>> >
>> > I think what Clojure needs is a default. It doesn't matter if it is a
>> "web framework" like Rails, or "libraries strung together" like Luminus.
>> >
>>
>> What Clojure needs is, well nothing. What the market MAY need is an
>> entrepreneur who will produce the framework the OP craves.  No takers so
>> far.  Conclusion: not a genuine unmet need.   But in the long run simple
>> economics say the Clojure approach will win.  You can't make your product
>> stand out by using the same framework everybody else uses.  The inevitable
>> trend, driv

Re: Wrapping org.apache.commons.math3.complex

[Mikera]

You often have to do bit of manual coercion to make things work nicely with 
the whole set of possible Clojure numerical types. Fortunately there are 
plenty of built-in functions in clojure.core to help you do this.

In your specific case I would do:

(.add (Complex. 1.0 2.0) (double 2)) 

This performs the coercion to the double type that you need for the Java 
interop. But the nice thing about the "(double ...)" is that it will handle 
not just longs but all other Clojure numerical types (ratios, bigints etc.)


On Saturday, 2 May 2015 19:53:12 UTC+8, Alan Forrester wrote:
>
> Hello 
>
> I'm currently trying to wrap org.apache.commons.math3.complex 
>
>
> http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/complex/Complex.html
>  
>
> to make a complex number library and I have a problem. Many of the 
> methods won't work with all Clojure number types. For example, 
>
> (.add (Complex. 1.0 2.0) 2) 
>
> produces an IllegalArgumentException. The method only works if at 
> least one of the arguments is a complex number although the other can 
> be a double. 
>
> What would be the best way of handling this? Should I just wrap add 
> the way it is and explain what types are expected in the 
> documentation, or is there a better way of dealing with this issue 
> that would allow Clojure number types to be used seamlessly? 
>
> Alan 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A more flexible versio of -> ?

[Mike Thompson]

In addition to what's already been pointed out, on a grander scale there's:
https://github.com/LonoCloud/synthread


On Tuesday, May 5, 2015 at 6:48:34 AM UTC+10, Kaiyin Zhong wrote:
>
> Wouldn't be nice to have something like:
>
> (->>> thing 
>   (f1 ph arg2 arg3)
>   (f2 arg1 ph arg3)
>   (f3 arg1 arg2 ph))
>
> ;; ph is a place holder for thing
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A more flexible versio of -> ?

[Franklin M. Siler]

On May 4, 2015, at 1546, Kaiyin Zhong  wrote:

> Wouldn't be nice to have something like:

See also Swiss Arrows:
https://github.com/rplevy/swiss-arrows

Great article on “hard to Google” forms in Clojure:
https://yobriefca.se/blog/2014/05/19/the-weird-and-wonderful-characters-of-clojure/

Frank`

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Embedded systems and transpiling Clojure to Nim

[Herwig Hochleitner]

2015-05-05 2:04 GMT+02:00 Alan Moore :
>
>
> Herwig - I like your suggestion re: rclojure. That seems like a harder
> but more fruitful approach than other porting options. Do you have any
> references to this kind of approach in other languages?
>
>
It could be argued, that compilers doing escape analysis (which includes
Hotspot), have that subset of their input language hidden in them. However,
I'm not aware of a dynamic vm that takes that subset and uses it to provide
e.g. allocation-free transducers over homogeneous arrays (The latter being,
what i estimate as a minimal useful example of an allocation-free language
subset). Even rpython assumes a gc for all code, though it certainly tries
to eliminate many allocations.

Graal talks about it, so that could mean they might provide infrastructure:
https://wiki.openjdk.java.net/display/Graal/Graal+Partial+Escape+Analysis
And value types as planned for a future jdk will certainly help java
programmers eliminating allocations.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure needs a web framework with more momentum

[blake]

>>Do the advantages you've pointed out apply to teamwork, though? That's
supposed to be where frameworks make life easier.

Frameworks make life easier for teamwork, sure—as long as everyone knows
the framework and has the same (presumably correct =P) understanding of it.
In practice here, everyone's understanding of rails was slightly different,
and we had to establish a whole lot of in-house convention, and the churn
on that was really painful.

Like, we switched to using mountable engines. Cool idea, but it was ugly,
and we ended up with pieces that were mountable and pieces that were not,
and it was fragile and hard to deploy. We've had that problem across many
iterations of Rails. (And, some teams having adopted Angular, it looks like
there's going to be some issue there since the next version of Angular is
supposed to be backward incompatible.)

I just don't see that happening with the Clojure apps. I've let a complete
neophyte add stuff to my main web app, and he's gotten useful work done.
(He made some goofs because he didn't get the "stateless" thing, but that's
about it.) I had a graphic designer come in and fix the Hiccup to make it
more professional looking. She didn't have a hitch.

Separation of concerns, simplicity, clarity...I guess they do have some
value.


On Mon, May 4, 2015 at 3:47 PM, gvim  wrote:

> On 04/05/2015 23:17, blake wrote:
>
>> I went from Ruby to Clojure in short-order and while I struggled
>> mightily with the functional aspect (after assiduously avoiding those
>> concepts for years), I much prefer every aspect of Clojure web
>> programming to Rails.
>>
>> The bible of rails programming is the Hartl book. In the edition I read,
>> before you got to any actual programming, you were introduced to
>> 14—fourteen! I counted!—different domains, including things like RSpec
>> and Cucumber. And it was all treated with this, "Well, you can figure
>> out what this all does because, hey, it looks just like English"
>> attitude, with a patina of "you don't need to know what's going on under
>> the covers".
>>
>> The advantage of having an opinionated framework is that it saves one
>> the effort of having to make up one's own mind. This means you're
>> trusting someone with literally no understanding of your problem domain
>> to make up your mind for you. It's sort of amazing that this works at
>> all, and that there aren't =more= vulnerabilities turning up like the
>> Rails XML hack.
>> ​
>> This made me really uncomfortable with Rails.
>>
>> My current Clojure web app is more sophisticated than anything I did
>> with Rails, though my Rails apps doubtless carried far more untapped
>> potential. But I know just about exactly what it does. I know because I
>> added each piece of middleware as I needed it, and this allowed me to
>> understand what going on. I needed access to Mongo and MS-SQL, so I
>> added those. I needed a front-end so I started with Hiccup, which is
>> "obvious" (and remarkably similar to Smalltalk's Seaside, which I've
>> used), and then added in some Javascript.
>>
>> I'll turn the Javascript into Clojurescript, but I felt that was too
>> much to absorb at once. And unlike Rails, I didn't need to absorb every
>> hot library du jour to get going. (And damned if in Rails, each tutorial
>> has a different idea of which libraries are essential.)
>>
>> Then I added authentication, and threading (which was ridiculously
>> easy), and so on. Each piece as needed, with an understanding of what
>> was going on. Now, I don't get ALL of it. But I know where my weaknesses
>> are. I have, now, an opinionated framework, but it's made of =my=
>> opinions. And I made those opinions by looking at what the libraries I'm
>> using did, which is way simpler in a shallow functional world than in an
>> object-drill-down world.
>>
>> In Rails, you don't know what you don't know.
>>
>>
> Do the advantages you've pointed out apply to teamwork, though? That's
> supposed to be where frameworks make life easier.
>
> gvim
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscri

Re: Clojure needs a web framework with more momentum

[Sven Richter]

Hi Dmitri,

When I was building closp I was taking luminus as the base for it with some 
minor adoptions. I just had a look at the website of luminus and saw the 
massive amount of work you put into the documentation again. If that sounds 
reasonable for you I'd like to try to move closp and closp-crud to luminus 
as an opionated part of it.
So if you call lein new luminus projectname +closp you will basically get 
what you get now with closp. You can look here for the additions: 
https://github.com/sveri/closp.
I would like to maintain that "branch".

I am not sure if that will work out the way I think, but I'd like to 
evaluate it at least. It would be nice to have a common base and a common 
documentation for it.

Best Regards,
Sven

Am Dienstag, 5. Mai 2015 02:38:41 UTC+2 schrieb Dmitri:
>
> As others have pointed out the comparison isn't really valid. Luminus 
> intentionally aims to leverage existing libraries that are maintained 
> independently whenever possible. I've been doing web dev with Clojure for 
> the past 4 years and overall I do prefer the approach of using composable 
> libraries over monolithic frameworks. With the Clojure web stack it's much 
> easier to tell what's actually happening during the request/response 
> lifecycle as things tend to be explicit. With frameworks like Rails a lot 
> of stuff happens implicitly and requires a lot of in depth knowledge to 
> work with effectively.
>
> However, there are a some downsides to the libraries over frameworks 
> approach as well. The biggest issue is that it's difficult to track what 
> libraries are actively maintained and which ones play nicely together. 
> Since most libraries are maintained by individuals it's common for them to 
> become abandoned. Another problem is that each app becomes a unique 
> snowflake since there aren't a lot of established patterns for structuring 
> them. Finally, security is an issue for Clojure web apps as a lot of it 
> done in rather ad hoc fashion. While this works great for people who are 
> well versed in the Clojure web ecosystem it's a huge barrier for newcomers.
>
> I think that the best way to address the problem is via organizations 
> where related projects are maintained by groups of contributors. This helps 
> discovery of projects, and it helps spread the burden of maintenance for 
> them. This approach is already working in the wild on GitHub with Ring, 
> Reagent, and Luminus orgs. Meanwhile, Leiningen templates are a great way 
> to provide reasonable defaults for different types of applications and can 
> be used to address issues such as security.
>
> Also, I'm certainly open to contributions for Luminus. I moved it to an 
> org recently and new members would be very welcome. :)
>
>
> On Saturday, May 2, 2015 at 4:43:53 PM UTC-4, g vim wrote:
>>
>> I recently did some research into web frameworks on Github. Here's what 
>> I found: 
>>
>>
>> FRAMEWORK   LANG  CONTRIBUTORS COMMITS 
>>
>> LuminusClojure28678 
>> CaribouClojure 2275 
>>
>> BeegoGolang991522 
>>
>> PhoenixElixir  1241949 
>>
>> YesodHaskell   1303722 
>>
>> LaravelPHP2684421 
>>
>> PlayScala   4176085 
>>
>> SymfonyPHP113020914 
>>
>> RailsRuby   269151000 
>>
>>
>> One could conclude from this that the Clojure community isn't that 
>> interested in web development but the last Clojure survey suggests 
>> otherwise. Clojure's library composition approach to everything only 
>> goes so far with large web applications, as Aaron Bedra reminded us in 
>> March last year: www.youtube.com/watch?v=CBL59w7fXw4 . Less manpower 
>> means less momentum and more bugs. Furthermore, I have a hunch that 
>> Clojure's poor adoption as indicated by Indeed.com maybe due to this 
>> immaturity in the web framework sphere. Why is it that Elixir, with a 
>> much smaller community and lifespan than Clojure's, has managed to put 4 
>> times as much mindshare into its main web framework when its module 
>> output, as measured by modulecounts.com, is a tiny fraction of 
>> Clojure's? 
>>
>> gvim 
>>
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://gr