On 24/04/2025 15:51, bart wrote:
On 24/04/2025 13:25, David Brown wrote:
On 23/04/2025 19:43, bart wrote:
By the 500 such macro definitions, and the EXTENSIVE use of such macro invocations instead of functions, in a class of application I'm very familiar with.
>
>
So you don't know. You guessed.
Why are you automatically sticking up for THEM and not ME?
Why are you criticising them (the Lua authors) when you have no idea what is behind their code?
I am not saying that you are wrong as such - maybe the Lua code /is/ overly complicated, and uses more macros than makes sense, and the code is harder to maintain because of it. Maybe there is no particularly good reason for this - maybe the Lua programmers are just not very good developers.
What I am saying is that you don't have the information or background to give a fair critique of the code. All you are giving is a highly subjective opinion based on a bit of the code, and your own strong prejudices about C in general, and certain C features in particular.
Of course I too could say that at a first glance, there are too many low-value macros here, the identifier names are poorly chosen, and at least some of the macros would be better if they were replaced by inline functions. But I know that would be a first-glance viewpoint, and could easily be wrong or unfair.
What qualifications and what experience would somebody need for David Brown to give credence to their opinion?
I already outlined that.
I'm sure there are lots projects you can look at and know straight off that its uses of macros or whatever is over the top.
I am not so sure of that.
Of course you can form a first impression in many cases, but I don't like to place too much weight on that. It is not unreasonable to talk about your first impressions, if they are clear enough, but it should be a qualified judgement. Don't say "this code abuses too many macros" - say "from what I have seen so far, it looks like the code uses more macros than I think is sensible for such a task".
Suppose you reported that here, but I suggested that you don't know that; you're only guessing?
If you called me out on a claim about some code without appropriate understanding of the context, then I should be grateful for the correction. I am not going to promise I /would/ be grateful - I'm a mere human, with as fragile an ego as the next person.
You don't have any idea /why/ the developers choose to use macros like this - you simply assume that because you have written an interpreter with little use of macros,
I've written a million lines of code with little use of macros.
So what?
That does not mean you can judge whether the given macros are a good solution in this code. In fact, I'd say it makes you a /worse/ judge than most C programmers, since you are unfamiliar with macro usage (except to criticise it without justification).
I've written a million lines of code, and never touched Rust - does that mean I can tell Rust programmers that their choices are inefficient and impractical?
They are prevalent in C simply because the language has them and people will use them. Even if you ignore the ones that only exist people because don't like to use enums for named constants.
They are prevalent in C programming primarily because they are very useful in C programming, and fully supported by the language and tools.
Do you also complain about people using the number 7 in their C code? After all, it is available in the language, but it is completely unnecessary - people could just write "6 + 1" instead and avoid all those silly sevens. Or do you think perhaps people write the number 7 rather than "6 + 1" because it gives them clearer code in a more convenient manner, just like good use of macros does?
What your experience tells you is that is that it is /possible/ to implement a little virtual machine for a simple language without using C macros.
It tells you nothing about whether or not it is a good idea, because you have not tried it out for comparison. It tells you nothing about how best to implement Lua in C, because that is a very different language from your languages.
The example I gave was from ADD; my language has ADD too! Except that Lua's ADD works between Ints and Floats (Floats only before 5.1?); mine works between Ints, Floats, Strings, Bignums and Sets.
So, how different is it really?
Lua is an established language used by lots of people - it is documented, popular, and battle-tested (both as a language, and the tools) - yours is not. It is designed as an embedded scripting language - yours is, AFAIK, not. Lua is based on tables (for hashmaps, arrays, etc.), while yours AFAIK is not. Lua has anonymous functions - indeed, all functions are anonymous in Lua. Lua has support for OOP via tables. It has proper scoping. I'm confident there are a great many differences, though I don't know details of your language. I'm sure there are plenty of similarities however, as there are between any pair of languages.
It tells you nothing about the best structure for a core project written by multiple people, with extensions written by hundreds or thousands of people, and with many orders of magnitude more end users - because you just have a one-person language.
You forgot the bit where I said I've been doing this since the 1980s, on a few languages of my own, both dynamic and statically typed. And I've looked at lots of others including their implementations.
No, I didn't forget.
I've also got my C compiler to build and run some of those (Lua and Seed7 among them).
I've compiled Lua too, linked in with my own code.
I even created a C interpreter.
I've experimented with half a dozen kinds of bytecode dispatcher, and several methods of type dispatching, and tried out AST tree-walkers.
Some of my interpreters were embedded, and run within commercial products, and used by other people to create their own add-on programs.
I realise you have done lots of stuff, and have lots of experience. I simply don't see it as relevant to be able to judge the way the Lua source code is structured without further knowledge of that code.
And while I am loathe to make ad hominem judgements or appeals to authority, you are a guy off the internet who has made a lifetime career of living in your own bubble, avoiding any contact or information from other languages, other software, or computer science research - convinced in your own superiority in language design and implementation over the entire rest of humanity. Lua was designed and implemented by university professors - experts in the field, familiar with the strengths and weaknesses of lots of languages and implementation techniques. The language and its implementation has been refined and developed with the feedback of huge numbers of people.
Of course you can have your subjective opinion on the language and its implementation. It is only natural that you would prefer your language, and your style of implementation. But do you understand that I do not consider your opinion to be objective? I am not giving any kind of opinion or critique on the Lua code, because I know I am not able to give a fair and justified analysis. I do not think you are either.
And to cap it all, you (AFAIUI) don't even use C to implement any of this stuff - you use your own languages. (Those may well be a better choice than C for implementing virtual machines.)
I did try C at one point. That didn't use macros either.
The way you could /know/ the best way to implement a Lua virtual machine in C would be to investigate if the Lua developers, or any other groups, have tried to implement the Lua VM in different ways and seen how well they work. Or you could find books or articles that discuss different ways of implementing VMs.
Maybe /I/ should write a book or article instead!
Perhaps you should. I am sure you have a lot of information (about many topics) that you could put in a book - or at least a series of articles. It would be a more constructive use of your keyboard than a lot of these Usenet threads :-)
>
There are perhaps a half-dozen basic ways of implementing language virtual machines. There are a very large number of interpreted or byte- coded languages. You have experience of implementing a couple of simple languages, for personal use, using either a strangely restricted subset of C or one of your own languages.
How many interpreters do you think the developers of Lua have worked on? (And how many of those developers also devised and programmed its implemenation language?)
I don't know the Lua developers personally - but since the core team are university professors, I imagine they have at least /some/ suitable qualifications and knowledge.
You describe my languages as 'simple'; how much more complex do you think Lua is?
I find it disappointing that you don't want to acknowledge that I might know something of this field, that I have extensive experience of it, and that my opinions might be valid.
I /do/ acknowledge your experience. I don't acknowledge that you are in a position to judge whether the macros used in the implementation of Lua are a good idea or not. Can't you understand that difference?
More so that you seem to know little about Lua, but decide to give them the benefit of a doubt anyway.
Note - again - that I have not said their use of macros was good. I have said that neither you nor I are in a position to say their use of macros was bad.
/Maybe/ they had good reasons for using so many macros, but /maybe/ so do I for having so few!
Equally, I am not in a position to say that your use of few macros is bad or that your code would be improved with more of them.
So why are you automatically assuming they must be right, and I must be wrong?
Why are you assuming I have said they are right in the way they designed their code, or that I have said you were wrong?
Stop trying to view everything as binary.
Further, this is part of a survey of interpreters running a recursive Fibonacci benchmark:
That tells you nothing useful.
So I know fuck-all about writing interpreters, they are all toys, my languages are toys, and my opinion counts for nothing?
Your opinions count as your opinions. Nothing more, nothing less.
do { quit; } else { }
Re: do { quit; } else { }