Slashdot Mirror
Damian Conway On Perl 6 and the Philosophy of Programming
M-Saunders writes: Perl 6 has been in development since 2000. So why, 14 years later, hasn't it been released yet? Linux Voice caught up with Damian Conway, one of the architects of Perl 6, to find out what's happening. "Perl 6 has all of the same features [as Perl 5] but with the rough edges knocked off of them", he says. Conway also talks about the UK's Year of Code project, and how to get more people interested in programming.
Will it run on HURD?
"Was that we wrote Perl 6 in Perl 5. What the hell were we thinking? It's Perl all the way down."
Perl 6 now with Duke Nukem Forever.
Just one more thing.
See also: Python 3
When you knock the "rough edges" off of Perl, there's nothing left.
Growing beards.
Now, the problem with that is that it only works if you know the distinction in the syntax. So people coming into Perl get lost in this sea of ampersands and stars and all sorts of other symbols that we use in the language. And until you get past and it sort of goes into your hind brain and it just translates immediately, âah yes, thatâ(TM)s a scalar variableâ(TM), âah yes, thatâ(TM)s a type blah, blah, blahâ(TM), it doesnâ(TM)t make sense. It looks like line noise, and I fully agree.
and he's quite right, because the alternative is COBOL or Visual Basic where every syntax element is spelled out in big words.
There's a reason Windows developers like C# and not VB.NET (even though its the same thing) and that's the syntax. With C# you get to use a few symbols for various bits that are otherwise spelled out in VB. Perl just takes it to the limit - which means you have to understand what those symbols mean, and if you don't it looks like garbage. Which, I guess, C# looks like to my mum.
So in other words: learn your shit guys, you can't criticise perl for looking like crap unless you have taken the time to learn the language. And then you'll think it looks correct.
or even Python 2.6 and Python 2.7, they're different langauges.
that immaturity regarding backward compatibility is the big problem with open source, Linux is even worse with the fluid kernel ABI
" As of 2009[dated info], multiple Perl 6 implementations are under development, but none of them are considered "complete". "
So, there have been releases of Perl 6 but no finalization, but aren't most programming languages like that now?
e.g. C# has 6 versions and Java (12ish, according to Wiki). Languages forever evolving.
I know PERL is old and people except it to be more rigid like Fortran (even with new versions), but Fortran isn't being used for web apps, etc. that see constant technological innovation.
Sig. Sig. Sputnik
Since the last 14 years, it's been a lot easier to access porn on the Internet.
Get free satoshi (Bitcoin) and Dogecoins
or even Python 2.6 and Python 2.7, they're different langauges.
Hyperbole, much? I don't think that I've had to change any of my thousands and thousands of lines of code to accommodate the move from 2.6 to 2.7 (if I did, it was so minor that I can't remember doing it). Adding features does not make them different languages.
Larry went crazy, incorporating everything and the kitchen sink into Perl 6 and continues even now.
Imagine a swiss army knife with fold-out basketball, urinal, blender, spark plug gap tester, hog nose tag plier, etc.
what a farce, HURD may be still be floundering after a longer time but Perl 6 has gone in more directions
More like the baby they had 14 years ago is starting to grow one.
Yes, I know the one about hackers and beards.
Yes, we do have Java applications that we haven't upgraded. Mostly because they work so there's no reason to touch them.
Fortran is very good about backwards compatibility...can still compile and run Fortran-77 programs in the newest incarnations...
More like the baby they had all those years ago, is now old enough to vote and fuck.
..."Perl 6 has all of the same features [as Perl 5] but with the rough edges knocked off of them"...
Hmmmm... it takes 14 years to remove some rough edges from Perl 5? There must be some really rough edges, Probably why Perl seems to be in decline.
Come on! In fourteen years you can develop your OS from scratch. Bearing in mind that Perl is noting more than a scripting language, what the hell have they been doing?
If I had to make a totally uninformed guess, I'd say they probably read and learnt so much about languages, interpreters and compilers and stuff that they're now totally insecure as to how to proceed.
Its self-indulgent to design an upward incompatible programming language (and, no, Perl 6 is hardly alone in this as others have pointed out about Python3, etc.) without looking for your keys some distance from the lamp post.
Seastead this.
This title is incorrect. He barely talks about Perl 6 at all! Stick to the facts, Soulskill; you'll end up with less disappointed readers when you don't go for misleading clickbait.
Those days are dead and gone and the eulogy was delivered by Perl. --Rob Pike
I remember having to make exactly one change: to replace a class with its instance as __enter__ / __exit__ no longer work as class methods.
At OSCON 2006 I was sitting in one of the green rooms (the spaces set aside for speakers before presentations). My laptop was open and I was happily hacking away on a project. As I killed a bug and checked the code back in, I muttered under my breath, "Python, I love you. You make the hard stuff so easy."
I noticed a few seconds later the room had gone utterly silent. I looked up, and sitting at the table across from me was Damian Conway, tapping away on his own laptop doing his own thing. I blinked a couple of times and suddenly noticed the entire room was expecting a Perl-vs-Python argument to erupt.
Damian looked up from his work, noticed everyone was looking nervous. He looked over at me, I gave a "I don't know what's up with them, uh, help?" look and a shrug.
Damian then looked back at the crowd and grinned. "Listen, the only thing I love more than Perl is well-written software, even if it's written in Python." He looked back over to me. "Kill a bug, didja?" I nodded. He gave me a smile and a thumbs-up, then returned to his code. I returned to mine, and after a few seconds the room let out his breath.
I love Python. But the only thing I love more than Python is well-written software, even if it's written in Perl. :)
I've always thought that Perl 6 was the best thing that ever happened to Perl. While all the people who wanted to change things just to break stuff were off on Perl 6, building the non-deterministic, ever-changing, gargantuan tar pit to swallow Perl, everyone else ignored them and Perl 5 has been useful, stable, and almost change-free for a very long time, giving system administrators and others a stable platform to build tools on that won't be yanked out from under them in a year or two. This kind of stability is wonderful. I could just do my job, and not have to keep up with random, gratuitous change. Perl 5 is mature and useful, and doesn't need to change.
I'm seeing this now with Python 3 - it's the playground for the people who want to break and change Python, and everyone else is ignoring it.
In some ways Perl 5 is getting the best of both worlds. 10 year old modules still work just fine pretty much every time, but really good features in Perl 6 get backported by people who are tired of waiting.
I read the internet for the articles.
Fortran scales from my mobile class processor to top500 super computers.
Conway states Perl isn't the ideal fist language and I sort of agree. I OTOH have found Perl awkwardly useful for learning OO. As in Perl 5 you had to roll your own inheritance, you definitely understood it better as a consequence. I transitioned to Java SE and I actually prefer the strong typing as it makes messing up that little harder. Perl is still in my toolbox and I do advanced system programs with it. You know, stuff that both Bourne and Java are bad at.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Wrong. Linux doesn't need a static ABI, because the device drivers are all distributed as part of the kernel. Only makers of proprietary modules, and sycophants and nay-sayers complain about the Linux kernel not having a static API and ABI for kernel modules.
If you're talking about application code, the kernel is static on that. You can take binaries from 15 years ago and run them on a modern Linux kernel. The problem you'll usually run into is that the libraries that binary links to are not fully backwards-compatible, including glibc. That's not a kernel issue. In practice, it's rarely an issue at all; even glibc is very stable. The other libraries, OTOH, are a different matter (things like gtk, Qt, and myriad other small libraries). Even here, though, there's a pretty good effort to maintain some backwards compatibility. Most distros have qt3 compatibility packages, for instance, if you need to run applications built with Qt3. But if you've wrote an application 15 years ago that only uses kernel system calls, it should work just fine now.
The problems with Perl6 and Python are real, though, and I think do hurt their adoption a lot. It's a real PITA if you can't run an older program because the newer versions of its interpreter aren't backwards-compatible.
This. The "old" languages still work and work beautifully. People would be surprised at just how many shops still use Fortran. I prefer the older, more polished languages myself. Perl is by far my favorite language for general sysadmin duties. While I'm not an accomplished programmer, I use Perl for making my life easier. It lets me work smarter not harder. I struggle sometimes with understanding Perl's "noise", but at the same time, I love the language and what it lets me do. I would love to take formal Perl 6 language classes and actually use the language in a more meaningful way.
And, fortran crushes C in benchmarks, without a header file with crafty macros to obscure the code.
Code reviews and developer training/education will eliminate shitty perl code. Having said that, most software engineering teams are led by clueless fucks who neither want to spend even a thought to code reviews nor the professional development of their tesam members.
IT is in a much worse shape that most othert professions; quality and professional development is basically left to the individual developer, or in other words, to chance.
So again:In the hands of a skilled developer, Perl scripts look nicely, are readable, maintainable, properly commeted, nicely decomposed in functions/classes. All variables are nicely named according to problem domain.
That would be the case if Perl were done by a German craftsman instead of a guy with the cynical mindset of an internationalist bankster.
They created a language that won't run Perl code and called it Perl. Then they tried to add everything to it at once. Then they created a platform for running interpreted languages to run it on, then they created another one, and then another one, and then another one. So after 14 years Perl 6 is still just a grammar that has no standard working implementation and is of no practical use. And because it is useless no one will invest time in finishing it and no one will ever use it to build anything.
Perl 5 is useful, because of lots of stuff is written in it, mostly stuff that was cobbled together on the fly. And Perl is a terrible language to maintain because it allows you to everything a dozen different ways, using obscure rules of English grammar as an organising principle, operating on unnamed variables without any readable structure or comments. Which is why they invented Perl 6, except that it doesn't exist. And porting Perl 5 code to Perl 6 ,if it did exist, would be harder than maintaining Perl 5 code.
They should have just called it Godot.
“There's no lack of void.”
Conway states Perl isn't the ideal fist language and I sort of agree.
Java SE, Official Programming Language of WWE
I have a CS degree and consider myself being a Âsoftware engineerÂ, not a ÂprogrammerÂ. Based on reading lots of applied CS literature, my own work since 1995 and based on reflecting about this trade and other trades, my conclusion is: The world of software development and IT would be in a much better shape if people knew the old and mature tools instead of running after the latest fad. Other trades have much better education systems than the CS folks. Since CENTURIES.
The key ideas of Fortran and Algol are actually very powerful, if only the software creators (engineers and all those amateurs) would understand and appreciate them. Unfortunately, most folks think that new==better.
Which in most cases is NOT true. C is a regression relative to Algol (think of all the undefined behaviour from wild type casts, raw pointers etc). Unix is a regression relative to many mainframe operating systems. But most people just know the Unix and the very similar Windows model. Dynamic languages also incur massive security risks from the lack of data type systems. But hey, they are quick and dirty. And someone beat the propaganda drum, while noone drummed for Fortran.
So, maybe the Applied CS Trade (so to speak) should focus on using all the hard-won knowledge of the 1950s and 1960s instead of running after the latest, almost surely crappy invention of some hipster with a loud drum. Start with learning an appreciating Pascal. Do until you get the Enlightenment.
Fortran is very good about backwards compatibility...can still compile and run Fortran-77 programs in the newest incarnations...
Finding a working card punch is the problem.
I laugh at people who point at all the new Python and C++ numeric stuff whenver Fortran is mentioned, that don't realize 75% of those projects consist of ForTran libraries.
you are wrong and part of the problem, the necessity and issues caused by rewritng drivers constantly causes problems and wastes time that could be better spent on extending features
they went one step further and threw it all in the spec to be safe. the result is a language that does everything, good for nothing in particular, that can't be implemented
IBM 1620 FORTRAN IV was the first compiled language I learned back in 1969. I coded Fortran IV and F77 in the decades following, and C after that. Lately I have been learning Ipython Notebook 2.0 and just installed Anacinda with all those libraries for scientific data reduction and graphics/visualization. So it is fine with me if there is some binaries in there that were compiled from FORTRAN sources, what really matters is the integration allowed and if the numerical analysis is tried and true and based on the old algorithms crafted back when I was a boy, so much the better.
Life is a set of trade offs and sometimes we settle for stuff that works for different reasons, ease of use, sometimes, efficiency at other times, and it is good to know which is which, but surely the integration now available was a dream back when we dealt with boxes of punched cards as output from programs. Now, we may have to deal with an inefficient program from time to time, as a trade off, then I welcome your algorithms hat, to tell me that you have a better code or can invent one.
There is no time wasted rewriting drivers, and there is no problem. The drivers are part of the kernel; when the interfaces are changed, the drivers are changed accordingly. This doesn't take any time because the changes are fairly trivial (usually adding an argument to a function call). You have no idea what you're talking about, and are obviously not involved in kernel development.
The last time I dealt with Fortran was second tier support for the GCC compiler in Solaris in 2003. Some of Sun's biggest customers for the compiler were Fortran developers working in science institutes. I tested and routed test cases for customers against bugs for the F90 and F77 compilers. I assure you that there were no punch card decks involved, although when I first used Fortran in the 1960's and '70's they were involved. You can compile fortran sources on most Linux distros, and probably most every OS out there, right now.
Only makers of proprietary modules, and sycophants and nay-sayers complain about the Linux kernel not having a static API and ABI for kernel modules.
Ok, so this is going to sound like flaming but its not.. Because _ANYONE_ who has used linux for any extended period of time in a non trivial manner and, who is being honest with themselves has had problems due to the kernel and associated drivers being tied together.
Thats because without fail, the drivers for every single piece of hardware and the kernel/userspace API's don't all tend to move at the same speed. This means that when you have a problem with a driver for a particular piece of hardware in your system, being forced to take newer versions of drivers for every other piece of hardware is a recipe for something breaking. I have a pretty functional laptop running a recent distribution, I was pretty estatic when about 90% of my use cases actually worked. Sound, 3d graphics, suspend/wakup, wifi, EFI boot, on and on. But, in the end, i'm not running the latest GL SL, because its not supported, I have to hand modify the bluetooth driver to get my wireless mouse working, and I had to hack KDE and the OS to get the back-light dimmer to work properly. Then every couple weeks/months a new kernel gets rolled out to fix some problem or another and I have to reapply my changes.
I could write a 1000 page book about driver/kernel problems I've personally seen, and you need only spend a little time on LKML to notice that driver developers on linux don't really appear to be any better than any other OS. They make forward progress most of the time, but they also regularly regress some feature or another resulting in plenty of pain. Expecting the few hundred developers involved in the kernel/drivers for any particular machine to GET IT RIGHT for in any given kernel release is an exercise in fantasy land. Expecting the ten thousand or so involved in every driver in the kernel to GET IT RIGHT for every single machine running linux is even more fantastic.
So, a problem like this has a solution, ignoring it for religious reasons doesn't.
I think you're completely overblowing things. Regressions are rare; once a driver is working properly, what reason is there to go back and muck with the driver? Personally I've never seen any regressions at all on my hardware (or any HW I've worked with); once something's working, it stays working on newer versions. It's not like they need constant maintenance; the only time they need any maintenance is when the kernel interfaces change.
For your bluetooth and backlight drivers, it sounds like you made some fixes, and didn't get those pushed upstream; is that the case? If you push your changes upstream and get them included in the kernel, then you don't need to reapply them.
You can get more people interested in programming if you never subject them to the frustration of programming in perl. Implicit variables, regular expressions and "magic" operations make it unbearably unpleasant to program in.