lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

Hi all,
Talking in terms of "computing" and "programming languages" is walking in the fields of the past;
 the times when noone was talking about informatics and most people work for computers...
Today, we can have another point of view. Informatics happens in the mind of people 

 and the pourpose is NOT to compute.
The experiences made using Smalltalk in the last +30 years sustain advances in the direction of informatics; where the activity on virtual systems is not related with bussiness nor computation
 and with the development of a person doing activities in a virtual environment.
The virtual environment support the growing of a mature person that interacts in/with open systems.
It is a support for self-development and the success of the environment is not related with the amount of people doing the activity (each instance count as evidence).
Lua execution machinery can be used for this porpouse, but the limits of the users of Lua (considering the "dynamic language" called Lua) impose a barrier to surpass the limitations of traditional computing and forces people to continuously define packages and modules ad infinitum, reaching th elimits of harware but ony repeating the loop of producing the same (libraries but nothing "new" on the human side).
All said with the intention to promote entering the path of modern informatics, on open systems 

best,

Ale


El 20/10/2020 a las 15:01, Gavin Holt escribió:

Hi,

Sorry, Lua is not specifically mentioned. I was considering the
comments through the lens of my experience with Lua.

Once you get through the intro and the "giants of software", we get to
"Why do programming languages matter" (@7.55).

>From the discussion I concluded that Lua is a good example (quotes are
mine for emphasis - not extracts of the tapes).

- The sweet spot in the level of abstraction.
- Portability over many architectures.
- Highly polished syntax and technical implementation.
- Just the right amount of sugar.
- No weird breaking of conventions.
- No attempt to be too clever with syntax. ++i i++
- Define away entire classes of bugs.
- Keep it small and clean.
- Pure Lua libraries/modules are easy to implement.
- Good error messaging with backtracking.
- Care and information over the selection of the correct default behaviour.
- Progressive disclosure of complexity.
- GC nurtures beginners - "fewer feet are shot".
- Provide mechanisms not implementations.
- Combined paradimes allow good solutions to more problems - "it's not
about which tribe wins".
- Libraries are treated as natural extensions of the language.
- Metatables for operator overloading.
- Coroutines sound good - I haven't used this part of Lua.
- Ways to compartmentalize and therefore fit more abstractions in the
7-8 slots in your head: functions or classes dealers choice.
- No real ceiling to possible complexity.
- A book to guide us.

There are a number of comments about leadership of software projects
and I see these good behaviours in our community.
- Small core leadership team, willing to make and revisit decisions.
- Consideration given to the "wisdom of the group".
- A good base of support to avoid "one man" taking all the flak.
- Shared understanding of the general future, with experience of
decision making from the very beginning.
- Implementing features in a sensible order.
- Good momentum, lots of introspection and visible true forward development.
- Acceptance of breaking change.
- Tollerating dumb questions (close to my heart).

I learned about "immutability" vs "value semantics", and the
application to parallelization, hardware vs software for future
improvements, instruction sets as a moving target, custom chips with
everything, single thread processing won't speed up, application of
machine learning to generating code, ecosystems are key to adoption.

Hope this helps - please remember I do hip replacements for a living
and may be easily misguided.

Kind Regards Gavin Holt