Re: ANN: Reagent 0.3.0 - now with async rendering
Cheers, Dan! I'm doing experiments with both Reagent and Om at the moment, and I'm very excited about this way of rendering changes to a webpage. I particularly enjoy how easy it is to work with Reagent's API, and appreciate the time you are putting into this project. One of the major wins is how explicit I can be with where I put state. My current experimental design puts state squarely in two places only: an atom in the client, and the database (Datomic, for the time being). The server essentially behaves like a pure function only. I don't have time to enumerate all the benefits of this design as opposed to the mess I usually encounter, where state is stored absolutely everywhere. On Monday, February 3, 2014 3:24:25 PM UTC+1, Dan Holmsand wrote: Reagent, a minimalistic interface between React.js and ClojureScript, is now at 0.3.0. The new release adds a couple of bugfixes, and async rendering. Read more here: http://holmsand.github.io/reagent/news/reagent-is-async.html The project page is here: https://github.com/holmsand/reagent Cheers, /dan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Caribou: Unable to create a model that has a self reference!
Hey!
i hope this is the right place to ask this question! Here it goes: I want
to create a simple model with cariou that references itself to generate a
tree-structure. Like this:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name related-categories :type link
:target-id (model/models :category :id)
:reciprocal-name
relating-categories}]}))
This results in a:
DEBUG :db insert into field values dependent = false, slug =
'relating-categories', position = 201, map = false, localized = false, name
= 'relating-categories', locked = false, model-id = '', target-id = 22,
uuid = '13776b59-7359-4412-850f-ffaa619665e0', type = 'link', updated-at =
'2014-02-04 09:53:48.578', model-position = 201, link-id = 380,
status-position = 139
Exception in thread main org.h2.jdbc.JdbcSQLException: NULL not allowed
for column MODEL_ID; SQL statement:
INSERT INTO field
(dependent,slug,position,map,localized,name,locked,model_id,target_id,uuid,type,updated_at,model_position,link_id,status_position)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) [23502-170]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.table.Column.validateConvertUpdateSequence(Column.java:293)...
Because the category to be reference is not yet available. Is there a way
to create a model and afterwards update it with constraints (Like you would
do in SQL)!?
Btw. naturally the other way around will dont work either:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name keywords :type string}
{:name parent-category :type part
:target-id (model/models :category :id)
:reciprocal-name child-categories}]}))
And the bidirectional (or in caribou-speech: reciprocal) also not:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name keywords :type string}
{:name parent-category :type link
:target-id (model/models :category
:id)}]}))
Any hints? Btw. Caribou is really pragmatic, fast and clean, love it!
NoSQL/Riak support would awesome too!
Thanks and regards,
David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Caribou: Unable to create a model that has a self reference!
... one step closer:
(defn category []
((model/create :model {:name category
:fields [{:name Label :type string}
{:name keywords :type string}
{:name parent-id :type integer}]})
(db/add-reference :field :parent-id :category :destroy)))
now i have to touch the model-table somehow.
Am Dienstag, 4. Februar 2014 10:11:06 UTC+1 schrieb David Baldin:
Hey!
i hope this is the right place to ask this question! Here it goes: I want
to create a simple model with cariou that references itself to generate a
tree-structure. Like this:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name related-categories :type link
:target-id (model/models :category :id)
:reciprocal-name
relating-categories}]}))
This results in a:
DEBUG :db insert into field values dependent = false, slug =
'relating-categories', position = 201, map = false, localized = false, name
= 'relating-categories', locked = false, model-id = '', target-id = 22,
uuid = '13776b59-7359-4412-850f-ffaa619665e0', type = 'link', updated-at =
'2014-02-04 09:53:48.578', model-position = 201, link-id = 380,
status-position = 139
Exception in thread main org.h2.jdbc.JdbcSQLException: NULL not allowed
for column MODEL_ID; SQL statement:
INSERT INTO field
(dependent,slug,position,map,localized,name,locked,model_id,target_id,uuid,type,updated_at,model_position,link_id,status_position)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) [23502-170]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.table.Column.validateConvertUpdateSequence(Column.java:293)...
Because the category to be reference is not yet available. Is there a way
to create a model and afterwards update it with constraints (Like you would
do in SQL)!?
Btw. naturally the other way around will dont work either:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name keywords :type string}
{:name parent-category :type part
:target-id (model/models :category :id)
:reciprocal-name child-categories}]}))
And the bidirectional (or in caribou-speech: reciprocal) also not:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name keywords :type string}
{:name parent-category :type link
:target-id (model/models :category
:id)}]}))
Any hints? Btw. Caribou is really pragmatic, fast and clean, love it!
NoSQL/Riak support would awesome too!
Thanks and regards,
David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Caribou: Unable to create a model that has a self reference!
Well, source-code is the best documentation:
(defn category []
((model/create :model {:name category
:fields [{:name Label :type string}]})
(let [category-model-id (model/models :category :id)]
(model/update :model category-model-id {:name category
:fields [{:name parent-category
:type part
:target-id prod-model-id
:reciprocal-name
sub-categories}]}
Documentation of caribou.model/create and caribou.model/update describes it
all!
Have a nice day!
Am Dienstag, 4. Februar 2014 10:11:06 UTC+1 schrieb David Baldin:
Hey!
i hope this is the right place to ask this question! Here it goes: I want
to create a simple model with cariou that references itself to generate a
tree-structure. Like this:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name related-categories :type link
:target-id (model/models :category :id)
:reciprocal-name
relating-categories}]}))
This results in a:
DEBUG :db insert into field values dependent = false, slug =
'relating-categories', position = 201, map = false, localized = false, name
= 'relating-categories', locked = false, model-id = '', target-id = 22,
uuid = '13776b59-7359-4412-850f-ffaa619665e0', type = 'link', updated-at =
'2014-02-04 09:53:48.578', model-position = 201, link-id = 380,
status-position = 139
Exception in thread main org.h2.jdbc.JdbcSQLException: NULL not allowed
for column MODEL_ID; SQL statement:
INSERT INTO field
(dependent,slug,position,map,localized,name,locked,model_id,target_id,uuid,type,updated_at,model_position,link_id,status_position)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) [23502-170]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.table.Column.validateConvertUpdateSequence(Column.java:293)...
Because the category to be reference is not yet available. Is there a way
to create a model and afterwards update it with constraints (Like you would
do in SQL)!?
Btw. naturally the other way around will dont work either:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name keywords :type string}
{:name parent-category :type part
:target-id (model/models :category :id)
:reciprocal-name child-categories}]}))
And the bidirectional (or in caribou-speech: reciprocal) also not:
(defn category []
(model/create :model {:name category
:fields [{:name Label :type string}
{:name keywords :type string}
{:name parent-category :type link
:target-id (model/models :category
:id)}]}))
Any hints? Btw. Caribou is really pragmatic, fast and clean, love it!
NoSQL/Riak support would awesome too!
Thanks and regards,
David
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Reagent 0.3.0 - now with async rendering
Gotta ask, what's the difference between Om and Reagent? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Another binary parser combinator - this time for java's streams
Thanks, header seems very useful and relevant to what I was doing, but I ended up doing something slightly different because I needed to include the information retrieved using the chunk header codec in the final result (specifically, the type of the chunk). Here is some code: https://gist.github.com/stathissideris/8801295 select-codec is almost identical to header (didn't bother with writing in this case), but it also merges the result of the decision-codec with the result of the selected codec. Of course it's less generic than header because it makes the assumption that we're dealing with maps. Also, note the use of core.match to decide on what codec to use. Stathis On Monday, 3 February 2014 16:50:12 UTC, Steffen Dienst wrote: I would use header for this: (def chunk (header :int-be #(ordered-map :type (b/repeated :byte :length 4) :data (b/repeated :byte :length %) :crc (b/repeated :byte :length 4)) #(count (:data % The resulting data structure would not contain the field length in this case. Length only gets used to configure the inner codec for the body (the map with :type, :data and :crc). You can read this codec as: Read a big-endian integer, then use this value to construct a new codec to read the body. When writing, count the :data field, write the length using :type and then write the body. Steffen 2014-02-03 Stathis Sideris sid...@gmail.com javascript:: Hello, Is it possible to use 'repeated with a dynamic size if the length-defining prefix does not directly precede the content? For example, see PNG chunks: http://en.wikipedia.org/wiki/Portable_Network_Graphics#.22Chunks.22_within_the_file The codec would be: (def chunk (b/ordered-map :length :int-be :type (b/repeated :byte :length 4) :data (b/repeated :byte :length ???) :crc (b/repeated :byte :length 4))) What do I put in the place of ??? Thanks, Stathis On Friday, 31 January 2014 08:12:23 UTC, Steffen Dienst wrote: Thanks, I fixed the documentation issues. Feel free to share your id3 tags parser, if you like :) You can see that mine is still stuck at the very beginning.. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 a topic in the Google Groups Clojure group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/2c9-oXfKlp0/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why do I get stackoverflow error?
Ok thanks, thats really helpful. The second link suggests using doall, which seems to do the trick : ((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) (map (partial reduce +) (doall (partition 2 1 (concat [0] row [0] 500) However you do lose the laziness, but here the laziness is not needed ... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why do I get stackoverflow error?
Similarly this works for my non-recursive effort, which I think is more concise : (fn [n] (nth (iterate (fn [r] (map (partial reduce +) (doall (partition 2 1 (concat [0N] r [0]) [1]) (dec n))) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to organize clojure functions? A clojure newbie here...
I think the right (or maybe idiomatic is a better word) organisation is an effect of a very important cause - changing the way you think about a software system. Simplistically, OO promises to be a world full of chunks of knowledge and behaviour that politely ask other chunks to behave in a certain way. You have relatively narrow but very deep 'shapes' as levels of abstraction increase. Realistically we all know how that goes :). In FP the form the structure of the knowledge itself is your primary chunk with a many little chunks of functionality that all know how to transform one shape to another. You have a relatively wide and shallow 'shapes' that all work on a few core chunks of knowledge (i.e. state). To put it another way, I find it really helpful in Clojure to phrase the question 'what shape data do I need and which transformations are necessary'. It isn't quite on its head, but close. You can absolutely still address encapsulation, domain abstractions etc. (http://thinkrelevance.com/blog/2009/08/12/rifle-oriented-programming-with-clojure-2) but start with the shapes of knowledge. All of the above is incredibly simplistic, 'wrong' for some definition of wrong but it is something I wish somebody had told me when I was first starting out :). On Monday, 3 February 2014 08:47:09 UTC, Aravindh S wrote: Hi All, I am new to clojure and have been working with the language for the past one week. I have got a basic hold of the constructs in clojure. I have been programming for 4 years in C# now. One thing I am not able to comprehend is how clojure programs are structured. In an OO world, I know what are the entities that the program should have, how they will be related etc. I am not able to do the same wit clojure. I agree that words like classes, methods dont make much sense in functional programming. I am precisely looking for a program written in clojure ( A medium level program say about 200 - 300 LOC) which clearly tells how a problem domain should be approached in a functional manner using clojure, how the functions should be organized. A specific solution for specific problem will be helpful. Thanks Aravindh.S -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a problem in FP when FP is done right. OO + mutable state = hard to reason about. FP + immutable state + pure/referentially transparent functions = much easier to reason about. Or not. Just my 2 pence :). On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
I don't want to seem rude but I think you've drank a bit too much kool-aid. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a problem in FP when FP is done right. OO + mutable state = hard to reason about. FP + immutable state + pure/referentially transparent functions = much easier to reason about. Or not. Just my 2 pence :). On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. pgpVKilgv_syW.pgp Description: PGP signature
Re: [ClojureScript] ANN: Reagent 0.3.0 - now with async rendering
Thanks, I enjoy writing it! ClojureScript is such a delight to use (except, of course, when Closure's advanced compilation bites you where it hurts). :) /dan On 4 feb 2014, at 09:09, Henrik Eneroth henrik.ener...@gmail.com wrote: Cheers, Dan! I'm doing experiments with both Reagent and Om at the moment, and I'm very excited about this way of rendering changes to a webpage. I particularly enjoy how easy it is to work with Reagent's API, and appreciate the time you are putting into this project. One of the major wins is how explicit I can be with where I put state. My current experimental design puts state squarely in two places only: an atom in the client, and the database (Datomic, for the time being). The server essentially behaves like a pure function only. I don't have time to enumerate all the benefits of this design as opposed to the mess I usually encounter, where state is stored absolutely everywhere. On Monday, February 3, 2014 3:24:25 PM UTC+1, Dan Holmsand wrote: Reagent, a minimalistic interface between React.js and ClojureScript, is now at 0.3.0. The new release adds a couple of bugfixes, and async rendering. Read more here: http://holmsand.github.io/reagent/news/reagent-is-async.html The project page is here: https://github.com/holmsand/reagent Cheers, /dan -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/tWHJg7xcnbg/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Lessons Learned from Adopting Clojure
tl; dr: I'm presenting Lessons Learned from Adopting Clojure in Chicago on Feb 11th: http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn't a match made in heaven. Fast forward five years, Clojure is the second most used language in the firm, and the primary language for several teams (including mine). Clojure wasn't the first language that I've introduced to an organization; however, it's unquestionably the most successful adoption I've ever been a part of. The use of Clojure has had many impacts on the firm: culturally, politically, and technically. My talk will discuss general ideas around language selection and maintenance trade-offs, and specific examples of what aspects of Clojure made it the correct choice for us. A few highlights - Where to first introduce a new language and your role as the language care-taker. - REPL driven development, putting TDD's 'rapid feedback' to shame. - Operations impact of adding a language - i.e. get ready for some DevOps. - Functional programming, the Lisp Advantage, and their impact on maintainability. Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I'll happily to describe those as well. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
My 2c - on my last project it would have been handy to have some test coverage tools, they can be useful to sanity check your testing. However, it's worth noting that compared to a java project, we had far fewer lines of code, so manually reviewing code for tests was a lot easier. And there were cases where some careful integration tests were more useful than unit testing everything, which ties in to Colin's point I think. And integration tests tend to break coverage metrics. (and I'm not sure how you'd do coverage for macros, but that's probably a digression) - Korny On 4 Feb 2014 11:23, Aaron France aaron.l.fra...@gmail.com wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a problem in FP when FP is done right. OO + mutable state = hard to reason about. FP + immutable state + pure/referentially transparent functions = much easier to reason about. Or not. Just my 2 pence :). On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
Comments in line. On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. You know the phrase I don't want to seem rude doesn't actually do anything right? :) To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java) using the current best of breed technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed process (agile, TDD, DBC, BDD, most other TLAs etc.). Using Clojure for the past year or so has opened my eyes to exactly how many problems we solve, and infrastructure we use is to pamper to complexity introduced by the tool-chain not the problem domain. I am suggesting maybe coverage tools are one of those. Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a problem in FP when FP is done right. OO + mutable state = hard to reason about. FP + immutable state + pure/referentially transparent functions = much easier to reason about. Or not. Just my 2 pence :). On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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. -- 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
Re: Lessons Learned from Adopting Clojure
Is there going to be online access during/after the event? I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :). On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote: tl; dr: I'm presenting Lessons Learned from Adopting Clojure in Chicago on Feb 11th: http://www.eventbrite.com/e/goto-night-with-jay-fields-tickets-10366768283?aff=eorgf Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn't a match made in heaven. Fast forward five years, Clojure is the second most used language in the firm, and the primary language for several teams (including mine). Clojure wasn't the first language that I've introduced to an organization; however, it's unquestionably the most successful adoption I've ever been a part of. The use of Clojure has had many impacts on the firm: culturally, politically, and technically. My talk will discuss general ideas around language selection and maintenance trade-offs, and specific examples of what aspects of Clojure made it the correct choice for us. A few highlights - Where to first introduce a new language and your role as the language care-taker. - REPL driven development, putting TDD's 'rapid feedback' to shame. - Operations impact of adding a language - i.e. get ready for some DevOps. - Functional programming, the Lisp Advantage, and their impact on maintainability. Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I'll happily to describe those as well. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
In clojure, generally I've found Unit-tests are often significantly harder to write than the corresponding implementing code, idiomatic code rarely has silly problems, and integration tests are enough to shake out bad behavior. So, the end result is constraining our codebase at API boundaries with integration tests does pretty well, and unit tests are most likely to get written only when I'm doing something weird and nasty. On Tue, Feb 4, 2014 at 7:14 AM, Korny Sietsma ko...@sietsma.com wrote: My 2c - on my last project it would have been handy to have some test coverage tools, they can be useful to sanity check your testing. However, it's worth noting that compared to a java project, we had far fewer lines of code, so manually reviewing code for tests was a lot easier. And there were cases where some careful integration tests were more useful than unit testing everything, which ties in to Colin's point I think. And integration tests tend to break coverage metrics. (and I'm not sure how you'd do coverage for macros, but that's probably a digression) - Korny On 4 Feb 2014 11:23, Aaron France aaron.l.fra...@gmail.com wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a problem in FP when FP is done right. OO + mutable state = hard to reason about. FP + immutable state + pure/referentially transparent functions = much easier to reason about. Or not. Just my 2 pence :). On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send
Re: ANN: Reagent 0.3.0 - now with async rendering
On Tuesday, February 4, 2014 11:24:16 AM UTC+1, Robin Heggelund Hansen wrote: Gotta ask, what's the difference between Om and Reagent? Well, I'd say that the basic functionality of the two is quite similar: it's all about efficiently transforming some application state into a UI description (that is then turned into actual UI by React). The differences come at both ends of that transformation. Om is much more ambitious when it comes to managing that application state. It helps you to handle changing state (and tells you how to do that), whereas with Reagent you're pretty much on your own there. Reagent is just about rendering a UI, and leaves state management to you. At the other end, the UI description in Reagent is a vector of vectors (with the same structure as in Hiccup), whereas Om uses React's javascript fake DOM elements more or less directly. Reagent on the other hand keeps the UI description as immutable data until it really has to tell React what to put out there. Then there are obviously some differences in API, but I think that these are more superficial. David might disagree strongly, of course :) /dan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
+1 I still force myself to write those tests simply for the confidence they give me in replacing my hack with idiomatic code as I/colleagues get more familiar down the road. I can absolutely see dramatically reducing the number of 'safety rails' type tests pretty soon; most of the code uses the core abstractions. It is quite humbling/interesting how little new code I actually need to write as oppose to picking one/assembling some off the shelf. On Tuesday, 4 February 2014 12:22:57 UTC, Gary Trakhman wrote: In clojure, generally I've found Unit-tests are often significantly harder to write than the corresponding implementing code, idiomatic code rarely has silly problems, and integration tests are enough to shake out bad behavior. So, the end result is constraining our codebase at API boundaries with integration tests does pretty well, and unit tests are most likely to get written only when I'm doing something weird and nasty. On Tue, Feb 4, 2014 at 7:14 AM, Korny Sietsma ko...@sietsma.comjavascript: wrote: My 2c - on my last project it would have been handy to have some test coverage tools, they can be useful to sanity check your testing. However, it's worth noting that compared to a java project, we had far fewer lines of code, so manually reviewing code for tests was a lot easier. And there were cases where some careful integration tests were more useful than unit testing everything, which ties in to Colin's point I think. And integration tests tend to break coverage metrics. (and I'm not sure how you'd do coverage for macros, but that's probably a digression) - Korny On 4 Feb 2014 11:23, Aaron France aaron.l...@gmail.com javascript: wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a problem in FP when FP is done right. OO + mutable state = hard to reason about. FP + immutable state + pure/referentially transparent functions = much easier to reason about. Or not. Just my 2 pence :). On Sunday, 2 February 2014 21:34:29 UTC, Aaron France wrote: Hi, I'm looking for coverage reporting in Clojure. I've been using Cloverage[1] but I'm just wondering if there are any other coverage tools? Aaron [1] https://github.com/lshift/cloverage -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated -
Re: Lessons Learned from Adopting Clojure
Interesting! A question: did you abandon TDD? why? IMO, TDD is a workflow that pushes for simplicity On Tue, Feb 4, 2014 at 9:22 AM, Colin Yates colin.ya...@gmail.com wrote: Is there going to be online access during/after the event? I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :). On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote: tl; dr: I'm presenting Lessons Learned from Adopting Clojure in Chicago on Feb 11th: http://www.eventbrite.com/e/goto-night-with-jay-fields- tickets-10366768283?aff=eorgf Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn't a match made in heaven. Fast forward five years, Clojure is the second most used language in the firm, and the primary language for several teams (including mine). Clojure wasn't the first language that I've introduced to an organization; however, it's unquestionably the most successful adoption I've ever been a part of. The use of Clojure has had many impacts on the firm: culturally, politically, and technically. My talk will discuss general ideas around language selection and maintenance trade-offs, and specific examples of what aspects of Clojure made it the correct choice for us. A few highlights - Where to first introduce a new language and your role as the language care-taker. - REPL driven development, putting TDD's 'rapid feedback' to shame. - Operations impact of adding a language - i.e. get ready for some DevOps. - Functional programming, the Lisp Advantage, and their impact on maintainability. Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I'll happily to describe those as well. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
+1 from Melbourne :) On 4 February 2014 23:22, Colin Yates colin.ya...@gmail.com wrote: Is there going to be online access during/after the event? I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :). On Tuesday, 4 February 2014 12:06:06 UTC, Jay Fields wrote: tl; dr: I'm presenting Lessons Learned from Adopting Clojure in Chicago on Feb 11th: http://www.eventbrite.com/e/goto-night-with-jay-fields- tickets-10366768283?aff=eorgf Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn't a match made in heaven. Fast forward five years, Clojure is the second most used language in the firm, and the primary language for several teams (including mine). Clojure wasn't the first language that I've introduced to an organization; however, it's unquestionably the most successful adoption I've ever been a part of. The use of Clojure has had many impacts on the firm: culturally, politically, and technically. My talk will discuss general ideas around language selection and maintenance trade-offs, and specific examples of what aspects of Clojure made it the correct choice for us. A few highlights - Where to first introduce a new language and your role as the language care-taker. - REPL driven development, putting TDD's 'rapid feedback' to shame. - Operations impact of adding a language - i.e. get ready for some DevOps. - Functional programming, the Lisp Advantage, and their impact on maintainability. Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I'll happily to describe those as well. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Cheers, Rafael Peixoto de Azevedo http://www.symprise.net @RPAzevedo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Feb 4, 2014, at 1:06 PM, Jay Fields j...@jayfields.com wrote: Hi Jay, thanks for the report. I only have few doubts about REPL making TDD to shame. I'm not a TDD practitioner, but I would not be so tranchant with it. The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other. I'm a fan of http://www.youtube.com/user/Misophistful?feature=watch stuff. he's able to be very clear and deep at the same time and if you take a look at his screencasts you would see that he uses both the REPL and the TDD at the same time. And he uses both unit test and simple-check tests as well. It is true that at the moment the feedback-loop in clojurescript is not feasible, but the REPL experience with cljs has to be improved too to make it comparable with the clj REPL experience (at least with a nREPL compliant editor/ide). Cheers mimmo - REPL driven development, putting TDD's 'rapid feedback' to shame. - Operations impact of adding a language - i.e. get ready for some DevOps. - Functional programming, the Lisp Advantage, and their impact on maintainability. Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I'll happily to describe those as well. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC 2014: org applications now open
Daniel, I'd be happy to help as an administrator, particularly if you can provide some guidance from previous years. I can also help re getting students to conferences. Alex On Monday, February 3, 2014 1:59:24 PM UTC-6, Daniel Solano Gómez wrote: Hello, all, Apparently, it's already time for organisations to apply for Google Summer of Coder 2014 [1]. This is a great program, and there have been several notable projects that have benefited as a result. For example, last year's successful projects included: * Enhance Neko for Android, Alexander Yakushev * core.typed: Extensions and Documentation, Ambrose Bonnaire-Sergeant * Clojure Compiler port to Clojure (CinC), Bronsa * Implementation of core.matrix-compatible multidimensional array in Clojure, Dmitry Groshev * Algebraic Expressions, Maik Schünemann * ClojureScript optimization and source maps support, Michal Marczyk I would love to see Clojure participate again this year. In order to do so, we need to start our application which is due in less than two weeks. We need volunteers to help prepare our application, and in particular it would be great to have administrators that can help lead the process. I am certainly willing to help out, but if there is someone who wants to lead up this effort, I would happy to assist. Ideally, we could have multiple administrators to spread out the following duties: * Updating the community wiki for the year [2] * Recruiting potential mentors * Raising the profile of GSoC within the community If we are accepted as a GSoC organisation, administrator duties include: * Ensuring we meet the deadlines * Arranging for travel to the mentor submit * Arranging for students' travel to conferences * If necessary, solve problems I am afraid that last year I let the ball drop a bit with the mentor summit and getting students to conferences. With multiple administrators to help spread the work around, I am sure we can make GSoC an even better experience for everyone involved. If you are interested in helping out in this effort, please set up a profile on Melange [3] and e-mail me your profile name. Thanks for your help. Sincerely, Daniel [1]: http://google-opensource.blogspot.com/2014/02/mentoring-organization-applications-now.html [2]: http://dev.clojure.org/display/community/Google+Summer+of+Code+2013 [3]: http://en.flossmanuals.net/melange/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: Comments in line. On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. You know the phrase I don't want to seem rude doesn't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java) using the current best of breed technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed process (agile, TDD, DBC, BDD, most otherTLAs etc.). Arguments from authority mean nothing on the internet. Using Clojure for the past year or so has opened my eyes to exactly how many problems we solve, and infrastructure we use is to pamper to complexity introduced by the tool-chain not the problem domain. I am suggesting maybe coverage tools are one of those. Coverage helps nothing on its own. It's a tool to aid in knowing which aspects of your system remain untested. It's fine to *believe* you're testing 100% of your system, but how do you actually know this? If you wander into a codebase you're not familiar with, what's the coverage? How do you know you're hitting all codepaths? You just cannot know this without reading all the code and the tests. Coverage helps to discover this information. My point isn't to eschew all other forms of testing in favour of coverage reports but to use them in tandem with the others to aid me in *knowing* which parts of the system are being tested and which are not. Aaron Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk of the potentially large and hard-to-identify 'impact analysis' you get in OO systems when you change state. In other words, coverage is necessary because we want to feel safe that all combinations of our code are extensively tested. Why don't we feel safe? Because the system is hard to reason about. Functional programming on the other hand is full of much smaller discrete and independent chunks of functionality. Ideally these small focused 'bricks' are pure/referentially transparent so the *only* context you need when reasoning about them is their parameters and the logic inside. Assembling these bricks introduces interactions that need to be tested, sure, but there are very few 'call this and watch the change cascade'/'this code is sensitive (i.e. coupled) to that data over there'. My ramblings are to say, maybe the root cause of coverage tools is to solve a problem (hard to reason about systems) which shouldn't be much less of a
Re: Coverage tools in Clojure
This has turned into an unconstructive argument and for whatever reason we don't seem to be communicating clearly. Shame as I (and probably most people on here) only want to help. You seem to be reacting quite strongly to my thoughts - not sure why. If I may, I will just make/rephrase two points: - I think you would find value in watching Rick Hickey's videos on Simple Made Easy and also the one where he talks about Hammock Driven Development. - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to re-examine and build up a whole new toolchain/approach to development that IME is significantly lighter and more powerful. Peace. On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: Comments in line. On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. You know the phrase I don't want to seem rude doesn't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java) using the current best of breed technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed process (agile, TDD, DBC, BDD, most otherTLAs etc.). Arguments from authority mean nothing on the internet. Using Clojure for the past year or so has opened my eyes to exactly how many problems we solve, and infrastructure we use is to pamper to complexity introduced by the tool-chain not the problem domain. I am suggesting maybe coverage tools are one of those. Coverage helps nothing on its own. It's a tool to aid in knowing which aspects of your system remain untested. It's fine to *believe* you're testing 100% of your system, but how do you actually know this? If you wander into a codebase you're not familiar with, what's the coverage? How do you know you're hitting all codepaths? You just cannot know this without reading all the code and the tests. Coverage helps to discover this information. My point isn't to eschew all other forms of testing in favour of coverage reports but to use them in tandem with the others to aid me in *knowing* which parts of the system are being tested and which are not. Aaron Aaron On Tue, Feb 04, 2014 at 03:19:05AM -0800, Colin Yates wrote: I don't know. But maybe the lack of coverage tools is itself interesting? My (not quite formed/making this up as I go) view is that maybe coverage tools are there to address the implicit complexity in other mainstream languages and/or to help mitigate the risk
Re: Coverage tools in Clojure
I don't come from 'Java-land'. I'm primarily an Erlang developer, which already is a very similar language to Clojure. Perhaps this is why I'm not gushing about functional programming's panacea? Aaron On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: This has turned into an unconstructive argument and for whatever reason we don't seem to be communicating clearly. Shame as I (and probably most people on here) only want to help. You seem to be reacting quite strongly to my thoughts - not sure why. If I may, I will just make/rephrase two points: - I think you would find value in watching Rick Hickey's videos on Simple Made Easy and also the one where he talks about Hammock Driven Development. - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to re-examine and build up a whole new toolchain/approach to development that IME is significantly lighter and more powerful. Peace. On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: Comments in line. On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. You know the phrase I don't want to seem rude doesn't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java) using the current best of breed technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed process (agile, TDD, DBC, BDD, most otherTLAs etc.). Arguments from authority mean nothing on the internet. Using Clojure for the past year or so has opened my eyes to exactly how many problems we solve, and infrastructure we use is to pamper to complexity introduced by the tool-chain not the problem domain. I am suggesting maybe coverage tools are one of those. Coverage helps nothing on its own. It's a tool to aid in knowing which aspects of your system remain untested. It's fine to *believe* you're testing 100% of your system, but how do you actually know this? If you wander into a codebase you're not familiar with, what's the coverage? How do you know you're hitting all codepaths? You just cannot know this without reading all the code and the tests. Coverage helps to discover this information. My point isn't to eschew all other forms of testing in favour of coverage reports but to use them in tandem with the others to aid me in *knowing* which parts of the system are being tested and which are not. Aaron Aaron
Re: Coverage tools in Clojure
I have no idea why you aren't gushing. I'm not gushing, and haven't gushed about anything technical for years because everything is a trade off and has its own compromises/ceremony. I can see (and highly value) the benefits of Clojure, sure. If you want to write of my point of view as 'gushing' and not bother to read it correctly then fine. However, what is your objective in posting your statement to a public forum if not to start an argument? If you insist on sending more flame bait/trying to get a rise then let's take this offline and keep this list low noise. My email address is colin full stop yates @ Google's mailing servers.com. On Tuesday, 4 February 2014 14:17:25 UTC, Aaron France wrote: I don't come from 'Java-land'. I'm primarily an Erlang developer, which already is a very similar language to Clojure. Perhaps this is why I'm not gushing about functional programming's panacea? Aaron On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: This has turned into an unconstructive argument and for whatever reason we don't seem to be communicating clearly. Shame as I (and probably most people on here) only want to help. You seem to be reacting quite strongly to my thoughts - not sure why. If I may, I will just make/rephrase two points: - I think you would find value in watching Rick Hickey's videos on Simple Made Easy and also the one where he talks about Hammock Driven Development. - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to re-examine and build up a whole new toolchain/approach to development that IME is significantly lighter and more powerful. Peace. On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: Comments in line. On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. You know the phrase I don't want to seem rude doesn't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java) using the current best of breed technology stacks (i.e Spring/Hibernate/AspectJ) with the best of breed process (agile, TDD, DBC, BDD, most otherTLAs etc.). Arguments from authority mean nothing on the internet. Using Clojure for the past year or so has opened my eyes to exactly how many problems we solve, and
Re: Coverage tools in Clojure
I took issue with you maintaining that Clojure automatically somehow gives you insight into the coverage of your tests. Which it does not. You still maintain this. On Tue, Feb 04, 2014 at 06:28:51AM -0800, Colin Yates wrote: I have no idea why you aren't gushing. I'm not gushing, and haven't gushed about anything technical for years because everything is a trade off and has its own compromises/ceremony. I can see (and highly value) the benefits of Clojure, sure. If you want to write of my point of view as 'gushing' and not bother to read it correctly then fine. However, what is your objective in posting your statement to a public forum if not to start an argument? If you insist on sending more flame bait/trying to get a rise then let's take this offline and keep this list low noise. My email address is colin full stop yates @ Google's mailing servers.com. On Tuesday, 4 February 2014 14:17:25 UTC, Aaron France wrote: I don't come from 'Java-land'. I'm primarily an Erlang developer, which already is a very similar language to Clojure. Perhaps this is why I'm not gushing about functional programming's panacea? Aaron On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: This has turned into an unconstructive argument and for whatever reason we don't seem to be communicating clearly. Shame as I (and probably most people on here) only want to help. You seem to be reacting quite strongly to my thoughts - not sure why. If I may, I will just make/rephrase two points: - I think you would find value in watching Rick Hickey's videos on Simple Made Easy and also the one where he talks about Hammock Driven Development. - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to re-examine and build up a whole new toolchain/approach to development that IME is significantly lighter and more powerful. Peace. On Tuesday, 4 February 2014 13:49:49 UTC, Aaron France wrote: On Tue, Feb 04, 2014 at 04:18:30AM -0800, Colin Yates wrote: Comments in line. On Tuesday, 4 February 2014 11:23:36 UTC, Aaron France wrote: I don't want to seem rude but I think you've drank a bit too much kool-aid. You know the phrase I don't want to seem rude doesn't actually do anything right? :) I genuinely don't want to offend. People allow themselves to become vested in their viewpoint. If that has happened to you, I'm sorry. To say that functional programming and war against state means that your application doesn't need to be tested thoroughly is a joke. And a very bad one. I agree, but who is saying that? I certainly didn't cover how much testing is necessary. I thoroughly test my Clojure systems using midje, which regularly rocks my world. My point is that the coverage is much *much* easier to reason about in FP than in OO (for the reasons I gave). I'm not following how you translate this into information which explains how your system is being tested. Coverage doesn't just aid you in seeing which parts of state caused which branches to be hit, it also gives you notice if there are any logical errors in your code which cause the branches to not be hit. And why are those logical errors which cause the branches to not be hit not immediately obvious? Why do you need a tool to tell you that? I know my Clojure code has around 100% coverage using white box testing for the functions and mocking the interactions. And what's the harm in getting this information from an automated tool? With your 20 years industry knowledge you should know that you cannot rely on humans to think and act reliably. It's just not a good way to plan systems. *Especially* when it comes to asking someone how correct their system is. I would challenge you to put ego/emotion to one side, stop finding non-existent points to argue against and re-read my post. By all means come back and justify why all the points I raised which reduce the need for coverage are invalid. Don't attribute stupid statements (like 'FP doesn't need testing') to me - I can come up with my own stupid statements thank you. You hand waved the need to use tools such as coverage reports simply on the virtue of some hard to quantify statements. I find that unscientific. If it helps, my stand point is from 20 years of building non-trivial Enterprise applications (primarily Java)
Re: Coverage tools in Clojure
I said that coverage tools answer a specific question; 'how much of my code is executed when I do this', where 'this' is typically running a set of tests. People use that answer to infer how 'safe' their system is because they equate test coverage and safety (which is often a flawed inference). In some environments there is so much incidental complexity that these metrics are hard to calculate by hand (mutating state, deep object hierarchies etc.). FP has a number of different design decisions which can significantly reduce that incidental complexity, so if a tool is still needed maybe the cause is somewhere else - too much coupling/not enough ignorance etc. I think we fundamentally come from different places as I do think you can trust people and I would choose a couple of decent engineers (although they are as rare as hen's teeth) without any tools over all the tools in the world. To be clear, I am not saying I don't see the need for code coverage, I am saying it should be much easier to keep track of code coverage in an FP system done well primarily due to the wonderfully low level of influence referential transparency gives you (for example). On the other hand I absolutely see the need for an automated tool in other environments because of the implicit complexity. If you thoroughly test all your code when you write it why do you need a tool to tell you you missed something? Again, note I am talking only about calculating test coverage and not about testing or how much there should be. Not sure how many ways I can say the same thing, but let's try one more; I never said it was Clojure automatically doing anything, I said it is possible for a good engineer to know the coverage and safety of their systems themselves in a well designed and implemented system. Some environments are full of complexity which make it heard, hence the need for a tool. I am not categorically saying I can't imagine a world where I would need said tool in a FP system, but my first question would be am I using a tool to solve a symptom of poor design. In terms of analysing a new system? When I was a consultant reviewing other's work the best tool I used was a whiteboard, a pen and their architect. I found that if their system *needed* a coverage tool the tests were probably so poorly written as to add very little value. I would genuinely like you/others to prove/disprove these points as this is an area I am still thinking/learning about (as evidenced by my first and last sentence in the original post) and would love to have a useful discussion. You haven't bought anything to the table other than little jibes and emotive statements unfortunately. Let's agree to disagree, and if you can resist having a dig on a public forum (feel free to continue over personal email) let's draw this to a close. On Tuesday, 4 February 2014 14:30:29 UTC, Aaron France wrote: I took issue with you maintaining that Clojure automatically somehow gives you insight into the coverage of your tests. Which it does not. You still maintain this. On Tue, Feb 04, 2014 at 06:28:51AM -0800, Colin Yates wrote: I have no idea why you aren't gushing. I'm not gushing, and haven't gushed about anything technical for years because everything is a trade off and has its own compromises/ceremony. I can see (and highly value) the benefits of Clojure, sure. If you want to write of my point of view as 'gushing' and not bother to read it correctly then fine. However, what is your objective in posting your statement to a public forum if not to start an argument? If you insist on sending more flame bait/trying to get a rise then let's take this offline and keep this list low noise. My email address is colin full stop yates @ Google's mailing servers.com. On Tuesday, 4 February 2014 14:17:25 UTC, Aaron France wrote: I don't come from 'Java-land'. I'm primarily an Erlang developer, which already is a very similar language to Clojure. Perhaps this is why I'm not gushing about functional programming's panacea? Aaron On Tue, Feb 04, 2014 at 06:12:18AM -0800, Colin Yates wrote: This has turned into an unconstructive argument and for whatever reason we don't seem to be communicating clearly. Shame as I (and probably most people on here) only want to help. You seem to be reacting quite strongly to my thoughts - not sure why. If I may, I will just make/rephrase two points: - I think you would find value in watching Rick Hickey's videos on Simple Made Easy and also the one where he talks about Hammock Driven Development. - when I started using Clojure I immediately looked for equivalents of all the supporting infrastructure I used in good old Java land. I have no idea of your situation, but if you are there you have a wonderful opportunity to
Re: lispy.el - a vi-like Paredit. Some Clojure features added.
OK, I've added a second screencast as both video and gif: https://raw.github.com/abo-abo/lispy/master/doc/screencast-2.ogv https://raw.github.com/abo-abo/lispy/master/doc/screencast-2.gif Oleh On Tuesday, February 4, 2014 7:41:15 AM UTC+1, Benjamin Peter wrote: Thanks but it is playing way too fast considering you have to monitor two windows. (buffer and keys). -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: lispy.el - a vi-like Paredit. Some Clojure features added.
This looks excellent! Desperately trying to suppress the whole emacs/vi battle raging inside which has is now rising up again :). On Sunday, 2 February 2014 13:44:12 UTC, Oleh wrote: Hi all, I've recently added some Clojure support to https://github.com/abo-abo/lispy. A short description of the package is that it's all the Paredit functions (and more) bound to unprefixed keys, e.g. a, c, 1, 2 etc. Nothing to do with evil package. Keys call commands instead of self-inserting when the point is in positions called special (marked here with |): |(defn sqr |[x]| |(* x x)|)| This comes together nicely since you rarely want to self-insert in those positions. Just to show how succinct the usage can be, you can transform from this: |(defn sqr [x] (* x x)) with just 4c to this: |(defn sqr [x] (* x x)) (defn sqr [x] (* x x)) (defn sqr [x] (* x x)) (defn sqr [x] (* x x)) (defn sqr [x] (* x x)) and further with 3j to this: (defn sqr [x] (* x x)) (defn sqr [x] (* x x)) (defn sqr [x] (* x x)) |(defn sqr [x] (* x x)) (defn sqr [x] (* x x)) and further with 2; to this: (defn sqr [x] (* x x)) (defn sqr [x] (* x x)) (defn sqr [x] (* x x)) ;; (defn sqr [x] (* x x)) ;; (defn sqr [x] (* x x)) Here's another example that shows how to transform |(map sqr (filter odd? [1 2 3 4 5])) to (- [1 2 3 4 5] (map sqr) (filter odd?))| I show it in a run-able test form (many more tests at github): (should (string= (lispy-with |(map sqr (filter odd? [1 2 3 4 5])) 2(-]]]wwlM) (- [1 2 3 4 5]\n (map sqr)\n (filter odd?))|)) The steps are: 1. 2( - wrap with parens. 2. - - self-insert (because point isn't special). 3. ] - forward list - point becomes special. 4. - barf. 5. ]] - forward, barf, forward. 6. ww - move sexp up twice. 7. l - exit list forwards. 8. M - transform sexp to multi-line. 9. you can e - eval to see if code works. Full description and some screenshots can be found at https://github.com/abo-abo/lispy. Here's a list of Clojure-specific features (cider is used for most): - look up doc inline in an overlay with C-1 - look up function arguments inline with C-2 - eval with e - eval and insert with E - goto symbol in file with g (clojure-semantic required) - goto definition with F The package is available in MELPA if you want to give it a go. Feedback welcome. regards, Oleh -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote: thanks for the report. I only have few doubts about REPL making TDD to shame. In this blog entry - http://blog.jayfields.com/2014/01/repl-driven-development.html - I demonstrate (very briefly, by design) my workflow. I also give my thoughts on TDD. On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo wrote: +1 from Melbourne :) I actually gave the talk in Melbourne, as part of YOW!. It was recorded and will be online at some point. On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote: Is there going to be online access during/after the event? I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :). This talk will not be recorded (afaik), but it's the same as the YOW! version, and that should be online soon. On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote: A question: did you abandon TDD? why? IMO, TDD is a workflow that pushes for simplicity TDD, yes, for the most part. However, I still write a large number of tests. YMMV though, as you may find that TDD gives you better design direction. Assuming that's the case, I'd never try to convince you to do something else. This is an experience report, not a prescription for adopting Clojure. =) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
Jay - in your demo I can't determine whether the (+ 2 2) expression is evaluated and the results pasted inline or whether you have manually pasted them? I see you are using emacs, can you detail how you have configured emacs? On Tuesday, 4 February 2014 16:33:44 UTC, Jay Fields wrote: On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote: thanks for the report. I only have few doubts about REPL making TDD to shame. In this blog entry - http://blog.jayfields.com/2014/01/repl-driven-development.html - I demonstrate (very briefly, by design) my workflow. I also give my thoughts on TDD. On Tuesday, February 4, 2014 7:24:21 AM UTC-5, Rafael Peixoto de Azevedo wrote: +1 from Melbourne :) I actually gave the talk in Melbourne, as part of YOW!. It was recorded and will be online at some point. On Tuesday, February 4, 2014 7:22:06 AM UTC-5, Colin Yates wrote: Is there going to be online access during/after the event? I would greatly value seeing this, but probably not enough to travel from the UK to Chicago :). This talk will not be recorded (afaik), but it's the same as the YOW! version, and that should be online soon. On Tuesday, February 4, 2014 8:02:28 AM UTC-5, ajlopez wrote: A question: did you abandon TDD? why? IMO, TDD is a workflow that pushes for simplicity TDD, yes, for the most part. However, I still write a large number of tests. YMMV though, as you may find that TDD gives you better design direction. Assuming that's the case, I'd never try to convince you to do something else. This is an experience report, not a prescription for adopting Clojure. =) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Feb 4, 2014, at 5:33 PM, Jay Fields j...@jayfields.com wrote: On Tuesday, February 4, 2014 8:17:44 AM UTC-5, Magomimmo wrote: thanks for the report. I only have few doubts about REPL making TDD to shame. In this blog entry - http://blog.jayfields.com/2014/01/repl-driven-development.html - I demonstrate (very briefly, by design) my workflow. I also give my thoughts on TDD. Thanks Jay, in the post you were less tranchant about TDD. As I said I'm not a TDD practitioner, but recently I started to appreciated it by mixing my REPL based workflow, mostly when I'm writing portable CLJ/CLJS code (you can't image how many subtle differences I discovered between CLJ and CLJS in this way. Thanks again mimmo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
Discussions around TDD / RDD (REPL-Driven-Development) probably need a separate thread but... On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza mimmo.cose...@gmail.com wrote: thanks for the report. I only have few doubts about REPL making TDD to shame. I'm a strong advocate of TDD (well, BDD specifically) and I agree with Jay's comment insofar as you write a test expression in the REPL and it evaluates immediately. That's always faster than writing a test and running a test, by definition. That's all I took his comment to mean. The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other. Indeed you can - and Jay does - and so do I. Especially now I'm using LightTable and can evaluate code in place in amongst my production code in one tabset and my expectations in another tabset. I have C-c , bound to evaluate a run-tests expression in my namespace so I can quickly evaluate and execute tests. Even so, live evaluation of test code is still a faster feedback loop. Many of my test expressions become long-lived unit tests (expectations). Or they become production code. I still write expectations to clarify how to design APIs in the small (and APIs in the large as needed), but most of the red-green-refactor loop of TDD/BDD now comes from the REPL experiments for me. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Should predicates always have one argument?
Thank you all for your answers, they helped me a lot :) Cheers On Saturday, February 1, 2014 12:10:42 AM UTC+2, Ivan L wrote: I typically wrap stuff with (partial) for easier reading. In your example you might use something like following. (defn are-valid [maps validator] (let [valid? (partial validator)] (map valid? maps))) On Friday, January 31, 2014 11:44:38 AM UTC-5, Ryan wrote: Hello, I am wondering if all my predicates should be one argument functions because I run into a couple of cases where I needed more than one. For example, I have a function called valid-params? which takes two parameters; the validator to use and a maps parameter. Is this approach wrong/not the clojure way? What are my alternatives? Should I just use a different function name which does not have a question mark at the end that implies that is a predicate? Cheers, Ryan -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Feb 4, 2014, at 6:13 PM, Sean Corfield s...@corfield.org wrote: The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other. Indeed you can - and Jay does - and so do I. And me too. So we are all in the same boat :-). mimmo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why do I get stackoverflow error?
Another option is: ((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) (mapv (partial reduce +) (partition 2 1 (cons 0 (conj row 0 500) Because row is a vector you can conj 0 to the end (quickly) and cons 0 to the front (quickly) and then mapv makes sure you get a vector back. Sean On Feb 4, 2014, at 2:39 AM, Andy Smith the4thamig...@googlemail.com wrote: Ok thanks, thats really helpful. The second link suggests using doall, which seems to do the trick : ((fn pascal ([n] (pascal n [1M])) ([n row] (if (= n 1) row (recur (dec n) (map (partial reduce +) (doall (partition 2 1 (concat [0] row [0] 500) However you do lose the laziness, but here the laziness is not needed ... signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Coverage tools in Clojure
On Tue, Feb 04, 2014 at 07:01:31AM -0800, Colin Yates wrote: I said that coverage tools answer a specific question; 'how much of my code is executed when I do this', where 'this' is typically running a set of tests. People use that answer to infer how 'safe' their system is because they equate test coverage and safety (which is often a flawed inference). I certainly don't connotate high coverage with a safe system. No-one said that. I use coverage to answer two questions: * Which lines of code are being hit during testing? * Which lines of code are not being hit during testing? You'll be surprised at how many times I've discovered dead code, needless checks, error handling etc just simply looking at what code was used when. A functional programming language allows you to write code which isn't used. In some environments there is so much incidental complexity that these metrics are hard to calculate by hand (mutating state, deep object hierarchies etc.). FP has a number of different design decisions which can significantly reduce that incidental complexity, so if a tool is still needed maybe the cause is somewhere else - too much coupling/not enough ignorance etc. I think we fundamentally come from different places as I do think you can trust people and I would choose a couple of decent engineers (although they are as rare as hen's teeth) without any tools over all the tools in the world. You present a false dichotomy here. You can have both. Good engineers aren't afraid to use tools where they make sense. To be clear, I am not saying I don't see the need for code coverage, I am saying it should be much easier to keep track of code coverage in an FP system done well primarily due to the wonderfully low level of influence referential transparency gives you (for example). On the other hand I absolutely see the need for an automated tool in other environments because of the implicit complexity. You used the words should be, therefore I will assume you haven't conducted any scientific studies to show these facts. May we ignore this point? These kinds of things are hard to quantify. If you thoroughly test all your code when you write it why do you need a tool to tell you you missed something? This is just so brain-dead stupid. How do you *know* that you thoroughly tested your code? Where do you get these metrics? There are various methods you need to employ before you can even beging to feel comfortable about saying you have 'thoroughly' tested code. Coverage is one method amongst many. Again, note I am talking only about calculating test coverage and not about testing or how much there should be. Not sure how many ways I can say the same thing, but let's try one more; I never said it was Clojure automatically doing anything, I said it is possible for a good engineer to know the coverage and safety of their systems themselves in a well designed and implemented system. Some environments are full of complexity which make it heard, hence the need for a tool. I am not categorically saying I can't imagine a world where I would need said tool in a FP system, but my first question would be am I using a tool to solve a symptom of poor design. You ask me to disprove things like this? Are you kidding? This is just hand-wavey and pulled out of the air. To say a good engineer can calculate complexity themselves is just asking for trouble. The less you rely on human behaviour the closer you get to doing science. In terms of analysing a new system? When I was a consultant reviewing other's work the best tool I used was a whiteboard, a pen and their architect. And what happens to this data? Did you store it? Did you write it down? Could you pass that data onto other people easily? It seems that institutional knowledge such as this is a bigger cause for concern than simply using coverage tools. I found that if their system *needed* a coverage tool the tests were probably so poorly written as to add very little value. At this point I'm beginning to suspect you've never really used a coverage tool properly. Coverage is used in conjunction with other methods to gain knowledge about your system, if you rely on coverage alone (and don't act on the results so long that you *continually* need it) then you have bigger problems than poor tests. I would genuinely like you/others to prove/disprove these points as this is an area I am still thinking/learning about (as evidenced by my first and last sentence in the original post) and would love to have a useful discussion. You haven't bought anything to the table other than little jibes and emotive statements unfortunately. Let's agree to disagree, and if you can resist having a dig on a public forum (feel free to continue over personal email) let's draw this to a close. On Tuesday, 4 February 2014 14:30:29 UTC, Aaron France wrote: I took issue with you
Live coding with Clojure and Emacs
A blog post meant to demonstrate the symbiosis between powerful interactive programming environments such as Clojure and Emacs. http://danielsz.github.io/2014/01/20/Live-coding-with-Clojure-and-Emacs/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
jvm.tools.analyzer 0.6.1
Hi, jvm.tools.analyzer 0.6.1 now supports ClojureScript 0.0-2138. [org.clojure/jvm.tools.analyzer 0.6.1] README https://github.com/clojure/jvm.tools.analyzer/blob/master/README.md CHANGELOGhttps://github.com/clojure/jvm.tools.analyzer/blob/master/CHANGELOG.md Thanks, Ambrose -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
Without starting a flame war - how are you finding LightTable for production? Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it... That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of the box immediately and just the way I like it :) On Tuesday, 4 February 2014 17:13:04 UTC, Sean Corfield wrote: Discussions around TDD / RDD (REPL-Driven-Development) probably need a separate thread but... On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza mimmo@gmail.comjavascript: wrote: thanks for the report. I only have few doubts about REPL making TDD to shame. I'm a strong advocate of TDD (well, BDD specifically) and I agree with Jay's comment insofar as you write a test expression in the REPL and it evaluates immediately. That's always faster than writing a test and running a test, by definition. That's all I took his comment to mean. The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other. Indeed you can - and Jay does - and so do I. Especially now I'm using LightTable and can evaluate code in place in amongst my production code in one tabset and my expectations in another tabset. I have C-c , bound to evaluate a run-tests expression in my namespace so I can quickly evaluate and execute tests. Even so, live evaluation of test code is still a faster feedback loop. Many of my test expressions become long-lived unit tests (expectations). Or they become production code. I still write expectations to clarify how to design APIs in the small (and APIs in the large as needed), but most of the red-green-refactor loop of TDD/BDD now comes from the REPL experiments for me. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
Colin Yates colin.ya...@gmail.com writes: AFAIK LightTable has paredit or sth. similar. Also, a great deal of customisation is available via ClojureScript. I am personally favouring Emacs as I am a polyglot programmer and do not only use Emacs as an editor, but the programming and computing environment: This post is sent via Emacs (Gnus), I write my blog posts with it, run shells, use git (magit) and even view photos and PDFs. If all you look is an editor/IDE-ish though, Emacs and LightTable are quite the same thing indeed, except for the fact that Emacs has better community and more packages. Without starting a flame war - how are you finding LightTable for production? Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it... That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of ethe box immediately and just the way I like it :) On Tuesday, 4 February 2014 17:13:04 UTC, Sean Corfield wrote: Discussions around TDD / RDD (REPL-Driven-Development) probably need a separate thread but... On Feb 4, 2014, at 5:17 AM, Mimmo Cosenza mimmo@gmail.comjavascript: wrote: thanks for the report. I only have few doubts about REPL making TDD to shame. I'm a strong advocate of TDD (well, BDD specifically) and I agree with Jay's comment insofar as you write a test expression in the REPL and it evaluates immediately. That's always faster than writing a test and running a test, by definition. That's all I took his comment to mean. The REPL is great, that's for sure, but IMHO it does not relegate TDD feedback/loop in a niche, because you can complement one with the other. Indeed you can - and Jay does - and so do I. Especially now I'm using LightTable and can evaluate code in place in amongst my production code in one tabset and my expectations in another tabset. I have C-c , bound to evaluate a run-tests expression in my namespace so I can quickly evaluate and execute tests. Even so, live evaluation of test code is still a faster feedback loop. Many of my test expressions become long-lived unit tests (expectations). Or they become production code. I still write expectations to clarify how to design APIs in the small (and APIs in the large as needed), but most of the red-green-refactor loop of TDD/BDD now comes from the REPL experiments for me. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- — gk -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Why does Clojure at times use Java classes as their base type?
On Sunday, February 2, 2014 3:07:27 PM UTC-8, Aaron France wrote: What's the benefit of hiding/abstracting the underlying platform away? The obvious answer to this is it limits exposure to the complexity of the underlying platform, and provides a stable platform. That's usually why people abstract platforms. The trade-off of embracing the platform is that the complexity of using clojure is not just the complexity of clojure. It is the complexity of the jvm plus the complexity of java plus the complexity of clojure plus the complexity of the interface between clojure and java, which is intricate. Thus, you need to know that in java 6 you have to make defensive copies of substrings, but on java 7 you don't; that on some jvm you will have abstract path manipulation, on others you won't; that (map #(+ 1 %) (float-array [1 2 3])) will run but (map #(+ 1 %) (byte-array [1 2 3])) will throw an error, and so-on, in unending detail. Probably the size of this looks different if you've already internalized the complexity of the platform from previous experience. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
how does source work?
Hi, user (source source) (defmacro source Prints the source code for the given symbol, if it can find it. This requires that the symbol resolve to a Var defined in a namespace for which the .clj is in the classpath. Example: (source filter) [n] `(println (or (source-fn '~n) (str Source not found nil user (source source-fn) Source not found nil Is there a way, from pure-clojure that I can implement my-def + my-source (without using def+source) which behaves as def+source does ... or does doing so require writing Java code? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
How to transform one data structure to another data structure?
Hi all,
I was wondering how I can convert the following data structure to the one
below:
from:
[[:a 123]
[:b 124]
[:a 125]
[:c 126]
[:b 127]
[:a 100]]
to
{:a [123 125 100] :b [124 127] :c [126]}
All the names here are arbitrary, but there are potentially a lot more keys
and certainly a lot more numbers. The order of things is not important.
TIA,
Thomas
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: how does source work?
source-fn is a private Var in the clojure.repl namespace; you can still use source to display its definition, but you'll have to use the fully qualified name: user= (source clojure.repl/source-fn) (defn source-fn Returns a string of the source code for the given symbol, if it can find it. This requires that the symbol resolve to a Var defined in a namespace for which the .clj is in the classpath. Returns nil if it can't find the source. For most REPL usage, 'source' is more convenient. Example: (source-fn 'filter) [x] (when-let [v (resolve x)] (when-let [filepath (:file (meta v))] (when-let [strm (.getResourceAsStream (RT/baseLoader) filepath)] (with-open [rdr (LineNumberReader. (InputStreamReader. strm))] (dotimes [_ (dec (:line (meta v)))] (.readLine rdr)) (let [text (StringBuilder.) pbr (proxy [PushbackReader] [rdr] (read [] (let [i (proxy-super read)] (.append text (char i)) i)))] (read (PushbackReader. pbr)) (str text))) Cheers, Michał On 4 February 2014 21:34, t x txrev...@gmail.com wrote: Hi, user (source source) (defmacro source Prints the source code for the given symbol, if it can find it. This requires that the symbol resolve to a Var defined in a namespace for which the .clj is in the classpath. Example: (source filter) [n] `(println (or (source-fn '~n) (str Source not found nil user (source source-fn) Source not found nil Is there a way, from pure-clojure that I can implement my-def + my-source (without using def+source) which behaves as def+source does ... or does doing so require writing Java code? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to transform one data structure to another data structure?
One way:
user (reduce (fn [s [k v]]
(merge-with concat s {k [v]}))
{} [[:a 123]
[:b 124]
[:a 125]
[:c 126]
[:b 127]
[:a 100]])
= {:c [126], :b (124 127), :a (123 125 100)}
On Tue, Feb 4, 2014 at 1:06 PM, Thomas th.vanderv...@gmail.com wrote:
Hi all,
I was wondering how I can convert the following data structure to the one
below:
from:
[[:a 123]
[:b 124]
[:a 125]
[:c 126]
[:b 127]
[:a 100]]
to
{:a [123 125 100] :b [124 127] :c [126]}
All the names here are arbitrary, but there are potentially a lot more
keys and certainly a lot more numbers. The order of things is not important.
TIA,
Thomas
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an
email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: How to transform one data structure to another data structure?
You can start here http://clojuredocs.org/clojure_core/clojure.core/group-by
it should be pretty easy to get it working from there.
On Tuesday, February 4, 2014 4:06:14 PM UTC-5, Thomas wrote:
Hi all,
I was wondering how I can convert the following data structure to the one
below:
from:
[[:a 123]
[:b 124]
[:a 125]
[:c 126]
[:b 127]
[:a 100]]
to
{:a [123 125 100] :b [124 127] :c [126]}
All the names here are arbitrary, but there are potentially a lot more
keys and certainly a lot more numbers. The order of things is not important.
TIA,
Thomas
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
LightTable (for the Emacs guy) was: Lessons Learned from Adopting Clojure
On Feb 4, 2014, at 10:21 AM, Colin Yates colin.ya...@gmail.com wrote: Without starting a flame war - how are you finding LightTable for production? Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it... That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of the box immediately and just the way I like it :) Like Emacs, it has its quirks(!) and it takes some adjustment after two years of using Emacs daily (and several years using Emacs twenty years back!). I use the Emacs plugin, the Emacs mode (from the underlying CodeMirror editor), and the Paredit plugin. Plus some custom key mappings. It's not perfect but I'm getting used to the differences. Being able to customize it via Clojure (technically ClojureScript data structures) is a plus and a minus and whilst I've written one plugin, I based it heavily on someone else's so I haven't yet learned much about the LT internals... but the customization capabilities are VERY impressive. At the moment, the biggest lack for me is something like magit but some folks are working on Git plugins so think that's just a short-term lack. I really like LT's eval-in-place approach now I've gotten used to it - it's like having a REPL that's a 2D sketchpad rather than a linear sequence of evaluation commands. I like that I can just try a bit of code out in the middle of my existing function definitions without having to switch to a REPL, so I'm finding I'm growing code directly inside my namespaces and then just wrapping each piece in defn and naming it once it does what I want, all on one canvas. I really like having a full-featured browser in my editor (that works cross-platform) and can act as a live evaluation target for .cljs and .js files (and .css and .html and so on). I still keep Emacs open as my Git client and as my IRC client, but I don't edit anything with it. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: LightTable (for the Emacs guy) was: Lessons Learned from Adopting Clojure
On Tue, Feb 4, 2014 at 5:20 PM, Sean Corfield s...@corfield.org wrote: On Feb 4, 2014, at 10:21 AM, Colin Yates colin.ya...@gmail.com wrote: Without starting a flame war - how are you finding LightTable for production? Moving away from emacs and paredit would be quite hard and every time I look at LightTable I get really excited until I actually download and try it... That is almost certainly because I don't have the time to invest in learning it and I expect it to do everything out of the box immediately and just the way I like it :) Like Emacs, it has its quirks(!) and it takes some adjustment after two years of using Emacs daily (and several years using Emacs twenty years back!). I'll provide a counterpoint to that. Let me preface by saying I do not hate Light Table. I supported the kickstarter, and I continue to follow the development as one of the best hopes for future Clojure development. I am now using Light Table for Clojurescript development on our not-small-but-not-massive Clojure/Clojurescript UI at Threatgrid. I find the live browser REPL interaction to be invaluable and finally makes me willing to invest more into the Clojurescript UI. Up until now I've found the Clojurescript REPL support to be lacking. Austin is promising, but I've still yet to find anyone who can demonstrate it functioning correctly in a non-demo environment. Light Table works for this, and it works quite well. That being said, Light Table is barely usable as text editor and is a really terrible editor for Clojure in specific. I hope (and believe) this will improve over time. The token paredit barf/slurp shows some attention to details, and work is ongoing for an extended paredit mode. But, I find that I spend a troubling large portion of my time in Light Table wrangling parenthesis and fighting the editor compared to the time I spend actually writing code. The exact opposite is true in emacs. I spend almost no mental effort on the syntax/structure. When I want to move an expression around or make a structural change, I can effect that change almost trivially with no distraction from the coding task at hand. Obvious, there's a lot of practice and experience goes into that, but it's only because emacs has those capabilities in the first place. While every developer is different, I have a hard time imaging any emacs/paredit user would find editing in Light Table a pleasurable experience, so far as the act of writing the code is concerned. There are many, many reasons to like Light Table and to use Light Table for now, but for day to day Clojure development, it's not even close to being ready for serious use. (only my opinion) Still, everyone should give it a try, if you approach it from the perspective of being a tool that might be able to provide some unique value in certain situations, I don't think you'll be disappointed. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] hiccup-watch
*hiccup-watch https://github.com/twashing/hiccup-watch* is just a leiningen watcher plugin that monitors for changes in your Hiccup source files. While building some web apps, I found that I like to treat my *hiccup.edn*forms as separate files. So this is akin to something like guard-haml https://github.com/guard/guard-haml (or guard-sasshttps://github.com/hawx/guard-sass). Ie, I like to serve up just raw HTML files and templates. So I needed a tool like this. And hiccup-watch fits nicely, into my workflow. This is still a new project, so feel free modify, make pull requests, etc. - [hiccup-watch 0.1.1] - Github https://github.com/twashing/hiccup-watch - Clojars https://clojars.org/hiccup-watch Tim Washington Interruptsoftware.com http://interruptsoftware.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: GSoC 2014: org applications now open
Thanks, Alex and Ambrose, I really appreciate the help. On Tue Feb 4 05:41 2014, Alex Miller wrote: Daniel, I'd be happy to help as an administrator, particularly if you can provide some guidance from previous years. I can also help re getting students to conferences. This would be a big help. To get started as an admin, the first step is to go to Melage https://www.google-melange.com and sign in with a Google account. Once you've done that, you'll need to create a profile. I need the username of at least one other person so that I can open our application. I'll be making edits to the community wiki soon, and as soon as its ready, I'll post a message to the mailing lists letting people know it's time to populate the project ideas page and review our answers for the org application. Thanks again. Sincerely, Daniel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: how does source work?
Issue resolved. Thanks! On Tue, Feb 4, 2014 at 1:09 PM, Michał Marczyk michal.marc...@gmail.com wrote: source-fn is a private Var in the clojure.repl namespace; you can still use source to display its definition, but you'll have to use the fully qualified name: user= (source clojure.repl/source-fn) (defn source-fn Returns a string of the source code for the given symbol, if it can find it. This requires that the symbol resolve to a Var defined in a namespace for which the .clj is in the classpath. Returns nil if it can't find the source. For most REPL usage, 'source' is more convenient. Example: (source-fn 'filter) [x] (when-let [v (resolve x)] (when-let [filepath (:file (meta v))] (when-let [strm (.getResourceAsStream (RT/baseLoader) filepath)] (with-open [rdr (LineNumberReader. (InputStreamReader. strm))] (dotimes [_ (dec (:line (meta v)))] (.readLine rdr)) (let [text (StringBuilder.) pbr (proxy [PushbackReader] [rdr] (read [] (let [i (proxy-super read)] (.append text (char i)) i)))] (read (PushbackReader. pbr)) (str text))) Cheers, Michał On 4 February 2014 21:34, t x txrev...@gmail.com wrote: Hi, user (source source) (defmacro source Prints the source code for the given symbol, if it can find it. This requires that the symbol resolve to a Var defined in a namespace for which the .clj is in the classpath. Example: (source filter) [n] `(println (or (source-fn '~n) (str Source not found nil user (source source-fn) Source not found nil Is there a way, from pure-clojure that I can implement my-def + my-source (without using def+source) which behaves as def+source does ... or does doing so require writing Java code? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
On Feb 4, 2014, at 11:20 AM, Aaron France aaron.l.fra...@gmail.com wrote: If you thoroughly test all your code when you write it why do you need a tool to tell you you missed something? This is just so brain-dead stupid. How do you *know* that you thoroughly tested your code? Where do you get these metrics? There are various methods you need to employ before you can even beging to feel comfortable about saying you have 'thoroughly' tested code. Coverage is one method amongst many. If you practice test-driven design in its strict form, it's relatively easy to show that you'll get 100% multicondition coverage (which is a bit stronger than branch coverage). In practice, you don't really achieve that because (1) humans err, and (2) it's fairly easy to degrade the coverage of a test suite as you evolve the system. Nevertheless, reasonably disciplined testing gets high enough coverage that I consider missing coverage a third-order problem. The first order problem is faults of omission, which coverage doesn't speak to at all. (http://www.exampler.com/testing-com/writings/omissions.html) In my own coding practice, it's not common that I later find a bug that a coverage tool would have forced me to find. I wouldn't mind having a Clojure code coverage tool, but not having one isn't much of a problem. At this point I'm beginning to suspect you've never really used a coverage tool properly. I don't know about Colin, but I've written or supervised the writing of four coverage tools (3 for C, 1 for Java). That in itself doesn't show that I've used them properly, but a number of people have appreciated my writings on coverage. Such as: http://www.exampler.com/testing-com/writings/coverage.pdf http://www.exampler.com/testing-com/writings/experience.pdf Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[ANN] garden-watch
*garden-watch* https://github.com/twashing/garden-watch is very similar to hiccup-watch https://github.com/twashing/hiccup-watch (previous annhttps://groups.google.com/forum/#!topic/clojure/7nglz0yz-9Q). But this time, we're compiling down to CSS, using the Gardenhttps://github.com/noprompt/gardenlibrary. Again, this is just a leiningen watcher plugin that monitors for changes in your Garden source files. And again, this is new software. So feel free to use, modify and make suggestions and / or pull requests. Treat this tool the same way you would treat guard-sass https://github.com/hawx/guard-sass. I like to serve up just raw HTML files and templates. So both these tools fit nicely into my toolbox. - [garden-watch 0.1.1] - Github https://github.com/twashing/garden-watch - Clojars https://clojars.org/garden-watch Tim Washington Interruptsoftware.com http://interruptsoftware.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Feb 4, 2014, at 6:06 AM, Jay Fields j...@jayfields.com wrote: - REPL driven development, putting TDD's 'rapid feedback' to shame. Pity I'll miss this, but I only come up to Chicago W-F. What I've found is that having autotest in the REPL dissolves most conflict between TDD and REPL-driven development. Or to put it differently: having a REPL autotest makes writing a test less hassle than working in the repl - maybe 80% of the time. In the other 20%, the REPL is invaluable, though I always grate at the need to then immortalize the core of what I did in the REPL in repeatable tests. (Actually, making clear distinctions like 80% doing this vs 20% doing that feels like a poor reflection of my lived experience. I spend my time with four emacs windows open: a repl, the source, the tests of the source, and the miscellaneous window. I move very fluidly between them. Whatever source-of-immediate-gratification works best in the moment is always ready-to-hand.) Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Code re-use in Speclj
context might be what you're looking for. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Code re-use in Speclj
You can also use let instead of with. If you have multiple tests inside let wrap them in a context call. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
ANN: [lein-describe 0.1.0] plugin for displaying detailed information about Clojure projects
Looks cool. I'll be sure to check it out. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Coverage tools in Clojure
This is a very specific coverage tool which I think lots of Clojure libraries could benefit from. https://github.com/ztellman/collection-check -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Lessons Learned from Adopting Clojure
On Tue, Feb 4, 2014 at 6:07 PM, Brian Marick mar...@exampler.com wrote: I always grate at the need to then immortalize the core of what I did in the REPL in repeatable tests. That's actually one of the things that bothered me in the Emacs REPL world: working in the REPL was separate from working in my production source and my test source. It's one of the things that has me really hooked on LightTable. I have my source and test namespaces both open. I have them both connected to a REPL. I can evaluate any code, in place, in either file. If I grow some code in the source file, I can put (defn some-name [args]) in front of it and M-) slurps it into a function - done! If I grow some code in the test file, I can put (expect result-value) in front of it and M-) slurps it into a test - done! Since I moved to LightTable, I've found myself doing even more REPL-Driven-Development than before because it's so much easier to turn the experiments into code - or tests - in place. -- 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 --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] garden-watch
FYI, I think lein garden does this already. is there a particular difference? On Wednesday, 5 February 2014 13:03:55 UTC+11, frye wrote: *garden-watch* https://github.com/twashing/garden-watch is very similar to hiccup-watch https://github.com/twashing/hiccup-watch (previous annhttps://groups.google.com/forum/#!topic/clojure/7nglz0yz-9Q). But this time, we're compiling down to CSS, using the Gardenhttps://github.com/noprompt/gardenlibrary. Again, this is just a leiningen watcher plugin that monitors for changes in your Garden source files. And again, this is new software. So feel free to use, modify and make suggestions and / or pull requests. Treat this tool the same way you would treat guard-sass https://github.com/hawx/guard-sass. I like to serve up just raw HTML files and templates. So both these tools fit nicely into my toolbox. - [garden-watch 0.1.1] - Github https://github.com/twashing/garden-watch - Clojars https://clojars.org/garden-watch Tim Washington Interruptsoftware.com http://interruptsoftware.com/ -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
