Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure will affect the way you think about programming

eli.thegreenplace.net

Post reply on HN
Print view View original

201–210 of 226 posts

Re: Clojure will affect the way you think about programming

#201

Post by lngnmn »

didibus wrote: post #155
lngnmn wrote: post #28

Why not Common Lisp or Scheme?

Its all explained here: https://clojure.org/about/rationale Here's an excerpt: Why did I write yet another programming language? Basically because I wanted: A Lisp for Functional Programming symbiotic with an established Platform designed for Concurrency and couldn’t find one.

I really appreciate narcissism and arrogance of Rich - he spent these two years (or whatever the legend says) writing Clojure 1.0 before made it public and this is what arrogance is for.

Nevertheless, even an ordinary CS student would notice, that there is literally nothing extraordinary in Clojure which was not being researched and implemented in other languages, like Erlang, Scheme (that subset of it which does not include set-car! and set-cdr!) SML and, obviously, Common Lisp. The systematizing effort and ability to deliver are exceptional.

So, I am sorry, but I am not buying these marketing slogans, because I know on which principles it has been made.

Re: Clojure will affect the way you think about programming

#202

Post by throwaway7645 »

vosper wrote: post #158
throwaway7645 wrote: post #131

Earlier quoted context omitted.

It will eventually use Chez Scheme as a backend since CISCO open sourced it. Chez is really fast and lightweight.

Does that help with the issue of outdated libraries at all (I don't know anything about Chez Scheme)?

Not an expert, but I'm guessing it could only help through increasing adoption. If Racket was blazing fast, a lot more people would consider using it and more libraries would be built and maintained.

Re: Clojure will affect the way you think about programming

#203

Post by tigershark »

yogthos wrote: post #171
tigershark wrote: post #142

Earlier quoted context omitted.

Maybe you didn't have much experience in programming before learning clojure? I never had any problems in understanding how a library worked in a language that I knew. And I have looked at the source code of quite big libraries in my life.

I've worked with Java for over a decade in the enterprise before I started using Clojure.

And which Java libraries where so complex that you could not understand them?

Re: Clojure will affect the way you think about programming

#204

Post by lispm »

lngnmn wrote: post #201
didibus wrote: post #155

Earlier quoted context omitted.

Its all explained here: https://clojure.org/about/rationale Here's an excerpt: Why did I write yet another programming language? Basically because I wanted: A Lisp for Functional Programming symbiotic with an established Platform designed for Concurrency and couldn’t find one.

I really appreciate narcissism and arrogance of Rich - he spent these two years (or whatever the legend says) writing Clojure 1.0 before made it public and this is what arrogance is for. Nevertheless, even an ordinary CS student would notice, that there is literally nothing extraordinary in Clojure which was not being researched and implemented in other languages, like Erlang, Scheme (that subset of it which does not…

It's like cooking. The ingredients are known, but the recipe makes the difference.

The particular combination/integration of features and the embedding in a Java environment is what made it liked by its target audience.

Re: Clojure will affect the way you think about programming

#205

Post by lispm »

madmax96 wrote: post #169
DigitalJack wrote: post #93

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…

Common Lisp had a lot thought put into it, but the design goals were different. One of the design goals was to support efficient compilation given various constraining dimensions: the need for speedy compilers vs. the need for delivery of applications on standard hardware. Thus a Lisp compiler should be able to generate fast code, even by using whole-program compilation. Thus the language has to take care of a wide range of possible implementations, not just one on a particular virtual machine.

Clojure OTOH has a relatively straight-forward compiler written in Java, only targetting the JVM in a standard way. The Java/JVM infrastructure for code generation (JIT), low-level optimizations (JIT), memory management, application building and delivery could be reused. With all its features and limitations (for example no TCO, fixed JVM instruction set, ...).

Common Lisp also not only provides some generic operators, but also lots of non-generic operators. One reason for that is the will for backwards compatibility (which was another goal in the Common Lisp design) and the idea that something like Common Lisp is also a low-level languages or provides at least a layer of low-level stuff, functions you would use to implement higher-level stuff.

Common Lisp is the next step in the evolution of Lisp I to Lisp 1.5 to Maclisp to Zetalisp. Thus it contains much of the core Lisp functions, stuff you can read about it the Lisp manuals from 1958 and 1960. People did not want to throw their code away, they wanted a modernized Maclisp. Thus one could port a 100kloc Lisp program from Maclisp or Zetalisp to Common Lisp without too much effort. The main operations were there.

Clojure OTOH has almost no backwards compatibility to earlier Lisp dialects. Programs can not be ported from Lisp to Clojure in a useful way. They have to be rewritten. But that was okay, since the main target were not Lisp developers, but people who wanted a language with Lisp influence in the Java/JVM eco-system (or possibly other eco-systems too).

Thus Common Lisp looks to you like it has less thought put in, where people actually struggled to be backwards compatible and modernize the language at the same time.

So Common Lisp has lots of non-generic functions, a layer of generic non-extensible functions (like the sequence layer) and a mechanism for extensible generic functions (CLOS). Something like CLOS is implemented on-top of the non-generic Lisp, with a few parts using implementation specific mechanims. One does not need to use the primitives of a different host language, because Common Lisp is already capable of hosting with its primitives.

Re: Clojure will affect the way you think about programming

#206

Post by lispm »

weavejester wrote: post #190
lispm wrote: post #183

Earlier quoted context omitted.

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 t…

I'm not talking about what is possible or what can be done. I'm talking about what is natural and promoted. See the message the article communicates:

> It promotes combinations of built-in data structures (lists, maps, vectors) over objects

I would say that this is actually the case and this article is not the only one to say that.

Re: Clojure will affect the way you think about programming

#207

Post by zmonx »

taktoa wrote: post #188
miguelrochefort wrote: post #101

Want to affect the way you think about programming? Learn Prolog.

Prolog is a programming language for turning polynomial-time algorithms into exponential ones.

And, true to form, it often works in the other direction too!

Especially with CLP(FD) and other Prolog constraints.

Re: Clojure will affect the way you think about programming

#208

Post by weavejester »

lispm wrote: post #206
weavejester wrote: post #190

Earlier quoted context omitted.

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 t…

I'm not talking about what is possible or what can be done. I'm talking about what is natural and promoted. See the message the article communicates: > It promotes combinations of built-in data structures (lists, maps, vectors) over objects I would say that this is actually the case and this article is not the only one to say that.

Yes, but as I said, using data structures over objects doesn't mean the data is unstructured. You can use lists, maps and vectors and still have a well defined and validated structure.
Post reply on HN