
How innovative is Clojure as a Lisp dialect from Lisp expert's perspective? - myth_drannon
https://www.reddit.com/r/lisp/comments/acid7a/how_innovative_is_clojure_as_a_lisp_dialect_from/
======
hardwaresofton
Outside of applying the research of persistent immutable data structures
(which I think is from the Okasaki paper[0]), I think the most innovative part
of Clojure is the fact that it's _actually used_ \-- they've managed to build
a community and ecosystem with high quality packages and buzz around lisp.

I don't pick Common Lisp/Scheme/Racket despite desperately wanting to because
IMO Haskell has a better package ecosystem in my eyes, which is saying a lot.
For example, try and find a HTTP server (by far the most common usecase for
new projects IMO) that is both multi threaded and async IO capable (i.e.
maximally using every core) -- it's surprisingly difficult, I found decent
seeming libraries that did either-or, with varying levels of polish and
paradigms involved.

I personally prefer CL to Clojure but I just can't imagine trying to convince
an enterprise to use Common Lisp these days especially since I can't even
really convince myself... Clojure would have the same problem but the
ecosystem + buzz is the differentiator in my mind.

[0]:
[https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf](https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf)

~~~
bad_user
>> “ _I think the most innovative part of Clojure is the fact that it 's
actually used_”

Popularity is not “innovative”.

~~~
hardwaresofton
IMO it depends on the lens through which you're looking. If "Clojure" in that
sentence to you means the language and the features, then no, popularity is
clearly not an innovative feature and is basically orthogonal. It obviously
doesn't matter how popular the language is if what we're talking about is
whether it supports <language feature x>.

However, if "Clojure" in that sentence is interpreted in a wider, more general
and necessarily less concrete sense -- to represent the language, ecosystem,
branding, etc -- good marketing/advertising, community management, and general
operations-level can be rife with places to innovate.

An excellent language that never gets adopted has effectively zero value IMHO
until it's corpse is ransacked by a language that _does_ get adopted. People
rediscover things that older languages have done all the while almost every
week it seems -- creating a language and the requisite community to actually
drive adoption can be considered innovative if the rest of the rest of the
landscape is sufficiently similar. Clearly the Clojure project is doing
_something_ differently from the Common Lisp/Scheme/Racket crowd.

~~~
kbp
It's too early to say. Clojure's still very young in Lisp terms, so it's
natural that it has more hype around it now than languages that were cool 30
years ago. It's also not exactly taking over the world, and I think you're
forgetting the buzz Lisp had in the 80s. It will be an innovation in the sense
you mean if it has wide adoption and hype in 2050, but it's certainly not
anything unprecedented yet.

------
axelrosen
As a Lisp dialect it isn't that innovative besides a few syntactic
improvements [0]. I'd gladly use Common Lisp instead if it could do something
like ClojureScript. But by design it'd be hard to pull off.

Like a good politician Clojure is pretty unimpressive in of itself, for any
given characteristic, someone has a better take. But as a whole it's one of
the few sensible choices out there.

[0] I feel like they're generally underrated. Adding [] {} and #{} might not
seem like much, but when writing DSLs they really do make all the difference.

~~~
fiddlerwoaroof
Parenscript is pretty close, as is js-cl. The issue is mostly that no one has
written something like figwheel or shadow-cljs yet.

~~~
axelrosen
Never heard of js-cl, but Parenscript definitely isn't. It's a glorified s-exp
notation for javascript. ClojureScript doesn't compile to plain js. It
maintains a lot of it's characteristics at run-time. And this is possible
because Clojure does something very similar on the JVM. This in turn enables
you to write code targeting both platforms without too much effort.

WISP is a little more like the Parenscript of Clojure (though it's written in
javascript itself) [https://github.com/Gozala/wisp/blob/master/doc/language-
esse...](https://github.com/Gozala/wisp/blob/master/doc/language-
essentials.md)

~~~
fiddlerwoaroof
js-cl is a (still-partial) Common Lisp implementation in JavaScript.
[https://github.com/jscl-
project/jscl/blob/master/README.md](https://github.com/jscl-
project/jscl/blob/master/README.md)

Parenscript is a bit more than just a glorified s-expression wrapper for
JavaScript: it also implements a lot of the core CL macros (defun, let,
lambda, etc.) in ways that are close to the CL semantics. It’s limited by the
fact that it doesn’t want to have its own runtime: so, while there is some
degree of source-level compatibility, it doesn’t have things like restarts and
CLOS that would require runtime support (although, there is a library called
the Parenscript object system that provides some degree of source
compatibility with CLOS.

~~~
axelrosen
Yea, it looks like js-cl is more like it. You'd want to implement some
reasonable subset of CL. And ClojureScript really didn't have to compromise on
much, which is why it's been embraced so easily.

Most of the time you just have a .cljc file and pretty much the same exact
code just works on both platforms. In a few places you'll use the #? reader
macro that lets you do different stuff based on platform, and that's it.

Well, you basically get simple macros for free as long when you have an s-exp
based notation for something. Which is why I do in fact like them. Something
like Parenscript or Wisp is really great for lightweight websites.

I remember way back around 2010 or 2011 playing around with CL and Parenscript
a bit and it looks like the landscape isn't too different today.

------
lincpa
the best innovative: Clojure is a functional programming language based on
relational database theory.

```

    
    
                   Clojure -> DBMS, Super Foxpro
    
                       STM -> Transaction，MVCC
    

Persistent Collections -> db, table, col

    
    
                  hash-map -> indexed data
    
                     Watch -> trigger, log
    
                      Spec -> constraint
    
                  Core API -> SQL, Built-in function
    
                  function -> Stored Procedure
    
                 Meta Data -> System Table
    

```

I don’t care about static or dynamic types, nor about FP, LP, or OO. For me,
they are overly complex, unreliable, and unscientific. I think they are very
bad and upset me.

The production methods and business management ideas of large industries are
also more mature than FP&OO. I have used them as programming ideas.

I think that RMDB is the simplest and most reliable in theory and practice,
and it is the most rigorous, long-term, high-stress test in critical
situations.

Before using clojure, I was a Foxpro programmer. I used clojure as a super
Foxpro, and I also used it successfully in the field of WebApp and R language
mixed programming. I will continue to apply this routine to the AI field in
the future.

The main development goal of clojure is to write the database. The development
idea is actually from the database, not the FP.

[https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow)

~~~
flavio81
>I don’t care about static or dynamic types,(...) I think that RMDB is the
simplest and most reliable in theory and practice

But... RDMBs are often statically typed (you specify the column type when
creating it), and strongly typed (they often don't do auto-conversions of data
types.)

~~~
lincpa
With reference to the database, as long as I use spec to strictly define
(standardization) the core data model, I can ensure the correctness of the
system.

I've turned the traditional work of ensuring code correctness from in-code
type system validation to data self-validation. Turn the work into verifying
the core data model instead of validating the input and output data types of
the function.

A system requires only a few core data models, and development is built around
the core data model.

Persistent data structures ensure that the modification of the immutable big
data model are high performance and memory efficient.

In addition, using my pure function pipeline data stream
([https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow))
makes debugging, parallelism and extension very simple.

~~~
lincpa
Similar to industry, verify that all finished products meet the standards
before entering the warehouse.

Also similar to databases, verify their compliance before data enters the
database.

That is "Data as a service, Warehouse as the core, operates around it".

------
lbj
There are alot of interesting points of view in that thread, unfortunately
they're all from people who've spent very little time with Clojure.

The biggest innovation I think, its putting Clojure on the JVM allowing for
tight host integrations. This has been my way of introducing Clojure in a
number of places it wouldn't otherwise have been able to go.

In terms of writing better code, the performant immutable datastructures yield
more power than I can sum up a single comment.

~~~
jfoutz
The jvm is really nice. Operationaly, it’s kind of a pain. You can upgrade the
installation on bare metal, you can play the packer game and ship new vms, or
you can have crazy fat docker containers. K8s can sort of deal with the vm
model, but it’s beta.

Go is pretty nice in this regard. I should look into racket and chicken again
for static binaries. I gotta say “from scratch “ is a fun way to start a
dockerfile

~~~
slondr
If you want to write a program in a Lisp and ship it as a compiled binary,
your best bet is to use Common Lisp and compile it with SBCL. A stripped SLAD
binary will be way smaller with way less overhead then running a whole host of
bytecode on a VM like Racket or Clojure.

~~~
fiddlerwoaroof
sbcl also has the ability to statically link all your C dependencies using
CFFI’s STATIC-IMAGE-OP

~~~
lincpa
Clojure can also do it. Java Abstracted Foreign Function Layer
[https://github.com/jnr/jnr-ffi](https://github.com/jnr/jnr-ffi)

~~~
fiddlerwoaroof
I don't think that's exactly the same: CFFI has the ability to bind C
libraries with minimal boilerplate just like jnr-ffi does. But, in addition,
with CFFI (and sbcl built with a particular set of flags) you can generate an
CL image that only depends on GLIBC because you've statically linked all your
.so dependencies into the resulting image.

------
jlarocco
It's kind of a trick question. Clojure pulled together a bunch of ideas from
other languages and packaged them on the JVM. I'm not sure any single feature
is particularly innovative.

Lisp is well known for its ability to adopt ideas from other languages, and
most of the important Clojure features (immutable data, transactional memory,
etc.) were already available for Common Lisp and Scheme, either built-in or as
libraries.

My guess is that most Clojure users came from Java rather than another Lisp.
Moving from Java is an obvious win (IMO), but as a CL user I don't see much
reason to use Clojure.

~~~
xiaq
Scheme and CL have immutable data structures, but not persistent data
structures.

~~~
chrisseaton
But the paper that introduced the term 'persistent data structure' said they
already existed in Lisp and gave the example of a persistent queue built by
sharing the tail of an existing one with a new head?

~~~
coldtea
Doesn't have to be built-in to exist in the Lisp ecosystem.

~~~
chrisseaton
Sorry I don't understand what that means?

A Lisp list is a persistent data structure.

~~~
coldtea
A Clojure seq offers much more than that. But you can re-create it in CL, it's
just not built-in.

~~~
chrisseaton
I was replying to

> Scheme and CL have immutable data structures, but not persistent data
> structures.

And I said they do. You've said Clojure persistent data structure offer more.
Ok, but I just said they existed in Lisp and they do.

------
cmiles74
I found the conversation to be sub-par and disappointing. I also find it
discouraging that these arguments inevitably boil down to a Clojure-vs-Common-
Lisp argument. What about Racket, Guile, Chicken Scheme, etc.?

~~~
nightfly
Probably because CLojure feels the closest to Common Lisp, so it's the best
comparison.

------
deepaksurti
Vsevolod Dymokin, a known name in the CL Community, especially for his work
around NLP in CL has posted a detailed article on his views about Clojure.
[1]. Worth a read.

FWIW, when I worked in Clojure in it's early days, I disliked when it dropped
into Java stack traces and dealing with Java exceptions made dealing with
Clojure REPL not a great experience. I don't know the state of things today.

[1]: [http://lisp-univ-etc.blogspot.com/2011/11/clojure-
complexity...](http://lisp-univ-etc.blogspot.com/2011/11/clojure-
complexity.html)

~~~
harperlee
It is still far away from CL conditions, but clojure 1.10 has improved error
messages A LOT through spec (a sort of optional typing system), and the plan
is to improve it even better (cryptic error messages have been for some time
the top issues in the yearly community feedback poll).

------
nickik
I think people here are making a lot of good points put I want to be a bit
more specific. I don't have a lot of experinace with others lisps so please
correct me.

\- The EDN ([https://github.com/edn-format/edn](https://github.com/edn-
format/edn)) data format is a further development of the code is data idea.
'Tagged Literals' are interesting feature and used in Clojure to make code
shared between different Hosts, mostly JS/JVM.

\- Transducers are a new interesting features that are fairly unique to
Clojure
([https://clojure.org/reference/transducers](https://clojure.org/reference/transducers))

\- Reducers
([https://clojure.org/reference/reducers](https://clojure.org/reference/reducers))

\- Clojure Multimethods are different from CLOS in CL and one interesting
feature are stand alone hierarchies. Some people would maybe call this an step
back from CLOS.
[https://clojure.org/reference/multimethods](https://clojure.org/reference/multimethods)

\- Concurrency primitives like Agents and Refs (featuring Software
Transactional Memory) are fairly unique to Clojure.

\- Metadata. In Clojure most types can have metadata attached, meaning data
that flows threw the program with your data but does not effect things like
equality or size.

\- Protocols are dynamic single dispatch system

\- spec. Clojure Spec is a core part of Clojure now and used internally as
well. Its a type of dynamic specification system and not like most systems of
this type ([https://clojure.org/guides/spec](https://clojure.org/guides/spec))

Some more information here:
[https://clojure.org/reference/lisps](https://clojure.org/reference/lisps)

------
kccqzy
I think Clojure is certainly innovative in that it includes software
transactional memory in its core language. Scheme doesn't, Common Lisp
doesn't, and perhaps most other lisps do not. It's not very often used, but
it's a welcome addition to the core language.

~~~
bad_user
STM has nondeterministic performance characteristics and doesn’t live up to
expectations.

~~~
StreamBright
Can you elaborate? I have used it successfully in many projects. People keep
saying it has bad performance but I haven't seen any proof yet.

~~~
TeMPOraL
"Nondeterministic" doesn't mean "bad", just that things can be OK until
suddenly they aren't, and you can't really predict it a priori.

------
jwr
I think I am qualified to answer this: I wrote reasonably complex systems in
Common Lisp before I gradually moved to Clojure several years ago. I have
written several fairly large apps and systems in Clojure and Clojurescript
(this includes [https://partsbox.io/](https://partsbox.io/) as my current
project and apps like an e-commerce search engine processing hundreds of
requests per second for many years).

I used to think Common Lisp was a fantastic language, but I always tried to
keep an open mind remembering the Blub paradox. Then I started working with
Clojure and after the initial friction (some things were just plain annoying
in the beginning) things clicked for me. It was, quite simply, a much better
language.

The major improvements over Common Lisp for me were: 1) immutable data
structures: these days I can't even imagine dealing with code that mutates
data in-place, 2) a great approach to concurrency and parallelism (it's really
difficult to get yourself deadlocked in Clojure), 3) Rich Hickey coming out
every year or so with a solution to yet another problem (core.async,
transducers, spec), 4) really flexible data structures.

I know there are many CL advocates who will try to point out that CL has all
these things. But these will be the same people who will be annoyed when Java
programmers point out that Java has all these things, too. It's just a matter
of friction, elegance and ease of use.

One additional factor which is often glossed over is Clojurescript. Most
software these days exists in some form in the browser, too. Being able to use
pretty much the same language (cljc files can be compiled both server-side and
client-side to Javascript!) on both sides brings many advantages.

People sometimes ask me if I miss CLOS or the MOP. Not at all. It's a great
set of concepts, worth learning (the green book makes for great reading). But
I found that larger systems using CLOS were really difficult to understand and
follow (just following the code flow is a nightmare if you have a lot of
multimethods), and systems that used the MOP in any but the most basic ways
were intractable without a debugger. Besides, please see above what I wrote
about immutability: I'd much rather have immutable data structures.

Clojure's emphasis on functions and data, while it may be based in the 60s, is
one of the really good ideas. And Clojure is really, really good at tackling
complexity, it's just not apparent in the language design. While other
languages focus on syntax sugar, Clojure's focus is on getting things done on
a large scale. You don't see that, but things like namespaced keywords,
clojure.spec, pre/post conditions, maps, sets, all play together to allow you
to create extensible and reusable code.

Also, it's easy to discount certain solutions in Clojure as "also existing"
elsewhere, but without actually using them in real systems one often doesn't
see the full advantage. Transducers are a good example: I think they are
under-appreciated and under-utilized. Common Lisp veterans will laugh and say
that SERIES did the same thing back in the 80s. But SERIES was all about
optimization and anyone who actually tried to use it will have stories to tell
about how easy it is to use. Transducers, on the other hand, if used to build
data-processing pipelines processing Clojure maps with namespaced keys, are an
elegant and efficient tool for building composable systems. Plus, once you've
coded your pipeline using transducers, it's a snap to parallelize it.

Looking at it differently: to "get" Clojure one has to understand that there
is no silver bullet: no single revolutionary "feature". Instead, the gains
come from tiny improvements all over the place: immutable data structures,
good built-in library for dealing with them, core.async, transducers, spec,
Clojurescript, not having to convert to JSON or XML on the way to the client,
re-using the same code on server-side and client-side, and more.

In practical terms, I would never be able to write and maintain by myself the
system I'm currently working on ([https://partsbox.io/](https://partsbox.io/))
without Clojure and Clojurescript. It isn't impossible, but I can't imagine
tackling the complexity in a comparable time frame.

I can't imagine going back to Common Lisp. I sometimes have to look at the
code I've written in CL, and it looks clunky. Especially place-oriented
programming (setf all over the place) is something I really really don't want
to go back to. It's a nightmare, particularly if you intend to have any kind
of concurrency.

I still try to keep an open mind, remembering about the Blub paradox. I make
it a rule to regularly check and learn about new languages. There are some
which I found really good for certain types of applications and which I would
use instead of Clojure in certain cases (Elixir is a good example). I still
haven't found anything comparable which is a general-purpose language,
especially if you consider the client-side story — but I'm checking all the
time

See also my answer to a similar question posted on Quora several years ago:
[https://www.quora.com/What-do-veteran-Lisp-programmers-
think...](https://www.quora.com/What-do-veteran-Lisp-programmers-think-of-
Clojure/answer/Jan-Rychter)

Also, as a general observation: most (not all, but most) criticism of Clojure
seems to be written by people who did not write anything significant in it,
and much of that by people who simply do not write large software systems at
all. Reading many discussions, I gloss over most comments, as they are simply
beside the point and not even worth addressing.

~~~
fiddlerwoaroof
This is really interesting, I write mostly Common Lisp as hobby projects (at
varying levels of scale, I've submitted patches for sbcl and mcclim and I've
written a bunch of libraries) and at work I help maintain a data pipeline
written in Clojure. I've generally found that I much prefer the "feeling" of
writing Common Lisp and have come to think that immutability in the core +
being hosted on the jvm forces some compromises on the interactive development
front that make writing Clojure always feel like something of a chore.

~~~
jwr
I had similar feelings in the very beginning, but I was quickly won over (I
didn't see compromises in interactive development, though, unless you mean
difficult debugging because of lazy sequences). Debugging in general was
something I missed the most (after all, even in CL, I implemented return-from-
frame in CMUCL to get better interactive debugging). And to this day I think
CL has better interactive debugging than Clojure.

But Clojure has so many advantages that it isn't even a close contest.

Also, _most_ of the code I write today isn't hosted on the JVM, it runs in the
browser. Or gets compiled to _both_ JVM bytecode and highly optimized
JavaScript.

~~~
fiddlerwoaroof
The more I've used Clojure, the less I've liked it: protocols don't work
correctly, multimethods are badly designed, core.async isn't source-compatible
between CLJ/CLJS, unless you know what to avoid, etc.

As far as interactive development compromises go, I'm mostly thinking about
how in Clojure, it seems like the only practical way to load your new code is
to use something like tools.namespace/refresh (or whatever it is). And, that
essentially involves throwing away everything and rebuilding it from scratch:
while that has some nice properties (e.g. you don't end up with an
inconsistent image state), it's also really annoying because you have to
restart all your servers, etc.

And, the other thing that makes CL standout from every system I've used except
Smalltalks, is that Quicklisp loads third party systems into the current image
without restarting: there are a bunch of tools I've seen floating around that
claim to be able to do this for Clojure, but I've never really been able to
make any of them work consistently.

------
pfdietz
My comments from Reddit threads:

"I have not used Clojure professionally, but I welcome it, and applaud the
effort that has gone into its creation and development. It's being used to
solve real problems for real customers, and supplying jobs for those wanting
to work in a Lisp family language. I also have a personal fondness for the
immutable data structure work.

Is it perfect? Nothing is perfect. I'd rather focus on the wins than lament
blemishes."

and

"Not all of us CL people are like that, even the language lawyers who read the
standard for entertainment. :)

I find a lisp that explores a different part of design space to be inherently
interesting, btw. The constraints surrounding Clojure are different from those
around CL, so design choices have been different. The lessons learned when
these choices collide with real world users cannot be obtained in any other
way."

------
kgwxd
I think the Sequences abstraction[1] is a pretty important one. I'm not sure
it's unique to Clojure though, I have no other practical Lisp experience.

[1]
[https://clojure.org/reference/sequences](https://clojure.org/reference/sequences)

------
dustingetz
Never used Lisp, but huge Clojure user, the real innovation is the immutable
data structures:

RICH HICKEY: Ok, so, problem number one on that list was place oriented
programming. Absolutely, this is the problem. Almost all the programs I wrote,
lots of the things on that list were multi-threaded programs, you know,
they're crazy hard in C++. Just impossible to get right, when you adopt a
normal mutability approach, you know, mutable objects. So, this is the number
one self-inflicted programming problem. It seemed, you know, clear to me that
the answer was to make functional programming and immutable data the default
idiom. So the challenge I had was, were there data structures that would be
fast enough to say, "we could swap this for that". And the objective I had,
_the goal I had was to get within 2x for reads and 4x for writes. And I did a
lot of work on this, this was actually the main research work behind Clojure,
was about these persistent data structures. Eventually I found...you know I
looked at Okasaki 's stuff and, you know, the fully functional approach and
none of that gets here. And then I found Bagwell's structures were not
persistent, but I realized could be made so, and they just have tremendously
great characteristics combining the persistence with the way they're laid out,
the way memory works._ They made it. They made this bar, and I was able to get
my friend to try my programming language. You know, we (?) have large library
of pure functions to support this, and, you know, immutable local bindings.
Basically if you fall into Clojure, your first hurdle is not the parentheses,
right? It's this, this functional paradigm, everything is gone, there's no
mutable variables, there's no state, there's no mutable collections and
everything else, but there's a lot of support, there's a big library. You just
have to, you know, sort of learn the idioms. So I think this was straight-
forward, the critical thing that's different about Clojure is, by the time I
was doing Clojure, the people who invented this stuff had adopted a lot more,
right? I think most of the adherents in the functional programming community
considered functional programming to be about typed functional programming,
statically typed functional programming is functional programming. And I don't
think so, I think that this is, you know, this falls clearly in the 80/20
rule. And I think the split here is more like 99/1\. The value props are all
on this side, and I think Clojure users get a sense of that, they get a feel
for that. This is the thing that makes you sleep at night.

[https://github.com/matthiasn/talk-
transcripts/blob/master/Hi...](https://github.com/matthiasn/talk-
transcripts/blob/master/Hickey_Rich/EffectivePrograms.md)

~~~
reitzensteinm
I would go as far as to say that a language with more traditional syntax (for
instance Python style) with pervasive immutable data structures would do very
well. Few of the benefits Clojure brings to day to day development seem to
require a lisp syntax.

~~~
dustingetz
Maybe – s-expressions have a killer app though, which is that they are so
simple that the level of effort to port Clojure to other platforms
(ClojureScript, Clojure CLR, etc) is within reach of one person. I am
irrationally bullish on Clojure, but this is the key to the bet – platform
reach has network effects which I believe may outweigh in longrun the
resistance to alien syntax. My Clojure codebase
([http://www.hyperfiddle.net/](http://www.hyperfiddle.net/)) runs on JVM,
node, browsers, lambdas, and inside Datomic cluster as stored procedure. Same
code! Same library artifact! Simultaneously targeting all these different
platforms!

~~~
int_19h
> which is that they are so simple that the level of effort to port Clojure to
> other platforms (ClojureScript, Clojure CLR, etc)

I don't see why that would be at all relevant to porting to other platforms?
Most languages with richer syntax would parse to a backend-independent AST
first, and so porting to a new platform would not require touching the parsing
code at all - you'd be working on the same level as S-exprs, effectively.

~~~
dustingetz
the s-expressions make the compiler simple. Clojure the language was designed
to make portability simple. you need both

~~~
int_19h
A well-designed grammar isn't difficult to parse into S-expressions. And they
were writing compilers for languages with rich grammars (e.g. Algol-60) back
in 1960s - often in hand-written assembly, on punch cards! I think a claim
that it makes the implementation overly complex strains credulity.

------
ledgerdev
Clojure is radically practical :)

------
drcode
Lots of user names with 4-6 characters in this thread- Definitely an HN topic
of yore!

------
chii
I wonder how good clojure is with soft real-time like graphics
rendering/games, or as an embedded script engine.

~~~
dustingetz
For real-time graphics, i think there is an impedance mismatch with the GPU
data structures which are basically big mutable array buffers

~~~
agumonkey
maybe used as a dsl interface for gpu ... I don't know

~~~
dustingetz
I think you want the same datastructures moving up and down all layers of
stack, otherwise you pay a marshalling penalty at each layer which is terrible
for perf. If this is true, then we'd need to see fast immutable memory models
inside GPUs that could natively represent persistent trees (moving away from
pointers to mutable array buffers). Otherwise, the imperative way will always
be at least C times faster, which seems a dealbreaker for the trailblazing
researchers who forge the path the application layer follows.

