Live data from Hacker News

Clojure will affect the way you think about programming

eli.thegreenplace.net

181–190 of 226 posts

Re: Clojure will affect the way you think about programming

#181
post #166
post #56

Clojure will affect the way you think about programming. It's led a number of people I know to start taking Haskell seriously after their Clojure phase.

This seems somewhat surprising to me since they are, in some sense, at opposite ends of the functional programming spectrum... but it's the path I took.

I think it's a cultural thing. There's something similar going on with Python and go.

Seems like a lot of people start with "getting types to go away makes a lot of powerful things easier". But eventually you a) get sick of typos causing runtime errors b) start to realise there are even more powerful things you can do with a non-broken type system.

Re: Clojure will affect the way you think about programming

#182
post #72

Earlier quoted context omitted.

Is there something about clj's repl that makes it any different from ghci's?

Yes, you can reload any symbol in the CLJ REPL directly from the editor. You can also evaluate any function within the context of the running application without going through the main. The REPL is an integral part of the development process in Clojure. You can see this in action here around 15 minute mark https://www.youtube.com/watch?v=nItR5rwP4mY

R and RStudio are actually quite good in this aspect.

- You can evaluate any part of editor in console with keyboard shortcut. The only difference between using console and editor is that your input is easily saved in editor.

- The environment browser make inspecting variables, data structures much easier.

Besides, in R you want to use vectorized functions for better performance, so you search for general functions and combine them, which actually promote good functional programming style instead of a big control block with many processes intertwined.

Re: Clojure will affect the way you think about programming

#183
post #173

Earlier quoted context omitted.

> In Clojure parlance, "simplicity" refers to interconnectedness Clojure tends to redefine words describing concepts with a new or restricted meaning. Typically a general concept like 'simplicity' would have more than one dimension. > take as as argument an object that has the "id" field from the "Student" class, and the "email" field from the "User" class. Or would you have to explicitly pre-define mixins like HasSt…

> Clojure tends to redefine words describing concepts with a new or restricted meaning. Typically a general concept like 'simplicity' would have more than one dimension. Sure, but that happens all the time in programming. When we talk about "objects" we don't mean "a material thing that can be seen and touched". > I would not do this at all. Having slots or not are low-level artefacts and writing methods which are fi…

I understand that, but as I said I don't like that at all. It binds methods to low-level adhoc features and not to class based domain ontologies. There are other pattern directed invocation systems, which also support that, but I usually prefer the more systematic approach of CLOS. In the tradition of symbolic programming I want to have symbolic classes as my anchors for functionality, not adhoc patterns.

Re: Clojure will affect the way you think about programming

#184

I don't like working with clojure. Its basically modern perl. I've worked with both professionally, and the outstanding point with both has been: - programmers try to be clever in their code, write one giant file full of complicated specialized 'beautiful' code, forget everything they know about breaking big tasks into simple small ones. - code is a nightmare to maintain for non-author - non-authors working on code r…

Sorry, but don't agree with what you are saying. Clojure is very different from Perl. I would argue Clojure is more readable than Java (when written well). Immutability by default means Clojure code can be read like math equation on a board. Sure, it's tough if you don't put in the effort to learn the notation, but once that barrier is crossed, it's a very usable language.

Also, this notion of code should be readable by everyone (not involved with the project) is bullshit. Learn the notation once, make use of it forever. All that is needed to do to find the grain of the problem, and cut along it (and REPL helps a lot with that). Contrarily, you can write code assuming no background - which leads to Java like code, where everything must be repeated.

Perl is a write-only context-dependent (with side-effects too) language, because Larry Wall thinks computer languages should be like human languages.

Re: Clojure will affect the way you think about programming

#185
post #78

Earlier quoted context omitted.

Do you know of a good resource for reading about their data-structures, especially anything Haskell doesn't have?

Any book on clojure and website too will go over them. They are fundamental to using clojure. I don't know enough about haskell to say what it does or doesn't have in relation to clojure. However, it's not simply the data structures, but how the language is built to interact with them from a programmers perspective. From a user interface to the language point of view, I find the ways of interacting with maps to be ve…

> Many Lisp traditionalists are bothered by the use of curly braces for maps and square brackets for vectors, however I'm a fan. Without this bit of syntax, you have to add verbosity to the language to differentiate defining a map from doing a lookup, etc.

I agree with you, in the sense that they are useful, however the complain of "Lisp traditionalists" will be that in any case, if you need them, you can add them to Common Lisp by using reader macros. So in CL the curly braces and brackets are "free" to be used (i.e. define what they should do) in any way you want; on Clojure they are already taken, so it feels a bit uncomfortable.

Re: Clojure will affect the way you think about programming

#186

Earlier quoted context omitted.

>> ...the bank announced they have decided to kill it because they don't like it, but that's got little to do with Clojure... I think that had something to do with Clojure. The thing is, businesses usually follow best-practices and choosing a language like Clojure is certainly not a best-practice (even if developers had really good reasons to use it). For example, who maintains the code? How many Clojurists (is that…

> How many Clojurists (is that a word?) can you find to work on the project? You don't need to look for Clojurians, you just need to look for developers. Getting to write in some slightly off-the-standard languages is a big draw for a lot of competent devs

> You don't need to look for Clojurians, you just need to look for developers.

One of the best comments in HN in a long time, deserves its own article.

So true. A programmer should be able to learn any other new language quickly.

Re: Clojure will affect the way you think about programming

#187
post #126

> Clojure is a dynamic language. Dynamically typed. As a dynamic language Clojure is less capable than many other Lisp implementations/languages. See for example 'late binding'. In Clojure you either need to define a function before its use or need declare it. Not that 'dynamic'. In a typical Lisp dialect the order of definitions makes much less a difference, since functions can be called late-bound. For an interpret…

> Historically, Lisp programmers weren't the biggest proponents of OOP

Yes, this is totally misleading... Lisp had OOP before Common Lisp existed, for example the Flavors OOP system through the '70s. This, of course, is before C++ was even a thought in the mind of Bjarne Strostroup.

Also, interesting fact: Common Lisp was the first Object-Oriented language to get an ANSI standard.

Re: Clojure will affect the way you think about programming

#189

Earlier quoted context omitted.

Any book on clojure and website too will go over them. They are fundamental to using clojure. I don't know enough about haskell to say what it does or doesn't have in relation to clojure. However, it's not simply the data structures, but how the language is built to interact with them from a programmers perspective. From a user interface to the language point of view, I find the ways of interacting with maps to be ve…

>Many Lisp traditionalists are bothered by the use of curly braces for maps and square brackets for vectors I have definitely seen this. I'm not sure that I understand this sentiment. The only thing that Clojure is missing is the "system" feel that Common Lisp provides, with things like character macros, symbol macros, etc. That being said, I definitely appreciate how thought through Clojure is, especially when compa…

> notion of a `calleable` type is gone

You can do this using the metaobject protocol and defining a class with a metaclass of FUNCALLABLE-STANDARD-CLASS, for example, given:

    (defclass c ()
      ((x :initarg :x :accessor x))
      (:metaclass funcallable-standard-class))

    (defmethod initialize-instance :after ((c c) &key)
      (with-slots (x) c
        (set-funcallable-instance-function
         c
         #'(lambda ()
             (format t "~&I'm #~a" x)))))
Then (funcall (make-instance 'c :x 3)) will print "I'm #3".

> `nth` isn't defined on vectors or strings (but you can still `length` them!)

ELT in Common Lisp is generic over sequence types. NTH is specific to lists. If you want to write a function that is generic over sequences, use ELT. If you know that you have a list or an array, and you're writing something performance sensitive, you can avoid type dispatch overhead by using NTH or AREF instead of ELT.

> nor is `first` and `rest`

You can avoid that friction a lot of the time by writing in terms of MAP, REDUCE, REMOVE-IF-NOT, and so on, as well as LENGTH and ELT, which are all generic over sequences, or doing (iter (for x in-sequence sequence) ...) or whatever.

But if you really want to use FIRST and REST to walk through a vector, you can do (coerce vector 'list) first to convert it. Coercing a list to list will just return that list, so that version would work for either, too. I admit, there's no real reason I know of (aside from lack of demand) that there isn't a predefined function like:

    (defun vector-rest (vector)
      (make-array (1- (length vector))
                  :displaced-to vector
                  :displaced-index-offset 1))
Then if it bothered you you could do something like

    (defun head (sequence)
      (elt sequence 0))

    (defun tail (sequence)
      (etypecase sequence
        (list   (rest        sequence))
        (vector (vector-rest sequence))))

Re: Clojure will affect the way you think about programming

#190
post #183

Earlier quoted context omitted.

> Clojure tends to redefine words describing concepts with a new or restricted meaning. Typically a general concept like 'simplicity' would have more than one dimension. Sure, but that happens all the time in programming. When we talk about "objects" we don't mean "a material thing that can be seen and touched". > I would not do this at all. Having slots or not are low-level artefacts and writing methods which are fi…

I understand that, but as I said I don't like that at all. It binds methods to low-level adhoc features and not to class based domain ontologies. There are other pattern directed invocation systems, which also support that, but I usually prefer the more systematic approach of CLOS. In the tradition of symbolic programming I want to have symbolic classes as my anchors for functionality, not adhoc patterns.

You can still create class-like ontologies with Clojure specs, but usually you don't need to.

Clojure's specs, adhoc or otherwise, certainly might not be your cup of tea. Clojure really pushes the idea of separation and isolation, and in my view you need to buy into that philosophy to be at all comfortable with the language.

Where I disagree with you is your assertion that maps in Clojure are always less structured than objects. I'd claim that (at least when properly spec'ed out) they provide far more structure than objects.

Post reply on HN