Clojure needs a web framework with more momentum

[gvim]

I recently did some research into web frameworks on Github. Here's what
I found:


FRAMEWORK LANG CONTRIBUTORS COMMITS

Luminus Clojure 28 678
Caribou Clojure 2 275

Beego Golang 99 1522

Phoenix Elixir 124 1949

Yesod Haskell 130 3722

Laravel PHP 268 4421

Play Scala 417 6085

Symfony PHP 1130 20914

Rails Ruby 2691 51000


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

[Fluid Dynamics]

Those numbers aren't going to be an apples-to-apples comparison. "Contributors" may be lower for the Clojure libs because as a Lisp it enables them to be enormously more productive (up to 10x) than the other languages. The greater expressiveness allows the same functionality to live in a smaller codebase (as measured in LOC), likely reducing the number of commits for a given amount of functionality. And Clojure's concurrency and immutability constructs likely reduce the number of bugs, and thus the number of tickets and the number of commits whose primary purpose is to fix bugs.

[gvim]

On 02/05/2015 22:06, Fluid Dynamics wrote:
>
> Those numbers aren't going to be an apples-to-apples comparison.
> "Contributors" may be lower for the Clojure libs because as a Lisp it
> enables them to be enormously more productive (up to 10x) than the other
> languages. The greater expressiveness allows the same functionality to
> live in a smaller codebase (as measured in LOC), likely reducing the
> number of commits for a given amount of functionality. And Clojure's
> concurrency and immutability constructs likely reduce the number of
> bugs, and thus the number of tickets and the number of commits whose
> primary purpose is to fix bugs.
>

Considering 3 of those languages - Elixir, Haskell and Scala - are
functional with immutable data structures and equivalent concurrency to
Clojure's I can't quite agree with you.

gvim

[Fluid Dynamics]

Ah, but none of them are Lisps. No macros, no DSLs, and thus much less of the productivity/code-size-efficiency gains.
 

[gvim]

On 02/05/2015 22:25, Fluid Dynamics wrote:
>
> Ah, but none of them are Lisps. No macros, no DSLs, and thus much less
> of the productivity/code-size-efficiency gains.
>

Elixir's macros are quite Lispy under the hood and all 3 languages can
arguably generate sophisticated DSLs. I'm as much a fan of Lisp's
benefits as you are but I honestly can't attribute this manpower
discrepancy to the fact that Clojure is a Lisp. I think the community's
overemphasis on library composition could be a bigger factor.

gvim

[Fluid Dynamics]

"Under the hood" is a delicate way of saying "not homoiconic", whereby 90% of the benefit goes away. In any event, the three functional languages you name also do have lower numbers for commits and contributors (three-digits) than the really messy imperative mutability-everywhere languages (four-digits), showing that they are "part of the way there" but not as advanced as Clojure. :)

[Plínio Balduino]

Excuse me, Fluid. I have to agree with gvim.

But I have the same impression. I think the state of Clojure development for web is quite immature if you compare with other languages.

To be clear, I could spend lines and lines talking about all the high quality Clojure library related to web applications and we have great web applications in the real world like Prismatic and Nubank, so I'm not criticizing any of the valuable friends that spent their personal time building awesome stuff.

But, "there's always a but", I still can't see all that claimed productivity with Clojure for web that I got, for example, I got with Rails or Flask.

I have friends here working to solve this issue, but I don't think the scenario will change soon.

That is my two cents.

Plínio

--
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.

[James Reeves]

On 2 May 2015 at 21:43, gvim <gvi...@gmail.com> wrote:

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 .

I agree that web development in Clojure can be improved, but I don't see why it follows that we should be writing web frameworks.

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?

By what measurement are you drawing this conclusion?

You've listed contributors and commits for single repositories, but that will clearly produce erroneous results when comparing a monolithic project to a very modular one.

- James

[Christopher Small]

I disagree with the premise entirely. I think that the Clojure community has just done a better job of building smaller, more modular tooling. And this is frankly something I prefer, and find refreshing in the Clojure sphere (as compared with my previous Rails webdev experience).

Note that to put things on the same footing, you'd want to be noting that Luminus depend on Ring and Compojure, with commit counts 761 and 865 resp, and contributor counts 73 and 29 resp.

I'm not saying that Clojure can't improve it's offering in web dev with added libraries etc, but I wouldn't want to see us move away from the modularity with which we've built things, because I think it's a win.

Just my 2 c

Chris Small

[gvim]

On 03/05/2015 00:39, James Reeves wrote:
>
> I agree that web development in Clojure can be improved, but I don't see
> why it follows that we should be writing web frameworks.
>

Luminus is a web framework. We don't have to write web frameworks at
all, that's true. Neither did the Ruby community. They had Sinatra
before Rails but it was Rails which brought them huge mindshare and,
more importantly, plenty of developers earning a good living. All I'm
saying is there's room for both approaches but the outside world, where
people make a living, tends to prefer web frameworks. Clojure needs
something like Scala's Play/Reactive framework which has a bit of
industry momentum behind it. It's been 5 years since Clojure 1.0 so the
excuse that Clojure is still finding its feet is no longer valid.

> 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 <http://modulecounts.com/>, is a tiny fraction of

> Clojure's?
>
>
> By what measurement are you drawing this conclusion?
>
> You've listed contributors and commits for single repositories, but that
> will clearly produce erroneous results when comparing a monolithic
> project to a very modular one.
>

Elixir's Phoenix is as modular as Luminus so the comparison is valid.
The 2 leading Rails developers behind it - Jose Valim and Chris McCord -
recognised before Elixir reached 1.0 that a strong web framework was
essential to gaining mindshare.

gvim

[gvim]

Most decent web frameworks these days are built from modular components
so this distinction is a bit laboured. Rails is built on top of Active*
and Rack so the Ring/Compojure distinction is illusory. Laravel is built
on top of Symfony components it could be argued that Symfony has played
a similar role to Ring/Compojure in the PHP community.

Clojure's modular approach is great but I just don't see the need to
polarise when there's such a strong business case for structured
frameworks. If you look at most of the jobs in web development at
Indeed.com they're almost exclusively framework-based. Modular is great
but it would also be nice to see a few more Clojure jobs advertised.

gvim

[Luc Prefontaine]

Business case...

I have two business cases at hand.

None can be done with frameworks w/o making the end products look like any other one in their respective space and having to bend to framework limitations.

Being disruptive requires a different approach.

Having to write all these individual libs ourselves would make these two product sets much more difficult to create. Experimentation would also suffer a lot.

Now we have the elements to create new recipes instead of everyone eating the same dry cake that's been left on the shelf for a year.

Aside from HR tagging, I see little value in a branded framework.
Being reluctant to be part of a tagged herd, I can't agree with you :)

But given my (bad) character this may explain that :)

Luc P.

> --
> 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.
>

--
Luc Prefontaine<lprefo...@softaddicts.ca> sent by ibisMail!

[Christopher Small]

For rails sure. What about Elixer & Yesod? Those could be just as modular for all I know... I'm just saying that one way or the other, those things should be taken into account since they are important.

OO junk leads to bloat.

--
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 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+u...@googlegroups.com.

[gvim]

On 03/05/2015 01:37, Luc Prefontaine wrote:
> Business case...
>
> I have two business cases at hand.
>
> None can be done with frameworks w/o making the end products look like any other one in their respective space and having to bend to framework limitations.
>
> Being disruptive requires a different approach.
>
> Having to write all these individual libs ourselves would make these two product sets much more difficult to create. Experimentation would also suffer a lot.
>
> Now we have the elements to create new recipes instead of everyone eating the same dry cake that's been left on the shelf for a year.
>
> Aside from HR tagging, I see little value in a branded framework.
> Being reluctant to be part of a tagged herd, I can't agree with you :)
>
> But given my (bad) character this may explain that :)
>
> Luc P.

All I'm saying is it doesn't have to be either/or. Clojure is big enough
for modular and (relatively :)) monolithic approaches.

gvim

[James Reeves]

On 3 May 2015 at 01:02, gvim <gvi...@gmail.com> wrote:

On 03/05/2015 00:39, James Reeves wrote:

I agree that web development in Clojure can be improved, but I don't see
why it follows that we should be writing web frameworks.

Luminus is a web framework. We don't have to write web frameworks at all, that's true. Neither did the Ruby community. They had Sinatra before Rails but it was Rails which brought them huge mindshare and, more importantly, plenty of developers earning a good living.

Sinatra was written three years after Ruby on Rails.

 

All I'm saying is there's room for both approaches but the outside world, where people make a living, tends to prefer web frameworks.

Are we ultimately aiming for something that's popular, or something that ultimately works better?

 

You've listed contributors and commits for single repositories, but that
will clearly produce erroneous results when comparing a monolithic
project to a very modular one.

Elixir's Phoenix is as modular as Luminus so the comparison is valid. The 2 leading Rails developers behind it - Jose Valim and Chris McCord - recognised before Elixir reached 1.0 that a strong web framework was essential to gaining mindshare.

Luminus is essentially a Leiningen template. I'm not too familiar with Phoenix, but my initial impression of the source and docs is that's it's more than just an application template.

To pick one example, Phoenix appears to have its own routing system, where Luminus depends on Compojure. If Luminus and Compojure were counted together, your statistics for number of commits and contributors would double.

Without accounting for how much functionality is in the repository itself, and how much is pulled in from other libraries, comparing commits or contributor numbers is meaningless.

- James

[Sean Corfield]

On Sat, May 2, 2015 at 1:43 PM, gvim <gvi...@gmail.com> wrote:

One could conclude from this that the Clojure community isn't that interested in web development but the last Clojure survey suggests otherwise.

Yes, lots of web apps get built with Clojure.

 

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.

I think Clojure's adoption is just fine for its age and its uniqueness. It's not the sort of language that mainstream developers are going to rush to, to build general web apps. People who adopt Clojure generally do so because they want to build software "The Clojure Way". That they also build a lot of web apps is somewhat incidental.

Every now and then we see a call for a "big web framework" and every now and then someone builds a "big web framework"... but the people who call for these frameworks don't seem to rally around the frameworks that appear, so it's really no surprise that these frameworks don't have the traction you're looking for...

I've used some "big web frameworks". I don't like them.

Years ago, for another language, I collaborated on almost every major web framework that appeared. I was lead developer on a few of them for various periods of time. Six years ago, I created my own very small, convention-based framework for that language. It's one of the top two frameworks for that language in terms of downloads, users, and mindshare. We run a bunch of high traffic production stuff on it at work. A few years back I decided to port it to Clojure, mostly as a personal challenge, but also because I thought it might be useful at work. Clojure's focuse on libraries meant that I only needed to write 400 lines of code and leverage Ring, and Selmer, to get it up and running. I haven't promoted it in the Clojure community yet because I'm not yet using it in production but I think it's a good solution -- but it's definitely not a "big web framework".
--

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

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

[John Chijioke]

What is a web framework?

[Mark Engelberg]

Last week, at the Clojure/West conference, someone (I think it was Brandon Bloom) summed up the general vibe well, by saying something along the lines of, "We now have all the pieces in place to make web development an order of magnitude more productive than in any other language, we just need to figure out how to put it all together and make that happen."

I think that's right.  From a technological standpoint, I think we're there.  The things we most need are informational resources and higher-level shared resources, such as UI widgets.  For example:

How do we use Buddy/Friend effectively to achieve secure web apps?  (The docs are not sufficiently informative for those who haven't thought much about security and assume too much prior knowledge).

How do we effectively leverage some of the more advanced Clojure-oriented webservers such as Aleph and Immutant?

Clojure is great for creating new, disruptive web models, but what's the easiest path to creating something that can be done trivially with, say, Drupal or Django?

Since more and more people are working with Reagent/Om/etc., we need as many Bootstrap-like widgets as possible for those tools, and more informational resources about how to use these new reactive models effectively, for example, how to do animated UIs.

Are there reusable components like, say, shopping baskets?

[Mike Rodriguez]

Not really related. But I just want to chime in to say I love this quote from Fluid in regards to the DSL bit:

"Under the hood" is a delicate way of saying "not homoiconic", whereby 90% of the benefit goes away.

+1 to that!

[Sean Corfield]

On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg <mark.en...@gmail.com> wrote:

Clojure is great for creating new, disruptive web models, but what's the easiest path to creating something that can be done trivially with, say, Drupal or Django?

The question tho' is why you'd want to use Clojure for something that is already trivially solved with free packaged software for widely used scripting languages where cheap, plentiful developers are falling over themselves to help... :)

Clojure doesn't have to be the solution for every problem. It certainly doesn't need to be the solution for low-value problems...
--

[Mark Engelberg]

Because many problems start out as things that can be solved with standard solutions and then evolve into something more elaborate.  Best to start with something that can both do the easy things, and handle the more complex stuff as well.

--

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.

[Sean Corfield]

On Sat, May 2, 2015 at 10:20 PM, Mark Engelberg <mark.en...@gmail.com> wrote:

Because many problems start out as things that can be solved with standard solutions and then evolve into something more elaborate.  Best to start with something that can both do the easy things, and handle the more complex stuff as well.

Perfection is the enemy of the good (Gustave Flaubert).

Sean

[Imre Samu]

>Clojure needs a web framework with more momentum

Some people make a big technology decision based on " TechEmpower Framework Benchmarks (TFB)" (round10) 

[ https://www.techempower.com/blog/2015/04/21/framework-benchmarks-round-10/ ]

Should techempower.com framework benchmarks be taken seriously ?

The following clojure frameworks tested by TFB :

Test type: "JSON serialization"

- compojure

- http-kit

- luminus

Test type: "Single query"

- http-kit

- compojure-raw

- luminus-raw

- compojure

- luminus

Test type: "Multiple queries"

-http-kit

-luminus-raw

-compojure

-compojure-raw

-luminus

Test type: "Fortunes"

- compojure

- luminus

Test type: "Data updates"

(nothing)

Test type: "Plaintext"

-compojure -luminus

Regards,

 Imre

gvim

[Sven Richter]

Hi,

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 the rest I agree with what is mostly said here, the beauty of clojure lies in the nature of small composable building blocks and the same goes for frameworks, so, basically it's all there, one just has to put it together. And to not have to put it together by hand time and time again there are leiningen templates.

Best Regards,
Sven

[Colin Fleming]

Because, in my case, I'm going to need a website shortly that I can use to sell Cursive. I'd really like to use Clojure for that. I could use Rails or Django which would make the site itself trivial, except I don't know either of them and then I'm stuck maintaining something in a language and framework I have no interest in and don't understand how to deploy or maintain. Or I could do it in Clojure which means that I understand the libraries, frameworks, deployment and monitoring inside and out, except I now have to implement a shopping cart and integrations with payments gateways etc. Neither of these are great options for me.

--

[Christopher Small]

I really like what you said here Mark:

From a technological standpoint, I think we're there.  The things we most need are informational resources and higher-level shared resources, such as UI widgets.  For example:

I fully agree. I don't think we've moved in a wrong direction at all. Just that we need to continue building on what we already have, and do so in the right directions.

[gvim]

On 03/05/2015 05:24, Sean Corfield wrote:
> On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg <mark.en...@gmail.com
> <mailto:mark.en...@gmail.com>> wrote:
>
> Clojure is great for creating new, disruptive web models, but what's
> the easiest path to creating something that can be done trivially
> with, say, Drupal or Django?
>
>
> The question tho' is why you'd want to use Clojure for something that is
> already trivially solved with free packaged software for widely used
> scripting languages where cheap, plentiful developers are falling over
> themselves to help... :)
>
> Clojure doesn't have to be the solution for every problem. It certainly
> doesn't need to be the solution for low-value problems...

Forgive me if that sounds a little elitist. What if I want to do what
Django can do but in Clojure? If Clojure is a better option there should
be something which can do more than Django. If my only choice is library
composition by definition it doesn't do what Django does well, ie. a
fully-structured setup out of the box with a predictable, best of breed
set of technologies.

There are many businesses, large and small, who will only go with a
well-established web framework with a vibrant community. Sadly,
Clojure's preference for protecting its niche means it will never be an
option for these opportunities, hence its poor showing in job listings.
Do we, as a community, want to be paid for what we do?

There's one factor missing from this discussion which is framework
community. I think there's immense value in the community factor which
emerges when a web framework gains a lot of mindshare. From what I've
read in this thread there will probably never be anything like RailsConf
for a Clojure web framework simply because shared knowledge can only go
so far with the library composition approach.

> Perfection is the enemy of the good (Gustave Flaubert).

"The whole is greater than the sum of its parts." (Aristotle)

gvim

[Sven Richter]

Hi Colin,

Regarding payment I'd choose something like stripe or whatever fits your needs and look for a clojure api or wrapper around a java api. Implementing payment stuff yourself might get you in a lot of legal trouble anyhwere in the world.

However, I'd agree that there may be the need for better documentation on integration of all the libraries, whereas I have to say that luminus does a pretty good job for what it offers, regarding the documentation.

Best Regards,
Sven

[Sven Richter]

Hi,

Am Sonntag, 3. Mai 2015 11:38:14 UTC+2 schrieb g vim:

On 03/05/2015 05:24, Sean Corfield wrote:
> On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg <mark.en...@gmail.com
> <mailto:mark.en...@gmail.com>> wrote:
>
>     Clojure is great for creating new, disruptive web models, but what's
>     the easiest path to creating something that can be done trivially
>     with, say, Drupal or Django?
>
>
> The question tho' is why you'd want to use Clojure for something that is
> already trivially solved with free packaged software for widely used
> scripting languages where cheap, plentiful developers are falling over
> themselves to help... :)
>
> Clojure doesn't have to be the solution for every problem. It certainly
> doesn't need to be the solution for low-value problems...

Forgive me if that sounds a little elitist. What if I want to do what
Django can do but in Clojure? If Clojure is a better option there should
be something which can do more than Django. If my only choice is library
composition by definition it doesn't do what Django does well, ie. a
fully-structured setup out of the box with a predictable, best of breed
set of technologies.

There are many businesses, large and small, who will only go with a
well-established web framework with a vibrant community. Sadly,
Clojure's preference for protecting its niche means it will never be an
option for these opportunities, hence its poor showing in job listings.
Do we, as a community, want to be paid for what we do?

Again I am missing some exact requests on what can be done in django that cannot be done in clojure? This by no means an offense, I am just curious about your experiences.

Best Regards,
Sven

[Dylan Bijnagte]

In my experience many applications are built using web frameworks because the often complex data models of corporate apps require significant UI for administration and UI or API for data entry. The application gets written using a language / framework that is optimized around that. Clojure is well positioned to handle the data processing portion of these applications where there real business value is derived, unfortunately that ends up getting implemented in the same language / framework due to developer familiarity and concerns about supportability.

Benefits of opinionated frameworks include:

• free developers up from the need to make decisions about libraries 
• consistent project structure enables people familiar with the framework to quickly get oriented
• keep less experienced developers from making major architecture mistakes.
• developers don't need to be experts on everything

Right now the cost of entry to Clojure web development is high because of the fragmentation, documentation, and paradigm shift. I believe that highly skilled developers can be far more productive using Clojure once familiar with the ecosystem and language. They have to get started though and there are often junior people on the team that will have a harder time coming up to speed.

My feeling is that if the "low value" portions of the application can't be trivially written in Clojure then the complex parts won't be either.

Dylan 

[Herwig Hochleitner]

​To me, the idea of a framework is embodied by a set processing tools, whose primary design goal is to work best in concert with each other.

I rather enjoy working with libraries, whose primary design goal is to work well in any technology stack. I don't think those are mutually exclusive, but working with libraries often sacrifices the ability to put a brand on your technology stack, at first, because building out of libraries means mixing and matching.

I think the right way towards a more coherent whole is to identify libraries with overlapping concerns and for their maintainers to converge on a common data format. Then "framework" brands can be created as specific compositions of those general purpose libraries. Ring, for example, pull this off with great success: I'm pretty sure that any clojure web framework is going to support it as an http representation.

Of course, one might say that making it easy to create a framework hurts the goal of getting the community unified behind a single brand. Then again to me, being able to quickly create a highly specific surface to very general and composable innards, is a big part to the purpose of homoiconicity.

That said, I do feel positive towards providing orientation on how to get stuff done, but I would urge anybody attempting to provide it, to first view any of their puzzle pieces in isolation and ask: "How would somebody use this, who took no part in the rest of my framework"

[larry google groups]

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 level of composition. 

[gvim]

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 level of composition.
>

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. Ruby and Python have had
lightweight composable alternatives for many years but Rails and Django
still dominate. I'm not against the composition at all. I just think we
need more structured alternatives that we can at least brand and market
as well as teach to Clojure beginners.

gvim

[Timothy Baldridge]

And that's the power of a system written in Clojure. You're not forced into some industry standard way of doing things that may not fit your needs. 

When I read Colin's report on Clojure at RoomKey http://www.colinsteele.org/post/23103789647/against-the-grain-aws-clojure-startup or Paul talking about Clojure at Consumer Reports (https://www.youtube.com/watch?v=BNkYYYyfF48), or how walmart uses Clojure (https://www.youtube.com/watch?v=av9Xi6CNqq4), I don't see one-stop-solutions. That's the niche I see Clojure fitting in. Not in the "Let's build a site in 10 hours", niche. But in the "We have a year to do something no one has done before, so let's stop and think hard for a month before we even start to write our code"

But isn't that what Rich has been ranting about for years? Clojure isn't easy, but it is (mostly) simple. Simple software may slow you down at first, but as your project matures, you'll make up that time in spades due to the simplicity of your system. 

Timothy

--
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.

--

“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)

[Andy Fingerhut]

“What you're supposed to do when you don't like a thing is change it. If you can't change it, change the way you think about it. Don't complain.” 
― Maya Angelou

[Mohit Thatte]

+1 to what Sven said.

To quote from  Rails is Omakase

Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn't designed to appeal to the taste of everyone, everywhere.

This is exactly what projects like Luminus do - curate a list of libraries that play well together and give you the functionality you need to build a web app.

The downside of a 'framework' like Rails is that you get the whole boatload of dependencies whether you need them or not. With lein templates, you are free to pick and choose what you like.

~Mohit

 

--
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.

--

-Mohit Thatte

[Fluid Dynamics]

On Sunday, May 3, 2015 at 2:12:02 AM UTC-4, Sven Richter wrote:

Hi,

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 the rest I agree with what is mostly said here, the beauty of clojure lies in the nature of small composable building blocks and the same goes for frameworks, so, basically it's all there, one just has to put it together. And to not have to put it together by hand time and time again there are leiningen templates.

So, basically, Clojure *is* the framework? :)

[Colin Yates]

Clojure + developer's skill + existing libraries + custom code is the framework.

--

[Herwig Hochleitner]

2015-05-03 16:27 GMT+02:00 Fluid Dynamics <a209...@trbvm.com>:

So, basically, Clojure *is* the framework? :)

Exactly! As is any language that you choose to work in. That means that buying into at least one framework is nessecary to get started with programming anyway.

With clojure, the predominant attitude seems to be: If I can buy into one framework, that gives me a skinnable, turing-complete language and focuses on composition, why should I buy into further frameworks, that can only distance me from my peers that use something else?

That said: I'd love to see a set of well-maintained, well-documented project templates to emerge from a common brand, for the benefit of beginners and 10h website creators.

[Plínio Balduino]

Mr Herwig

"That said: I'd love to see a set of well-maintained, well-documented project templates to emerge from a common brand, for the benefit of beginners and 10h website creators."

THIS is exactly what I was discussing right now with a friend.

I think you nailed it.

--

[Andrew Rosa]

Extending a little more on Herwig's previous idea, a good "Clojure framework" could be a collection of schemas, protocols and interfaces. A "ring for the whole stack".

Creating our stack will be a matter of composing our web pipeline with our desired libraries. Even templates could become unnecessary, despite being very helpful to lower the entry point for new developers. IMHO *that* is the power of data driven architectures that we like to sell, isn't?

[]'s

Andrew

[larry google groups]

This can be read in a manner opposite to what you intended: 

> There's one factor missing from this discussion which is framework 
> community. I think there's immense value in the community factor which 
> emerges when a web framework gains a lot of mindshare. From what I've 
> read in this thread there will probably never be anything like RailsConf 
> for a Clojure web framework simply because shared knowledge can only go 
> so far with the library composition approach. 

A personal story: this week I was at a web agency that was discussing how to proceed with a new client. The web agency has several engineers who mostly work with PHP, and they love the Symfony framework. They had one engineer who wanted to start using Rails for their web projects. I was not part of their team, but I was invited to speak, so I said that Rails would offer them some benefits. 

One of the PHP engineers then asked me "Can you name any advantage that Rails has over PHP?" 

I said, "Ruby is more composable than PHP. Since 2005 PHP has been influenced by Java and it has developed a somewhat literal style. That makes it harder to integrate 3rd party code. Ruby allows a level of runtime reflextion and meta-programming that makes it easy to integrate 3rd party code. There is a great wealth of gems that allow you to implement all of the standard features that you might need. And it takes very little effort to integrate those 3rd party gems." 

And the PHP engineer replied: "Are you aware how huge the Symfony community is? Are you aware how many plugins there are? There is vast wealth of plugins for Symfony." 

And then I said something which he had apparently never realized, and it clearly had a big impact on him: "In Ruby, the gems exist at the level of the language. In PHP, the plugins exist at the level of the framework. You can not use a Symfony plugin with WordPress, nor can you use a WordPress plugin with CakePHP. In PHP, ever CMS has its own plugin system. In Ruby, there are few gems that are specific to Rails. Most gems can be used in a great variety of contexts, because composing code in Ruby is much easier than composing code in PHP." 

And that seemed to settle the debate: they would try Ruby. 

But I'll point out, if they had been open to hearing something a bit more radical, I could have continued and pointed out that Ruby has it limits, and the very fact that something like RailsConf exists suggests that Ruby has a limit. In a truly composable language, where all code can be used with any code, the community will exist at the level of the language, not at the level of any system written in that language.

[Hildeberto Mendonça]

Hello Gvim,

On Sun, May 3, 2015 at 11:37 AM, gvim <gvi...@gmail.com> wrote:

On 03/05/2015 05:24, Sean Corfield wrote:

On Sat, May 2, 2015 at 8:18 PM, Mark Engelberg <mark.en...@gmail.com

<mailto:mark.en...@gmail.com>> wrote:

    Clojure is great for creating new, disruptive web models, but what's
    the easiest path to creating something that can be done trivially
    with, say, Drupal or Django?

Clojure doesn't have to be the solution for every problem. It certainly
doesn't need to be the solution for low-value problems...

Forgive me if that sounds a little elitist. What if I want to do what Django can do but in Clojure? If Clojure is a better option there should be something which can do more than Django. If my only choice is library composition by definition it doesn't do what Django does well, ie. a fully-structured setup out of the box with a predictable, best of breed set of technologies.

I would recommend watching the video "Simple made easy" by Rich Hickey: http://www.infoq.com/presentations/Simple-Made-Easy . By watching this video, I realized there is no sense writing frameworks in Clojure. Not because the video says so, but because the approach of using libraries to compose solutions makes a lot more sense. Django and Rails are examples of easy technologies, while Clojure and its libraries are an example of simple. You will also understand Sean when he said that Clojure "doesn't need to be the solution for low-level problems".

Do you actually program in Clojure? Have you experienced web development in Clojure? I'm asking that because my personal experience was actually good. I'm happier writing Clojure web apps adding libraries on demand instead of having a huge piece of software with a lot of things that I don't use at all.

[larry google groups]

> 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."

[Leon Grapenthin]

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. 

[Christopher Small]

Perhaps we need to see an example of a minimalistic/modular approach that _has_ won out.

Node's express has > 5k commits, 177 contribs, >18k stars. Possibly the most popular node framework out there. Tagline?

> Fast, unopinionated, minimalist web framework for node.

[Angel Java Lopez]

I could add something about NodeJS arena:

There are web frameworks, but the most popular (AFAIK) way is the use of:

- Express for MVC routing and middleware management (before middle ware management was Connect task), and template engine coordination

- NPM ecosystem for any library or middleware needed

I guess that "big web frameworks" are more suitable for simple application without a lot of changing requirements. Every time I got an application with non-trivial logic, and agile embracing the change, I preferred the "simple-way" insteof the "easy-way". 

And "small web frameworks" are in charge of:

- middleware chaining

- routing a la MVC

- coordinate template rendering

In contrast, PayPal developed kraken http://krakenjs.com/ adding some conventions and libraries

Angel "Java" Lopez

@ajlopez

--

[Luc Préfontaine]

Here in Morocco, the dominant web technology is... PHP. Tadaaa !

The're not even considering Raills or anything more 'advanced' for that matter.

It's really an evolution ladder. People got on the 'framework' 'one fit for all band after trying
things like PHP, JSP, ... and now realizing that it does not solve the issues they just leave.
It will certainly happened with PHP and Rails.

These solutions are geared toward some specific problem scopes. As soon as the business
needs outrun what they can easily solve you are short of something else.

The industry has been searching for a silver bullet solution for decades.
In the early 80s, late 70s, CASE tools were suppose to be that bullet, (basic stuff in today's
world, git, ant, ....).

Open systems then picked up, blabla, .... None of that fully delivered their promises. Ever.
They helped climb the ladder however. In small steps...

And now we have these frameworks that supposedly can ease the pain in any
circumstances. They do fill the role up to a certain glass ceiling, the unforeseen business needs
that make them blow in pieces because they can't be easily stretched, twisted, bended, ...

Each of these initiatives were motivated by software creation automating and
supposedly shrinking the costs while trying to downplay the need for an essential ingredient...
Us. Wetware.

I think it's a mirage.

Maybe the solution has been there for decades under our eyes. Human beings.
Capable of assembling solutions grater than the sum of their parts. Capable of bending the
software as needed to do new stuff instead of having to fully rewrite stuff because shoes
are becoming to tight. In one word adapt.

This assumes that you have components to build from and people that can compose them
as needed.
Not some kind of frozen approach in time to software development were roles are pre-assigned
and any change outside of this limited scope becomes a challenge by itself.

The 'structure' needed here has nothing to do with walls and concrete. We need brain power
to tear down/recompose things and stop thinking that processes, normalization, herd tagging,
etc can lead us to work more efficiently. Processes, conventions, ... may help but at a low scale.

Not pushed by at the scale of the whole software industry like these days Variety is the key.

Luc P.

> --
> 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.
>

--
Luc Préfontaine<lprefo...@softaddicts.ca> sent by ibisMail!

[Colin Fleming]

A shopping cart. All the available Java ones require a J2EE stack.

--

[gvim]

On 03/05/2015 19:01, Hildeberto Mendonça wrote:
> I would recommend watching the video "Simple made easy" by Rich Hickey:
> http://www.infoq.com/presentations/Simple-Made-Easy . By watching this
> video, I realized there is no sense writing frameworks in Clojure. Not
> because the video says so, but because the approach of using libraries
> to compose solutions makes a lot more sense. Django and Rails are
> examples of easy technologies, while Clojure and its libraries are an
> example of simple. You will also understand Sean when he said that
> Clojure "doesn't need to be the solution for low-level problems".
>
> Do you actually program in Clojure? Have you experienced web development
> in Clojure? I'm asking that because my personal experience was actually
> good. I'm happier writing Clojure web apps adding libraries on demand
> instead of having a huge piece of software with a lot of things that I
> don't use at all.

Rich Hickey's videos got me into Clojure so, yes, I've watched all of
them several times.

Yes, I do program in Clojure. Exclusively at the moment as I'm currently
free to work on my own startup project. I'm using Luminus and enjoy it
so I didn't start this thread out of dissatisfaction with Luminus itself
but more from a sense of frustration at seeing so little input coming
from the community compared with other languages.

gvim

[James Reeves]

On 3 May 2015 at 23:36, gvim <gvi...@gmail.com> wrote:

Yes, I do program in Clojure. Exclusively at the moment as I'm currently free to work on my own startup project. I'm using Luminus and enjoy it so I didn't start this thread out of dissatisfaction with Luminus itself but more from a sense of frustration at seeing so little input coming from the community compared with other languages.

By what measurement?

- James 

[gvim]

On 03/05/2015 23:55, James Reeves wrote:
> On 3 May 2015 at 23:36, gvim <gvi...@gmail.com

I posted some figures at the beginning of this thread where I was
comparing frameworks, not components. A framework is more than the sum
of it's components so I don't think comparing Ring and Compojure to
Phoenix or Play is relevant. Clojure frameworks aren't the only ones
built from components.

gvim

[Leon Grapenthin]

If it is more than the sum of its components, what does it add? 

What are you missing that couldn't be done in a component or template, that other languages have because they have frameworks?

[James Reeves]

On 4 May 2015 at 00:02, gvim <gvi...@gmail.com> wrote:

I posted some figures at the beginning of this thread where I was comparing frameworks, not components. A framework is more than the sum of it's components so I don't think comparing Ring and Compojure to Phoenix or Play is relevant. Clojure frameworks aren't the only ones built from components.

So you're using measurements that are clearly biased toward monolithic codebases, and you've discovered that Clojure, a language that has few monolithic codebases, is underrepresented?

- James

[James Reeves]

On 4 May 2015 at 00:51, Jason Whitlark <ja...@whitlark.org> 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

[Jason Whitlark]

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.

What Andrew said above: 

Extending a little more on Herwig's previous idea, a good "Clojure framework" could be a collection of schemas, protocols and interfaces. A "ring for the whole stack".

hit the nail on the head.  

The problem with not being able to solve low value problems with Clojure is that it forces people to split their attention between Clojure web development and Rails/Django/whatever development.  Like it or not, lots of decisions get made on "adequate across a wide range of problems", with languages like Python or Ruby winning out.  

Polyglot programming is a necessity, but resorting to it unnecessarily is a trade off many people won't make.

~Jason

[Brian Marick]

Sven Richter wrote:
> For the rest I agree with what is mostly said here, the beauty of
> clojure lies in the nature of small composable building blocks and the
> same goes for frameworks, so, basically it's all there, one just has to
> put it together.

If composable building blocks are superior to frameworks (which I'm
inclined to believe), there should be impressive examples to point
people at. What are those?

[Ilya Ivanov]

I recently did some research into web frameworks on Github. Here's what I found

I've noticed that you didn't include pedestal (https://github.com/pedestal/pedestal). I don't have personal experience with it, but I think it is aimed at providing framework-like functionality with a Clojure feel.

[Mark Engelberg]

On Sat, May 2, 2015 at 11:12 PM, Sven Richter <sve...@googlemail.com> 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.

[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

Luminus        Clojure            28        678
Caribou        Clojure             2        275

Beego        Golang            99        1522

Phoenix        Elixir              124        1949

Yesod        Haskell           130        3722

Laravel        PHP                268        4421

Play                Scala               417        6085

Symfony        PHP                1130        20914

Rails        Ruby               2691        51000


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

[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.

[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.

--

[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.

[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

--
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.

--

Andrey Antukh - Андрей Антух - <andrei....@kaleidos.net> / <ni...@niwi.be>

http://www.niwi.be

https://github.com/niwibe

[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

[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

[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

[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

[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

[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 <ernie....@gmail.com> 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.

--
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.

--

“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)

[gvim]

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

[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.

[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.

[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

[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

[Marcus Blankenship]

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

--
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.

Best,

Marcus

Marcus Blankenship

\\\ Technical Coach, Startup Advisor, Calvinist

\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

[Christopher Small]

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

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+u...@googlegroups.com.

[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. 

[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.

[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.  

[Sean Corfield]

On May 4, 2015, at 10:53 AM, Josh Kamau <joshn...@gmail.com> 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)

[Josh Kamau]

@Sean, i wanted totally stateless backend. 

[Sean Corfield]

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

Without a database? :)

[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

--
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.

[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".

[Gregg Reynolds]

On May 4, 2015 7:16 AM, "Eric MacAdie" <emac...@gmail.com> 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.

[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.

[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.  

[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. 

[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

[gvim]

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

gvim

[Raoul Duke]

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

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

[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

[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.

[gvim]

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

[Sean Corfield]

On May 4, 2015, at 4:10 PM, gvim <gvi...@gmail.com> 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.

[Kyle Cordes]

 
On May 4, 2015 at 3:51:23 PM, Josh Kamau (joshn...@gmail.com(mailto:joshn...@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

[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.

[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 level of composition.
>

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. Ruby and Python have had
lightweight composable alternatives for many years but Rails and Django
still dominate. I'm not against the composition at all. I just think we
need more structured alternatives that we can at least brand and market
as well as teach to Clojure beginners.

gvim