Re: Thought experiment: what would you remove from Lua

[Coda Highland <chighland@...>]

On Wed, Aug 1, 2018 at 5:07 PM, Andrew Starks <andrew@starksfam.org> wrote:
>
>
> On Wed, Aug 1, 2018 at 4:50 PM, Coda Highland <chighland@gmail.com> wrote:
>>
>> On Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <andrew@starksfam.org>
>> wrote:
>> >
>> >
>> > On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <chighland@gmail.com>
>> > wrote:
>> >
>> >> Well, given that coroutines CAN be implemented in terms of other
>> >> language features, you could implement them at a higher level -- some
>> >> sort of automated source transformation at parse time so that the
>> >> VM/JIT/whatever doesn't have to worry about it. The Javascript
>> >> community has done this for quite a while now in order to work around
>> >> lack of browser-side support, and while the generated code is really
>> >> hard to read it's definitely just mechanical.
>> >>
>> >> /s/ Adam
>> >>
>> >
>> > I think that meta-programming is a useful boarder. Whenever you're
>> > adding
>> > language features into the language that you're programming, you're
>> > meta-programming. JavaScripts lack of a concurrency framework requires
>> > immense amounts of meta-programming and complexity.
>> >
>> > Lua has this too, but mostly for extending existing mechanisms in
>> > particular
>> > directions: cqueues, object libraries and ad hoc type systems.
>> >
>> > I think that wherever there is meta programming, it's good to ask why
>> > and
>> > evaluate whether it's not needed or should be part of the language.
>> >
>> > --
>> > Andrew Starks
>>
>> By that definition, working on the interpreter itself is
>> metaprogramming. And while that's technically true -- and other things
>> like building a source-to-source transpilation tool are also
>> metaprogramming -- that makes the distinction much less useful for
>> figuring out what should or shouldn't be part of a language. Because
>> at some point, SOMEONE has to do some metaprogramming, or else you're
>> never going to be able to use the language in the first place.
>>
>> Likewise, it's really not fair to judge a feature by which compiler
>> pass it's implemented in. That's just an implementation detail and the
>> design of the language shouldn't have to be concerned about it.
>>
>> Conversely, a different perspective: If it requires metaprogramming
>> hackery to be able to do something, isn't that a sign that it's
>> something that SHOULD be considered for addition to the language, so
>> that you don't have to do the hacky thing?
>>
>> /s/ Adam
>>
>
> I can't help but think we're saying exactly the same thing. Meta programming
> isn't bad. It does happen and it just is. Another way to look at it is
> attempted growth or mutations to the language. The ones that stick and have
> wide use are either sufficient as libraries or big red flags that demark
> potential areas for change that might result in more simplicity.
>
> Type is a great example. Lua has a little type but not a lot. It's tempting
> to want to extend type in the core language, but then you realize that
> testing takes care of a lot of the reasons why you want to check for object
> type. And so a type library does not come to be a required library to
> download in order to "really use Lua". Often you might find yourself looking
> in a `._class` field or something. But people do this and while there may be
> benifits to providing such features  or enforcing limitations in the
> language, those decisions cut off possibilities. And that's pretty much what
> designing a language must come down to.
> --
> Andrew Starks
> 612 840 2939
> andrew@starksfam.org

Oh, I see. I had interpreted your proposed border as being a rubric
for acceptance instead of a sign of where further consideration is
needed. Especially since I'm a C++ programmer, I get a lot of
"metaprogramming bad!" responses from people when the subject comes
up.

I can certainly agree that tasks that require metaprogramming should
be looked at as informative use cases for language design. The need
should be addressed one way or the other, whether by "there's already
a simpler way to do that" on the one hand or "that's useful enough to
be incorporated" on the other.

/s/ Adam