Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Comments

top

Programming Clojure

stuart.halloway Re:Clojure's LISP does not enforce abstraction (109 comments)

A good question. In Clojure, the idiomatic way to do the good part of OO is to use defrecord. Records created in this way do not encapsulate data. The data is immutable, and is directly accessible via public fields or map keyword lookup. Some other interesting differences from most OO: You *must* program to protocols (interfaces)--records cannot implement methods that are not part of a protocol. And implementation inheritance is forbidden. Defrecord supports a very iterative approach to development. You can start with simple functions and maps and then gradually discover protocols and records as your system evolves. When you introduce protocols and records, calling code need not change at all. All too often, data encapsulation protects your data from being used and reused, by creating an incompatible micro-language per domain entity. This is folly.

more than 4 years ago
top

Programming Clojure

stuart.halloway Re:Those who do not understand Lisp - (109 comments)

It's worth fighting through this initial impression to get to the other side. Lisps syntax is very regular, which makes reading/writing/tooling remarkably easy (once you are familiar). And, almost any kind of expression can go anywhere, encouraging maximal reuse. Mainstream OO languages, on the other hand, are built using all kinds of special syntax that cannot be composed together. If you and everyone around you have memorized the rules, they seem easy, but they are not simple at all. Consider the idea that "braces always mean a block of logic," which conceals a ton of hard-won special-case knowledge: Some blocks must be enclosed with {}, some have optional {}, and some cannot have {} at all. Some blocks are statements and cannot be used on the right hand side of an assignment, while others are expressions. Some blocks are not logic at all, but groupings of related methods (into a class) or classes (into a namespace). Some blocks (method bodies) can be preceded by a throws declaration, but others (class bodies, flow control) can't. Every kind of block has rules about what other kinds of blocks it can nest inside (Can I declare a static method in a finally block? Create a new named class in the else branch of an if?) Familiarity feels simple, but it may not be. Hang in until Clojure syntax gels for your, and your life will be simpler.

more than 4 years ago
top

Programming Clojure

stuart.halloway Re:Clojure's LISP does not enforce abstraction (109 comments)

I am not sure if you know what you are concerned about, as you use the word 'abstraction' in the title of your post, the word 'encapsulation' in the first sentence, and then conclude with 'OOP'. So I will take them one at a time. (1) Clojure is built around abstractions, there is a rich set of carefully designed interfaces. (2) Clojure's approach to data is certainly not what an OO person would expect. In Clojure, *data* encapsulation is considered folly. However, this must be taken in the context of several synergistic ideas: persistent data structures, the unified update model, and a rich, general approach to data. (3) For an introduction to Clojure's approach to OO concepts, check out my video introducing clojure protocols (http://vimeo.com/11236603). I would welcome (and have been seeking) an informed debate on the soundness of protocols in comparison to the options available in other OOP languages.

more than 4 years ago
top

Programming Clojure

stuart.halloway Re:Asynchronous and self modifying code. (109 comments)

"Functional programming" and "self-modifying" code are closer to opposites than synonyms. Functional programs work with immutable data, eliminating the confusion that ensues when things can change behind your back. Clojure makes functional programming efficient (via persistent data structures) and accessible to mainstream developers (on the JVM). Also, Clojure connects FP to an understandable model for state and time (see http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey). People have been taking design patterns to a concrete level for years now, it's called copy/paste reuse. Lisp has had the design patterns problem solved for decades, and Clojure is no exception.

more than 4 years ago
top

Programming Clojure

stuart.halloway Re:First! Lisp! Rant! (109 comments)

In Clojure you would likely use destructuring to dig pieces out of a sequence, avoiding explicit function calls altogether. Agreed that languages need more than just good naming conventions. In Clojure's case, that 'more' is a careful set of abstractions, including some for modeling time. A good conceptual overview on time, state, and identity is online at http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey.

more than 4 years ago
top

Programming Clojure

stuart.halloway Re:First! Lisp! Rant! (109 comments)

One of the nice things about Clojure is Rich's willingness to dispense with old names that have gone stale with time. Clojure has no 'car' or 'cdr' functions. 'cons'(truct) lives on, as its mnemonic is useful.

more than 4 years ago

Submissions

stuart.halloway hasn't submitted any stories.

Journals

stuart.halloway has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>