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

61–70 of 109 posts

Re: Pixie: A sweet Clojure-ish language

#61

Post by afandian »

gleenn wrote: post #52
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…

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.

Please feel free to contribute a Ruby example (as long as it's normal and idiomatic, this isn't a competition)! I've not written Ruby for years.

(inc was just a random function for the sake of showing invocation so it's not really fair to use operators)

Re: Pixie: A sweet Clojure-ish language

#62

Post by ds300 »

threeseed wrote: post #42
weavie wrote: post #29

Earlier quoted context omitted.

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

Which is nice. And it could definitely open up new avenues for them. But for example one of the areas that Clojure has been doing well in is the enterprise big data space which is dominated by the JVM based Hadoop ecosystem. Likewise many companies feel comfortable bringing in Clojure because they can leverage their existing Java libraries. My point was that getting rid of the JVM loses a lot of what made Clojure act…

Who got rid of the JVM? Pixie is not Clojure 2. Clojure still exists and you can use it, but now Pixie also exists and you can also use it. There is no downside unless you think developing languages which don't run on the JVM is a waste of time.

Re: Pixie: A sweet Clojure-ish language

#63

Post by afandian »

virtualwhys wrote: post #60
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…

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)) }

Thanks for the typo spot. I've not written Scala for about 5 years. Unfortunately I can't go back and edit my post.

Re: Pixie: A sweet Clojure-ish language

#64

Post by NhanH »

smenko wrote: post #27
JackMorgan wrote: post #25

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…

You're the first person I've seen that is vocal about having a truly bad experience with Clojure. Even from other people who prefer strongly typed language, I've mostly seen them expressing it as "not their taste", rather than actively dislike it. Do you mind sharing your experience and what was wrong with Clojure? You put js as an alternative, but in term of typing, js is borderline one of the worse type system out there.

Re: Pixie: A sweet Clojure-ish language

#65

Post by masklinn »

andrewchambers wrote: post #57
masklinn wrote: post #47

Earlier quoted context omitted.

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.

I'm not missing anything, I'm saying the statement

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

looks completely correct in and of itself. Clojure's startup time can be blamed for making things worse (by a fairly significant bit), but the JVM is already, without Clojure, the slowest-starting runtime I have on my machine. And that's what pjmlp objected to.

Re: Pixie: A sweet Clojure-ish language

#66

Post by lmm »

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…

Worry about -Xms rather than -Xmx for startup times.

I suspect there are ways to make it faster (e.g. there's a nashorn runner that starts up appreciably faster than "proper" java), but the main use case for java is server-side programs that run for days or weeks between restarts, so it's optimized for that use case.

Re: Pixie: A sweet Clojure-ish language

#67

Post by bmillare »

Can anyone verify if Pixie has concurrent multithreading or is it limited to greenthreads as described in the article? Based on the fact that atoms are implemented and they would not be necessary in a single threaded environment, I would guess that support for concurrent multithreading would be at least in the works, if not already possible.

Re: Pixie: A sweet Clojure-ish language

#68

Post by 616c »

I like the side-note.

> As a side note, expressing configurations in Clojure S-expressions makes a ton of sense. Clojure S-expressions provide a superset of JSON and Clojure's eval allows you to define a function to compute certain values. It's an escape hatch so that you're configuration files don't need to become accidentally Turing complete. The Turing complete nature of your configuration files is well defined as Clojure.

I had posted a while back wondering why more formats do not just derive from sexp or SXML (yes, say that out loud in the office). As I think some Lispers (I am even below beginner) cannot help but notice that if sexpr are coincidentally (I am sure it can be done without, but still, I am not sure if McCarthy and company just started with sexp or choose it specifically and held their ground beyond it was their choice) core to the lisp's homoiconic power-features, why more people do not just want sexp as the core data definiton, keep the data and program as close as possible, and just macro the data back, tossing back and forth between code and data as the division is limited.

Anyway, I like that far more intelligent people than me not only like this idea, but are encouraging it and pushing it forward.

(Yes, flame away. I know some people love Lisp and hate, I just thought it is an interesting premise; I am ready for you to throw shoes at me, HN.)

Re: Pixie: A sweet Clojure-ish language

#69

Post by fmargaine »

616c wrote: post #68

I like the side-note. > As a side note, expressing configurations in Clojure S-expressions makes a ton of sense. Clojure S-expressions provide a superset of JSON and Clojure's eval allows you to define a function to compute certain values. It's an escape hatch so that you're configuration files don't need to become accidentally Turing complete. The Turing complete nature of your configuration files is well defined as…

https://github.com/Zirak/SEN

Re: Pixie: A sweet Clojure-ish language

#70

Post by kyllo »

616c wrote: post #68

I like the side-note. > As a side note, expressing configurations in Clojure S-expressions makes a ton of sense. Clojure S-expressions provide a superset of JSON and Clojure's eval allows you to define a function to compute certain values. It's an escape hatch so that you're configuration files don't need to become accidentally Turing complete. The Turing complete nature of your configuration files is well defined as…

Steve Yegge wrote a blog post about this a few years back that I found eye-opening.

The whole nasty "configuration" problem becomes incredibly more convenient in the Lisp world. No more stanza files, apache-config, .properties files, XML configuration files, Makefiles — all those lame, crappy, half-language creatures that you wish were executable, or at least loaded directly into your program without specialized processing. I know, I know — everyone raves about the power of separating your code and your data. That's because they're using languages that simply can't do a good job of representing data as code. But it's what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they? https://sites.google.com/site/steveyegge2/the-emacs-problem

Post reply on HN