5 ms·

STM and concurrency...sure those are "aspects" of Clojure, Clojure's biggest strength is that it's data-centric. The vast majority of the language is focused ar

STM and concurrency...sure those are "aspects" of Clojure, Clojure's biggest strength is that it's data-centric. The vast majority of the language is focused around manipulating hashmaps, vectors, sequences, etc, and do that in an efficient way. All the concurrency stuff is just icing. So I really have to sit back and shake my head when the author says he's going to be as good as Clojure, then goes off into the weeds with custom syntax, STM and actors. Really? Why actors? This would have been a much better article if it just left Clojure out of the discussion since whenever the author talks about the language he's mostly wrong. And as always, lies, damn lies, and benchmarks: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=clojure&lang2=sbcl https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... If you're going to use a phrase like "faster", at least spend some time to define the word.

m0skit0 10y ago
Isn't a functional language supposed to be function centric?
- _halgari 10y ago
  Sure, but what do those functions do? In clojure they manipulate data. That's pretty much the gist of the language: using pure functions to manipulate data. Almost all the work I do these days as a software engineer is data transformation. Going from a HTTP request, which is data (even the header is a hashmap), and a HTTP body, which is data, into some business logic that eventually writes to a database in a different format. Even the most complex systems I've built containing dozens of servers and multiple databases, queues, http servers, etc. All boil down to transforming data from format A to format B perhaps with conditional logic applied. So yes, Clojure is a functional language, but functions are just a tool to be used to get the actual work done of transforming data.
- macmac 10y ago
  Clojure's rich persistent data structures together with protocols facilitates functional programming in Clojure. When Clojure is called a data-centric I think most users mean that it encourages functional programming applied to rich immutable data.
freeduck 10y ago
Cl has fset for persisten collections
brudgers 10y ago
I like Clojure. It's data-centricness is something that it shares with certain ways of programming in Common Lisp. In particular the use of lists in Common Lisp. For example, a list holding a schedule of appointments ;;; adapted from ;;; https://www.ida.liu.se/ext/caisor/archive/1978/001/caisor-1978-001.pdf (((JAN 12 2014) ((9 15) (10 00) (SEE ANDERSON)) ((10 45) (11 00) (SEE LUNDSTROM)) ((13 15) (16 00) (ATTEND Y COMMITTEE MEETING))) (((JAN 13 2014) ((9 30) (10 00) (ATTEND NEW PRODUCTS PRESENTATION))) A lot of what Clojure brings is more efficient abstractions. For example Common Lisp has two key-value stores a-list and hash tables that Clojure collapses into one thing and then rolls together with hashes and sets as much as possible.
- _halgari 10y ago
  Same data in Clojure: [{:appt/start #inst "01-02-2014T9:15:00Z" :appt/end #inst "01-02-2014T9:15:00Z" :appt/description "See Anderson"} {:appt/start #inst "01-02-2014T10:45:00Z" :appt/end #inst "01-02-2014T11:00:00Z" :appt/description "See Lundstrom"} {:appt/start #inst "01-02-2014T13:15:00Z" :appt/end #inst "01-02-2014T16:00:00Z" :appt/description "Attend Y Committee Meeting"} ...] Let's point out some important differences: 1) Clojure prefers maps over cons cells. This means that I always know exactly what I'm looking at. I don't have to guess that the second times are the end-times...I know because it' named :appt/end. 2) We don't overload data types. Have a date? Use a date type. In the CL example we see symbols and numbers sometimes used for descriptions, sometimes for times, etc. Here in Clojure we have #inst ... which creates an actual DateTime object. Now I no longer wonder what I'm looking at, I know it's a date. 3) Clojure prefers data over DSLs. What this calendar example shows is some sort of domain specific language that not only has to be parsed by a program, but it also has to be parsed by a human. 4) Got a meeting description, use a actual string....what's up with the use of symbols as strings (I never understood that about CL). 5) From the perspective of a data modeler...in the CL example if you want a meeting to last over midnight or for longer than a day, it looks like you're sunk. But thanks for the example, it's fun to see how data modeling is done in other languages.
  - jorams 10y ago
    I think most CL programmers would agree with several of your points. Using lists of symbols instead of strings is not useful. Though there are infinite ways to model the calendar, a slightly better way would be something like the following. Note that it's incredibly similar to your Clojure example, though it uses property lists instead of maps: ((:start @2014-01-02T09:15:00Z :end @2014-01-02T09:15:00Z :description "See Anderson") (:start @2014-01-02T10:45:00Z :end @2014-01-02T11:00:00Z :description "See Lundstrom") (:start @2014-01-02T13:15:00Z :end @2014-01-02T16:00:00Z :description "Attend Y Committee Meeting") ...) Do note that this uses the local-time[1] library's timestamp syntax. If you don't want dependencies you could put numerical universal-time[2] timestamps there. Of course, depending on the programmer, this would change a lot. For example you could use a simple list or vector of 3 items instead of a property list, or maybe an association list. But if this isn't a one-off thing, most would probably define a class or a struct to store the data in, with proper accessors to get the data out. This wouldn't be so easily PRINTable as the above, but in code it would look something like the following: (list (make-appointment :start @2014-01-02T09:15:00Z :end @2014-01-02T09:15:00Z :description "See Anderson") (make-appointment :start @2014-01-02T10:45:00Z :end @2014-01-02T11:00:00Z :description "See Lundstrom") (make-appointment :start @2014-01-02T13:15:00Z :end @2014-01-02T16:00:00Z :description "Attend Y Committee Meeting")) Now you have data with actual types, with accessors like appointment-start, appointment-end, and appointment-description. [1]: https://common-lisp.net/project/local-time/manual.html#Reader-Macros https://common-lisp.net/project/local-time/manual.html#Reade... [2]: http://www.lispworks.com/documentation/HyperSpec/Body/25_adb.htm http://www.lispworks.com/documentation/HyperSpec/Body/25_adb...
klibertp 10y ago
> Really? Why actors? Probably because Common Lisp is already on a similar level of being data-centric, so it would be redundant to talk about it. Actually, the only difference between how Clojure and CL treat data is that (while both offer access to both kinds of data) Clojure strongly prefers immutable values, while CL doesn't care.
- dsrguru 10y ago
  Clojure doesn't just "strongly prefer" immutable data but syntactically ensures that all data is immutable unless governed by one of four concurrency mechanisms. Persistent data structures aren't just a popular convention in Clojure--the language is literally built around them.
igouy 10y ago
> And as always, lies, damn lies, and benchmarks Things change: not the same JVM as 2014, not the same Clojure. We may quote to one another with a chuckle the words of the Wise Statesman, lies, damned lies and statistics, still there are some easy figures which the simplest must understand but the astutest cannot wriggle out of. 1895 Leonard Henry Courtney

m0skit0 10y ago

Isn't a functional language supposed to be function centric?

_halgari 10y ago
Sure, but what do those functions do? In clojure they manipulate data. That's pretty much the gist of the language: using pure functions to manipulate data. Almost all the work I do these days as a software engineer is data transformation. Going from a HTTP request, which is data (even the header is a hashmap), and a HTTP body, which is data, into some business logic that eventually writes to a database in a different format. Even the most complex systems I've built containing dozens of servers and multiple databases, queues, http servers, etc. All boil down to transforming data from format A to format B perhaps with conditional logic applied. So yes, Clojure is a functional language, but functions are just a tool to be used to get the actual work done of transforming data.
macmac 10y ago
Clojure's rich persistent data structures together with protocols facilitates functional programming in Clojure. When Clojure is called a data-centric I think most users mean that it encourages functional programming applied to rich immutable data.

freeduck 10y ago

Cl has fset for persisten collections

brudgers 10y ago

I like Clojure. It's data-centricness is something that it shares with certain ways of programming in Common Lisp. In particular the use of lists in Common Lisp. For example, a list holding a schedule of appointments ;;; adapted from ;;; https://www.ida.liu.se/ext/caisor/archive/1978/001/caisor-1978-001.pdf (((JAN 12 2014) ((9 15) (10 00) (SEE ANDERSON)) ((10 45) (11 00) (SEE LUNDSTROM)) ((13 15) (16 00) (ATTEND Y COMMITTEE MEETING))) (((JAN 13 2014) ((9 30) (10 00) (ATTEND NEW PRODUCTS PRESENTATION))) A lot of what Clojure brings is more efficient abstractions. For example Common Lisp has two key-value stores a-list and hash tables that Clojure collapses into one thing and then rolls together with hashes and sets as much as possible.

_halgari 10y ago
Same data in Clojure: [{:appt/start #inst "01-02-2014T9:15:00Z" :appt/end #inst "01-02-2014T9:15:00Z" :appt/description "See Anderson"} {:appt/start #inst "01-02-2014T10:45:00Z" :appt/end #inst "01-02-2014T11:00:00Z" :appt/description "See Lundstrom"} {:appt/start #inst "01-02-2014T13:15:00Z" :appt/end #inst "01-02-2014T16:00:00Z" :appt/description "Attend Y Committee Meeting"} ...] Let's point out some important differences: 1) Clojure prefers maps over cons cells. This means that I always know exactly what I'm looking at. I don't have to guess that the second times are the end-times...I know because it' named :appt/end. 2) We don't overload data types. Have a date? Use a date type. In the CL example we see symbols and numbers sometimes used for descriptions, sometimes for times, etc. Here in Clojure we have #inst ... which creates an actual DateTime object. Now I no longer wonder what I'm looking at, I know it's a date. 3) Clojure prefers data over DSLs. What this calendar example shows is some sort of domain specific language that not only has to be parsed by a program, but it also has to be parsed by a human. 4) Got a meeting description, use a actual string....what's up with the use of symbols as strings (I never understood that about CL). 5) From the perspective of a data modeler...in the CL example if you want a meeting to last over midnight or for longer than a day, it looks like you're sunk. But thanks for the example, it's fun to see how data modeling is done in other languages.
- jorams 10y ago
  I think most CL programmers would agree with several of your points. Using lists of symbols instead of strings is not useful. Though there are infinite ways to model the calendar, a slightly better way would be something like the following. Note that it's incredibly similar to your Clojure example, though it uses property lists instead of maps: ((:start @2014-01-02T09:15:00Z :end @2014-01-02T09:15:00Z :description "See Anderson") (:start @2014-01-02T10:45:00Z :end @2014-01-02T11:00:00Z :description "See Lundstrom") (:start @2014-01-02T13:15:00Z :end @2014-01-02T16:00:00Z :description "Attend Y Committee Meeting") ...) Do note that this uses the local-time[1] library's timestamp syntax. If you don't want dependencies you could put numerical universal-time[2] timestamps there. Of course, depending on the programmer, this would change a lot. For example you could use a simple list or vector of 3 items instead of a property list, or maybe an association list. But if this isn't a one-off thing, most would probably define a class or a struct to store the data in, with proper accessors to get the data out. This wouldn't be so easily PRINTable as the above, but in code it would look something like the following: (list (make-appointment :start @2014-01-02T09:15:00Z :end @2014-01-02T09:15:00Z :description "See Anderson") (make-appointment :start @2014-01-02T10:45:00Z :end @2014-01-02T11:00:00Z :description "See Lundstrom") (make-appointment :start @2014-01-02T13:15:00Z :end @2014-01-02T16:00:00Z :description "Attend Y Committee Meeting")) Now you have data with actual types, with accessors like appointment-start, appointment-end, and appointment-description. [1]: https://common-lisp.net/project/local-time/manual.html#Reader-Macros https://common-lisp.net/project/local-time/manual.html#Reade... [2]: http://www.lispworks.com/documentation/HyperSpec/Body/25_adb.htm http://www.lispworks.com/documentation/HyperSpec/Body/25_adb...

klibertp 10y ago

> Really? Why actors? Probably because Common Lisp is already on a similar level of being data-centric, so it would be redundant to talk about it. Actually, the only difference between how Clojure and CL treat data is that (while both offer access to both kinds of data) Clojure strongly prefers immutable values, while CL doesn't care.

dsrguru 10y ago
Clojure doesn't just "strongly prefer" immutable data but syntactically ensures that all data is immutable unless governed by one of four concurrency mechanisms. Persistent data structures aren't just a popular convention in Clojure--the language is literally built around them.

igouy 10y ago

> And as always, lies, damn lies, and benchmarks Things change: not the same JVM as 2014, not the same Clojure. We may quote to one another with a chuckle the words of the Wise Statesman, lies, damned lies and statistics, still there are some easy figures which the simplest must understand but the astutest cannot wriggle out of. 1895 Leonard Henry Courtney