On Fri, 23 Feb 2018 19:25:35 +0000, bartc wrote: > On 23/02/2018 18:05, Steven D'Aprano wrote: >> On Fri, 23 Feb 2018 13:51:33 +0000, Ben Bacarisse wrote: > >> Stop writing crap code and then complaining that the language is "too >> slow". Write better code, and then we'll take your complaints >> seriously. > > I write compilers for static languages, which are generally considered > toys, partly because the code generated is not great.
I have no idea whether your compilers are toys, or what "not great" means for your generated code. - too slow for the intended purpose? - full of bugs? - generated code is enormous? - requires too much memory? - all of the above? If the actual answer is, "none of the above", then apart from your failure to attract users and build a full ecosystem around your compiler, I see no reason to call them toys. If your compilers can get within 10% of best-of-breed C compilers, even if only on trivial problems, that's nothing to sneer at. If you can do it on non-trivial applications (say, the Linux kernel) without introducing a vast number of compiler-generated bugs, then you're doing very well indeed. In another post (responding to Chris) you wrote: > Python is 10 times slower than a competitor = doesn't matter > My language is 1.5 times slower than the big boys' = matters > a great deal Maybe it matters to *you*. You are the one who stated it was a toy compiler. To me, I have *no idea* whether the compiler is any good. Nobody but you uses it. I once tried to compile it, and couldn't get it to compile. As for Python's order-of-magnitude speed difference, thank you for being generous. If you cherry-pick the right benchmarks, you could easily have said it was two orders-of-magnitude slower. On the other hand, if you use PyPy, and similarly cherry-pick the right benchmarks, you can justifiably say that *Python is faster than C*. (On carefully chosen examples which probably aren't representative of full application performance.) But okay, let's take "Python is an order of magnitude (between 10 and 90 times) slower than C" for the sake of the argument. Does it matter? Maybe. Maybe not. Sometimes it matters. Sometimes it doesn't. The world's fastest street-legal production car is, so I'm told, the Bugatti Veyron Super Sport. It has a top speed of 268 mph and the engine has 1200 horsepower. And yet literally *billions* of car drivers choose to drive something slower. They wouldn't buy a Veyron even if they could afford it. Why shouldn't people make choices based on factors other than speed, speed, speed, speed, speed? Ruby has fallen out of favour now, but for quite a few years it was looking like a contender despite being an order of magnitude slower than Python. Which is an order of magnitude slower than Java, which is an order of magnitude slower than C, according to some benchmarks at least. People write business applications using Excel spreadsheets and macros. And why not? So it is quite possible to get practical work done and be a competitive, useful language despite being (allegedly) a thousand or more times slower than C. [...] > Have you ever written a benchmark in your life? If so, did it do > anything useful? Other than what benchmarks are normally used for. Yes I have, not for what benchmarks are normally used for (dick-measuring contests between programmers competing to see whose language is more macho) but for the very practical purposes of: (1) Deciding which algorithm to use in practice; (2) Ensuring that updates to the code don't suffer serious performance regressions; (3) And checking that the code is *fast enough* (not as fast as conceivably possible) for its purpose. They are the sorts of benchmarks I care about. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
