producing Blub code and vv.

[Hank]

Hi,

I'd like to check the interest in the community for a comprehensive
Clojure library/framework/whathaveyou that helps produce Java/Python/
Ruby/... a.k.a. "Blub" (http://www.paulgraham.com/avg.html) code, i.e.
instead of writing a Clojure program that e.g. produces web pages,
writing a Clojure program that produces a Blub program that produces
web pages. A Blub program in idiomatic, maintainable, efficient Blub
code that is.

This is obviously to enable cooperation on shared domain
knowledge/"business logic" across communities with mixed Clojure/Blub
language preferences that I expect will continue to exist for decades.
Full cooperation would then also require the framework to produce
Clojure code that embodies functionality embodied in Blub code. I'd
expect that bit to be harder to realize but also more valuable, as it
would allow drawing not only on the body of work done in Blub for
reasons of preference but also on legacy code from the dark ages when
there was no Clojure.

I'm asking this especially in light of the upcoming Clojure Conj where
there would be an opportunity to discuss this complex subject in a
"high bandwidth" :) kind of way.

Searching this group I haven't found much along those lines other than
isolated problems being tackled -- the question here rather being:
What's the furthest the the envelope can be pushed in terms of co-
opting the Blub world?

Hank

[David Nolen]

ClojureScript?

David

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

[Hank]

Mauve has more RAM? :)

On Sep 29, 9:46 pm, David Nolen <dnolen.li...@gmail.com> wrote:
> ClojureScript?
>
> David
>

[Nicolas]

Clojure has native interoperability with JVM & CLR. This mean that you
can have part of your code written in Clojure, part in Java/Jython/
JRuby if your target the JVM or C# if you target CLR. Of course you'll
not be able to mess everything like first half of a method in Clojure,
second half in java but this is going to work.

Clojurescript might bring you interroperability with JS too.

The best blurb language then is going to be java because support for
it is part of the clojure design.

But adding a new arbitrar language to this equation is going to be
very costly. Also you don't only want interroperability you want to
have a translation to idiomatic blurb code and back to idiomatic
clojure. There is no offering for this right now and this would need
lot of time to do it properly. And from my understanding, I see no
other language that bring such support you ask for. This is not a
feature that clojure lack.

Maybe its me, but I do not see it as a a top priority for clojure
language. We already have support with JVM, CLR. If required to any
language through a network protocol. With Java/Clojure combination you
can do nearly everything and have library for nearly everything too.

Life is great !

[David Nolen]

Have you actually looked at the ClojureScript compiler? In what way is
its design unsuitable for what you're proposing?

David

[Hank]

On Sep 30, 8:35 am, Nicolas <bousque...@gmail.com> wrote:
> Clojure has native interoperability with JVM & CLR.

Right, this is machine interop. What about people interop? How can a
Clojure programmer "interoperate" with a Ruby programmer? Can I chuck
some Clojure code into Google translate (http://google.com/translate)
and out comes Ruby code or vice versa? That would be nice.

> And from my understanding, I see no
> other language that bring such support you ask for. This is not a
> feature that clojure lack.

That's right, if your idea of a "lacking" feature is one that other
langauges have and therefore Clojure should have, too, this isn't the
case here. It is a feature that's "lacking" just because it would be
useful.

> Maybe its me, but I do not see it as a a top priority for clojure
> language.

That's why I posted this, to find out what the need is, how many
Clojure programmers live in inhomogeneous programming environments?
Someone just posted something like that a few hours later (http://
groups.google.com/group/clojure/browse_thread/thread/
18b13c222163dda0), though I was more thinking of the open source
communities out there and the vast amounts of code they produce, they
are easier to observe and interact with since stuff doesn't happen
behind closed doors like in the corporate world.

[Raoul Duke]

Hank,

it ain't Clojure so this might be irrelevant to you, but some
interesting cross-platform languages are: (a) www.haxe.org which is
mature, and (b) Shen http://preview.tinyurl.com/6hnjpb2 which is still
young.

sincerely.

[David Nolen]

On Thu, Sep 29, 2011 at 7:54 PM, Hank <ha...@123mail.org> wrote:

On Sep 30, 8:35 am, Nicolas <bousque...@gmail.com> wrote:
> Clojure has native interoperability with JVM & CLR.

Right, this is machine interop. What about people interop? How can a
Clojure programmer "interoperate" with a Ruby programmer? Can I chuck
some Clojure code into Google translate (http://google.com/translate)
and out comes Ruby code or vice versa? That would be nice.

Embedding V8 is becoming popular in the Ruby community. You can write ClojureScript and interoperate just fine.

David

[Hank]

No. Maintanable and idiomatic code weren't its goals, efficient maybe.
If it did in fact produce maintainable and idiomatic code that would
be an accidental byproduct. Does it?

The ClojureScript compiler was also, from what I understand, designed
to produce small programs, i.e. "one web page's worth" of JavaScript
code. I wouldn't assume that this easily scales up especially
maintainability wise.

[Hank]

Just replying to my own post here:

Something like Linj (https://github.com/xach/linj /
http://www.doiserbia.nb.rs/img/doi/1820-0214/2008/1820-02140802019L.pdf)
and the corresponding Jnil go into the right direction.

[Hank]

Thanks, but from what I can see, they enable machine interop, not
people interop. Instead of cross-platform, can you do cross-community?

[Sean Corfield]

On Thu, Sep 29, 2011 at 3:39 AM, Hank <ha...@123mail.org> wrote:
> I'd like to check the interest in the community for a comprehensive
> Clojure library/framework/whathaveyou that helps produce Java/Python/
> Ruby/... a.k.a. "Blub" (http://www.paulgraham.com/avg.html) code, i.e.
> instead of writing a Clojure program that e.g. produces web pages,
> writing a Clojure program that produces a Blub program that produces
> web pages. A Blub program in idiomatic, maintainable, efficient Blub
> code that is.

I think the major obstacle is likely to be the difference in idioms.
Any substantial idiomatic piece of Clojure is going to be almost
impossible to automatically translate to _idiomatic_ code in another
high-level language that uses different idioms. You'd also probably
have to introduce a number of "coding conventions" to constrain your
Clojure code in order to avoid "holes" in the translation.

Some questions:
* How do you translate Clojure functions in namespaces spread across
multiple files into a Java class?
* Would it even be idiomatic Java to always have classes full of only
static methods?
* What about Clojure's vast library of functions (esp. higher-order)?
* What would something like
(map (juxt :id identity) (filter (comp not nil? :data)
some-lazy-data-stream))
look like in Blub, if Blub doesn't have keywords, composition,
higher-order functions, lazy data structures?
* How would code that uses STM translate to a Blub without it?
* How idiomatic would Blub code be when Clojure uses immutable data by default?

I think it's a fascinating problem to try to solve for any given
target Blub but I'm not sure how practical it would be, i.e., how
readable the generated Blub code would be to an "average" Blub
programmer...?
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Hank]

> I think the major obstacle is likely to be the difference in idioms.
> Any substantial idiomatic piece of Clojure is going to be almost
> impossible to automatically translate to _idiomatic_ code in another
> high-level language that uses different idioms.

That could very well turn out to be the case. In the spectrum between
"fully manual" and "fully automated" I can picture scenarios like:
- Mostly manual but with some automatic assistance from the IDE: E.g.
the way Eclipse assists you in coding Java, when you press Ctrl+Space.
It doesn't automatically write code for you but it can narrow down the
choice as to what to type next.
- Most automatic but with some manual assistance from the coder: E.g.
annotate the Clojure code with hints about the idioms to translate to
in the target language. Right now in Clojure we use annotations
like :exposes-methods that aren't strictly for the Clojure
functionality itself but for Java interop. So there could be
annotations like :use-design-pattern-x that dictate the choice of
idiom/design pattern in the compilation to the target language.

> You'd also probably
> have to introduce a number of "coding conventions" to constrain your
> Clojure code in order to avoid "holes" in the translation.

It's probably a question of how unwieldy the produced code is allowed
to get. If you express the goal of "maintainability" in terms of some
metric like lines of code or whatever then I can see hard limits being
reached. If you don't put a limit on that then I don't see any danger
of holes.

> Some questions:
> * How do you translate Clojure functions in namespaces spread across
> multiple files into a Java class?

> [...]

Those are very good questions and I'd have to think about it. Maybe
I'll start a wiki somewhere so we can start collecting "translation
recipes". Generally, if the answer isn't obvious from staring at the
Clojure code, it helps to think about the problems in terms of the
bigger picture, i.e. the business logic/domain knowledge, and then
translate to Blub in the head. E.g. "I want to cache generated web
pages on the disk, how would I do this in Java?"

> * How would code that uses STM translate to a Blub without it?

I like this one in particular. People have written concurrent code
before STM. I do it in my job every day. :) How did that work with
explicit locks again??

> * How idiomatic would Blub code be when Clojure uses immutable data by default?

A good source for this is the O'Reilly book "Functional Programming in
Java". There you can see how idioms from one language can be applied
to another. I think Java code that uses a lot of immutable data, i.e.
"final" variables all around, would still be accepted by the Java
community. The produced code could even leave out the "final" keyword
in order to not cause too much clutter but still not modify the
variables. It violates the principle of least authority but I see that
in real-world code everywhere.

> I think it's a fascinating problem to try to solve for any given
> target Blub but I'm not sure how practical it would be, i.e., how
> readable the generated Blub code would be to an "average" Blub
> programmer...?

The problem may have to be solved first in order to judge the value of
the solution. My day-to-day experience and my guts tell me it's worth
it. :D

You weren't going to the Conj by any chance, were you?

[Sean Corfield]

On Thu, Sep 29, 2011 at 10:48 PM, Hank <ha...@123mail.org> wrote:
> A good source for this is the O'Reilly book "Functional Programming in
> Java". There you can see how idioms from one language can be applied
> to another.

Oh yes, I know about that book but the question is: how idiomatic is
that code in Java? You can write imperative, stateful code in Clojure
but it wouldn't be idiomatic.

> You weren't going to the Conj by any chance, were you?

Yup. Looking forward to it!

[Hank]

Addendum: Just as an example, for this here ...

> Would it even be idiomatic Java to always have classes full of only
> static methods?

... the Java-ists have an idiom ("design pattern") called singleton.
They're not static methods but once-instance classes.

[Sean Corfield]

On Thu, Sep 29, 2011 at 11:24 PM, Hank <ha...@123mail.org> wrote:
>> Would it even be idiomatic Java to always have classes full of only
>> static methods?
> ... the Java-ists have an idiom ("design pattern") called singleton.
> They're not static methods but once-instance classes.

Doesn't that kind of prove my point? :)

And, after all, isn't the Singleton design pattern only a workaround
for the fact that languages like Java don't have a built-in construct
for creating a memoized global variable? :)

See you at the Conj...

[Hank]

On Sep 30, 2:58 pm, Sean Corfield <seancorfi...@gmail.com> wrote:

> On Thu, Sep 29, 2011 at 11:24 PM, Hank <h...@123mail.org> wrote:
> >> Would it even be idiomatic Java to always have classes full of only
> >> static methods?
> > ... the Java-ists have an idiom ("design pattern") called singleton.
> > They're not static methods but once-instance classes.
>
> Doesn't that kind of prove my point? :)

Uh not sure. Let's argue about it in person in November.

> And, after all, isn't the Singleton design pattern only a workaround
> for the fact that languages like Java don't have a built-in construct
> for creating a memoized global variable? :)

http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures

[Dennis Crenshaw]

Nice article in the wiki link, the logic rings pretty true for me. Clojure is a truly powerful language and I don't want for any higher-level facilities with it yet. :)

That said, it would probably mean great strides in the "industry" if elegant Clojure code could be translated to comprehensible Java code (or to other languages.)

I feel companies use different tools all the time as long as it results in efficient generation of their lingua franca (Java, Python, Ruby, etc.) They switch languages very rarely because it takes a revolution in philosophy to unseat a considerable investment in a particular language.

If Clojure could translate itself into other languages the adoption argument would be reduced to getting someone to let you use anther tool to auto-generate boilerplate (the same way IDEs might generate Java getter/setters.) Only this tool would come with lots of parenthesis and a REPL, among other things. ClojureScript being a prime example of Clojure 'speaking' another language.

This type of feature is probably only useful as a bridge between now and when everyone in the future talks in reverse polish notation. However, I think comfortable proximity to Clojure's elegance and efficiency would help other developers slowly become acclimated to, and even secretly curious about a new way of thinking.

[Nicolas]

Hi,

Well many will agree that if you can find a good solution to this
problem this is going to be usefull. I tend to agree too.

The question is maybe can you find a good solution? My response would
be no.

Let me explain: From a theoretical point of view you can always
translate one turring complete language to one another; But if you do
that you really miss the point of using clojure instead of blurb.

Clojure isn't theorycally better. It is not. Every thing you can do in
clojure you'll be able to do in any blurb language, at soon at it is
turing complete. So this include cobol, vhdl or SQL.

If it was easy to transform easilly back and forth to idiomatic blurb
language that would mean that there is some sort of bijection between
all idiomatic feature of clojure and blurb.

But the whole point of using clojure instead of blurb here is because
clojure is a "better" or at least different language. With more
interresting abstractions than one available in blurb, at least for a
specific problem domain. So the bijection is not here.

To have this bijection the blurb language would need to be clojure
with a different syntax. We could think about common lisp but even
there... Immutability and persistent collection could be enough to
make the translation not idiomatic at all.


And this only for the language. A language is just one part of the
problem. You also need the libraries. For example GWT team had to
support a good subset of Java API to make GWT usable. To transform
back and forth would mean that you'll need a common API for both
language, that is an API that would not be idiomatic for at least one
of thoses language. More than being not idiomatic this would be an API
thoses of blurb would not be used to.


Maybe all of this is possible. After all an human can do it manually.

But I see it as more a research topic than engineering topic. With low
probability of sucess. It is a good thing to work on it then when
many things aren't here yet for clojure?

Best Regards,

Nicolas.

[Hank]

Thanks for writing, I think this here sums it up nicely:

> Maybe all of this is possible. After all an human can do it manually.

I have a background in machine learning/artificial intelligence ...
and yes I can see those things come in handy here.

> But I see it as more a research topic than engineering topic. With low
> probability of sucess.

Well, some people are enticed by "research" and "high risk". :)