LFE: Lisp Flavored Erlang
1–10 of 33 posts
Re: LFE: Lisp Flavored Erlang
#2Re: LFE: Lisp Flavored Erlang
#3LFE is really cool, but I think the biggest thing that LFE has going against it in terms of mainstream/industry adoption is that Elixir is _roughly_ a Lisp (pretending it's not). LFE is competing against a language that has some _very_ well polished edges, and IMO it doesn't feel like LFE brings to much to the table for industry over the Lisp-y features that Elixir already has[0][1][2][3][4].
What I'd really like to see is a Mix LFE compiler[7] that lets you write LFE modules in a bigger Elixir project[5], plus a set of mix tasks like `mix lfe.repl` that integrates with the other BEAM components of your Mix projects.
Long term I think it would be cool if the BEAM community comes together around the excellent tooling (mix, ExUnit, Iex) that the Elixir Team is bringing, I'd love to see other BEAM languages (LFE, Gleam[6]) with top notch integrations that let a mix project include them side by side.
I think the BEAM is a really cool piece of technology, and many of these new BEAM languages offer pretty neat advantages, I'm excited to see the interop story grow over time
[0] https://elixir-lang.org/getting-started/meta/macros.html
[1] https://elixir-lang.org/getting-started/comprehensions.html
[2] https://elixir-lang.org/getting-started/protocols.html
[3] https://elixir-lang.org/getting-started/basic-types.html#lin...
[4] https://elixir-lang.org/getting-started/basic-types.html#ano...
[5] This exists, but looks unmaintained https://hex.pm/packages/mix_lfe
Re: LFE: Lisp Flavored Erlang
#4Can someone direct me to some code where I can see the full potential of Lisp?
I have programmed in Scheme before while taking a course using SICP. Final project was a Scheme interpreter. But I didn't have any epiphany/awakening like many others seems to have.
Re: LFE: Lisp Flavored Erlang
#5Can someone direct me to some code where I can see the full potential of Lisp? I have programmed in Scheme before while taking a course using SICP. Final project was a Scheme interpreter. But I didn't have any epiphany/awakening like many others seems to have.
I think you will have to program with it to get it. It's not so much about a final, static copy of code that you can look at and be amazed, but more about how fluid and well oiled the journey there was.
Try to build something with Clojure (bit easier to get started with than LFE, Common Lisp or others, except maybe Racket) and try to focus on a REPL heavy flow (with integration with your favorite editor) to see the full potential of Lisp.
Re: LFE: Lisp Flavored Erlang
#6Also related is clojerl which is Clojure running on Erlang VM: https://github.com/clojerl/clojerl (http://clojerl.org/)
Some past submissions of clojerl:
Re: LFE: Lisp Flavored Erlang
#7Can someone direct me to some code where I can see the full potential of Lisp? I have programmed in Scheme before while taking a course using SICP. Final project was a Scheme interpreter. But I didn't have any epiphany/awakening like many others seems to have.
> Can someone direct me to some code where I can see the full potential of Lisp?
There's exists no code that shows the full potential of Lisp because its potential lies not in the code itself, but in the way of working with it.
The language is interactive and image-based, meaning that you do not program in it by passing code through a compiler into executables, but instead you modify the running Lisp image until it contains the program you want. This is usually done by connecting the editor to the running Lisp image and sending commands to it: usually that is to compile-and-load (or compile-and-replace) individual forms/functions/variables, or whole files, or whole systems, or to work with the read-eval-print loop, or to interactively inspect objects, or to interactively resolve signaled errors via the debugger. This provides a lot of introspection into how the Lisp image and the program contained within works, and drastically reduces the feedback loop since the overhead of compiling-and-loading individual functions or even whole files is unnoticeable.
Disclosure: I am a Common Lisp programmer.
Re: LFE: Lisp Flavored Erlang
#8Can someone direct me to some code where I can see the full potential of Lisp? I have programmed in Scheme before while taking a course using SICP. Final project was a Scheme interpreter. But I didn't have any epiphany/awakening like many others seems to have.
> Can someone direct me to some code where I can see the full potential of Lisp? There's exists no code that shows the full potential of Lisp because its potential lies not in the code itself, but in the way of working with it. The language is interactive and image-based, meaning that you do not program in it by passing code through a compiler into executables, but instead you modify the running Lisp image until it c…
Yeah but none of what you said applies to Scheme.
Re: LFE: Lisp Flavored Erlang
#9Earlier quoted context omitted.
> Can someone direct me to some code where I can see the full potential of Lisp? There's exists no code that shows the full potential of Lisp because its potential lies not in the code itself, but in the way of working with it. The language is interactive and image-based, meaning that you do not program in it by passing code through a compiler into executables, but instead you modify the running Lisp image until it c…
Yeah but none of what you said applies to Scheme.
The question was about Lisp in general, or at least I read it that way. If I misread, then I'll nonetheless leave describing Scheme paradigms to someone who knows something substantial about Scheme programming; I'm not that person.
Re: LFE: Lisp Flavored Erlang
#10Can someone direct me to some code where I can see the full potential of Lisp? I have programmed in Scheme before while taking a course using SICP. Final project was a Scheme interpreter. But I didn't have any epiphany/awakening like many others seems to have.
Lisp has two big ideas. The first big idea is that a regular syntax allows the trivial implementation of macros. Just have a separate compilation where the AST is passed in as a list to different macros and then compile the result.
The second idea (not shared by the some Lisps like Scheme) is that of a system image which is modified in real time. This allows on the fly debugging, adding of new features, etc with no downtime.
Macros have worked there way into languages like Julia or Nim, while the system image idea is mostly constrained to Smalltalk and Common Lisp.
The best example of the power of macros is Racket, which has world class meta programming facilities and is probably the best language in existence for creating new languages, DSLs, and doing experimental PL research.
I've used both CL and Racket professionally, and they both shine in certain situations.
That being said, I've grown tired of the relative verbosity of both languages (minimal syntax has a high cost) and the performance and productivity cost of dynamic typing.
For most new engineering projects, I'd much rather use something like OCaml or Scala than CL or Racket. For scientific computing, I usually go with Julia or kdb+/q.
That being said, I think Racket especially shines in the development of internal business or research tools. The large number of high quality libraries (especially for GUIs) makes it a great choice for desktop apps.