On Sun, Dec 22, 2013 at 12:26 PM, Lee Spector lspec...@hampshire.eduwrote:
The issue I was rasing is that, when traversing '(() 0) with zip/next, one
should first visit the root, then (), and then 0. But what actually happens
is that between then () and the 0 one lands on a non-existent nil
The two classes have essentially the same semantics, but performance
differences, which is why Clojure sometimes uses one and sometimes the
other. If you want to enforce that a map is returned, enforce that the
return is a subtype of java.util.Map rather than checking for a specific
concrete class
Just a link to the Gilad Bracha post Richard Cole is referring to: Types
Are Anti-Modularhttp://gbracha.blogspot.it/2011/06/types-are-anti-modular.html
.
Il giorno lunedì 23 dicembre 2013 02:24:08 UTC+1, Richard Cole ha scritto:
The things is that dynamically typed languages are easier to
This ties in nicely to my summary of how I feel about static typing: Static
typing is a premature optimisation. Like most optimisations, it has
genuine value, but if you apply it globally and too early, you end up
causing more pain than you gain.
sometime type discussions lead to lead to early
Do you guys have any concrete examples?
Sent from my iPhone
On 23 Dec 2013, at 10:13, Korny Sietsma ko...@sietsma.com wrote:
This ties in nicely to my summary of how I feel about static typing: Static
typing is a premature optimisation. Like most optimisations, it has genuine
value, but
I agree entirely with Korny's
statements.
As for concrete examples ?
Hard to enumerate some, I can only
say I agree after more than 30 years
coding in various languages and
finally getting out of Java hell.
When I started there were a variety
of dynamic languages used in the
industry and given
juan.facorro juan.faco...@gmail.com writes:
Hi Clojurers,
[snip]
There are parsing libraries which provide good parse trees (i.e. Parsley,
Instaparse), but my understanding is that what needs to be
mantained is a full abstract syntax tree for the whole code base and although
This article makes some interesting points, but it seems to draw the wrong
conclusions.
The thing that is anti-modular isn't the types: it is depending on the
internal implementation details of another module. If you expose too much
of the implementation details in your interface declaration,
Hello,
Food for thought:
Currently Counterclockwise does 2 things:
- it has an up-to-date list of symbols / keywords derived from the current
editor. This of course does not need a running REPL, works as an heuristic
for locals, and that's all. It won't go beyond the current file, won't show
On Dec 23, 2013, at 3:40 AM, Cedric Greevey wrote:
On Sun, Dec 22, 2013 at 12:26 PM, Lee Spector lspec...@hampshire.edu wrote:
The issue I was rasing is that, when traversing '(() 0) with zip/next, one
should first visit the root, then (), and then 0. But what actually happens
is that
Hi Larry,
You can use *lein check* which *Check[s] syntax and warn[s] on
reflection.* only for the *.clj files in your project's soure files.
HTH,
Juan
On Sunday, December 22, 2013 7:33:56 PM UTC-3, larry google groups wrote:
I know this has been discussed before but I could not find
*John:* I had watched that talk a while ago, not sure how I got to it. The
work he describes is really interesting and sounds quite herculean,
something that a company like Google can do. Unluckily the project hasn't
seen the public light of day yet, at least not that I know of.
*Zack*: Thanks
Hi Larry,
This is not exactly what you asked but it might be helpful. There's a *check
*command in *leiningen* wich *Check[s] syntax and warn[s] on reflection.*
only
for the **.clj* files in your project's source files. This doesn't really
resolve the reflection warnings for the libraries you
I came to this thread late, and have only skimmed some of the answers, but
I think that the following, somewhat oblique, opinion hasn't yet been
expressed about the, I don't know, maybe ... harassment by type weenies
that zcaudate feels. Apologies in advance if I've missed a similar point.
Cross posted from pedestal-users group, as many people who are not using
pedestal may still know about dataflow, terms like effect are used in the
context of pedestal
Pedestal seems strongly based on dataflow based programming. The gigantic
tutorial just sort of jumps in on it.
Based on my
Dynamical languages are above all oriented toward practical programming
needs *in certain contexts*--in other contexts, static typing is more
practical.
Agreed -- which is why I find your speculation about lightening up with
more experience ... meeting the demands of practical coding to
Agreed -- which is why I find your speculation about lightening up with
more experience ... meeting the demands of practical coding to be unsound.
For those of us whose practical programming context includes a high cost
associated with most any runtime bug, greater embrace of static typing,
I don't think we disagree. The guesses I gave in my post only concerned
people like those who frustrated zcaudate, and who, from what was said,
seemed to feel that anything other than strict static typing was wrong in
all contexts. Maybe I'm reading too much into zcaudate's post, though.
As another data point, Cursive's symbol resolution in normal code editing
is totally static - it doesn't use the REPL at all. When typing in the REPL
window, local resolution is used for the code in the editor and the REPL is
used for everything else, so that local symbols can be completed and so
@Richard. I would have said the same as you before I joined a relatively large
organisation heavily influenced by scala and the Coursera FP lecture series. We
are slowly moving into Clojure code but there now seems to be a huge
misconception that FP and Type Systems are joined at the hips.
My
I'm not sure what you mean by invoking the putative silliness of an any
type, but existential types aren't just a way of saying anything goes
here, typewise---they do enable further substantive static guarantees
(such as those used by e.g. Haskell's ST system).
On Mon, Dec 23, 2013 at 2:16 PM,
About:
The question, then, is whether the flexibility of
dynamic types lets you develop, test, unit test, and system test code
so much faster than you would in a language with strong static types
that you are able to prevent all runtime type errors anyway.
Yes! In the past years, I coded in
@mars0i That is how I feel. Of course static typing has its use. For starters,
it makes my programs go faster.
However, the more i write lisp code, the more i realise that types has its
drawbacks. I'm not sure of the answer here but I have my suspicions: Can typed
clojure be written in typed
On Mon, Dec 23, 2013 at 2:34 PM, Chris Zheng z...@caudate.me wrote:
However, the more i write lisp code, the more i realise that types has its
drawbacks. I'm not sure of the answer here but I have my suspicions: Can
typed clojure be written in typed clojure?
Why in the world couldn't it be?
On Dec 23, 2013, at 14:16, Chris Zheng wrote:
I completely agree with Korny that types are a premature optimisation.
My take is that required types may force premature optimization and may
inhibit the creative process. So, I like dynamic languages. However,
optional types (preferably with type
On Monday, December 23, 2013 5:39:54 PM UTC-6, Rich Morin wrote:
My take is that required types may force premature optimization and may
inhibit the creative process.
That's an interesting point. I like it. Kind of off topic, but my earlier
remark about psychological factors that might
Is there a straightforward way to setup a Clojure library so that it can
depend on an older version of itself?
I can think of a couple of ways to do this that seem clunky, but was
wondering what approaches (if any) have worked well for other folks.
Something involving pomegranate and
I don't have any suggestions as to how this might be achieved, I'm afraid,
but I am very curious as to *why* you'd want to do this.
- James
On 24 December 2013 00:07, Michael Bradley, Jr. michaelsbradle...@gmail.com
wrote:
Is there a straightforward way to setup a Clojure library so that it
I’m writing a parser that will be easier to write with itself, but I want to be
able to “freeze” an earlier version that’s passing all the tests (for features
implemented so far) and which is implemented quite differently. The older
version can then be used as the basis for the next version,
Can typed clojure be written in typed clojure?
could just project everything into some universal type, then do case
analysis based on what sort of thing you had. (Which is the nub of Bob
Harper's claim that dynamically typed languages are just a special case of
statically typed
On Dec 23, 2013, at 16:03, Mars0i wrote:
... creativity often requires a intermediate stage of messiness.
Then you have to clean it up to get something interesting, in
many cases, but you wouldn't have gotten to some place new and
interesting if you only went via purely rational, rigorous
No, lein check will give you reflection warnings on 3rd party libraries...
(sean)-(jobs:0)-(/Developer/workspace/worldsingles/ws/model/clojure/worldsingles)
(! 505)- lein check
Compiling namespace worldsingles.activity
Reflection warning, clojure/core/incubator.clj:84:7 - reference to
field
Sean,
Thank you much.
I do understand that Clojure is not a *statically typed language, *but it
seems like it should be possible to deal with these reflexion issues when
someone needs to. In my company we had a Scala versus Clojure debate and
there was a vocal crowd that felt we should use
enforce that the return is a subtype of java.util.Map rather than
checking for a specific concrete class of map.
Thank you. I'll do that. All the same, can anyone tell me why this function
changes the type of the value? All it does is call fetch. The fetch
function has this post condition:
I find this surprising. I do this:
(supers %)
inside of my :post condition, and I get:
java.lang.ClassCastException: clojure.lang.PersistentHashMap cannot be cast
to java.lang.Class
at clojure.core$bases.invoke(core.clj:4985)
at clojure.core$supers.invoke(core.clj:4994)
at
Since it's just temporary, maybe create a temporary namespace hierarchy
with the old version of the compiler. This would be a terrible sin if you
intended for that code to stick around but if you promise you will throw
away the older version once you don't need it anymore...
On Mon, Dec 23, 2013
You mean (supers (type %)) ?
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org
From: larry google groups
Sent: Monday, December 23, 2013 7:28 PM
To: clojure@googlegroups.com
I find this surprising. I do this:
(supers %)
inside of my :post condition,
;; persistent maps only
(instance? clojure.lang.IPersistentMap %)
;; all Java maps
(instance? java.util.Map %)
On 24 December 2013 04:28, larry google groups
lawrencecloj...@gmail.com wrote:
I find this surprising. I do this:
(supers %)
inside of my :post condition, and I get:
On 24 December 2013 07:35, Michał Marczyk michal.marc...@gmail.com wrote:
;; persistent maps only
(instance? clojure.lang.IPersistentMap %)
Additionally, this one's better written
(map? %)
(map? is in fact defined as instance? IPM.)
Cheers,
M.
;; all Java maps
(instance? java.util.Map %)
39 matches
Mail list logo
