Just include a depth sensor, lidar, etc. I'm sure over time that will become increasingly easy to defeat too, but then we can just keep improving the sensors too.
I think it's very likely the next iPhone will have some form of authenticity proof too, I just hope Apple doesn't go with its own standard again that's incompatible with everything else.
Samsung were also the ones who demonstrated a fatal flaw in C2PA: device manufacturers are explicitly trusted in implementation.
C2PA requires trust that manufacturers would not be materially modifying the scene using convolutional neural networks to detect objects and add/remove details[1]
The Wikimedia Endowment (which is sorta-kinda separate) is to drive solutions to that exact problem.
By having a separate fund that the Wikimedia Foundation can access to help Wikipedia to have the technical expertise and knowledge workers required to continue the work of the Wikimedia Foundation.
Should the Wikimedia Foundation cease to exist, the funds in the endowment can be redirected to a successor.
EDIT: this is similar in style to the UK's Guardian Foundation, who provides funding to The Guardian newspaper. https://theguardianfoundation.org/
The point is that without Wikipedians adding and improving articles, Wikipedia will die, even if the site could be kept up indefinitely. So it has to remain a relatively wide social phenomenon, an obscure Wikipedia that no students know about and care to use will knowledge rot, even if it doesn't but rot.
What specifically do you think would be better? Lua shares many of JS's quirks (like the relationship between arrays and non-array objects, the behavior of undefined for non-existent object properties, metatables are somewhat similar to JS prototypes, etc.) and adds a bunch more (lack of continue statement, 1-indexing, cannot have nil values in tables).
I can see people liking or disliking Lua and JS both, depending on taste, but it's hard to see someone liking one and disliking the other.
Lua has tail call optimization and js doesn't. For me, this is a dealbreaker for js.
Lua also has operational advantages compared to javascript. You can build it from source in at most a few seconds and run it anywhere that has a c compiler. The startup time is negligible even compared to a compiled c program so you can run entire scripts that do very useful things faster than most js engines can print hello world. There is also the benefit that in spite of what this article discusses, it is possible for most problems to write a lua solution that works for all lua >= 5.1. This is wonderful because it means if I stick to the standard library, the bitrot is essentially zero.
Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
Of course Lua is far from perfect, but while there are some similarities, the differences are quite significant and meaningful.
> Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
That was not my experience when I was working with lua. Did anything change since? Asked google. Answered :
> In Lua, if a variable is assigned a value inside a function without being explicitly declared with the local keyword, it will automatically become a global variable. This is because, by default, all variables in Lua are global unless explicitly specified as local.
Yeah, this puzzled me too. I'm assuming they're referring to the semantics of "var" in JS vs "local" in Lua, with the latter resembling "let" in JS, which doesn't have broken scoping.
> Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
As a scripting language for browsers this is an antifeature, and the fact Lua comes by default with a bunch of features that allow loading arbitrary binary code in the process makes it pretty annoying to properly use it as a sandboxed scripting language.
You're conflating a few things here. V8 and Spidermonkey aren't the only interpreters out there. There are a number of them explicitly designed to be small, easy to compile and to embed, such MuJS, Fabrice Bellard's QuickJS, and more still. I can't speak to their FFI interfaces, but you can't judge JS's ability to call C functions based off that of Node/V8. I'm not sure how FFI runs against its execution model given JS is generally used as an embedded language, necessitating foreign function calls.
If I remember correctly, TCO is now part of the ECMAScript standard. Safari has implemented it. The issue is that others engines have not because they are concerned about stack unwinding and stacktraces.
I agree mostly in that Lua and Javascript are both similar, and like I said in my post above, I could see myself saying the exact opposite if Lua had been included in the browser.
The things I do not like about Javascript can easily be shot down in an argument. Some of it was having to work with Javascript (and it's evil cousin JScript) in the 90s and early 00s.
The type coercion and in the early days people used '=='. I think === did not even appear until ie6?
[] == ![] // true
The lack of a lot of easy helper functions in the standard lib. That now are provided by people writing a bunch of stuff in the npm ecosystem.
The npm ecosystem itself. Lack of security. Lack of... curation? (Also, all this would have probably happened anyway if Lua was in the browser)
I also think javascripts long history has created a legacy of different paradigms
variable declaration
var, let, const
function declaration
function f1() {}
const f2 = function() {};
const f3 = () => {};
const obj = { f4() {} };
There is a lot of stuff like this in javascript. I could probably make a blog post about it. But the above gives the general idea of my complaints.
In practice you don't run into these issues often. I'm annoyed when you see different function declaration conventions in the same codebase, but generally () => is used for either one line functions or inline lambdas, and function foo(){} for everything else. Nobody uses var anymore.
The implicit conversions is a definite footgun tho.
Bundlers will convert let/const to var, assign classes and functions to var etc but generally people don't write it themselves unless they want to (ab)use its semantics for performance reasons.
For me, JS has just too much magic, in particular the behavior of 'this', and lots of weird quirks, like "for in" vs. "for of". Lua, on the contrary, is very predictable and therfore easy to understand.
One killer feature of Lua (that surprisingly few scripting languages have) is stackful coroutines, i.e. you can yield across nested stack frames. Unlike JS or Python, there is no artificial split between generators and async/await and no need for function coloring.
If Lua had zero-based indexing, it would be close to perfect :)
Have you read large Lua codebases written by others? It is write-only language. All your "very predictable" features are overloadable, at runtime. No static typing to rest your eye on. It is a swamp.
"But, just write good code" you will say. Just like with Perl, some languages are designed in a way to discourage writing good code...
I'm talking about the core language, which I do find very predictable. You can go crazy with any language. Lua is definitely not worse than Python or JS in this regard.
> No static typing to rest your eye on.
That goes for any dynamically typed language. How is that an argument against Lua in particular?
> Have you read large Lua codebases written by others?
No, because I use it as a scripting language, as intended. I totally agree that one shouldn't use dynamically typed languages for building large applications. But again, this is not specific to Lua.
Oh, as a scripting language you embed into your project so that you can write scripts for it — there is hardly anything better than Lua. The C code is super clean and easy to embed and modify.
But once that project gets passed to next maintainer — I'm not sure I'd pick Lua over Forth or Scheme.
I held a similar opinion several years ago. The main thing is that lua has less magic than js largely because it's been allowed to break compatibility.
My main example is self in lua which is just the first argument of a function with some syntactic sugar vs this in javascript which especially before 'bind' often tripped people up. The coercion rules are also simpler largely by virtue of making 0 true.
Lua's metatables also cover a fair bit more ground than JS. For example, indexing, math operations (including bitwise), comparisons and equality can be overriden.
Some of thr language features like operators can be overloaded using method tables, much like python's double underscore methods. I do think that the inability to do this in JS is what held it back from becoming a data processing powerhouse. But it perhaps can be made to run fast precisely because of the lack of such overrides (otherwise we'll be running python at JS speeds). That said, LuaJIT seems like a good compromise and might be best of both worlds.
I love JS and Ruby, and I spent a bit of time maintaining a web app in Lua.
There are parts about the language I really enjoy. I like dynamic languages; I don't run into type issues so often it bothers me, but the tooling around Lua still leaves me wishing for me.
Part of this is really my own ability, or lack thereof, but I feel slow and constrained in lua. I have a hard time debugging, but I don't feel these things in other languages.
Yeah. I think if I were to pick one reason, it would be Lua is "minimalist". But, like I wrote, maybe, it too, would have just had lots of stuff added onto it if it had been in the browser. Hard to say.
I love ++, but you know what? I was shocked when a co-worker pointed out that it is frowned upon to use ++ in javascript. It some big companies, their linter settings mark ++ as something that should be changed.
The origin of this rule was that Douglas Crockford doesn't like ++.
From JavaScript: The Good Parts (May 2008):
> The ++ (increment) and -- (decrement) operators have been known to contribute to bad code by encouraging excessive trickiness. They are second only to faulty architecture in enabling viruses and other security menaces. The JSLint option plusplus allows the use of these operators.
Needless to say, I'm with you and hackthemack on this.
On https://blog.google/products/gemini/gemini-3-flash/ , the paragraph that starts with:
"Or you can quickly build fun, useful apps from scratch using your voice without prior coding knowledge."
reply