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

101–109 of 109 posts

Re: Pixie: A sweet Clojure-ish language

#101

Post by innguest »

Elrac wrote: post #76
innguest wrote: post #74

Earlier quoted context omitted.

Tell me about it. First thing I asked when I saw HTML over a decade ago was "Oh so you can close tags out of order?" - "Uhm, no, the last opened tag must be closed first" - "Then why do I need to say its name when closing? There's no ambiguity, it's always 'close the last opened tag', so why say its name again?". Folks at W3C must not know Lisp.

I'm happy to disclaim that I have nothing to do with the mess that is the HTML standard! But if I had to guess I would say that the ending tags in HTML add a modicum of redundancy that allows for some of the crazy/creepy/smart error correction browsers have been doing for decades: 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…

> That makes HTML "code" marginally easier [...] and for programs to error-check and correct.

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.

Re: Pixie: A sweet Clojure-ish language

#102

Post by smenko »

JackMorgan wrote: post #34
smenko wrote: 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…

80% of the problems I had to deal with (in a live, real-life Clojure system that had to be maintained and supported, not a hobby-happy-slappy-project-thing) were caused by putting square pegs in a round hole. You're telling me I need to get a macro-based library and add :pre and :post conditions that check the structure of a map, as opposed to using a language with types?! Really??? Oh, and guess what, I am sure there is a Javascript library that does that too...

Re: Pixie: A sweet Clojure-ish language

#103

Post by pjmlp »

masklinn wrote: post #97
pjmlp wrote: post #95

Earlier quoted context omitted.

I get 130ms on Windows 8.1, Core Duo 2.53 GHz with jdk1.8.0_40. And 120ms If I disable the JIT. With a normal hard disk. Maybe it does take a few ms more than Lua or Python, but hardly anything significant.

> Maybe it does take a few ms more than Lua or Python 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.

I don't want to install Lua or Python just to test how long an Hello World takes, hence my "maybe".

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

Re: Pixie: A sweet Clojure-ish language

#104

Post by kyllo »

hcarvalhoalves wrote: post #96
kyllo wrote: post #86

Earlier quoted context omitted.

It really depends on the environment and culture. In Python web apps for example it's very popular to keep project configuration in Python dicts and lists, which are just Python code (as opposed to using something like YAML or JSON for config).

Popular, but an anti-pattern. People start including production configuration as a module inside the build. The Right Way (TM) is loading from env vars.

By "inside the build" do you mean in the git repo?

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.

Re: Pixie: A sweet Clojure-ish language

#105

Post by kyllo »

warfangle wrote: post #94
kyllo wrote: post #86

Earlier quoted context omitted.

It really depends on the environment and culture. In Python web apps for example it's very popular to keep project configuration in Python dicts and lists, which are just Python code (as opposed to using something like YAML or JSON for config).

Well, technically, JSON is just a Plain Old Javascript Object, with restrictions (no expressions, quoted keys).

Sort of, at least in the sense that you can eval JSON from JS code rather than having to parse it yourself. This is one of many language concepts that JavaScript cribbed from the Lisp/Scheme family of functional languages.

Re: Pixie: A sweet Clojure-ish language

#106

Post by virmundi »

ajuc wrote: post #98
virmundi wrote: post #88

Earlier quoted context omitted.

Out of curiosity which Java? OpenJDK or Oracle or IBM?

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

Thanks. I would have figured hot spot to be better.

Re: Pixie: A sweet Clojure-ish language

#107

Post by andrewchambers »

tsmarsh wrote: post #24
lmm wrote: 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.

I don't know if it would be an exact clojure clone, would need a few tweaks and the addition of native channels.

Re: Pixie: A sweet Clojure-ish language

#108

Post by Goladus »

davexunit wrote: post #81
kyllo wrote: post #70

Earlier quoted context omitted.

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 proc…

Great quote. This idea is still not too popular, unfortunately. There are a lot of folks out there that get real mad when configuration is code. Notably, sysadmins that feel forced to learn Clojure or to configure an application. "Why not XML or JSON?", they say.

Most well-designed applications will separate the administrative interface (configuration) from a programming interface (the API), even if the same langauge is used for each one. If you do this properly, most administrators are not going to care what language your configuration is in so long as it's clear and consistent.

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.

Re: Pixie: A sweet Clojure-ish language

#109

Post by Goladus »

kyllo wrote: post #104
hcarvalhoalves wrote: post #96

Earlier quoted context omitted.

Popular, but an anti-pattern. People start including production configuration as a module inside the build. The Right Way (TM) is loading from env vars.

By "inside the build" do you mean in the git repo? 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 w…

I think he means that the configuration file is on the library path is read using an import statement rather than parsed explicitly from a standard path like etc/.
Post reply on HN