Pixie: A sweet Clojure-ish language
blog.goodstuff.im
blog.goodstuff.im
> 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.)
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
In my experience, the main annoyance using programming languages for configuration is the need to use explicit string literals for every string in your file. List separators are another major source of clutter in configuration files, though this is theoretically not a problem in clojure. The second problem is the tendency to be undisciplined and allow too much program logic in configuration files resulting in complex and unclear relationships between options and behavior.
Personally I do all my configuration in yaml now. Even if I was using lisp I would use yaml whenever possible for configuration and static resource definitions, because yaml is very portable.
The Right Way (TM) is loading from env vars.
Because there isn't really a such thing as a "build" for a Python web app, it's a dynamic language. It's not like Java where you'd have to recompile the whole app if you packaged your config inside the compiled jar.
In Django apps, there's an env var called DJANGO_SETTINGS_MODULE that points to one of multiple settings.py files, and you change that var depending on which environment you're working in. Then typically you also would want to store individual variables that need to be secure (stuff like any secret keys and database credentials) in env vars, but the overall structure of your config is just a python dict in settings.py.
For reasons that Yegge touches on in the blog post I linked above, you really want a tree structure for configuration of any complexity, and env vars don't provide that.
Spec - https://github.com/edn-format/edn
Walkthrough - http://www.compoundtheory.com/clojure-edn-walkthrough/
Thanks for reminding my to finished the EDN docs.
You can close your P tags or not; if you don't, the next opeining one is a new paragraph, with the previous one assumed closed. Similarly with LI tags in lists or the multiple levels of stuff in TABLE.
That makes HTML "code" marginally easier (at least in terms of effort) for humans to write and maybe also read, and for programs to error-check and correct. It's also led to waves of shitty HTML code and generations of smarter programs to guess the intentions of stupid HTML generators.
XML, being more strictly defined, could have followed the lead of Lisp and done without the closing tags. I guess people felt the need for a security blanket of closing-checkable tags, or its slightly better human-readability.
This is a great point. It's not subjective and I'm pretty sure it's right. I hadn't thought of that. I guess there is a use for redundancy sometimes. If the point is to make the language welcoming to beginners then this decision makes sense.
I wonder, though, if they made the same mistake that the SQL people did, in devising a language with characteristics that are advantageous to some imagined target group ("non-programmers") but that ends up getting used just by programmers who then hate the training wheels.
HTML (well, SGML, in this case) was designed for humans hand-authoring large documents. If your opening tag is a few hundreds lines above the closing tag, a little redundancy is handy.
Remember, HTML is a markup format, not a data format. Tags were designed to add a bit of data to what is otherwise a plaintext document intended for human consumption.
if whatever
...
end # whatever
(p
...(bunch of stuff inside p)...
) ; p
Folks at W3C want to fix all kinds of non-existing problems (like HTML5 canvas when there's already OpenGL viewports).
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.
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.031shttp://lists.nongnu.org/archive/html/chicken-users/2011-03/m...
With Haskell:
http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...
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.
Unfortunately for the folks who still have to use Java desktop software written in Swing.
> time for x in $(seq 1 100); do ./helloworld.py ; done
real 0m1.240s
user 0m0.902s
sys 0m0.343s
Java for comparison:
> time for x in $(seq 1 100); do java Hw; done
real 0m4.952s
user 0m4.051s
sys 0m1.071s
> java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)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 actually successful.
> 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.
Pixie is not officially connected to Clojure in any way.
The creator has been involved in Clojure's development, and is remixing parts he likes into a new language and platform. I would peg this more as a research project that the Clojure team could take some pointers from.
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.
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
> 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.
With a normal hard disk.
Maybe it does take a few ms more than Lua or Python, but hardly anything significant.
Yeah, like 3 to 6 times longer.
> but hardly anything significant.
Well if 6x is not significant, surely Clojure's second start time is hardly significant.
Even if I am wrong, 6x here means 130ms, whereas Clojure time is in the order of seconds.
Big enough to warrant a few entries on their roadmap.
http://dev.clojure.org/display/design/%27Lean%27+Runtime
http://nicholaskariniemi.github.io/2014/02/25/clojure-bootst...
> Some form of package distribution support... could this be piggy-backed on Clojars?
There is Dust :
https://github.com/pixie-lang/dust
which pulls packages from Github.
Clojure:
(defn blub-extra [a b]
(blub (inc a) (inc b)))
Scala:
def blubExtra(a: Int, b: Int): Int {
blub(inc(a), inc(b))
}
Java:
Integer blubExtra(Integer a, Integer b) {
return blub(inc(a), inc(b));
}
Ruby:
def blubExtra(a, b)
blub(inc(a), inc(b))
end
Python:
def blubExtra(a, b):
return blub(inc(a), inc(b))
C:
int blubExtra(int a, int b) {
return blub(inc(a), inc(b));
}
It's roughly the same numbers of brackets (or equivalent) in Clojure, Scala, C and Java. A bit less in Python and Ruby.
def blubExtra(a: Int, b: Int): Int = blub(inc(a), inc(b))
def blubExtra(a: Int, b: Int): Int = {
blub(inc(a), inc(b))
}(inc was just a random function for the sake of showing invocation so it's not really fair to use operators)
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.
F#:
let blubExtra a b = blub (inc a) (inc b)
4 parens.
let blubExtra a b = inc b |> blub (inc a)
which 2 parens less, but at the cost of using the (very idiomatic) pipe operator.
S-expressions are uniform in that they all look the same way. This means you have one form for literally everything in the program and you will have no problem parsing that form. It makes reading, mentally parsing and editing easier because everything is neatly delimited by parentheses.
In terms of readability, do you have any particular difficulties parsing the following code?
(define (sum/recursive lst [sum 0])
(if (null? lst)
sum
(sum/recursive (rest lst)
(+ sum (first lst)))))
We use a default value of 0 for a function parameter called sum to store the sum. When the input list is empty ('(null? lst)' returns true) we return that variable. There is no return keyword, we just specify that variable and it will be returned.
If the list isn't empty, we apply sum/recursive on the rest of the list and as a second parameter we add the first number in the list to the already accumulated sum ('(+ sum (first lst))'). Using matching parens in your editor will make it obvious when you have matched the right amount of parens.
It should be noted that Racket, this Lisp variant, uses '[]' as well to delimit certain parts, for readability.
In any case, the bigger part of the being productive in a codebase is to figure out how it encodes the domain, what idioms and patterns are favoured etc. So sometimes, it's just not worth adding another source of aggravation for "new arrivals".
When you compare Clojure to other lisps, I think you'd agree it's more discriminable, given the plethora of literals that dont use parenthesis: vectors [1 2 3] sets #{1 2 3} maps {:key "value" :name "Bryan"}
I guess I need a clojure mentor for the first non-trivial project. There really isn't that much idiomatic web-related code out there to read, and with clojure there is also quite a lot of variation in how systems get designed (b/c of the power and expressiveness available).
This is not an excuse, just noting the factor that has turned out to slow me down. If i had more leisure time I'd just power through and build stuff until I arrived (through trial and error) at my own sense of best-practices / design tradeoffs. That has yet to happen but will someday.
If you treat the language as a user interface to your computer, shouldn't things that do different things have different appearances, to help you distinguish them at a glance?
Like you say, with training, the differences are probably not that big a deal, but I don't think they are something to completely ignore, either.
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.
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.
> 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.
Dependent typing is some cool stuff, I'd love to see more of it.
There are some people using some of extensions for Haskell inspired by "dependently typed" systems in production.
Dependent typing is an active research topic right now, and I doubt any fully fledged dependently typed language is used "in production".
However, I was just pointing out that it is possible for types to express a wide variety of things that we do not normally associate with them. Even without full dependent typing, Haskell types are wonderfully expressive and powerful.
There are 3 concepts that are all diffrent, and a couple yours ago core.async was added. All in all thats a amazingly simple and powerful combination. Everybody I have heard is pretty happy with these tools. What is your problem?
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)).
(20 . > . (10 . / . 5)) (> 20 (/ 10 5)) [1] http://docs.racket-lang.org/ts-guide/
[2] http://docs.racket-lang.org/guide/contracts.html?q=contractsWith Clojure/Lisp languages you are basically starting from the beginning. Most of the approaches you would take to constructing your applications don't work. It just takes a lot of practice for you to recognise patterns and then both the typing and parentheses will seem natural.
(Can't help you on the brackets. I mostly stick to Scala myself)