Re: How to go about 'proving' why dynamically typed languages are better.
I think what you're banging your head against is the tension between computer science qua pure science, versus software engineering qua engineering practice. This tension isn't unique to our field; mathematicians look down on theoretical physicists, who look down on practical physicists, who look down on engineers, all the way down to the humanities, who are generally ignored. Or, to summarize: http://imgs.xkcd.com/comics/purity.png So, sure, from a theroetical standpoint, oriented toward proofs and provable correctness, type systems are superior. OTOH, for practicing software engineers, who care more about reliably and efficiently *building shit,* language flexibility is a massive boon, and we compensate for the lack of provable correctness with strategies like TDD. I agree w/ Laurent; it's not a black/white issue... to me it's more apples and oranges, dispatching on intent. Are you trying to prove a theorem, or build software? Not that you can't build scalable web services in Haskell, but I don't know anyone within a standard deviation of sanity who has ever done so for production code. The beauty of Clojure is that it gives us the ability to create realiable, robust, real-world solutions without sacrificing elegance; not because it's dynamically typed or because it has an optional type system (although both of those aspects are great), but because it combines power and simplicity. Holy wars are fun for a while (if I wanted to start one on this list, I'd go into the superiority of vim over emacs), but if your real goal is building things, you gotta let them go, and when people start heckling the fact that Clojure doesn't implement Hindley-Milner type inference... just shrug, point to the reliable, scalable architecture you built in two weeks, and get back to work. Just my US$0.02. Jason On Tuesday, October 8, 2013 12:46:41 AM UTC-4, zcaudate wrote: Hahaha, thanks Philip. Does it really take a doctorate to understand classification of elephants? I think the overall consensus is that having basic type checking is good... but over doing types is bad. Would this be a reasonable guideline for using types? 1. Types are useful for structures that HOLD data (ints, strings, maps, arrays… ) because they provide ways defining standard operations to manipulate data that make sense in the context of that type of data. It is helpful to have a type checker check that I am not accessing the 6th element of a hashmap or that I am adding 10 to Hello. 2. When a particular data-structure is sufficient for holding information, then its better to just use the data-structure because we have so many generic operations predefined. For example, if I have to model customers in a line. I wouldn't have type CUSTOMER and type LINE. I would just represent this as a QUEUE of MAPS…. However… I find that I am writing a lot of statements like this: (cond (hash-map? v) …… (vector? v) …… (list? v) ….. :else …..) I'm not sure a type checker will help in that instance. -- -- 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: Teaching Clojure to students (how ?)
2013/10/6 bernardH un.compte.pour.tes...@gmail.com Hi all, I intend to (ab)use my authority as a teacher to enlighten unsuspecting students about Clojure. I've been teaching Clojure for 3 years now in a university course focused on concurrent and parallel programming http://soft.vub.ac.be/~tvcutsem/multicore/. While I give a basic intro to Clojure, I mostly stick to just functions + basic collections + the seq API, and of course atoms/refs/agents. As part of that course, I developed a meta-circular implementation of Clojure's STM https://github.com/tvcutsem/stm-in-clojure. STM is a pretty complex language feature. I found showing students an implementation of STM in Clojure itself helps them to better understand it. Of course, this is beyond an introductory programming course, so YMMV. Regards, Tom -- -- 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] Instaparse 1.2.3
Instaparse https://github.com/Engelberg/instaparse/ is an easy-to-use, feature-rich parser library. The big idea behind instaparse is to make it simple to convert grammars to parsers without needing to know the idiosyncrasies of LL1, LALR, and other esoteric grammar restrictions imposed by most parser generators. 1.2.3 is a minor update, providing documentation for two recently added experimental features: 1. A special parsing mode that can optimize memory usage in some cases. 2. A mechanism that simplifies the specification of grammars that permit optional whitespace between all tokens. (Thanks to Reid McKenzie for proposing this). https://github.com/Engelberg/instaparse/blob/master/docs/ExperimentalFeatures.md The documentation details how to use the features as they are currently implemented, but also explains the design tradeoffs I'm considering, and what kind of feedback I'd like to get from the community before finalizing the features. -- -- 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: Teaching Clojure to students (how ?)
John D. Hume duelin.mark...@gmail.com writes:
I'd suggest that Clojure's Hello, World! should happen initially at the
repl, where leiningen definitely simplifies the UX.
lein repl # from any cwd
(println ...)
which launches nicely into demonstrating dynamic development.
Except that the Clojure repl is not persistant; compare this to R for instance:
$ lein repl
user= (defn fun[]
#_= (println hello))
#'user/fun
user= (fun)
hello
nil
user= Bye for now!
$ lein repl
user= (fun)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: fun in
this context, compiling:(NO_SOURCE_PATH:1:1)
$ R
hello - function(){
+ print(Hello)
+ }
hello
function(){
print(Hello)
}
hello()
[1] Hello
Save workspace image? [y/n/c]: y
$ R
[Previously saved workspace restored]
hello()
[1] Hello
With R, the REPL is a user-interface that you can work in over time.
With Clojure, the REPL is somewhere you can experiment, but ultimately
you have to keep your source in a file.
I've tried teaching python using it's repl and you have the same problem
there. It's fine for teaching what print hello does, and what 7/2
returns. After that, you have to say now forget that REPL stuff and
let's type a file.
Phil
--
--
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: Teaching Clojure to students (how ?)
Guess you have programmed before. Besides which, if I am teaching any significant number of students, I will get the sys admins to do the installation; otherwise, you the first two weeks, you spend running around fixing peoples environment. This kind of nonsense is soul-destroying for new programmers; it's depressing and saps their desire to learn. Old programmers know the tricks to get through this quickly (students never believe me when I tell them that they will still be writing hello world in 10 years time); and besides, most old programmers sold their souls years ago. All aside from the confusion that of to start Clojure, type lein. Does that make any sense? Phil Nando Breiter na...@aria-media.com writes: I'm in the process of trying to Clojure, and the fact that you need to install leiningen (I think ...) isn't a problem. All I need is clear, simple to follow instructions, and an explanation how all this plumbing works, and what its advantages are. I find installation instructions rather easily. Clear explanations about how the dependency plumbing works seem to be a bit lacking up front. Aria Media Sagl Via Rompada 40 6987 Caslano Switzerland +41 (0)91 600 9601 +41 (0)76 303 4477 cell skype: ariamedia On Mon, Oct 7, 2013 at 10:28 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: Lee Spector lspec...@hampshire.edu writes: I teach Clojure, to beginning programmers among others. IMHO you really have to specify your audience(s) before any advice about how best to teach Clojure (or programming in general) will make much sense. I'd absolutely agree with this. If you are teaching brand new programmers, then you really don't want to teach clojure at all; you want to teach programming, with the language being somewhat of a detail. You also need to know *why* you are teaching them. I teach differently if I am teaching new programmers hoping to gain a general understanding of computer science, than new programmers who have an immediate practical need. Also IMHO (just trying to deflect some flames here) the Clojure ecosystem currently lacks the ideal environment for this. Tend to agree with this also. As nice as leiningen is, Clojure seems to inherit from Java bulky projects. Compare these two hello worlds: (println hello world) to #!/usr/bin/python print( hello world ) Both equivalently simple, up and till the point you actually try to run them. The best I came up with is... java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar hello_world.clj which, of course, depends on me having installed leiningen and used it. So this may be totally wrong for many of your purposes, but FWIW: https://github.com/lspector/clojinc That's a nice idea. Phil -- -- 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. -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- 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: Teaching Clojure to students (how ?)
John Gabriele jmg3...@gmail.com writes:
For new users who want to get their feet wet right on the first day, I'd
suggest this (after they make sure they've got Java installed):
#. Download `lein`, drop it into your ~/bin, and `chmod +x` it if
necessary,
#. `lein version` (so it installs and thus creates ~/.lein directory (see
next step))
#. `touch ~/.lein/profiles.clj`, and into that file put `{:user {:plugins
[[lein-exec 0.3.1]]}}` (or whatever the current version of [lein-exec] is
when you're reading this. :) )
[lein-exec]: https://github.com/kumarshantanu/lein-exec
Now you can create your hello world about as simply as with P{erl,ython}:
#. create a ~/wherever/foo.clj file,
#. into it goes `(println hi)`, then
#. run it in the prescribed way: `lein exec foo.clj`.
That's interesting, didn't know about lein-exec (although I'm not
surprised someone has written it).
Phil
--
--
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: Teaching Clojure to students (how ?)
On Oct 8, 2013, at 02:36, Phillip Lord wrote: Except that the Clojure repl is not persistant; ... Although lein-exec allows re-use of Clojure scripts, it isn't much like a persistent REPL. So, this seems like an obvious opportunity for improvement. I'd love to have a convenient way to save and return to REPL sessions, pass them along to others, etc. One way to implement this would be to use (say) Git to store branches, commits, etc. -r -- http://www.cfcl.com/rdmRich Morin http://www.cfcl.com/rdm/resume r...@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation -- -- 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 go about 'proving' why dynamically typed languages are better.
On 6 Oct 2013, at 04:35, zcaudate z...@caudate.me wrote: I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. This debate is as old as the hills (it certainly predates object-oriented programming). There's no question that there is a valid debate to be had about static versus dynamic typing, but most such debates are hamstrung by basic misunderstandings. The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ In particular it asserts (correctly in my view) that what static type system proponents mean by type and what dynamic type system proponents mean by type are very different things. Most debates founder on a failure to recognise that difference. -- paul.butcher-msgCount++ Snetterton, Castle Combe, Cadwell Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://www.linkedin.com/in/paulbutcher MSN: p...@paulbutcher.com AIM: paulrabutcher Skype: paulrabutcher -- -- 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 go about 'proving' why dynamically typed languages are better
There's a link to his presentation there actually: http://www.infoq.com/presentations/data-types-issues?utm_source=infoqutm_medium=QCon_EarlyAccessVideosutm_campaign=StrangeLoop2013 However is says this: *Thank you for attending Strange Loop 2013* This is a restricted presentation that can only be viewed by Strange Loop 2013 attendees! Maybe Alex can comment on whether it's possible for those who didn't attend to watch this video at all. I'd be very keen. Leonardo Borges www.leonardoborges.com On Tue, Oct 8, 2013 at 2:11 AM, gaz jones gareth.e.jo...@gmail.com wrote: Martin Odersky gave a keynote at Strangeloop this year called The Trouble With Types (https://thestrangeloop.com/sessions/the-trouble-with-types) which made me never want to use a type system again (probably the exact opposite of his intention). The video should be coming out on infoq at some point: (http://www.infoq.com/conferences/strangeloop2013/). I've never looked at Scala before and I'm pretty sure I never will after sitting through that... On Mon, Oct 7, 2013 at 9:26 AM, juan.facorro juan.faco...@gmail.comwrote: Thanks for the link! I really liked the interview, it was interesting and fun to watch. J On Monday, October 7, 2013 9:49:24 AM UTC+9, brad bowman wrote: zcaudate z...@caudate.me Oct 05 08:35PM -0700 I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell http://www.infoq.com/**interviews/armstrong-peyton-** jones-erlang-haskellhttp://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell This interview covers some of the strong-types vs flexible development (apparent) dichotomy, but in a playful, open and non-dogmatic way. (catmatic?) Simon Peyton Jones is one of the Haskell leaders, yet admits to being envious of type-free generics. Joe Armstrong of Erlang fame also sees the benefit to thinking in and annotating types. These two are both leaders of typed or dynamic cults but have a pleasant friendly and frank conversation about the issues. (Erlang's Dialyzer sounds somewhat like core.typed) A sample: SPJ: So, I've told you what I most envy about Erlang. What do you most envy about Haskell? JA: All the types. I mean they're very nice. I wish we had them. On the other hand, wouldn't you love to have all these generic turn-to-binary, these sort of things? How can you live without them? SPJ: I have a little bit of residual envy about generics. JA: You just take anything and compare it to the serializer and then send it? SPJ: That's sinfully easy, and shouldn't be allowed. So if these two can agree that there's strengths and weaknesses in both approaches, that settles it for me. It's a matter of knowing your trade-offs and choosing your tools appropriately. My suspicion is that type affinity is related to some trait of personality, and so trying to prove superiority is a likely to work as proving you are right in any other clash of personalities. Brad -- -- 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
Re: How to go about 'proving' why dynamically typed languages are better.
Chris Zheng z...@caudate.me writes: Hahaha, thanks Philip. Does it really take a doctorate to understand classification of elephants? I have a doctorate in how yeast divide. Trust me, computers are easy in comparison to elephants. I think the overall consensus is that having basic type checking is good... but over doing types is bad. Would this be a reasonable guideline for using types? 1. Types are useful for structures that HOLD data (ints, strings, maps, arrays… ) because they provide ways defining standard operations to manipulate data that make sense in the context of that type of data. It is helpful to have a type checker check that I am not accessing the 6th element of a hashmap or that I am adding 10 to Hello. This would be useful indeed. Although, a hard core type head would say I want to distinguish between a string that is an email, someones name, and a day of the week. This is not unreasonable. However… I find that I am writing a lot of statements like this: (cond (hash-map? v) …… (vector? v) …… (list? v) ….. :else …..) I'm not sure a type checker will help in that instance. A type-checker wouldn't no, but a type system would; pretty much every language with a static type system has a type based dispatch somewhere. It would be nice to be able to do (defun fn ([^vector v] ...) ([^list l] ...) ([else] ...) I guess that core.logic will support this at some point. Phil -- -- 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 go about 'proving' why dynamically typed languages are better
This demonstrates yet another problem with not simply *writing a blog post* or something on The Trouble With Types. Not only do videos require enormous bandwidth (which mobile users often pay metered rates for, and most people not actually metered have caps with overage charges for exceeding them), and sometimes get stuck buffering, and eat up disk space if you download to keep a local copy to avoid the buffering, and google can't see inside them, nor can control-F, nor can you read them at *your* pace, nor can you skim them, nor can you copy and paste bits to quote and discuss them, nor can you print them and highlight key passages, nor etc. etc. etc., but fairly often the damned things are locked behind paywalls or similar idiocy, which is rarely the case with textual content such as blog posts. And in an awful lot of cases the giant extra bandwidth, and loss of most of the search, navigation, and UI capabilities that have built up around text but are sorely lacking for audio/video, is suffered merely to deliver several tens of megabytes of pictures of someone's talking head, with maybe some slides showing some useful diagrams now and again, and of course sometimes the site *wants* to make quoting and even viewing more difficult for their own (perceived, at least; it's often illusory, especially in the case of copy-protection) pecuniary benefit. Text, with maybe a few illustrative jpegs or even an animated .gif or two if needed, for the win. :) On Tue, Oct 8, 2013 at 6:32 AM, Leonardo Borges leonardoborges...@gmail.com wrote: There's a link to his presentation there actually: http://www.infoq.com/presentations/data-types-issues?utm_source=infoqutm_medium=QCon_EarlyAccessVideosutm_campaign=StrangeLoop2013 However is says this: *Thank you for attending Strange Loop 2013* This is a restricted presentation that can only be viewed by Strange Loop 2013 attendees! Maybe Alex can comment on whether it's possible for those who didn't attend to watch this video at all. I'd be very keen. Leonardo Borges www.leonardoborges.com On Tue, Oct 8, 2013 at 2:11 AM, gaz jones gareth.e.jo...@gmail.comwrote: Martin Odersky gave a keynote at Strangeloop this year called The Trouble With Types ( https://thestrangeloop.com/sessions/the-trouble-with-types) which made me never want to use a type system again (probably the exact opposite of his intention). The video should be coming out on infoq at some point: ( http://www.infoq.com/conferences/strangeloop2013/). I've never looked at Scala before and I'm pretty sure I never will after sitting through that... On Mon, Oct 7, 2013 at 9:26 AM, juan.facorro juan.faco...@gmail.comwrote: Thanks for the link! I really liked the interview, it was interesting and fun to watch. J On Monday, October 7, 2013 9:49:24 AM UTC+9, brad bowman wrote: zcaudate z...@caudate.me Oct 05 08:35PM -0700 I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell http://www.infoq.com/**interviews/armstrong-peyton-** jones-erlang-haskellhttp://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell This interview covers some of the strong-types vs flexible development (apparent) dichotomy, but in a playful, open and non-dogmatic way. (catmatic?) Simon Peyton Jones is one of the Haskell leaders, yet admits to being envious of type-free generics. Joe Armstrong of Erlang fame also sees the benefit to thinking in and annotating types. These two are both leaders of typed or dynamic cults but have a pleasant friendly and frank conversation about the issues. (Erlang's Dialyzer sounds somewhat like core.typed) A sample: SPJ: So, I've told you what I most envy about Erlang. What do you most envy about Haskell? JA: All the types. I mean they're very nice. I wish we had them. On the other hand, wouldn't you love to have all these generic turn-to-binary, these sort of things? How can you live without them? SPJ: I have a little bit of residual envy about generics. JA: You just take anything and compare it to the serializer and then send it? SPJ: That's sinfully easy, and shouldn't be allowed. So if these two can agree that there's strengths and weaknesses in both approaches, that settles it for me. It's a matter of knowing your trade-offs and choosing your tools appropriately. My suspicion is that type affinity is related to some trait of personality, and so trying to prove superiority is a likely to work as proving you are right in any other clash of personalities. Brad -- -- You received this message
Re: Teaching Clojure to students (how ?)
Rich Morin r...@cfcl.com writes: On Oct 8, 2013, at 02:36, Phillip Lord wrote: Except that the Clojure repl is not persistant; ... Although lein-exec allows re-use of Clojure scripts, it isn't much like a persistent REPL. So, this seems like an obvious opportunity for improvement. I'd love to have a convenient way to save and return to REPL sessions, pass them along to others, etc. One way to implement this would be to use (say) Git to store branches, commits, etc. That wouldn't do the full job. R persistance saves *everything* including state. So if you read a dataframe from a file, the dataframe will be available next time even if the file is not. The easiest way to persist this would probably be to pickle the entire runtime and then load it again. Phil -- -- 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: Teaching Clojure to students (how ?)
Hi Rich, On Tuesday, 8 October 2013 15:18:17 UTC+5:30, Rich Morin wrote: On Oct 8, 2013, at 02:36, Phillip Lord wrote: Except that the Clojure repl is not persistant; ... Although lein-exec allows re-use of Clojure scripts, it isn't much like a persistent REPL. So, this seems like an obvious opportunity for improvement. (I'm the author of lein-exec.) That's definitely an interesting angle. I would think about how best to implement such a thing. Please feel free to raise an issue or send a pull request. One idea could be to launch a Clooj[1] or Clj-SwingREPL[2] instance with the script. [1] https://github.com/arthuredelstein/clooj [2] https://github.com/alandipert/clj-swingrepl Shantanu -- -- 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 go about 'proving' why dynamically typed languages are better
It will be at some point. Like most conferences taped by InfoQ, the videos will be released slowly over time. Those who attended this conference got a key that they can use to access the video. Timothy On Tue, Oct 8, 2013 at 4:32 AM, Leonardo Borges leonardoborges...@gmail.com wrote: There's a link to his presentation there actually: http://www.infoq.com/presentations/data-types-issues?utm_source=infoqutm_medium=QCon_EarlyAccessVideosutm_campaign=StrangeLoop2013 However is says this: *Thank you for attending Strange Loop 2013* This is a restricted presentation that can only be viewed by Strange Loop 2013 attendees! Maybe Alex can comment on whether it's possible for those who didn't attend to watch this video at all. I'd be very keen. Leonardo Borges www.leonardoborges.com On Tue, Oct 8, 2013 at 2:11 AM, gaz jones gareth.e.jo...@gmail.comwrote: Martin Odersky gave a keynote at Strangeloop this year called The Trouble With Types ( https://thestrangeloop.com/sessions/the-trouble-with-types) which made me never want to use a type system again (probably the exact opposite of his intention). The video should be coming out on infoq at some point: ( http://www.infoq.com/conferences/strangeloop2013/). I've never looked at Scala before and I'm pretty sure I never will after sitting through that... On Mon, Oct 7, 2013 at 9:26 AM, juan.facorro juan.faco...@gmail.comwrote: Thanks for the link! I really liked the interview, it was interesting and fun to watch. J On Monday, October 7, 2013 9:49:24 AM UTC+9, brad bowman wrote: zcaudate z...@caudate.me Oct 05 08:35PM -0700 I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell http://www.infoq.com/**interviews/armstrong-peyton-** jones-erlang-haskellhttp://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell This interview covers some of the strong-types vs flexible development (apparent) dichotomy, but in a playful, open and non-dogmatic way. (catmatic?) Simon Peyton Jones is one of the Haskell leaders, yet admits to being envious of type-free generics. Joe Armstrong of Erlang fame also sees the benefit to thinking in and annotating types. These two are both leaders of typed or dynamic cults but have a pleasant friendly and frank conversation about the issues. (Erlang's Dialyzer sounds somewhat like core.typed) A sample: SPJ: So, I've told you what I most envy about Erlang. What do you most envy about Haskell? JA: All the types. I mean they're very nice. I wish we had them. On the other hand, wouldn't you love to have all these generic turn-to-binary, these sort of things? How can you live without them? SPJ: I have a little bit of residual envy about generics. JA: You just take anything and compare it to the serializer and then send it? SPJ: That's sinfully easy, and shouldn't be allowed. So if these two can agree that there's strengths and weaknesses in both approaches, that settles it for me. It's a matter of knowing your trade-offs and choosing your tools appropriately. My suspicion is that type affinity is related to some trait of personality, and so trying to prove superiority is a likely to work as proving you are right in any other clash of personalities. Brad -- -- 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
Re: How to go about 'proving' why dynamically typed languages are better.
On Oct 8, 2013 5:35 AM, Phillip Lord However… I find that I am writing a lot of statements like this: (cond (hash-map? v) …… (vector? v) …… (list? v) ….. :else …..) zcaudate, in what context(s) do you find yourself writing a lot of expressions like that? I rarely want to allow so much flexibility in arguments. I'm wondering if there are idioms to avoid it. I'm not sure a type checker will help in that instance. A type-checker wouldn't no, but a type system would; pretty much every language with a static type system has a type based dispatch somewhere. It would be nice to be able to do (defun fn ([^vector v] ...) ([^list l] ...) ([else] ...) How is Clojure's protocols feature different from what you're describing? -- -- 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: Teaching Clojure to students (how ?)
Hi Phil, 1. Select the text you want auto-indented and press SHIFT+TAB. 2. The documentation tab opens in a new tabset - to close tabsets you right-click on them and choose 'Close tabset'. 3. I haven't discovered a way to disable auto-brackets. 4. Yes, you can access it from the command pane, or you can add a key-binding in your user.keymap. I have mine set to CMD+; with pmeta-; [:toggle-comment-selection]. 5. Won't you need to copy+paste from the console anyway? Why not just grab the part without the filename? 6. Currently you make projects externally (using Leiningen) and then import them into Light Table. 7. This is one downside to having an IDE that's written in Clojure. 8. You can hide evaluations using the command pane and Eval: Clear inline results, or you can add a key-binding in your user.keymap. I have mine set to CMD+SHIFT+BACKSPACE pmeta-shift-backspace [:clear-inline-results] 9. I don't think Light Table has this feature yet. It's worth noting that Light Table is still in the early stages of development, so it doesn't have all of the features of more mature IDEs. However, Chris is going to add plugin support in the next major release, which will remove him as the bottleneck for adding exactly the kind of features you're looking for. I think it's a very exciting time for Light Table. Cheers, James On Tuesday, October 8, 2013 12:00:52 AM UTC+2, Lee wrote: Hi James, I have indeed tried LightTable, and it does indeed seem promising. Really exciting potential. But I've hit enough snags every time I've tried it that I haven't really found it useful (either for teaching or for my own use). I just tried the latest version again, just now, and just for anyone who may care here are my (opinionated, and YMMV) reactions: 1. Is there auto-reindentation? I don't see it. Pretty essential, IMHO. 2. I can close a tab (like the documentation) if I control-click on it, but the pane remains... and I've ended up with lots of panes that I have to quit to get rid of. In general I love the look of the GUI but wish the controls were more obvious/standard in many cases. 3. Can automatic bracket insertion be turned off? It's problematic in my book, especially for newcomers who should be allowed to use the keyboarding skills that they already have. 4. Is there a block comment/uncomment feature? 5. The console output precedes every line with the file that generated it, which means that you can't get a clean output log. Lots of the code that I and my students write is oriented toward producing textual output in the console, and this sort of rules out those uses (unless you want to clean up the output later, which would be a pain). 6. Can I make a new project? I don't immediately see how... (Digression: tried to search the documentation for this but couldn't see how to do the search... I do get a (novel) find pane for my open editor window, but can I make that work for the documentation pane? Can I make it go away? Again, looks cool but I wish it leveraged more common GUI idioms.) 7. A new project created with lein at the command line works, but an older one gives Light Table requires Clojure Version 1.5.1 or higher... I see that that old project used [org.clojure/clojure 1.4.0]... Awkward that this couldn't be run even if the IDE needs something newer for itself... 8. Expressions that produce big values can make it hard to read your code by interspersing the values, which I may not really want to see. 9. Is there anyway to get arglist on space or arglists (and/or documentation) in another pane or a popup or whatever, either as you type or when you hit a particular key? Overall: Very cool in several ways, some glitches or little issues that I could live with, but also quite a few that would be pretty problematic to me personally, for my teaching and/or my own use (specifically 1, 3, 5, 9). Clooj is better on many of these issues, but it has some other weaknesses (esp that it is not maintained very actively, e.g. I don't know if it works with modern leiningen). NightCode is also getting into the running, I think. But from my perspective none of them yet fill the niche that I've been discussing. -Lee PS I'd be in Clojure IDE heaven if someone could provide some version of one of these light-weight Clojure IDEs that also incorporated nrepl-ritz so that we could see the values of locals when we hit exceptions... On Oct 7, 2013, at 4:15 PM, Jernau wrote: Lee, Have you tried Light Table? I think it would be a perfect match for your use-case. Here's a screencast of me using Light Table's Instarepl to teach list comprehension in Clojure. As you will hopefully agree, Light Table's features are a great match for a learning/teaching situation. Light Table's Instarepl works out-of-box after installation, so it'll be easy to get your students up and running. Then, when your
Re: How to go about 'proving' why dynamically typed languages are better.
1. Types are useful for structures that HOLD data (ints, strings, maps, arrays… ) because they provide ways defining standard operations to manipulate data that make sense in the context of that type of data. It is helpful to have a type checker check that I am not accessing the 6th element of a hashmap or that I am adding 10 to Hello. This would be useful indeed. Although, a hard core type head would say I want to distinguish between a string that is an email, someones name, and a day of the week. This is not unreasonable. Perhaps some may see this as an oversimplification, but ... If you try and add 10 to Hello in a typed language, you get an error. If you try to do the same in a dynamic language, you get an error. The only difference seems to be that in a dynamic language, you need to *run* the code to get the error, rather than compile it. That said, not all programming errors in a typed language will be found at compile time, so these need to be run anyway to test them. As I understand it, in a dynamic language, if you want to check if a string is an email, you need some function like defn (email? [str]). You'd need the same in a typed language. I've never understood the essential distinction here. (+ 10 Hello) doesn't work in both dynamic or typed languages because, well, 10 and Hello are different *types* of things. Both dynamic and typed languages interpret them as different types. I do understand, however, that typed languages are more difficult to learn and program in, and that the same task can take longer in a typed language. It also seems to me that it is easier to lose the forest for the trees in a typed language. When we speak with each other, we don't generally say The number 6 plus the number 4 equals the number 10. There's a good reason for that. 6 plus 4 equals 10 is not only sufficient, but easier to understand. The incidental complexity that type systems add *can* foster programming errors, even as typed languages are supposed to prevent them. -- -- 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] Public Early Access Program for Cursive, the IntelliJ-based Clojure IDE
Hi everyone, Following on from the discussion a while back about interest in a commercial Clojure IDE, I'm pleased to announce the public Early Access Program for Cursive (http://cursiveclojure.com). Cursive is based on the IntelliJ platform and is mostly written in Clojure. The website is still a little basic but I'm happy to answer any and all questions, and I'm very interested in any feedback. My goal is to make an environment that's both powerful and easy to use, and is easily approachable by people new to Clojure. The almost total lack of documentation is by far the biggest impediment to this right now. Cursive will eventually be available as both a plugin to IntelliJ (either Ultimate or Community) or as a standalone IDE. The current beta is only for the plugin version but it can be used with the free Community edition of IntelliJ as described on the website. It will be commercial at a PyCharm-like price point, and the same licence will work for both the plugin and the IDE version. I'm also probably going to release a free edition of the IDE version that will have slightly restricted functionality and a licence prohibiting commercial work, for use in academic environments or for people to just try Clojure out easily. Many people have helped out with the testing, and I'd like to thank them all for their help and support, they've been great - you know who you are! Cheers, Colin -- -- 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 go about 'proving' why dynamically typed languages are better.
Just bc it's dynamically typed doesn't mean you can't leverage types for dispatch. Remember, you can single dispatch on type (using protocols), or multi-dispatch using a function applied to the arguments (multimethods). --- Joseph Smith j...@uwcreations.com @solussd On Oct 8, 2013, at 7:46 AM, John D. Hume duelin.mark...@gmail.com wrote: On Oct 8, 2013 5:35 AM, Phillip Lord However… I find that I am writing a lot of statements like this: (cond (hash-map? v) …… (vector? v) …… (list? v) ….. :else …..) zcaudate, in what context(s) do you find yourself writing a lot of expressions like that? I rarely want to allow so much flexibility in arguments. I'm wondering if there are idioms to avoid it. I'm not sure a type checker will help in that instance. A type-checker wouldn't no, but a type system would; pretty much every language with a static type system has a type based dispatch somewhere. It would be nice to be able to do (defun fn ([^vector v] ...) ([^list l] ...) ([else] ...) How is Clojure's protocols feature different from what you're describing? -- -- 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 go about 'proving' why dynamically typed languages are better.
On 08/10/13 13:49, Nando Breiter wrote: If you try and add 10 to Hello in a typed language, you get an error. If you try to do the same in a dynamic language, you get an error. Not necessarily... $ perl print 10 + Hello, \n ^D 10 $ Rob -- -- 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 go about 'proving' why dynamically typed languages are better.
2013/10/8 Robert Day robertk...@gmail.com On 08/10/13 13:49, Nando Breiter wrote: If you try and add 10 to Hello in a typed language, you get an error. If you try to do the same in a dynamic language, you get an error. Not necessarily... $ perl print 10 + Hello, \n ^D 10 $ Then don't use Perl :-p -- -- 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] Show the latest version of the library on your Github README page
Have you ever felt annoyed to update the README after you released a new version of your project? Have your users ever struggled to make the older version work because you forgot to update that README? Suffer no more, because Clojars has just the right medicine for you. From now on, you can append */latest-version.svg* to your artefact's link, which will resolve to an image that shows the latest version of your project. Then you can embed this image in your README, or Wiki, or wherever else you like. A couple examples: https://clojars.org/leiningen/latest-version.svg https://clojars.org/com.palletops/pallet-cli/latest-version.svg The only downside of using this feature is that the user can't just select and copy the dependency line anymore. Although Webkit-based browsers support text selection in SVGs (and Firefox's support for one is on the way) it works only when opening the single image, but not when the image is embedded into the page. But I hope it can be worked around somehow in future. Thanks to Nelson Morris and Phil Hagelberg for pushing this 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 go about 'proving' why dynamically typed languages are better
The video will be available sometime in the next couple months. Usually we do keynotes early. No schedule yet (need to get working on that!). The slides are at: https://github.com/strangeloop/StrangeLoop2013/blob/master/slides/sessions/Odersky-TroubleWithTypes.pptx Alex On Tuesday, October 8, 2013 5:32:17 AM UTC-5, Leonardo Borges wrote: There's a link to his presentation there actually: http://www.infoq.com/presentations/data-types-issues?utm_source=infoqutm_medium=QCon_EarlyAccessVideosutm_campaign=StrangeLoop2013 However is says this: *Thank you for attending Strange Loop 2013* This is a restricted presentation that can only be viewed by Strange Loop 2013 attendees! Maybe Alex can comment on whether it's possible for those who didn't attend to watch this video at all. I'd be very keen. Leonardo Borges www.leonardoborges.com On Tue, Oct 8, 2013 at 2:11 AM, gaz jones gareth@gmail.comjavascript: wrote: Martin Odersky gave a keynote at Strangeloop this year called The Trouble With Types ( https://thestrangeloop.com/sessions/the-trouble-with-types) which made me never want to use a type system again (probably the exact opposite of his intention). The video should be coming out on infoq at some point: ( http://www.infoq.com/conferences/strangeloop2013/). I've never looked at Scala before and I'm pretty sure I never will after sitting through that... On Mon, Oct 7, 2013 at 9:26 AM, juan.facorro juan.f...@gmail.comjavascript: wrote: Thanks for the link! I really liked the interview, it was interesting and fun to watch. J On Monday, October 7, 2013 9:49:24 AM UTC+9, brad bowman wrote: zcaudate z...@caudate.me Oct 05 08:35PM -0700 I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell http://www.infoq.com/**interviews/armstrong-peyton-** jones-erlang-haskellhttp://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell This interview covers some of the strong-types vs flexible development (apparent) dichotomy, but in a playful, open and non-dogmatic way. (catmatic?) Simon Peyton Jones is one of the Haskell leaders, yet admits to being envious of type-free generics. Joe Armstrong of Erlang fame also sees the benefit to thinking in and annotating types. These two are both leaders of typed or dynamic cults but have a pleasant friendly and frank conversation about the issues. (Erlang's Dialyzer sounds somewhat like core.typed) A sample: SPJ: So, I've told you what I most envy about Erlang. What do you most envy about Haskell? JA: All the types. I mean they're very nice. I wish we had them. On the other hand, wouldn't you love to have all these generic turn-to-binary, these sort of things? How can you live without them? SPJ: I have a little bit of residual envy about generics. JA: You just take anything and compare it to the serializer and then send it? SPJ: That's sinfully easy, and shouldn't be allowed. So if these two can agree that there's strengths and weaknesses in both approaches, that settles it for me. It's a matter of knowing your trade-offs and choosing your tools appropriately. My suspicion is that type affinity is related to some trait of personality, and so trying to prove superiority is a likely to work as proving you are right in any other clash of personalities. Brad -- -- 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 - 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
Re: Teaching Clojure to students (how ?)
On Tue, Oct 8, 2013 at 11:41 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: Guess you have programmed before. Besides which, if I am teaching any significant number of students, I will get the sys admins to do the installation; otherwise, you the first two weeks, you spend running around fixing peoples environment. This kind of nonsense is soul-destroying for new programmers; it's depressing and saps their desire to learn. Ah, ok. Understood. Point taken. Old programmers know the tricks to get through this quickly (students never believe me when I tell them that they will still be writing hello world in 10 years time); and besides, most old programmers sold their souls years ago. All aside from the confusion that of to start Clojure, type lein. Does that make any sense? Phil To me, this begins to look more like a user interface issue than strictly a programming issue. The folks who do interface design have a technique - pretend it's magic. What would the solution look like if it was magic ( setting all programming considerations aside for the moment) ? The student installs something ... opens something ... and something just works. How would you flesh that out? Aria Media Sagl Via Rompada 40 6987 Caslano Switzerland +41 (0)91 600 9601 +41 (0)76 303 4477 cell skype: ariamedia -- -- 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 go about 'proving' why dynamically typed languages are better.
I think there's a case to be made for a theoretical subjectivity. Mathematical purity is nice and elegant, sometimes useful, but 'useful' refers to utility. The ease or the cost of making some valuable change to code in the possibility-space of changes you might make, and the ramifications of that change are directly proportional to utility. Understanding the theoretical, but discerning the 'useful' is what makes an engineer effective, and that's the difference between an engineer and a theoretical computer scientist. I can say objectively that clojure is useful, because programs are read and languages are worked in subjectively by subjective humans, and I find it more useful than other things. That's at least a statistical measure (mathematicians frown on statistics too? Statistics are definitely useful, as anyone with a working cell phone should appreciate). If there's a theory that I could explore more to make a case, it would be one of cognitive load, mental 'overhead', and the convenience of removing classes of worries (say, action at a distance), letting you reason about your program in side-effect-free chunks. The easier it is to draw lines around chunks of your program, or the lower the time/effort cost of changing code to make the first easier, the less benefit there is to be had in types/contracts, in my opinion. Practical engineering is about the economics of the process, and it's about how our tools plus outside constraints limit our solutions. Mathy guys value 'objectivity', as that's the accepted social currency that's ingrained in techies. Clojure has a rich/proven heritage and a coherent/enabling design, and programs are written and read by people, so I think it's ok to admit that the subjective is 'useful' when there's enough objective common ground. We will be the most persuasive when we understand the theory and point of view of the other side of the argument, and we can effectively engage in the economics of that kind of reasoning. On Tue, Oct 8, 2013 at 1:46 AM, Jason Lewis ja...@decomplecting.org wrote: I think what you're banging your head against is the tension between computer science qua pure science, versus software engineering qua engineering practice. This tension isn't unique to our field; mathematicians look down on theoretical physicists, who look down on practical physicists, who look down on engineers, all the way down to the humanities, who are generally ignored. Or, to summarize: http://imgs.xkcd.com/comics/purity.png So, sure, from a theroetical standpoint, oriented toward proofs and provable correctness, type systems are superior. OTOH, for practicing software engineers, who care more about reliably and efficiently *building shit,* language flexibility is a massive boon, and we compensate for the lack of provable correctness with strategies like TDD. I agree w/ Laurent; it's not a black/white issue... to me it's more apples and oranges, dispatching on intent. Are you trying to prove a theorem, or build software? Not that you can't build scalable web services in Haskell, but I don't know anyone within a standard deviation of sanity who has ever done so for production code. The beauty of Clojure is that it gives us the ability to create realiable, robust, real-world solutions without sacrificing elegance; not because it's dynamically typed or because it has an optional type system (although both of those aspects are great), but because it combines power and simplicity. Holy wars are fun for a while (if I wanted to start one on this list, I'd go into the superiority of vim over emacs), but if your real goal is building things, you gotta let them go, and when people start heckling the fact that Clojure doesn't implement Hindley-Milner type inference... just shrug, point to the reliable, scalable architecture you built in two weeks, and get back to work. Just my US$0.02. Jason On Tuesday, October 8, 2013 12:46:41 AM UTC-4, zcaudate wrote: Hahaha, thanks Philip. Does it really take a doctorate to understand classification of elephants? I think the overall consensus is that having basic type checking is good... but over doing types is bad. Would this be a reasonable guideline for using types? 1. Types are useful for structures that HOLD data (ints, strings, maps, arrays… ) because they provide ways defining standard operations to manipulate data that make sense in the context of that type of data. It is helpful to have a type checker check that I am not accessing the 6th element of a hashmap or that I am adding 10 to Hello. 2. When a particular data-structure is sufficient for holding information, then its better to just use the data-structure because we have so many generic operations predefined. For example, if I have to model customers in a line. I wouldn't have type CUSTOMER and type LINE. I would just represent this as a QUEUE of MAPS…. However… I find that I am
Re: [ANN] mod-lang-clojure for Vert.x 0.2.0 released
Hans-J.: I haven't yet had a chance to try out Stream's ring adapter, but I hope to do so soon. I think it should probably be published as a jar for embedded use, and as a Vert.x module that depends on that jar for use in a Vert.x container. Can you file against the ring adapter[1] asking for a release? Isaiah Peng and I are currently working on a lein plugin[2] that should make working with lein-based Vert.x projects easier. It will include support for specifying Vert.x module dependencies in project.clj, but isn't quite there yet. If running Vert.x apps with lein is something that interests you, we'd love some help :) [1]: https://github.com/stream1984/ring-vertx-adapter/issues [2]: https://github.com/isaiah/lein-vertx Hans-J. Schmid writes: Hi Toby, would it be possible to have the ring-vertx-adapter as a jar that we can include as a dependency in our Clojure projects? Couldn't find anything on Clojars or Maven and the sample code uses embedded vertx. Kind regards, Hans-J. On Wednesday, September 18, 2013 1:49:38 PM UTC+2, Toby Crawley wrote: Josh Kamau writes: Does this have the ring adapter bundled in ? No, the ring adapter is a separate project (https://github.com/stream1984/ring-vertx-adapter), and will likely remain so. -- Toby Crawley http://immutant.org | http://torquebox.org -- -- Toby Crawley http://immutant.org | http://torquebox.org -- -- 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 go about 'proving' why dynamically typed languages are better.
John D. Hume duelin.mark...@gmail.com writes: On Oct 8, 2013 5:35 AM, Phillip Lord I'm not sure a type checker will help in that instance. A type-checker wouldn't no, but a type system would; pretty much every language with a static type system has a type based dispatch somewhere. It would be nice to be able to do (defun fn ([^vector v] ...) ([^list l] ...) ([else] ...) How is Clojure's protocols feature different from what you're describing? Yeah, I picked a bad example, following on from the previous. I was thinking where the classes are defined in Java and there are several of them -- class based overloading in otherwords. Phil -- -- 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 go about 'proving' why dynamically typed languages are better.
Short comment in bad English: I found that TDD is the great equalizer btw dynamic and static languages. I don't have any trouble writing code in dynamic language wo/code completion, etc.. if I wrote baby steps using TDD. And then, the dynamic nature (less ceremony, etc...) starts to shine. I use typed language for performance reasons. Angel Java Lopez @ajlopez On Tue, Oct 8, 2013 at 11:48 AM, Phillip Lord phillip.l...@newcastle.ac.ukwrote: John D. Hume duelin.mark...@gmail.com writes: On Oct 8, 2013 5:35 AM, Phillip Lord I'm not sure a type checker will help in that instance. A type-checker wouldn't no, but a type system would; pretty much every language with a static type system has a type based dispatch somewhere. It would be nice to be able to do (defun fn ([^vector v] ...) ([^list l] ...) ([else] ...) How is Clojure's protocols feature different from what you're describing? Yeah, I picked a bad example, following on from the previous. I was thinking where the classes are defined in Java and there are several of them -- class based overloading in otherwords. Phil -- -- 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 go about 'proving' why dynamically typed languages are better.
Nando Breiter na...@aria-media.com writes: 1. Types are useful for structures that HOLD data (ints, strings, maps, arrays… ) because they provide ways defining standard operations to manipulate data that make sense in the context of that type of data. It is helpful to have a type checker check that I am not accessing the 6th element of a hashmap or that I am adding 10 to Hello. This would be useful indeed. Although, a hard core type head would say I want to distinguish between a string that is an email, someones name, and a day of the week. This is not unreasonable. Perhaps some may see this as an oversimplification, but ... If you try and add 10 to Hello in a typed language, you get an error. If you try to do the same in a dynamic language, you get an error. This depends on the type coercions which are available, rather than the static/dynamic type system divide. echo print 10 + 10 | perl 20 for instance. The only difference seems to be that in a dynamic language, you need to *run* the code to get the error, rather than compile it. This is a big difference, especially, if the code is hard to test. As I understand it, in a dynamic language, if you want to check if a string is an email, you need some function like defn (email? [str]). You'd need the same in a typed language. To a first approximation, yes, but once you have constructed an email type, and got a value into that type, then in a strongly typed language, you know that you have an email. You cannot accidentally pass a string which is not an email by mistake. I do understand, however, that typed languages are more difficult to learn and program in, and that the same task can take longer in a typed language. I think learn is true. The second conclusion I think is wrong. The joyful experience of passing a map of lists when you were expecting a map of sets, or typing a keyword wrong happens to most people; and it can take a long, long time to find out where. It also seems to me that it is easier to lose the forest for the trees in a typed language. When we speak with each other, we don't generally say The number 6 plus the number 4 equals the number 10. There's a good reason for that. 6 plus 4 equals 10 is not only sufficient, but easier to understand. Hmmm. So when you are teaching programming to beginers and you try to explain why 20 + 20 crashes, how do you describe in, using the terms that you find sufficient? The incidental complexity that type systems add *can* foster programming errors, even as typed languages are supposed to prevent them. This hasn't been my experience; I do sometimes find that it take take so longer to shut the damn compiler up and just have it do what I know will work that it's not worth the effort. Phil -- -- 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 go about 'proving' why dynamically typed languages are better.
I am now allergic to integrated type systems mostly because of the lack of efficiency that they impose, at least in my world. If I can spare some time, I would like to immerse myself in Haskell to see if I can cope with its type system on a daily basis. Still I would think twice before switching to a language that imposes one on me again. Clojure.type looks to me reasonable because it's optional and annotations have no effect on the running code. My academic track record is thin, I always preferred to deliver projects than work on academic studies and this taints my opinion. I do not reject academic thinking, it's needed at some point to create new foundations for practical applications. Clojure is a good example of this interaction. However I am always cautious about debates like this vs real life project comparisons, like any tool they are limits to what theory can prove. Program correctness has been in their air for several decades however in real projects, its applicability has been scarce to non-existent. I know of a Swiss engineer that was building bridges using concrete and none of his designs could be proven by mathematical models in his lifetime. He was using 1/3 of the concrete is competitors were using... Is bridge designs are elegant and sophisiticated. I think there is still a huge gap between academic thinking and real life software projects in general. This is not a criticisim, theory as to lead practical applications, however proofing has to be based on facts otherwise discussions are circling around. A solid basis for a real debate would require some extensive survey of software projects and maintenance with a number of facets (cost, timeline, #bugs, language used, ) Luc P. I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. BTW... This is no means a criticism of all the type system work that is going on in the clojure community. I am a huge fan of Ambrose's Typed Clojure project because it gives me the *option *of using types... not shoving it down my throat. I like the freedom to choose. My experience of programming in clojure has freed me from thinking about types and hierarchies and this article rings so true: http://steve.yegge.googlepages.com/is-weak-typing-strong-enough. However, everywhere I look, there are smug type-weenies telling me that my dynamically typed program is bad because it cannot be `proven correct` and not `checked by the compiler`. This question on SO really makes me angry http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages because no one is defending dynamic languages on there. The reason is very simple. because we don`t have a theory to back us up! I do want to put up an counter argument against this barrage of abuse against dynamic languages. And I want to put some academic weight behind this. The only counter I could come up with was to use Godel's incompleteness theorem. For those that don't know... here is an introduction to the man and his theory. http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, invalidated Principia Mathematica as a complete system of description. Principia Mathematica btw effectively led to Type Theory. According to http://en.wikipedia.org/wiki/Type_theory. The types of type theory were invented by Bertrand Russell in response to his discovery that Gottlob Frege's version of naive set theory was afflicted with Russell's paradox. This theory of types features prominently in Whitehead and Russell's Principia Mathematica. It avoids Russell's paradox by first creating a hierarchy of types, then assigning each mathematical (and possibly other) entity to a type. Objects of a given type are built exclusively from objects of preceding types (those lower in the hierarchy), thus preventing loops. I'm hoping to collect a few more `proofs` from the clojure community... for example... if there is a paper on why are type systems so bad at classifying animals... then please forward it on. -- -- 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
Re: How to go about 'proving' why dynamically typed languages are better.
On Tuesday, October 8, 2013 6:26:20 AM UTC-4, Paul Butcher wrote: The best explanation of these misunderstandings I've come across is What to Know Before Debating Type Systems: http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/ In particular it asserts (correctly in my view) that what static type system proponents mean by type and what dynamic type system proponents mean by type are very different things. Most debates founder on a failure to recognise that difference. -- paul.butcher-msgCount++ Thanks for that link, it's a pretty good article. No amount of proof is going to make your software ironclad. You could start the program, but the operating system only has half as much memory available as it requires. Your network connection could be down. The database could be off, or someone could have changed the user account password. The configuration file could be corrupted. The SQL statement in your code (or properties file, or whatever) could have a spelling error. You could have a dependency on a library with an undiscovered bug. We take for granted that outside of our programs' specific internals, the rest of the world can go insane, break our software completely, and there's nothing we can do but try to detect the error early and fail gracefully. I like the Scala language, but even if you push its static type system to its limits, it's like building a house with invincible walls on one side - you better hope the tornado winds all blow from that direction, because otherwise you're in just as much trouble as the people living in a lean-to. But back to practicality - Ebay was originally written in Perl. Myspace was written in ColdFusion. Facebook was written mostly in PHP. Youtube was written in Python. Twitter was writtin in Ruby. Most of the tools around KVM virtualization in the Linux kernel are written in Python. Slashdot was written in Perl. Of course most or all of these sites had to do extra work once they were dealing with a massive volume of traffic, but how many of us have that problem? When I'm making a million dollars a month and programming language X has some fundamental aspect that prevents better scaling, I'll look into languages with better performance. But I see the state of the modern web as proof enough that non-static type systems work just fine for an overwhelming number of use cases. -Mike -- -- 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] mod-lang-clojure for Vert.x 0.2.0 released
Hi Toby, thanks for the info. I was actually in contact with Stream Liu and he made an update to the project on https://github.com/stream1984/ring-vertx-adapter. It stills needs some polishing according to Stream (refering to the project page: It is very common that run project of clojure with repl in lein, But i have not yet enough time to make a plugin to wrap vert.x's clojure as a module in lein.) But so far the adapter is very usable for me now. Thanks for your support. Hans-J. On Tuesday, October 8, 2013 4:34:04 PM UTC+2, Toby Crawley wrote: Hans-J.: I haven't yet had a chance to try out Stream's ring adapter, but I hope to do so soon. I think it should probably be published as a jar for embedded use, and as a Vert.x module that depends on that jar for use in a Vert.x container. Can you file against the ring adapter[1] asking for a release? Isaiah Peng and I are currently working on a lein plugin[2] that should make working with lein-based Vert.x projects easier. It will include support for specifying Vert.x module dependencies in project.clj, but isn't quite there yet. If running Vert.x apps with lein is something that interests you, we'd love some help :) [1]: https://github.com/stream1984/ring-vertx-adapter/issues [2]: https://github.com/isaiah/lein-vertx Hans-J. Schmid writes: Hi Toby, would it be possible to have the ring-vertx-adapter as a jar that we can include as a dependency in our Clojure projects? Couldn't find anything on Clojars or Maven and the sample code uses embedded vertx. Kind regards, Hans-J. On Wednesday, September 18, 2013 1:49:38 PM UTC+2, Toby Crawley wrote: Josh Kamau writes: Does this have the ring adapter bundled in ? No, the ring adapter is a separate project (https://github.com/stream1984/ring-vertx-adapter), and will likely remain so. -- Toby Crawley http://immutant.org | http://torquebox.org -- -- Toby Crawley http://immutant.org | http://torquebox.org -- -- 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 go about 'proving' why dynamically typed languages are better.
Laurent PETIT laurent.pe...@gmail.com writes: print 10 + Hello, \n ^D 10 $ Then don't use Perl :-p PHP does the same thing and it's really useful. We all think that the ability to build DSLs in Clojure is good; ultimately, what this means is that we think that good language behaviour is domain specific. For webpages, I think this kind of coercion can be good. It would be easy to get Clojure to behave in the PHP way, while it is rather harder to stop PHP from doing this. Phil -- -- 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: Teaching Clojure to students (how ?)
On Oct 8, 2013, at 8:47 AM, Jernau wrote: Hi Phil, It was I (Lee) who posted those reactions, but hi and thanks! 1. Select the text you want auto-indented and press SHIFT+TAB. Nice. Is this (re)discoverable somehow from the interface? 2. The documentation tab opens in a new tabset - to close tabsets you right-click on them and choose 'Close tabset'. Okay. Now that I see it. I guess I should right-click on things more to discover stuff in the future. 3. I haven't discovered a way to disable auto-brackets. Unfortunate. I realize I may be unusual in this respect, but this will probably keep me from using it in any serious way. 4. Yes, you can access it from the command pane, or you can add a key-binding in your user.keymap. I have mine set to CMD+; with pmeta-; [:toggle-comment-selection]. Ah. I see, and while it didn't work with the commenting style I was using I think it's fine. I haven't done the key binding yet but I think I see how to do that. 5. Won't you need to copy+paste from the console anyway? Why not just grab the part without the filename? Yes, but I will typically generate outputs from many separate calls to println. I'll want to grab all and only what I asked to have printed, and the only way to do that now will come along with a filename on every line, which I'll then have to remove in post processing. Not impossible but a pain and I don't see why it helps to clutter up the output like that. In general, if you're running your code to produce console output then you probably want the output that you asked to be printed, without extra stuff. 6. Currently you make projects externally (using Leiningen) and then import them into Light Table. I think that's fine, but it could be more obvious that this is what you have to do. You can make files without projects, which is a little odd in the first place, but not projects... 7. This is one downside to having an IDE that's written in Clojure. Maybe it's unavoidable, but I would have thought that one JVM instance could be running the IDE and another the user's code, with different versions of Clojure if necessary. But maybe that's more complicated than I would have thought. 8. You can hide evaluations using the command pane and Eval: Clear inline results, or you can add a key-binding in your user.keymap. I have mine set to CMD+SHIFT+BACKSPACE pmeta-shift-backspace [:clear-inline-results] Seems reasonable. Again, I wonder if this could be more easily discoverable (a go away X next to the result?), but I see that it's workable. 9. I don't think Light Table has this feature yet. Understood. FWIW, this is another pretty important one for me and my students. I never remember argument list order, etc., and I've long relied on Lisp environments unobtrusively reminding me of them as I type. It's worth noting that Light Table is still in the early stages of development, so it doesn't have all of the features of more mature IDEs. However, Chris is going to add plugin support in the next major release, which will remove him as the bottleneck for adding exactly the kind of features you're looking for. I think it's a very exciting time for Light Table. Sounds great. I appreciate that it's early days. I'm just providing this feedback in case it helps. And FYI, in light of the clarifications in your reply, I'd be quite likely to switch my teaching and research to LightTable if/when #3, #5, and #9 are addressed (ability to turn off auto-brackets, get unadorned console output, and some form of dynamic arglist info). Thanks so much, -Lee Cheers, James On Tuesday, October 8, 2013 12:00:52 AM UTC+2, Lee wrote: Hi James, I have indeed tried LightTable, and it does indeed seem promising. Really exciting potential. But I've hit enough snags every time I've tried it that I haven't really found it useful (either for teaching or for my own use). I just tried the latest version again, just now, and just for anyone who may care here are my (opinionated, and YMMV) reactions: 1. Is there auto-reindentation? I don't see it. Pretty essential, IMHO. 2. I can close a tab (like the documentation) if I control-click on it, but the pane remains... and I've ended up with lots of panes that I have to quit to get rid of. In general I love the look of the GUI but wish the controls were more obvious/standard in many cases. 3. Can automatic bracket insertion be turned off? It's problematic in my book, especially for newcomers who should be allowed to use the keyboarding skills that they already have. 4. Is there a block comment/uncomment feature? 5. The console output precedes every line with the file that generated it, which means that you can't get a clean output log. Lots of the code that I and my students write is oriented toward producing textual output in the console, and this sort of rules out those uses (unless you want to clean up the
Re: Teaching Clojure to students (how ?)
On Monday, October 7, 2013 8:12:05 PM UTC-7, John Gabriele wrote:
For new users who want to get their feet wet right on the first day, I'd
suggest this (after they make sure they've got Java installed):
#. Download `lein`, drop it into your ~/bin, and `chmod +x` it if
necessary,
#. `lein version` (so it installs and thus creates ~/.lein directory (see
next step))
#. `touch ~/.lein/profiles.clj`, and into that file put `{:user {:plugins
[[lein-exec 0.3.1]]}}` (or whatever the current version of [lein-exec] is
when you're reading this. :)
You don't need a plugin for that actually:
$ lein run -m clojure.main/main -i foo.clj
Maybe a shell alias or lein alias would be more convenient though.
-Phil
--
--
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.
Can I use transactions in go block?
Looks like it doesn't work. (go (dosync (ref-set aaa 1))) -- -- 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: Can I use transactions in go block?
Use the latest snapshot from github, I pushed a change last Friday that fixed this. Note though, ! won't work inside a dosync, and shouldn't be done anyways, since it's not transaction safe (hence the ! in the name). But the example you gave works fine with the latest code from master. Timothy On Tue, Oct 8, 2013 at 11:05 AM, Gary Zhao garyz...@gmail.com wrote: Looks like it doesn't work. (go (dosync (ref-set aaa 1))) -- -- 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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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 Neocons 2.0.0-beta2 is released
Neocons [1] is a Clojure Neo4J Server client. Version 2.0 targets development milestones of Neo4J 2.0 and introduces new features. Release notes: http://blog.clojurewerkz.org/blog/2013/10/08/neocons-2-dot-0-0-beta2-is-released/ -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- 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 Elastisch 1.3.0-beta4 is released
Elastisch [1] is a minimalistic Clojure client for ElasticSearch. 1.3.0-beta4 fixes a bug in date histogram in the native client. Release notes: http://blog.clojurewerkz.org/blog/2013/10/08/elastisch-1-dot-3-0-beta4-is-released/ 1. http://clojureelasticsearch.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- 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 Langohr 1.6.0-beta1
Langohr [1] is a Clojure client for RabbitMQ. 1.6.0-beta1 introduces automatic connection recovery improvements. Release notes: http://blog.clojurewerkz.org/blog/2013/10/08/langohr-1-dot-6-0-beta1-is-released/ 1. http://clojurerabbitmq.info -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- 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: Can I use transactions in go block?
Thanks. On Tuesday, October 8, 2013 10:12:30 AM UTC-7, tbc++ wrote: Use the latest snapshot from github, I pushed a change last Friday that fixed this. Note though, ! won't work inside a dosync, and shouldn't be done anyways, since it's not transaction safe (hence the ! in the name). But the example you gave works fine with the latest code from master. Timothy On Tue, Oct 8, 2013 at 11:05 AM, Gary Zhao gary...@gmail.comjavascript: wrote: Looks like it doesn't work. (go (dosync (ref-set aaa 1))) -- -- 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. -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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 go about 'proving' why dynamically typed languages are better.
js Array(16).join(wat - 1) + Batman! NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman! js On Tuesday, October 8, 2013 6:07:47 AM UTC-7, Laurent PETIT wrote: 2013/10/8 Robert Day rober...@gmail.com javascript: On 08/10/13 13:49, Nando Breiter wrote: If you try and add 10 to Hello in a typed language, you get an error. If you try to do the same in a dynamic language, you get an error. Not necessarily... $ perl print 10 + Hello, \n ^D 10 $ Then don't use Perl :-p -- -- 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] mod-lang-clojure for Vert.x 0.2.0 released
Hi Guys; For me, the eventbus is the killer feature in Vertx. I think there will be many developers who would like to embed vertx into into their existing applications to enable 'realtime' communication with the browser via the eventbus. I would love to be able to do this as easily as possible. Otherwise i appreciate the work done so far. Josh On Tue, Oct 8, 2013 at 6:37 PM, Hans-J. Schmid hans-j.sch...@hans-jschmid.com wrote: Hi Toby, thanks for the info. I was actually in contact with Stream Liu and he made an update to the project on https://github.com/stream1984/ring-vertx-adapter. It stills needs some polishing according to Stream (refering to the project page: It is very common that run project of clojure with repl in lein, But i have not yet enough time to make a plugin to wrap vert.x's clojure as a module in lein.) But so far the adapter is very usable for me now. Thanks for your support. Hans-J. On Tuesday, October 8, 2013 4:34:04 PM UTC+2, Toby Crawley wrote: Hans-J.: I haven't yet had a chance to try out Stream's ring adapter, but I hope to do so soon. I think it should probably be published as a jar for embedded use, and as a Vert.x module that depends on that jar for use in a Vert.x container. Can you file against the ring adapter[1] asking for a release? Isaiah Peng and I are currently working on a lein plugin[2] that should make working with lein-based Vert.x projects easier. It will include support for specifying Vert.x module dependencies in project.clj, but isn't quite there yet. If running Vert.x apps with lein is something that interests you, we'd love some help :) [1]: https://github.com/stream1984/**ring-vertx-adapter/issueshttps://github.com/stream1984/ring-vertx-adapter/issues [2]: https://github.com/isaiah/**lein-vertxhttps://github.com/isaiah/lein-vertx Hans-J. Schmid writes: Hi Toby, would it be possible to have the ring-vertx-adapter as a jar that we can include as a dependency in our Clojure projects? Couldn't find anything on Clojars or Maven and the sample code uses embedded vertx. Kind regards, Hans-J. On Wednesday, September 18, 2013 1:49:38 PM UTC+2, Toby Crawley wrote: Josh Kamau writes: Does this have the ring adapter bundled in ? No, the ring adapter is a separate project (https://github.com/**stream1984/ring-vertx-adapterhttps://github.com/stream1984/ring-vertx-adapter )**, and will likely remain so. -- Toby Crawley http://immutant.org | http://torquebox.org -- -- Toby Crawley http://immutant.org | http://torquebox.org -- -- 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] Public Early Access Program for Cursive, the IntelliJ-based Clojure IDE
Congratulations! EAP looks promising - its already much better than La Clojure. I don't know if this is intentionally done so, or is it some problem with Windows or whatever, but local nREPL session doesn't display current namespace which is very helpful of course. I had to use *ns* occasionaly to recall where I am. Anyway, great work. -Vjeran -- -- 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 go about 'proving' why dynamically typed languages are better.
2013/10/8 Greg Bowyer gbow...@fastmail.co.uk js Array(16).join(wat - 1) + Batman! NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman! js One of the many reasons we're using Clojurescript and not raw javascript :-) On Tuesday, October 8, 2013 6:07:47 AM UTC-7, Laurent PETIT wrote: 2013/10/8 Robert Day rober...@gmail.com On 08/10/13 13:49, Nando Breiter wrote: If you try and add 10 to Hello in a typed language, you get an error. If you try to do the same in a dynamic language, you get an error. Not necessarily... $ perl print 10 + Hello, \n ^D 10 $ Then don't use Perl :-p -- -- 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: Teaching Clojure to students (how ?)
On Tue, Oct 8, 2013 at 12:30 PM, Lee Spector lspec...@hampshire.edu wrote: 7. This is one downside to having an IDE that's written in Clojure. Maybe it's unavoidable, but I would have thought that one JVM instance could be running the IDE and another the user's code, with different versions of Clojure if necessary. But maybe that's more complicated than I would have thought. It can't be *too* complicated, because recent versions of clooj do it. Indeed you can even kill -9 a hung REPL process and start a fresh one from your open clooj window, without clooj bombing out (the REPL pane will note that the REPL got disconnected, and almost anything you do will restart it in the namespace you're working in. You'll keep history memory (ctrl-uparrow stuff) but need to reload any code and reenter any stuff you did at the REPL to define vars. And avoid whatever hung your REPL before, such as triggering an infinite loop.) -- -- 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 go about 'proving' why dynamically typed languages are better.
On Tue, Oct 8, 2013 at 8:49 AM, Nando Breiter na...@aria-media.com wrote:
If you try and add 10 to Hello in a typed language, you get an error.
Interesting. I hadn't realized that the following's language was not typed:
package foo.bar;
public class Main {
public static void main (String[] args) {
System.out.println(Hello + 10);
}
}
% javac Main.java
% java foo.bar.Main
Hello10
%
:)
--
--
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: Cut down uberjar size
You can use a regex to exclude files from uberjars, see the leiningen sample file and the :uberjar-exclusions key ;; Files with names matching any of these patterns will be excluded from jars. :jar-exclusions [#(?:^|/).svn/] ;; Same thing, but for uberjars. :uberjar-exclusions [#META-INF/DUMMY.SF] hope that helps On Tue, Oct 8, 2013 at 5:56 AM, Ruslan Prokopchuk fer.ob...@gmail.com wrote: What are the best practices to cut down uberjar size? Is it able to automagically :exclude from project unused parts dependencies of big libraries, and will it affect on uberjar size? -- -- 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 go about 'proving' why dynamically typed languages are better.
On Tuesday, October 8, 2013 10:19:07 PM UTC+3, Laurent PETIT wrote: 2013/10/8 Greg Bowyer gbo...@fastmail.co.uk javascript: js Array(16).join(wat - 1) + Batman! NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaN Batman! js One of the many reasons we're using Clojurescript and not raw javascript :-) ClojureScript is an improvement, no doubt about that! But javascript idiosyncrasies does leak through on occasion: http://cljsfiddle.net/fiddle/jonase.batman On Tuesday, October 8, 2013 6:07:47 AM UTC-7, Laurent PETIT wrote: 2013/10/8 Robert Day rober...@gmail.com On 08/10/13 13:49, Nando Breiter wrote: If you try and add 10 to Hello in a typed language, you get an error. If you try to do the same in a dynamic language, you get an error. Not necessarily... $ perl print 10 + Hello, \n ^D 10 $ Then don't use Perl :-p -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.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: How to go about 'proving' why dynamically typed languages are better.
The string concatenation operator in java calls 'toString' on it's args.
---
Joseph Smith
j...@uwcreations.com
@solussd
On Oct 8, 2013, at 2:29 PM, Cedric Greevey cgree...@gmail.com wrote:
On Tue, Oct 8, 2013 at 8:49 AM, Nando Breiter na...@aria-media.com wrote:
If you try and add 10 to Hello in a typed language, you get an error.
Interesting. I hadn't realized that the following's language was not typed:
package foo.bar;
public class Main {
public static void main (String[] args) {
System.out.println(Hello + 10);
}
}
% javac Main.java
% java foo.bar.Main
Hello10
%
:)
--
--
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] Public Early Access Program for Cursive, the IntelliJ-based Clojure IDE
Hi Vjeran, Thanks! I'm glad you're liking it. The namespace in the current REPL is displayed at the top of the window, in the REPL tab name. Cheers, Colin On 9 October 2013 07:52, vmarci...@gmail.com wrote: Congratulations! EAP looks promising - its already much better than La Clojure. I don't know if this is intentionally done so, or is it some problem with Windows or whatever, but local nREPL session doesn't display current namespace which is very helpful of course. I had to use *ns* occasionaly to recall where I am. Anyway, great work. -Vjeran -- -- 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: Teaching Clojure to students (how ?)
Right, there should be no problem doing this - pretty much all the editors/IDEs out there start an external process for the REPL server, and it should be able to use any Clojure version you like, independently of the version used by the IDE itself. On 9 October 2013 08:21, Cedric Greevey cgree...@gmail.com wrote: On Tue, Oct 8, 2013 at 12:30 PM, Lee Spector lspec...@hampshire.eduwrote: 7. This is one downside to having an IDE that's written in Clojure. Maybe it's unavoidable, but I would have thought that one JVM instance could be running the IDE and another the user's code, with different versions of Clojure if necessary. But maybe that's more complicated than I would have thought. It can't be *too* complicated, because recent versions of clooj do it. Indeed you can even kill -9 a hung REPL process and start a fresh one from your open clooj window, without clooj bombing out (the REPL pane will note that the REPL got disconnected, and almost anything you do will restart it in the namespace you're working in. You'll keep history memory (ctrl-uparrow stuff) but need to reload any code and reenter any stuff you did at the REPL to define vars. And avoid whatever hung your REPL before, such as triggering an infinite loop.) -- -- 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 go about 'proving' why dynamically typed languages are better.
Hopefully, we all knew it :))
And you should add that auto boxing
Is done on the literal, otherwise this
magic would not work.
Otherwise, Java would be the most
brittled language.
It probably is anyway :))
Luc P..
The string concatenation operator in java calls 'toString' on it's args.
---
Joseph Smith
j...@uwcreations.com
@solussd
On Oct 8, 2013, at 2:29 PM, Cedric Greevey cgree...@gmail.com wrote:
On Tue, Oct 8, 2013 at 8:49 AM, Nando Breiter na...@aria-media.com wrote:
If you try and add 10 to Hello in a typed language, you get an error.
Interesting. I hadn't realized that the following's language was not typed:
package foo.bar;
public class Main {
public static void main (String[] args) {
System.out.println(Hello + 10);
}
}
% javac Main.java
% java foo.bar.Main
Hello10
%
:)
--
--
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.
--
Luc Prefontainelprefonta...@softaddicts.ca sent by ibisMail!
--
--
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 go about 'proving' why dynamically typed languages are better.
Holy wars are fun for a while (if I wanted to start one on this list, I'd go into the superiority of vim over emacs), It wasn't me =) Don't get me wrong, I'm not ANTI-type. I'm ANTI-ANTI-untype… which is a much more partial position to take =) On 08/10/2013, at 11:46 PM, John D. Hume duelin.mark...@gmail.com wrote: (cond (hash-map? v) …… (vector? v) …… (list? v) ….. :else …..) zcaudate, in what context(s) do you find yourself writing a lot of expressions like that? I rarely want to allow so much flexibility in arguments. I'm wondering if there are idioms to avoid it. I do it for operator overloading/syntactic sugar…. http://z.caudate.me/ova/#indices-selection Also, they are quite useful for macros… https://github.com/zcaudate/purnam As well as custom representation of data and also for traversing nested maps… https://github.com/zcaudate/adi --- Chris. -- -- 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 go about 'proving' why dynamically typed languages are better.
I have another question re types…. I find it hard to express the absence of properties…. Like in Haskell… if you want to display something.. you have to derive Show for that object… which I think is allowing .toString to work Wouldn't it be more helpful to have a type Unshow which stops the object from being shown? There are some things that are universal and it is the absence of that which is unique. Is there a way to model this with types? On 09/10/2013, at 7:58 AM, Joe Smith j...@uwcreations.com wrote: The string concatenation operator in java calls 'toString' on it's args. --- Joseph Smith j...@uwcreations.com @solussd -- -- 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 Report: CinC, port of the clojure compiler in clojure
I don't think that's what Mike was talking about. Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an public long invokePrim() method. When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim instead of invoke. If we redefine (defn x [] ) then y won't work because the new version of x doesn't implement IFn$L, we'd need to recompile y too. Mikhail Kryshen writes: Mikera mike.r.anderson...@gmail.com writes: 2) This in turn means we are going to have to recompile if we want to retain any sort of dynamic behaviour. The current system of independently mutable vars won't work (for obvious reasons: changing a var could easily violate the previous type inference assumptions) The HotSpot JIT compiler already performs adaptive optimization based on runtime profile and dynamicaly recompiles bytecode when necessary. The problem is the way Clojure calls functions through vars is not transparent to the compiler's optimizer. Invokedynamic can help here, see http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html -- -- 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 go about 'proving' why dynamically typed languages are better.
Some things that I see most of the time when I read debates about dynamic vs static are: 1. Statically defined types don't solve everything, so they are not useful. Some help is better than no help even if the help doesn't solve all of your problems. Yes, you should wash your hands before dinner, even though we are all going to die in the end anyway. 2. I like static typing as long as it is optional In the case where the point of using statically defined types is to have a compiler catch problems instead of you needing to predict their occurrence then static typing would have to be non-optional. 3. You don't need the compiler to warn you about types, because you can write tests. A difficult problem is one that occurs on a rare occasion in some place that you would not have thought to check. So, you can't expect to be able to catch them with tests. If the problem is one that would have been flagged as a compile-time error, then in that case it would have been useful to have been using static typing. I am still unsure. It seems likely that the usefulness of statically defined types would depend upon the application. When using statically defined types makes development slower to an extent that outways the benefit, then it is bad. If faster initial development as a result of dynamic typing ultimately ends up taking more time because of problems that would have been caught by a compiler, then it is bad. If statically defined typing makes you not discover things you would have because of the overhead of dealing with the static typing, then that is bad. Kendall On 10/05/2013 08:35 PM, zcaudate wrote: I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. BTW... This is no means a criticism of all the type system work that is going on in the clojure community. I am a huge fan of Ambrose's Typed Clojure project because it gives me the *option *of using types... not shoving it down my throat. I like the freedom to choose. My experience of programming in clojure has freed me from thinking about types and hierarchies and this article rings so true: http://steve.yegge.googlepages.com/is-weak-typing-strong-enough. However, everywhere I look, there are smug type-weenies telling me that my dynamically typed program is bad because it cannot be `proven correct` and not `checked by the compiler`. This question on SO really makes me angry http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages because no one is defending dynamic languages on there. The reason is very simple. because we don`t have a theory to back us up! I do want to put up an counter argument against this barrage of abuse against dynamic languages. And I want to put some academic weight behind this. The only counter I could come up with was to use Godel's incompleteness theorem. For those that don't know... here is an introduction to the man and his theory. http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, invalidated Principia Mathematica as a complete system of description. Principia Mathematica btw effectively led to Type Theory. According to http://en.wikipedia.org/wiki/Type_theory. The types of type theory were invented by Bertrand Russell in response to his discovery that Gottlob Frege's version of naive set theory was afflicted with Russell's paradox. This theory of types features prominently in Whitehead and Russell's Principia Mathematica. It avoids Russell's paradox by first creating a hierarchy of types, then assigning each mathematical (and possibly other) entity to a type. Objects of a given type are built exclusively from objects of preceding types (those lower in the hierarchy), thus preventing loops. I'm hoping to collect a few more `proofs` from the clojure community... for example... if there is a paper on why are type systems so bad at classifying animals... then please forward it on. -- -- 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
Re: How to go about 'proving' why dynamically typed languages are better.
This is Clojure- we can have both, at the same time! clojure.core.typed --- Joseph Smith j...@uwcreations.com @solussd On Oct 8, 2013, at 5:36 PM, Kendall Shaw ks...@kendallshaw.com wrote: Some things that I see most of the time when I read debates about dynamic vs static are: 1. Statically defined types don't solve everything, so they are not useful. Some help is better than no help even if the help doesn't solve all of your problems. Yes, you should wash your hands before dinner, even though we are all going to die in the end anyway. 2. I like static typing as long as it is optional In the case where the point of using statically defined types is to have a compiler catch problems instead of you needing to predict their occurrence then static typing would have to be non-optional. 3. You don't need the compiler to warn you about types, because you can write tests. A difficult problem is one that occurs on a rare occasion in some place that you would not have thought to check. So, you can't expect to be able to catch them with tests. If the problem is one that would have been flagged as a compile-time error, then in that case it would have been useful to have been using static typing. I am still unsure. It seems likely that the usefulness of statically defined types would depend upon the application. When using statically defined types makes development slower to an extent that outways the benefit, then it is bad. If faster initial development as a result of dynamic typing ultimately ends up taking more time because of problems that would have been caught by a compiler, then it is bad. If statically defined typing makes you not discover things you would have because of the overhead of dealing with the static typing, then that is bad. Kendall On 10/05/2013 08:35 PM, zcaudate wrote: I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. BTW... This is no means a criticism of all the type system work that is going on in the clojure community. I am a huge fan of Ambrose's Typed Clojure project because it gives me the option of using types... not shoving it down my throat. I like the freedom to choose. My experience of programming in clojure has freed me from thinking about types and hierarchies and this article rings so true: http://steve.yegge.googlepages.com/is-weak-typing-strong-enough. However, everywhere I look, there are smug type-weenies telling me that my dynamically typed program is bad because it cannot be `proven correct` and not `checked by the compiler`. This question on SO really makes me angry http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages because no one is defending dynamic languages on there. The reason is very simple. because we don`t have a theory to back us up! I do want to put up an counter argument against this barrage of abuse against dynamic languages. And I want to put some academic weight behind this. The only counter I could come up with was to use Godel's incompleteness theorem. For those that don't know... here is an introduction to the man and his theory. http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, invalidated Principia Mathematica as a complete system of description. Principia Mathematica btw effectively led to Type Theory. According to http://en.wikipedia.org/wiki/Type_theory. The types of type theory were invented by Bertrand Russell in response to his discovery that Gottlob Frege's version of naive set theory was afflicted with Russell's paradox. This theory of types features prominently in Whitehead and Russell's Principia Mathematica. It avoids Russell's paradox by first creating a hierarchy of types, then assigning each mathematical (and possibly other) entity to a type. Objects of a given type are built exclusively from objects of preceding types (those lower in the hierarchy), thus preventing loops. I'm hoping to collect a few more `proofs` from the clojure community... for example... if there is a paper on why are type systems so bad at classifying animals... then please forward it on. -- -- 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
Re: How to go about 'proving' why dynamically typed languages are better.
while i can see the strengths of both sides, the ideal solution is imho this: everything is statically typed. always. but you *never* have to write the type explicitly. you *can* do it, but it is always optional. i made good experiences with both scala and haskell (although i just wrote minor things in the latter). the compiler really helps spotting oops-errors early on, and the ide (in case of scala) has a lot of information about the code and can assist you in ways that are simply impossible without static typing. please, do not confuse java with static typing. static typing could also track all supported methods of an object as its type. imagine java, but let every class implement one interface for each method that can be called on it - its inferred type is, instead of just a simple class, the set of interfaces necessary for the code to compile. to actually write that would be completely annoying, but if a compiler actually does the work for you and breaks it down, you would have a lot of error checking and static information without losing much flexibility Am 09.10.2013 00:36, schrieb Kendall Shaw: Some things that I see most of the time when I read debates about dynamic vs static are: 1. Statically defined types don't solve everything, so they are not useful. Some help is better than no help even if the help doesn't solve all of your problems. Yes, you should wash your hands before dinner, even though we are all going to die in the end anyway. 2. I like static typing as long as it is optional In the case where the point of using statically defined types is to have a compiler catch problems instead of you needing to predict their occurrence then static typing would have to be non-optional. 3. You don't need the compiler to warn you about types, because you can write tests. A difficult problem is one that occurs on a rare occasion in some place that you would not have thought to check. So, you can't expect to be able to catch them with tests. If the problem is one that would have been flagged as a compile-time error, then in that case it would have been useful to have been using static typing. I am still unsure. It seems likely that the usefulness of statically defined types would depend upon the application. When using statically defined types makes development slower to an extent that outways the benefit, then it is bad. If faster initial development as a result of dynamic typing ultimately ends up taking more time because of problems that would have been caught by a compiler, then it is bad. If statically defined typing makes you not discover things you would have because of the overhead of dealing with the static typing, then that is bad. Kendall On 10/05/2013 08:35 PM, zcaudate wrote: I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. BTW... This is no means a criticism of all the type system work that is going on in the clojure community. I am a huge fan of Ambrose's Typed Clojure project because it gives me the *option *of using types... not shoving it down my throat. I like the freedom to choose. My experience of programming in clojure has freed me from thinking about types and hierarchies and this article rings so true: http://steve.yegge.googlepages.com/is-weak-typing-strong-enough. However, everywhere I look, there are smug type-weenies telling me that my dynamically typed program is bad because it cannot be `proven correct` and not `checked by the compiler`. This question on SO really makes me angry http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages because no one is defending dynamic languages on there. The reason is very simple. because we don`t have a theory to back us up! I do want to put up an counter argument against this barrage of abuse against dynamic languages. And I want to put some academic weight behind this. The only counter I could come up with was to use Godel's incompleteness theorem. For those that don't know... here is an introduction to the man and his theory. http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, invalidated Principia Mathematica as a complete system of description. Principia Mathematica btw effectively led to Type Theory. According to http://en.wikipedia.org/wiki/Type_theory. The types of type theory were invented by Bertrand Russell in response to his discovery that Gottlob Frege's version of naive set theory was afflicted with Russell's paradox. This theory of types features prominently in Whitehead and Russell's Principia
Re: How to go about 'proving' why dynamically typed languages are better.
Yes the kind of app you are working on may make your mileage vary. But not only this criteria impacts how good you can fare with imposed data types. One tendency in software development is to normalize everything up to a point where two values are identical but because they have been typed differently they are not comparable anymore or interchangeable. The perversion here is that data typing at some point becomes a pain in the a... Especially when you want to make changes to your software. You inherit rigidity along the way and you have to pay for it as you go and an extra fee later. Having optional type checking allows you to pay the price where it's needed. I do not see why this is a problem. In any project you have to compromise on many factors. One great example is documentation, this is the first thing that gets axed when the schedule gets tight. Why not have this flexibility with the data type system ? Some components might benefit from it while others will not. You may consider data typing as a form of documentation but do you want to pay the price down to this level ? Low level documentation fail at describing component interactions (javadoc is a great example of verbosity w/o useful content). Better dedicate some time to write a higher level document than painfully type all the values in your software wall to wall. Luc P. Some things that I see most of the time when I read debates about dynamic vs static are: 1. Statically defined types don't solve everything, so they are not useful. Some help is better than no help even if the help doesn't solve all of your problems. Yes, you should wash your hands before dinner, even though we are all going to die in the end anyway. 2. I like static typing as long as it is optional In the case where the point of using statically defined types is to have a compiler catch problems instead of you needing to predict their occurrence then static typing would have to be non-optional. 3. You don't need the compiler to warn you about types, because you can write tests. A difficult problem is one that occurs on a rare occasion in some place that you would not have thought to check. So, you can't expect to be able to catch them with tests. If the problem is one that would have been flagged as a compile-time error, then in that case it would have been useful to have been using static typing. I am still unsure. It seems likely that the usefulness of statically defined types would depend upon the application. When using statically defined types makes development slower to an extent that outways the benefit, then it is bad. If faster initial development as a result of dynamic typing ultimately ends up taking more time because of problems that would have been caught by a compiler, then it is bad. If statically defined typing makes you not discover things you would have because of the overhead of dealing with the static typing, then that is bad. Kendall On 10/05/2013 08:35 PM, zcaudate wrote: I'm a little bit miffed over this current craze of `types` and `correctness` of programs. It smells to me of the whole `object` craze of the last two decades. I agree that types (like objects) have their uses, especially in very well defined problems, but they have got me in trouble over and over again when I am working in an area where the goal is unclear and requirements are constantly changing. BTW... This is no means a criticism of all the type system work that is going on in the clojure community. I am a huge fan of Ambrose's Typed Clojure project because it gives me the *option *of using types... not shoving it down my throat. I like the freedom to choose. My experience of programming in clojure has freed me from thinking about types and hierarchies and this article rings so true: http://steve.yegge.googlepages.com/is-weak-typing-strong-enough. However, everywhere I look, there are smug type-weenies telling me that my dynamically typed program is bad because it cannot be `proven correct` and not `checked by the compiler`. This question on SO really makes me angry http://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages because no one is defending dynamic languages on there. The reason is very simple. because we don`t have a theory to back us up! I do want to put up an counter argument against this barrage of abuse against dynamic languages. And I want to put some academic weight behind this. The only counter I could come up with was to use Godel's incompleteness theorem. For those that don't know... here is an introduction to the man and his theory. http://www.youtube.com/watch?v=i2KP1vWkQ6Y. Godel's theorem, invalidated Principia Mathematica as a complete system of description. Principia Mathematica btw effectively led to Type Theory. According
Re: GSoC Report: CinC, port of the clojure compiler in clojure
Yes Nicola, that's exactly the problem I was talking about. As far as I'm aware, the only way to make this maximally efficient at runtime on the JVM (and probably any other non-trivial runtime with typed method dispatch?) is to use some kind of recompilation strategy. invokedynamic is nice but doesn't get you there either: it still has a non-trivial runtime overhead. Scala has an incremental recompilation strategy using dependencies, though I think their compilation units are a bit larger than individual Clojure forms. See for more information: http://www.scala-sbt.org/0.13.0/docs/Detailed-Topics/Understanding-incremental-recompilation.htmlhttp://www.scala-sbt.org/0.12.3/docs/Detailed-Topics/Understanding-incremental-recompilation.html On Wednesday, 9 October 2013 06:09:02 UTC+8, Nicola Mometto wrote: I don't think that's what Mike was talking about. Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an public long invokePrim() method. When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim instead of invoke. If we redefine (defn x [] ) then y won't work because the new version of x doesn't implement IFn$L, we'd need to recompile y too. Mikhail Kryshen writes: Mikera mike.r.an...@gmail.com javascript: writes: 2) This in turn means we are going to have to recompile if we want to retain any sort of dynamic behaviour. The current system of independently mutable vars won't work (for obvious reasons: changing a var could easily violate the previous type inference assumptions) The HotSpot JIT compiler already performs adaptive optimization based on runtime profile and dynamicaly recompiles bytecode when necessary. The problem is the way Clojure calls functions through vars is not transparent to the compiler's optimizer. Invokedynamic can help here, see http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html -- -- 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] Grenchman, for running Clojure code quickly
When we've polled Leiningen users in the past[1], the #1 pain point people always report is its startup time. While there have been a number of strategies suggested to reduce the annoyance of slow JVM startup time and project loading, keeping your JVMs around can lead to awkward workflows in some situations given the tooling we've had so far. To this end I'm happy to announce the release of Grenchman, a tool for executing Clojure code in a running process *quickly*: http://leiningen.org/grench.html With Grenchman you can launch an nREPL server in the background (typically with `lein trampoline repl :headless`, but you can also embed an nREPL server in a production setting) and then connect to it directly From the command-line with minimal overhead: $ time grench eval '(println Hello, world!)' Hello, world! real0m0.117s user0m0.024s sys 0m0.024s This opens up a number of new command-line-centric workflows. You can also invoke Leiningen tasks from Grenchman if you launch a separate out-of-project `lein repl :headless` server: $ time grench lein version Leiningen 2.3.3 on Java 1.6.0_27 OpenJDK 64-Bit Server VM real0m0.118s user0m0.032s sys 0m0.020s Finally, Grenchman includes its own interactive nREPL client using GNU Readline: $ grench repl user= (System/getProperty user.dir) /home/phil/src/syme [...] Plans for the next version[3] include completion in the repl client and support for repl history and multi-line form input. While it is a very young project, the non-interactive functionality is quite stable. Please give Grenchman a try if this sounds interesting to you. The install process is the same as Leiningen where you download and chmod an executable, except that there is a different executable for different platforms; I have precompiled binaries for several common platforms at the link above and will post user-contributed builds for other platforms I don't have access to if there is demand. thanks, Phil [1] - https://lein-survey-2013.herokuapp.com/results and https://lein-survey-2012.herokuapp.com/results [2] - https://github.com/technomancy/leiningen/wiki/Faster [3] - https://github.com/technomancy/grenchman/issues?milestone=2state=open [4] - Grenchman was inspired to a degree by Jark (http://icylisper.github.io/jark/) but does not share any code with it. [5] - Timings above are taken from my 4½-year-old laptop; newer hardware would perform better. pgpNvXSLf_8X1.pgp Description: PGP signature
[ANN] clara-rules 0.2.0 released
Version 0.2.0 of Clara, a forward-chaining rules engine in Clojure, has been released. Thanks to Marshall Bockrath-Vandegrift, Chris Zheng and especially Yuval Lando for contributing code and ideas to the project. The main features of this release including using arbitrary maps as facts, optionally destructuring them in the left hand-side of the rule, and several corrections and improvements to simplify the code and its usage. Details in links below. Project page: https://github.com/rbrush/clara-rules Arbitrary maps and destructuring in rules: https://github.com/rbrush/clara-rules/wiki/Guide#fact-expressions Change Log: https://github.com/rbrush/clara-rules/blob/master/CHANGELOG.md -- -- 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] Grenchman, for running Clojure code quickly
Nice! I'd been vaguely thinking of redoing my nrepl client but I don't really use clojure these days. Glad to see you're a fan of ocaml too :) martin On Tue, Oct 8, 2013 at 7:49 PM, Phil Hagelberg p...@hagelb.org wrote: When we've polled Leiningen users in the past[1], the #1 pain point people always report is its startup time. While there have been a number of strategies suggested to reduce the annoyance of slow JVM startup time and project loading, keeping your JVMs around can lead to awkward workflows in some situations given the tooling we've had so far. To this end I'm happy to announce the release of Grenchman, a tool for executing Clojure code in a running process *quickly*: http://leiningen.org/grench.html With Grenchman you can launch an nREPL server in the background (typically with `lein trampoline repl :headless`, but you can also embed an nREPL server in a production setting) and then connect to it directly From the command-line with minimal overhead: $ time grench eval '(println Hello, world!)' Hello, world! real0m0.117s user0m0.024s sys 0m0.024s This opens up a number of new command-line-centric workflows. You can also invoke Leiningen tasks from Grenchman if you launch a separate out-of-project `lein repl :headless` server: $ time grench lein version Leiningen 2.3.3 on Java 1.6.0_27 OpenJDK 64-Bit Server VM real0m0.118s user0m0.032s sys 0m0.020s Finally, Grenchman includes its own interactive nREPL client using GNU Readline: $ grench repl user= (System/getProperty user.dir) /home/phil/src/syme [...] Plans for the next version[3] include completion in the repl client and support for repl history and multi-line form input. While it is a very young project, the non-interactive functionality is quite stable. Please give Grenchman a try if this sounds interesting to you. The install process is the same as Leiningen where you download and chmod an executable, except that there is a different executable for different platforms; I have precompiled binaries for several common platforms at the link above and will post user-contributed builds for other platforms I don't have access to if there is demand. thanks, Phil [1] - https://lein-survey-2013.herokuapp.com/results and https://lein-survey-2012.herokuapp.com/results [2] - https://github.com/technomancy/leiningen/wiki/Faster [3] - https://github.com/technomancy/grenchman/issues?milestone=2state=open [4] - Grenchman was inspired to a degree by Jark (http://icylisper.github.io/jark/) but does not share any code with it. [5] - Timings above are taken from my 4½-year-old laptop; newer hardware would perform better. -- -- 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: Teaching Clojure to students (how ?)
On Tuesday, October 8, 2013 12:52:38 PM UTC-4, Phil Hagelberg wrote:
On Monday, October 7, 2013 8:12:05 PM UTC-7, John Gabriele wrote:
For new users who want to get their feet wet right on the first day, I'd
suggest this (after they make sure they've got Java installed):
#. Download `lein`, drop it into your ~/bin, and `chmod +x` it if
necessary,
#. `lein version` (so it installs and thus creates ~/.lein directory
(see next step))
#. `touch ~/.lein/profiles.clj`, and into that file put `{:user
{:plugins [[lein-exec 0.3.1]]}}` (or whatever the current version of
[lein-exec] is when you're reading this. :)
You don't need a plugin for that actually:
$ lein run -m clojure.main/main -i foo.clj
Maybe a shell alias or lein alias would be more convenient though.
Thanks Phil! Didn't know you could do that! Wrote up some notes on getting
it working:
http://www.unexpected-vortices.com/blog/2013/scripts-in-clojure.html
-- John
--
--
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.
Regarding http://clojuredocs.org
Hello everyone , Latest version of Clojure is 1.5. But, http://clojuredocs.org only show docs for 1.2 and 1.3 versions. How about 1.4 and 1.5 documentation ? Thanks Binita -- -- 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: Regarding http://clojuredocs.org
Those who created ClojureDocs.org made some progress towards rewriting the server side code in Clojure (it was originally developed in Ruby on Rails, IIRC), but have found it challenging to find enough time to finish that work. I recall a month or two ago someone mentioning that they would be interested in finishing that work and updating the site, I think in a message on this group. Many/most of the functions and examples on ClojureDocs.org are still relevant for Clojure 1.5. It does not include new functions and macros added since Clojure 1.3, but there are not a huge number of those. Andy On Tue, Oct 8, 2013 at 8:13 PM, binita binita.bhar...@gmail.com wrote: Hello everyone , Latest version of Clojure is 1.5. But, http://clojuredocs.org only show docs for 1.2 and 1.3 versions. How about 1.4 and 1.5 documentation ? Thanks Binita -- -- 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: Regarding http://clojuredocs.org
The official docs is at http://clojure.org/documentation, http://clojure.github.io/clojure/ On Wed, Oct 9, 2013 at 2:13 PM, binita binita.bhar...@gmail.com wrote: Hello everyone , Latest version of Clojure is 1.5. But, http://clojuredocs.org only show docs for 1.2 and 1.3 versions. How about 1.4 and 1.5 documentation ? Thanks Binita -- -- 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. -- simple is good http://brucewang.net http://twitter.com/number5 -- -- 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.
