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

LFE: Lisp Flavored Erlang

lfe.io

Post reply on HN
Print view View original

21–30 of 33 posts

Re: LFE: Lisp Flavored Erlang

#21

Post by dnautics »

whynotwhynot wrote: post #15
grantjpowell wrote: post #3

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

I'd like to invite you to the Other Side Of The Force, Grant. http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were... It's much more pretty over there. I haven't looked at Elixir but I have read a bit about Supervisors which I think are an excellent idea for fault tolerant systems. However, the phrase "self healing" is thrown around a lot in talks about Elixir, as if it's a magical feature of the language, wi…

Supervisors are only the beginning of the journey to fault tolerance in the BEAM... There's so much you can do; one way of thinking about it is that you get very smart garbage collection on arbitrary system resources, tied to concurrent threads, and you can link threads so they fall in the same failure domain.

Re: LFE: Lisp Flavored Erlang

#22

Post by elongatedMusku »

Hey guys, I've done SICP in the past and I like scheme a lot. I've since then moved to Haskell.

How do I get a functional programming job (say lfe)? A lot of the job listings ask for experience of 2 years. Any suggestions on where I should look would be really helpful.

Re: LFE: Lisp Flavored Erlang

#23

Post by dnautics »

whynotwhynot wrote: post #18
67868018 wrote: post #17

Earlier quoted context omitted.

> coding for the happy path It's not that complicated. A relatable example would be writing an API endpoint that receives data and then you do something with that data. 1. Write the endpoint so it works for the expected data. 2. You're done That's it. You don't need to worry about anyone sending you malformed payloads or fuzzing your API. You can ignore it. They cannot exploit anything, they cannot crash BEAM. It wil…

That is seems to be more about the underlying infra (BEAM) than the language. I thought it was something specific to Elixir. I thought they meant it at the level of program logic, which is why it seemed very confusing. I guess Lisp is about beauty and poetic justice and it shall remain in that realm. I'll look into Elixir. Seems to have a healthy and growing ecosystem.

The underlying infra is not decouplable from the language. The beam is first and foremost designed to get stuff done easy and without error, not to be beautiful and poetic. Doesn't mean it can't be beautiful! And programming is fun because it feels like programming with training wheels on.

Re: LFE: Lisp Flavored Erlang

#24

Post by tarkin2 »

Despite this being obvious hn catnip, I’m interested.

I loved the little and seasoned schemer books, yet found both racket and CL somehow divergent and unappealing.

Does anyone here use it? I can’t find if it deals with continuations well. I’ve never used many languages that allow eloquent use.

Re: LFE: Lisp Flavored Erlang

#25

Post by digikar »

hackingthenews wrote: post #13
smabie wrote: post #10

Earlier quoted context omitted.

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

Thanks! I haven't really experienced the image feature, as I used Scheme. It doesn't sound like it would be consequential to how I program, but that might just be my ignorance of it. My experience with the macro stuff is that they enable in-house implementation of language features like lazy evaluation (not possible in other languages without a lot of extra code), which we implemented during the course. But implement…

>Image

The best video I've come across thwt demonstrates images is https://youtu.be/3GEAINRCbJ4

TBH, one can use emacs to get a similar workflow in single file python projects. There are also julia-snail and slime variants in emacs for providing it for julia; none of which I've tested to comment much.

Re: LFE: Lisp Flavored Erlang

#26

Post by gitgud »

hackingthenews wrote: post #4

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

Pretty sure you're writing on a good example now!

Hacker news is written in Arc, which is a dialect of Lisp. There's an old copy of code base here:

https://github.com/wting/hackernews

Re: LFE: Lisp Flavored Erlang

#27

Post by dig1 »

hackingthenews wrote: post #4

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

* Hiccup (https://github.com/weavejester/hiccup) - DSL for generating html. You can easily mix it with other language constructs. There are similar libraries for Common Lisp and Scheme.

* Compojure-api (https://github.com/metosin/compojure-api) - for building web applications. Mix json-like, hiccup and clojure constructs for web applications and autogenerate Swagger documentation.

* LOL book (https://letoverlambda.com/). Extreme examples what you can do with macros and code modifications during compile time.

* Seesaw (https://gist.github.com/daveray/1441520) - library for building GUI apps with Clojure and Swing. Express GUI elements through declarative syntax. Qt and other libraries has similar feature, but is usually preprocessed with external tools.

* Scheme - MiniKanren (https://docs.racket-lang.org/minikanren/index.html)

Most of these things in regular languages would require modifying language parser or compiler, or adding external tool that will parse that code and generate new one; e.g. like React is doing with html chunks. Also, many Scheme/CL/Clojure implementations provide functions to modify syntax table in runtime, allowing you to alter how things are parsed. That is extremely hard in regular languages due unregular syntax constructs.

Re: LFE: Lisp Flavored Erlang

#28

Post by mercer »

67868018 wrote: post #17
whynotwhynot wrote: post #15

Earlier quoted context omitted.

I'd like to invite you to the Other Side Of The Force, Grant. http://www.petecorey.com/blog/2017/08/07/what-if-elixir-were... It's much more pretty over there. I haven't looked at Elixir but I have read a bit about Supervisors which I think are an excellent idea for fault tolerant systems. However, the phrase "self healing" is thrown around a lot in talks about Elixir, as if it's a magical feature of the language, wi…

> coding for the happy path It's not that complicated. A relatable example would be writing an API endpoint that receives data and then you do something with that data. 1. Write the endpoint so it works for the expected data. 2. You're done That's it. You don't need to worry about anyone sending you malformed payloads or fuzzing your API. You can ignore it. They cannot exploit anything, they cannot crash BEAM. It wil…

My 'A-ha' moment with Elixir was exactly your example.

Both me and a friend were building an app that ingests cryptocurrency data and stores it in a database for later analysis. The important part was that we wanted data at regular intervals. I'm not much into all this but this is what was asked of us. He wrote the app in Python; I wrote it in Elixir.

Turns out the API's of the various exchanges are (or were) atrocious. We'd get responses ranging from weird error codes to malformed data to timeouts. API's would randomly change. It was a mess.

My app just chugged along, a process per request per api endpoint. When some of these endpoints 'misbehaved' the others just kept going.

His app kept crashing, restart, and so one misbehaving endpoint would cause trouble for all the other ones. He had to add try...catch statements and fix the problems. I would just look at my logs, update the happy-path code, push it, and recompile() in the REPL.

I also have a bunch of personal projects chugging along on my VPS. They actively handle requests a few times per hour at least, by me, and they're doing fine despite the fact that I was quick about it and only wrote the 'happy path'. There's crashes and errors all over the place, and yet when one part crashes the rest just keeps going. It's been a rare occasion where the entire supervision tree failed and the app gave up.

Re: LFE: Lisp Flavored Erlang

#29

Post by kazinator »

smabie wrote: post #10
hackingthenews wrote: post #4

Can 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 d…

> The first big idea is that a regular syntax allows the trivial implementation of macros.

Note that Lisp existed for quite a while before macros. The regular syntax allowed for the evaluation algorithm of Lisp to be described as if it were a Lisp procedure itself, and it allowed the language to be extended with "FEXPR" routines.

Re: LFE: Lisp Flavored Erlang

#30

Post by whynotwhynot »

mercer wrote: post #28
67868018 wrote: post #17

Earlier quoted context omitted.

> coding for the happy path It's not that complicated. A relatable example would be writing an API endpoint that receives data and then you do something with that data. 1. Write the endpoint so it works for the expected data. 2. You're done That's it. You don't need to worry about anyone sending you malformed payloads or fuzzing your API. You can ignore it. They cannot exploit anything, they cannot crash BEAM. It wil…

My 'A-ha' moment with Elixir was exactly your example. Both me and a friend were building an app that ingests cryptocurrency data and stores it in a database for later analysis. The important part was that we wanted data at regular intervals. I'm not much into all this but this is what was asked of us. He wrote the app in Python; I wrote it in Elixir. Turns out the API's of the various exchanges are (or were) atrocio…

So, both of you guys talk about API request handling.

How about some computational task where coding only the happy path means accurate calculated results for 80% of the cases?

I think my problem is the marketing hype with Elixir around "happy path" and "self healing" are too broad and resemble hype more than feature description. I'd be happy if those terms weren't used outside of marketing literature, until we have an AGI that can manage complexity on its own :)

Post reply on HN