• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Clojure for teams

 
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dears Michael and Chris,
Clojure has massive power under the coat mainly due its Lisp legacy.
I know that Clojure tries hard to get ride some of Lisp annoyance but given its syntax is same as Lisp's (or more accurately its minimal, nearly non-existant syntax), do you think that Clojure is a suitable language for teams?
Because seriously some times I think Lisp/Clojure is rewarding for the single individual, not for teams.
If any team is going to adopt Clojure, do you have any suggestions and best practices to adopt?
Thanks.
 
author
Posts: 22
VI Editor Clojure Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think Clojure's syntax, while perhaps less familiar than some
alternatives, is good even for teams. Of course if any particular
development team is unable to pick up Clojure's syntax, I couldn't
recommend they switch to it, but I would certainly hope such a team is
rare. As you note, it's not as if the syntax is complex.

Another reason I've heard that Clojure may be unworkable for teams is
because of its lack of compile-time type checking. This argument
about static vs. dynamic typing is of course well worn and I'm not
likely to do it justice or change anyone's mind right here. Instead
I'll simply make two small points. First, I think in most
circumstances unit and regression tests, which are recommended for
statically typed languages as well, do at least as well at
communicating module interfaces and preventing regressions as type
declarations do. Second, a variety of dynamically typed languages
have been used to good effect by teams large and small.

I think that if teams invest the time they would have spent getting
type declarations right creating tests that can also serve as
example, they'll be pleased with the rapidity with which they can
create quality code.
 
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Chris Houser wrote:
I think that if teams invest the time they would have spent getting
type declarations right creating tests that can also serve as
example, they'll be pleased with the rapidity with which they can
create quality code.


How are unit testing performed in Clojure ? Do you explain this in your book ?
 
Chris Houser
author
Posts: 22
VI Editor Clojure Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We cover testing in chapter 12 of The Joy of Clojure. Clojure comes with a testing framework in the clojure.test namespace, though there are now others available such as lazytest and midje. Unit testing doesn't have to be complicated. In most cases learning two or three functions from a testing framework is enough to write all the tests you need to demonstrate how a module is supposed to work.
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you. I'm curious to know how functions are mocked ? Let's say that you have a function which gets some data from a database, but you don't want to access the database for your unit tests. How can you do it in Clojure ? (something like mock objects in JUnit)
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I find the OP's question very strange. Why would something that works for an individual not work for a team ?
 
Hussein Baghdadi
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pradeep bhatt wrote:I find the OP's question very strange. Why would something that works for an individual not work for a team ?


Have you tried to look at any considerable Lisp or Clojure code before? do you imagine you have a big code base of this code?
Of course nothing wrong with Lisp (well some how ;)) but Lisp will tax your memory and it takes a lot of time to get a Lisp eye.
Also your team have to be elite and highly brilliant (which it is a good thing of course).
 
author
Posts: 12
Monad BSD Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

John Todd wrote:Have you tried to look at any considerable Lisp or Clojure code before? do you imagine you have a big code base of this code?
Of course nothing wrong with Lisp (well some how ;)) but Lisp will tax your memory and it takes a lot of time to get a Lisp eye.
Also your team have to be elite and highly brilliant (which it is a good thing of course).



I don't want to speak in generalities because I recall similar talk when object-oriented programming started gain some market share. However, I will speak from my own experience. That is, I find functional code, in general, easier to grasp than most examples of object-oriented code. The reason for this can be summarized by a quote from Adele Goldberg, who was speaking about Smalltalk, but the point is a general point on OOP in my opinion:

In Smalltalk, everything happens somewhere else.



That is, behaviors in OOP are inherited, composed, mixed-in, etc. and therefore spread out over multiple files, classes, libraries, and projects. I find it very difficult to keep these disparate pieces in my head. Even local to individual methods Java code (just to pick any imperative OOP language) is obfuscated in that it doesn't inherently lend itself succinctness. These conditions are in part mitigated by IDEs however.

However, in Clojure code things tend to happen exactly where you happen to be looking.

 
Hussein Baghdadi
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

However, in Clojure code things tend to happen exactly where you happen to be looking.


Man this is enlightening, I never look to it this way.
 
Rancher
Posts: 379
22
Mac OS X Monad Clojure Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

John Todd wrote:Because seriously some times I think Lisp/Clojure is rewarding for the single individual, not for teams.



I'm curious John, could you elaborate on why you have this impression? I'd never really thought of a language being more or less suited for use by a team compared to an individual so I'm really interested in hearing why someone thinks this...

Thanks!
 
Hussein Baghdadi
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Sean Corfield wrote:

John Todd wrote:Because seriously some times I think Lisp/Clojure is rewarding for the single individual, not for teams.



I'm curious John, could you elaborate on why you have this impression? I'd never really thought of a language being more or less suited for use by a team compared to an individual so I'm really interested in hearing why someone thinks this...

Thanks!


  • The prefix notation.
    Mainstream languages have a very different syntax and developers aren't used to read and write prefixed-notation code.
    Also, Clojure will tax your memory and pushes you to understand a lot of things too soon.
  • Readability.
    The location and the number of parentheses which it is again not Lisp/Clojure fault, mainstream languages are very different.

  • Due these points I got the feeling that with Lisp/Clojure, code could be looks encrypted (hence suitable for the individual and not for a team).
    Obviously, my feeling isn't accurate.
     
    Michael Fogus
    author
    Posts: 12
    Monad BSD Clojure
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    John Todd wrote:The location and the number of parentheses which it is again not Lisp/Clojure fault, mainstream languages are very different.



    We need to be careful to distinguish between what people are accustomed to and what is inherently difficult. It's a tautology to say that Lisp syntax is hard to read when you don't know Lisp syntax. However, is there anything inherently more difficult to prefix operators and parentheses in Lisp than a long parade of `end` in Ruby, or significant whitespace in Python, or dots, commas, semicolons, AND parentheses in Java? I don't think so. There is nothing magically intuitive to Java syntax over any other language syntax -- it's all learned through exposure and practice.
     
    Sean Corfield
    Rancher
    Posts: 379
    22
    Mac OS X Monad Clojure Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    John Todd wrote:The prefix notation.
    Mainstream languages have a very different syntax and developers aren't used to read and write prefixed-notation code.


    Well, mainstream OO languages have taught us "object . verb( subjects )" but since that's really "To object do verb with subjects" you could argue that's not a very English-like sentence structure (yes, I'm playing Devil's Advocate here). Pre-OO - when I started programming - you typically wrote "verb( object, subjects )" which is "Do verb to 'a bunch of things'" which I think most people would say is more readable than the OO style. My feeling is that developers raised on OO find the prefix form alien because they haven't used non-OO languages where function calls were all prefix form. More on OO vs FP below.

    John Todd wrote:Also, Clojure will tax your memory and pushes you to understand a lot of things too soon.


    An interesting observation. I wonder if that's really truer of Clojure than some other Language X? I know that right now I still have to refer to the Clojure docs a lot more than for my 'day-to-day' language, but I also still have to refer to the Scala docs quite a bit too. Clojure's "standard library" is quite big when you're first getting into it but overall it's much, much smaller than Java (or Scala). I think the new concepts - immutability, high-order functions, etc - make it feel like there's more to learn / remember? The basic syntax is minimal (especially compared to Java or Scala!).

    John Todd wrote:Readability.
    The location and the number of parentheses which it is again not Lisp/Clojure fault, mainstream languages are very different.


    This seems to be a common push back but I think it's mostly perception. A function call in Java has a pair of parentheses, a function call in Clojure/Lisp has a pair of parentheses. A code block in Java has braces, in Clojure/Lisp it has parentheses (and it could be argued let has both () and [] but that's only one extra set of delimiters - and you don't have any of the other Java punctuation in Clojure/Lisp). A conditional in Java typically has () and two {} as well as internal () for function calls, a conditional in Clojure has just the enclosing () - any internal () are due to function calls that would also be present in Java. Arithmetic is where you see extra parentheses in Clojure/Lisp because operators are just regular function calls (but even there, any parentheses in Java for grouping do not cause additional parentheses in Clojure/Lisp).

    John Todd wrote:Due these points I got the feeling that with Lisp/Clojure, code could be looks encrypted (hence suitable for the individual and not for a team).
    Obviously, my feeling isn't accurate.


    No, I think your feeling is accurate for you - and it's shared by a lot of people who find Lisps to be very alien. I'm certainly not trying to argue against your feelings. I am trying to understand them better, because I want to be able to help teach people Clojure in a way that makes them comfortable and minimizes obstacles (perceived or otherwise). I've actually had reasonably good reactions from people who have no real OO experience - purely imperative, procedural developers - at least in terms of syntax. The immutability thing throws them for a loop tho'

    On OO vs FP:

    Based on the reactions of various types of programmers, I'm wondering if functional programming is easier to pick up if you have less object-oriented exposure? Before everyone started doing OO, we had data in one place and we had functions that operated on them. Sure, we had mutability but it was always "over there" - data was operated on in isolation. With OO, we learned to internalize the data with the functionality and treat objects and operations as black boxes - we call methods, they do stuff (often modifying their internal state). We've gotten so used to this that I think it now makes it harder for us (by which I mean generically OO / mainstream programmers) to adopt a style of development where data is once more "over there", separate from the functionality. Going from procedural to functional seems in many ways a smaller jump than going from OO to functional.

    What do other people think about that hypothesis?
     
    Hussein Baghdadi
    clojure forum advocate
    Posts: 3479
    Mac Objective C Clojure
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Very important and useful comments, thank you Michael and Sean.
    Now I'm pretty sure that picking functional programming is a lot easier if we have less OOP exposure.
    Excellent note Sean and welcome to the Ranch.
     
    Sean Corfield
    Rancher
    Posts: 379
    22
    Mac OS X Monad Clojure Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    John Todd wrote:Excellent note Sean and welcome to the Ranch.


    Thank you! I guess it's a little ironic that after doing Java for 14 years, what finally got me to create an account on the Ranch was Clojure
     
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Same here.

    Sean Corfield wrote:

    John Todd wrote:Excellent note Sean and welcome to the Ranch.


    Thank you! I guess it's a little ironic that after doing Java for 14 years, what finally got me to create an account on the Ranch was Clojure

     
    reply
      Bookmark Topic Watch Topic
    • New Topic