Thought experiment: what would you remove from Lua

classic Classic list List threaded Threaded
100 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
It was thus said that the Great Petri Häkkinen once stated:

>
> > On 7 Sep 2018, at 23.41, Sean Conner <[hidden email]> wrote:
> >
> > It was thus said that the Great Petri Häkkinen once stated:
> >>
> >> I would remove ’:’ and ’self’. I never use them in my code and they
> >> support bad habits.
> >
> >  What bad habbits?  The excessive use of OOP?
>
> I’m talking about OOP in general. Every OO codebase I’ve worked with has
> been an overdesigned, hard to maintain mess. In my opinion, the invention
> of OOP was a misstep, leading to analysis paralysis (so many ways to model
> the program as classes) and poor performance (caused by too much emphasis
> on abstractions and code reuse rather than efficient data flow — see Data
> Oriented Design).
>
> Luckily more and more programmers are beginning to realize this (including
> pretty much all experienced programmers I personally know).

  While I agree with that (yes, I'm not a fan of OOP myself) I do find the
':' notation worthwile as a form of scope for functions (mostly with
userdata).  I find:

        config = tls.config()
        config:protocols("all")
        config:verify_client(true)
        config:ca_file("trust_these")
        config:cert_file("my_cert")

        server = tls.server()
        server:configure(config)

        connection = server:accept_socket(s)

nicer than:

        config = tls.config()
        tls.config_protocols(config,"all")
        tls.config_verify_client(config,true)
        tls.config_ca_file(config,"trust_these")
        tls.config_cert_file(config,"my_cert")

        server = tls.server()
        tls.configure(server,config)

        connection = tls.accept_socket(server)

  As it stands, my top level tls module [1] only has five functions instead
of some 80 functions---the configuration functions are only available to the
config "object" (for lack of a better term); the context functions are only
available to the "context" (or in this case, "server") object.  It's a form
of organization.

  -spc

[1] https://github.com/spc476/lua-conmanorg/blob/master/src/tls.c

        Rockspec coming soon ...

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
In reply to this post by Petri Häkkinen
On Mon, Sep 17, 2018 at 12:24 PM, Petri Häkkinen <[hidden email]> wrote:

>
>> On 7 Sep 2018, at 23.41, Sean Conner <[hidden email]> wrote:
>>
>> It was thus said that the Great Petri Häkkinen once stated:
>>>
>>> I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.
>>
>>  What bad habbits?  The excessive use of OOP?
>>
>>  -spc
>
> I’m sorry, I somehow forgot to check back on this.
>
> I’m talking about OOP in general. Every OO codebase I’ve worked with has been an overdesigned, hard to maintain mess. In my opinion, the invention of OOP was a misstep, leading to analysis paralysis (so many ways to model the program as classes) and poor performance (caused by too much emphasis on abstractions and code reuse rather than efficient data flow — see Data Oriented Design).
>
> Luckily more and more programmers are beginning to realize this (including pretty much all experienced programmers I personally know).
>
> For me it took almost two decades in C++ land to realize it. After that I wrote a pretty substantial OO codebase in Lua, still OO because classes was all I could see back then. Now I’ve been working on a Lua codebase with only free functions for 2+ years and it feels much cleaner and easier to work with than any of the OO stuff I’ve done before.
>
> Especially with a powerful dynamic language such as Lua I see no need for rigid classes & inheritance.
>
> Petri

There's nothing wrong with OOP in general. There is a tendency for
some engineers to overengineer, this is true, and some tools end up
demanding overengineering (Java, I'm looking at you), but nothing
about the paradigm in and of itself is necessarily bad.

As with everything, it's always a question of having the right tool
for the job. There are some domains where an object-oriented modeling
is the obvious fit. There are some domains where trying to crystallize
up an object model ends up making more of a mess than it solves. And
the most egregious source of trouble is when you're forced to use
SOMEONE ELSE'S object model because the underlying framework demands
it even when it doesn't make sense for your needs. And on the flip
side, having a bunch of free functions means that you expect all of
your things to behave the same way all the time -- which is a
perfectly reasonable design for some applications, and a dangerously
bad design for others.

That said, I agree with the conclusion that Lua doesn't need rigid
classes and inheritance built-in. Dynamic languages have their roles
just like static languages do. If your problem is one that would be
better served by a static language, then you should use something
besides Lua instead of trying to force Lua to conform to what you're
looking for.

Lua's implementation of OO is a very good balance for a dynamic
language. It allows grouping related data together in a container, it
allows that data to carry around the functions that it expects you to
use on it, and it gives objects the ability to share a set of
predefined behaviors. None of these are required if they don't fit
your purposes, but they're sufficiently lightweight and unopinionated
that they can deal with most use cases.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Petri Häkkinen
In reply to this post by Sean Conner

> On 17 Sep 2018, at 23.57, Sean Conner <[hidden email]> wrote:
>  While I agree with that (yes, I'm not a fan of OOP myself) I do find the
> ':' notation worthwile as a form of scope for functions (mostly with
> userdata).  I find:
>
>    config = tls.config()
>    config:protocols("all")
>    config:verify_client(true)
>    config:ca_file("trust_these")
>    config:cert_file("my_cert")
>
>    server = tls.server()
>    server:configure(config)
>
>    connection = server:accept_socket(s)
>

I agree, ’:’ can be useful for data description.

 [ I forgot I use it in my custom shader DSL for describing struct fields:

struct ”vertex”
  : float3 ”position”
  : float4 ”color”

]

So, I take back that ’:’ should be removed. But my (strong) opinion on OOP still stands :)

Petri
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Petri Häkkinen
In reply to this post by Coda Highland

> On 18 Sep 2018, at 0.25, Coda Highland <[hidden email]> wrote:
>
> There's nothing wrong with OOP in general. There is a tendency for
> some engineers to overengineer, this is true, and some tools end up
> demanding overengineering (Java, I'm looking at you), but nothing
> about the paradigm in and of itself is necessarily bad.

Well, that’s the theory but practice is altogether different matter. :) OO systems start nice and well behaved but when time goes on and new features are implemented over existing ones they all fall to mess. Nobody has time to remodel the classes when requirements change. So in my opinion just letting it go is the most sane & time saving solution.

> a bunch of free functions means that you expect all of
> your things to behave the same way all the time

Polymorphism can still be achieved for example with lambdas / callbacks in your data. Actually this is much more powerful than classes, because you can mix those callbacks any way you like (unlimited combinations vs. fixed number of classes), override them per instance rather than needing to create a new class (specialization for those weird cases), add them dynamically (do this after that) etc.

Petri
Reply | Threaded
Open this post in threaded view
|

AW: Thought experiment: what would you remove from Lua

michaelflad
In reply to this post by Petri Häkkinen
> -----Ursprüngliche Nachricht-----
> Von: [hidden email] <[hidden email]> Im Auftrag
> von Petri Häkkinen
> Gesendet: Montag, 17. September 2018 19:24
> An: Lua mailing list <[hidden email]>
> Betreff: Re: Thought experiment: what would you remove from Lua


> Especially with a powerful dynamic language such as Lua I see no need for
> rigid classes & inheritance.

This, very much. F.i. I have all kinds of functions working with "rectangles", like
intersections, collisions checks, grow/shrink/point inclusion etc. etc. but there's
no need to limit the usage to any predefined type. In my case it's just tables and
as long as they contain x/y/width/height key/value pairs, they're valid data.

It's much much more reusable than any OOP/interface construct, no dependency
or coupling of any kind.


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
In reply to this post by Petri Häkkinen
On Tue, Sep 18, 2018 at 1:17 AM, Petri Häkkinen <[hidden email]> wrote:

>
>> On 18 Sep 2018, at 0.25, Coda Highland <[hidden email]> wrote:
>>
>> There's nothing wrong with OOP in general. There is a tendency for
>> some engineers to overengineer, this is true, and some tools end up
>> demanding overengineering (Java, I'm looking at you), but nothing
>> about the paradigm in and of itself is necessarily bad.
>
> Well, that’s the theory but practice is altogether different matter. :) OO systems start nice and well behaved but when time goes on and new features are implemented over existing ones they all fall to mess. Nobody has time to remodel the classes when requirements change. So in my opinion just letting it go is the most sane & time saving solution.
>
>> a bunch of free functions means that you expect all of
>> your things to behave the same way all the time
>
> Polymorphism can still be achieved for example with lambdas / callbacks in your data. Actually this is much more powerful than classes, because you can mix those callbacks any way you like (unlimited combinations vs. fixed number of classes), override them per instance rather than needing to create a new class (specialization for those weird cases), add them dynamically (do this after that) etc.
>
> Petri

Not all OOP looks like C++ or Java. Carrying callbacks in your data is
still OOP.

Having an object with optional event handlers is a form of OOP that's
actually OLDER than C++.

It's even still OOP if you're just dealing with stuff by using
consistent interface contracts even if there's no direct coupling or
dependency.

Don't throw the baby out with the bathwater.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Tim Hill
In reply to this post by Petri Häkkinen


> On Sep 17, 2018, at 10:24 AM, Petri Häkkinen <[hidden email]> wrote:
>
>
> I’m sorry, I somehow forgot to check back on this.
>
> I’m talking about OOP in general. Every OO codebase I’ve worked with has been an overdesigned, hard to maintain mess. In my opinion, the invention of OOP was a misstep, leading to analysis paralysis (so many ways to model the program as classes) and poor performance (caused by too much emphasis on abstractions and code reuse rather than efficient data flow — see Data Oriented Design).
>
> Luckily more and more programmers are beginning to realize this (including pretty much all experienced programmers I personally know).
>
> For me it took almost two decades in C++ land to realize it. After that I wrote a pretty substantial OO codebase in Lua, still OO because classes was all I could see back then. Now I’ve been working on a Lua codebase with only free functions for 2+ years and it feels much cleaner and easier to work with than any of the OO stuff I’ve done before.
>
> Especially with a powerful dynamic language such as Lua I see no need for rigid classes & inheritance.
>
> Petri

+1 on all your points.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Petri Häkkinen
In reply to this post by Coda Highland

> On 18 Sep 2018, at 22.32, Coda Highland <[hidden email]> wrote:
>
> Not all OOP looks like C++ or Java. Carrying callbacks in your data is
> still OOP.
>
> Having an object with optional event handlers is a form of OOP that's
> actually OLDER than C++.

I disagree. Using function pointers does not automatically mean that it’s OO. Especially since with the callbacks there’s no direct correlation between functions and data (the callbacks may not even get the pointer to the data, for example with continuations). I’m pretty sure jump tables & function ptrs predate OOP by at least a decade, so saying that any code that uses function pointers is automatically OO sounds weird.

Petri


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Wed, Sep 19, 2018 at 1:27 AM, Petri Häkkinen <[hidden email]> wrote:

>
>> On 18 Sep 2018, at 22.32, Coda Highland <[hidden email]> wrote:
>>
>> Not all OOP looks like C++ or Java. Carrying callbacks in your data is
>> still OOP.
>>
>> Having an object with optional event handlers is a form of OOP that's
>> actually OLDER than C++.
>
> I disagree. Using function pointers does not automatically mean that it’s OO. Especially since with the callbacks there’s no direct correlation between functions and data (the callbacks may not even get the pointer to the data, for example with continuations). I’m pretty sure jump tables & function ptrs predate OOP by at least a decade, so saying that any code that uses function pointers is automatically OO sounds weird.
>
> Petri
>

I didn't say "using function pointers." I said "carrying callbacks in
your data." And on the assumption that your data is structured and the
callback always has a consistent semantic meaning concerning the data
carrying it, then that is at least rudimentarily object-oriented code.
Obviously the rest of the program might not be structured in such a
way that the object-oriented nature of that structure is relevant at
all, so I wouldn't go so far as to say the code is automatically OO,
but the kernel is there and it can certainly be beneficial to make use
of that nature when it's the right tool for the job.

(In particular I was actually talking about Smalltalk, which uses
message passing, not function pointers.)

Because central to the idea of object-oriented programming is the
concept of polymorphism: the notion that objects that obey a certain
contract can be treated interchangeably even though their
implementation details differ. Languages like C++ and Java define
these contracts statically, requiring that the programmer teach the
compiler how to enforce this. Languages like Lua allow the contract to
be defined informally. But as long as that contract has the object
itself providing the implementation details of some operation, you can
meaningfully call it object-oriented.

This is obviously not the right choice for many kinds of applications.
If your data is always the same structure anyway, then flat functions
have some clear advantages -- namely, it's a lot easier to describe
some properties about the functions, such as whether or not they're
pure.

The biggest problem with OO is, as I mentioned previously, opinionated
frameworks. "When all you have is a hammer," as the saying goes: Java
engineers in particular have a tendency to try to build frameworks
that are generic enough to tackle anything without thinking about
whether or not it's actually the best idea. (C++ engineers do the same
thing but instead of making a zillion interfaces that require you to
define dozens of tiny classes, they make a zillion templates.)

This isn't the fault of the object-oriented paradigm, though, because
you'll see the same failures in the functional programming community:
a rigidly narrow focus on defining everything in terms of pure
functions, higher-order functions, and function composition, inventing
schemas and frameworks and patterns that they swear will make your
code better if only you follow the rules. And if your application fits
the kind of ideas where that structure makes sense, it does. And if
your application doesn't quite fit that mold, you end up having to
hack around it, making a mess where you might have been able to
express the same thing in a few obvious lines of code.

In short: Use the right tool for the job. Sometimes OOP is the right
tool. Sometimes FP is the right tool. Sometimes good old-fashioned
structural/procedural code is the right tool. Sometimes it works best
to use a hybrid of the techniques. (There's a functional-OO hybrid
that I'm particularly fond of that I've seen a few different sources
discuss but there's no consensus on what to call it because there's
not yet a large body of formal theory around it.) No programming
paradigm is inherently bad, and you shouldn't dismiss them just
because you've had bad experiences -- odds are, your bad experiences
were the result of it not being the right tool for the task you were
doing at the time.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
Op Do., 20 Sep. 2018 om 04:08 het Coda Highland <[hidden email]> geskryf:
>

> The biggest problem with OO is, as I mentioned previously, opinionated
> frameworks. "When all you have is a hammer," as the saying goes: Java
> engineers in particular have a tendency to try to build frameworks
> that are generic enough to tackle anything without thinking about
> whether or not it's actually the best idea. (C++ engineers do the same
> thing but instead of making a zillion interfaces that require you to
> define dozens of tiny classes, they make a zillion templates.)
>
> This isn't the fault of the object-oriented paradigm, though, because
> you'll see the same failures in the functional programming community:
> a rigidly narrow focus on defining everything in terms of pure
> functions, higher-order functions, and function composition, inventing
> schemas and frameworks and patterns that they swear will make your
> code better if only you follow the rules. And if your application fits
> the kind of ideas where that structure makes sense, it does. And if
> your application doesn't quite fit that mold, you end up having to
> hack around it, making a mess where you might have been able to
> express the same thing in a few obvious lines of code.

Two days ago, I bought a second-hand copy of Reiser and Wirth's 1992
book "Programming in Oberon" at a library sale for half the price of a
can of beer, even though the PDF is free and I have it somewhere on my
computer too. It repaid the investment within minutes.

"Object-orientation as a programming technique, together with object-
oriented programming languages, is a fashionable topic. Oberon is true
to its spirit: a minimal language extension — namely extension of record
types — suffices. This is in contrast to other approaches that introduce a
wealth of new concepts many simply renaming established notions."

"The ultimate innovation was data type extensibility, which unfortunately
remained obscured behind the much less expressive term ‘object-oriented.’"

The book is exactly as old as Lua, which also has does it by only a
minimal language extension. Dare I guess that Lua's authors, too, were
and are not over-fond of OO buzzwords and hype?

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Albert Chan
Earlier in this thread, Y combinator were introduced (a week ago ?)

I was confused.  
Why would we complicate a recursive function like that ?

Then, I found this: http://dreamsongs.com/Files/WhyOfY.pdf

From the same site, this might apply to Lua, the language
There is no need to create the perfect language ...

http://dreamsongs.com/WorseIsBetter.html


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Petri Häkkinen
In reply to this post by Coda Highland

> On 20 Sep 2018, at 5.07, Coda Highland <[hidden email]> wrote:

> In short: Use the right tool for the job. Sometimes OOP is the right
> tool.

Well, if it works for you, go for it. Personally I have no use for OO anymore, unless forced to deal with an existing codebase.

There were times when I thought OOP was well suited to certain areas, e.g. GUIs. But the cheer pleasure of working with immediate mode guis have shown that to be a fallacy.

Petri




Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Aapo Talvensaari
> On 20 Sep 2018, at 5.07, Coda Highland <[hidden email]> wrote:

> In short: Use the right tool for the job.

I don't believe this anymore. It just leads to overtooling. Instead you should just pick a few tools and try to do most with them. And only occasionally use some very specialized tools.
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Thu, Sep 20, 2018 at 9:45 AM, Petri Häkkinen <[hidden email]> wrote:

>
>> On 20 Sep 2018, at 5.07, Coda Highland <[hidden email]> wrote:
>
>> In short: Use the right tool for the job. Sometimes OOP is the right
>> tool.
>
> Well, if it works for you, go for it. Personally I have no use for OO anymore, unless forced to deal with an existing codebase.
>
> There were times when I thought OOP was well suited to certain areas, e.g. GUIs. But the cheer pleasure of working with immediate mode guis have shown that to be a fallacy.
>
> Petri

TMTOWTDI. Nothing says there is one and only one right tool for the
job. Immediate mode GUIs can certainly be the right tool for the job,
especially for simpler layouts. I wouldn't want to use an immediate
mode framework for something more complex, like web layout.

It should also be noted that the underlying code for the immediate
mode GUI is almost certainly object-oriented even if you don't have to
use OOP code to interface with it. There are just too many advantages
to being able to treat GUI components polymorphically when you're
working at that level.


On Thu, Sep 20, 2018 at 12:14 PM, Aapo Talvensaari
<[hidden email]> wrote:
>> On 20 Sep 2018, at 5.07, Coda Highland <[hidden email]> wrote:
>>
>>
>> > In short: Use the right tool for the job.
>
>
> I don't believe this anymore. It just leads to overtooling. Instead you
> should just pick a few tools and try to do most with them. And only
> occasionally use some very specialized tools.

It sounds like you do still believe in it; you just have new
requirements for defining the "right tool" -- namely, if you have a
tool that you're already using in a project, and it's close enough,
then that IS the right tool for the job, because the cost of bringing
in another tool is greater than the benefit it would give you.
Likewise, if you have a tool you're proficient with that's close
enough, while you're unfamiliar with the tool that would on the
surface appear to be superior, then that other tool is NOT the right
tool for the job. And your cited exception is the cases where the
tools you're already using AREN'T close enough and the benefit of
bringing a new one in outweighs the drawbacks.

This is EXACTLY the right mindset to use in practical software engineering.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
Op Do., 20 Sep. 2018 om 20:44 het Coda Highland <[hidden email]> geskryf:

> Likewise, if you have a tool you're proficient with that's close
> enough, while you're unfamiliar with the tool that would on the
> surface appear to be superior, then that other tool is NOT the right
> tool for the job.

Well, by that definition, most of the time Lua is the right tool for
the job. I did Python for about four years and never felt
"proficient"; I considered myself proficient (albeit optimistically)
after about 18 months of Lua and have not looked back.

If I may for a moment regress to the OP's subject, my answer after 89
messages, is: nothing.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Thu, Sep 20, 2018 at 2:06 PM, Dirk Laurie <[hidden email]> wrote:

> Op Do., 20 Sep. 2018 om 20:44 het Coda Highland <[hidden email]> geskryf:
>
>> Likewise, if you have a tool you're proficient with that's close
>> enough, while you're unfamiliar with the tool that would on the
>> surface appear to be superior, then that other tool is NOT the right
>> tool for the job.
>
> Well, by that definition, most of the time Lua is the right tool for
> the job. I did Python for about four years and never felt
> "proficient"; I considered myself proficient (albeit optimistically)
> after about 18 months of Lua and have not looked back.
>
> If I may for a moment regress to the OP's subject, my answer after 89
> messages, is: nothing.

Lua has the beautiful advantage of being unopinionated. It has exactly
the feature set necessary to implement a broad variety of meaningful
programming paradigms without overprivileging any one of them. It can
do OOP (prototypes), it can do FP (tail call optimization and
lambdas), it can do declarative (original design motivation!), or of
course it's happy to do good ol' procedural/imperative. It can do
synchronous or asynchronous. With a bit of elbow grease it can
integrate with just about anything.

It's not the perfect tool for every job -- no tool is -- but as long
as you don't need C levels of performance, you've got the deployment
side of things solved, and you've got bindings for any libraries you
want to use, Lua is a great general-purpose workhorse. And if you need
to embed a scripting language in a host application, Lua jumps from
"great" to "best in class".

So yes, I too hold the opinion that the Lua core can't afford to lose
anything it has built into it right now. It's as lean as it can get
without sacrificing its versatility.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
In reply to this post by Dirk Laurie-2
On Sat, 8 Sep 2018 at 17:08, Dirk Laurie <[hidden email]> wrote:

>
> Op Sa., 8 Sep. 2018 om 14:33 het Dibyendu Majumdar
> <[hidden email]> geskryf:
> >
> > On Sat, 8 Sep 2018 at 06:27, Dirk Laurie <[hidden email]> wrote:
> > > On the other hand, unlike Dibyendu and Paige, writing and supporting
> > > dialects of Lua is not my hobby. (Btw Dibyendu, if you need a name for
> > > this stripped-down Lua of yours, how about Deimos? For over 100 years,
> > > it was the smallest known moon in the universe.)
> > >
> >
> > Nice name. I think there is a smaller language / implementation
> > lurking inside Lua that might be more efficient and optimizable. The
> > problem as always is of compatibility - and the fact that it is very
> > very hard to establish a new language. It requires full time attention
> > and many years of effort. The amount of time I am able to give to Ravi
> > for example, is insufficient to do this. And the difficulty then of
> > popularizing it makes it hard to be motivated.
>
> Actually Lua is so minimalistic, the question is always what one could
> add rather than what could one remove, and the answer in both cases
> can usually be implemented by loading a package.
>

Sure, if you aren't interested in performance.

As someone trying to build an efficient JIT for Lua, I do wish I could
do away with some things that broadly speaking:

* Lead to lots of runtime type checking - such as metamethods, Integer subtype
* Unpredictable stack manipulation - via C api, or debug api
* Coroutines
* Need to support inheritance via metatables

I haven't kept of list of issues that I would like to address - these
are off the top of my head.

I think a language that had none of these features (but was otherwise
Lua) would still be very powerful. Difficulty is getting anyone to
adopt a new language.

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Lorenzo Donati-3
In reply to this post by Roberto Ierusalimschy
On 11/09/2018 22:14, Roberto Ierusalimschy wrote:
[...]

> local Y = function (le)
>       local a = function (f)
>         return le(function (...) return f(f)(...) end)
>       end
>       return a(a)
>     end
>

OUCH! My brain hurts!

I can "feel" its beauty, but it's way over my functional head to understand!

(It almost reminds me of the difficulties of understanding Duff's device :-)


>
> -- Roberto
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Sat, Sep 22, 2018 at 2:51 AM, Lorenzo Donati
<[hidden email]> wrote:

> On 11/09/2018 22:14, Roberto Ierusalimschy wrote:
> [...]
>
>> local Y = function (le)
>>       local a = function (f)
>>         return le(function (...) return f(f)(...) end)
>>       end
>>       return a(a)
>>     end
>>
>
> OUCH! My brain hurts!
>
> I can "feel" its beauty, but it's way over my functional head to understand!
>
> (It almost reminds me of the difficulties of understanding Duff's device :-)
>

I dunno, Duff's device is pretty simple by comparison.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Lorenzo Donati-3
On 23/09/2018 01:18, Coda Highland wrote:

> On Sat, Sep 22, 2018 at 2:51 AM, Lorenzo Donati
> <[hidden email]> wrote:
>> On 11/09/2018 22:14, Roberto Ierusalimschy wrote:
>> [...]
>>
>>> local Y = function (le)
>>>       local a = function (f)
>>>         return le(function (...) return f(f)(...) end)
>>>       end
>>>       return a(a)
>>>     end
>>>
>>
>> OUCH! My brain hurts!
>>
>> I can "feel" its beauty, but it's way over my functional head to understand!
>>
>> (It almost reminds me of the difficulties of understanding Duff's device :-)
>>
>
> I dunno, Duff's device is pretty simple by comparison.

I didn't mean to compare the two things directly. I just compared how I
felt when coming in contact with those. The bedazzling feeling is the
same! :-)

I saw Duff's device for the first time probably 25+ years ago and I was
waaaay less experienced as a programmer back then. Moreover (IIRC) it
was in K&R book and I didn't have to understand it for my uni courses,
so it was just a curiosity. I did understand it some years later (and it
took me quite an effort).

I totally agree that Roberto's example is far more mind-boggling.



>
> /s/ Adam
>
>


12345