Live data from Hacker News

Pixie: A sweet Clojure-ish language

blog.goodstuff.im

31–40 of 109 posts

Re: Pixie: A sweet Clojure-ish language

#31

This seems like bit of a short sighted move not that I disagree with it. Project Jigsaw which will be a big part of Java 9 aims to make the JVM more modular which will reduce the memory footprint substantially. Personally I would like to see a version of Clojure that targets this JVM specifically and abandons backwards compatibility. Leaving the JVM means you abandon the decade of libraries many of which you simply c…

In fact JVM is pretty fast. If you run a simple java app without dependencies and only displaying "Hello world" it will run in about 1s on modern hardware. The problem with Clojure is AFAIR related to parsing and loading a big number of namespaces which is quite slow.

> If you run a simple java app without dependencies and only displaying "Hello world" it will run in about 1s on modern hardware.

> time for x in $(seq 1 100); do ./helloworld.py ; done

    real    0m1.240s
    user    0m0.902s
    sys     0m0.343s
That's reasonably fast.

Java for comparison:

> time for x in $(seq 1 100); do java Hw; done

    real    0m4.952s
    user    0m4.051s
    sys     0m1.071s
And I had to compile java first. Still, I expected worse from java TBH.

Re: Pixie: A sweet Clojure-ish language

#32
post #4

Dynamic typing and parentheses are what keep me away from Clojure or Lisp like languages. How can I get over them?

I don't know where this trick come from, but I've read it a long time ago, and you might find it helpful.

Lisp languages in fact have the same(ish) amount of parentheses as any other language, the trick is that the placement slightly differ: the opening parentheses come before the function name, rather than after it. Ie foo(bar) => (foo bar) . foo(bar(baz)) => (foo (bar baz)).

Re: Pixie: A sweet Clojure-ish language

#33
post #30

Earlier quoted context omitted.

There aren't many languages that have radically fewer parentheses than Clojure / LISP. Clojure: (defn blub-extra [a b] (blub (inc a) (inc b))) 8 parens + 2 brackets Scala: def blubExtra(a: Int, b: Int): Int { blub(inc(a), inc(b)) } 8 parens + 2 braces Java: Integer blubExtra(Integer a, Integer b) { return blub(inc(a), inc(b)); } 8 parens + 2 braces Ruby: def blubExtra(a, b) blub(inc(a), inc(b)) end 8 parens Python: d…

I think it's the positioning of them that makes them stand out to people, plus the fact that they tend to bunch up at the end of things.

Of course, I know. But most people express it as 'too many parens', without (I believe) actually thinking too hard. I was just trying to provoke a few thoughts!

The position of parens is something to get used to, but then again so is Python's indentation, Scala's type system, etc etc. Every language has something unique to get used to.

Re: Pixie: A sweet Clojure-ish language

#34
post #27

Earlier quoted context omitted.

I think Clojure is actually a lot safer by default than most people expect for a Lisp. Check out this comparison I wrote up between C#(or Java), F#, Clojure, and JavaScript on common edge case safety. http://deliberate-software.com/programming-language-safety-a... In most ways I care about, Clojure is actually safer than C#. Now, if you're coming from an ML HM language, sure, you'll be taking a step back perhaps.

Clojure is horribly unsafe. I spent a year writing Clojure and half the time we were fixing bugs where someone had wrapped a map in another map or changed the shape of a data structure. For all that's worth, I'd rather use Javascript. To add insult to injury (the amount of wasted time on something that could be easily checked by a compiler and a sane type system) there's all the bad habits you acquire and the general…

Sounds like you needed Schema, which can ensure the shape and contents of a map as :pre and :post assertions in every function you annotate, then be turned off for production use. https://github.com/Prismatic/schema

That's why I come back to Clojure every time, if I need anything, it's available as a library. Need better typesafety? Just add in what you need with a macro or two. (Schema is not much more than that).

That's not really possible easily with Javascript, and Javascript has a lot more unsafe by default edge cases than Clojure. I'm not sure why if a mostly safe dynamic language bothers you, you'd now prefer an extremely unsafe dynamic language?

Lastly, types only give you a single dimension of safety, is this that exact shape, and ensuring I don't put a square peg into a round hole: both of which Schema adds in easily. Clojure is ALSO safe along many other dimensions, like thread saftey, immutably, null reference exceptions, etc.

Re: Pixie: A sweet Clojure-ish language

#35
post #24
post #18

Earlier quoted context omitted.

Embedding an immutable language in a mutable one is a recipe for awkwardness - how would you expose host-language things to the inner language? Better to do it the other way around - mutable scripting language embedded inside immutable host.

Clojure is an immutable language built on top of mutable hosts. Interop is handled beautifully. A go hosted Clojure (gojure?) would probably be fine.

Calling Clojure from Java is not remotely what I would call beautiful; it's a lot of Strings and pain (especially when you compare to calling Scala from Java). Calling Java from Clojure is substantially more elegant (it requires a structured FFI but Clojure is good at those).

Re: Pixie: A sweet Clojure-ish language

#36
post #27

Earlier quoted context omitted.

Clojure is horribly unsafe. I spent a year writing Clojure and half the time we were fixing bugs where someone had wrapped a map in another map or changed the shape of a data structure. For all that's worth, I'd rather use Javascript. To add insult to injury (the amount of wasted time on something that could be easily checked by a compiler and a sane type system) there's all the bad habits you acquire and the general…

Sounds like you needed Schema, which can ensure the shape and contents of a map as :pre and :post assertions in every function you annotate, then be turned off for production use. https://github.com/Prismatic/schema That's why I come back to Clojure every time, if I need anything, it's available as a library. Need better typesafety? Just add in what you need with a macro or two. (Schema is not much more than that). T…

Oh, god, thanks for reminding me about the whole agent/atom/ref hell - another reason I'd rather erase the whole Clojure experience from my brain altogether...

Re: Pixie: A sweet Clojure-ish language

#37
post #21

Earlier quoted context omitted.

In fact JVM is pretty fast. If you run a simple java app without dependencies and only displaying "Hello world" it will run in about 1s on modern hardware. The problem with Clojure is AFAIR related to parsing and loading a big number of namespaces which is quite slow.

1s to print hello world is an awful lot I would like to point out.

Sure it's a lot, but clojure startup times are significantly longer than that.

Re: Pixie: A sweet Clojure-ish language

#38

This seems like bit of a short sighted move not that I disagree with it. Project Jigsaw which will be a big part of Java 9 aims to make the JVM more modular which will reduce the memory footprint substantially. Personally I would like to see a version of Clojure that targets this JVM specifically and abandons backwards compatibility. Leaving the JVM means you abandon the decade of libraries many of which you simply c…

From the README

> Although parts of the language may be very close to Clojure (they are both lisps after all), language parity is not a design goal. We will take the features from Clojure or other languages that are suitable to our needs, and feel free to reject those that aren't. Therefore this should not be considered a "Clojure Dialect", but instead a "Clojure inspired lisp".

And I agree that seeing maybe Clojure 2.0 abandon backwards compatibility with Java < 9 would be nice.

Re: Pixie: A sweet Clojure-ish language

#39
post #27

Earlier quoted context omitted.

Clojure is horribly unsafe. I spent a year writing Clojure and half the time we were fixing bugs where someone had wrapped a map in another map or changed the shape of a data structure. For all that's worth, I'd rather use Javascript. To add insult to injury (the amount of wasted time on something that could be easily checked by a compiler and a sane type system) there's all the bad habits you acquire and the general…

Sounds like you needed Schema, which can ensure the shape and contents of a map as :pre and :post assertions in every function you annotate, then be turned off for production use. https://github.com/Prismatic/schema That's why I come back to Clojure every time, if I need anything, it's available as a library. Need better typesafety? Just add in what you need with a macro or two. (Schema is not much more than that). T…

I agree with most of what you said, but

> Lastly, types only give you a single dimension of safety.

Dependent types can express a huge number of things, and are often limited only by your ability to describe what exactly you want.

Re: Pixie: A sweet Clojure-ish language

#40
> And the JVM has the slowest startup time of any runtime I've ever encountered.

Blame Clojure not the JVM.

https://nicholaskariniemi.github.io/2014/02/11/jvm-slow-star...

Besides if 0.04s is still too slow, there are quite a few (commercial) AOT compilers to native code available.

However, Pixie does look quite cool.

What I am missing in Clojure is the ability to take advantage of type metadata to compile it AOT to Android Dalvik/ART friendly bytecode.

Apparently not even 1.7.0 will fix the performance issues.

Post reply on HN