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

Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

anmonteiro.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#61

Post by lispm »

grzm wrote: post #48
lispm wrote: post #46

Earlier quoted context omitted.

To me 'fast' means more than startup time. The headline is just clickbait. The time you are reporting is also not that 'fast'. Other tools start in a fraction of that time.

sbcl isn't Clojure, is it? Or am I mistaken? I don't see the article or its title comparing it to repls in general. Edit: original comment mentioned sbcl and included sbcl repl start-up time.

Better title would be:

'less slowest starting Clojure REPL of three'

Mentioning 'fastest' at a time of 3GHZ multicore machines with SSD and a duration of 0.1 seconds is just absurd. That's >100 million instructions just to start a language prompt and evaluating a symbol to itself. The Java version is even more absurd with around 1 billion instructions just to get a REPL...

A shell on a 1 MIPS DEC VAX 11/780 started faster, while the machine had a hundred users.

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#62

Post by lispm »

fnordsensei wrote: post #52
lispm wrote: post #46

Earlier quoted context omitted.

To me 'fast' means more than startup time. The headline is just clickbait. The time you are reporting is also not that 'fast'. Other tools start in a fraction of that time.

What tools? What are you comparing it to?

Basically any self respecting scripting language starts at a fraction of the time of the 'world fastest Clojure REPL'.

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#64

Post by rcarmo »

spinningarrow wrote: post #50
rcarmo wrote: post #24

Earlier quoted context omitted.

Erm. No. I'd pay not to use npm at all.

Why? You can use it not at all for free!

Because the whole npm system is broken, and I wish yarn would break apart and start anew.

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#65

Post by lispm »

patrec wrote: post #57
berdario wrote: post #32

Earlier quoted context omitted.

I'm afraid I don't have a satisfactory answer for you. I just prefer to pass around functions/closures as values, and being able to invoke them like any normal function, instead of having to call an helper `apply`/`invoke`/`call` function on them (depending on the language) That's why I said: "maybe more apt"... if OP doesn't care at all about that difference, and it's not among the details that they'd want to replic…

I never found the funcall argument terribly convincing, because there is no reason it couldn't be much more concise. And it allows you to avoid silly variable names like lst or fst. In Common lisp to refer to a function as a variable you do (function f) or as (read-table) syntactic sugar #'f. You could easily use destructuring to write HOFs without funcall. So instead of requiring people to write (defun bad-map (f li…

In Common Lisp in your first example it's not

   (funcall #'f (first list) ...)
but

   (funcall f (first list)) ...
f is already a function object.

We could write a macro for that or a new version of defun. Here just a macro lisp1fy:

    (defmacro lisp2fy ((&rest calls) &body body)
      `(flet (,@(loop for (f . args) in calls
                  collect `(,f ,args (funcall ,f ,@args))))
         (declare (inline ,@(loop for (f . nil) in calls collect f)))
         ,@body))


    (defun bad-map (f list)
      "Maps function `f' over `list', inefficiently."
      (lisp2fy ((f a))
        (when list
          (cons (f (first list))
                (bad-map f (rest list))))))

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#66

Post by didibus »

iagooar wrote: post #58
bpicolo wrote: post #47

Earlier quoted context omitted.

The erlang ecosystem has new-found life with Elixir. The ecosystem for Elixir is rock-solid. Very high quality libraries abound.

Absolutely. The level of robustness is outstanding for such a new language / ecosystem.

To be fair, and I find this to be a bit of a shame, but most of that robustness and ecosystem comes straight from Erlang, which was always solid. Though I do enjoy the consistency that Elixir brings and the improved macros. I'm a Clojure guy, so I also love the protocols.

Just wanted to say that Erlang vanilla is robust and has a great ecosystem. So Elixir builds itself on top of a solid foundation.

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#68

Post by wcummings »

mac01021 wrote: post #42
iagooar wrote: post #2

Sometimes I think Clojure should have been developed on top of the ErlangVM instead of the JVM. I think that the ErlangVM solves a lot better the problems that Clojure is trying to solve. Also, seems like targeting the ErlangVM is an achievable feat, since Elixir in its version 1.3 has proven to be extremely solid. Crazy idea: if I wanted to implement Clojure on top of the ErlangVM, where should I start?

I think shared memory is foundational to Clojure's approach to concurrency, and that is something the Erlang VM cannot provide. So some main fixtures of Clojure's standard library, like atoms, STM, agents, become either useless or nonsensical. It's also not clear to me wether the Erlang VM provides what Clojure needs to efficiently implement its user-defined types, protocols, etc That said, a Clojure-like dialect of…

Mnesia is sorta like STM in Erlang.

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#69

Post by mateuszf »

anmonteiro90 wrote: post #59
mateuszf wrote: post #55

Earlier quoted context omitted.

How do you specify which npm packages / versions do you want to use?

Just like you'd do in Node. Add deps to a package.json and npm install. Then just `(js/require "your-package")`

That's great. Thanks.

Re: Lumo – A fast, standalone ClojureScript REPL that runs on Node.js and V8

#70

Post by amelius »

mac01021 wrote: post #42
iagooar wrote: post #2

Sometimes I think Clojure should have been developed on top of the ErlangVM instead of the JVM. I think that the ErlangVM solves a lot better the problems that Clojure is trying to solve. Also, seems like targeting the ErlangVM is an achievable feat, since Elixir in its version 1.3 has proven to be extremely solid. Crazy idea: if I wanted to implement Clojure on top of the ErlangVM, where should I start?

I think shared memory is foundational to Clojure's approach to concurrency, and that is something the Erlang VM cannot provide. So some main fixtures of Clojure's standard library, like atoms, STM, agents, become either useless or nonsensical. It's also not clear to me wether the Erlang VM provides what Clojure needs to efficiently implement its user-defined types, protocols, etc That said, a Clojure-like dialect of…

How about targeting Go instead?
Post reply on HN