
Pixie: A sweet Clojure-ish language - coding4all
http://blog.goodstuff.im/pixie
======
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.)

~~~
coding4all
Once you use Clojure's EDN, you start to cringe when you see JSON.

Spec - [https://github.com/edn-format/edn](https://github.com/edn-format/edn)

Walkthrough - [http://www.compoundtheory.com/clojure-edn-
walkthrough/](http://www.compoundtheory.com/clojure-edn-walkthrough/)

~~~
616c
I was excited to hear someone's Guile Scheme answere to Sinatra, Artanis (yes,
I know, cute), led me to the Summer of Lisp winner list, including this of
course and the Learn You a Datalog guy. Naturally, that led me to EDN.

Thanks for reminding my to finished the EDN docs.

[http://www.learndatalogtoday.org/](http://www.learndatalogtoday.org/)

------
threeseed
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 can't get on any other platform (in particular for the enterprise).
Given that Clojure has been gaining a lot of ground in these large companies
it seems like a missed opportunity.

~~~
mateuszf
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.

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

~~~
potatosareok
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 my windows computer (also I barely know what I'm doing so probably even
timing it wrong).

    
    
      [Mon Mar 09 03:22:31 zebra@ZEBRA:~ ]
      $ time a.exe
      Hello, world
      real    0m0.098s
      user    0m0.015s
      sys     0m0.015s
      [Mon Mar 09 03:22:34 zebra@ZEBRA:~ ]
      $ time java Hello
      Hello, world!
    
      real    0m0.285s
      user    0m0.000s
      sys     0m0.031s

~~~
lmm
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.

~~~
kyllo
_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._

Unfortunately for the folks who still have to use Java desktop software
written in Swing.

------
pjmlp
> 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...](https://nicholaskariniemi.github.io/2014/02/11/jvm-slow-startup.html)

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.

~~~
jeremyjh
.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.

~~~
pjmlp
Right, I looked into the wrong place.

------
weavie
> There are some things that I would like to see from/in Pixie...

> Some form of package distribution support... could this be piggy-backed on
> Clojars?

There is Dust :

[https://github.com/pixie-lang/dust](https://github.com/pixie-lang/dust)

which pulls packages from Github.

------
kra34
I'm already replacing my project's ancient Go and Rust based services with
Pixie powered end points!

~~~
namikaze
Could you elaborate some points that motivated you to switch from go? What
would be next?

~~~
felixgallo
This week's hottest language is SVIRFNEBLIN. It's got everything: privilege
escalators, compile-to-malgeboge, mini-hdmi, and that thing where your types
are all fragments of Sapphic erotic literature!

~~~
picks_at_nits
Oh, Stefon, don’t ever change.

------
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.

~~~
davexunit
You should check out Scheme implementations like Guile and Chicken.

------
andrewchambers
I want to see a clojure clone embedded as a Go scripting language. The
immutability means that the interpreter would be mostly threadsafe, and thus
would support goroutines well.

~~~
lmm
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.

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

~~~
lmm
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).

------
agumonkey
Direct link to pixie's github [https://github.com/pixie-
lang/pixie](https://github.com/pixie-lang/pixie)

------
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.

------
gigasquid
A quick video if you want to see pixie startup time in action
[https://www.youtube.com/watch?v=LlDQTLRrcZI](https://www.youtube.com/watch?v=LlDQTLRrcZI)

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

~~~
afandian
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:

    
    
        def blubExtra(a, b):
            return blub(inc(a), inc(b))
    

8 parens, one colon

C:

    
    
        int blubExtra(int a, int b) {
            return blub(inc(a), inc(b));
        }
    

8 parens + 2 braces

It's roughly the same numbers of brackets (or equivalent) in Clojure, Scala, C
and Java. A bit less in Python and Ruby.

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

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

