| |||||||||||||
Should be: Goodnight, Perl 6.Should be: Goodnight, Perl 6.Posted Feb 11, 2013 0:44 UTC (Mon) by rqosa (subscriber, #24136)In reply to: Should be: Goodnight, Perl 6. by tjc Parent article: Chromatic: Goodnight, Parrot Starting over from scratch at this point would be madness, since Rakudo is almost feature complete. They've just got to turn the last few red and yellow boxes green, and then it's all done.
(Log in to post comments)
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 0:55 UTC (Mon) by dskoll (subscriber, #1630) [Link] They've just got to turn the last few red and yellow boxes green, and then it's all done. I don't think so. It has admittedly been a while since I looked at Rakudo, but when I did look at it it was unbelievably slow and huge compared to Perl 5. Getting Rakudo to "work" in the sense of implementing the Perl 6 spec may be doable. Getting it to be a viable and useful language comparable to Perl 5 in size and speed? I'm not holding my breath.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 3:10 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Well, doing better than Perl5 shouldn't be that hard. I mean, come on, it can't even collect reference cycles. In 2013. It doesn't have bloody subroutine signatures. And let's not mention WTFs like "Variable "$foo" will not stay shared".
That said, the field of "dynamically typed" (read: unityped), object-oriented programming languages is crowded enough already; I don't think we need Perl 6 either. Parrot would have been interesting if it had actually delivered as the "one dynamic VM to rule them all", so that code can be shared between different languages. But the article seems to indicate otherwise. Perhaps PyPy will be more successful, given the recent development of Topaz.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 5:34 UTC (Mon) by eru (subscriber, #2753) [Link] Perl5 [...] I mean, come on, it can't even collect reference cycles ... subroutine signatures ...Who cares, for the kinds of things Perl was originally intended to, and where it excels? It works fine as a "better sh" or a "better awk". I have found it to be just about the perfect language for small programs in the range of 100 ... 1000 lines that do some file manipulations and/or launch other programs. For large programs there exist several more suitable options, so there is no point in extending Perl beyond its original design.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 7:27 UTC (Mon) by tpo (subscriber, #25713) [Link]
In another thread someone asked, commenting on your tone, whether your account couldn't just be deleted:
> I don't think we need Perl 6 either.
Perl6 does have some interesting ideas (like being able to change the language parser from within a program). That phrase of you is scolding.
I'd say you did not read the original article or when you read it, did not digest one of its main points: Chromatic says there that developer motivation and interest is not fungible and that once it was not fun any more the negative comments (among others things) made him quit.
So what's the point of you commenting? With your negative comments making people quit doing what they like and that way showing the superiority of your opinions?
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 18:03 UTC (Mon) by HelloWorld (guest, #56129) [Link]
I'm writing comments to express my opinions. The fact that some people seem not to like them doesn't bother me very much.
> So what's the point of you commenting? With your negative comments making people quit doing what they like and that way showing the superiority of your opinions?
That said, my comment isn't as negative as you imply. I said that I like the idea of sharing code written in different languages through a common VM like Parrot; how is that negative? It's a sad fact it didn't deliver in that regard; the Parrot Wiki [1] doesn't list a single language that is maintained and considered production-ready except for HQ9+, which is a joke language.
And yes, I said that I don't think we need Perl 6. What people don't seem to realise is that there's a cost associated with having more choice than necessary. When people write code in Perl 6, I can't reuse their code in whatever language I happen to use and vice versa, so everybody loses. And if I really want to rewrite my program's AST, I can do that with Clojure and use all kinds of Java libraries along the way. But actually, I don't like so-called dynamic languages for the reasons mentioned in [2]. Statically-typed languages like Scala or Haskell make DSELs easy enough for my taste.
[1] http://trac.parrot.org/parrot/wiki/Languages
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 8:23 UTC (Mon) by epa (subscriber, #39769) [Link]
I think the point being made was not about the quality of the language so much as the implementation. The Perl 5 implementation is old technology: it doesn't have dynamic native code compilation, or even a real garbage collector, as you noted. But the upside of that is that it is mature and, for what it does, pretty fast. A complex algorithm implemented in Perl will never run as fast as Javascript with the latest engines, but programs that do a small amount of processing around builtin C routines (such as the regexp engine) have decent performance and not excessive memory usage. The Unicode support is nowadays very good too. Rakudo being something new hasn't been optimized to the same extent.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 8:53 UTC (Mon) by khim (subscriber, #9252) [Link] I mean, come on, it can't even collect reference cycles. Why is it a problem? Refcounting it probably the best compromise between predictability and convenience. Note how MacOS is losing the much lauded ability to handle reference cycles. Sure, you get an instrument which is less pleasing from the abstract beauty POV but which is infinitely more usable: you can use it to track external resources, you know exactly how much memory is used at any particular moment, etc. And it's not as if you can't leak memory with "proper" garbage collector. Proponents of "full-blown" garbage collectors start foaming at this point and explain how these memory leaks are not memory leaks at all but the fact remains: when your program runs out of memory it does not matter if your leaks are "real" (and can be removed by a "proper" garbage collector) or "unreal" (and thus will be around no matter what you do). If you know and can guarantee that all the references to "dead" data structures will be eliminated then usually it's easy to do the next extra step and break cycles apart, too, and if your data structures are so complex that you can't tear up the cycles then usually your program will consume endless amount of memory for "non-leaks" in some cases anyway.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 9:23 UTC (Mon) by alankila (subscriber, #47141) [Link]
The stated justification for losing the capability is to align even OS X developers with the iOS way of the world, where GC is apparently thought to be too expensive. Funnily though, Android phones show that GC is entirely feasible on mobile. I guess they should have tried harder.
And the "leaks" possible with garbage collector are usually not your father's memory leaks. The runtime doesn't lose track of the objects, it just can't release them because programming mistake prevents that. It's usually not hard to track down and fix, because you can capture snapshot of the heap and work out which objects are around by large numbers at the end of the day. (I do not think I've ever had to do this, whereas I've crashed production applications because of inadvertently introduced reference cycles. It shows to me which problem is more severe.)
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:35 UTC (Mon) by khim (subscriber, #9252) [Link] Funnily though, Android phones show that GC is entirely feasible on mobile. Sure, if you'll throw dual-core 1.2GHz CPU on the task which works perfectly fine on 600MHz iPhone 3GS you'll get the expected result. But is it really wise use of resources? The stated justification for losing the capability is to align even OS X developers with the iOS way of the world, where GC is apparently thought to be too expensive. Which is kind of strange because iPhone 5 specs are about half of what desktop Mac had when garbage collection was introduced in MacOS X 10.5, isn't it? And next iPhone will probably be more powerful then these macs. No, I think they just found that garbage collection is just unacceptable: it introduces jitter which is not easily observable on a desktop with mouse but is a big problem for touchscreen. But of course there are PR and to say that all these decades of GC-science were just waste of time is not politically correct thing to do.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 20:55 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Sure, if you'll throw dual-core 1.2GHz CPU on the task which works perfectly fine on 600MHz iPhone 3GS you'll get the expected result. But is it really wise use of resources?
First Android phones had 300MHz CPUs and were pretty snappy.
That's because Dalvik should be used as a glue system for native code and the UI layer.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 21:27 UTC (Wed) by khim (subscriber, #9252) [Link] >Sure, if you'll throw dual-core 1.2GHz CPU on the task which works perfectly fine on 600MHz iPhone 3GS you'll get the expected result. But is it really wise use of resources? Sorry, but no. Not sure which 300MHz you are talking around but I still have G1 which has 528MHz - and it's laggy as hell. Sometimes it does not react on click for a second or more when you just adjust alarm time! And when I need couple of seconds to go from "new SMS arrived" to the content of said SMS from the home screen... on an idle device with 192MB of RAM? No, it's the exact opposite of snappiness. Now, that's true that not all these freezes are caused by GC, but many of these are indeed a GC freezes. Especially when you scroll something. Basically the only way to have smooth scrolling on G1 was to allocate all the objects once and then reuse them as was noted before. I seriously doubt that's GC creators imagined it's use but in practice it's often the only thing that works reliably.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:46 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Try to connect to it and do GC debugging. You'd be surprised.
Most of pauses happen because there's very little RAM on the phone so it has to load applications every time you try to access them. And while Dalvik was specifically designed to make this fast, crappy flash layer often makes it slow.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 21:30 UTC (Wed) by khim (subscriber, #9252) [Link] That's because Dalvik should be used as a glue system for native code and the UI layer. But UI code is the code where latency is more important then throughput! It does not matter if you render new frame 10 milliseconds or 15 milliseconds, but if you usually render it in 5 milliseconds but occasionally need 50 then you have a problem - and this is exactly what typical GC does to your program.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:44 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
GC in G1 rarely took more than 20ms _and_ it was designed to be interruptible. I've actually debugged laggy applications on G1 and most of lags were caused by the native libraries taking too much time to do stuff.
Flash drive on G1 is also pretty crappy and can sometimes pause for a long time even on simple operations.
GC or not GC Posted Feb 13, 2013 23:04 UTC (Wed) by marcH (subscriber, #57642) [Link]
> GC in G1 rarely took more than 20ms _and_ it was designed to be interruptible. I've actually debugged laggy applications on G1 and most of lags were caused by the native libraries taking too much time to do stuff.
In fact the real problem that this discussion demonstrates is the lack of transparency. Not just developers but semi-technical, "power users" should be able to do basic "lag troubleshooting" with relative ease, on the field, not requiring a PC and remote debugger.
GC or not, Android or iOS, all these systems should have basic self-monitoring and logging features *built-in* producing clear, power-user readable reports of all events like "ran out of memory, terminated X while Y was using 100M" and "ran GC for 2 seconds", etc.
Nothing beats name and shame. This is how Powertop multiplied by 2 or 3 the battery life of many Linux laptops.
GC or not GC Posted Feb 13, 2013 23:08 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
You can get GC logs without debugger. But why do you need them? Debugging lags is not really a stuff that power users should do.
> GC or not, Android or iOS, all these systems should have basic self-monitoring and logging features *built-in* producing clear, power-user readable reports of all events like "ran out of memory, terminated X while Y was using 100M" and "ran GC for 2 seconds", etc.
GC or not GC Posted Feb 14, 2013 0:42 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Debugging lags is not really a stuff that power users should do.
It's the only way to identify the guilty applications/services/system configurations/etc
As another example Windows' Resource Monitor (from Vista onwards) totally changed my Windows experience. I used to struggle against bloatware, taking random shots in the dark. Thanks to the Resource Monitor I am now doing surgical and very successful strikes in no troubleshooting time at all.
Too bad there is no "bootchart for Windows" yet. Or isn't there? Autoruns is nice but just a list.
Any complex and professional system has monitoring features built-in. Why not smartphones too? They are certainly complex enough to deserve this.
> Android has something like it, it can estimate the power use by application. You can use various apps to view these stats.
These are averages - the opposite of latency measurements.
GC or not GC Posted Feb 15, 2013 0:04 UTC (Fri) by marcH (subscriber, #57642) [Link]
> Android has something like it, it can estimate the power use by application. You can use various apps to view these stats.
In fact what's needed is something very similar to this. An interface just as simple that displays the list of what the CPU/memory/network/applications were too busy doing in the last minute or so when it failed to react quickly.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 22:53 UTC (Wed) by nybble41 (subscriber, #55106) [Link]
There are two general ways to deal with GC pauses in programs requiring a near-realtime response. You can use a realtime GC algorithm which amortizes the GC work across all allocations and guarantees a bounded response time, or you can guarantee that there is sufficient free memory available to run the critical path without invoking the GC. The latter is most suitable when the program can expect a certain amount of idle time, e.g. between frames. It should be a simple matter of determining how much memory is needed to render a frame and then adding a call to the GC just before going idle to free at least that much space for the next frame.
Realtime GC algorithms are rare, because they're not usually required and they tend to have more overhead. While Java has System.gc(), it's apparently not very well defined (could be anything from a no-op to a stop-the-world full GC pass), and JavaScript has no standardized control over the GC at all, probably for security reasons. The end result is that while GC response time is manageable in principle, applications written in the most popular GC languages are not provided with the necessary tools for the job.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 22:29 UTC (Mon) by marcH (subscriber, #57642) [Link]
> No, I think they just found that garbage collection is just unacceptable: it introduces jitter which is not easily observable on a desktop with mouse but is a big problem for touchscreen.
A problem so big that it prevents Android from selling in any significant numbers. Oh, wait...
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 20:17 UTC (Wed) by efraim (subscriber, #65977) [Link]
It does not prevent Android from being sold in great numbers. It is however annoying as hell to have a freaking dial pad stall for several seconds on a 512 MiB RAM phone. I don't remember such basic functionality annoying me to no end on S40 phones with ~0.5MiB RAM.
Regardless, the greatest problem with GC IMHO is that they don't really collect memory. They collect objects, which reference resources. Those resources are typically much more scarce than memory - think DB connections, file locks. (ouch!) And an application which unpredictably does not free those resources will behave in a buggy way. Worse yet, most of the managed (either .NET or JavaScript) code I've seen is written with an attitude that GC will take care of resource disposal no matter what - and only the expected code execution path has a thought-through way of releasing those resources. If any exception shall occur, all bets are off. So the GC does not really help you. You still need to take care of all those resources - which means lots and lots of catching and rethrowing, not unlike C code which tries not to leak. So you either have an ugly code or exceptionally fragile code. (btw, have a look at the mess which is IDisposable in .NET framework - Microsoft developers had to decide whether to implement IDisposable when they designed each base class and interface in the standard library - based on an idea what those *inheriting* those classes might want to do - guess how many times they got that wrong; I do not blame them for it, seems like GC is simply the wrong idea if you want robust code which uses any external resources)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 20:52 UTC (Wed) by marcH (subscriber, #57642) [Link]
> It is however annoying as hell to have a freaking dial pad stall for several seconds on a 512 MiB RAM phone. I don't remember such basic functionality annoying me to no end on S40 phones with ~0.5MiB RAM.
Agreed but, once again, I never saw any definitive proof that GC was to blame for that. It could just be too many background apps/daemons starting simultaneously when you just wake up the phone to make a call - an entirely different problem.
By the way and for some fun try to google "slow ipad" or "slow iphone".
> So the GC does not really help you. You still need to take care of all those resources
A typical application has an order of magnitude less network connections and files than memory objects, so GC means a LOT less to worry about.
> which means lots and lots of catching and rethrowing, not unlike C code which tries not to leak.
Which language does better and how? Please give some pseudo code example.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 0:25 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> Worse yet, most of the managed (either .NET or JavaScript) code I've seen is written with an attitude that GC will take care of resource disposal no matter what - and only the expected code execution path has a thought-through way of releasing those resources.
This is not a problem with garbage collection but with developers who don't know which problems a garbage collector solves and which it doesn't.
> You still need to take care of all those resources - which means lots and lots of catching and rethrowing, not unlike C code which tries not to leak.
> (btw, have a look at the mess which is IDisposable in .NET framework - Microsoft developers had to decide whether to implement IDisposable when they designed each base class and interface in the standard library - based on an idea what those *inheriting* those classes might want to do - guess how many times they got that wrong; I do not blame them for it, seems like GC is simply the wrong idea if you want robust code which uses any external resources
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 6:46 UTC (Thu) by efraim (subscriber, #65977) [Link]
>>The right way to use IDisposable is through a using statement, not through the GC.
using statement is only useful under *very* limited circumstances. Far more
So according to what you say, modern GC languages have no way of handling shared resource problem (unlike, uh, C++, which has reference-counted RAII patterns at least)
Another problem is that .NET allows you to reference (not weak references, the real thing) IDisposable objects from non-IDisposable ones. So you may perfectly well be referencing a zombie object which has been disposed of, but not GC'ed.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 8:30 UTC (Thu) by alankila (subscriber, #47141) [Link]
Combine using with a refcount then, so you can reference the same thing in multiple using-statements. Or pool the object. It's not like this is intractable problem.
Altogether these claims sound strange to me. I've never run into it myself. I pass the objects from the scope that has the 'using' downwards to all parties that need it. This makes sense for me because it's usually database connection and I need to commit or rollbak transaction by the end of it.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 17:11 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> using statement is only useful under *very* limited circumstances.
> [...] > So according to what you say, modern GC languages have no way of handling shared resource problem (unlike, uh, C++, which has reference-counted RAII patterns at least)
The using statement is useful under the *exact* same circumstances where a C++ destructor is useful: it's just a way to call a function as soon as a certain local variable goes out of scope.
> her problem is that .NET allows you to reference (not weak references, the real thing) IDisposable objects from non-IDisposable ones. So you may perfectly well be referencing a zombie object which has been disposed of, but not GC'ed.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 17:42 UTC (Thu) by efraim (subscriber, #65977) [Link]
>> The using statement is useful under the *exact* same circumstances where a C++ destructor is useful: it's just a way to call a function as soon as a certain local variable goes out of scope.
As I've already told you, using cannot be used in certain situations where reference counting can.
>> If you do the same mistake in C++, you'd have a dangling pointer, how is that any better?
You wouldn't, because you'd use a ref-counting pointer such as std::shared_ptr.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 20:24 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> As I've already told you, using cannot be used in certain situations where reference counting can.
That's like saying that C++ destructors cannot be used in certain situations where refcounting can: it doesn't make any sense. Refcounting works just as well in C# as it does in C++, you just have to implement the refcounting logic in your Dispose method, similar to how shared_ptr implements its refcounting logic in the destructor. And actually, alankila already pointed this out, so I don't even know why I bother repeating it...
> You wouldn't, because you'd use a ref-counting pointer such as std::shared_ptr.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 21:01 UTC (Thu) by efraim (subscriber, #65977) [Link]
>> Refcounting works just as well in C# as it does in C++, you just have to implement the refcounting logic in your Dispose method, similar to how shared_ptr implements its refcounting logic in the destructor. And actually, alankila already pointed this out, so I don't even know why I bother repeating it...
Yes alankina already pointed it out, and it is wrong. Refcounting simply does not work in C#. Because all the helper classes, collections e.t.c, do NOT implement IDispose. That's the point. You cannot implement refcounting when half the standard library is working against you.
>> You would, because if you end up holding a reference to an object with refcount 0, that means you forgot to increase the reference count at some point, and that is perfectly possible with a shared_ptr<T>. You could call .get() on the shared_ptr<T> and store the returned T* somewhere. Or, more subtly, you can write a function that takes a T& and then stores that reference somewhere else. Then you pass *t (where t is a shared_ptr<T>) to that method and you've blown it.
Both would be really stupid things to do and any non-newbie programmer in C++ knows better.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 23:49 UTC (Thu) by HelloWorld (guest, #56129) [Link] Yes alankina already pointed it out, and it is wrong. Refcounting simply does not work in C#. Because all the helper classes, collections e.t.c, do NOT implement IDispose. That's the point. You cannot implement refcounting when half the standard library is working against you.Well, it's not all that bad. You can write an extension method for IEnumerable that will return an object whose Dispose method disposes of the objects contained within the collection. Then you can write something like
using (myCollection.Disposer()) {
...
}
Anyway, C++ still has the advantage that an object will implicitly call its member objects' destructors after running its destructor, and that it'll call the destructors of the already-constructed member objects when an exception is thrown within a constructor. So yeah, point taken, C++ probably does somewhat better in that regard.
Both would be really stupid things to do and any non-newbie programmer in C++ knows better.I wish! People mess up simple things like that all the time.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 23:54 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Both would be really stupid things to do and any non-newbie programmer in C++ knows better.
How many non-newbie C++ programmers have you met for real? Three? Five?
Should be: Goodnight, Perl 6. Posted Feb 15, 2013 8:26 UTC (Fri) by efraim (subscriber, #65977) [Link]
Assuming you are asking this in good faith (as opposed to, say, condescension) actually around twenty. Of course in this day and age you don't really have to meet a programmer "for real" to know they exist - just look at the number of people giving competent C++ answers on stackoverflow.com.
Should be: Goodnight, Perl 6. Posted Feb 15, 2013 20:26 UTC (Fri) by marcH (subscriber, #57642) [Link]
It's hard not to make any harmful mistake in C++, much harder than in other languages. As a consequence good C++ programmers are few and a very large number of C++ programmers in service can be considered as newbies. You cannot dismiss mistakes as being "too stupid to do" in C++ as easily as in other languages.
Should be: Goodnight, Perl 6. Posted Feb 15, 2013 22:33 UTC (Fri) by efraim (subscriber, #65977) [Link]
While you are right that there are many gotchas in C++ which can trip newbies, pointers are pretty easy to get right by simple ownership rules:
1. If you get a shared_ptr or unique_ptr you can store it for use later.
2. Otherwise (if you get a raw pointer or a reference) you have to assume that you do not own the resource and can only use it in the method's scope.
3. By calling .get() you are saying you are going to take care of ensuring the object's existence during your use of the pointer - i.e. you get no help all bets are off.
Moreover other languages have much more subtle traps in basic parts of language than C++ does - look at JavaScript and PHPs type-casting rules - while wildly different, both are very counter-intuitive and prone to creating security issues.
Should be: Goodnight, Perl 6. Posted Feb 16, 2013 1:01 UTC (Sat) by marcH (subscriber, #57642) [Link]
I know nothing about JavaScript besides this funny description I've read some day: a functional language disguised behind curly brackets and some object-orientation not to scare away people afraid of maths :-)
http://javascript.crockford.com/javascript.html
You are probably right about JavaScript dangers. On the other hand, I know enough about PHP not to even consider it as programming language. Otherwise the differences between all other languages become negligible and they all become equally excellent
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad...
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 0:16 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> garbage collection is just unacceptable: it introduces jitter
No it doesn't, not if you do it right. Incremental garbage collectors have been around for years, and measurements have generally shown that performance doesn't suffer significantly as long as enough memory is available, even with conservative garbage collectors like Boehm GC. Otoh, what people continuously push to the back of their mind is that calling free(3) isn't free. It does take time to free a big data structure.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 1:33 UTC (Tue) by wahern (subscriber, #37304) [Link]
Incremental garbage collectors don't remove jitter, they just help to mitigate it. Like generational collecting, it's an optimization. But there will always be jitter associated with GC. Whether you can perceive it or not is another matter.
What sells me on GC is the ability to handle things like lexical closures without trouble. Closures really cry out for GC, otherwise it's much too easy create cycles (as happens in Perl 5, often).
And the ability to manage external resources is largely a red-herring. A properly implemented C or C++ class will use reference counting internally, so that script references merely holds a lease, and don't control the lifetime, per se.
"Improperly" implemented classes however... well, if you're just tossing garbage C code into your application, then I have no sympathy for you. And adding a simple ref count should be easy enough.
As for GC memory leaks, AFAIU these are usually associated with caches, where you can create undetectable cycles between the key and the value in the cache. These can be solved by "ephemeron tables", although they're not computationally cheap. But then again, nothing is preventing you from manually breaking the cycle.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 20:48 UTC (Mon) by zlynx (subscriber, #2285) [Link]
Please don't use Android as a shining example of good garbage collection. I curse Android RAM management every time an app goes out to lunch and stops responding to finger input for a couple of seconds.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 22:30 UTC (Mon) by marcH (subscriber, #57642) [Link]
I think you are confusing Garbage Collection and swapping.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 0:15 UTC (Tue) by zlynx (subscriber, #2285) [Link]
No, I've seen the performance logs. It is GC. When the machine hits the limits it goes off and does serious GC, ie, not incremental but full.
Sometimes it also has to run out and kill off background tasks which seems to be time consuming. Does it wait for them to exit or something? KILL -9!
Many Android apps hits this problem when scrolling because they're dropping lots of objects from use and creating new ones. Then to fix that leads them into crazy object reuse schemes which start to make C++ look quite nice.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 1:25 UTC (Tue) by alankila (subscriber, #47141) [Link]
There is no swapping on android. It runs something like OOM killer that hunts for a process to murder based on some rules.
I do not see those long pauses reported here myself. My experience of a GC cycle is that it takes about 2 ms to do, though no doubt there are longer cycles occasionally.
IMHO larger problems are with the physical limits of the touchscreens and poor UI decisions. For instance, it takes some sampling to determine at suitable precision where the finger is, and that requires some low-pass filtering, making every UI movement already lag by default. Some UIs try to use doubleclick and singleclick for completely different actions, requiring singleclick processing to be delayed until it is known that doubleclick was not intended.
My personal #1 annoyance with my phone, a galaxy s2, is to do with the fact that the hardware takes around 1 second to wake up from sleep after I push the power button. That is a long time to wait. I once tried to logcat to see why, but it seems that waking up the hardware simply takes that long, whatever the reason.
And honestly, my phone has 1 GB of memory. It's hard to see it getting used up any time soon, because I'm just not the sort of power user these things are made for. Current shipping phones appear to have 2 GB. If you compare that to around 24 MB heap limit for most android applications, it's evident that something like 50 should be able to exist concurrently without system being even pressed for memory.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 21:01 UTC (Wed) by marcH (subscriber, #57642) [Link]
> There is no swapping on android. It runs something like OOM killer that hunts for a process to murder based on some rules.
I have a (too) cheap, Android 2.2 tablet with too little memory and it is slow because they enabled swap on it. I know for sure because they were honest about it and told about it in an official changelog. I also know because I installed another, non official build on it, disabled swap and it became much faster.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 12:35 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
An interpreted dynamic language without GC is a dinosaur. Refcounting often misses even the obvious cycles in simple closures - and that's something that shouldn't happen.
iOS is losing GC because it never was feasible in the first place. Objective-C requires a conservative GC that fully scans the app's RAM for all possible pointer-like data - and that is not really a good idea on a small device. Precise GCs in Android, WebOS and WinPhone do not suffer from this.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 12:28 UTC (Mon) by dskoll (subscriber, #1630) [Link] What practical difference does lack of subroutine signatures make? Or the fact that Perl can't break reference cycles? Who really cares? Perl 5 followed Larry Wall's philosophy of making something that works, even if it isn't "beautiful" from an abstract computer science point of view. Perl 6 is going completely in the opposite direction: All sorts of amazingly cool features that thrill language designers but result in an unusable and horribly complex impractical lumbering beast.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 23:29 UTC (Mon) by raiph (guest, #89283) [Link]
> What practical difference does lack of subroutine signatures make?
An example in Perl 6 is that signatures are integral to the FFI solution and the upshot is that using C libraries from Perl 6 is truly trivial. http://justrakudoit.wordpress.com/2011/01/28/zavolaj/
> Perl 5 followed Larry Wall's philosophy of making something that works, even if it isn't "beautiful" from an abstract computer science point of view. Perl 6 is going completely in the opposite direction: All sorts of amazingly cool features that thrill language designers but result in an unusable and horribly complex impractical lumbering beast.
I think you're viewing Perl 6 through the lens of dissatisfaction of trying it years ago.
Partly because the effort is pretty much directed by Larry Wall, the Perl 6 result is increasingly delivering all the practical goodness of Perl 5, plus an enormous bunch of extra *practical* goodies, combined with doing it right from a computer science point of view.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 14:14 UTC (Mon) by dskoll (subscriber, #1630) [Link] So... I built rakudo star 2013-01 and wow... they are making progress! My original measurements showed perl6 taking 553 times as long as perl 5 to start and consuming 27 times as much memory. Now perl 5 is bigger and slower than back then, and rakudo is smaller and faster, so... perl6 takes only 50 times as long to start as perl 5 and uses a mere 8 times as much memory. I'm not trying to be sarcastic here... I really am impressed they've been able to improve it this much.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 17:50 UTC (Mon) by bronson (subscriber, #4806) [Link]
So, if you extrapolate based on these two points, how long will it take for it to reach parity? :)
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:10 UTC (Mon) by dskoll (subscriber, #1630) [Link] Ah, well! :) Do you extrapolate linearly? Exponentially? That's the $64k question.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:15 UTC (Mon) by raiph (guest, #89283) [Link]
That's on Parrot, which is terribly expensive in some ways in terms of both speed and memory.
You might be interested in my Feb 2nd post to perlmonks about the outlook for the speed of Perl 6 in 2013: http://www.perlmonks.org/?node_id=1016758
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 20:45 UTC (Mon) by dskoll (subscriber, #1630) [Link] That's an interesting post. However, if the answer to "make this go faster" is to target a different VM, then I'm not filled with confidence. That's a huge change to make in a software project that's supposed to be at the optimization phase of its development.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 22:11 UTC (Mon) by raiph (guest, #89283) [Link]
It just so happens that one of the pieces that's happening anyway -- a port to the JVM so they can complete threads, NFG/Unicode, and native types -- looks set to have a big impact on speed and memory. So it definitely warrants at least a mention.
But no, the answer to making it go faster and be less wasteful of memory is not to port to a different VM. It's mostly about realizing the speed and memory efficiency already inherent in the design. This is something the team is only just now starting to do because they've followed the correct approach which is to make things work, make them work correctly, and only then focus on speeding things up.
There are several examples in the perlmonks thread I linked. Implementing sink/void context had no impact on semantics but sped up some operations by enormous factors (think thousands of times faster) and saved vast amounts of memory (think reducing usage from N gigabytes to N megabytes). This is the sort of thing they're now doing at an accelerating pace.
Fwiw the JVM port is not a huge change at all. Or rather it is, but they've already done the huge changes over the last few years. If you read jnthn's excellent blog post (http://6guts.wordpress.com/2013/02/02/a-look-at-the-prepa...) you'll understand this point.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 2:40 UTC (Tue) by alankila (subscriber, #47141) [Link]
Java has a lot of "industrial-strength" libraries. It would be very interesting to be able to use them from a language such as Perl6 natively. All of Java's stuff would be a vast addition to CPAN.
One of the reasons that really irritated me about programming in Perl 5 some 3-4 years ago was that it was clearly falling behind in terms of supporting some xml-based technologies, or pdf generation, or microsoft excel interoperability, and all such stuff which the primary competition in that space (java) had no trouble with, and which were features that the customers were requesting. I have no reason to think the situation has got any better, because my impression is that Perl's popularity has been falling further since.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 3:35 UTC (Mon) by bronson (subscriber, #4806) [Link]
> They've just got to turn the last few red and yellow boxes green
Remember when Perl6 felt close enough that they published a book about it? That was eight years ago.
No, it doesn't matter how many red or green lights you see, Perl6 is still a very long way from general use. It seems like it's been on a constant-time-to-completion schedule for almost its entire life.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 3:46 UTC (Mon) by bronson (subscriber, #4806) [Link]
I'm wrong, looks like we can celebrate the ten year birthday of Perl6 Essentials on June 27th of this year. A full decade.
Quick bump to a fine LWN article of antiquity: https://lwn.net/Articles/200075/
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 4:29 UTC (Mon) by rqosa (subscriber, #24136) [Link] When that book was published there was no implementation, at all. Now there's an approximately 88% feature-complete implementation. That's a big difference.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 6:14 UTC (Mon) by bronson (subscriber, #4806) [Link]
It went from unusable to useless. Not such a big difference from where I sit.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 6:38 UTC (Mon) by rqosa (subscriber, #24136) [Link] If you can't explain why you think Rakudo is "useless", then posting comments like that is just needless hostility towards its developers.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 8:46 UTC (Mon) by alankila (subscriber, #47141) [Link]
As a 10 year old perl 5 programmer, the way I see it is that Perl 6 is the last dinosaur men buit. (I know, so very optimistic of me...) It is so incredibly complicated that I suspect that only very few would be capable of learning to use it in full, and discover the most suitable abstraction to use in each specific type of problem. Everybody else will make do with some random but unique subset of the language, so everybody's programs will look different. That is not a good thing, imho.
I'd argue it is unwelcome even if there was a 100% functioning implementation that did not show poor performance characteristics. As in, nobody should ever use it. Why? Because Perl6 design is so complicated that there is probably not much room for new features or taking the language in new directions. It's really the same problem as with Perl5: a lot of bloat and ill thought out features that can never be changed because backwards compatibility.
I think Perl6's idea was to make a core so flexible that it has no limitations, and that makes it almost textbook case of Second System Syndrome. I also suspect it's the primary reason why it has taken so long: designing fully generic schemes for doing everything are a lot more work than just designing something according to reasonable guess of what your average programmer might want or need. Usually these designs prove out to be less flexible than hoped, and that effort was all a colossal waste.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:30 UTC (Mon) by raiph (guest, #89283) [Link]
> It is so incredibly complicated that I suspect that only very few would be capable of learning to use it in full
The same could be said of Perl 5. A big difference is that it's less true of Perl 6.
Perl 6 is a simpler language than Perl 5 in most ways. But, like Perl 5, there is scope for a full range of fluencies from baby to advanced. If you don't like that, you don't like Perl.
> Perl6 design is so complicated that there is probably not much room for new features or taking the language in new directions.
Again, this is arguably true of Perl 5. It's definitely not of Perl 6.
> I think Perl6's idea was to make a core so flexible that it has no limitations
You didn't get that idea from the actual project.
> I also suspect it's the primary reason why it has taken so long.
The reasons for it taking so long are legion. It was and is ambitious, no doubt about it.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 2:03 UTC (Tue) by alankila (subscriber, #47141) [Link]
"Perl 6 is a simpler language than Perl 5 in most ways."
Well, maybe for someone who is in the zen. Perl5 certainly wasn't pretty, though I could live with it apart from its scalars using so much memory and the language generally being so slow.
I'll assume what you say is true, though on the surface it seems to have a lot more syntax to deal with that is new to Perl6.
"You didn't get that idea from the actual project."
It is hard to remember stuff clearly from a decade ago, but I got the impression from the apocalypses where I thought that the common theme was "this is something that was difficult in perl5, let's remove this limitation [through some very complicated scheme for no clear reason]", and I got sick of it all when I learnt about the runtime reconfigurable syntax parsing. In my mind, that is a sign of language design going off the deep end. I get it that semantics sometimes have to be redefined to support features like operator overloading (whatever the merits and faults of this technique), but syntax too? I really don't look forwards to seeing code that makes use of that feature.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 3:02 UTC (Tue) by cmccabe (guest, #60281) [Link]
> Perl5 certainly wasn't pretty, though I could live with it apart
> from its scalars using so much memory and the language generally > being so slow.
Let's be fair. Perl5 is still faster than a lot of the languages in common use: Python, Ruby, and Bash. (JRuby might be another story, but it's not widely used.)
My favorite new language is Golang. I've been using it in places where I formerly used Python (and before that... Perl) and it just... works so much better. It's really refreshing how quickly it starts up and runs, and the fact that it's compiled and type-checked. You don't have to live in terror of the next version silently breaking your code. And of course, there's a better concurrency story than just "run multiple VMs in parallel."
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 9:21 UTC (Tue) by alankila (subscriber, #47141) [Link]
Of course Perl is not the slowest language there is, but its speed and memory consumption nevertheless proved prohibitive for my needs. In general the problem had most to do with using a scripting language at all. Most of all I needed the struct packing efficiency and execution speed of a precompiled language, and the ability to spend just 4 bytes for an int. Hash tables (extremely fat objects) and 40 byte scalars (even if it was a single integer value) as perl typically does just wouldn't scale.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 5:16 UTC (Tue) by raiph (guest, #89283) [Link]
> "Perl 6 is a simpler language than Perl 5 in most ways."
> Well, maybe for someone who is in the zen.
Consider the comparison of baby Perl 5 and baby Perl 6 (the card deck code of pages/slides 16 thru 29) in this presentation by Carl Mäsak: http://masak.org/carl/fosdem-2013-flying-car/talk.pdf
> I got sick of it all when I learnt about the runtime reconfigurable syntax parsing.
Oh dear. That stuff (all the way through slangs) is pretty core to Perl 6 and stars in many of its triumphs as a DSL for producing DSLs. If you don't like that you dislike one of its unique strengths. Not to worry, there are many more. :)
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 9:32 UTC (Tue) by alankila (subscriber, #47141) [Link]
To me this perl5 vs 6 example you cite reads like someone came up with the syntax specifically to do those tasks. So there's a method that just happens to pick any number of array items? A lot of us would call those features bloat.
Cross operator such as "X~" which appears to mean something like 'combine two lists in every possible way with 2 implied for loop, then stringify every item, then return the list' sure is powerful, but I'm a boring stick-in-the-mud and do not really see that as much of an improvement over the two for loops. More to the point, assuming we really do want to get rid of explicit for loops, then why not compose the functionality out of functions from some Perl module?
Think of: cross(@a, @b) yielding some Pair objects of the two lists, rather than @a X @b. And rather than some weird operator like X~, perhaps there should be a stringify(cross(@a, @b)). I guess it's just not the Perl way, though, but I know which language I'd rather write.
Ditto for expressions like (1, 2, 3) >>+<< (3, 2, 1) yielding (4, 4, 4). This seems like rank madness to me. Python's NumPy would do the same with something like array((1,2,3)) + array((3,2,1)) yielding array(4, 4, 4). Why not use the existing library facilities and overloading capability to build this stuff?
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 11:14 UTC (Tue) by niner (subscriber, #26151) [Link]
The nice thing about hyper operatiors is that they allow automatic parallelization and they work with all operators even ones you define yourself. The compiler simply has much better optimization possibilities this way. That the code becomes very compact is a nice side effect.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 9:44 UTC (Wed) by k8to (subscriber, #15413) [Link]
But a generic method of applying functions to data can achieve the same thing while being syntactically regular and expressively clearer.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 17:27 UTC (Wed) by raiph (guest, #89283) [Link]
> But a generic method of applying functions to data can achieve the same thing
Can it?
First, Perl 6 operators compile down to function application. Folk are free to write directly in the function application style. So at some level these appear to be equivalents.
But, aiui, there are at least three big impacts:
* you need syntax to control order of evaluation;
> while being syntactically regular and expressively clearer.
Most languages allow a + b as well as add(a,b) and I'd say most folk find the a + b option expressively clearer in most situations.
===================
To drill down in to the details of evaluation, consider the Perl 6 expression "@ X~ @b" which for our purposes I'll say means to create the array result of a crosswise combination of the elements of the array variables @a and @b, concatenating each pair.
Now consider how to express that in a function application style, in particular how the compiler, syntax and programmer deal with order of evaluation, parallelization, optimization, and laziness.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 17:59 UTC (Wed) by andrel (subscriber, #5166) [Link]
Have there been psychology experiments proving that understanding the different syntax uses a different part of the brain, or is that still informed conjecture?
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 19:21 UTC (Wed) by raiph (guest, #89283) [Link]
> Have there been psychology experiments proving that understanding the different syntax uses a different part of the brain, or is that still informed conjecture?
Aiui there have been lots of brain scan experiments demonstrating that understanding spoken natural language uses different synaptic circuits to process different syntax elements. I hope to get some time to find more useful answers to your question this weekend and post back in this thread.
Use of our natural language processing neural mechanisms for reading, writing, understanding computer languages Posted Mar 7, 2013 21:27 UTC (Thu) by raiph (guest, #89283) [Link]
I've just hunted around starting from a google for "understanding syntax" "brain scans". I've not yet found stuff specifically discussing how natural language syntax processing neural mechanisms impact our processing of computer language, but here's one that A) confirms use of some such mechanism in processing of music notation and B) suggests that such mechanisms would/can also be used used in reading, writing, understanding computer languages.
"These combined results suggest that [an area of the brain], known to be crucial for syntax processing in [natural] language, plays also a functional role in the processing of musical syntax. Hence, the present findings are consistent with the notion that Broca's area supports the processing of syntax in a rather domain-general way." (from http://www.ncbi.nlm.nih.gov/pubmed/20570253)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 19:01 UTC (Wed) by k8to (subscriber, #15413) [Link]
Claims 1 and 2 are false on their face, because (as you point out yourself) the execution is equivalent.
You don't typically need to control order of application of the function to the items, which is why it's fast. You do of course need to control order of function application, but with function syntax it's all the more clear.
Optimization meanwhile is the same, except for the most degenerate of examples such as "we hand-crafted the machine code of this operator for this one case".
But a typical implementation of combining two arrays in all permutations would be something like
permute(NIL, a, b)
so the compiler can see that there's no action required but to combine them, and it's a trivial matter to parallelize the combination across N cores or computers. Indeed there were functional compilers capable of fully optimizing this problem in the early 90s.
As for item 3 I will have to say that I doubt you are right, but I cannot claim either way since there is of course no evidence presented, and probably no research.
I do find infix to be pleasant for colloquial, familiar expressions. I find it to be personally extremely counterproductive for comprehension with unusual constructions.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 20:26 UTC (Wed) by raiph (guest, #89283) [Link]
> Claims 1 and 2 are false on their face, because (as you point out yourself) the execution is equivalent.
Heh. It appears you didn't interpret the word "appear" as I intended...
> You do of course need to control order of function application, but with function syntax it's all the more clear.
So, is it concat(cross(@a,@b)) or cross(concat(@a,@b)), or something else, and what is the result?
> Optimization meanwhile is the same, except for the most degenerate of examples such as "we hand-crafted the machine code of this operator for this one case".
Are you suggesting it's degenerate to specifically atomically optimize a crosswise concatenate?
> As for [understanding a+b uses a different part of our brain than add(a,b)] I will have to say that I doubt you are right, but I cannot claim either way since there is of course no evidence presented, and probably no research.
I'd be surprised if there was no research but my own investigations have been of brain science as it relates to natural language, not computer languages. The "aiui" was partly because I've taken Larry's word (he was a linguist) that similar principles apply. I hope to dig in to this this weekend and post back here, with a focus on comparing add(a,b) and a + b.
> I do find infix to be pleasant for colloquial, familiar expressions.
I'm going to assume here you mean in computer languages. As in, you find a + b in computer code pleasant.
For me @a X @b ("array a crossed with array b") felt natural and pleasant as did @a X~ @b ("array a cross concatenated with array b").
> I find it to be personally extremely counterproductive for comprehension with unusual constructions.
So a+b works well instead of add(a,b) but a**b fails compared to power(a,b) (or something like that)?
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 12:21 UTC (Thu) by fatrat (subscriber, #1518) [Link]
How does this differ from the Haskell (or Python version)
ghci> [ x+y | x <- [1,2,3], y <- [4,5,6] ]
which seems cleaner.
In Haskell, that can also deal with lazy lists etc
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 17:41 UTC (Thu) by hummassa (subscriber, #307) [Link] Cleaner than
> 1, 2, 3 X+ 4, 5, 6 5 6 7 6 7 8 7 8 9? ok then.
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 18:22 UTC (Thu) by raiph (guest, #89283) [Link]
> How does this differ from the Haskell (or Python version)
> ghci> [ x+y | x <- [1,2,3], y <- [4,5,6] ] > [5,6,7,6,7,8,7,8,9]
That's the same.
One issue is whether you prefer, from an expressivity point of view, x+y or something like add(x,y). I usually prefer x+y. It looks like, for the "familar" function/operator add/+, we all agree: x+y is generally preferable.
So what about "unfamiliar" functions/operators? I'm going to guess at the haskell syntax for a zipped string concat:
zipwith (++) ["foo", "bar"] ["sing", "song"].
Perl 6 uses ~ instead of ++ and supports infix notation so one can write:
["foo", "bar"] Z~ ["sing", "song"]
It seems alankila and k8to (and you?) consider the Z~ infix notation for zipped string concat to be less clear.
Let's assume for a moment that this is just a syntax sugar issue. (Regardless of whether the sugar seems sweet or not to any given writer/reader.) Given that Perl 6 is aiming at (among other things) being a metaDSL (a language for easily expressing and combining DSLs) then sugar matters and it's potentially important to make it trivial to use a wide range of expressivity, including infix notation, for user defined functions/operators (as well as builtins of course).
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 19:34 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
Haskell doesn't let you mix letters and symbols in operator names, but apart from that it's simple to define an operator similar to Z~ which works on any nested list type, including lists of strings ([[Char]]):
infixr 6 ++~
["foo", "bar"] ++~ ["sing", "song"]
Should be: Goodnight, Perl 6. Posted Feb 14, 2013 21:40 UTC (Thu) by fatrat (subscriber, #1518) [Link]
I think my issues is that the [ ... ] list/monad comprehension approach is very general, and, as nybble41 points out, can be specialised as needed.
The Perl6 approach seems to lead to a proliferation of operators, and consequent maintenance issues.
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 13:29 UTC (Tue) by raiph (guest, #89283) [Link]
> To me this perl5 vs 6 example you cite reads like someone came up with the syntax specifically to do those tasks.
I routinely see both example and $dayjob code that reads as if the syntax and builtins were made just to make that bit of code nicer to write and read. But I've watched the relevant discussions so I can see this is the natural outcome of a good language design process rather than Larry Wall focusing on parlor tricks.
> So there's a method that just happens to pick any number of array items?
Yes. It picks randomly and does not repeat an element. Handy for selecting threads from a pool, for example.
> A lot of us would call those features bloat.
Imo it is suitably huffmanized and pushed as far out of the technical core as is reasonable. I see it as excellent design.
> Cross operator such as "X~" which appears to mean something like 'combine two lists in every possible way with 2 implied for loop, then stringify every item, then return the list' sure is powerful, but I'm a boring stick-in-the-mud and do not really see that as much of an improvement over the two for loops.
More or less. If an infix X is followed by another operator it applies the operator pairwise for every operand combination and returns the list of results.
But you can still write two for loops if that's what you prefer...
> More to the point, assuming we really do want to get rid of explicit for loops, then why not compose the functionality out of functions from some Perl module?
That's more or less how it already works. String concatenation (~) and many other operators (+, -, etc.) ship with the stock Perl 6 but you (or others) can add more (which will then automatically combine with the range of metaops).
> Think of: cross(@a, @b) yielding some Pair objects of the two lists, rather than @a X @b. And rather than some weird operator like X~, perhaps there should be a stringify(cross(@a, @b)). I guess it's just not the Perl way, though, but I know which language I'd rather write.
Folk can write code long hand if they want. You can write add(3, 4) instead of 3 + 4 if you want.
But key things get lost in the translation you suggest. The metaops like X parallelize. And what if @a and/or @b are lazy or infinite lists? And what about an optimization specific to crosswise string concatenation?
> Ditto for expressions like (1, 2, 3) >>+<< (3, 2, 1) yielding (4, 4, 4). This seems like rank madness to me. Python's NumPy would do the same with something like array((1,2,3)) + array((3,2,1)) yielding array(4, 4, 4). Why not use the existing library facilities and overloading capability to build this stuff?
How do you parameterize the operation of the + op? For example, how would you control the +'s handling of unequally shaped arrays? Hang on, let me go check this. ... Ah. With NumPy, "the size of the trailing axes for both arrays in an operation must either be the same size or one of them must be one" or an exception is raised. The Perl 6 syntax allows more refined control of what NumPy calls broadcasting.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 17:45 UTC (Mon) by bronson (subscriber, #4806) [Link]
Zero hostility toward developers at all. All new languages are useless when they first start out (for varying definitions of "first start out").
As for why, I tried switching some of my easier Perl5 scripts to Perl6 a few years ago, and they got a little shorter and a lot harder to read. I loved Perl5 -- it's hard not to like a project that puts you in the authors file for a few patches -- but Perl6 appears to be going in exactly the opposite direction than I would choose. That plus the perpetual vapor makes it awfully hard for me to find a use for it.
I'll close with the hopeful sentence at the end of my comment from 4 years ago: https://lwn.net/Articles/330101/ Though, I've tried Perl6 since then, and I'm less excited about it now.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:38 UTC (Mon) by raiph (guest, #89283) [Link]
> I'll close with the hopeful sentence at the end of my comment from 4 years ago: https://lwn.net/Articles/330101/ Though, I've tried Perl6 since then, and I'm less excited about it now.
When did you last try it and is there some reason other than it taking so long that is why you are less excited?
It's important to accept the real pace of development rather than what might be hoped. As I said, also 4 years ago, "as hard to stomach as it may be, the story remains, even though they've taken a decade to get this far, they may well take ... five [years] to get to Perl 6.0.0 and a generally robust status". I continue to follow Perl 6 and I think that estimate was a good one.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 11:31 UTC (Mon) by NAR (subscriber, #1313) [Link]
It is said that for any project the last 10% takes 90% of the time. Based on this metric Perl6 will be ready in the next century...
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 5:21 UTC (Tue) by raiph (guest, #89283) [Link]
Or, as Carl Mäsak puts it, the Perl 6 project is currently on the third 80%.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 5:00 UTC (Mon) by theophrastus (guest, #80847) [Link]
yeah i bought that book too (man, what a sucker!)
i think it's time that someone who has managed projects like this to write a useful autopsy/analysis. was it the case of trying to take too big a step away from the time-honored version? too many high-level add-on features? was perl(5) already too syntax bound to back out? was the polyglot backend (which == 'Parrot', i think...) the downfall? too many cooks not enough benevolent dictator? what killed it???
i loved perl. (it got me through the data analysis on my thesis) i'm sorry to see it sink away. but to deny that it has isn't going to help at this point.
Should be: Goodnight, Perl 6. Posted Feb 11, 2013 19:47 UTC (Mon) by raiph (guest, #89283) [Link]
I realize that denying Perl is dying is useless at this point.
So instead I'll note that Perl is very much alive and kicking, with Perl 6 set to roll out in triumph over the next few years, and leave it to history to show that those who base their opinions on lots of data, rather than theory, tend to be much better at predictions. :P
Should be: Goodnight, Perl 6. Posted Feb 12, 2013 18:51 UTC (Tue) by dskoll (subscriber, #1630) [Link] I realize that denying Perl is dying is useless at this point. Perl is not dying. Perl 6 is likely to be stillborn and even the Perl 6 developers take pains to say that Perl 6 is a different language from Perl (which everyone nowadays understands to mean Perl 5.)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 1:23 UTC (Wed) by raiph (guest, #89283) [Link]
> Perl is not dying.
Right. If you notice the very next thing I said was "Perl is alive and kicking". I made the mistake of being sarcastic and, worse, forgot an appropriate emoticon.
> Perl 6 is likely to be stillborn and even the Perl 6 developers take pains to say that Perl 6 is a different language from Perl (which everyone nowadays understands to mean Perl 5.)
I've never heard a Perl 6 developer say that Perl 6 is a different language from Perl, just from Perl 5. In particular, Larry Wall has made it clear he reserves the right to the name "Perl".
Being stillborn is no longer one of the possible outcomes. It's most complete; it's in great shape technically; sixers are in great spirits; productivity reflects the good vibe; Larry Wall is writing his first Perl 6 book and is aiming to publish it about a year from now; there's still $100K in grant money set aside specifically for marketing and further funding of Perl 6 when it's ready for prime time; and so on. It might not be the future of Perl 5, but it is pretty much unstoppable at this point.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 12:43 UTC (Wed) by dskoll (subscriber, #1630) [Link] I've never heard a Perl 6 developer say that Perl 6 is a different language from Perl It seems this point is still debated.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 17:36 UTC (Wed) by raiph (guest, #89283) [Link]
The section you've linked notes that "some people" feel Perl 6 isn't Perl. I've heard some of these folk. None have been Perl 6 devs.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 18:14 UTC (Wed) by dskoll (subscriber, #1630) [Link] I won't post a long quote from here, but in essence it says: The "commonly used Perl language" is also known as Perl 5. "Perl 6 is different from Perl 5" Which as a programmer, I read as Perl == Perl5 && Perl6 != Perl5 which implies Perl6 != Perl. But maybe I'm being a bit pedantic. :)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 19:10 UTC (Wed) by raiph (guest, #89283) [Link]
I have read the entire "What about Perl 6?" page and agree with all of it.
> The "commonly used Perl language" is also known as Perl 5.
You missed out "commonly used". If you will it's CU Perl == Perl5 && Perl6 != Perl5 which implies Perl6 != CU Perl, which is true enough.
Perl6 is Perl, but it's not "the commonly used Perl".
> But maybe I'm being a bit pedantic. :)
Perhaps not pedantic enough. :)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 19:30 UTC (Wed) by dskoll (subscriber, #1630) [Link] :) It depends on whether you interpret "the commonly-used Perl language" as "The Perl language, which is commonly used, ..." or "The commonly-used Perl language (as opposed to some not-commonly-used language also known as Perl)" I think we can agree we are splitting hairs here, just as Perl 6 is splitting heirs wrt the Perl branding.
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 23:50 UTC (Wed) by raiph (guest, #89283) [Link]
"splitting heirs" :)
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 12:44 UTC (Wed) by dskoll (subscriber, #1630) [Link] Being stillborn is no longer one of the possible outcomes. How so? Do you consider Chandler not to be stillborn even though it was "completed"?
Should be: Goodnight, Perl 6. Posted Feb 13, 2013 18:55 UTC (Wed) by raiph (guest, #89283) [Link]
Who wanted Chandler written enough to freely give time and money to do it? Primarily Mitch Kapor. Who thought they wanted to try it bad enough that they would ignore its problems? Almost no one. What happened when Mitch gave up and the product wasn't sufficiently high quality? It died.
Who wants Perl 6 to be written enough to freely give time and money to do it? Boatloads of people, including many Perl 5 heavy hitters. These folk are generally quiet but have made it clear (behind the scenes) that they are waiting till the time is right to get involved. For example Nicholas Clark began contributing (by testing) a few months ago.
Who thinks they want to use Perl 6 bad enough to put up with its problems? It's clear that millions of hackers are or would be open to it, including many Perl 5 users. These folk are generally quiet and just want whatever works. If Perl 6 meets their needs, they'll try it out. And it's clearly nearly there. As Larry recently said, the only big problem left is speed, and the prognosis for addressing that this year is excellent.
|
|||||||||||||