Re: Clojure Users Group - Denmark
On Thursday, November 14, 2013 11:40:08 PM UTC+1, Jacob Mortensen wrote: I do clojure+clojurescript hobby programming at home. I live in copenhagen. It seems there is a clojure user group here in copenhagen, but I havent been able to locate it. We've started to write some of the concurrent infrastructure in Xamarin Test Cloud in Clojure. I know YouSee is using Clojure in at least one project. - Karl -- -- 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: custom templates shadow _admin templates
Hi all,
I'm just toying around with Caribou. I successfully created the models
of my toy app, and now I started defining routes, pages, and templates.
I started with this:
--8---cut here---start-8---
(def routes
[[/:home
[[login :login [])
(def pages
{:home {:GET {:controller 'home :action 'home :template home.html}}
:login {:GET {:controller 'login :action 'login :template login.html}}})
--8---cut here---end---8---
And wow, indeed http://localhost:3/login now shows the page
generated by filling out the login.html template like my login action
said.
However, that has also broken the Admin login page. Visiting
http://localhost:3/_admin/login now also shows my custom login page,
but the template variables aren't filled out (because that's rendered by
the admin controller, not my controller).
So it seems that template names have to be unique and in order not to
interfere with Admin templates. Is that intended? I guess no...
For the time being, I'll prefix my custom templates with the project
name in order to have them unique.
Bye,
Tassilo
--
--
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: custom templates shadow _admin templates
The your own resources subdirectory is merged over the admin one, the
structure visible here: caribou admin
templateshttps://github.com/caribou/caribou-admin/tree/master/resources/templates
And yes, anything which has the same directory structure in your project is
merged over the admin templates (this is useful for per-project
customization, in my experience).
The javascript and css are stashed under resources/public/_admin/, and it
would probably be a good idea to move all the admin templates under a
unique subdirectory as well, but it is a more complex change. I am
seriously considering creating a templates/_admin/ and bumping all admin
templates under that path.
On Friday, November 15, 2013 5:50:28 AM UTC-8, Tassilo Horn wrote:
Hi all,
I'm just toying around with Caribou. I successfully created the models
of my toy app, and now I started defining routes, pages, and templates.
I started with this:
--8---cut here---start-8---
(def routes
[[/:home
[[login :login [])
(def pages
{:home {:GET {:controller 'home :action 'home :template home.html}}
:login {:GET {:controller 'login :action 'login :template
login.html}}})
--8---cut here---end---8---
And wow, indeed http://localhost:3/login now shows the page
generated by filling out the login.html template like my login action
said.
However, that has also broken the Admin login page. Visiting
http://localhost:3/_admin/login now also shows my custom login page,
but the template variables aren't filled out (because that's rendered by
the admin controller, not my controller).
So it seems that template names have to be unique and in order not to
interfere with Admin templates. Is that intended? I guess no...
For the time being, I'll prefix my custom templates with the project
name in order to have them unique.
Bye,
Tassilo
--
--
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: custom templates shadow _admin templates
Update: I have created a namespaced-templates branch of caribou-admin, and
the fix actually looks like it will be a shallow change (if moderately
tedious given our lack of relative partial paths in templates which gives
me another idea...).
On Friday, November 15, 2013 6:36:30 AM UTC-8, Justin Smith wrote:
The your own resources subdirectory is merged over the admin one, the
structure visible here: caribou admin
templateshttps://github.com/caribou/caribou-admin/tree/master/resources/templates
And yes, anything which has the same directory structure in your project
is merged over the admin templates (this is useful for per-project
customization, in my experience).
The javascript and css are stashed under resources/public/_admin/, and it
would probably be a good idea to move all the admin templates under a
unique subdirectory as well, but it is a more complex change. I am
seriously considering creating a templates/_admin/ and bumping all admin
templates under that path.
On Friday, November 15, 2013 5:50:28 AM UTC-8, Tassilo Horn wrote:
Hi all,
I'm just toying around with Caribou. I successfully created the models
of my toy app, and now I started defining routes, pages, and templates.
I started with this:
--8---cut here---start-8---
(def routes
[[/:home
[[login :login [])
(def pages
{:home {:GET {:controller 'home :action 'home :template
home.html}}
:login {:GET {:controller 'login :action 'login :template
login.html}}})
--8---cut here---end---8---
And wow, indeed http://localhost:3/login now shows the page
generated by filling out the login.html template like my login action
said.
However, that has also broken the Admin login page. Visiting
http://localhost:3/_admin/login now also shows my custom login page,
but the template variables aren't filled out (because that's rendered by
the admin controller, not my controller).
So it seems that template names have to be unique and in order not to
interfere with Admin templates. Is that intended? I guess no...
For the time being, I'll prefix my custom templates with the project
name in order to have them unique.
Bye,
Tassilo
--
--
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: Do web apps need Clojure?
Me too! Thanks to everyone who’s contributed, it’s been *very* helpful! On Nov 14, 2013, at 10:43 AM, Waldemar Schwan waldemar.sch...@googlemail.com wrote: I just want to say that this is one of the most interesting discussions I followed on this mailing list. Thanks to all participants. Am 14.11.2013 um 19:24 schrieb Brian Craft craft.br...@gmail.com: On Thursday, November 14, 2013 9:42:52 AM UTC-8, Jonathan Irving wrote: I agree with much of what you write James - I'm paid to write rails and node.js code, and I'm finding that node is encouraging me to compose small components and basically sidestep a lot of the issues that rails is designed to address. Can you give a concrete example? -- -- 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. marcus blankenship \\\ Partner, Problem Solver, Linear Thinker \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo -- -- 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: Do web apps need Clojure?
Thanks Sean, wonderful input! On Nov 14, 2013, at 2:28 AM, Sean Johnson belu...@acm.org wrote: I'm a Rails guy who now uses Clojure for all new web development, so don't take what I'm about to say as disagreeing with Justin. As someone with a foot firmly in both worlds, a couple of Justin's points aren't really marks in Clojure's favor, at least compared to Ruby/Rails (I can't say as much about Python/Django). I also have a few other benefits to bring up that Justin didn't: Clojure provides execution efficiency that Ruby or Python cannot match. This translates to lowered hosting costs. Agreed. This is a huge point. And not just in lowered hosting costs, but also potentially a better user experience (lower latency). The lein tool provides very clean and isolated dependency management, that makes setting up dev environments and deployment very straightforward. The pair of Bundler/rake does this very effectively for Ruby. Targeting the JVM means that each deploy can be a single jar or war file that you upload to the server. True. Clojure offers potentially much simpler deployment schemes, but if this is important to you, there's JRuby. The ring middleware system is a very clean way of including functionality in an app. Rack is every bit as clean in the Ruby world. Working with immutable data structures and threadsafe bindings as a pervasive default does a lot for stability, and rules out many of the round about ways one of heisenbugs end up in the system. True, but this comes up less frequently than you might expect with the typical web app. With the stateless nature of HTTP, and the MVC (of a sort) convention of Rail/Django, typical web app code in these frameworks ends up being more short lived, imperative, and object based in nature rather than long running, object-oriented, and stateful. Here are several additional points to consider: Conciseness. Terseness. Or to put a more positive spin on it, expressiveness. Idiomatic Clojure is more concise than idiomatic Ruby or Python. I find that having 2x or less code to implement the same functionality to be very refreshing and empowering. Big Rails/Django apps suffer entropy much faster than comparable Clojure apps. Full-stack with ClojureScript. The ability to code all in one language, and to share code between client and server, is quite nice compared to Ruby/JavaScript, Ruby/CoffeeScript. It's one small reason node.js has gained momentum so quickly. Neither Rails nor Django has a robust, mature threading story. Both achieve concurrency primarily through many processes. This can eat through memory on your hosts quickly as the footprint for Rails and Django themselves is not small and is replicated in each process. This comes up as you end up serving web requests to multiple processes to concurrently, and end up with a many processes model for working background requests. This has gotten a bit better in the Ruby/Rails world as Rails is now thread safe and so can be run multithreaded in alternative Ruby implementations (other than MRI), and Sidekiq has come on the scene for background work, and it leverages Celluloid's actor implementation, borrowed from Erlang, to provide multi-threaded Rails workers. Django has celery but I think that's still process based like resque is in the Ruby world. Not positive, but I don't think Django is threadsafe though. Framework vs. ecosystem of interoperable libraries. The monolithic framework (see Rails and Django) is not the way web development is done in Clojure. Instead imagine the Clojure world as a set of legos. You get to build whatever you want with your legos, selecting just the blocks you need, in the colors and sizes you want, and they all snap together [1]. The benefit to this approach is simplicity. There is a LOT to know about the Rails and Django frameworks, as they are big, mature things that have grown to solve all the common web development needs, and you start your development with ALL of that framework. Your starting point with Clojure on the other hand is much simpler. It will seem too simple... at first you'll be wondering... where is all the stuff? You start with maybe just ring and compojure (web middleware and routing) and a few lines of your code and your first couple of stories are already complete. You add libraries as you find you need them as you build out your app over time, but at all times your app is as simple as it can be, and only has the stuff it needs. It's therefore much easier to understand and less a big ball of mud. The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no magic (Python). This probably comes down to personal preference, and so is a potential benefit of any of them, depending on your preference, but it's a significant difference, so it's worth pointing out. By magic I just mean when the
Re: How could you solve this problem
Round Robin: In case you are new to Clojure, I have written extended commentary of my implementation here: http://programmers.stackexchange.com/questions/194487/ring-of-numbers-where-adjacent-entries-sum-up-to-a-prime/218470#218470, were somebody else asked about the problem in April. On Tuesday, November 12, 2013 11:39:18 PM UTC+1, Round Robin wrote: Can anyone help me solving this problem in clojure 1196 - Ring of Primes http://coj.uci.cu/24h/problem.xhtml?abb=1196 -- -- 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: A Design (Simplification) Problem
Thank you everyone for your input!
@James
Hm, I think I understand what you mean. Interesing idea, I will think some
more about it.
@Sacha
Ah, yes, of course. I don't know why I didn't think of it. Probably because
I had I similar idea when I first started out but discarded it for some
forgotten reason. But this is probably the way I'll go.
@Cedric
I had not thought about that. Although it would not work out so well in my
game, it's an interesing idea.
Thanks again to you all!
On Wednesday, November 13, 2013 8:30:45 PM UTC+1, Cedric Greevey wrote:
One might also wish to consider a pull model, in which clients
explicitly request information they need from the server. A client could
ask for an object's health, given its ID; or for the current ids and
positions of monsters in a particular small geographical area (which the
server would look up using interval trees).
On Wed, Nov 13, 2013 at 1:46 PM, Phlex ph...@telenet.be javascript:wrote:
Instead of making changes to your data structure, then creating an event,
you could :
-create a modification command as a data structure {:type :move
:character-id 12 :move-to {some coords..}}
-apply it to your data structure (each and every modification to the data
structure would have to be done via those commands)
-send it to the client as an event (some filtering might be in order)
This way you have a clear way to channel all your commands to your world,
a clean separation between command, world and client. A clean interface to
your world and finally a clean wire protocol ! (and easy logging, replay
from save point etc...)
Sacha
--
--
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 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: custom templates shadow _admin templates
Justin Smith noisesm...@gmail.com writes: Hi Justin, The your own resources subdirectory is merged over the admin one, the structure visible here: caribou admin templateshttps://github.com/caribou/caribou-admin/tree/master/resources/templates Ok, thanks for the clarification. At least login and logout seem like very likely names to be picked by users, too. Update: I have created a namespaced-templates branch of caribou-admin, and the fix actually looks like it will be a shallow change (if moderately tedious given our lack of relative partial paths in templates which gives me another idea...). That looks like a good change to me. If I'm right, I can still override admin templates by creating a _admin/login.html for example, right? Bye, Tassilo -- -- 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: custom templates shadow _admin templates
Yes, I've made significant progress in moving the templates, but a few of the field editing partials are not accounted for yet. Right now most of the admin works in the new branch, but a few of the field editors have some errors introduced. You are welcome to check out the namespaced-templates branch of the caribou-admin projecthttps://github.com/caribou/caribou-admin/tree/namespaced-templatesif you would like to help and submit a pull request. On Friday, November 15, 2013 10:01:23 AM UTC-8, Tassilo Horn wrote: Justin Smith noise...@gmail.com javascript: writes: Hi Justin, The your own resources subdirectory is merged over the admin one, the structure visible here: caribou admin templates https://github.com/caribou/caribou-admin/tree/master/resources/templates Ok, thanks for the clarification. At least login and logout seem like very likely names to be picked by users, too. Update: I have created a namespaced-templates branch of caribou-admin, and the fix actually looks like it will be a shallow change (if moderately tedious given our lack of relative partial paths in templates which gives me another idea...). That looks like a good change to me. If I'm right, I can still override admin templates by creating a _admin/login.html for example, right? Bye, Tassilo -- -- 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: custom templates shadow _admin templates
And yes, you could still customize by overriding the templates in their new path (which all being under _admin would not reasonably conflict with an app that intends to use the admin). On Friday, November 15, 2013 10:20:25 AM UTC-8, Justin Smith wrote: Yes, I've made significant progress in moving the templates, but a few of the field editing partials are not accounted for yet. Right now most of the admin works in the new branch, but a few of the field editors have some errors introduced. You are welcome to check out the namespaced-templates branch of the caribou-admin projecthttps://github.com/caribou/caribou-admin/tree/namespaced-templatesif you would like to help and submit a pull request. On Friday, November 15, 2013 10:01:23 AM UTC-8, Tassilo Horn wrote: Justin Smith noise...@gmail.com writes: Hi Justin, The your own resources subdirectory is merged over the admin one, the structure visible here: caribou admin templates https://github.com/caribou/caribou-admin/tree/master/resources/templates Ok, thanks for the clarification. At least login and logout seem like very likely names to be picked by users, too. Update: I have created a namespaced-templates branch of caribou-admin, and the fix actually looks like it will be a shallow change (if moderately tedious given our lack of relative partial paths in templates which gives me another idea...). That looks like a good change to me. If I'm right, I can still override admin templates by creating a _admin/login.html for example, right? Bye, Tassilo -- -- 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.
maintainability, DSLs, declarative APIs, etc.
Pulling this from another thread: On Nov 14, 2013, at 2:28 AM, Sean Johnson bel...@acm.org wrote: The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no magic (Python). This probably comes down to personal preference, and so is a potential benefit of any of them, depending on your preference, but it's a significant difference, so it's worth pointing out. By magic I just mean when the system seems to be more doing something much more powerful than you can readily see just by looking at the code. A simple few lines of code are doing all these wondrous things that aren't spelled out completely in the code (unless you peek under the covers and can understand the black arts that lie there). In Ruby/Rails this is the result of a lot of metaprogramming happening, based on conventions (that must be learned). In Clojure this happens through macros that implement powerful DSLs. In Python, it doesn't happen nearly as much. Code tends to be more transparent. This description of ruby, clojure, and python very much matches my experience (though with ruby I'm relying on the accounts of other developers that I know, since I haven't personally used ruby). Why are black arts and opaque code desirable? It's almost a tautology that these things are unmaintainable: you can't maintain code if you can't readily understand it, e.g. if it depends on black arts, or is not transparent. -- -- 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.
What does Clojure get from Java 8?
I had read that the Clojure team was prepping the build to work on the new JDK8 and it got me to thinking - what does Clojure get from Java 8? Will it be using some of the new features or does the compiler just need to be ready for changes in the JDK so compilation passes? Clojure already has much of what Java 8 is delivering, so will it switch its internals to using the Java internals or just leave it alone? Again, just curious. 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.
Re: maintainability, DSLs, declarative APIs, etc.
To me macros DSLs are just an instance/extension of the DRY principle and not that much different to using functions (albeit with more syntactic freedom, e.g. by supplying a body expression to be wrapped or transformed into something more complex). Of course there's the potential loss of control understanding when using 3rd party macros, but in Clojure the use of library macros is often hardly enforced without also having a purely functional way as alternative. I think the stronger reliance on certain naming conventions (e.g. in RoR) or the type specific overriding of operators in C++ has much more of a magical/mysterious element to it than most of the CLJ macros I've been using thus far. Last but not least, since most libs are open source, what stops you from studying a specific macro/DSL? My 2p... On 15 Nov 2013 19:51, Brian Craft craft.br...@gmail.com wrote: Pulling this from another thread: On Nov 14, 2013, at 2:28 AM, Sean Johnson bel...@acm.org wrote: The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no magic (Python). This probably comes down to personal preference, and so is a potential benefit of any of them, depending on your preference, but it's a significant difference, so it's worth pointing out. By magic I just mean when the system seems to be more doing something much more powerful than you can readily see just by looking at the code. A simple few lines of code are doing all these wondrous things that aren't spelled out completely in the code (unless you peek under the covers and can understand the black arts that lie there). In Ruby/Rails this is the result of a lot of metaprogramming happening, based on conventions (that must be learned). In Clojure this happens through macros that implement powerful DSLs. In Python, it doesn't happen nearly as much. Code tends to be more transparent. This description of ruby, clojure, and python very much matches my experience (though with ruby I'm relying on the accounts of other developers that I know, since I haven't personally used ruby). Why are black arts and opaque code desirable? It's almost a tautology that these things are unmaintainable: you can't maintain code if you can't readily understand it, e.g. if it depends on black arts, or is not transparent. -- -- 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: maintainability, DSLs, declarative APIs, etc.
I've worked extensively in Java, Ruby, and Clojure, so I have plenty of experience with having and not having meta-programming and macros. In my opinion meta-programming and macros are not black art, they are simply part of the language. If someone chooses to do something that isn't easy to understand, that's not the fault of the language, it's the fault of the programmer. (this is the royal You, not Brian) Your language choice should probably factor in your desire to dig into metaprogramming or macros. You don't need to use those features of the language in your own code, but you'll surely run into both using someone else's framework or library. If you prefer not to deal with the complexities that can arise from having those features available, not using Ruby or Clojure is probably a good choice. Conversely, if you want the power of metaprogramming and macros, and are willing to learn them deeply enough that you can deal with some poorly written metaprogramming or macros, then you should prefer Ruby or Clojure. Better to have the ability when you desire it, than not to have it - if you're willing to put up with other people (ab)using that power at times. It's a balance, and I strongly believe that people program in many different ways. (among other tradeoffs) You can have a powerful IDE and a ton of boiler plate, explicit code, or you can have little refactoring support and the ability to eliminate the boiler plate code; you have to chose which you value more. You also need to know that the choice you make will eliminate working with some people - those that choose the other way. Neither group of people will be good or bad, both will have great and terrible programmers who simply prefer to program in differing ways. On Fri, Nov 15, 2013 at 2:51 PM, Brian Craft craft.br...@gmail.com wrote: Pulling this from another thread: On Nov 14, 2013, at 2:28 AM, Sean Johnson bel...@acm.org wrote: The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no magic (Python). This probably comes down to personal preference, and so is a potential benefit of any of them, depending on your preference, but it's a significant difference, so it's worth pointing out. By magic I just mean when the system seems to be more doing something much more powerful than you can readily see just by looking at the code. A simple few lines of code are doing all these wondrous things that aren't spelled out completely in the code (unless you peek under the covers and can understand the black arts that lie there). In Ruby/Rails this is the result of a lot of metaprogramming happening, based on conventions (that must be learned). In Clojure this happens through macros that implement powerful DSLs. In Python, it doesn't happen nearly as much. Code tends to be more transparent. This description of ruby, clojure, and python very much matches my experience (though with ruby I'm relying on the accounts of other developers that I know, since I haven't personally used ruby). Why are black arts and opaque code desirable? It's almost a tautology that these things are unmaintainable: you can't maintain code if you can't readily understand it, e.g. if it depends on black arts, or is not transparent. -- -- 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: What does Clojure get from Java 8?
There are only two changes I am aware of for JDK8 preparation so far, and they are simply to allow Clojure to compile without warnings [1] and pass all of the unit tests without failure when using JDK8 [2]. These are minor changes. [1] http://dev.clojure.org/jira/browse/CLJ-1264 [2] http://dev.clojure.org/jira/browse/CLJ-1246 [2] was really an existing issue before JDK8 -- it is simply that a change in the annotations of the Java class library caused the problem to be exposed with the existing unit tests when run on JDK 8. Andy On Fri, Nov 15, 2013 at 11:54 AM, Charles Harvey III charlesnhar...@gmail.com wrote: I had read that the Clojure team was prepping the build to work on the new JDK8 and it got me to thinking - what does Clojure get from Java 8? Will it be using some of the new features or does the compiler just need to be ready for changes in the JDK so compilation passes? Clojure already has much of what Java 8 is delivering, so will it switch its internals to using the Java internals or just leave it alone? Again, just curious. 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: maintainability, DSLs, declarative APIs, etc.
On Friday, November 15, 2013 12:10:59 PM UTC-8, Karsten Schmidt wrote: To me macros DSLs are just an instance/extension of the DRY principle and not that much different to using functions (albeit with more syntactic freedom, e.g. by supplying a body expression to be wrapped or transformed into something more complex). Of course there's the potential loss of control understanding when using 3rd party macros, but in Clojure the use of library macros is often hardly enforced without also having a purely functional way as alternative. I think the stronger reliance on certain naming conventions (e.g. in RoR) or the type specific overriding of operators in C++ has much more of a magical/mysterious element to it than most of the CLJ macros I've been using thus far. Last but not least, since most libs are open source, what stops you from studying a specific macro/DSL? Thanks for your perspective. Regarding the last question, it's a matter of scaling. Often in production code you have to be in and out of an unfamiliar piece of code in a few hours. You can't stop to study an unfamiliar DSL for a couple days. I've heard people doing contract work in ruby swearing when they encounter another DSL: it kills their productivity. -- -- 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: maintainability, DSLs, declarative APIs, etc.
On Fri, Nov 15, 2013 at 3:30 PM, Brian Craft craft.br...@gmail.com wrote: I've heard people doing contract work in ruby swearing when they encounter another DSL: it kills their productivity. those same people wouldn't have Ruby contracting work if it weren't for metaprogramming... -- -- 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: maintainability, DSLs, declarative APIs, etc.
The first rule of macro club is Don't write macros. Macros are powerful, but they should be considered the last avenue of attack. Often macros are a slim wrapper around an API made out of functions, and there just to provide some syntax sugar. Libraries that use macros more extensively, like core.logic, or the go form in core.async, are relatively rare, and cover the cases where nothing else but macros are powerful enough to implement the desired functionality. Instead, it's far better to start with a data-driven approach. A data structure is always preferable over an API, and an API is always preferable over a DSL. This approach can be seen in Datomic, which uses data structures to represent queries and commands, or Ring, where data structures are used to represent HTTP requests and responses. Clojure heavily emphasises data, far more than most other languages, and certainly more than OOP. - James On 15 November 2013 19:51, Brian Craft craft.br...@gmail.com wrote: Pulling this from another thread: On Nov 14, 2013, at 2:28 AM, Sean Johnson bel...@acm.org wrote: The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no magic (Python). This probably comes down to personal preference, and so is a potential benefit of any of them, depending on your preference, but it's a significant difference, so it's worth pointing out. By magic I just mean when the system seems to be more doing something much more powerful than you can readily see just by looking at the code. A simple few lines of code are doing all these wondrous things that aren't spelled out completely in the code (unless you peek under the covers and can understand the black arts that lie there). In Ruby/Rails this is the result of a lot of metaprogramming happening, based on conventions (that must be learned). In Clojure this happens through macros that implement powerful DSLs. In Python, it doesn't happen nearly as much. Code tends to be more transparent. This description of ruby, clojure, and python very much matches my experience (though with ruby I'm relying on the accounts of other developers that I know, since I haven't personally used ruby). Why are black arts and opaque code desirable? It's almost a tautology that these things are unmaintainable: you can't maintain code if you can't readily understand it, e.g. if it depends on black arts, or is not transparent. -- -- 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: [ANN] Yesql 0.2.1 - Clojure SQL queries rethought.
Hi Kris, I really like your approach, but I've also been feeling the burn a bit with having to store each SQL query in its own file (especially since my data exploration frequently leaves me cataloging hundreds of them). Take a look at the approach used in sql-phrasebook: https://github.com/ray1729/sql-phrasebook I'm hoping it will give you some ideas to extend Yesql to address this particular issue, ideally with a nicer syntax than that used in sql-phrasebook. Otherwise, I think Yesql is bound for great things! Cheers, ~Gary On Tuesday, November 12, 2013 5:14:14 AM UTC-5, Kris Jenkins wrote: It depends on which kind of composability you mean. If we're talking about a SELECT ... FROM ... here with a WHERE ... there, I don't see why not. It's a down-the-road feature, but I'm open to it. But the kind of composability that would get me excited is the cascalog/datalog kind. Where you could say, SELECT * FROM employee and mix that with SELECT * FROM deparment and get an automatic, sensibly-optimised join. That's real composibility, beyond mere string concatenation. No, I don't see Yesql ever supporting that. (There again, I haven't seen it from any of the Clojure-SQL-DSLs either. If you have, please point me to them. I'd be interested!) Cheers, Kris On Tuesday, 12 November 2013 03:35:46 UTC, John Hume wrote: For me, the one feature that can justify an internal DSL for generating SQL is the ability to compose queries. I assume that's not on the Yesql roadmap. On Nov 11, 2013 5:10 AM, Kris Jenkins krisaj...@gmail.com wrote: https://github.com/krisajenkins/yesql Yesql is a simple library for blending SQL Clojure together, cleanly. Here's how it works https://github.com/krisajenkins/yesql#rationale, and how to use it https://github.com/krisajenkins/yesql#example-usage. Feedback welcomed, Kris -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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] Cornet 0.1.0 - Clojure asset pipeline for minification and compilation of LessCSS and CoffeeScript (...more coming soon)
http://upload.wikimedia.org/wikipedia/commons/6/6d/Cornet2.png https://github.com/cosmi/cornet Cornet is a simple asset pipeline that will help you compile on the flight LessCSS, CoffeeScript and minify all your CSSes and JSes. I wasn't happy with what's already there (dieterhttps://github.com/edgecase/dieter isn't really in spirit of Clojure) - I wanted something simple to use and compatible with Compojure. So here it is - my third iteration of the idea. There's simple basic usage described in the README, but I am really proud of the architecture of the library. It is very extendable and can combine transformations in any way you want, so I will work on new usage modes if needed (or you can figure it out by yourself :) ). Let me know what you think. Also, how are you managing this now? Marcin -- -- 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: maintainability, DSLs, declarative APIs, etc.
One more point that no one has emphasized: Lisps allow code to write code. Sometimes the way to provide an abstraction or generalization of a pattern is by writing a code-writer. Macros provide a convenient way of using that capability. (On a project years ago, for every Java class of kind X, we needed a corresponding Java class of kind Y. There were many X classes, so I ended up writing a Perl script to construct Y source files from X source files. It was much easier to do that with Perl than to write a Java code-translator. For an analogous problem with Clojure code, it would be even easier use Clojure to generate the new code.) -- -- 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.
