×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

State of the Onion 11

Zonk posted more than 6 years ago | from the my-personal-favorite-is-french-onion-soup dept.

Perl 278

chromatic writes "Larry Wall's State of the Onion 11 address is now online. Every year, he describes the state of Perl and its community through metaphor and analogy. This year, Larry explored the history of scripting languages, from their dimly-lit beginnings to their glorious future. Along the way, he also describes several of the design principles invoked in the design of Perl 6. 'When I was a RSTS programmer on a PDP-11, I certainly treated BASIC as a scripting language, at least in terms of rapid prototyping and process control. I'm sure it warped my brain forever. Perl's statement modifiers are straight out of BASIC/PLUS. It even had some cute sigils on the ends of its variables to distinguish string and integer from floating point. But you could do extreme programming. In fact, I had a college buddy I did pair programming with. We took a compiler writing class together and studied all that fancy stuff from the dragon book.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

278 comments

Frost piss (0, Flamebait)

(TK2)Dessimat0r (669581) | more than 6 years ago | (#21613225)

Perl can fuck off and die. What a terrible programming language.

Re:Frost piss (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21613565)

Ditto: Perl can fuck off and die. What a terrible programming language.

Re:Frost piss (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21614875)

Mega ditto: Perl can fuck off and die. What a terrible programming language.

Horseback Basketball (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21613227)

When will Larry Wall learn that just because he is riding a zebra while playing basketball on horseback, it does NOT mean he is the referee?

scripting (5, Insightful)

Lord Ender (156273) | more than 6 years ago | (#21613333)

I really wish the term "scripting language" would die. Can't we just call them "very high level" languages, instead? Isn't that sufficient to distinguish the Perls, Pythons, and Rubys of the world from the "high level" languages like C and C++? It is perfectly possible to compile Python programs, for example, to a pyc binary. They aren't any more "scripts" than a.out. The difference between "very high" and "high," to me, is the fact that dynamic datastructures (lists, hashes) are native, so programmers don't have to worry about mundane memory address and pointer nonsense.

Re:scripting (1)

Solra Bizna (716281) | more than 6 years ago | (#21613405)

I don't think Perl or Python are scripting languages. I think sh-script is a scripting language.

I don't like to think about AppleScript.

-:sigma.SB

Re:scripting (4, Insightful)

Ed Avis (5917) | more than 6 years ago | (#21613455)

Python, Perl, Lua etc. are very high level languages, at least from a slightly old-fashioned perspective that regards assembler as the baseline and something like C or Pascal as high level. But there are other very high level languages which are not scripting languages, for example Haskell, Erlang, Prolog, C++ with insane template nonsense, even SQL and XSLT. So the term scripting language is still useful I think. The definition is a bit fuzzy, which is what Larry points out in his talk.

Re:scripting (1)

Intron (870560) | more than 6 years ago | (#21614009)

C only has the data types supported by the hardware, so it is not a high-level language. A high level language is one which provides an abstract view of the machine.

Re:scripting (1)

Reality Master 101 (179095) | more than 6 years ago | (#21614295)

C only has the data types supported by the hardware, so it is not a high-level language.

Uh, no. C has guaranteed data types that must be present in every implementation, such as 32 bit integers (not native to 8 bit processors) and floating point (not native to many processors). It is true that C has flexible data types that can be optimized for particular hardware.

Re:scripting (0)

Anonymous Coward | more than 6 years ago | (#21614427)

What have you been smoking? Since when does C require ints to be 32 bits?

Re:scripting (1)

forkazoo (138186) | more than 6 years ago | (#21614665)

What have you been smoking? Since when does C require ints to be 32 bits?

It doesn't. It does, however, require a 32 bit integer data type (which the OP said). long has to be 32 bits on a conformant implementation.

Re:scripting (2, Insightful)

Reality Master 101 (179095) | more than 6 years ago | (#21614849)

It doesn't. It does, however, require a 32 bit integer data type (which the OP said). It doesn't. It does, however, require a 32 bit integer data type (which the OP said).

Close, but not correct. C requires *at least* 16 bits for a short, and *at least* 32 bits for a long. It actually doesn't require an exactly 32 bit integer datatype. Well, to be really pedantic, the C Standard specifies a range of values that a datatype must support, so technically a binary machine is not required.

Re:scripting (1)

Reality Master 101 (179095) | more than 6 years ago | (#21614899)

What have you been smoking? Since when does C require ints to be 32 bits?

It doesn't, but I realize I phrased my post poorly. I meant that C requires an integer with at least 32 bits, which is typically not native to an 8 bit processor.

Re:scripting (1)

Ed Avis (5917) | more than 6 years ago | (#21614309)

C provides an abstract view of the machine in that you don't have to care about how many registers the processor has; you can just declare as many variables as you want and they will be allocated to registers automatically when needed for computation. It provides abstract data structures (structs) where you don't have to care about the memory layout. I agree that ML could be considered more abstract than C, and assembler less abstract; I don't think that 'provides an abstract view of the machine' is a good criterion, because it's too, um, abstract.

There's no particular requirement that C provide only integer or floating point types supported by the hardware. It is quite possible to have a full ANSI C implementation where the size of an int is not the processor's native integer.

Re:scripting (1)

Intron (870560) | more than 6 years ago | (#21614839)

A data structure is not a data type. Carry bits have been around for a while, too.

When you compile C the assembly code looks like the C code. You can do it yourself at least as well as gcc, usually better. Subroutine calls and stack frames follow standard, simple rules and leave a lot of room for optimization. Structs and unions are just a list of offsets and bookkeeping. There's basically nothing in the compiled code that you don't write in the C source code or include in a very straightforward way from a library except for the standard initialization and exit code.

If you tried to hand-compile perl code (for example) I think you would get lost in a hurry due to dynamic typing and sizes, hashes, references being more than pointers, garbage collection, etc. Its the invisible runtime environment and services that make virtual machine languages HLLs and those are very far from the hardware features of the computer.

Re:scripting (0)

Anonymous Coward | more than 6 years ago | (#21614913)

C only has the data types supported by the hardware, so it is not a high-level language.

And by "the hardware", you mean "the PDP-7 which it was written on" (ASCIZ!).

A high level language is one which provides an abstract view of the machine.

So C is a high-level language on a Lisp machine? Python is low-level if I'm using it to write OpenGL? Feh. I happen to find Alan Perlis' description much more useful: "A programming language is low level when its programs require attention to the irrelevant."

Re:scripting (1)

Lord Ender (156273) | more than 6 years ago | (#21614333)

My point is that whether a virtual machine, bytecode interpreter, or traditional compiler are used, you are still going from human-readable-language to machine code. The path you take to get there is inconsequential compared to what really matters: the language itself.

Re:scripting (1)

Ed Avis (5917) | more than 6 years ago | (#21614719)

I don't understand what you mean. Do you mean that C is a compiled language (generating machine code) while Python is interpreted?

Re:scripting (1, Funny)

Anonymous Coward | more than 6 years ago | (#21613475)

The difference between "very high" and "high," to me
The difference to me is if i'm not very high I dont understand perl at all.

Re:scripting (2, Interesting)

Anonymous Coward | more than 6 years ago | (#21613487)

Agreed. I code almost exclusively in Python at work (I say "almost", because I dabble in bash), and I'm so damn glad I don't have to deal with memory allocation nonsense like in C and C++. Even Java gets on my nerves with its static typing.

Languages like Python make it easier to design and implement algorithms without having to worry about other concerns.

High level != "automated memory management" (4, Informative)

Anonymous Brave Guy (457657) | more than 6 years ago | (#21614145)

Can we please stop bashing C++ memory management? I write C++ for a living, yet very rarely use what the critics typically call "manual memory management". Either it's really not that hard to do things in better ways, or I guess I must be a superhuman programmer, because according to all the checking software, I haven't introduced a memory leak since... no, actually, I've never introduced one in as long as I've worked here. If you want to talk about the advantages of garbage collection, knock yourselves out, but please stop treating C++ and C as if they're the same in terms of memory management. They are different worlds.

In any case, garbage collection is far from the biggest benefit of using a scripting language (or whatever we want to call them) over something lower level. As others are pointing out, the more important properties exhibited by most of the modern scripting languages that make them "high level" include first class data structures, first class functions, and dynamic typing.

Re:High level != "automated memory management" (2, Informative)

Anonymous Brave Guy (457657) | more than 6 years ago | (#21614247)

Before anyone else points it out, I realised that my final sentence in the parent post reads as though I think dynamic typing is necessary for a high-level language. I don't think this is so in general, but in the context of scripting languages, I think it's one of the key features that lets you write higher level code more easily. In a statically typed language, some sort of type inference serves a similar role, keeping the code generic and cutting out unnecessary boilerplate code.

Re:High level != "automated memory management" (4, Insightful)

smitty_one_each (243267) | more than 6 years ago | (#21614337)

Can we please stop bashing C++ memory management?
No.
If we don't insist on treating the tools themselves as the end product, then how will we perpetuate mis-information, and sell "new" products, which are, dared we look at them objectively, just re-shufflings of what has come before?

Re:scripting (1)

LWATCDR (28044) | more than 6 years ago | (#21613613)

"Is the fact that dynamic datastructures (lists, hashes) are native, so programmers don't have to worry about mundane memory address and pointer nonsense."
I guess you haven't used STL.
I have not used Perl for a while but when I did I would have called it a scripting language. It just didn't lend it's self to large programs. Python looks like it is better for large tasks but I haven't had time to get into it.
Perl and PHP are what I consider the crescent wrenches of programing.
Not the best tool but just too useful to not have.

Re:scripting (0)

Anonymous Coward | more than 6 years ago | (#21613653)

Let's see: a.out is an executable. It goes directly to memory to be executed by the CPU. test.pl is a script. It goes to memory and then uses another program to do what it wants. There is a fundamental difference. Machine code != bytecode != scripts, even though they are all the *fundamental* executable unit of their respective programming languages (you know, what your compiler/interpreter and linker spit out).

Re:scripting (1)

AmaDaden (794446) | more than 6 years ago | (#21613969)

Yes but Java does the same kind of thing and is considered a programing language by most. While it seems obvious to a lot of people where the lines are a lot of other people are going to war over a few square feet. Hypothetical arguments are the worst kind of argument, no one can ever win.

Re:scripting (1)

abigor (540274) | more than 6 years ago | (#21614109)

a.out gets executed by microcode. In that sense, machine code is "read" like a script. Really, it's just turtles all the way down.

Re:scripting (1)

interiot (50685) | more than 6 years ago | (#21613757)

Even compiled python retains the ability to eval(), no? Granted, even C can do this at times (C-Interp, XCoral), and in my mind at least, eval() isn't at the core of what defines "scripting languages" (as you mentioned, garbage collection (making memory management go away) and robust introspection (making serialization and debug-dumping brain-dead easy) are the defining features for me).

Re:scripting (1)

zippthorne (748122) | more than 6 years ago | (#21613843)

And, where would you classify graphical programing languages, like Labview?

Re:scripting (0)

Anonymous Coward | more than 6 years ago | (#21613975)

And, where would you classify graphical programing languages, like Labview?

under 'H' for Harmful.

Re:scripting (1)

Eco-Mono (978899) | more than 6 years ago | (#21614065)

I'd want to see a compiler from Perl/Ruby/Python to machine code (not bytecode!) before I'd be comfortable doing away with the "scripting language" terminology.

Re:scripting (1)

rbanffy (584143) | more than 6 years ago | (#21614119)

I think "scripting language" refers to the idea that what you write in the program happens in that order. Another idea is that you can write the program with a text editor and run the text file directly from your shell without further steps.

That's not like C or Java, when what happens when the program runs is what is inside the main function (or static method). And that happens only after you turned your text file into something else.

I think we may be creating a category where there is none or, better, we are joining a whole lot of different things under a single name for no better reason than to separate them from other languages that are even more different.

Re:scripting (1)

bahwi (43111) | more than 6 years ago | (#21614367)

I think Interpreted language is what it is now. In Perl/PHP etc... you can define functions/methods before or after you call them, as the entire file is parsed into bytecode typically, then interpreted. The steps are all automatic from the compiler/interpreted(perl or php from the command line). Python can save as bytecode to speed it up even further, although it is a one-time speed up typically.

Most IDEs let you compile and run at least basic C/C++ code from the IDE, without any additional steps. :D You can think of this as what php or perl itself does. AFAIK, Bash and other shell scripts go line-by-line, and stuff typically has to be defined before they are used. That is more of a traditional definition of a scripting language.

A good thing most websites that use php use is a bytecode cache(think of Java Bytecode) where it is compiled once and kept in memory to let it run faster.

You could easily have a .bat file in windows or a shell script handle all the things to make a text file into an a.out or into a compiled java program and then run that program, it's all a matter of where it is happening and who is doing it. Ah, love technology. Labels are stupid these days, use what works best for the situation and go from there.

Re:scripting (1)

AceJohnny (253840) | more than 6 years ago | (#21614195)

It is perfectly possible to compile Python programs, for example, to a pyc binary. They aren't any more "scripts" than a.out.

Pedantic mode ON
A .pyc is python source code compiled to bytecode. That bytecode is then interpreted by the Python virtual machine which executes appropriate machine code, sort of like the Java VM (though I don't think the Python VM does JIT compilation to machine code).
This is different from a.out (or the more modern alternative, ELF), which contains real machine code, which is executed by the processor, not by a virtual machine.
Pedantic mode OFF

Now I agree that .pyc isn't script. However I've have yet to see people exchanging .pyc files instead of the original script*, so I don't believe they're relevant.

*Outside of Py2exe

Re:scripting (1)

Yossarian45793 (617611) | more than 6 years ago | (#21614297)

The difference between a scripting language and a high level language is that scriping languages make it very easy to write small programs, but nearly impossible to write large programs. High level languages are the reverse. Perl can do very useful things in just 10 lines of code. However, nobody would want to deal with a Perl program 100,000 lines long. In C/C++/C#/Java it usually takes at least a few dozen lines to write even simple programs, but the tradeoff is that these languages scale nicely up to very large programs, with a million lines of code or more. I haven't written and Python or Ruby, but from what I've read about them I suspect that they are useful for relatively small to medium size programs -- which means they are scripting languages.

Re:scripting (2, Insightful)

Yvanhoe (564877) | more than 6 years ago | (#21614435)

Perls, Pythons, and Rubys are interpreted languages as opposed to compiled languages. A .pyc is not an executable file.
Every people use the term differently. Here is mine : I am doing a script when I give directives to launch programs or functions written in another language. When the CPU spends 90% of its time outside my program, I consider that this is a script.
Python's philosophy is that it is a scripting language in the sense that if you spend more than 10% of your CPU time interpreting some python code, you are doing something wrong. They encourage you to rewrite these image processing functions in C/C++ if you are serious about performances.

And yes, given this definition, one can write scripts in C.

Re:scripting (1)

mstrebe (451943) | more than 6 years ago | (#21614879)

I think we should use the traditional terms, "interpreter" and "compiler", because that is a fundamental and intrinsic differentiator. I'm leaving byte-coded languages like Python and Java in the interpreted category, but perhaps "coded" would be a better intermediate term.

While any language could be implemented either way, languages do have their defaults and those defaults speak to design differences that matter. interpreted languages are almost always garbage collected, which creates memory and performance characteristics that don't change much even if they are compiled. For example, "compiling" python to an executable is really just binding the python interpreter to a package of byte-code wrapped as an executable--it's not really converting Python to machine code. As such, it's not much faster than interpreted python and really only exists as a convenient way to package Python for Windows.

The difference in terms matter. Scripting langauges are for integration work, administration, and other "one-time" coding projects. Compilers are for creating shippable mass market products. That difference will always be with us.

Perl 6: The Language of the Future (... Forever) (5, Funny)

joe_n_bloe (244407) | more than 6 years ago | (#21613409)

Every year Larry talks about what interesting things have been going on with Perl 6. These interesting things never include "release."

Re:Perl 6: The Language of the Future (... Forever (0)

Anonymous Coward | more than 6 years ago | (#21613429)

And every year it seems like his talks just keep getting more and more out-of-touch and irrelevant...

Re:Perl 6: The Language of the Future (... Forever (2, Informative)

Otter (3800) | more than 6 years ago | (#21613505)

Every year Larry talks about what interesting things have been going on with Perl 6.

And this year he barely even did that!

Fine by me (3, Insightful)

winkydink (650484) | more than 6 years ago | (#21613513)

Perl 5.8 does everything I need it to. There are other languages I use when Perl doesn't do what I need it to. I don't need one language for all of my needs.

I view Perl 6 as an continued employment mechanism for those who write books about Perl and teach Perl to others.

Re:Fine by me (1, Insightful)

TheLink (130905) | more than 6 years ago | (#21614827)

There's one big limitation I find with Perl 5.8. It's slow. Don't get me wrong it's fast enough in many cases.

BUT if it was 20-30 times faster people would be able to use it for a lot more stuff where they'd otherwise have to resort to stuff that involves a lot more work :).

Parrot hasn't been very impressive, and ponie is dead anyway.

Yeah I know python is a bit faster and cleaner but so far it doesn't seem like a huge improvement.

I've looked at Lisp and I've come to the conclusion that:

Lisp is powerful for all the code you write, unfortunately you still have to write a lot of that code yourself.

In contrast Perl is powerful because of all the code you don't have to write. :)

perl 5.10 should not be neglected (Re:Fine by me) (2, Interesting)

doom (14564) | more than 6 years ago | (#21615077)

perl 5.8 does everything I need it to. There are other languages I use when Perl doesn't do what I need it to.
perl 5.10 is about to be released, and it has a number of significant improvements over perl 5.8. Off the top of my head: it has a real "switch" statement included (as originally designed for perl 6), it has recursive regular expressions that can be used to do Text::Balanced sorts of things (if for some reason that now-standard module doesn't do it for you), and a number of new modules have been added to the standard library.

I view Perl 6 as an continued employment mechanism for those who write books about Perl and teach Perl to others.
At the present, I look at Perl 6 as an attempt at turning perl into a saner, more rational language, by keeping Larry and Damien busy with something else.

Even so, I'm still interested in seeing where it goes. Unlike commercial projects, open source projects can continue to stagger forward to success long after many people have given up hope (e.g. Mozilla/firefox).

Re:Perl 6: The Language of the Future (... Forever (3, Funny)

rubycodez (864176) | more than 6 years ago | (#21613555)

and every year the design for Perl 6 becomes more and more contorted and ultra-complicated, basically taking every cool feature Larry sees in other languages and mashing them together into an incoherent Mulligan stew. If Perl is like "whale guts everywhere" then Perl 6 is like taking a whole Oceanarium of sea creatures and dropping them through the dual rotors of a crane copter 10,000 feet over Manhattan.

Re:Perl 6: The Language of the Future (... Forever (1)

krog (25663) | more than 6 years ago | (#21613661)

Thankfully, Perl 6 follows the same principle as previous Perls: you don't need to know the whole language to use it -- kinda like spoken language. There's more than one way to do it, and those who can't hang with this design goal have plenty of pattern-rigid, syntax-poor dynamic languages to choose from (Python, Ruby, Esperanto...).

Re:Perl 6: The Language of the Future (... Forever (3, Interesting)

timster (32400) | more than 6 years ago | (#21613817)

That sounds great, until you're trying to work with someone else's Perl code and it turns out that they have a special fondness for those Perl features which were inspired by awk. A language with a clean design means that you can collaborate with others.

Re:Perl 6: The Language of the Future (... Forever (1, Insightful)

krog (25663) | more than 6 years ago | (#21613883)

Or, conversely, you could blame yourself for not knowing the language you're trying to work on, rather than blaming your colleague for knowing it.

I'm not saying that ugly Perl doesn't exist, because it sure as hell does. Perl does not enforce any coding standards at all on its programmers, so undisciplined coders will write undisciplined code, but I'd rather be in Perl's side of the enforcement continuum than, say, Java's or Python's side.

Re:Perl 6: The Language of the Future (... Forever (2, Insightful)

timster (32400) | more than 6 years ago | (#21613995)

You said that it's OK for Perl to have an excessive number of features, because you don't have to know them. I'm pointing out that the truth is that you do have to know the whole language to use it. So no, I don't have to "blame myself for not knowing the language", I blame the language for being poorly designed.

Re:Perl 6: The Language of the Future (... Forever (1)

krog (25663) | more than 6 years ago | (#21614169)

You need to know the whole of the language to use it with someone who knows, and uses, the whole of the language. This is to be expected. However, if you are in your boxer shorts and you just want to pump out a short file-diddling script before bedtime, no one is going to tell you that it can't look like C.

Perl will let you approach a problem however you want. Imperative, functional, OO programming all works out of the box; constraint, logic, aspect programming are possible. This liberates many programmers, and intimidates many others.

Re:Perl 6: The Language of the Future (... Forever (0)

gardyloo (512791) | more than 6 years ago | (#21614373)

However, if you are in your boxer shorts and you just want to pump out a short file-diddling script before bedtime, no one is going to tell you that it can't look like C.
And that, boys and girls, is why it's very, very important to give proper context to your statements. Otherwise, you're going to be arrested...

Re:Perl 6: The Language of the Future (... Forever (1)

timster (32400) | more than 6 years ago | (#21614521)

You need to know the whole of the language to use it with someone who knows, and uses, the whole of the language.

No! You need to know the whole of the language to work with three other people, each of whom knows a different part of the language.

Re:Perl 6: The Language of the Future (... Forever (1)

Otter (3800) | more than 6 years ago | (#21614527)

This is to be expected.

And his point is that that's why hideous syntax and features are a problem even if you choose not to use them.

Re:Perl 6: The Language of the Future (... Forever (0)

Anonymous Coward | more than 6 years ago | (#21614769)

You need to know the whole of the language to use it with someone who knows, and uses, the whole of the language.
No, you need to know the whole language to reliably know that you can work with anyone else who also "knows Perl". Having two or more people who can apparently know the same language and yet be unable to effectively work with each other's code can only be a bad thing.

Perl will let you approach a problem however you want. Imperative, functional, OO programming all works out of the box; constraint, logic, aspect programming are possible.
You say that as if that's a good thing. Perl prides itself so much on "there's more than one way to do it", why is it apparently so closed to the idea that some of those ways might mean using another language. Instead of trying to be all things to all men and getting an abhorration of a language, why not accept that Perl is not, and never will be, the One True Language and that multiple languages is the appropriate and practical way to express multiple programming paradigms.

Of course that won't actually happen. Reading TFA just further shows that Perl 6 is intended to be Larry Wall's feature-list novelty language with applicability and useability as afterthoughts.

Re:Perl 6: The Language of the Future (... Forever (0)

Anonymous Coward | more than 6 years ago | (#21615327)

Having two or more people who can apparently know the same language and yet be unable to effectively work with each other's code can only be a bad thing.

No. You don't have some kind of divine right to understand all code that happens to be written in a particular language, any more than you have the right to understand all code that happens to run on a particular operating system. Otherwise, your "multiple languages" idea would fail because you claim to understand "Linux programming", and yet you can't understand code for a Linux implementation of APL (substitute your choice of operating system/language for Linux and APL).

Re:Perl 6: The Language of the Future (... Forever (0)

Anonymous Coward | more than 6 years ago | (#21615167)

Hm...? Are you both arguing that Perl sucks, or only one of you arguing that Perl sucks?

Re:Perl 6: The Language of the Future (... Forever (1)

Coryoth (254751) | more than 6 years ago | (#21614867)

I'm not saying that ugly Perl doesn't exist, because it sure as hell does. Perl does not enforce any coding standards at all on its programmers, so undisciplined coders will write undisciplined code, but I'd rather be in Perl's side of the enforcement continuum than, say, Java's or Python's side.
I think which side of the enforcement continuum looks appealing is generally a function of the sort of project you're working on. The more programmers who all have to cooperate and work with each others code, and the greater the importance of long term maintenance, the more appealing strict enforcement becomes. Conversely, the more important rapid expression and development of ideas is, the more appealing lack of enforcement and flexibility in how you express things becomes.

So yes, if you have a big project with lots of programmers, and the expectation of ongoing maintenance work by people other than the original coders, then having strict enforcement, and hence clarity and consistency throughout, looks very appealing. Sure, you can fit a flexible language to the task by writing a big document of official coding standards and guidelines and spending time going through code as people submit it to make sure it meets the guidelines; on the other hand you can just have the compiler to that work for you. This is why Java is more popular for large scale enterprise applications etc.

Also, yes, if you just need to write a quick program to do some processing, or play around with some prototypes to clarify your ideas, etc. then the compiler complaining every time you don't manage to squeeze your thinking into the appropriate idiom is just kind of annoying and slows you down. This is why perl remains very popular: if managing to get ideas into code as fast as possible is of primary concern, then it's probably at least as good a choice as any.

There is no "better", merely what sort of concerns matter most for the project.

Re:Perl 6: The Language of the Future (... Forever (1)

ajs318 (655362) | more than 6 years ago | (#21614359)

But you could say the same about almost any language, unless it's either based on a "bondage-and-discipline" paradigm, forcing you to do things One True Way; or hopelessly crippled in terms of things you can actually do with it. Or both. (*cough* Modula-2 *cough*)

Some use screws, some use nails; some use nuts and bolts, some use tapped holes. Some use gaffer tape. Perl doesn't mind which you use. The OP's complaint sounds like someone who has inherited a second-hand tool box and found no number 2 posi bits that weren't chewed up, the 10 and 13mm. sockets missing and "SNAP-ON" changed to "STRAP-ON".

Re:Perl 6: The Language of the Future (... Forever (4, Funny)

nuzak (959558) | more than 6 years ago | (#21614873)

> Thankfully, Perl 6 follows the same principle as previous Perls

Except for actually existing.

Re:Perl 6: The Language of the Future (... Forever (1, Funny)

Anonymous Coward | more than 6 years ago | (#21613801)

Free sushi at your doorstep, for everybody!!!

Tell me again how this is bad?

Yup... and he doesn't apologize for it (5, Interesting)

krog (25663) | more than 6 years ago | (#21613575)

The Perl 6 community is more focused on getting it right than getting it into the marketplace ASAP. While this is frustrating for many -- it seems like every other day, there's a Perl 6 feature I want to use in my Perl 5 program -- it has contributed positively to the development of Perl 5 and Perl 6 alike. Perl 6 is painstakingly designed and planned as truly a next-generation dynamic language, and as features are completed, they often spill down into Perl 5. (See the perldelta [cpan.org] for v5.10, out very soon, for some good examples.)

Unless someone is willing to finance full-time development on Perl 6, this is the best we get. I think it's pretty good.

Re:Yup... and he doesn't apologize for it (2, Insightful)

rubycodez (864176) | more than 6 years ago | (#21613687)

getting it right???? Perl 6 is a pathologically overcomplicated mess of anything and everything Larry saw in other better designed languages over the last decade, all mixed up with no rhyme or reason. It's like a swiss army knife with condiment and shaving cream dispenser, cell phone and vibrating butt plug. The specs are a nightmare to read, the syntax takes 25% more effort to construct something compared to other scripting languages, and there's no end in sight. Time to realize Perl 6 is like the Ripley-Alien clone freaks, only merciful thing would be to hit it with a flamethrower and start over.

Re:Yup... and he doesn't apologize for it (-1, Flamebait)

krog (25663) | more than 6 years ago | (#21613763)

Like I said elsewhere, if you can't keep your head afloat in choppy waters, you're free to use whichever kiddie-pool language you want. You can shit out your ten-minute Rails apps to your heart's content, and I shall continue to write concise, higher-order Perl which will fuck you and leave you in an alley.

Re:Yup... and he doesn't apologize for it (0, Troll)

rubycodez (864176) | more than 6 years ago | (#21613983)

Rails is a web app framework, not a language. There are much better ones for Ruby. High order Perl, haha, that's like when I had to write some Objective COBOL for an insurance company almost ten years ago, fun because it was so painful compared to the same task in a well designed language.

Re:Yup... and he doesn't apologize for it (4, Funny)

Nimey (114278) | more than 6 years ago | (#21613803)

So it's the computer-language equivalent of English?

Re:Yup... and he doesn't apologize for it (1)

Ant P. (974313) | more than 6 years ago | (#21615027)

It's like a swiss army knife with condiment and shaving cream dispenser, cell phone and vibrating butt plug.
You say that as if it's a bad thing.

Re:Yup... and he doesn't apologize for it (3, Funny)

theskipper (461997) | more than 6 years ago | (#21615059)

I once made a bet with a friend that some day we would see the terms "Perl 6" and "vibrating butt plug" in the same sentence.

Kicking myself for not saying paragraph instead of sentence.

Re:Perl 6: The Language of the Future (... Forever (1)

Ed Avis (5917) | more than 6 years ago | (#21613833)

If perl 6 had been released, Larry would be talking about perl 7.

In other news... (4, Funny)

nycguy (892403) | more than 6 years ago | (#21613603)

Duke Nukem Forever team announces that they are reimplementing everything in Perl 6.

Re:In other news... (2, Funny)

Ignominious (816315) | more than 6 years ago | (#21614377)

FTA:

"Then there's Duke Nukem Forever, a nice clean design. It has some issues, but in the long run Duke Nukem Forever might actually turn out to be a decent platform for running Perl 6 on. Pugs already has part of a backend for Duke Nukem Forever, though sadly that has suffered some bitrot in the last year. I think when the new Duke Nukem Forever engines come out we'll probably see renewed interest in a Duke Nukem Forever backend."

Re:In other news... (1)

siglercm (6059) | more than 6 years ago | (#21615019)

FWIW, I tagged this article "perl6forever"

Great minds think alike, eh? (That way at least the two of us can feel superior....):

Re:In other news... (0)

Anonymous Coward | more than 6 years ago | (#21615353)

Oh no!!!! Now it will take twice the time to get... nevermind. Inifinityx2=Infinity.

Thanks, and see ya! (2, Insightful)

stuntpope (19736) | more than 6 years ago | (#21613691)

Thank you, Mr. Wall, for providing a language that caught my interest and led me into a profitable career.

However, I moved on several years ago. One of those Python guys inspired negatively by Perl. Much of what keeps me away from Ruby, in fact, is the Perl resemblance. I still have a legacy Perl application to maintain, but I don't do any new Perl work.

I'd think a regular "State of the Onion" pronouncement would be an avenue to discuss where we are today, and where we are headed, with Perl. Instead, it's a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

I guess I really don't get the purpose of the essay.

As to TMTOWTDI, I've concluded TOABWTDI (There's Often A Better Way To Do It).

Re:Thanks, and see ya! (4, Insightful)

kisrael (134664) | more than 6 years ago | (#21614273)

I'd think a regular "State of the Onion" pronouncement would be an avenue to discuss where we are today, and where we are headed, with Perl. Instead, it's a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

I guess I really don't get the purpose of the essay.
I think the purpose of the essay might be to be a rambling short history of "scripting" languages, and a rundown of various language design choices with "Perl 6 will have [x]" statements.

It was also (IMO) a damn fine read, with lots of intriguing rhetorical flourishes (I also learned a little C. [...] That's because a little C is all there is) and thought-provoking concepts, like how most human languages can express anything, but they differ in what you MUST express.

I think most people have a rough idea where Perl is now (present, though likely slipping as a % of interesting code being written) and where it's going (a guess about how the new perl 6 would be received when it finally shows up)

As to TMTOWTDI, I've concluded TOABWTDI (There's Often A Better Way To Do It).
Better than Perl, or in general?
If the latter, well sure... there will almost be another way that is better in some subset of the parameters you could use to measure "Betterness". One tradeoff you always have to make is how much time and conceptual effort do you put into optimizing that...

Re:Thanks, and see ya! (1, Offtopic)

Tomy (34647) | more than 6 years ago | (#21614281)

Though Ruby may have borrow some syntax features from Perl, most of the Ruby community stay away from them. I don't think you'll find much Ruby code out there that in any way resembles Perl. Like you, I'm negatively-inspired by Perl, after working for a company that had huge amounts of Perl code as a large portion of their infrastructure.

Code should be pleasing to read, since we spend so much of our lives at this activity. I think Python and Ruby do well in this goal, though the double underscores like "__init__" in Python always bothered me. Of course the Ruby '@' prefix to indicate class scope probably bothers those who haven't wasted away hours in Rogue-ish pursuits.

Editing (0)

Hemogoblin (982564) | more than 6 years ago | (#21613711)

The summary could use a touchup. "But you could do extreme programming" is a sentence fragment. Does Slashdot have editors?

Re:Editing (1)

amrittuladhar (824792) | more than 6 years ago | (#21614041)

Erm... I believe that's a quote from the article itself... now incorrect quoting would be worse, wouldn't it?

It's not exactly a sentence fragment anyway.

Because people begin sentences with conjunctions all the time.

Re:Editing (1)

ggvaidya (747058) | more than 6 years ago | (#21614787)

Why is it a sentence fragment? I don't know much (anything?) about English grammar, but there's a subject ('you'), object ('extreme programming'), and a verb ('do'); what's missing?

BASIC/PLUS (2, Funny)

Sloppy (14984) | more than 6 years ago | (#21613745)

Oh wow, BASIC/PLUS on a PDP-11 running RSTS. That's how I started too. And yet, I became a Python guy. ;-)

Re:BASIC/PLUS (1)

markana (152984) | more than 6 years ago | (#21613961)

Yeah, that particular machine was an 11/45 running RSTS/E. That was a sweet machine and O/S learning programming and systems fundamentals. Oh, it had FORTRAN, COBOL, and assembly too, for the masochistic Comp Sci students.

The real reason they didn't put Unix on it was because that machine was the *only* minicomputer on campus, and ran the school database (written by Larry) and cafeteria card readers. It was locked in to running those critical functions, and V7 Unix certainly wasn't going to run on the occasional Trash-80 that was hanging around.

Re:BASIC/PLUS (4, Funny)

Suzuran (163234) | more than 6 years ago | (#21613987)

My high school had a calculator policy of "You may bring any calculator you like to calculator-allowed tests."
So one day I decided that my calculator was GLAXIA, my PDP-11/44 which ran RSTS/E (V8 or V7, I forget which...)
I packed the whole thing on a cart; the system (Two BA11s), RA81 disk, and LA-120 teletype, and wheeled it into the classroom.
The teacher asked me what it was - "It's my calculator." The look on his face was priceless.
It was loud as hell, but the teacher allowed me to complete the test with it. I forget what I scored.
Thereafter the calculator policy was changed to read
"You may bring any calculator you like to calculator-allowed tests, provided it does not dim the lights when powered on."

Old hardware rocks!

Re:BASIC/PLUS (1)

rbanffy (584143) | more than 6 years ago | (#21614343)

A lot of people started with BASIC: that was just about the only choice for 8-bit computers with no real mass storage back in the 70s and early 80s. No way I could conjure the money for a real CP/M computer.

And the IBM-PC was, already, the same sorry inelegant mess it is today, so I won't get started. And it was very expensive too.

I learned to program in a Texas calculator and my first computer was an Apple II+ (after a Sinclair ZX-81 clone that was not a real computer) and, or course, I learned BASIC with it.

But like many others, I went on to learn more interesting stuff. Perl got my interest in about 1996, but lost its appeal when I had contact with other cleaner, less concise but far more readable and maintainable options.

Keep in mind I learned APL in college. I _know_ a write-only programming language when I see one.

Not as funny as usual (0)

Anonymous Coward | more than 6 years ago | (#21613821)

Usually I can count on The Onion to provide a few laughs, but this one only a few chuckles. Maybe I just don't get it.

The Camel (0, Troll)

slagheap (734182) | more than 6 years ago | (#21613889)

Isn't Slashdot violating O'Reilly's trademark by using an image of a Camel in association with Perl?

Just sayin'...

Did anyone else... (1)

Gigiya (1022729) | more than 6 years ago | (#21613937)

...read it and think "State of The Onion"? And then become confused when they started talking about Perl?

Re:Did anyone else... (1)

BrianRagle (1016523) | more than 6 years ago | (#21614313)

You aren't alone. I am a non-programmer and saw the headline as having something to do with The Onion satire site.

Re:Did anyone else... (1)

AndrewNeo (979708) | more than 6 years ago | (#21614975)

I know I did. Then I saw it talking about Perl and was wondering what the heck onions have to do with Perl. (Protip: I don't use Perl)

wanna be annoyed? try this (2, Informative)

wardk (3037) | more than 6 years ago | (#21614171)

attend a local Perl user group meeting seeking basic knowledge like maybe a few tips about hashes and namespaces

your question may be answered if you are willing to sit through 3 hours of the alpha geeks sparring over who understands Damian Conways latest obsfucation most, hopefully with many examples of their own variations to programs that have no real use. meetup at break with someone who didn't participate in that discussion and note they don't know what the hell they are there for either

besides, anyone who doesn't know enough about perl to make changes to it's internals is a lamer

I love using perl, but in my experience, the community around it is lead by pretentious people who think you suck

ok, I admit I haven't attended one of these in years, but now you know why

your mileage may vary, hopefully much better results than mine were

Perl 6. why again should any mere mortal even give a damn??

Pair programming? (1)

FlyByPC (841016) | more than 6 years ago | (#21614713)

Maybe I just don't get it, but I really don't see how "pair programming" -- at least as it was explained to us in the CS classes I took -- could possibly be efficient. Two programmers sharing one computer?

I'm not the world's most l33t programmer (far from it), but I did win a local programming contest a few years back -- due in large part, I think, to the fact that the other teams had to share a terminal, whereas I was working by myself. Anecdotal, I know -- but it gives me definite doubts about the wisdom of Pair Programming.

I figure if anyone knows, you guys do. Am I missing something here -- or is this really as inefficient as it seems to be?

Worst presentation in a while. (3, Insightful)

harrkev (623093) | more than 6 years ago | (#21614813)

Is it just me, or is this his worst presentation in a while? I think that I missed last year's, but I remember thinking that a couple of his presentations were quite original. There is the one where he based his entire presentation on an optical-illusion picture (three years ago, as I recall), and one where his presentation was based on the default Red Had screensaver collection (two years ago, if I am not mistaken). I had always thought that listening to him present one of these would be kind of like geek-stand-up-comedy. This one was downright plain by comparison.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...