Is Clojure right for me?

[Massimiliano Tomassoli]

Hi,
I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure.

[tao]

http://pedestal.io/

http://www.luminusweb.net/

-- 

tao

Sent with Sparrow

On Thursday, December 26, 2013 at 5:06 AM, Massimiliano Tomassoli wrote:

Hi,
I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure.

--
--
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/groups/opt_out.

[Devin Walters]

http://hoplon.io/#/home/

http://caribou.github.io/caribou/docs/outline.html

-- 

Devin Walters

[James Reeves]

What sort of web development were you planning to do?

- James

On 25 December 2013 21:06, Massimiliano Tomassoli <kiuh...@gmail.com> wrote:

Hi,
I'm not sure if Clojure is the right language for me. I'd like to use Clojure mainly for web development but I don't know if it's already mature enough to be productive. For instance, Scala has Play, Groovy has Grails, etc... If I'm not wrong, Clojure doesn't have a well-established framework for web development. I'm intrigued by Clojure because I like functional programming, but I need to be productive and, alas, I don't have time to learn Clojure just for my pleasure.

--

[Alex Baranosky]

I'm still partial to Ring.

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 11:16:07 AM UTC+1, James Reeves wrote:

What sort of web development were you planning to do?

I'd like to build websites. What kind depends on what my clients need.

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 7:55:05 AM UTC+1, Devin Walters (devn) wrote:

http://hoplon.io/#/home/

http://caribou.github.io/caribou/docs/outline.html

On Thursday, December 26, 2013 at 12:26 AM, tao wrote:

http://pedestal.io/

http://www.luminusweb.net/

Why so many frameworks? It's difficult to decide which one to use and you'll find fewer people that use the same framework and can answer your questions.

[James Reeves]

My recent Clojure web development has revolved around web services, either internally as part of a larger system, or as an external-facing API. Clojure is well-equipped in this area.

I can offer less advice around the classic RoR use-case of a form-based website with a SQL back end. Most of the things I work on doesn't overlap much with that architecture.

- James

[Malcolm Sparks]

Hi Massimiliano.

The absence of a well-established framework for web development in Clojure is not a sign of its immaturity (rather the opposite). Web frameworks can give you some increased productivity to begin with, but as soon as you need to do something that isn't naturally supported by your chosen web framework you're in trouble, and that's when productivity drops off a cliff as you struggle to bend the web framework to your requirements. For example, you choose a web framework with good REST support, then find out later you need to add web sockets.

I've written and deployed about a dozen serious web applications using Clojure. My opinion is the best strategy that guarantees long-term productivity is to build your system from a set of smaller components that you choose 'a la carte'. That way, if your requirements change you can swap in and out other components as you need to. I would guess that the vast majority of Clojure web applications are written this way, which is why you don't see widescale adoption of a particular web 'framework' by the Clojure community. Instead, Clojure developers pick from a set of constituent parts: Jetty, http-kit, Ring, Compojure, Hiccup, Enlive, Stencil, Liberator, domina, dommy, C2, Om, <shameless-plug>bidi</shameless-plug>, and so on and so on. The fact that these components all fit together so well is one of the truly outstanding features of the Clojure platform. Few languages come close to this level of integration, which is why they actively curate frameworks.

Investing time in Clojure is both pleasurable and productive. It's a question of whether you want 'short-term' productivity to meet a particular project goal (choose a web framework), or sustainable productivity to deliver value to your users over the longer term (choose to learn, understand and utilize a set of components from the wide pool that the Clojure community has created).

Regards,

Malcolm

[Massimiliano Tomassoli]

Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure?

[tao]

Yes, I feel framework is a patch to a language. Use framework can do some thing productively, but also limit you do some thing poorly. 

Prefer Libraries to Frameworks

http://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html

-- 

tao

Sent with Sparrow

--

[James Reeves]

On 26 December 2013 16:32, Massimiliano Tomassoli <kiuh...@gmail.com> wrote:

Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure?

You write functions. To quote Alan J. Perlis:

It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.

IMO, OOP just makes it harder to build modular systems, because OOP involves a lot of implicit connections between components. Clojure, and other functional languages, tend to emphasise isolation more.

- James

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 7:51:39 PM UTC+1, James Reeves wrote:

On 26 December 2013 16:32, Massimiliano Tomassoli <kiuh...@gmail.com> wrote:

Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure?

You write functions. To quote Alan J. Perlis:

It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures.

Classes or objects are not simple data structures.
 

IMO, OOP just makes it harder to build modular systems, because OOP involves a lot of implicit connections between components. Clojure, and other functional languages, tend to emphasise isolation more.

Why implicit? Objects communicate through well-defined channels. OOP can certainly be misused but it served me well for over 20 years (C++/C#). And Scala proves that FP and OOP are orthogonal paradigms. I can't see how the lack of OOP is a good thing for Clojure, honestly. I'm willing to give up mutability because I never programmed that way and I believe it can be a good thing (after I get used to it), but giving up OOP means going back to something I already know and I don't like.

[Dennis Haupt]

exactly which part of OOP is missing in clojure that you would like to use?

if you took my java code and ported it to clojure, the main difference would be (a b) instead of b.a , but the main design would be similar

2013/12/26 Massimiliano Tomassoli <kiuh...@gmail.com>

--

[Jeff Heon]

On Thursday, December 26, 2013 11:32:51 AM UTC-5, Massimiliano Tomassoli wrote:

Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure?

This presentation has been really helpful in that regard for me:

Clojure in the Large 

Even though Clojure is not OOP in the way Java is, you can go a long way with Protocols and namespaces, imho.

[Luc Prefontaine]

Agree, classes are not simple
structures, they carry internal
mutable state and hidden behaviours.

Compounding mutable objects
creates a huge brittled context were
system state at any given point in
time is untraceable by a normal
human brain except in simplistic
systems.

Now you could create un mutable
objects but then why bother
creating classes with hidden
behaviours if there is no hidden
state ?

Please explain then the advantage
of using classes in this context
versus name spaces to delimit
concerns with high order functions ?

How can you stick to both things
at the same time ?

Luc P.

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

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 9:01:56 PM UTC+1, HamsterofDeath wrote:

exactly which part of OOP is missing in clojure that you would like to use?

if you took my java code and ported it to clojure, the main difference would be (a b) instead of b.a , but the main design would be similar

How can that be? What about encapsulation, inheritance and polymorphism? OOP is not just syntactic sugar.
If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial.

[Gary Trakhman]

Encapsulation:

a) I don't miss it.

b) Functions/private-namespaces/maps/deftypes can serve this purpose.

Inheritance:

Clojure provides ad-hoc hierarchies, which give you the desired tree structure of a type-hierarchy, but it is decoupled from implementation details.  You can inherit implementations in lots of ways in clojure.  The simplest conceptually in my mind is simply a hash-map of keys to functions.  Once you start doing it, the question shifts to "do you need a 'this' pointer"? 'this' makes a first argument to a pure function implicit. In most cases, you don't need it.  If you do need it, deftypes or records can fill in the gap.  Records and deftypes also participate in protocols, which provides...

Polymorphism:

Single-dispatch is a degenerate case of more generalized multiple dispatch, which we have via multi-methods.  It turns out that JVMs are pretty good at it, but conceptually I think of 'dispatching on the type' as an implementation detail or optimization, not something to build a language around (java, C++, ...).  Protocols give this kind of fast-implementation polymorphism back to you in a decoupled form.  Reify/proxy are just so darned convenient, both with JVM interfaces and clojure protocols.

There's nothing missing here, it's just disassembled and presented back to you in pieces as part of a practical and philosophical argument.  This is the 'design by decoupling' thought.

What _is_ missing here is an actually helpful static type-system (there's WIP), but immutable data is the best glue for a dynamic one, in my opinion, as it provides easy isolation of components.  I don't miss java's, that's for sure.

Some things that didn't look like syntactic sugar will start to look like syntactic sugar once you get deep into compiler internals and macros :-).  Lisp broke me in this way, but I like it.

--

[James Reeves]

On 26 December 2013 19:53, Massimiliano Tomassoli <kiuh...@gmail.com> wrote:

Why implicit? Objects communicate through well-defined channels. OOP can certainly be misused but it served me well for over 20 years (C++/C#). And Scala proves that FP and OOP are orthogonal paradigms. I can't see how the lack of OOP is a good thing for Clojure, honestly. I'm willing to give up mutability because I never programmed that way and I believe it can be a good thing (after I get used to it), but giving up OOP means going back to something I already know and I don't like.

Clojure provides all the functionality of OOP, but separated into specialised tools.

For grouping functions, we have namespaces. For polymorphism, we have multimethods and protocols. For encapsulation there are closures, and for inheritance we have the "derive" and "isa?" functions.

I've worked with OOP systems for over a decade, but it wasn't until I started using Clojure that really started to understand the separate pieces of functionality that OOP bundles together. I found that there were some pieces I used regularly (such as namespaces), some pieces I used occasionally (polymorphism), and some pieces I didn't use at all (encapsulation and inheritance).

Clojure emphasises "simplicity", which in this case means should aim for tools that perform specific tasks, rather than tools that attempt to tackle everything at once. This is why Clojure doesn't have OOP, because Clojure prefers having a diverse toolbox of individual tools, rather than a single generic tool that acts as a swiss army knife.

Clojure also rejects the idea that we should hide data structures behind an API (i.e. encapsulation). This is the opposite of OOP doctrine, which suggests that data structures need to be hidden to prevent constant refactoring. In practise, I find I need to refactor less with Clojure, while at the same time avoiding the need to hide information, and the repetition that comes with having to re-implement part of the functionality of a map, every time I build an object.

When I started using Clojure, I almost started on an OOP system for it. Within a few weeks, I began to understand that wasn't necessary. After 5 years, I'm very much sold on Clojure's methodology.

I suspect I'm not alone in this, otherwise there would be at least a dozen OO systems for Clojure. To my knowledge, there are zero so far.

- James

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 9:18:06 PM UTC+1, Luc wrote:

Now you could create un mutable
objects but then why bother
creating classes with hidden
behaviours if there is no hidden
state ?

The state is still hidden. Even if the state is immutable:
1) other code could access it and, thus, changing the inner working of your class would break that code;
2) other code could create a new instance of your class with inconsistent internal state.
As you can see, immutability is totally orthogonal to object orientation. Encapsulation is still useful, as are inheritance and polymorphism.

[Softaddicts]

a) encapsulation of unmutable state ? What for ?
b) inheritance ? see a)
c) polymorphism ? Multimethods (which are more flexible) or protocols

Nice words but not much else.

Comparing C versus C++ is fair but this comparison does not relate at all to
Clojure, it's like answering "blue" to the question
"which even number sits between 1 and 3 ?"

I am still waiting for an answer to my previous post btwy...

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/groups/opt_out.
>

--
Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!

[James Reeves]

On 26 Dec 2013 21:04, "Softaddicts" <lprefo...@softaddicts.ca> wrote:
>
> a) encapsulation of unmutable state ? What for ?
> b) inheritance ? see a)
> c) polymorphism ? Multimethods (which are more flexible) or protocols
>
> Nice words but not much else.
>
> Comparing C versus C++ is fair but this comparison does not relate at all to
> Clojure, it's like answering "blue" to the question
> "which even number sits between 1 and 3 ?"
>
> I am still waiting for an answer to my previous post btwy...

Let's be nice. We're supposed to have a welcoming community, not a combative one :)

- James

[Gary Trakhman]

"If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial."

Those are both inexpressive in different ways.  In my opinion java is closer to lisp than C++, given garbage collection, closures (even faked by objects), reflection (code-as-data), classloading (eval).

--

[Softaddicts]

Ok I'll drop the subject. Still cannot understand why people cannot
try something new w/o sticking to the stuff they know already until they are
totally immersed in the new thing. And by that I mean use the new thing as
it was intended.

Then you can generate useful conclusions and get some benefits from
this learning process.

I was just teasing a bit :) If I were to be combative, it would be much worse :)

Luc P.

[john walker]

clojurekoans.com uses Joodo.

https://github.com/slagyr/joodo

What are some other cool sites powered by Clojure?

[Alex Baranosky]

http://preview.getprismatic.com/news/home

--

[Alexander Hudek]

You can define vars to be private to a namespace in clojure, thus preventing (1). In practice, I've found that (2) never comes up. Ultimately, you won't truly appreciate what is being said in this conversation without giving it a chance and trying it out. 

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 10:26:11 PM UTC+1, Gary Trakhman wrote:

"If I were to implement something (complex enough) in C and C++ the differences between my implementations would be far from superficial."

Those are both inexpressive in different ways.  In my opinion java is closer to lisp than C++, given garbage collection, closures (even faked by objects), reflection (code-as-data), classloading (eval).

You can do metaprogramming in C++ (with templates, which are Turing-complete) and now it supports closures and many other things. Unfortunately, it's become too complex. D would be a better choice if only it was more popular.

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 11:04:00 PM UTC+1, Luc wrote:

Ok I'll drop the subject. Still cannot understand why people cannot
try something new w/o sticking to the stuff they know already until they are
totally immersed in the new thing. And by that I mean use the new thing as
it was intended.

Then you can generate useful conclusions and get some benefits from
this learning process.

Learning every single language just to find the right one is not very time-efficient.

[Massimiliano Tomassoli]

On Thursday, December 26, 2013 10:04:21 PM UTC+1, Luc wrote:

a) encapsulation of unmutable state ? What for ?
b) inheritance ? see a)
c) polymorphism ? Multimethods (which are more flexible) or protocols

Nice words but not much else.

Comparing C versus C++ is fair but this comparison does not relate at all to
Clojure, it's like answering "blue" to the question
"which even number sits between 1 and 3 ?"

I am still waiting for an answer to my previous post btwy...

 
I did answer to your post.

[James Reeves]

There are a lot of programming languages, but you can get a good overview from just few. If I had to pick just four to provide a reasonable spread of ideas, I'd suggest Scheme, C, Smalltalk and Haskell. In my very subjective estimation, Clojure sits somewhere between Scheme and Haskell.

However, assuming you don't want to spend several months researching interesting programming languages, let me see if I can make an argument against OOP that requires a little less background reading :)

Clojure has been around for over six years now, and has all the components necessary to construct an object system. It would take maybe a few hours to build a library for Clojure that provide support for OOP. To the best of my knowledge, however, no-one has. If OOP was a particularly useful paradigm, why the lack of interest in reproducing it in Clojure? Perhaps it's worth investigating how Clojure manages without it?

- James

[Massimiliano Tomassoli]

OK, I'll give Clojure a try. Thanks for your time.

[Luc Prefontaine]

This depends strictly on your learning speed which I will
not comment here :)

It took me three months full time to start to feel at ease with
Clojure writing production code and I was around 45 years
old at the time.

Learning is never inefficient... when you want to learn.

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/groups/opt_out.
>
--

[Mark Engelberg]

I do like the way Clojure steers you away from all sorts of unnecessary OO-nonsense, and provides most of the raw capabilities of OO in other forms.

However, even if you avoid mutable state, inheritance, and polymorphism, Classes/objects make great namespaces, and Clojure's namespaces can't do everything classes can do, for example, cyclic dependencies.  This was the subject of my blog post yesterday.  Take a look at the following gist code for one of the scenarios that frequently drives me up a wall:

https://gist.github.com/Engelberg/8141352

I'd love to hear any tricks you guys use to deal with situations like this in your own code.

[Stuart Halloway]

Hi Mark,

I am not following your example.  Can you post (pseudocode fine) what a good OO impl would look like, and why Clojure's defrecords can't do something similar?

Stu

  

--

[Mark Engelberg]

Does this OO pseudocode help clarify at all?
https://gist.github.com/Engelberg/8142000

[Mark Engelberg]

One reason it might not be clear what I'm driving it is that in trying to create a minimalist example, I used grid dimensions, and in reality, you'd probably know right away to put something like that in a data structure, and pass it around to all your functions.

Try to imagine that at the beginning of your project, you really do believe that you're only going to ever be working with 3x4 grids, and then later, you realize that's not the case.

In the early phase, it's very easy to construct a bunch of functions that all refer to those shared vars (in my example `rows` and `cols`).  Later, when you realize rows and cols can change, making those names parameters is a major overhaul to the codebase.  I believe that most Clojurians try to delay the refactoring by using `binding` to alter those vars.  But that's a fragile strategy, and eventually the code typically needs to be rewritten.

[Steven D. Arnold]

On Dec 26, 2013, at 9:32 AM, Massimiliano Tomassoli <kiuh...@gmail.com> wrote:

> Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a little bit worried about the absence of support for OOP in Clojure. How do you decompose large systems in Clojure?

That seems like a very intelligent question. I didn't see that anyone in the thread mentioned Brian Marick's book, Functional Programming for the Object-Oriented Programmer. In the book, Marick emulates object-oriented programming in Clojure, which not only helps you see the greater flexibility you get with Clojure, but also helps you be a better OOP programmer when dealing with OOP languages. I'd definitely recommend the book.

Another book worth checking out is Dmitri Sotnikov's Web Development with Clojure, which is a good survey of Clojure web development using Ring and Compojure. It illustrates well the idea of selecting the components you need for your web application and pulling them together, as opposed to the idea of a single overarching framework.

I am a professional Rails developer and I like Rails. But I think the criticisms leveled against the single-framework model are very legitimate. If you want to do something the framework is not built for, you can spend a lot of time trying to work around the framework instead of using it. The easy things are really magically easy, but the hard things are pretty hard.

Having said all that, here's what I really love about Clojure. Like Ruby and Rails, you can start off with an amorphous, ill-defined idea that you are prototyping. You can put it together, realize you had a lot of misconceptions (about the problem, the product, what people want, etc), and easily shift your assumptions.

But Clojure shifts from Ruby and Rails when your idea matures and the invariants of your application settle. Clojure's tools give you more assurance of correctness when your app increasingly takes shape. Functional programming and immutability save you from whole classes of really fun state problems. Pure functions give you testability and transparency that are rarely seen in Rails apps. You can gradually add types to your arguments and return values (https://github.com/clojure/core.typed), thereby gaining much of the safety of statically-typed languages. You can use contracts (https://github.com/clojure/core.contracts) to ensure that your assumptions are always met, both regarding parameters and results of your functions. You can elegantly address all the possible cases of a set of parameters using matching (e.g. matchjure, https://github.com/dcolthorp/matchure/). Argument pattern-matching and destructuring is a fabulous tool and you really have to use it a little to realize how handy it is.

In short, Clojure gives you all you need for prototyping, and when your idea jells out, you can tighten it down tremendously and expect fewer late-night phone calls where the app is breaking. Your software is simply more stable and correct, with less effort. Yet, you didn't have to pay the static-typing toll up front, when you needed the freedom and flexibility to try different things.

I don't know if Clojure is ultimately right for you. But I can say with no doubt that learning Clojure will grow you as a software developer, and you won't be sorry you spent the time to get to know the language and the Clojure way of thinking.

Good luck,
steven

[Sean Corfield]

On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli

<kiuh...@gmail.com> wrote:
> Thank you, Malcolm. I'm completely new to LISP and its dialects and I'm a
> little bit worried about the absence of support for OOP in Clojure.

I'm a little late to this thread (it's been one of those days!) but
having read over your posts, I didn't get a good sense of why you are
worried about the absence of support for OOP in Clojure?

Like you, I have 20+ years of OOP experience - including eight years
where I worked on the ANSI C++ Standards Committee - and I've worked
with C++, Java, Groovy, Scala and a few other OOP languages during
that time. I've developed and worked with static analysis tools and
been able to look at millions of lines of code (mostly C++), and seen
all sorts of horrors committed in the name of OOP :)

Before that I worked on C and COBOL compilers, and various C and
assembler projects. And before that I did FP, albeit in an academic
context. For the last three years I've worked increasingly in Clojure.
My team is slowly migrating from an OOP language and a 90Kloc system
to Clojure (where we already have 16Kloc). Adjusting to FP from OOP
can be hard - I've seen a number of Java developers really struggle
with the transition. You might find Prof. Grossman's "Programming
Languages" course (on Coursera) to be illuminating: it starts with
Standard ML, then moves on to Racket, and then finishes with Ruby.
Part of the course looks closely at what both FP and OOP bring to the
table and how they can be viewed as complementary, orthogonal, and in
some ways simply equivalent.

> How do you decompose large systems in Clojure?

I'm curious as to why you think only OOP allows you to decompose large
systems? Between namespaces, protocols, multimethods, ad hoc
hierarchies, and higher order functions, Clojure has a lot of tools
for organizing code...
--
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]

Words play a very important role in expressing ideas. For me, I think clojure is mostly about ideas. A way of doing things. For me clojure was intuitive from day one. The notion of programming with functions applied to data. So in clojure data structures are emphasized as a way of representing data as opposed to classes which Rich Hickey has argued as using mechanical things(classes) for the wrong purpose. Because of this we have words like: pure functions, higher order functions, which many OOP language has just started adopting; closures, which are analogous to objects in OOP but are sanely done with the help of immutability; data structures as opposed to using classes to track numerous variables in the name of data; composition rather than inheritance because the *complect* control. And a number of other ideas. 

You just have to take a deep breadth and accept you are about to look at things a bit more mathematically using functions as the major tool for designing machines. Don't resort to familiarity as that will prevent you from learning new things and trust me you have a whole lot to unlearn. But if you stick with the community you can learn fast seeing you already a programmer.

With regard to frameworks I agree it's about composition of libraries that's where you get the most power and less problem because of all this immutability thing. Dive in and start applying it on something real and before long you will be glad you did and ready to bring others on board. 

[Robert Levy]

Mark,

Your comment "Clojure's namespaces are quite limited in ways that frequently cause me pain" brings to mind Daniel Spiewak's talk on modularity in functional languages: http://2013.flatmap.no/spiewak.html. It might be interesting to Massimiliano as well.

Spiewak is actually criticizing Haskell's approach to modules and not Clojure's but similar criticisms could apply to both. The gist of what he says is that there are expressive advantages to Scala's decision to treat modules as first class things.

He then goes on to cite Clojure's protocols as another example of an OO abstraction improving modularity in an FP language, but that's not news here.

Rob

[Mark Engelberg]

Yes!  This is very much what I'm talking about.  When we talk about why we don't need classes in Clojure, we're usually talking about how we have better tools for inheritance, polymorphism, encpasulation, mutable state, etc.  But classes are also powerful namespaces, and Clojure's namespaces aren't rich enough to make me stop missing those sorts of useful aspects of classes.  Spiewak gives some really great examples in his talk.  Thanks for the link.

[Walter van der Laan]

First, regarding OO. When programming Clojure I never think about adding objects to the application, I think "how can I extend the language so it is better tailored to my application domain?". And for a lot of domains good libraries are already available. So, for the example that you gave I would first look at core.matrix https://github.com/mikera/core.matrix. It does something which objects can't do; it adds matrices to the language in a very natural way.

Second, regarding cyclic dependencies. When programming Clojure I think about how data (EDN) flows through my application. Because of this my namespaces usually depend on the structure of the data. My namespaces rarely depend on namespaces other that those that provide the additional language elements that I need (like e.g. core.matrix, core.async, ...). This does raise a new problem "how do I check the validity of the data flowing in and out of namespaces?". There were several presentations at Clojure/conj that addressed this problem. But overall I find this approach to work very well, even for large applications, because namespaces are highly decoupled and easy to test.

Those are the "tricks" that I use. But I must admit that it has taken me many iterations to slowly improve my code. Old habits die hard.

[Massimiliano Tomassoli]

The point is that Clojure is not the only modern language out there. I can't possibly learn them all in depth just to decide which language to use for my production code. That would be time-inefficient because my goal in not to learn languages, but to pick up a new language suitable for my needs.

[Luc Prefontaine]

Then we have more in common
than you may think :)

I learned Ruby first, went through
Scala which appeared in the same
time frame,
all this to pick up the language of
choice to replace Java and Ruby
which we used to prototype our
product.

All this took around 9 months
including the time to get the prototype
working.

Choose carefully... :)

Luc P.

> > > To post to this group, send email to clo...@googlegroups.com<javascript:>

> > > 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 <javascript:>

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

> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> > --

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

[Stuart Halloway]

Yes, thanks Mark. It seems to me that you are saying "namespaces make poor maps".  Stipulated.  So why not use records or maps?

I think that where my experience differs from yours is summarized in your comment "In Clojure, a project often begins with a bunch of functions sharing some immutable state or "magic constants" stored in vars." I *never* do that.  If there are a group of related things, I put them in an associative container (maybe just a map) on day one.

The analogy with OO is misleading here.  If you started an OO project putting everything in static/singleton members, you would have the same pain you attribute to Clojure's namespaces.

I find this to be a "my car doesn't have wings" argument, and the kind of thing that leads into casually complecting everything with everything else.

Stu

[Luc Prefontaine]

I would add that you *need* to
write some code to get a feeling
about a new language.

Feature comparisons may help you up
to a certain degree. However deciding about how efficient
you may become using a new language requires you to dive at
least a bit into it. Not all brains are wired the same.

Luc P.

[Massimiliano Tomassoli]

On Friday, December 27, 2013 7:29:22 AM UTC+1, Sean Corfield wrote:

On Thu, Dec 26, 2013 at 8:32 AM, Massimiliano Tomassoli

> How do you decompose large systems in Clojure?

I'm curious as to why you think only OOP allows you to decompose large
systems? Between namespaces, protocols, multimethods, ad hoc
hierarchies, and higher order functions, Clojure has a lot of tools
for organizing code...

I've never claimed that OOP is the only way to decompose large systems, but since Clojure doesn't support OOP and many languages are multi-paradigm nowadays, I was wondering how you modularize systems in a language which is purely functional.

[Massimiliano Tomassoli]

I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems. You can't get an idea of that just by writing some code and getting a feeling about the language, IMHO. When I studied OOP at University my professors taught me that OOP was extremely successful in reducing the complexity of big systems. I was given many examples of that in the many courses of software engineering I took. FP was relegated to some theoretical courses about paradigms. With such a background it's not easy to accept some of the things the Clojure community claim. The fact that I'm here asking questions should mean that I'm more open minded than most :) But please understand where I'm coming from.

[Malcolm Sparks]

I modularize my Clojure systems using Jig: https://github.com/juxt/jig - it's one of many possible approaches.

--

--
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/zwhpqptqV1A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Softaddicts]

It took us some time to structure the code at the time and now
with protocols we went under a other restructuring a year ago.

I agree this part can be hard (structuring the code) but at the time we started
protocols were not yet there hence some of the restructuring.
Best practices also evolved for a couple of years.
It's much more stable these days.

When I say write some code, well you need to choose a domain
aside from simple things like "hello world". Which makes it harder
to write some code :) but forces you to question yourself about
how to do this right the first time.


This is the list of my favorite items that I keep an eye on:

a) abstractions, choose them according to your business domain, do not
try to re-invent the wheel or create alien terminology.
This is a starting point to get your name space structure right.

b) In your APIs try to stay generic by not assuming implementation details.
This step can be hard to achieve. Keep doors opened.

c) You may want to redefine the implementations of
your abstractions or provide different flavors or some flexibility in your APIs.
Protocols/multimethods become handy at some point here.
This is the part that may feel a bit like OO but this is the one you have to
think last. (remember point a and b)

d) Do not hesitate to refactor. There's less code than in most other languages
that get some support for refactoring from their IDE so you should not
wait until it becomes a mess. If a name space is not rightly named anymore,
chane it. If more separation of concerns is required, add/change name
spaces accordingly and reorg the code.

e) A good indicator of the stability of your APIs is how much your test code
gets messed up when you do change something. It could be
related to implementation details leaking out, bad choice in name space
design, ....

I am not an advocate of TDD but at some point when the code of a
name space is stable enough, a few test cases can be used as
health signs.

f) Search for existing librairies, there are enough of them out there,
either Java libs with/wo Clojure wrappers or Clojure centric ones
to speed you up not having to rewrite the universe.

g) Read the code of the libs you are pulling in as you go along.
This will probably light a bulb in your brain about tricks you should
apply to your code.

The above should sound familiar :) It's not that different in Clojure to me
than in many other languages.

If you have some specific concerns, send them to me off line.
I may share some code privately to answer some of your questions.
Sorry for the other folks on this thread but there are copyright issues here :)

Luc P.

Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!

[Mars0i]

On Friday, December 27, 2013 10:02:46 AM UTC-6, Massimiliano Tomassoli wrote:

I've seen Clojure in action and I know it's extremely concise and expressive. What I wanted to know is how it copes with complexity when you develop complex systems.

My intuition is that getting rid of or reducing mutable state by itself reduces some of the problems of complexity.  I'm not against mutability--some things are a lot easier with it--but it's also one of the motivations for modularizing code.  One of the purposes of OO is to reduce and constrain dependence on state elsewhere.

This is not a full answer because there's still a need for making code modular even with immutability, and because although I've programmed in an FP spirit for a long time, it's only recently, when I started learning Clojure, that I've tried to be more pure about FP.  So others will have more insight into what I suggest above.

[Sean Corfield]

On Fri, Dec 27, 2013 at 8:02 AM, Massimiliano Tomassoli
<kiuh...@gmail.com> wrote:
> When I studied OOP at
> University my professors taught me that OOP was extremely successful in
> reducing the complexity of big systems.

That's always been the claim about OOP but big systems have an
inherent complexity and you can never reduce that - you can just push
it around in the system and give the illusion of hiding it. But it's
still there. Having done decades of OOP as well as quite a bit of FP
both before and after, I don't find OOP to be any more successful at
_reducing_ complexity in the real world.

> I was given many examples of that in
> the many courses of software engineering I took.

Hmm, I've never known any courses that deal with "big systems"
although many of them discussion the _theory_ of dealing with big
systems.

> FP was relegated to some
> theoretical courses about paradigms.

That's unfortunate. I think the shift in education from FP to OOP was
actually a bad thing.

> With such a background it's not easy to
> accept some of the things the Clojure community claim.

With my background I find it hard to accept some of the things the
educational OOP community claim :) The reality is that "big systems"
are just plain hard to work with - in any paradigm - and FP provides
tools to manage it just like OOP does. They're just _different_ tools.

I'm glad you're open minded. For now you'll just have to trust those
people who tell you that Clojure lets you deal with "big system"
complexity very well. I'm not sure why you are less trusting of their
real world experiences than what your professors told you about
(theoretical) OOP...

[Massimiliano Tomassoli]

That makes me think that maybe there's a need for more books about Clojure. There are many introductory books but nothing more advanced such as best practices, patterns, etc...
That's maybe a problem for someone like me who wants to "do things right" from the start. Should I read books about Common LISP and functional programming in general?

[Massimiliano Tomassoli]

On Friday, December 27, 2013 7:31:25 PM UTC+1, Sean Corfield wrote:

I'm not sure why you are less trusting of their
real world experiences than what your professors told you about
(theoretical) OOP...

First, someone said that OOP doesn't alleviate the problems that it's supposed to solve and this I don't believe.
Then, someone else claimed that OOP is useless in presence of immutability. I don't agree with that. It would also imply that Scala's developers are just plain stupid.
So I was under the impression that you were criticizing something you didn't fully understand.
Also, it's difficult to trust someone who claim that LISP is the best language there is and everybody else is just stupid for not realizing that.
I only tend to trust people who realize that their language is not perfect and is just one of the many languages available.

[Sean Corfield]

On Fri, Dec 27, 2013 at 12:24 PM, Massimiliano Tomassoli
<kiuh...@gmail.com> wrote:
> First, someone said that OOP doesn't alleviate the problems that it's
> supposed to solve and this I don't believe.

There is no silver bullet: OOP helps with some problems in some ways
but it's not perfect. The folks who pioneered OOP didn't imagine it
would turn into C++ or Java...

> Then, someone else claimed that OOP is useless in presence of immutability.

I don't think anyone claimed that. There was a comment that
encapsulation is less important in the presence of immutability.
Encapsulation is only one aspect of OOP - and Clojure provides several
ways to encapsulate data if you want to do that.

> So I was under the impression that you were criticizing something you didn't
> fully understand.

Perhaps you've been convinced otherwise now? I feel that I understand
OOP pretty well after two decades of using several OOP languages to
deliver production systems - and helping to design parts of C++, and
building a C++ compiler :)

> Also, it's difficult to trust someone who claim that LISP is the best
> language there is and everybody else is just stupid for not realizing that.

Well, that's the Smug Lisp Weenie and part of the Lisp Curse [1]. I
think there's an OOP equivalent but it doesn't get written about very
much because OOP is so mainstream, despite its flaws.

[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

[Luc Prefontaine]

I am kind of old school.
To me these things come through
practice...

Which I understand maybe of little
help to you in the immediate
future :)

When I was young we had
many books that had little to
do with the ones mostly
available today.
(Learn xxx in nnn days)

Looks to me that this is the missing
piece in the puzzle. Not sure that
this kind of book would be popular
these days.

Luc P.

> > Softaddicts<lprefo...@softaddicts.ca <javascript:>> sent by ibisMail from
> > my ipad!
> >
>

> --
> --
> 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/groups/opt_out.
>
--

[Mark Engelberg]

With a little searching, you can find several papers like this one that research the question of whether OO has lived up to the hype:
http://scholarworks.gvsu.edu/cgi/viewcontent.cgi?article=1129&context=cistechlib

Feel free to jump straight to the conclusion, i.e., "object-oriented technology has only partly kept its promises."

If you want to use OO in its traditional form, there are many languages that will support you in doing that.  Clojure is not one of them.  If you want to join a community of people who are dissatisfied with OO, and feel they are working towards a better way, with better tools for reuse and managing complexity, give Clojure a try.  It's entirely your choice.  No one's making you do anything.

[john walker]

Err, a lot of these questions are quite open in nature. I don't think anyone in software engineering has great answers - see "Everything is an Object" for Javaland and then some of the proposals in Doug Hoyte's Let Over Lambda (an excellent read if you're after Common Lisp books and recognize the high-mindedness). These topics should then probably be reframed with additional context.

I probably sound like a broken record, but I strongly feel that you should ask for examples of large projects and look for yourself to see how they're engineered.

Umm, I hope that no one actually said that Lisp is the perfect language and everyone else is stupid or that OOP is useless with immutability.

What are some flaws that you think Clojure has? : )

[Mark Engelberg]

Luc, I've just got to say, your tiny margin widths always make me think your message is some kind of haiku :)

[Gary Trakhman]

brain-dump TLDR: I like clojure's costs-to-benefits.. and it's successful because it's what the industry needs.

I wouldn't say lisp family langs are the 'best' languages, but I would say its tradeoffs maximize the power of the individual, which interests me since I am one :-).

Talking about tradeoffs can get very verbose, but I find it helpful to make an analogy for things like mutability/immutability as a number line.

Let's think of some tradeoffs and virtues, it's not always black/white or bad/good:

regularity/expressiveness

type-safety/dynamicity

mutability/immutability

speed

code size (language implementation or generated)

'weight of an abstraction' (ie how hard/big is it to jump a level of expressiveness)

orthogonality of feature-set (pay for what you use)

popularity

blub-ability (do you need to be an expert to program in it?)

team-suitability

Then we can start to think of it as quantities, a vector.

We can subjectively normalize these for orthogonality, eg.. for some languages, some tradeoffs will interact more with others in practice, and we can come up with a cost-model according to our usage.

Then programming in this language can be thought of as a projection (dot-product) of our minds along this vector space over time.

These tradeoffs affect 'costs', ie time/money/effort.  There is a fixed cost to learning clojure well enough (IME the time it takes to grok Joy of Clojure, implementation details like core.clj and Compiler.java, learning enough emacs to get by), and little recurring costs along the way (like how hard it is to refactor something).

In my opinion, I love clojure because of the orthogonality of its feature-set (design by decoupling) and because of the expressivity of lisp itself, that outweighs everything else.  Its code has a high SNR because of it.

I think s-expressions are the closest thing to how brains actually work, ie it's an efficient way to 'project' at any level of abstraction, and the cost of traversing abstractions up and down is low due to the regularity of the syntax.  Scheme makes a good teaching language because there are benefits to seeing the structure directly.  We know from experience that restricting abstraction is bad (java).

So, I'm pretty satisfied with it, I might learn other languages for specific use-cases, but I think time spent in lisp isn't wasted, since it's easy to pull an abstraction out of anything repetitive, and we as users can steal ideas from other languages more effectively without involvement from compiler writers.  A new language becomes necessary when we have to revisit core primitives, which we will be compelled to do once we identify certain costs are too high for too many people. 

People might have different ideals, use-cases or costs based on their experience or situation.'

I think the curation approach of 'design by decoupling' turned out to be a great idea simply because of the huge amount of stuff that's been written by many people in isolation over the last decades.  If we took it to an extreme, then it would also cease to be a good idea.  I think C++/Java-style OO has already been taken as far as it needs to go.  We've reached the point where the costs-to-benefits are well-understood and felt to be lacking for many current and future use-cases.

[Patrick Kristiansen]

Maybe it would be helpful to define what exactly you mean by OOP. Use this list:

http://www.paulgraham.com/reesoo.html

Clojure supports some of the constructs that people typically relate to OOP.

Decomposing large systems: How do you decompose large systems with OOP? By using classes and objects? I don't believe that classes and objects tell you much about how to structure systems (comprised of multiple subsystems). It tells you more about how to view the software you are writing at a small scale, and it tells you how to build a mental image of your programs.

In any case, you can use established principles in Clojure programming that transcends language paradigms, e.g., hiding implementation details, creating well-defined interfaces and data structures, separating concerns (making things simple, as they say in the Clojure community).

If you are hoping to find a feature set in Clojure that matches what you are already familiar with, you may end up disappointed. Is Clojure the right language for you? It probably depends mostly on personal taste and willingness to change perspective.

Best regards,
Patrick

[Jeff Heon]

Given your goals of evaluating the language quickly, not having a lot of free time to devote to it, and having to get productive fast in a web environment,

I think a better avenue to explore would be Groovy alongside Spring Boot or Ratpack.

It's concise, close to Java OO, and yet have functional programming features and metaprogramming facilities.

[Luc Prefontaine]

Been writing these on my iPhone most of the day and if I do not cut
lines myself, it looks pretty ugly
on my side :)

I am pretty bad at writing poetry,
glad to see I could fake at it :)

Luc P.

[Alexis Gallagher]

Hi Massimiliano,

Perhaps I'm a bit late to this thread but let me offer an opinion going in the opposite direction.

Basically, if the web development you have in mind fits squarely within the use case addressed by RoR or Django or something like that, then I expect you will find one of those frameworks is more productive than the Clojure web stack. The reason has nothing to do with FP vs OOP, or anything so grand. It's just that the Clojure web dev ecosystem doesn't offer the same depth of mature, ready-to-go components. I'm thinking of meat and potatoes things like administrative interfaces, user account management, user authentication systems, forgot-my-password workflows, etc.. Yes you can build what you need yourself. And, quite possibly, maybe you can build it from scratch in Clojure faster than in another language. But building it from scratch in Clojure will still be slower than downloading a widely-used framework in another language.

I expect this difference will be especially strong if you're working on relatively small projects with conventional requirements, since those are most likely to be handled by frameworks in other languages. As projects become larger and more customized, then Clojure becomes a better choice because of the strength of the language fundamentals.

All of this is not because Clojure is immature. It's just because it's not what most people are using the language for. I have the impression (I could be wrong) that more people use Clojure to build API endpoints, or to perform some kind of compute service behind an endpoint.

If you do want to go ahead with Clojure for web development, then there are a number of great projects that give good examples of the current state of things: luminusweb, caribou, pedestal, etc.. I also found that the books Clojure Programming and Web Development in Clojure both had good discussions of how to do it.

Anyway, this is the opinion I came to over the last couple months, diving into Clojure web development on a real project for the first time, after already being familiar with the language but new to its web stack. But I could be wrong. For instance, I've never used RoR seriously, so it may be I'm overestimating the quality of what you get "out of the box" doing it that way.

A

[Massimiliano Tomassoli]

On Friday, December 27, 2013 10:07:14 PM UTC+1, Sean Corfield wrote:

On Fri, Dec 27, 2013 at 12:24 PM, Massimiliano Tomassoli

> So I was under the impression that you were criticizing something you didn't
> fully understand.

Perhaps you've been convinced otherwise now? I feel that I understand
OOP pretty well after two decades of using several OOP languages to
deliver production systems - and helping to design parts of C++, and
building a C++ compiler :)

Yes. I wasn't speaking of you in particular and mine was just a first impression.
Now I'm ready to start learning Clojure and find out if it is really as powerful as you say. I must admit I don't like its syntax (or absence of it), but I hope to get used to it.

[Massimiliano Tomassoli]

On Friday, December 27, 2013 10:12:06 PM UTC+1, john walker wrote:

What are some flaws that you think Clojure has? : )

I don't even know the language yet! :)

[Massimiliano Tomassoli]

On Friday, December 27, 2013 10:47:35 PM UTC+1, Jeff Heon wrote:

Given your goals of evaluating the language quickly, not having a lot of free time to devote to it, and having to get productive fast in a web environment,

I think a better avenue to explore would be Groovy alongside Spring Boot or Ratpack.

It's concise, close to Java OO, and yet have functional programming features and metaprogramming facilities.

I already know Python. As my next language I want to try something radically different like F#, Scala or Clojure, but thanks for the suggestion.

[Mars0i]

On Friday, December 27, 2013 6:27:34 PM UTC-6, Massimiliano Tomassoli wrote:

I must admit I don't like its syntax (or absence of it), but I hope to get used to it.

This is understandable.   I think that the things that are most important for becoming comfortable with the syntax, other than experience, are using an editor that matches parentheses, and learning (Clojure-style) Lisp pretty-printing.  If you can use an editor that has a plugin that will do the pretty-printing for you, that's even better.

[Massimiliano Tomassoli]

I'm using eclipse + counterclockwise.