Kind-of a long-winded way to point out the (very well known) fact that passing non-terminated strings to functions that expect terminated strings is fraught with danger, isn't it?
Nope, and what I'm actually doing is fuzzing the input to this function, which is a common breaking technique.
You see, programmers tend to go around only using functions exactly as they were intended. Hackers come along and then use them in unintended ways, which causes bugs. The way to prevent this is to think like a hacker and try to use your code in unintended ways and then try to prevent them.
Profile your existing app and find out what is making it slow.
When you fully understand how your existing app performs (and why it performs) you may start making informed decisions.
Profiling is a highly technical art that is beyond even most competent programmers. You need a good systems engineer who is proficient with the tools used to examine application performance on your system, and understands the different technology stacks involved (networking, disk I/O, cpu/threading/scheduling, virtual memory etc.). If you can reproduce the problem, they should be able to pinpoint the cause.
Also, you may want to read up on Node.js and understand what benefits it brings to the table - it is not a silver bullet that solves all Web application problems.
This is so typical of the brain rot most technology reviewers suffer from.
The basic line is something like "if it has been well engineered, and someone has put a whole lot of effort into it, and its a bit different to everything else out there, then we are basically obliged to give it high marks".
They seem incapable of judging devices by the most basic and important standard: user experience. If the user experience is bad, then nothing else matters. A user interface is not brilliant if no one wants to use it.
WinPho7 is the best current example of this going round. Almost universally acclaimed by reviewers, almost totally ignored by consumers.
I like the design of the Metro UI. I can find my way around, the transitions and layout is basically informative and attractive. In my mind, it beats the tar out of Android in those dimensions. I'm not sure if I could even call it inferior to the design conventions and capabilities on iOS, which often accrues the most praise.
Although you could take "user experience" to very generalized levels ("did it get to market early enough", "do my friends have it", "are there applications I want", "is it in the mobile phone store"), these are usually considered social or business questions. One only need look at the flop of the Nexus One -- basically a well designed phone, but one that was positioned poorly with carriers -- for evidence.
I think it is sociological and business factors that blight the Windows Phone, not its design or user experience, except in the most overgeneralized sense.
Have you actually used Windows Phone for any considerable length of time and have any real criticisms of the UX or are you just armchair quarterbacking? At least all the reviewers have actually used the devices, some for a week.
I'm trying to think of a way to read your question that doesn't make it dismissive and condescending. Why wouldn't the current three implementations be angled for real-world use?
I'm using Perl 6 "in the real world". I use it on my spare time. I use it at work. I have production code running in Perl 6. I use Perl 5 even more heavily, but with each month I use Perl 5 a little less and Perl 6 a little more.
"Why wouldn't the current three implementations be angled for real-world use?"
Because going to perl.org -> Download says "We recommend that you always run the latest stable version, currently 5.14.2." [1] and doesn't even mention Perl 6.
And when you do find a page that has Perl 6, it says "If you are looking for production ready code please use Perl 5" [2]
When somebody asks you "What's the latest version of C?" Do you answer "C++11"? Of course not.
Perl 5 and Perl 6 are two different languages that happen to share a similar style and history. The latest version of Perl5 will never be 6.something.
And yes, Perl6 is not recommended for production use, since the specification has not been finalized. By the same argument, C++0x should not have been, yet many people did.
As a comparison, python.org has both Python 2 and Python 3 binaries clearly marked and available for download.
I'll be surprised if Perl 6 gets much attention until the perl.org download page has links to Perl 6 binaries, like it does for Perl 5 binaries. Visiting the download page, you wouldn't even know Perl 6 exists.
By the same argument, C++0x should not have been, yet many people did.
I see little equivalence; despite the flux of the C++0x specification, many C++ useful and usable compilers existed and implemented several portions of the specification.
Put another way, the draft status of portions of the Perl 6 specification say nothing about whether "Just compile git HEAD yourself!" is the preferred distribution and deployment mechanism, nor about whether the right approach to supporting real users involves slapping a TODO tag on regressions to appease the test suite.
... many [Perl 6] useful and usable compilers exist and implement several portions of the specification.
My company was working on a product based on Perl 6 two years ago. We planned to release it to paying customers at the time of the Rakudo Star release. We officially scuttled it several weeks ago when it became obvious that Rakudo's development process would continue to be incompatible with shipping a working product for as far as we could predict (and two of us have commit access to most or all of the Rakudo stack, so it's not like we're disconnected from the development of Perl 6).
The words "useful" and "usable" do not reflect the reality of the situation.
This is rather surprising, coming from you. In past years, you vehemently took the opposite side of that argument (e.g. https://qht.co/item?id=1737504).
Could you explain what happened to change your perspective?
Could you explain what happened to change your perspective?
Certainly. Rakudo Star wasn't what everyone hoped it would be, but I figured another few months of tuning and releases would let it stabilize to the point where our customers could rely on it as a significant part of the product. That was my understanding of Rakudo Star, sort of the Perl 6 version of Debian Testing versus the Debian Unstable monthly compiler releases.
Performance wasn't a huge concern; the five to ten percent monthly improvements we were getting were sufficient for our projections, if they continued. (They did.)
Around December 2010, some of the Rakudo discussion turned to rewriting the main implementation language used to bootstrap Rakudo (and part of the discussion was "Hey, this'll be a great opportunity to consider targeting additional backend VMs!"). Scopes creep and rewrites produce regressions and remove stability.
Rakudo forked its development into "The old stuff that used to be Rakudo Star but won't get any updates or even releases" and "The new branch which will become the main branch even though it won't see any releases and has huge regressions" and they're starting to address regressions now.
As you might expect, the release schedule for Rakudo Star slipped from "every month" to "every three months" to "whenever things get stable".
In the absence of project discipline to release stable code every month--in a culture which believes it's okay to tell people "Sure, it's useful and usable, just track Git HEAD for multiple components"--you can't deploy a product without heroics. I'm not going to risk my business on heroics.
In short, they stopped delivering a stable product and I stopped believing in their ability or their desire to do so.
As an outside observer of Perl 6 development since its conception, I feel that this pattern (Scope creep and massive rewrites / depreciation of current infrastructure whenever one component was in "danger" of becoming useful) has played out over and over again throughout the life of the project.
This went back at least to the original Parrot announcement. Arguably, even the _birth_ of Perl 6 was based on the idea of a massive rewrite, superseding the much more modest Topaz effort (After about two years of development, Topaz had not yet delivered fully working code. The original announcement of Perl 6 promised working code in 18 months).
Parrot and Perl 6 really suffered until Pugs started producing a standalone test suite. If Perl 6 on Parrot had had that in 2000 or 2001, things might have turned out differently.
I normally agree that throwing away working code and starting anew is the wrong approach, but trying to rewrite the Perl 5 internals to support Perl 6 would have taken at least as long as Parrot and Rakudo have taken; it's really that impenetrable in places.
Your phrase "in danger of becoming useful" is quite perceptive though; I wish I'd thought of it.
I love perl6, and though I wish otherwise, I have to agree with this assessment. #perl6 is a resonant echo chamber, but I do admire the people and enjoy reading the logs. Maybe one day...
I am very interested in Perl 6. What would be the recommended implementation to use in production? What are your experiences with using it in production?
I've been an active Perl 6 user since 2008; during that time, I've often had too high expectations on then-current Rakudo implementations: I've been dabbling in wiki software, etc. It was slow. Sometimes it was unstable.
Seen from ten thousand meters, Rakudo 2008-2010 was about features, and Rakudo 2011 has been about performance. As moritz' retrospective states, the fruits of that work are only coming online now. That will enable more people to move into performance-sensitive fields such as web development with Perl 6. That's already starting to happen; see tadzik's Bailador project, for example.
Meanwhile, my Perl 6 production code has been getting by with slightly lowered expectations on performance and memory frugality. Crashes/segfaults are no longer a problem (as they were in 2008/2009). Tradeoff example: My blog, which runs on Perl 6, is statically generated rather than dynamically. That's been working out pretty nicely.
When I need more speed and/or regex/grammar features, I go with Niecza. Otherwise, I mostly develop on Rakudo. But Niecza's main developer is developing at an almost intimidating pace, and I expect to be using Niecza even more in 2012.
"real world" means different things for different people.
At this point how many companies do you know of that use perl6 to solve their business problem (may be as simple as a web app) ?. Has there been any job posting anywhere which are looking for perl6 devs?
That said, there's two of us in the company I work for: http://www.edument.se/english/ . I got hired mostly on my merits as a Perl 6 core contributor. We're eager to hire more Perl 6 programmers.
I see what you did there. Your assuming people who use G+ are trying to share their lifes with you. They are not. If I want to "share my life" with people. I will call them and drive to their house and spend time with them. That is sharing of life. Posting social gossip on a website is not.
