|
in reply to Re: -Ofun times
in thread -Ofun times
I get it -- optimization is a fun game. But isn't one of the rules of Optimization Club to implement the spec first, and optimize once that's been done?
That's only if you do waterfall-style development, and if you have well-financed dev team.
But we are volunteer-driven dev team, and so we must also keep those developers happy. And having a dog slow compiler frustrates people, and drives them away. And if volunteer devs have no users and no fun, they stop developing.
Another point is that we're listening to user feedback. When we first released the Rakudo Star distribution, we got lots and lots of feedback. Most of it was "this is very cool, but please make it much, much faster (and less memory hungry)".
Also, while Rakudo isn't feature complete, most user complaints these days concern performance and reliability, not features. Most missing things are very much orthogonal (and on a higher level) than the current optimization, so we don't expect much friction from adding those features later. Quite the opposite; since Rakudo is a partially self-hosting compiler, optimizing it speeds up the development cycle, which makes it easier to add more features.
Finally I'd like to point to other languages and compilers, like C++ with gcc and clang, and C# with mono/roslyn, and java with OracleJVM/OpenJDK + javac. The compiler (and VM) developers spend quite some time optimizing for performance. Yet none of the languages are feature complete, they are all being developed constantly. And not just the languages, the compilers have to catch up on those features too. Do you think they are all wrong too?
|
Re^3: -Ofun times
by Anonymous Monk on Apr 12, 2014 at 13:57 UTC
|
TIL that #perl6 believes that comparing perl-6 to C++, C#, or Java doesn't make perl-6 look like a horrible, mismanaged, irrelevant death march.
Mind blown.
Well played. Perhaps those other three languages will eventually have real world users too someday? It will be interesting to see if they also get documentation, libraries, backwards compatibility, stability, tooling, packaging, and project management. | [reply] |
Re^3: -Ofun times
by Anonymous Monk on Apr 14, 2014 at 08:31 UTC
|
That's only if you do waterfall-style development, and if you have well-financed dev team.
How is that true? Does agile say that you requirements be never frozen?
And having a dog slow compiler frustrates people, and drives them away.
How big is your user base and how many have been driven away? There are slower tools, like Scala. Which many people have no problem in using. Mainly because they can atleast use it, instead of a product that isn't complete but promises to be. I guess you don't realize you have a literally zero user base, apart from a few people who like to write one liners on IRC or write toy programs to implement commonly known algorithms on Forums which no one takes seriously. Which explains why they are happy with a sub set of features. Because for most toy programs you don't need much, but the existing ones to run fine
Also, while Rakudo isn't feature complete, most user complaints these days concern performance and reliability, not features.
Also who are these users? Can you show us at least on serious use of Perl 6 in the wild? A big company, A start up? Anything?
C++ with gcc and clang, and C# with mono/roslyn, and java with OracleJVM/OpenJDK + javac. The compiler (and VM) developers spend quite some time optimizing for performance. Yet none of the languages are feature complete
They are incomplete in the same sense iPhone, or your TV is incomplete. It doesn't mean iPhone's or TV's aren't usable now. It only means they may get a few feature based on the competition they face in the future
Perl 6 is just incomplete. Its a bit like shipping an iPhone without a feature to store phone numbers. That's a very different kind of incompleteness than the former.
| [reply] |
|
|
Also who are these users?
We get feedback on IRC, twitter, mailing lists, blogs, and on conferences in real life. I don't know what all of those people do with Perl 6, only some. Some of them write IRC bots, others write Perl 6 code that refactors their java code, again others manipulate CAD file with Perl 6, for their own consulting business.
Some of those projects are developed and maintained over years, and make their owners money. IMHO that's "serious".
Anyway, are you trying to imply that we shouldn't listen to user feedback because there are no facebook-scale Perl 6 installation? That it's OK to be annoyingly slow because we don't have a huge user base? And instead listen to a rather aggressive, anonymous poster on perlmonks?
Anyway, I'm afraid I'm wasting my time here. If we implement new features, people complain that rakudo is unusable because it's too slow and buggy; if we spend time optimizing it, people complain that we should make it feature complete first. Whatever we do, we'll get hate and pushback from random people on the Internet, so there's nothing left to do but do what we think is best.
| [reply] |
|
|
Why not triage things? In the long list of things. I would prefer to be spec complete first and then take up optimization. No one here is saying optimization shouldn't be done. The question is when? When product itself is half complete whats the point in optimizing an half complete product?
Whatever we do, we'll get hate and pushback from random people on the Internet, so there's nothing left to do but do what we think is best.
This is what bought us into this trouble in the first place. Secondly if a project is 14 years late. And all people see is sub projects and re writes how do you expect people to react?
Either way the days of the Perl 6 hope are over. We are now in a stage where we accept we won't see a Perl 6 ever. If we ever see, its just a good thing to have.
Say whatever you like, but by looking at the current progress I see at least 3 years of waiting time till we get something useful.
| [reply] |
|
|
|
|
| |
|
|
|
| |
|
|
|
|
|
Way to strawman, Moritz.
perl-6 has no real users (except that sorry sad sack writing IRC bots and making millions of dollars in production!!) because no-one trusts you all to deliver something "useful and usable". That was Rakudo Star and that was four years ago and you couldn't even be arsed to write documentation or make installable packages or keep the (few) modules passing their tests or even compiling from month to month.
No, Rakudo Star was followed by a huge rewrite that took months. At the end of the process you all announced your intention to abandon the single piece of the project that demonstrated any project management acumen at all, and now you're wondering why all of its contributors vanished.
Somehow you've convinced yourself that the only user feedback you've ever received is "it's too slow".
But I guess that's what you get when you don't have any users besides the spec tests.
After 14 years, you don't even have a static website generator, let alone a replacement for WordPress.
That's why people don't take you seriously. Because after all these years, you still don't have anything anyone would feed to a dog.
So go on, keep doing what you think is best. Because it's clearly worked out well so far. perl-6 is going to have as many users as Perl sometime soon, not because perl-6 is getting more users but because it's poisoned Perl.
| [reply] |
|
|
I would like to say that:
I am one of those users which don't use Rakudo mostly because it is too damn slow.
Last month I switched back from Scala to Perl 5 one of my projects because the scala compiler/toolset was so slow I couldn't bear it anymore.
I don't mind about the incomplete parts, I could add them myself if required. Perl 5 is also quite incomplete in several ways.
Yea, I like implementing algorithms!
| [reply] |
|
|
