Re: Another newbie question
On Tuesday, November 8, 2011 8:04:19 AM UTC+2, Sean Corfield wrote: docstrings? Yeah, sure, but docstrings aren't linkable. It's interesting that Java, with all its faults, has an incredible documentation system. Scala has a problem in this field, too, since the complex typing and tricks and advanced features used to generate DSLs make Scaladocs almost useless in some cases. That is one of Scala's major pain points, IMO. I think Clojure could have a better documentation story. Maybe automatic links inside docstrings? Maybe tagging docstrings (and I mean tags like GMail tags. Something which helps you create ad-hoc groupings)? A lot of folks here are successfully using Clojure in large, complex projects Well, that in itself is reassuring. Can anyone share the size of the team involved? The duration of the project? I realize that young languages don't yet have well-established industry-wide development practices (do old languages?), but some of them bear greater similarity to what we have been doing for years, and some, like Clojure, are more novel (if not in their language concepts, then in their commercial applications). They might hold greater promise, but are more scary to introduce into working teams. I think the developer community, at least those of us more fearful to tread into uncharted territory, would greatly benefit from talks/blog posts focusing on the *process *of developing in Clojure, thus making the territory more... charted. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On Tue, Nov 8, 2011 at 3:14 AM, pron ron.press...@gmail.com wrote: Yeah, sure, but docstrings aren't linkable. It's interesting that Java, with all its faults, has an incredible documentation system. Have you looked at autodoc? It's responsible for generating stuff like this: http://clojure.github.com/java.jdbc/ Direct links to source code, table of contents containing links to all the functions... Well, that in itself is reassuring. Can anyone share the size of the team involved? The duration of the project? I'll leave that to others. World Singles has a small team. The project is ongoing. I started working with Clojure in early 2010 and introduced it at work probably about a year ago as an option for our JVM-based mixed-language codebase. Our first Clojure code went to production in June or July and we're very happy with how things are going. some, like Clojure, are more novel (if not in their language concepts, then in their commercial applications). A lot of working production software has been built with Lisps over the years (but I understand your concerns about the novelty of Clojure, in terms of age). The list of Clojure success stories has a broad range of companies but I'll concede a lot of them are startup-style organizations who are a lot less risk-averse than many corporations: http://dev.clojure.org/display/community/Clojure+Success+Stories -- 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) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On Tuesday, November 8, 2011 8:42:13 PM UTC+2, Sean Corfield wrote: Have you looked at autodoc? Yes, but it lacks cross-referencing and linking from within the docstrings themselves (like Javadoc's @See). I would like to suggest tagging in order to compensate for the lack of Javadoc's Use page (that is possible due to static typing) - something that will allow grouping functions according to concepts and/or data structures in addition to grouping by namespace. BTW, I'd like to say that your Real World Clojure series has been extremely helpful. Thank you for that. I wish someone would write a similar series about the less technological aspects. Something along the lines of Alex Miller's excellent posthttp://tech.puredanger.com/2011/10/20/real-world-clojure/ - we could use more of that! -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On Tue, Nov 8, 2011 at 4:09 PM, pron ron.press...@gmail.com wrote: Yes, but it lacks cross-referencing and linking from within the docstrings themselves (like Javadoc's @See). You can use :see-also metadata to cause autodoc to generate cross-references with links... I think it would be pretty easy to extend autodoc to do more of what you're looking for (but I think it's already closer than you might believe :) BTW, I'd like to say that your Real World Clojure series has been extremely helpful. Thank you for that. I wish someone would write a similar series about the less technological aspects. Something along the lines of Alex Miller's excellent post - we could use more of that! Yup, I plan to write more in that series! -- 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) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
Am 06.11.2011 12:56, schrieb pron: Hi. I'm new to Clojure, and enjoy using it very much. It's been years since I learned Scheme back in college, and it's a pleasure going back to lisp. I do, however, have a question regarding real-world Clojure use in large teams. While I clearly understand the pros of common data access/manipulation, doesn't the lack of encapsulation prove problematic in large projects with many developers? E.g., one developer may add a keyword to a map for one purpose, and another, use the same keyword for a different purpose. give each developer its own namespace for keywords http://stackoverflow.com/questions/2481984/when-should-clojure-keywords-be-in-namespaces from then on, it's the same as an evil oo-developer misusing someone elses field, preferably via reflection so it's difficult to track With classes, all data manipulation for a single type is located in one place, so such clashes can easily be prevented, let alone the fact that encapsulation helps delineate legal operations with the data. I realize there are always tradeoffs, and perhaps the pros outweigh the cons, but I would like to know how you deal with such problems, that invariably arise in large-team development. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
I see. So namespaces are helpful here. What other team practices do you use? E.g. what do you use for effective documentation? With Java you can easily find all helpful operations that can be used to manipulate a type. How do you make sure developers find all relevant functions in Clojure and don't re-implement old functionality? Not that it's a nonexistent problem in the Java world, but Javadoc is very helpful there. I understand my questions could be directed at most dynamic languages, and I'm absolutely not entering the static vs. dynamic debate - but before I recommend Clojure for use in a team, I'd like to hear some experiences. Another member of this forum has asked about refactoring and was told that the problem doesn't arise that often in Clojure. That's good to know. But I would like to hear more. I guess that in some organizations the question is not how do I program in a new language, but how do I develop software in a large team using a new language. I've tried to find some online material that addresses this issue, but couldn't find any. Some languages, such as Erlang, induce a model that is very similar to OO, so the development practices, I can assume, are similar. But Clojure is completely different. I tried to think back to how we did things in C, but there we had header files, that, while annoying, did provide some documentation and communicated intents rather well. But in Clojure the pieces just seem so... disconnected. It is elegant, but does it provide any tools for team communication? Has anyone even encountered such problems at all? And perhaps I shouldn't have used the world invariably. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
I'm new to all this, too. The kinds of teams I've worked on, generally, favor breaking down a problem into separate processes such that we each get to work on our own apps which communicate via messaging or http, so I may not have quite the experience you have with big shared-code libraries (other than jar files downloaded from the net). What I've been moving towards, slowly, is the idea of not caring too much about what the actual thing is that gets passed around from function to function, but instead just caring about the functions themselves and the end-result values. For instance, say you want an S3 client, you might do something like: (let [client (s3/mk-client)] (when (exists? client bucket-name) (post client my-data) (println (s3-get client my-key))) (Please excuse the poor naming.) The client is actually a map with connection info and other metadata, but I just don't have to care as a user of the S3 namespace. All I really need to know is what's public in the s3-client name space. Admittedly, this is really a sort-of OO kind of thing (in which I'm doing method object params rather than object.method(params)) but it really does seem clear when I come back to it later. I've seen other similar usages, such as the various web frameworks, and even the congo-mongo driver. The connection object in congo-mongo is a map with some java-driver objects in it, but you don't ever really have to know that. Just (with-conn conn (collection :data)) or similar. The web apps do similar things with the server you start up: (let [server (mk-jetty-server :port 8080 :mode async :foo bar)] (jetty server start)) But maybe you're talking about value objects? I guess the bottom line is that I feel for you question because I've spend SO LONG in the OO world that I've lost the sense of encapsulation as something separate from classes. K -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
Oops. I somehow it some magic key. Soon as that post makes it through review I'll rewrite it to something short and useful. Moral of the story is to not use the web form on Google Groups. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
actually, we avoid dynamically typed languages like the plague. i am taking a peek at clojure because i'm curious. Am 07.11.2011 11:19, schrieb pron: I see. So namespaces are helpful here. What other team practices do you use? E.g. what do you use for effective documentation? With Java you can easily find all helpful operations that can be used to manipulate a type. can you really? you can quickly find all methods in a certain class, but you never know if there isn't a useful little helper method somewhere. the clojure-equivalent would be functions in namespace How do you make sure developers find all relevant functions in Clojure and don't re-implement old functionality? laziness is the key. Not that it's a nonexistent problem in the Java world, but Javadoc is very helpful there. I understand my questions could be directed at most dynamic languages, and I'm absolutely not entering the static vs. dynamic debate - but before I recommend Clojure for use in a team, I'd like to hear some experiences. Another member it was me :D of this forum has asked about refactoring and was told that the problem doesn't arise that often in Clojure. That's good to know. But I would like to hear more. I guess that in some organizations the question is not how do I program in a new language, but how do I develop software in a large team using a new language. i wouldn't suggest using a language no one has experience in at the start of a new project. you'll mess up the core design and everyone will course you for decades. I've tried to find some online material that addresses this issue, but couldn't find any. Some languages, such as Erlang, induce a model that is very similar to OO, so the development practices, I can assume, are similar. But Clojure is completely different. I tried to think back to how we did things in C, but there we had header files, that, while annoying, did provide some documentation and communicated intents rather well. But in Clojure the pieces just seem so... disconnected. i am beginning to understand how lisp/clojure is supposed to work. can't put it in words yet. It is elegant, but does it provide any tools for team communication? Has anyone even encountered such problems at all? And perhaps I shouldn't have used the world invariably. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On Mon, Nov 7, 2011 at 2:19 AM, pron ron.press...@gmail.com wrote: What other team practices do you use? E.g. what do you use for effective documentation? docstrings? I understand my questions could be directed at most dynamic languages, and I'm absolutely not entering the static vs. dynamic debate Hmm, but if your questions could fit most dynamic languages, you can't really avoid the static vs dynamic debate... But I would like to hear more. A lot of folks here are successfully using Clojure in large, complex projects so you may need to move from listening to trying things out for yourself at this point. Maybe Clojure will work for you, maybe it won't. I've seen this sort of question in every language forum over the years - existing users can justify to some extent but not all languages work for everyone... -- 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) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On Mon, Nov 7, 2011 at 10:23 AM, Dennis Haupt d.haup...@googlemail.com wrote: actually, we avoid dynamically typed languages like the plague. Why? Genuinely curious... -- 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) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Another newbie question
Hi. I'm new to Clojure, and enjoy using it very much. It's been years since I learned Scheme back in college, and it's a pleasure going back to lisp. I do, however, have a question regarding real-world Clojure use in large teams. While I clearly understand the pros of common data access/manipulation, doesn't the lack of encapsulation prove problematic in large projects with many developers? E.g., one developer may add a keyword to a map for one purpose, and another, use the same keyword for a different purpose. With classes, all data manipulation for a single type is located in one place, so such clashes can easily be prevented, let alone the fact that encapsulation helps delineate legal operations with the data. I realize there are always tradeoffs, and perhaps the pros outweigh the cons, but I would like to know how you deal with such problems, that invariably arise in large-team development. Thanks. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On Sun, Nov 6, 2011 at 03:56, pron ron.press...@gmail.com wrote: Hi. I'm new to Clojure, and enjoy using it very much. It's been years since I learned Scheme back in college, and it's a pleasure going back to lisp. I do, however, have a question regarding real-world Clojure use in large teams. While I clearly understand the pros of common data access/manipulation, doesn't the lack of encapsulation prove problematic in large projects with many developers? E.g., one developer may add a keyword to a map for one purpose, and another, use the same keyword for a different purpose. Is this in any way different to how the developer might use a slot on a class, or a get/set method pair for different purposes? With classes, all data manipulation for a single type is located in one place, so such clashes can easily be prevented, let alone the fact that encapsulation helps delineate legal operations with the data. I realize there are always tradeoffs, and perhaps the pros outweigh the cons, but I would like to know how you deal with such problems, that invariably arise in large-team development. From my experience, if you have an architecture that encourages developers to think in terms of discrete functional units, and to have documented interfaces between the functional units, you wind up with a system that works - regardless of the control the language expresses over access to members. On the other hand, if you have an architecture (or culture) that encourages poking into the implementation details, or just getting things done - the pragmatic solution - rather than doing things right, you will wind up with problems no matter which approach you take. In other words I question your invariably, rather than any other part of your statement. These are not automatic problems, and they are not all that, in my experience, related to the degree that your language forces you to go through a single channel for all access to a particular bit of data. Do you have more concrete concerns here, or is it just the general assumption that without data hiding and a one object, one file model you can't have a working large scale system? Daniel -- ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On 6/11/2011 12:56, pron wrote: E.g., one developer may add a keyword to a map for one purpose, and another, use the same keyword for a different purpose. With classes, all data manipulation for a single type is located in one place, so such clashes can easily be prevented, let alone the fact that encapsulation helps delineate legal operations with the data. One way to encapsulate things in clojure is namespaces. For this specific example you gave there, one might use namespace qualified keywords to add some data to your map. This way name clashes are only possible when you want them. I am actually using that very technique to add application (and namespace) specific data to the request map from a ring (web) application as it is passed further down through different namespaces during the routing of the request. Namespaces can have private vars and functions as well. The documented interfaces mentioned by Daniel are very useful too, protocols are providing this functionality. Though i must confess I sometimes still use multimethods to that effect =) In my opinion, far from being a weakness, programming in the large is a strong point of clojure. Sacha -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Another newbie question
On Sun, Nov 6, 2011 at 3:56 AM, pron ron.press...@gmail.com wrote: I realize there are always tradeoffs, and perhaps the pros outweigh the cons, but I would like to know how you deal with such problems, that invariably arise in large-team development. Why do you think this sort of problem is invariably going to arise in large-team development? -- 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) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
