Functional programming in Lua

Don’t think this has been discussed much on the forum but I’m looking into functional programming at work as part of a new project (in F#) and I wondered how applicable this new paradigm might be to Lua - turns out quite a bit!

Anyway I stumbled on this link https://pragprog.com/magazines/2013-05/a-functional-introduction-to-lua and was surprised to see that the article explicitly mentioned Codea and the example program (https://gist.github.com/joshski/5429239) was also written using Codea so I thought I’d share for the benefit of the community.

Enjoy!

Thanks @TechDojo, very cool article. Some of those functions, like each and map in particular, could be quite handy. Warning: one may find the program hard to understand at first, but it’s worth it.

It really is blowing my mind - I was initially taught procedural programming back in the '80’s, then had to learn OOP in the '00’s and now it’s almost like I’m going back in circles - trying to learn a “functional mindset” whilst still being able to contribute code to a massive OO project is a real juggling act.

Fortunately I work for a really progressive company that is investing heavily in it’s staff training and using cutting edge practices (XP, pair programming etc), the hope is that eventually we’ll be able to introduce functional elements / concepts in to our codebase to help with speed, reduce bugs, improve the quality of our unit tests etc.

I understand how the tail call recursion optimisations work, but coming from a traditional background I can’t seem to get away from the idea that lot’s of dynamic memory allocations are expensive and the whole idea of not storing state (making everything immutable / values not variables etc) is quite a challenge.

Do you have any advice about one key concept or takeaway that should be considered a good starting point? To me it seems to be idea to try and identify core generic computational units in an algorithm that can then be recombined to build up complexity incrementally (a bit like RISC based processors).

Given the potential overhead of implementing the list processing functions in pure Lua I wonder if @Simeon would consider implementing them in Swift and then exposing the methods by extending the table class?

Hi @TechDojo !

I’ve discovered the functional paradigm 3 years ago, and it was a big slap in my face. As you said, it require a mindset at the opposite of procedural programming, but there is a lot of power behind it.

In some way, the procedural programming is “how?” i do something, and the functional is more “why?”.

One key concept is the lambda calculus. To see if your understand it, try to implement church numerals, it’s a beautiful way to begin.

And for the functional programming, you can begin with the towers of Hanoi or simple functions on lists.

One thing that I love in functional paradigm is the way a function is : it take only one argument! a little example :

-- procedural
local function max(a,b) return a > b and a or b end

max(1) -- error
max(1,2) -- 2

-- functional
local function max(a)
  return function(b)
    return a > b and a or b
  end
end

max(1,2) -- funtion(b) : doesn't work as expected, 2 is ignored
(max(1))(2) -- 2 : real notation of what we want just before

local max1 = max(1) -- create a function with immutable context
max1(2) -- 2
max1(0) -- 1

I agree that map, filter, reduce etc are now very common across quite a few languages, eg Javascript and Swift, I find them really useful. @Simeon talked about incorporating one of the Lua functional programming libraries into Codea a while back, I remember it had map, filter, reduce, I can’t find the thread now (wasn’t it part of the discussion on the beta thread for the 2.3.2 release? Can’t seem to find it in a search). I said I was in favour, though I seem to remember others weren’t so keen for some reason.

Although, as that repo you linked to shows, it’s pretty easy to implement those kinds of functions ourselves

@TechDojo, you’re doing pair programming? How do you like it?

@UberGoober - It’s a new challenge, I like the way in which everything is discussed and suggested prior to typing, leads to better code I think, but at the moment I’m still tempted to hog the keyboard a lot - I suppose a lot depends on who you’re pairing with, the company do like to mix up the pairs as a way to prevent knowledge silo’s but I’m finding I’m gelling more with some than others.

i pair often, currently on the spacewar homage i’m working on. i’ve been pairing for 20 years, so i fancy i’m fairly good at it. :smile: and i enjoy pairing. once you get the rhythm it’s like talking about programming at a party, except you get code, not a headache. questions welcome … maybe a new thread?

Whoah!!! Ron Jeffries for real?!?

Your article on writing that Codea calculator changed the whole way I think about unit testing. I read it a year or so ago. It was very inspirational. Thank you for it!

It seems that programming styles keep changing. Someone in management reads something and thinks that’s the way to go even though they don’t know anything about it other than what they read. My opinion is to use the programming style that’s comfortable for you and what you understand. Keep it simple. If you can’t understand it while you’re writing it, you won’t understand it a month later when it goes into user review and you have to change everything because the users changed their minds about what they wanted. I’m glad I’m retired and program just for fun now.

@dave1707 - that’s fine for hobby programmers who work entirely on their own, but for any non trivial group project, the programming needs to be checked, and maintained, as easily as possible. That’s where allowing people to do their own thing can lead to disaster, and modern professional techniques come in.

I hate fads and buzzwords, but I believe the programming of important projects needs to be highly disciplined. I agree that senior managers get seduced by stuff they don’t understand, but there does need to be some system, and not a whole bunch of individual styles in a team.

I saw this over and over again in spreadsheets, where uncontrolled users created disastrous messes that were impossible to check, buggy as hell, and horrible to maintain. If you focus on making your code easy (for other people) to check and maintain - and unit testing helps by building testing right into the code- then you get vastly superior results.

@Ignatz That’s not only fine for hobby programming but also production programming. When I worked, I wrote a program from proof of concept to production. I was the only programmer (almost) that worked on that code. I updated, and maintained that program for approx 20+ years. There were 2 to 3 major updates per year and depending on needs, several minor updates per year. The program grew each update and was probably 60,000+ lines of code when it was replaced. I wrote the code keeping it as simple as I could. I wrote it in C and when it was replaced it was done by a team of 5 programmers who re-wrote it in C++ over a 2 year period. I continued to update my code and they updated their code until their code replaced all of mine on approx 35,000 devices over a 3 year period. Because I was the only one writing my code, I knew where everything was and how it worked. There are still about 5 programmers maintaining the other code. It was risky for them, because if I died or quit, someone who knew little about the code would have to take over. Since I didn’t do either, it worked out fine.

That’s exactly my point. Organisations need to avoid key man risk, and your employer was crazy to leave all the knowledge in one persons head!

These days, it’s uncommon for one person to write so much unchecked code. If other people need to work with it, it’s important that a common development approach is used. So sometimes personal preferences have to be put aside for the common good!

@dave1707 i hope you got paid at least 4x the average programmer wages?

I wasn’t trying to point out the craziness of the decision, I was trying to say that one person can manage a large program over a long period of time without all of the fancy programming styles that come and go. Pick an easy language to use and write simple code. I didn’t write any test sheets to check every little thing I did. I wrote sections of code and when it was done I checked to make sure it did what it was supposed to do. If it did I went on to the next step, if it didn’t I fix it. When all of the updates were finished, there was a large user testing period where users from around the country would come and make sure that everyone’s code worked together and it was what they wanted. Everyone would make necessary changes to their code during that period. If everything checked out OK, then everyone’s code would be rolled out over the next several weeks. @Jmv38 No I didn’t get paid 4x the average, but I did have my perks and I enjoyed what I was doing. I was left alone to do my coding and no one bothered me with other stuff.

I worked the same way on my own for many years - and wrote bad code - compare to what I now know to be best practice. I’ve seen the same with other people who wrote on their own - very idiosyncratic stuff, and difficult for other people to maintain. Just saying!

I’ve been a solo programmer most of my career but I can definitely see the benefits of a paired approach, from a company perspective there are many benefits - one being reducing knowledge silo’s (ie where one person know’s everything and becomes indispensable - which is what I think @Ignatz was referring to).

I’ll still keep solo’ing on my personal projects but if given the chance I’ll continue to pair on work ones.

@dave1707 I remember once reading a management article that (jokingly - I think) said that if you ever find out that a person has become indispensable you should fire them before they realise it :slight_smile:

As a senior programmer who’s been there, done that and met a lot of other programmers (both good and bad, with good and bad work habit’s) I can see a whole other raft of company benefits - peer pressure to not slack off and look at facebook for one.

Plus - if for no other reason I like the opportunity to learn something new and new ways of working and it forces you to communicate with people, something a lot of programmers need to learn :slight_smile:

@TechDojo I knew I was indispensable and so did they, but I didn’t take too much advantage of it. Each release there was a list of new features that needed to be added. As long as I was able to add everything without any production problems, they left me alone.