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

Pixie: A sweet Clojure-ish language

blog.goodstuff.im

Post reply on HN
Print view View original

51–60 of 109 posts

Re: Pixie: A sweet Clojure-ish language

#51

Post by unstabilo »

potatosareok wrote: post #28
fijal wrote: post #21

Earlier quoted context omitted.

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

Upvoted you because I agree. JVM has many strong points but I don't think anyone is disputing that startup time is a weakness. I've used some java tools that you invoke from a command line and I'm always slightly annoyed by how slow they are. As an aside - I was trying to reduce -Xmx to improve HelloWorld startup (lol idk...) and Xmx smaller then 1024k and it couldn't start up with less then 1024k so there's that. On…

Hello World execution time benchmark in many languages:

http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...

With Haskell:

http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...

Re: Pixie: A sweet Clojure-ish language

#52

Post by gleenn »

afandian wrote: post #22
namelezz wrote: post #4

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

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…

You can do it in Ruby with 4 parens, or even 0 if inc is really just +1. I wouldn't ever write it with so few but if we're really going down this rabbit hole then we ahould get it right.

Re: Pixie: A sweet Clojure-ish language

#53

Post by pjmlp »

jeremyjh wrote: post #50
pjmlp wrote: post #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…

.04 is user time. The elapsed time was .12 - this is how long you have to wait. Still it's a fair point: 120ms is noticeable but not painful.

Right, I looked into the wrong place.

Re: Pixie: A sweet Clojure-ish language

#54

Post by pjmlp »

weavie wrote: post #29
threeseed wrote: post #7

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…

It can call into C libraries so there is a whole other ecosystem available to it.

Yes, but Clojure can call the same C libraries, plus the JVM ones.

Re: Pixie: A sweet Clojure-ish language

#55

Post by forki23 »

forki23 wrote: post #49
afandian wrote: post #22

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…

as someone already pointed out on twitter: F#: let blubExtra a b = blub (inc a) (inc b) 4 parens.

Usually we would write it as:

let blubExtra a b = inc b |> blub (inc a)

which 2 parens less, but at the cost of using the (very idiomatic) pipe operator.

Re: Pixie: A sweet Clojure-ish language

#56

Post by pjmlp »

JackMorgan wrote: post #43
wz1000 wrote: post #39

Earlier quoted context omitted.

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.

Absolutely right, I was just comparing with the dominant Java or Python. Dependent typing is some cool stuff, I'd love to see more of it.

I have been following Idris, quite cool.

Re: Pixie: A sweet Clojure-ish language

#57

Post by andrewchambers »

masklinn wrote: post #47
pjmlp wrote: post #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…

It's unclear what machine and JVM configuration they're using. Using the JVM 1.8 (java version "1.8.0_20") on a 2010 MBP (2.4GHz i5) I get ~190ms (180~200) for their program. By comparison, on the same machine using an equivalent program - Lua 5.2.3 takes 20ms - CPython 2.7.5 takes 40~45ms - MRI 2.0.0p481 and CPython 3.4.3 clock in at 55~60ms - Pypy 2.5.0 takes 85~95ms

You are missing clojure start time which for me is over 1.5 seconds on top of the jvm start time.

Re: Pixie: A sweet Clojure-ish language

#58

Post by Gonzih »

Language and implementation both look very promising! I was looking for small footprint and fast startup modern lisp for a long time for my embed hobby projects. And finally it's here! I'm really excited about this language and where it stands now compared to when I first discovered it.

Re: Pixie: A sweet Clojure-ish language

#59

Post by bbradley406 »

NhanH wrote: post #32
namelezz wrote: 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)).

This trick is very helpful, but I would argue that there are still a lot more parentheses due to almost everything being written as a function in lisp. When I started programming in Racket arithmetic and comparison expressions tripped me up frequently. My tip to beginners in this area would be to use the dot-notation first, then switch to the standard way once comfortable. for example:

    (20 . > . (10 . / . 5))
may be more clear than

    (> 20 (/ 10 5))

Re: Pixie: A sweet Clojure-ish language

#60

Post by virtualwhys »

afandian wrote: post #22
namelezz wrote: post #4

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

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…

Scala example is wrong, wouldn't even compile; should be:

    def blubExtra(a: Int, b: Int): Int = blub(inc(a), inc(b))
The original would need an equals thrown in there, otherwise it's procedural syntax (IIRC, has been deprecated or will be in the next release) which has a return type of Unit, thus not compiling when specifying a return type of Int.

    def blubExtra(a: Int, b: Int): Int = {
      blub(inc(a), inc(b))
    }
Post reply on HN