It's called predicting the future. And, no, it's seldom 100% accurate.
So don't pretend that it is established scientific fact. Climate predictions have not been scientifically tested at all; they are pure guesswork.
But it's better than sitting on your arse and waiting for the sky to fall, then being surprised when it does.
No, it is not better if you use this guesswork to justify policies that seriously harm the global economy, and may actually lead to more carbon emissions over the long run.
In Japan politicians are not allowed to buy advertising at all. They can go round and campaign in person, but not TV or billboard or newspaper ads.
And Japanese democracy is such a wonderful example to emulate. Riiiight.
What we need to do is get money out of politics. There has been some suggestion of state funding of parties in the UK, where once you reach a certain size you get a fixed budget from the state to run your campaigns and no more. It helps stop people buying their way into office, or buying politicians.
There are much easier ways of buying politicians: you give them money directly.
I wouldn't call Lua performance without a JIT "abysmal" compared to C or Java. In terms of runtime on inner loops, it's usually about 5-10x slower, which is pretty good for an interpreter. But that is only one performance measure. Once data structures and libraries get into the picture, any speed advantage of C/Java quickly disappears because those are native in Lua anyway. And even plain Lua beats both equivalent C and Java code on code size and code complexity by 1-2 orders of magnitude, and that often has a big effect on overall performance of a system as well.
And Lua in the kernel isn't trying to replace C, it is trying to complement it. And it's a good complement, because Lua (or Lua+LuaJIT) is tiny, but would allow the kernel to become much smaller and simpler by throwing out a lot of code that C just isn't very good at.
Wind-up radios have been around for a long time and will continue to be around. Baylis didn't invent them, he came up with another way of building one (using a spring for energy storage). It turned out his way wasn't as efficient as other ways (using a capacitor / battery for storage), so he didn't make much money.
What was your point again? Oh, the courts should stop powerful vested interests? That's not how power works in our society. Billionaires have successfully moved the locus of blame for crony capitalism away from them by brainwashing 30% of the electorate with fairy-tales that don't stand up to scrutiny.
No, my point is that there are lots of powerful vested interests: politicians, civil servants, billionaires, unions, old people, churches, you name it. They all manipulate public opinion for their own purposes. You arbitrarily want to remove one force from this mix. But self-serving and distorted as, say, the oil and coal industry's propaganda may be, it is the necessary balance to the self-serving and distorted propaganda from organizations like Greenpeace and other environmental groups. And if you look at the last few presidential elections, you'll find that private spending by billionaires was only a small part of overall spending on free speech. Obama easily dwarfed his opponents.
Billionaires have successfully moved the locus of blame for crony capitalism away from them
Crony capitalism is implemented by politicians through regulation, corporate bailouts, and subsidies for "important industries". Now take a look at the position of one of the major organizations funded by the Koch brothers, the Cato institute. They argue strongly for reducing or eliminating all of these mechanisms, because the only known way to reduce crony capitalism and rent seeking is by reducing the mechanisms that make it possible.
On the other hand, every major regulation, bailout, or subsidy by the Obama administration (and the Bush administration as well, for that matter) has contained massive pork and massive crony capitalism. And now Democrats and progressives want to silence their last critics through restrictions on political speech so that they can then engage in crony capitalism free from any scrutiny or criticism. And although I'm sure they generally believe they are doing this for the good of the country, in the end, it's still primarily about their political power.
You have identified the problem correctly, namely crony capitalism and rent seeking, you are simply misidentifying the culprit.
Muller's criticism of Mann's paper was justified: the paper was unsound. After a lot of checking, it turned out that Mann's conclusions about global average temperatures were about right. But what were they right about? A slow temperature rise, amounting to maybe 1C warming per century. That's all the data we actually have. By itself, that's not cause for alarm. It would take centuries even to reach the temperatures of the last few interglacial maxima, and we know that no catastrophic warming took place then.
All the panic and FUD about climate change is based on extrapolations, assumptions about economic and emissions growth, hand waving about positive feedback mechanisms and tippings points. Those are not scientific fact. In fact, many of the statements about climate change by prominent AGW activists are objectively false and contradict long established science.
The voter is not sufficiently informed to make even the most basic of decisions. When exposed to copious amounts of BS from "think tanks", the average voter will inevitably make a BS decision.
He is also exposed to copious amounts of b.s. from politicians, progressives, from unions, from organizations representing "the elderly", "children", and "the environment". All these people have their own agenda, all of them are selfish, and none of them have truth or the common welfare at heart. Voters somehow need to make a decision balancing between all this b.s. Trying to silence one of those selfish groups is simply a political ploy to give the others more power.
Read Hayek, "The Road to Serfdom" for an argument why powerful vested interests should not be able to change the rules to protect themselves from economic disappointment.
And he is absolutely right.
Powerful private citizens can and do propagandize the sheeple for just this effect.
That's your addition and it is absolutely wrong. Your disdain for the voters and citizens is typical of the kind of socialist attitudes that Hayek was strongly opposed to.
In fact, voters are propagandized by "powerful private citizens", by corporations, by unions, by not-for-profits, and by government. They are in balance with one another. You argue that we should remove one of those forces. How does that possibly help? Do you think government, unions, not-for-profits, etc. argue in everybody's best interest? Do you think they are not also interested in maximizing their power, influence, and revenue?
Look up the abuses of power in the gilded age because powerful individuals became laws unto themselves. It all happens through propaganda, which costs money, and a weakness in democracy.
Blaming the abuses of the Gilded Age on free speech is utter nonsense. Social problems in the Gilded Age, such as they were, were due to rapid growth and people just starting to figure out how a large scale modern economy works. The "powerful individuals" were largely powerful due to monopolies, something that government as a legitimate right and obligation to regulate. And relative to the rest of the world, the US was doing extremely well during the Gilded Age. Look at what was going on in Europe at the time and the many millions of Europeans that fled to the US during that time.
Do you want cigarette companies writing the laws? After-all, according to them, they have a metric tonne of scientific evidence that smoking is benign, and protecting their bottom line has nothing to do with killing innocent people.
If cigarette companies knowingly falsify data to misrepresent the safety of their products, then the proper place to determine that is the courts. If you damage my health by forcing me to inhale second hand smoke (e.g., by lighting up on an airplane), then I can sue you too. In our system of government, it's the courts that determine truth, not Congress, not the voter, and not the president.
Anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.
Nice quote, but it doesn't help determine who actually is ignorant and unscientific. I would argue (as would a lot of conservatives and libertarians) that much of the Obama administration's and the progressives' agenda is unscientific and based on ignorance.
Actual facts or scientific data NEVER come up or if they do, it's a liberal conspiracy to tax more and for wealth transfer.
I don't see any actual facts in your post either. And having checked a wide range of predictions and statements by AGW activists, I can say that a large fraction of them are scientifically either unsupported or plain wrong.
That was my point; it's not ostensibly illegal to do what they are doing, and many people are doing it openly, so why are they hiding it?
If the fact that Exxon or the Koch brothers fund conservative and libertarian causes, or that institutes like the Heartland Institute receive money from conservative donors comes as a surprise to you, you're an idiot. You can't accuse them of "hiding it" simply because you're too stupid to figure this out.
The ready stream of cash set off a conservative backlash against Barack Obama's environmental agenda that wrecked any chance of Congress taking action on climate change.
Good. I hope they keep it up. And anybody with half a brain knows who to thank for that.
So, private citizens exercise their right to free speech and say something that differs from the "scientific consensus" preferred by the current administration and the press. That's what free speech and democracy is all about, folks: we let people proclaim whatever sense or nonsense they want to proclaim, and then we trust the voter to sort out right and wrong. People who claim that voters are being manipulated into making bad decisions by "secret denial networks" are saying that they can't come up with convincing counter-arguments. And that by itself means that their own case is weak.
The spike is probably due to garbage collection. And you're right that that can be a problem for real-time applications. But the Linux kernel isn't real-time anyway, and for most uses of Lua in the kernel, this wouldn't matter.
I would expect that, over time, people would change the Lua interpreter for kernel use (it's small and simple), which might include adding a real-time garbage collector.
The benchmarks on which "Perl is faster" are benchmarks where the problem is solved using Perl's regex library while running in interpreted Lua in Lua. That doesn't show you that "Perl is faster", it shows that Perl has a better regex library, a library you can trivially call from Lua as well.
If those benchmarks show anything, it's how impressively fast the Lua interpreter is that it can actually even come in the ballpark of Perl's regex library.
Regardless of how much this would simplify kernel hacking, it means that a lot of controversial or legally restricted code can be added to the kernel with just some tiny text files being passed around. Users could likely add exFAT support, cryptography, DVD decryption, etc. with nothing more than a command like "cat exfat-support >/proc/lua".
And this would also be available at boot time, making it much easier to work around all the weird problems that keep Linux systems from starting; instead of ever increasingly complex configuration files, blacklists, and C-based workarounds, most of those boot problems could be handled by loading a little bit of Lua code at boot time.
Lua interpreter instances are small. In a kernel environment, you'd like run lots of tiny Lua interpreters, one for every "task" you want to perform. You can impose limits on memory and CPU usage on each instance. Under an out-of-memory condition, you can also ask each of them to reclaim a maximum amount of memory, via a hook and via the GC interface. And if that fails, you can start killing them off one by one in order of least importance, just like you might with other processes or functions. The fact that Lua has better defined semantics and interfaces for resource management than a chunk of C code means that it's actually easier to deal with out of memory conditions with Lua interpreters than for general C code.
They make no effort to build something like "memory safe C" ? Quite shoddy decision-making.
There is no widely used, memory safe implementation of C or C++. Even if there were, building a memory safe language on top of C and C++ is itself shoddy decision making because those languages are completely unsuitable to the task.
I consider it crappy if a C program launches in 10ms and less while the ordinary Java program needs 1000ms.
The C program only launches quickly because all of its shared libraries are kept in memory by the kernel. If you loaded it from scratch, it would likely take much longer. C++ is even worse because its libraries are huge and bloated. Lua, in contrast, has a tiny memory footprint and tiny dependencies. By your own measure of "crappiness", it beats Java, C, and C++ hands down.
A lot of it is executed rarely because at least half the code is drivers
And a lot of the non-driver code is executed rarely too.
But, that's more in line with the point that precisely because kernels are generally developed so well, they rarely have "performance critical" code.
The term "performance critical code" doesn't refer to "slow code" and is unrelated to how "well developed" a system is, it refers to sections of code that have a large impact on the overall performance of the system.
And odds are good that having Lua+LuaJIT outside the kernel space yet in the kernel source would have virtually all the benefits and nearly none of the drawbacks.
It has the disadvantages I mentioned: you get context switch overhead, and, more importantly, someone needs to actually define and support all the necessary interfaces for interacting with the kernel. It also only works once there can be user-space processes. Built-in Lua could help a great deal with getting a kernel off the ground, help with boot issues, etc.
But, honestly, I'd feel it safe and saner if it were a language that was reducible to a FSA.
Well, nice, but lots of other people disagree, there is no such tool, and nobody has shown that that is sufficient. Many kernels have been written in dynamic languages (Lisp, Smalltalk, others) or managed languages (C#, Modula-3), etc. So, having a Turing-equivalent managed language with dynamic typing and garbage collection in the kernel has ample precedent. In addition, the NetBSD developers thought it was a good idea. But Lua+LuaJIT gives easy kernel configurability and extensibility at near native speeds in maybe 300kb. You're welcome to try and come up with something better. I doubt that you can within the foreseeable future.
Rationalizations like yours is why people don't bother doing this or much else innovative for Linux anymore. Linus comment on what new functionality came in 3.0 was "NOTHING. Absolutely nothing." And it shows. As a long-time UNIX (and I mean UNIX) hacker, I find Linux has turned into a ridiculous Rube Goldberg contraption, of workarounds on top of patches, much of it meant to stick to a design and design constraints that were relevant in the 1970's.
Either you keep using the existing environment, or you replace it wholesale with Lua. With LuaJit, I see performance that generally makes the codesys mess redundant.
Maybe in "industrial process control" you can afford to throw out everything and start over. But Linux has tens of thousands of kernel developers and billions of deployed devices: C needs to stay. However, once a tool like Lua were in the kernel, one could incrementally migrate functionality to it and reduce kernel bloat. And long time experience with kernels written in dynamic languages shows that you need a small core of routines written in a C-like language. You might as well keep C for that, instead of inventing something completely new.
It's not mainly for messing with device drivers (although it may be useful for that too).
It's mainly useful for all the stuff that people right now create/proc devices, ioctls, and user-level kernel-related daemons for. Those mechanisms are both slow and complicated. With Lua in the kernel, a lot of that stuff can be handled much more easily, without the overhead of context switches and with much less code.
It probably won't replace all the bloated configuration stuff that already exists, but at least when writing new device drivers and new functionality, developers could save a lot of time and effort.
Kernel code is like lots of other code: a lot of it is executed rarely and not performance critical. There's setup code, occasional permissions checking, etc.
In addition, this is not to replace plain C modules (although it may be useful for prototyping), it's for complex and dynamic configurability.
Right now, there are two ways of handling that. One is to invent complex configuration files and data structures, sometimes even little interpreters. The kernel is full of those. They are error prone, complicated, and require a lot of effort to maintain. The other is to put complex decision making into user-space, but that involves context switches and other overhead. It also means lots of special-purpose and redundant code, and lots of documentation and complexity. The kernel uses both of those strategies extensively, one reason why it's so big.
Putting Lua+LuaJIT in the kernel is likely faster than either of those approaches, while at the same time also being easier to maintain and document.
Slashdot Mirror
You really don't have a clue about either history, social science, or economics, do you?
So don't pretend that it is established scientific fact. Climate predictions have not been scientifically tested at all; they are pure guesswork.
No, it is not better if you use this guesswork to justify policies that seriously harm the global economy, and may actually lead to more carbon emissions over the long run.
And Japanese democracy is such a wonderful example to emulate. Riiiight.
There are much easier ways of buying politicians: you give them money directly.
I wouldn't call Lua performance without a JIT "abysmal" compared to C or Java. In terms of runtime on inner loops, it's usually about 5-10x slower, which is pretty good for an interpreter. But that is only one performance measure. Once data structures and libraries get into the picture, any speed advantage of C/Java quickly disappears because those are native in Lua anyway. And even plain Lua beats both equivalent C and Java code on code size and code complexity by 1-2 orders of magnitude, and that often has a big effect on overall performance of a system as well.
And Lua in the kernel isn't trying to replace C, it is trying to complement it. And it's a good complement, because Lua (or Lua+LuaJIT) is tiny, but would allow the kernel to become much smaller and simpler by throwing out a lot of code that C just isn't very good at.
Wind-up radios have been around for a long time and will continue to be around. Baylis didn't invent them, he came up with another way of building one (using a spring for energy storage). It turned out his way wasn't as efficient as other ways (using a capacitor / battery for storage), so he didn't make much money.
No, my point is that there are lots of powerful vested interests: politicians, civil servants, billionaires, unions, old people, churches, you name it. They all manipulate public opinion for their own purposes. You arbitrarily want to remove one force from this mix. But self-serving and distorted as, say, the oil and coal industry's propaganda may be, it is the necessary balance to the self-serving and distorted propaganda from organizations like Greenpeace and other environmental groups. And if you look at the last few presidential elections, you'll find that private spending by billionaires was only a small part of overall spending on free speech. Obama easily dwarfed his opponents.
Crony capitalism is implemented by politicians through regulation, corporate bailouts, and subsidies for "important industries". Now take a look at the position of one of the major organizations funded by the Koch brothers, the Cato institute. They argue strongly for reducing or eliminating all of these mechanisms, because the only known way to reduce crony capitalism and rent seeking is by reducing the mechanisms that make it possible.
On the other hand, every major regulation, bailout, or subsidy by the Obama administration (and the Bush administration as well, for that matter) has contained massive pork and massive crony capitalism. And now Democrats and progressives want to silence their last critics through restrictions on political speech so that they can then engage in crony capitalism free from any scrutiny or criticism. And although I'm sure they generally believe they are doing this for the good of the country, in the end, it's still primarily about their political power.
You have identified the problem correctly, namely crony capitalism and rent seeking, you are simply misidentifying the culprit.
Muller's criticism of Mann's paper was justified: the paper was unsound. After a lot of checking, it turned out that Mann's conclusions about global average temperatures were about right. But what were they right about? A slow temperature rise, amounting to maybe 1C warming per century. That's all the data we actually have. By itself, that's not cause for alarm. It would take centuries even to reach the temperatures of the last few interglacial maxima, and we know that no catastrophic warming took place then.
All the panic and FUD about climate change is based on extrapolations, assumptions about economic and emissions growth, hand waving about positive feedback mechanisms and tippings points. Those are not scientific fact. In fact, many of the statements about climate change by prominent AGW activists are objectively false and contradict long established science.
He is also exposed to copious amounts of b.s. from politicians, progressives, from unions, from organizations representing "the elderly", "children", and "the environment". All these people have their own agenda, all of them are selfish, and none of them have truth or the common welfare at heart. Voters somehow need to make a decision balancing between all this b.s. Trying to silence one of those selfish groups is simply a political ploy to give the others more power.
And he is absolutely right.
That's your addition and it is absolutely wrong. Your disdain for the voters and citizens is typical of the kind of socialist attitudes that Hayek was strongly opposed to.
In fact, voters are propagandized by "powerful private citizens", by corporations, by unions, by not-for-profits, and by government. They are in balance with one another. You argue that we should remove one of those forces. How does that possibly help? Do you think government, unions, not-for-profits, etc. argue in everybody's best interest? Do you think they are not also interested in maximizing their power, influence, and revenue?
Blaming the abuses of the Gilded Age on free speech is utter nonsense. Social problems in the Gilded Age, such as they were, were due to rapid growth and people just starting to figure out how a large scale modern economy works. The "powerful individuals" were largely powerful due to monopolies, something that government as a legitimate right and obligation to regulate. And relative to the rest of the world, the US was doing extremely well during the Gilded Age. Look at what was going on in Europe at the time and the many millions of Europeans that fled to the US during that time.
If cigarette companies knowingly falsify data to misrepresent the safety of their products, then the proper place to determine that is the courts. If you damage my health by forcing me to inhale second hand smoke (e.g., by lighting up on an airplane), then I can sue you too. In our system of government, it's the courts that determine truth, not Congress, not the voter, and not the president.
Nice quote, but it doesn't help determine who actually is ignorant and unscientific. I would argue (as would a lot of conservatives and libertarians) that much of the Obama administration's and the progressives' agenda is unscientific and based on ignorance.
I don't see any actual facts in your post either. And having checked a wide range of predictions and statements by AGW activists, I can say that a large fraction of them are scientifically either unsupported or plain wrong.
As they are for climate change.
Once "the facts" will become obvious, then people will gladly vote for action. Until "the facts" are obvious, they aren't facts at all to most people.
If the fact that Exxon or the Koch brothers fund conservative and libertarian causes, or that institutes like the Heartland Institute receive money from conservative donors comes as a surprise to you, you're an idiot. You can't accuse them of "hiding it" simply because you're too stupid to figure this out.
Good. I hope they keep it up. And anybody with half a brain knows who to thank for that.
So, private citizens exercise their right to free speech and say something that differs from the "scientific consensus" preferred by the current administration and the press. That's what free speech and democracy is all about, folks: we let people proclaim whatever sense or nonsense they want to proclaim, and then we trust the voter to sort out right and wrong. People who claim that voters are being manipulated into making bad decisions by "secret denial networks" are saying that they can't come up with convincing counter-arguments. And that by itself means that their own case is weak.
The spike is probably due to garbage collection. And you're right that that can be a problem for real-time applications. But the Linux kernel isn't real-time anyway, and for most uses of Lua in the kernel, this wouldn't matter.
I would expect that, over time, people would change the Lua interpreter for kernel use (it's small and simple), which might include adding a real-time garbage collector.
The benchmarks on which "Perl is faster" are benchmarks where the problem is solved using Perl's regex library while running in interpreted Lua in Lua. That doesn't show you that "Perl is faster", it shows that Perl has a better regex library, a library you can trivially call from Lua as well.
If those benchmarks show anything, it's how impressively fast the Lua interpreter is that it can actually even come in the ballpark of Perl's regex library.
Regardless of how much this would simplify kernel hacking, it means that a lot of controversial or legally restricted code can be added to the kernel with just some tiny text files being passed around. Users could likely add exFAT support, cryptography, DVD decryption, etc. with nothing more than a command like "cat exfat-support > /proc/lua".
And this would also be available at boot time, making it much easier to work around all the weird problems that keep Linux systems from starting; instead of ever increasingly complex configuration files, blacklists, and C-based workarounds, most of those boot problems could be handled by loading a little bit of Lua code at boot time.
Lua interpreter instances are small. In a kernel environment, you'd like run lots of tiny Lua interpreters, one for every "task" you want to perform. You can impose limits on memory and CPU usage on each instance. Under an out-of-memory condition, you can also ask each of them to reclaim a maximum amount of memory, via a hook and via the GC interface. And if that fails, you can start killing them off one by one in order of least importance, just like you might with other processes or functions. The fact that Lua has better defined semantics and interfaces for resource management than a chunk of C code means that it's actually easier to deal with out of memory conditions with Lua interpreters than for general C code.
There is no widely used, memory safe implementation of C or C++. Even if there were, building a memory safe language on top of C and C++ is itself shoddy decision making because those languages are completely unsuitable to the task.
The C program only launches quickly because all of its shared libraries are kept in memory by the kernel. If you loaded it from scratch, it would likely take much longer. C++ is even worse because its libraries are huge and bloated. Lua, in contrast, has a tiny memory footprint and tiny dependencies. By your own measure of "crappiness", it beats Java, C, and C++ hands down.
And a lot of the non-driver code is executed rarely too.
The term "performance critical code" doesn't refer to "slow code" and is unrelated to how "well developed" a system is, it refers to sections of code that have a large impact on the overall performance of the system.
It has the disadvantages I mentioned: you get context switch overhead, and, more importantly, someone needs to actually define and support all the necessary interfaces for interacting with the kernel. It also only works once there can be user-space processes. Built-in Lua could help a great deal with getting a kernel off the ground, help with boot issues, etc.
But, honestly, I'd feel it safe and saner if it were a language that was reducible to a FSA.
Well, nice, but lots of other people disagree, there is no such tool, and nobody has shown that that is sufficient. Many kernels have been written in dynamic languages (Lisp, Smalltalk, others) or managed languages (C#, Modula-3), etc. So, having a Turing-equivalent managed language with dynamic typing and garbage collection in the kernel has ample precedent. In addition, the NetBSD developers thought it was a good idea. But Lua+LuaJIT gives easy kernel configurability and extensibility at near native speeds in maybe 300kb. You're welcome to try and come up with something better. I doubt that you can within the foreseeable future.
Rationalizations like yours is why people don't bother doing this or much else innovative for Linux anymore. Linus comment on what new functionality came in 3.0 was "NOTHING. Absolutely nothing." And it shows. As a long-time UNIX (and I mean UNIX) hacker, I find Linux has turned into a ridiculous Rube Goldberg contraption, of workarounds on top of patches, much of it meant to stick to a design and design constraints that were relevant in the 1970's.
Maybe in "industrial process control" you can afford to throw out everything and start over. But Linux has tens of thousands of kernel developers and billions of deployed devices: C needs to stay. However, once a tool like Lua were in the kernel, one could incrementally migrate functionality to it and reduce kernel bloat. And long time experience with kernels written in dynamic languages shows that you need a small core of routines written in a C-like language. You might as well keep C for that, instead of inventing something completely new.
It's not mainly for messing with device drivers (although it may be useful for that too).
It's mainly useful for all the stuff that people right now create /proc devices, ioctls, and user-level kernel-related daemons for. Those mechanisms are both slow and complicated. With Lua in the kernel, a lot of that stuff can be handled much more easily, without the overhead of context switches and with much less code.
It probably won't replace all the bloated configuration stuff that already exists, but at least when writing new device drivers and new functionality, developers could save a lot of time and effort.
Kernel code is like lots of other code: a lot of it is executed rarely and not performance critical. There's setup code, occasional permissions checking, etc.
In addition, this is not to replace plain C modules (although it may be useful for prototyping), it's for complex and dynamic configurability.
Right now, there are two ways of handling that. One is to invent complex configuration files and data structures, sometimes even little interpreters. The kernel is full of those. They are error prone, complicated, and require a lot of effort to maintain. The other is to put complex decision making into user-space, but that involves context switches and other overhead. It also means lots of special-purpose and redundant code, and lots of documentation and complexity. The kernel uses both of those strategies extensively, one reason why it's so big.
Putting Lua+LuaJIT in the kernel is likely faster than either of those approaches, while at the same time also being easier to maintain and document.
I don't know what you mean by "pretty abysmal, performance wise". Lua is one of the fastest scripting languages around, even without LuaJIT.