I think we should focus on 1) narrowly defining problematic situations and
2) coming up with simple solutions with minimal scope and impact on
Clojure.

With regards to "bag of properties", this is a problem in very specific
situations, which would be helpful to enumerate. It is decidedly not a
problem IMHO in the vast majority of use cases. Having instant notification
of minor typos IMHO does not justify a language-level change.

The situations were bag of properties is problematic tends to be:
1) where the bad is successively read and written to by different
operations or parts of the system. Middleware is a great example. When a
given operation fires, whats in the bad is dependent on the previous
computational history. This becomes hard to track.
2) where a huge context map is being passed, accumulating stuff from all
over the system.

Situation 1 is exactly why Schema was invented. Situation 2 is why
Component was invented. However, this is not to say that we cannot do
better. I would be very interested in those directions being taken further,
or other small, orthogonal solutions complementing them.

With regards to types, I think Mike was onto the right idea with KISS: Can
we can a statically typed language that is highly interoperable and
complementary with Clojure? One important step would be to look at existing
JVM languages (like Frege) and asses their potential for Clojure interop.

If its not possible to create a statically typed language with good Clojure
interop, then I'd argue thats evidence that the chances of giving Clojure
itself a static type system is small. If it is possible to have a 2nd
language (existing or new) in this role, than I'd argue that is the simpler
solution.







On Wed, Dec 2, 2015 at 1:51 AM, jongwon.choi <oz.jongwon.c...@gmail.com>
wrote:

> Use defrecord. People still can mess by using it as map, but it is a
> different problem.
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Reply via email to