Re: [lisp-flavoured-erlang] The state of LFE ... and a New Hope

[Duncan McGreggor]

In light of the upswelling of interest in contributing to LFE, I will offer my time in the role of QA engineer: I will assist with reviews, merging PRs, and publishing merged contributions (e.g., web sites).

Mike -- thanks for sharing! GREAT news to hear about LFE in action and how other companies have embraced it. I'm not at liberty to discuss the companies I have consulted for and their use of it, so this is really, really helpful.

I don't know if I can answer (or have the "right" to answer) your question, but it might be really helpful for us all to hear about the sorts of things that push you away from a community and the specific things keep you coming back to LFE ...

More emails on their way,

d

On Fri, Oct 14, 2016 at 1:12 PM, Michael J. Forster <mi...@forsterfamily.ca> wrote:

Hi,

Pinched for time here, but I wanted to at least say that our company uses LFE heavily.  We started two years ago with migration of our seven year old 100 KLOC Erlang-based event admissions system.  Since then, I've written two new KFE-based systems--another 70KLOC--to expand our online ticketing services.

We've been committed to Erlang and, now, even more so to LFE. We could be for the next decade, if the last 25 years has been any indicator.

Perhaps not applicable to attracting newcomers and, especially, teams (as Elixir has excited floundering Rubyists), but I've succeeded and been productive with LFE by leveraging my experience with both Lisp and Erlang and their resources.

One question I have is:  Who do you want to attract?  I'm here because the Clojure BDFL and community have made--and are sticking with--technical choices that do not fit my cost/benefit needs.  Likewise for Elixir.  Of course, I'm not suggesting you should attract only me!!  But I think it's a crucial initial question: Who is your target user?  How broad of a "Who" can you afford to satisfy over the long haul?

Best,

Mike

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.
Visit this group at https://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[Duncan McGreggor]

On Fri, Oct 14, 2016 at 2:11 PM, Claudia Doppioslash <claudia.d...@gmail.com> wrote:

 

Yes, the site does need a reworking and if someone was to take on this project it would be a big boost and I would be very grateful. I have more or less translated the Erlang tutorial to LFE but at the moment it is the gitbook section but it should be moveable to a future site. Work is also being done to write clojure inspired modules for LFE and one has been included and as soon as I get the time[*] I will pull the update.

I could help with the website.

Claudia, this is *great* news -- thanks!

What is needed? 

Oh, soooo much. First, a note on philosophy:

* open source is volunteer-driven, so volunteers need to be provided with the freedom of working on the things they enjoy using the tools they love.

I mention this because I'm going to share some links to open web site (and related infrastructure) tickets ... they have a lot of detail in them about tool choice, development priorities, etc. That was done when I was working on this stuff exclusively. In accordance with the philosophical statement above, any contributors have every right to make different propositions, select different tools, etc.

Ultimately, what counts, is the finally delivery of some bit of functionality (site, docs, code, etc.) to the community, and that final piece is evaluated in the PR (as opposed to the tool selection, etc., being evaluated. (If you want to make big directional changes, just share some links to mockups or templates ahead of time -- that will lighten the load during the PR/QA/review cycle.)

So, with the following links, know that they are guidelines and that have you the freedom to chose your own path forward to helping the LFE community in whatever contributions bring you the most joy :-)

Tickets:

 * There are almost 60 open tickets here

 * Link: https://github.com/lfe/docs/issues

 * That view is almost useless ...

Milestone:

 * The v3 release of the docs is the next milestone (... and has been for a while :-( ...)

 * Link: https://github.com/lfe/docs/issues/62

 * This view is the most useful top-level view right now

 * Each of the tickets linked in that description is an epic

Epics and other Tickets:

 * Epics each have their own list of task and feature tickets (and sometimes sub-tickets)

 * Some of the epics have been closed, such as infrastructure decisions and information architecture -- feel free to re-open if you want to change directions anywhere

Current status

 * The following WrapBootsrap (3) theme has been developed:
    - http://docs3.lfe.io/examples/theme.html

 * The following landing page was the last look&feel task in progress (part of the #66 epic):
    - http://docs3.lfe.io/examples/prototype-landing.html

    - It explores top nav, footer, "splash" jumbotron, highlevel above-the-fold sections, and a detailed list of sections/subsections below-the-fold (tied in with the IA epic, #49)

    - This was part of this ticket set: https://github.com/lfe/docs3/issues/11

    - Which was linked in this epic: https://github.com/lfe/docs/issues/66

Additional Notes
 * As you can see, there is a zoo of tickets (with *some* attempt at organization) around this work ... could be much more clearly organized

 * I'm no longer sold on converting HTML to S-expressions. That may be over-LFE-ing and limiting our pool of site contributors

 * I'm no longer sold on inching towards a CMS-style approach; raw HTML might be fine for now, and possibly indefinitely (it's not like we'd be changing content at the rate that news sites do)

 

Looking forward to anything you feel like helping out with!

d

I have some good news anyway. My boss and I have been working hard to try and spread LFE inside Erlang Solutions and we have it included in the Erlang Ecosystem. See the logo at the end (which needs to be rotated 45 degrees). I always mention it when talking about the ecosystem. As part of a consulting job we are doing for a client in Elixir I should be able to a section in LFE. I will know in 2 weeks time. We have some really cool pictures with 3d versions of the cube as well.

Cool :) 

--

Claudia Doppioslash

@doppioslash

http://www.doppioslash.com

http://www.lambdacat.com   | Functional Programming

http://www.shadercat.com    | Shader & Graphics Programming

[Eric Bailey]

Looks like I've been removed from most LFE-related orgs/teams. Am I to understand this means I should fork and PR going forward, rather than commit directly, and that you'll serve as the gate keeper (read: QA engingeer), Duncan?

Eric

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

[Claudia Doppioslash]

Oh, soooo much. First, a note on philosophy:

A lot indeed xD 

Ultimately, what counts, is the finally delivery of some bit of functionality (site, docs, code, etc.) to the community, and that final piece is evaluated in the PR (as opposed to the tool selection, etc., being evaluated. (If you want to make big directional changes, just share some links to mockups or templates ahead of time -- that will lighten the load during the PR/QA/review cycle.)

The more we can use what's already done, the less work we have to do. 

So no direction changes from me, unless it's really needed.

Tickets:

 * There are almost 60 open tickets here

 * Link: https://github.com/lfe/docs/issues

 * That view is almost useless ...

Milestone:

 * The v3 release of the docs is the next milestone (... and has been for a while :-( ...)

 * Link: https://github.com/lfe/docs/issues/62

 * This view is the most useful top-level view right now

 * Each of the tickets linked in that description is an epic

Epics and other Tickets:

 * Epics each have their own list of task and feature tickets (and sometimes sub-tickets)

 * Some of the epics have been closed, such as infrastructure decisions and information architecture -- feel free to re-open if you want to change directions anywhere

 

Will take some time to go through that.

 

 * I'm no longer sold on converting HTML to S-expressions. That may be over-LFE-ing and limiting our pool of site contributors

Yeah, please no. 

The least work that gets us a working up-to-date website, the better.

 

 * I'm no longer sold on inching towards a CMS-style approach; raw HTML might be fine for now, and possibly indefinitely (it's not like we'd be changing content at the rate that news sites do)

True. The only CMS I've used lately is Ghost, but it takes time to rework a website to fit within it.

So you made a static site generator of sorts, for this?

Are lfe packages on hex? LFE itself is, but I don't see LFE libs.

Is rebar3 the best way to integrate LFE in a project, now?

Is there a way to do that with mix?

[Eric Bailey]

Responses inline.

_____________________________

From: Claudia Doppioslash <claudia.d...@gmail.com>
Sent: Saturday, October 15, 2016 1:58 PM
Subject: Re: [lisp-flavoured-erlang] The state of LFE ... and a New Hope
To: <lisp-flavo...@googlegroups.com>

I maintain the LFE package and have been publishing the rebar3 compiler plugin too. I've got a couple other libraries on Hex and plan to do more when I get time (especially now that clj.lfe is in LFE proper), but that's basically it.

I've had a lot of trouble with the interdependencies of the lfex libraries over the last year or so, which has led me to avoid using them whenever possible. Migrating them all to Hex packages would be great imo, but is certainly no small task. I would be willing to help out, should the community need.

Is rebar3 the best way to integrate LFE in a project, now?

Yes. The blog post is a bit outdated at this point, but the general principles still apply. The rebar3 team continues to be very helpful in ensuring support and helping me solve weird problems.

Is there a way to do that with mix?

My knowledge of mix is lacking, but as I understand, you can tell it to compile deps with rebar3. As such, in theory, you should be able to use LFE libs (and code) with minimal issues. I'd love to see a writeup or blog post about this. ericmj and the members of #rebar on Freenode in general would be great resources to that end.

--

Claudia Doppioslash

@doppioslash

http://www.doppioslash.com

http://www.lambdacat.com   | Functional Programming

http://www.shadercat.com    | Shader & Graphics Programming

--

You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

[Duncan McGreggor]

On Sat, Oct 15, 2016 at 1:58 PM, Claudia Doppioslash <claudia.d...@gmail.com> wrote:

Oh, soooo much. First, a note on philosophy:

A lot indeed xD 

Ultimately, what counts, is the finally delivery of some bit of functionality (site, docs, code, etc.) to the community, and that final piece is evaluated in the PR (as opposed to the tool selection, etc., being evaluated. (If you want to make big directional changes, just share some links to mockups or templates ahead of time -- that will lighten the load during the PR/QA/review cycle.)

The more we can use what's already done, the less work we have to do. 

So no direction changes from me, unless it's really needed.

+1
 

Tickets:

 * There are almost 60 open tickets here

 * Link: https://github.com/lfe/docs/issues

 * That view is almost useless ...

Milestone:

 * The v3 release of the docs is the next milestone (... and has been for a while :-( ...)

 * Link: https://github.com/lfe/docs/issues/62

 * This view is the most useful top-level view right now

 * Each of the tickets linked in that description is an epic

Epics and other Tickets:

 * Epics each have their own list of task and feature tickets (and sometimes sub-tickets)

 * Some of the epics have been closed, such as infrastructure decisions and information architecture -- feel free to re-open if you want to change directions anywhere

 

Will take some time to go through that.

 

 * I'm no longer sold on converting HTML to S-expressions. That may be over-LFE-ing and limiting our pool of site contributors

Yeah, please no. 

The least work that gets us a working up-to-date website, the better.

+1
 

 

 * I'm no longer sold on inching towards a CMS-style approach; raw HTML might be fine for now, and possibly indefinitely (it's not like we'd be changing content at the rate that news sites do)

True. The only CMS I've used lately is Ghost, but it takes time to rework a website to fit within it.

/me nods
 

So you made a static site generator of sorts, for this?

Not entirely. I had considered it, since we have so many special needs around our markdown files (and multiple *kinds* of markdown: Github, Gitbook, Jekyll, Jekyll "book-making", etc.). I did start doing some development towards that goal, but it was only early stages, really.

It would be nice to have a means of generating different types of sites, or content for sites, based on sources.  But that will only slow this effort down. Integrating content from Gitbook into a site would be possible by other means as well. And simply updating our old Markdowns to one consistent format could obviate the need for supporting a number of other formats.

Given that some content will probably be in Markdown format, there will be some need for conversion. Whether that's simply a collection of functions that do transformations or if we're using something like Garrett Smith's Lambdapad, would be entirely up to you :-)

d

 

Are lfe packages on hex? LFE itself is, but I don't see LFE libs.

Is rebar3 the best way to integrate LFE in a project, now?

Is there a way to do that with mix?

--

Claudia Doppioslash

@doppioslash

http://www.doppioslash.com

http://www.lambdacat.com   | Functional Programming

http://www.shadercat.com    | Shader & Graphics Programming

--

[mi...@forsterfamily.ca]

At the risk of boring everyone, I'll try to sum up my peculiar perspective as briefly as I can.

First, I rarely think about community issues--not that people shouldn't, nor do I think them unimportant. To put it simply, my job descriptions and demands have found a much better match in the old "written in stone" Common Lisp spec than any "on the move" language. I wear all the development & administration hats from hardware selection and purchase through to customer support (and loading and hauling a 40 foot trailer across the country). So, when I invest time and effort into a PL, I need to leverage it for everything from sysadmin scripting, backing services, web services, web front-ends (generating JS), desktop apps (POS terminals), and embedded devices (not just phones). When I write something in that language, I need it to build and deploy for years without breaking. To date, Common Lisp and its loose community of feral cats has done just that and will continue to do so.

However, the BEAM solves a problem for me more simply than anything else by far, and the benefit of investing in Erlang proficiency outweighs the cost. Yet, the cost is there. LFE allows me to leverage my SEXPR-n-macros experience to bring that cost down (I generate LFE, CL, and Parenscript code from higher level CL-based DSL). So here I am.

In a nutshell, I'd be happy with LFE-the-language as it is now, tracking the BEAM/OTP in a timely fashion over the long term and converging upon a single simple tooling in the short term. Give me a kerl-based install--I don't need lfetool. Give me either a rebar3 XOR a make approach to building LFE projects--I don't need lfetool nor mix. Give me one test framework (ltest), one docstring extractor, and one configuration file (lfcg ???). Let me fit a minimal stable LFE and tools into my continuous integration & deployment, leverage the BEAM/OTP library ecosystem, and never look back.

Those are my needs (more than my wants). I don't expect they'll align with what other folks need or want, so I'll just keep my eyes open for what I can take and where I might contribute for the benefit of others.

Best,

Mike

[Robert Virding]

I have been following this thread but as I am travelling have not really had time to contribute to it. I really appreciate offers to help from the community. I unfortunately don't have time to do more than I am doing now.

As I mentioned earlier there is a chance that I may get to do some real work in LFE, hopefully I will find out next week. That should be a boost. Anyway LFE is not dying even if it still small.

So go for it,

Robert

[Mário Guimarães]

Hello Mike,

your email did not bother (me) at all !

I have also thought recently of the same way to programming that you seem to follow, that is, write the code in a DSL using CL, and then generate target code to the plataform or language where it needs to be run.

You are doing this using CL, but I think it is certainly possible to do with any kind of Lisp, including LFE, and still have that feeling of being always lisping.

But, how do you debug your programs in face of the distance between your DSL and the target code?

I can only think of using the old "prints everywhere" and "function trace" styles.

Using a debugger, for example, to run a DSL program step-by-step seems unfeasible with the tools I know ... or there is some way to do it?

Also, you said "the BEAM solves a problem for me more simply than anything else by far" in which this "anything" seems to include CL.

What specific problem does the BEAM solve that even CL does not?

Do you think that the fact the BEAM does it, and CL does not, justifies for you to quit CL and adopt LFE,

or you consider to keep your DSL and generate to LFE to leverage the BEAM?

I think your answers will be a good input to help further development of LFE too.

Thanks

Mário

--

[Robert Virding]

I can answer this one. It's all about concurrency, fault tolerance and scalability. Copied from slides from a talk I have given:

What is the BEAM? A virtual machine to run Erlang

Properties of the BEAM:
- Lightweight, massive concurrency (we can do millions of processes in one erlang node)
- Asynchronous communication
- Process isolation
- Error handling
- Continuous evolution of the system
- Soft real-time
- Transparent SMP/multi-core support
- Interfaces to the outside world

More properties;
- Immutable data
- Predefined set of data types
- Pattern matching
- Functional language
- Modules/code
- No global data

I gave one version of the talk at EUC and another version with a different focus at Functional Conf.

Robert

[mi...@forsterfamily.ca]

On Friday, October 21, 2016 at 12:52:55 PM UTC-5, Robert Virding wrote:

I can answer this one. It's all about concurrency, fault tolerance and scalability. Copied from slides from a talk I have given:

[...]

I'll just add that, for me, it's also about having all of this in one comprehensive, multi-platform, conveniently-deployed system. Here's a list of just some of the things that Erlang/OTP eliminates for me:

- Apache/Nginx;
- memcached/redis;
- RabbitMQ/ZeroMQ/Kafka;
- Zookeeper;
- Docker;
- several times the number of servers; and
- all the shell scripts, Puppet/Chef, and other mess to manage the mess above.


As for CL, no, it will always play a central role in our projects. What it lacks in simple concurrency and scalability, it dominates in malleability and interactive development. We have several desktop/fat-client applications that would not be feasible without LispWorks for example. And there are places where mutation and near-C speed is divine :-)


Mike

[mi...@forsterfamily.ca]

On Friday, October 21, 2016 at 6:39:37 AM UTC-5, Mário Guimarães wrote:

Hello Mike,

[...]

But, how do you debug your programs in face of the distance between your DSL and the target code?

I can only think of using the old "prints everywhere" and "function trace" styles.

Using a debugger, for example, to run a DSL program step-by-step seems unfeasible with the tools I know ... or there is some way to do it?

[...]


Hello Mário,

Yes, debugging certainly becomes less interactive, especially when you consider how immediate CL development (i.e. with Emacs & Slime) can be.

Of course, it's not just debugging. Using CL to generate LFE, which must then be piped to the LFE compiler, introduces a staged development workflow for those parts of the overall system. Similarly, the generated CL/Parenscript must, in turn, generate Javascript.  To retain the benefit of a high-level declarative language for our applications without falling into the trap of the CASE tools of the past, I still have had to invest in writing (and debugging) layers of languages in both Parenscript and LFE.  Bugs are easier to isolate to either the top-level language, one of the intermediate languages, or the base CL, LFE, or Javascript.  Further, fixes to one of those layers don't require altering the others, so I haven't the CASE problem rendering the spec useless by hand-patching generated code.


Mike