State of the Onion 11

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.'"

Comments

scripting

[Lord Ender]

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

[Solra Bizna]

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

[Ed Avis]

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

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:scripting

[LWATCDR]

"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

[Anonymous Coward]

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

[interiot]

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

[zippthorne]

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

Re:scripting

[AmaDaden]

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

[Anonymous Coward]

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

under 'H' for Harmful.

Re:scripting

[Intron]

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

[Eco-Mono]

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

[abigor]

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

[rbanffy]

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

[AceJohnny]

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

[Reality Master 101]

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

[Yossarian45793]

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

[Ed Avis]

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

[bahwi]

Oh, there's lots of those: http://www.governmentsecurity.org/archive/t4695.html is one example. There are more for PHP, I'm sure for Ruby and Python but I rarely dabble in those languages.

But also, what is Java then? A scripting language? :D The definitions never really seem to settle.

Re:scripting

[Lord Ender]

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

[bahwi]

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

[ajs318]

a.out gets executed by microcode.

What if you're running it on an ARM2?

Re:scripting

[Anonymous Coward]

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

Re:scripting

[Yvanhoe]

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

[nschubach]

The day that they take away sizeof()?

Re:scripting

[forkazoo]

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

[Ed Avis]

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

[Intron]

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

[Reality Master 101]

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

[mstrebe]

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.

Re:scripting

[Reality Master 101]

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

[Anonymous Coward]

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

[abigor]

Yeah, yeah, okay. Or even a 6502 (weren't they hardwired also?)

Re:scripting

[mondoterrifico]

"Can't we just call them "very high level" languages, instead?"

No.

Re:scripting

[Lord Ender]

Classifying languages primarily by one of their least important attributes, the path code takes from source to execution, makes as much sense as classifying vehicles by their color instead of their shape, size, or purpose.

For example, most would categorize vehicles as either boats, airplanes, automobiles, or trains. Categorizing languages by "scripting" or "compiled" is like grouping boats and trains into the same group if they happen to be the same color.

The language syntax and featureset matters far, far more than how it is compiled.

Re:scripting

[Anonymous Brave Guy]

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.

Assuming you're referring to the container classes in the C++ standard library, those are nothing close to having first class data structures and good language support for them. You can't write literals using them, for a start. Even what they do do is clumsier than in languages with built-in support, e.g., Perl's neat sort keys %hash, Python's yield facility and for loop, Haskell's pattern matching for list processing, and many similar ideas in these and many other languages.

Re:scripting

[SL Baur]

C only has the data types supported by the hardware, so it is not a high-level language. That's not the distinguishing feature of a "high-level language". A high level language is one which often requires translation of the source into hidden subroutine calls to implement some of the features (and I'm not referring to simple stuff like double word arithmetic).

C is not a high-level language because it is sugar-coated assembly.

Re:scripting

[scubamage]

The difference between high and very high has always meant about one or two bowlpacks difference to me...

Re:scripting

[Anonymous Coward]

There is no telling what a modern C compiler is going to do to your code. Referring to C as a "sugar-coated assembly" is completely ridiculous. Your definiton of "high level language" is vague to the point of meaninglessness. This term "high level" is simply not well defined. This is why you get idiots chasing each other in circles arguing about whether language X high level or higher level than language Y. The term "assembly" is much clearer, and C does not fit the bill.

Re:scripting

[Chandon Seldon]

Hand compiling is only moderately more complicated for Perl than it is for C. Just as the C function turns into a specific pattern in assembler, the various things that Perl provides can be turned into assembler patterns too. The stuff that Perl does for memory management implicitly is only moderately more complex than the stack manipulation that C does implicitly for lexical variables. Even the two data structures that Perl provides - vectors and hashes - are just very simple data structures that would always translate into the same simple pattern of assembler.

Basically the only thing that cleanly differentiates a language like Perl from a language like C is the "eval" function - which requires access to a Perl interpreter/compiler to work.

Re:scripting

[Lord Ender]

You think that's pedantic? Your "real machine code" isn't. It's a set of CISC code that is interpreted to RISC. Only the RISC runs on the Si itself. The so-called binary does not.

I win the pedantry wars and my point stands :-)

Re:scripting

[Ed Avis]

I agree. Especially since path from source to execution can vary for the same language (Python can be compiled, and C interpreted, Haskell is both, and in any case there is usually some intermediate bytecode involved).

However I wouldn't use 'scripting' to just mean a language which is interpreted. For me, a scripting language is one where you can write small useful programs quickly - which suggests some kind of interpreter is available, it has dynamic typing, provides reasonable high-level data structures like lists and dictionaries, comes with useful libraries, etc.

Re:scripting

[drew]

I don't know about python specifically, but in my experience "compiling" most interpreted languages only means that you are embedding the a copy of the interpreter and the source code (or the parse tree) of your program together into an executable format. It doesn't give you any benefit over interpreting the raw script other than that you don't have to have the standalone interpreter installed on the target machine. (and if the "compiler" generated the parse tree for you then you save a minor hit on parsing the script again, which only barely affects startup time of the program.)

I don't generally use the term "Scripting" language unless maybe I am talking about shell scripting, but saying that something isn't a scripting language because you can "compile" seems pretty meaningless.

Re:scripting

[Ed Avis]

So your argument is that C compiles down to code which runs on the bare processor, whereas Perl etc. compiles to a bytecode that runs in a much richer runtime environment with garbage collection. This makes sense. I agree that C is not a high level language - just wanted to point out that 25 years ago, it was considered more of a high-level language than it is considered now.

Re:scripting

[coolGuyZak]

Then it gets executed by electrons? No--no, it gets executed by turtles.

Re:scripting

[Chandon Seldon]

That's how you would define high level language if you were trying to exclude C, and even then it's arguable - malloc is part of the C language for example. Sure, you'll argue that it's a function call - part of the standard library not the language - but that's really just a question of syntactic sugar - C-like language where malloc was a keyword with special syntax wouldn't be any higher level than C.

Re:scripting

[maxume]

There are ways to get python to run as machine code(or at that level, I don't care about splitting hairs). For instance, psyco, which is more or less a JIT for python code:

http://psyco.sourceforge.net/introduction.html

There are also python like languages(pyrex) and attempts at using type inference to make stuff that looks like python compile as C++(Shedskin), so the range of ways to run python(like) code is pretty broad for (I more familiar with python, I'm sure others have similar options).

The big difference between what you are calling compiled languages and interpreted languages is mostly typing. A big long rant about it is here:

http://steve.yegge.googlepages.com/is-weak-typing-strong-enough

Weak/dynamically typed languages often end up interpreted because it is a whole lot easier to make them work that way. They end up memory managed because memory is usually most important where speed is most important, and they, mostly because of weak/dynamic typing, are generally not cycle efficient, so prating over memory doesn't end up being worth it.

Re:scripting

[krog]

Spoken like someone who's never had to use it. Here's a sample application:

Spend a few days writing a discrete wavelet transform algorithm and grapher in C,

OR

Wire three LabVIEW modules together in two minutes, then drink beer until your mom starts crying.

Re:scripting

[anomalous cohort]

To me, the term scripting has nothing to do with the level of abstraction. Rather, it is more about whether or not the source is directly interpreted or compiled into an intermediate form. Having said that, I must admit that it would be awfully silly to create a low level language that is interpreted.

From most of the languages that he lists, it looks to me that what he is really talking about are Dynamic Scripting Languages. Scripting languages that are also dynamic provide a lot of flexibility and can genuinely be categorized as different from static languages in an interesting way. I have blogged on this recently as part of a larger article on OSS.

Re:scripting

[Ed Avis]

I must admit that it would be awfully silly to create a low level language that is interpreted.

Not at all. Open Firmware (used in the OLPC among other devices) is built around a Forth interpreter which can be used to write device drivers and hardware initialization code. Pascal was originally implemented as a p-code interpreter. And so on.

Re:scripting

[EssenceLumin]

If you don't seriously advocate nuclear power, then you don't take global warming seriously.

What a weird sig. 90% of humans dieing off would certainly take care of it.

Re:scripting

[Intron]

When you compare C to some of its predecessors like lisp and apl it is pretty clear that C was designed more for efficient compilation and low overhead than for fancy computer science constructs. It is great for its intended purpose, writing system code, which is why it's still used today.

----

"C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

And limiting your project to C means that people don't screw that up, and
also means that you get a lot of programmers that do actually understand
low-level issues and don't screw things up with any idiotic "object model"
crap."
    -- the ever-tactful Linus, Sep-6-2007, on gmane.comp.version-control.git

Re:scripting

[mdd4696]

There are five generations of languages as defined by Aho, Lam, Sethi and Ullman in Compilers: Principles, Techniques & Tools (also known as the Dragon Book):

1. Machine code
2. Assembly languages
3. Higher-level languages (Fortran, Cobol, Lisp, C, C++, C#, Java)
4. Application-specific languages (SQL, Postscript)
5. Logic- and constraint-based languages (Prolog)

Scripting languages fall into the third generation. The distinction between scripting languages and other languages is that they are interpreted rather than compiled and that they provide many higher level constructs.

Re:scripting

[Anonymous Coward]

What is with the geek pedantry? Why do we have to classify everything? No I'm not new here, but is it not enough to look at the lineage of things? At some point the thing is what it is. Yes biologists classify things but they have the good sense to stop at species!

Re:scripting

[Anonymous Coward]

C code, i is a 64-bit int automatic

i += 5;

compiled on PPC

      ld r3,40(stkp)
      addi r3,5
      sd r3,40(stkp)

okay, your turn for the perl:

$i += 5;

what's it compile to? Don't forget that the value of $i may be undefined, a string, an integer, a float or a ref.

Re:scripting

[nog_lorp]

The STL isn't native...

Re:scripting

[Ed Avis]

I think C was designed mainly to make it easy to write a C compiler (the history of C++ is similar, although it has certainly gone off the rails a bit since the early days).

Re:scripting

[davegaramond]

How about demoting the currently "high level" (C/C++ and the likes) languages to medium or low level. By today's standards, they're not very high level anyway.

Re:scripting

[clayne]

What is with the geek pedantry? Geek desire for control.

Re:scripting

[totally bogus dude]

okay, your turn for the perl:

$i += 5;

what's it compile to? Don't forget that the value of $i may be undefined, a string, an integer, a float or a ref.

The GP's point was that the various things that Perl provides can be turned into assembler patterns too. The pattern that += 5 produces would be longer in Perl than in C, as it has to do existence and type checking etc., but it's still a pattern. Just because it's longer doesn't automatically mean it's orders of magnitudes more complicated once you understand it. It's just a bunch of simple things joined together.

Consider a C function add_two_things(val1, val2) which accepts two pointers and returns the result of adding them together. These pointers can point to a variety of different objects: strings, integers, floats, complex data types, or even NULL. This function needs to work out what type of thing both values are, convert them into compatible values, and return the result. You'd have no problem converting this C function into assembly language, right? And if you did, the pattern you'd end up with would be similar to that produced by compiling a Perl $i += 5.

So basically Perl is just higher level than C, in that it saves you writing a whole bunch of code. This is merely because of the definition of the language though. In C, "i += 5;" means "add the integer value 5 to the memory location i" if i is declared as an integer, or "add the floating point value 5.0 to the memory location i" if i is defined as a float. If i is undefined, then it's an error and the language definition says it's invalid code that can't be run.

In Perl, "$i += 5;" means something more like "if $i hasn't yet been defined, define it as an integer 0 and add 5 to it (unless 'use strict' is in effect), otherwise if it's any kind of numeric value add 5 to it, otherwise if it's a string to convert it into some kind of numeric value and add 5 to it". Plus a few other behaviours, probably. The assembly language pattern this produces would be much longer than the C pattern for "i += 5", but that's because they're not in any way equivalent. The assembly produced by add_two_things() would however be similar to the Perl equivalent.

Don't forget: the Perl interpreter is written in C, which implies anything you can do in Perl can be done in C, which implies it can be done in machine language.

Now, if Chandon Seldon was actually arguing that Perl isn't a higher level language than C then he, she, or it is nuts. The claim that Hand compiling is only moderately more complicated for Perl than it is for C depends on how good one is at hand compiling, I suppose. The code will certainly be longer, but all the stuff "$i += 5" does will repeated in any similar operation, and if you're good at assembly you're probably good dealing with big chunks of repeated code. But the difficulty here lies more in the volume of code you need to produce, not the actual production of it.

Re:scripting

[chromatic]

I think "scripting language" refers to the idea that what you write in the program happens in that order.

I don't understand what you mean by this. All of these languages have flow control.

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.

PIR on Parrot runs what's inside the function annotated as :main, but it does so whether the file is text or processed bytecode. Besides that, I could write a C or Java interpreter if I really wanted to which could work on source code.

Re:scripting

[chromatic]

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.

Why not? I've used it for large programs that are still in place. You're reading the output from one of them right now.

(You won't hear me arguing that Slash is and has always been a good example of maintainable Perl code, but you won't hear Cmdr Taco arguing that he's a good example of a programmer either.)

Re:scripting

[shutdown -p now]

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.

This is not correct. The C Standard explicitly requires encoding of integers to be either two's complement or one's complement binary. Which kinda makes sense, since if no specific representation was required, the bitwise operators on integers would be rather useless (because then you wouldn't be able to rely on the fact that (int)0 is all bits reset, and int(1) is first bit set).

Re:scripting

[shutdown -p now]

Even Java gets on my nerves with its static typing.

Do you really mean "static typing", or is it "explicit typing"? Most people are actually annoyed by the latter.

Re:scripting

[Anonymous Coward]

I'd agree, but only if Only if "G for gay to the fucking max" is already occupied.

Re:scripting

[pjabardo]

You do realize that there are such things as libraries?

Re:scripting

[LWATCDR]

You know I have seen big programs written in ASM and Basic as well. Perl has just to many syntactic tricks for me to feel comfortable. And part of it what do you consider a large program. Are you talking 20,000 lines of code or 200,000 lines of code?

Re:scripting

[Frothy Walrus]

You do realize that clicking and dragging a wire from one library to another is easier than gluing them (or anything) together in C? LabVIEW is absolutely not a general-purpose programming environment, but when you want the features it has, it is like the Garden of Eden.

Re:scripting

[Reality Master 101]

This is not correct. The C Standard explicitly requires encoding of integers to be either two's complement or one's complement binary.

You're going to have to quote the standard on this -- I can find nothing that specifies the encoding of integers.

Which kinda makes sense, since if no specific representation was required, the bitwise operators on integers would be rather useless (because then you wouldn't be able to rely on the fact that (int)0 is all bits reset, and int(1) is first bit set).

The logical operators have nothing to do with the representation. As a trivial example, byte ordering of machines can be very different. All that matters is that 1 is 2^0, and 2 is 2^1, and 4 is 2^2, etc. It's a mathematical operation.

Re:scripting

[chromatic]

Are you talking 20,000 lines of code or 200,000 lines of code?

20,000 lines of Perl is a moderately big program. It's probably equal in complexity to at least 250,000 lines of C, perhaps 500,000. Do you count SLOC for CPAN libraries too? Do you count the SLOC for shared libraries used in the C program?

Re:scripting

[shutdown -p now]

You're going to have to quote the standard on this -- I can find nothing that specifies the encoding of integers.

Sure. If we're talking about the classic C89, it's ISO/IEC 9899:1990, section 6.1.2.5 ("Types"):

"The type char, the signed and unsigned integer types, and the enumerated types are collectively called integral types. The representations of integral types shall define values by use of a pure binary numeration system".

The footnote details the meaning, which makes it clear that it is binary notation - i.e. an integer with the first bit set is guaranteed to be equal to 1; the only thing that is unspecified is the representation of signed negative values.

C99 goes further. ISO/IEC 9899:1999 states in 6.2.6.2 ("Integer types"):

"For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit. There need not be any padding bits; there shall be exactly one sign bit. Each bit that is a value bit shall have the same value as the same bit in the object representation of the corresponding unsigned type (if there are M value bits in the signed type and N in the unsigned type, then M <= N). If the sign bit is zero, it shall not affect the resulting value".

It then goes on to detail three permissible ways to encode sign (sign & magnitude, two's complement, and one's complement), and states that is implementation-defined which one of those is used in a specific implementation (but note that, due to explicit description in the Standard, it is possible to detect the method used even at compile time, and a program that does that would still be legal C99).

The logical operators have nothing to do with the representation. As a trivial example, byte ordering of machines can be very different. All that matters is that 1 is 2^0, and 2 is 2^1, and 4 is 2^2, etc. It's a mathematical operation.

I did not even mention the logical operations. I only spoke of left & right shift operators, and the bitwise AND/OR/XOR operators. If you do not know how your integers are represented in binary, certain frequently used cases are no longer guaranteed to be working. For example, (1 << 2) is meaningless if you cannot be sure that the integer "1" is really represented by a single rightmost bit set, and all other bits reset. Note that bitwise shift in C is not a "mathematical operation" of power-of-two - it is a bit shift, defined as such in the standard. The sole reason why it is equivalent to power-of-two is precisely because integer representation is restricted to pure binary.

Re:scripting

[Reality Master 101]

Sure. If we're talking about the classic C89, it's ISO/IEC 9899:1990, section 6.1.2.5 ("Types"): "The type char, the signed and unsigned integer types, and the enumerated types are collectively called integral types. The representations of integral types shall define values by use of a pure binary numeration system".

Hmm. My version of the C89 standard ("The Annotated C Standard, by Schildt, 1990, regarding ANSI/ISO 9899-1990") says:

"The type char, the sign and unsigned integer types, and the floating types are collectively called the basic types. Even if the implementation defines two or more basic types to have the same representation, the are nevertheless different types."

No mention of integral types at all, so it's possible they tightened up the definitions in some later standards (C89 was the last time I cared about the C standard. :)). I'm actually surprised they needed to specify that.

Note that bitwise shift in C is not a "mathematical operation" of power-of-two - it is a bit shift, defined as such in the standard.

According to my version of the standard (which may have changed), it says:

"The result of E1

"The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity, 2 raised to the power E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined."

Granted, it gives the "short version" in terms of bits for easy understanding, but the formal definition is mathematical.

But, based on your quotes, it sounds like they gave up on a lot of the more esoteric portability aspects of C in later versions.

Re:scripting

[Reality Master 101]

Damn! Here's the quote again:

"The result of E1 << is E1 left-shifted E2 bit positions; vacated bits are filled with zeroes. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity, 2 raised to the power E2, reduced modulo ULONG_MAX+1 if E1 has type unsigned long, UINT_MAX+1 otherwise.

"The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity, 2 raised to the power E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined."

Re:scripting

[Anonymous Brave Guy]

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.

That is exceedingly unlikely. It might have been true a decade or two ago, but modern advances in both compiler optimisations and processor design mean those days are long gone. The odds of anyone but a genuinely expert assembly language programmer generating assembly that outperforms a good optimising C compiler are pretty slim these days (unless the compiler in question has an unusually bad flaw in a certain area of its code generator, of course).

Re:scripting

[pjabardo]

I've used labview and while it is easy to connect the output from one control to the input of another it is a whole other business developing anything a little more complicated. It is a nightmare. It is a real mess with all those wires. That's why most people I know make a simple GUI interface and save the data to a file and use some other environment (matlab/octave/scilab/R/etc) to do all mathematical processing. In my opinion labview is great for developing a user interface that controls instrumentation but not much more. The first time a saw LabView, 10 years ago, I was amazed, thought it was great. This lasted until I had to do a little programming. Since we had already invested some time on the thing we kept using it. Fortunately I found out about the possibility to call a DLL and only used LabView for the DAQ and GUI parts only.
I guess labview is very nice to people with very little programming experience and do not feel like learning to program. They are usually the ones that love LabView.
The other day I found out about a labview toolbox that allows the use of scilab functions. This should really improve things for Labview. It will certainly be blessing for anyone trying any thing more than trivial mathematical programming. But without such tools labview is a horrible programming environment with a great set of libraries.
The last few years I've been using R to do data acquisition. Even though there is no GUI it is a great environment for data acquisition and . I had to write the drivers for the DAQ boards and other instruments but since many of those do not have a LabView driver or have lousy LabView drivers, it wasn't much work. But for standard measurements (things we do very often) the lack of an appropriate easy to use GUI is a pain. Paulo

Re:scripting

[nurb432]

But ultimately, that is what they are so why not continue to call them that?

Sure you *can* compile python down and carry it around in binary format, but that isn't the true *intent* of the language so it doesn't count.

Re:scripting

[aevans]

In Perl, $i += 5 doesn't ever, in fact get compiled to assembly. That is the distinguishment. The Perl interpreter handles the expression, it being a program that is currently being executed as machine instructions, and the code it processes is merely parameters. Virtual Machines, such a Java, obscure this a little, since there is a compilation to an intermediary language, but the fact is that the Java virtual machine operates on a series of instructions that are, in part, patterned on machine instructions, and that Perl is pre-processed into a symbol structure before being passed to the interpreter confuse the fact that the difference between programming and scripting is that in the one you are programming the machine, and in the other you a writing a script for a pre-written program to execute.

Re:scripting

[aevans]

No, categorizing languages by how they are executed (whether they are compiled or scripted) is like categorizing vehicles by how they run. You can place a boat on a trailer and roll it down the highway, but that doesn't make it have wheels.

Re:scripting

[totally bogus dude]

I think that's a good and useful distinction, and probably worth leaving it at that.

But, it almost seems like an arbitrary cutoff; there's no particular reason a Perl program couldn't be compiled into native machine code, it's just (much) easier not to. So it's like we're drawing the line between "programming" and "scripting" based on the details of a particular implementation of the operating environment. While that's fair enough, it seems like a pretty pointless distinction.

What happens if someone builds a hardware CPU that executes Java bytecode or that directly interprets and runs the Perl symbol structure. Would that suddenly make them programming languages and not scripting languages?

How about old console games? Aren't they compiled code designed to run on a particular CPU? What happens if they're run on a PC under an emulator? Do they become "scripting" because they're now being run by a pre-written program?

Well, I don't really have anything to add, but I do feel that dividing programming and scripting in that manner doesn't seem quite complete. Not that I can improve on it, of course.

Local man writes script for posterity

[Delusion_]

no body

Re:Local man writes script for posterity

[Delusion_]

Way to miss the joke, guys.

Re:Local man writes script for posterity

[clayne]

Just wait until H-Dog hears about Perl.

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

[joe_n_bloe]

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

[Anonymous Coward]

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

[Otter]

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

[winkydink]

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

[TheLink]

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. :)

Re:Fine by me

[Anonymous Coward]

Vapourware, in other words. A convenient lie that keeps people like you in business until Wall actually manages to -release- something instead of blabber about it.

Too bad that everything Perl 6 will supposedly do whenever it comes out (they're using it as the scripting engine for Duke Nukem Forever incidentally*), Python and Ruby will already have been doing it for quite a while, and doing a better job of it, too.

Re:Fine by me

[bzipitidoo]

I'm not a Perl wizard, but I have used it. I find a lot more limitations than just slowness.

Calling on external C functions from Perl is a pain. You can't ignore all those C functions, there's way too many useful ones out there. There's UNIX system calls, XWindows and higher level GUI libraries, socket and networking stuff, file manipulation, and everything in libc. Perl has a good bit of that covered natively, but suppose you want to use OpenGL? Then you're stuck trying to figure out Frozen Bubble for example. Or you could do it yourself and grind out the XS manually, or fix some automatically generated XS. If you're lucky, someone else has already put together a module, and that module works. Or you say the heck with it and just use C.

Maybe I'm not being flexible, but I found Perl's OOP confusing. The return from a function could be anything from a simple integer to an object that's an instance of a class in a very big ugly hierarchy, and you can't tell what class it is. Lazy undisciplined programmers can very quickly make a horrendous mess. What, some class doesn't have a function called "draw" because it didn't inherit from the correct branch? Just add one, and who cares about keeping the hierarchy sane! I've heard Perl called a "write only language".

Re:Fine by me

[forty7]

Warning: I'm a huge Perl fan. If you don't care, ignore me.

Calling on external C functions from Perl is a pain. You can't ignore all those C functions, there's way too many useful ones out there. There's UNIX system calls, XWindows and higher level GUI libraries, socket and networking stuff, file manipulation, and everything in libc. Perl has a good bit of that covered natively, but suppose you want to use OpenGL? Then you're stuck trying to figure out Frozen Bubble for example. Or you could do it yourself and grind out the XS manually, or fix some automatically generated XS. If you're lucky, someone else has already put together a module, and that module works. Or you say the heck with it and just use C.

XS has a pretty steep learning curve. It's possible to learn to use it effectively, but in my experience that can take some time, and as you point out, "just use C" is often a better choice if you don't want to spend that time.

The return from a function could be anything from a simple integer to an object that's an instance of a class in a very big ugly hierarchy Well, sure, but that's like saying "my $i" might represent an int or a string or a ref at any given time. Of course functions can return any type of value, or multiple values of different types. Or even completely different values and types depending on what context it's called in (whether the caller expects a single value or a list of them). It's a feature of the language.

you can't tell what class it is Sure you can, if you need to. ref($thing) returns a string that represents what type of thing $thing refers to. In the case of blessed references (i.e., objects), that string will begin with the class name. Or better yet, use the 'isa()' method. $thing->isa('My::Type') returns true if $thing is of type My::Type (or some other type derived from My::Type). But it isn't often necessary, because even though they can, functions don't often return different types of values based on some arbitrary criteria.

Lazy undisciplined programmers can very quickly make a horrendous mess. The same is true of any language. No exceptions. Lazy, undisciplined programmers write bad code. They're very capable of doing it in whatever language you care to choose. Sometimes several all at once, if my experience is any guide.

What, some class doesn't have a function called "draw" because it didn't inherit from the correct branch? Just add one, and who cares about keeping the hierarchy sane! Huh? If it didn't inherit one at all, then none of the classes it derives from implemented one. If it inherited the "wrong" one, well, that's a classic problem with multiple inheritance. Any language which supports multiple inheritance will need some mechanism for dealing with the problem.

I've heard Perl called a "write only language". People love to say that, but it's very FUD-like. Well-written Perl isn't any harder to follow, understand, or maintain than well-written code in any language. Poorly written code is hard to understand and maintain, but that's hardly the fault of the language.

Re:Fine by me

[clayne]

Calling on external C functions from Perl is a pain.
[...]
Perl has a good bit of that covered natively, but suppose you want to use OpenGL? Think very hard about those two statements and then read between the lines.

Re:Fine by me

[asuffield]

Calling on external C functions from Perl is a pain. You can't ignore all those C functions, there's way too many useful ones out there. There's UNIX system calls, XWindows and higher level GUI libraries, socket and networking stuff, file manipulation, and everything in libc. Perl has a good bit of that covered natively, but suppose you want to use OpenGL? Then you're stuck trying to figure out Frozen Bubble for example. Or you could do it yourself and grind out the XS manually, or fix some automatically generated XS. If you're lucky, someone else has already put together a module, and that module works. Or you say the heck with it and just use C.

Where have you been for the past five years? Go and read the Inline::C documentation immediately. There is no good reason for writing XSUB any more, unless you're fooling around with the guts of Perl itself.

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

[rubycodez]

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.

Yup... and he doesn't apologize for it

[krog]

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 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

[rubycodez]

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

[Nimey]

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

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

[rubycodez]

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

[rbanffy]

He really annoyed you, didn't he?

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

[Ant P.]

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

[theskipper]

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:Yup... and he doesn't apologize for it

[wiredlogic]

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

Yes. Which is why linguists allowed to design programming languages not should be.

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

[Anonymous Coward]

It already was the computer-language equivalent to English.

It is now moving closer to the sum of all natural languages.

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

[frank_adrian314159]

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

Uh, no. It's like the computer language equivalent of what happened at the Tower of Babel. With line noise. And no hookers.

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

[Anonymous Coward]

The implication being, of course, that other languages are simply rushing out the door full of bugs and other issues, I suppose? Can you name one example of a competitor to Perl in which this has really been the case? Even with the constant state of flux that Ruby is in, they still manage to put out great, functional and stable releases. Funny thing is they don't take decades to do it. Most of them aren't getting paid either. When Matz espouses the changes that will be coming up in later versions of Ruby people at least know that they'll be able to expect them within a decade. Meanwhile the Perl 6 developers are supposedly "getting it right" while the rest of the world forgets about them and moves on, and rightly so. If it's taking them this long to "get it right" then they obviously need better talent on their development team.

No offense, but the whole "getting it right" line is pure bullshit. They're not taking time to get it right, they're simply taking time. Too MUCH time. Not enough of the developers are interested enough in the project to really bear down and get the work done...not their fault, most of them are volunteers. This wouldn't be such a problem if Larry Wall didn't come out of his hole with a "State of the Onion" speech about how great Perl 6 is going to be when it never comes out, making the "work" part of "volunteer work" just that little extra bit more stressful.

Of course he doesn't apologize for it, at the end of the day he's just a mouthpiece that gets too much airtime. Perhaps instead of apologizing he might consider actually doing some fucking coding and make the 12th State of the Onion worth reading. What do we get instead? "Back in the day I programmed on this...Perl 6 will sure be great!"

Fuck Larry Wall. And no, I'm not apologizing either. Perl was once my favourite language, now it's a legacy app at best and a joke at worst.

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

[jc42]

Hey, that's a bet that's really easy to win. As you just did. And your friend can't object, because it's clearly OT.

You should thank the guy who set it up for you.

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

[Mutant321]

You may be right, but I don't think anyone (not even the people working on Perl 6) will know for sure until it's been completed and released for a year or two.

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

[arkane1234]

SQL & COBOL :)

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

[Anonymous Coward]

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.

You should read some of my source code.

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

[rubycodez]

well, I was in my mid-thirties when Perl 6 design was started (36 in 2000 A.D.), but now I'm four years into middle-age, maybe my children will know the answer, heheh.

Back in 2003 there was a blog poster (google alan perl 6 new book site:bleaklow.com) with mock cover of a Perl 6 O'Reilly book with a flying creature designed by a committee on it, on that end of that page you can see wisecrack comment in 2005 that the post and picture were still accurate and maybe Debian would have next release and Hurd would come out before Perl 6. And oh my goodness, both of those really came true, Debian 4 and Debian/Hurd distro came out!

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

[Mutant321]

Up until the last year or two, there wasn't much progress (or at least *visible* progress) on Perl 6. If you look now though, there's a fair bit of tangible work being completed, e.g. Parrot 0.5 was just released, along with the Parrot Roadmap.

As with many OSS projects, the main impediment at the moment is not having enough man hours available to complete the work. But I think it's fairly obvious it's not complete vapourware.

If Perl 6 does everything it says it will, and happens to get it's timing right, it could be huge. It might be the first OSS language to take the sort of status the Java has now, and COBOL used to have. Or it could be of little use to anyone. As I said earlier, I don't think anyone really knows.

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

[rubycodez]

I'll agree parrot is fascinating, and of course the only reason I was spouting off about Perl 6 is because I've used Perl 4 and 5 for many years and I actually do get the Pugs newsletter and follow Perl 6 development. In other words, a part of me actually cares, but I've been hugely dissapointed in what I'm seeing, Perl 6 is trying to be too much.

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

[phaylon]

I can absolutely understand people who don't use free stuff they don't like. I can also understand people who talk about stuff they don't like and say what they don't like. But I could never understand why people are lobbying against stuff others are doing for free on their own time?

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

[chromatic]

But I could never understand why people are lobbying against stuff others are doing for free on their own time?

Those who can, do. Those who can't, tell those who do not to.

In other news...

[nycguy]

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

Re:In other news...

[Ignominious]

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...

[siglercm]

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...

[Anonymous Coward]

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

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

[krog]

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...).

Thanks, and see ya!

[stuntpope]

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!

[kisrael]

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!

[Tomy]

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.

Re:Thanks, and see ya!

[doom]

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

It's not entirely clear what you're getting at here, but this brings up a bit of a peeve with me: we all know that lanugage snobs dislike perl -- why they appear to dislike it more than the far-worse PHP is hard to discern, but clearly they do -- but you shouldn't jump from that to the conclusion that use of perl is dwindling. For example, if you look at CPAN activity, there's a hell of a lot of stuff going on out there, supposedly more-so than during the dot.com era. Or if you look at the features of the upcoming perl 5.10 release, there's a lot of cool stuff being added to perl 5, which continues to be under active development. As far as commercial interest goes, there's a lot of jobs out there using perl and I've heard that perl programmers tend to get paid a little more than Java (one of the disadvantages of following the fads is that you risk becoming a glut on the market).

One of the worse things about Perl 6 is the threat of an "Osborne Effect": a lot of people assume that because it's running late that means that the perl overall is in bad shape, but that's hardly the case.

Re:Thanks, and see ya!

[Fweeky]

Much of what keeps me away from Ruby, in fact, is the Perl resemblance. foo =~ /bar/ and $1 etc are probably the most used Perlish feature in Ruby. While I've never been a fan of Perl, I do appreciate the odd little shortcut like this. Where it's not suitable, there's always md = /bar/.match(foo), md[1], or indeed Regexp.new("bar").

Sigils like @ and $ have only a passing resemblence to Perl; they define scope, and can often be considered a warning sign ($foo -- zomg you're using a global you idiot! @foo -- hey, maybe you'd be better off using the accessor methods?), but they don't require additional thought because they don't change how it behaves; no hashrefs (almost everything's a reference; if you want a copy you .dup it), no scalar/list/hash context and annoying rules about how you get slices or individual elements; it's just an object like any other.

Hmm, what else? There are other magic variables like $: ($LOAD_PATH) and $$ (Process.pid), and the very rarely used $_, which matz has mentioned were probably a mistake, but they're not used much other than the aforementioned regexp ones.

Other unfamiliar syntax probably looks more scary when you see code abusing the Perlishness. Some ugly example code written by an inexperienced newbie certainly put me off trying Ruby for several months.

Re:Thanks, and see ya!

[kisrael]

Well, don't get me wrong: I love Perl and it remains my "goto" language... everything on my own tends to be Perl CGI (and, oy, flatfiles...) but professionally I do Java, lately with a big hunk of "Wicket". (And I worry that my years of exposure to Perl CGI, and the strong mapping with CGI and Hashmaps in the normal HTTP cycle has made me have a hard time getting used to stuff like Wicket that abstracts that away)

My guesstimation that Perl is dwindling was based on A. fewer headhunters who were appearing to be buzzword hunting it and B the cheerleading going on for other languages, from the great mass of PHP users (I started playing w/ PHP before it was ready for primetime, apparently, and while Perl has a lot of quirks, but unlike PHP there are relatively few things that stand out as being that way because it was easier for the implementor of the language to do it that way...) to the folks championing Python (including a recent xkcd) and Ruby (felt a little too much like a Domain Specific Language to me, though being a complete stack was pretty cool.)

So career wise, I dunno, I might be a little too much "street perl" for my own good. But besides being fantastic for small serverside projects and misc. admin-y tasks, it's also a great complement to the stuff like Java, any language that's largely text based.

Re:Thanks, and see ya!

[doom]

I started playing w/ PHP before it was ready for primetime, apparently, and while Perl has a lot of quirks, but unlike PHP there are relatively few things that stand out as being that way because it was easier for the implementor of the language to do it that way...

You mean, except for the complete absence of any namespaces in PHP?

PHP's technical advantages, as I understand it, are (1) a smaller memory footprint; and (2) ISP's seem to feel it's easier for them to support.

I can see how those would be regarded as a win (in some circumstances), but it doesn't explain why the language purists aren't jumping up and down about how PHP is completely unsuited to large projects, and produces maintenance nightmares, and so on.

Re:Thanks, and see ya!

[kisrael]

From a programmer's point of view, PHP's advantages seem to be (1) that whole code-embedded-in-HTML thing, ala JSP or ASP (I feel I get about the same benefit through use of Perl's quoting operator) and (2) pretty much every damn library seems to be baked into the typical PHP install, as opposed to requiring trips through CPAN, and then some challenges installing locally, if you don't have admin privileges on the machine you're renting webspace off of.

When I was playing with PHP in 2002, then, the DISadvantages were stuff like well A, the iterator for an array being a component of that array, something that would need to be reset to walk the array a second time, seemed REALLY odd to me B. and then walking a 2D array was just broken... the PHP programmers tried to pass it off as an oversight in documentation, but really, the documentation described something that made logical sense, and there wasn't an acceptable work around for it.

I do wish Perl had an object model that seemed a bit more sane to me.

Re:Thanks, and see ya!

[Anonymous Coward]

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.

Would have helped if Larry titled his piece that way.

Maybe there are two camps discerned here:

1. Programming languages helps us to do things.
2. Programming languages facilitate literary performance.

Camp 1, to which I belong, appreciate both technical elegance (as in simplicity) as well as literary elegance (but in the literary context), whereas the camp 2 confuses the two. We do not appreciate Newton's work and Eisntein's work for literary elegance. You guys from camp 2 are muddying things up up in the wrong genre.

The worst is that, the whole point of camp 2's elegance, which is to get some fine asses, is wasted. Go to art criticism or some such where your talent would be more rewarding.

Re:Thanks, and see ya!

[moro_666]

my first job was given to me thanks to my perl skills. almost a decade ago. but you don't see me bashing it... why ?

to be honest, your fear or dislikeness of perl as the whole is weird to say the least.

  i have seen perl code that is a beauty compared to a lot of python crap that my eye has spotted, it's all a matter of style and self control. for the last few years i have kept away from both as much as possible.
  python stops to be portable where i need it (if you browse the python docs really deeply you'll start to find a lot of "but"-s in it, also almost every external associative library like python-gtk tends to be stable and available like a striped elephant on a skateboard, mostly you don't have it, and if you get it the version is a mismatch and nothing tends to work as expected) and perl 5.x has a speed and threading issues (aside from ugly as hell 3rd party code).

  just don't generalize things here, there are moments when perl kicks the a** of python without blinking the eye and vice versa, and none of the two is a true king (except of clunky syntax where python just owns everyone).

ps. nice jokes larry, but just throw the comic book aside and give us a working perl 6 ;)

Re:Thanks, and see ya!

[davegaramond]

I do wish Perl had an object model that seemed a bit more sane to me. Moose.

Re:Thanks, and see ya!

[Tomy]

Offtopic? I didn't bring up band camp. I simply implied that reading Perl was like trying to read old BBS systems back in the days of non-error correcting modems. IMNSFHO, Larry still doesn't seem to get that languages like Python and Ruby have surpassed Perl because they are easier on the eyes. Natural language sucks for controlling computers. Look at Appletalk.

The last thing I want to do on Monday is pour over a thousand lines of Perl code trying to figure out what some hack was trying to do.

If this isn't relevant to the conversation per the mods, then may they all write a million lines of Perl and then be forced to maintain it for all eternity.

If that isn't hell I don't know what is. Well maybe like working at Amazon.

Re:Thanks, and see ya!

[chromatic]

Larry still doesn't seem to get that languages like Python and Ruby have surpassed Perl because they are easier on the eyes.

Statistics, please. (Your assertion doesn't match the statistics we're seeing at O'Reilly, surveying job advertisement data and book sales.)

The last thing I want to do on Monday is pour over a thousand lines of Perl code trying to figure out what some hack was trying to do.

s/Perl// in that sentence, or have you never seen the horrors that barely-competent monkeys perpetuate upon the world in any language you tell them to use? (s/(po)ur/$1re/ too, while I'm in a regex mood.)

If this isn't relevant to the conversation per the mods, then may they all write a million lines of Perl and then be forced to maintain it for all eternity.

I've written plenty of Perl in my day, and I don't mind maintaining it. Of course, I know what I'm doing, I practice TDD, I refactor mercilessly, I choose good names....

Re:Thanks, and see ya!

[djberg96]

Statistics, please. (Your assertion doesn't match the statistics we're seeing at O'Reilly, surveying job advertisement data and book sales.) http://radar.oreilly.com/archives/2006/07/ruby_book_sales_pass_perl.html

Outdated now, but I couldn't find a more recent chart, and I couldn't find a job ad survey from O'Reilly anywhere.

Re:Thanks, and see ya!

[chromatic]

Very outdated, and for a period in which the only Ruby on Rails book had just come out and in which there were no new Perl books released. The initial sell-in period of a book's first printing is almost always a huge spike, as sales representatives concentrate on sales into channels for the months leading up to a release, in hopes of generating big frontlist sales and strong potential for backlist sales as the inventory management within the channels shuffles the physical copies to the places where they sell best.

Anyway, I'll grant you that Ruby book sales in one quarter did best Perl book sales. How about the rest of the statistics, showing that people are abandoning Perl and Python in droves for Ruby?

Editing

[Hemogoblin]

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

Re:Editing

[amrittuladhar]

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

[ggvaidya]

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?

Re:Editing

[Anonymous Coward]

He seems to be complaining about starting a sentence with a conjunction ("and", "or", "but", "so", "because", etc.). This is supposed to be discouraged in formal writing; I believe the theory is that if it was allowed, people would overuse it, leading to monotonous writing. You see it all the time in novels and journalism, though, probably because it most closely reflects what the author is trying to say.

See: http://www.gpuss.co.uk/english_usage/start_sentence_conjunction.htm

Re:Editing

[Hemogoblin]

Hmmm, yeah it is a quote. I didn't notice that originally. In any case, it's still difficult to read.

BASIC/PLUS

[Sloppy]

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

[markana]

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

[Suzuran]

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

[rbanffy]

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.

Re:BASIC/PLUS

[sigzero]

Yes but I know who Larry Wall is...that is the difference. : )

Re:BASIC/PLUS

[MichaelSmith]

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.

Back when the alpha came out there were a bunch of old-timers in DECUS Australia looking at a port of RSTS to the alpha. I don't know if anything came of it though.

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

[Anonymous Coward]

Free sushi at your doorstep, for everybody!!!

Tell me again how this is bad?

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

[timster]

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.

Not as funny as usual

[Anonymous Coward]

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.

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

[Ed Avis]

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

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

[krog]

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.

The Camel

[slagheap]

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

Just sayin'...

Perl?

[phlurg]

People still use that??? ;)

Re:Perl?

[Anonymous Coward]

No, they don't, by and large.
Perl died about 5 years ago. Its mindshare has plummeted. Python, Ruby and even Java have stolen Perl's thunder. Back in 1998 Perl was the scripting language of choice, but now there are better alternatives. The same thing has happened to other languages (e.g. Tcl/Tk), and it happened to Perl. C'est la vie.

Did anyone else...

[Gigiya]

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

Re:Did anyone else...

[notque]

No, just you.

Re:Did anyone else...

[BrianRagle]

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...

[AndrewNeo]

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)

Re:Did anyone else...

[doom]

BrianRagle wrote:

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

It's not Larry Wall's fault if someone else is using the same old jokes. A lot of people grew up on Mad Magazine.

I remember the Dragon book...

[WarlockD]

I remember how Fry's discounted the dang thing to 14.98. The Fools.

He's Waiting for Axl Rose

[geoffrobinson]

He's waiting for Axl Rose to put out that new "Guns N' Roses" album.

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

[timster]

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.

High level != "automated memory management"

[Anonymous Brave Guy]

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"

[Anonymous Brave Guy]

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"

[smittyoneeach]

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:High level != "automated memory management"

[Anonymous Brave Guy]

Sorry, my bad. ;-)

Re:High level != "automated memory management"

[heinousjay]

If the reshuffling introduces something many people find useful, who are you to tell them they're wrong?

That's my basic problem with language zealots.

Re:High level != "automated memory management"

[smittyoneeach]

There isn't much need to accuse anyone of being "wrong" in a Turing-complete context; we can fix most wrongness with a sufficiently big hammer.
I'm actually preaching the anti-zealot gospel: languages are means, not ends.

Re:High level != "automated memory management"

[onefriedrice]

> Can we please stop bashing C++ memory management?

That would be nice merely because all the bashing becomes tedious. I would like to say that C++ is probably mostly bashed by idiots who simply don't "get it," but let me instead mention (not to you specifically) how pointless debating relative programming language superiority is because no one language fits every possible use. C++ is great because it's a very complete object oriented language and API (including STL) with a small/fast runtime. It's great for high-performance games. Perl has great support for string manipulation. It's great for reports, web apps, and other tasks. Java/C#/Obj-C support dynamic typing and built-in garbage collection for rapid development. They're great for desktop apps.

The bottom line is just use the tool that is best suited for the job. I wouldn't use C++ for outputting reports when Perl has far better string manipulation. I wouldn't use Perl for my high-requirements 1st person shooter because C++ has better support for objects. Only idiots constantly advocate a single language, and the reason people bash other languages is because they just don't understand, and they're probably too lazy to figure it out.

Re:High level != "automated memory management"

[Anonymous Brave Guy]

Yep, you're absolutely right: generic language wars are generally fairly pointless exercises.

I do think there's a place for objective discussion of the relative merits of languages in different contexts. After all, as you say, we want to choose the best tool for the job. Learning about the experiences of others who have used the tools you're choosing between might help to make a good choice, though of course unless you're planning to write the same program they did, it's not the be-all and end-all.

What I don't like is factually incorrect statements or misleading commentary. These just introduce bias into the picture, and that's the last thing you need if you're trying to evaluate several possible language choices. That's why I dislike all the C++ memory management bashing and equating it with C.

Re:High level != "automated memory management"

[DuckDodgers]

I'd say a scripting language has two other advantages that are both incredibly handy.

1. Your script is your code. You don't need to track your source and your compiled binary code separately. You can't lose the source code for a particular version of your software. During development, you just save your code in your editor (Ctrl-S, :w, whatever) and run it. If you forgot which version of a particular app is on a particular machine and what features it might have, you can just open the files directly in view-only mode and read the change log or the code itself.

2. In addition to their own merits, the first class data structures, first class functions, and dynamic typing all contribute to code brevity. If you can express complex ideas in fewer lines of code while keeping the code easier to understand, I think it improves your productivity and also makes it easier for others to maintain your code. I'm sure there are thousands of C, C++, and maybe even Java developers than can accomplish anything I can do in 20 lines of Perl with 15 lines of their own code. But in most cases, it would be damn difficult to read.

Re:High level != "automated memory management"

[Anonymous Brave Guy]

I'm sure there are thousands of C, C++, and maybe even Java developers than can accomplish anything I can do in 20 lines of Perl with 15 lines of their own code. But in most cases, it would be damn difficult to read.

I doubt it's even true. Languages like C++ and Java are good for very different things than languages like Perl and Python. I suspect it's unlikely that a typical concise, 20-line Perl script could be written in 20 remotely sensible lines of C++, just as it's unlikely than a typical 1M LOC long-term project that can be structured effectively in C++ could be written at all in Perl. In either case, the lesser language simply isn't the right tool for that particular job.

Re:High level != "automated memory management"

[arkane1234]

pointer allocation and malloc issues are the problem. Don't take it too personally, the language problems aren't a hit on your coding style. Just a hit on the usability over multiple people's skills in a group.

Re:High level != "automated memory management"

[Anonymous Brave Guy]

Don't worry, I won't take it personally. :-)

Of course, the reason those things don't affect me very much is that I only use them once in a blue moon when I'm writing some low-level library function. Everything else is built with more powerful types that handle their own memory management, just as you get by default in scripting languages.

Re:High level != "automated memory management"

[DuckDodgers]

I'd argue that some million line C++ projects can be handled just fine by Perl. Perl supports modules, object orientation, threading, etc...

Now if raw performance is a serious consideration, then obviously Perl won't work.

Re:High level != "automated memory management"

[Anonymous Coward]

If someone want garbage collection in C++, just wrap all the pointers in Shared_Ptr. It does ref. counting, so you have gc in C++.

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

[krog]

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.

wanna be annoyed? try this

[wardk]

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??

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

[ajs318]

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

[gardyloo]

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

[timster]

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

[Otter]

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.

Pair programming?

[FlyByPC]

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?

Re:Pair programming?

[phoebusQ]

While pair programming may not win any contests for LOC/hr efficiency, that is not the only measure of such. For some projects, for some people, pair programming provides efficiency gains in bug creation/resolution, on-spec performance, and reduction of dead-end programming. YMMV.

Re:Pair programming?

[sohp]

Pair programming isn't 2 people both trying to use the computer at the same time. Pair programming is 1 person working on writing the code and doing the keyboard tasks while the other person looks on and thinks about what's happening within the context of whatever functionality is currently being added to the code. They talk to each other, help each other notice stupid 1-off errors and typos, and bounce ideas off each other. Every so often, whenever one of them is tired of typing, or the one not typing has an idea that can be more easily expressed by typing out the code rather than talking about it, they switch.

Maybe one of them is a whiz the language and tools, and but is a bit fuzzy on the domain, and the other one is new to the language, but is a domain expert. At first the whiz does most of the keyboard work and the domain expert handles the meta stuff, but gradually they learn from each other and switching off helps them both progress. The domain expert might come to a point where he is trying to explain something complex, so decides to ask for the keyboard and type in some code that does it. It might not be syntactically correct or use the language structure in the best way, but the whiz, looking on, can help clean it up once the ideas are down.

But really, you can't fully appreciate it until you try it with someone with experience in pair programming.

Re:Pair programming?

[HeavyAl]

I didn't know that there was a term that actually defined this methodology. As I was growing up (read: years 12-15 of my life) my friend and I both programmed. He was incredibly talented in the programming language department and I was just as good at putting the project into perspective and correlating goals with current technologies (being the 80's you can probably guess that this ran the gamut from basic, to pascal to C). We would often program together. He would have the keyboard and would fly along typing crazily while I stopped him ever so often to give my input on how something should be implemented or how it would effect the user experience later on.

I know it's anecdotal, but I sincerely wish that today I had someone like him to share my programming responsibilities with. I think together we got more done than we ever did apart (at that time). I would have to say that if you can find someone that you can 'click' with that this is definitely something worth trying.

Re:Pair programming?

[sohp]

It acquired a specific term to encompass the process in order to get through to the PHBs who see two people coding together and say "Hey you two, quit screwing around and get back to your jobs (sitting separately in cubicles, typing)!"

Re:Pair programming?

[johannesg]

Pair programming is one guy who's bored out of his skull staring out the window and occasionally muttering about simple typing mistakes, while the other guy is a walking time bomb with ever-rising blood pressure who will at some point explode into a frenzy of violence that will leave blood splattered against the ceiling.

For example, the guys from the colombine massacre were into pair programming and were in fact pair programming on that fatal day. Lee Harvey Oswald had spent the day pair programming before he shot Kennedy. And 9/11? That's right, 10 teams of pair programmers!

But you are right, in that you cannot fully appreciate it until you try it. Who knows, you could be the next unabomber!

Perl 6 mailing list

[hey]

The summaries ended in 2006...
http://dev.perl.org/perl6/list-summaries/

Does that mean the future is over?

Re:Perl 6 mailing list

[Bill, Shooter of Bul]

No, starting in 2006 the perl 6 community decided to implement perl 6 directly into their frontal lobes. Of course, reading the perl 6 newsletter summaries requires perl 6 to be installed. So first install gcc, then GHC, then pugs, then you can install perl 6 to your frontal lobes and read about whats happening in perl 6.

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

[Anonymous Coward]

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.

Worst presentation in a while.

[harrkev]

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.

Re:Worst presentation in a while.

[doom]

Is it just me, or is this his worst presentation in a while?

Yes, it's just you. Last year's collection of family pictures was way too fluffy, essentially a punt. This year's, by comparison, is an interesting overview of some technical issues, with a few interesting little quips tossed in. It's not as brilliant as his "postmodern computer language" talk, for example, but it's nothing to complain about.

I think the real trouble with these talks is that Larry Wall doesn't really have an overview of the whole onion any more. The perl 5 world is chugging along without him at this point, and he doesn't really know what's going on with it (or he might've said something about pluggable regexp engines, for example), and perl 6, if not exactly stalled out, hasn't had a lot of changes in the big picture of late, so what is there really to say?

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

[Coryoth]

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

[nuzak]

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

Except for actually existing.

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

[doom]

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

[Anonymous Coward]

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

[Anonymous Coward]

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).

As a language designer, I appreciate this paper

[SimBuddha]

I've been designing and implementing a general purpose programming language for many years (in my limited free time) and enjoy studying numerous languages and their good and not so good ideas and fitness for creating a broad range of applications. There are many challenging issues to consider when engaged in programming language implementation. While I am not a Perl/Ruby/Python programmer, I have studied these languages and have used many languages mentioned in the paper professionally. I found the paper to be very insightful, but it really is speaking to other language developers... It might be more useful for the paper to discuss Perl issues from the point of view of various programmers using the language for different applications. Most folks in the audience are more interested in solving problems quickly, reliably, with high performance, scalably and maintably and are less interested in the internal drama that goes on in the heads of language implementors.

From my perspective, I want my language to be approachable by first time programmers age 12+, but capable of building complex professional applications that require assembler and 'C' level performance. My deepest programming language foundations are several assembler languages, 'C', C++, APL, SQL, BASIC, LISP, Prolog, Pascal, Lua, Torque, and JavaScript as well as others. My useage for these has been in constructing spreadsheet recalculation engines, virtualization and dynamic translating processors, educational game simulations, custom business vertical database/financial apps and a host of graphics and system level stuff and some hardware. So I have a bit of a bottom up perspective with some healthy vertical app top down moderation. I love games like "The Incredible Machine" series and engines like The Torque Engine and PhysX. Have you seen the new Crysis game.... unbelieveable.

So in my mind, my language has to be capable of being used to create these types of reliable, networked applications with performance equal to 'C' and assembler, but with the brevity of APL, structure of 'C', Lua or TorqueScript, the platform of TGE and the analytical and transactional power of SQL DBMS. And that is what my language is attempting to fuse together in a sensible manner. Then to provide a "Scratch" or "Lego Mindstorms" application constructor GUI for newbies to use to get started. (ya I know, a huge goal)

I think the biggest challenge facing communities using their favorite language is how to provide useful general direction to the future of the language; like how to simplify it while expanding its overall applicability for an ever wider scope of real world products and a broader programmer/user audience. And as a language implementor, the challenge is how to interpret the needs of programmers and navigate an optimal evolution for the language.

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

[doom]

timster wrote:

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.

Which explains why Lisp is the leading programming used throughout the industry.

The trouble with the line you're taking is that you run into problems with "the waterbed theory of complexity": If you simplify the language, the libraries get more complicated.

On average, do you expect it to be eaiser for an intermediate user to look-up information on an unfamiliar core language feature, or on an unfamiliar library feature?

the provocative larry wall

[doom]

we all know that language snobs dislike perl -- why they appear to dislike it more than the far-worse PHP is hard to discern, but clearly they do

Actually, it occurs to me that I probably do know why perl provokes such rabid responses, I think it's because of "The State of the Onion" talks.

"Larry has turned what was a gentleman's war into guerrilla tactics. He consistently and cleverly (I never said he wasn't brilliant) slanders other languages and language communities, and encourages this behavior in his lieutenants." -- Steve Yegge

I don't know where Yegge got this "gentleman's war" stuff -- when I got started in this game, Nikalaus Wirth was making pronouncements about how a generation of programmers have had their brains irreparably damaged by programming in Basic (and Larry Wall alludes to this in his talk).

I think what's really going on here is that like most "gentleman's" rules, it's only intended to protect you if you're a member of the club. The club got very upset at Wall for daring to suggest that there might be some limitations to their worldview (most "computer scientists" are really mathematicians trying hard to pretend that they're still doing math). That's the really unforgivable thing.

In contrast, the PHP culture is just happy they're doing better than ASP, and makes no explicit philosophical statements about language design.

GENTLE_ART_OF_PROGRAMMING

Put up or shut up, please

[coryking]

I'm disappointed with the state of perl. I used to be a huge perl nut and have a major project that is all mod_perl. But I'm growing increasingly fustrated by the lack of modern programming tools, especially compared to other modern languages. Even PHP has a better choice of editors. Heck, I can write syntax colored, intellesense'd python in Visual Studio!

Perl6 is a text book example of why rewrites are bad. While these people are busy writing the Programming Language to End All Programming Languages, .NET has stolen the market for the very thing these people where trying to make. Pugs, or parrot or whatever, sounds a heck of a lot like .NET/Mono. By the time Perl6 gets out, if it ever does, nobody will care about it because the open source market will be dominated by Mono. At this rate, the perl crew might be better served by just compiling down to MSIL and leveraging Mono for cross-language compilation.

So please, put up or shut up.

See also: Netscape.

Re:Put up or shut up, please

[e. boaz]

I'm disappointed with the state of perl. I used to be a huge perl nut and have a major project that is all mod_perl. But I'm growing increasingly fustrated by the lack of modern programming tools, especially compared to other modern languages. Even PHP has a better choice of editors. Heck, I can write syntax colored, intellesense'd python in Visual Studio!

I'm sorry. I'm not exactly the sharpest knife in the programming drawer and I don't call people out very often ... but what in the hell are you talking about? What the hell does a color syntax highlighting editor have to do with Perl?

On UNIX, both vim and emacs have color syntax highlighting of Perl.

On Mac OS X, you have Textmate (this is the one text editor you need if you script, code, or write web pages on Mac OS X) and many others.

If you code on a Windows box, there's probably something out there for you. . .

And moderators ... why did you mod this inane, semi-educated babble up?

Re:Put up or shut up, please

[coryking]

vim and emacs suck. I build for unix servers but I sure as hell don't use one for my workstation.

I want a perl editor that works like Visual Studio because quite frankly, Visual Studio is the best development tool on the market. I want a perl editor with intellense, good support for perldoc, refactoring tools, and a good enough understanding of the language that I can click on a object's method, I can go "find all references to this function". Good refactoring would be a bonus too.

Eclipse + EPIC seem to do most of this and both seem to be getting more and more stable. The problem is activeperl + mod_perl + windows = trouble, at least in my playing around.

By the way, I'm aware that because perl is a dynamically typed language, most of what I want is very hard if not impossible. I can always dream though...

Re:Put up or shut up, please

[skrolle2]

You are, sadly, wasting your breath. :-(

There is a large amount of programmers who found their comfort zone in certain loosely-typed languages, typically they did a lot of C, moved on to Perl and realized that they were much more productive in Perl, but not really realizing why, only thinking that Perl must be some holy grail. They are programmers who have never used Visual Studio or Eclipse or similar IDEs for strongly typed languages, they have *no* *idea* what refactoring is, and what it can do for your productivity, or how easy it makes your job of reading other's code with functions like "find usage".

They're used to getting no help from their editors, they're used to manual search and replace, and they're used to small-team projects where that kind of tools actually work. And since they're stuck in that comfort-zone with those languages where you *cannot* make tools like VS or Eclipse, they will never learn their power.

The lesson here is that we who use modern IDEs, we will get bypassed by something in the future, and we will be stuck in our comfort zones. Will we move on?

Re:Put up or shut up, please

[Abcd1234]

See also: Netscape.

Err... you mean that which produced one of the most successful alternatives to IE? The one that actually spurred a new round of browser competition? That rewritten project?

I mean, generally speaking, yes, rewrites are bad. But there are almost certainly better examples you could've drawn from.

Re:Put up or shut up, please

[coryking]

People who dont use modern IDE's are living in the stone age. Seriously. It is primitive crap when you cannot find all references to a function. It is primitive crap when your IDE doesn't know about the heirachy of your classes and can show you all the methods you've inherited. It makes programming a pain. The more I get spoiled in Visual Studio, the more I wish I could scrap everything and do it in C#. I love perl, but I hate the tools.

Re:Put up or shut up, please

[coryking]

Yup. But you aren't running netscape are you?

Granted my comparison to netscape is weak, but it is another case of where a rewrite killed them in the market place. Their derivatives (of which I count Firefox) won. In Perl's case it could be argued the derivatives like ruby, python, or *gag* php are winning.

Like netscape when netscape released their newly rewritten application, I fear it will be too late for Perl6. All the derivatives will have taken over.

To go way off, I'd argue perl6 development quite resembles the development on the hurd. Theoretically pure, always shifting in target, but never ready for prime time.

The whole thing is a damn shame, really.

Re:Put up or shut up, please

[jc42]

... programmers who have never used Visual Studio or Eclipse or similar IDEs for strongly typed languages, they have *no* *idea* what refactoring is, and what it can do for your productivity, ...

Heh. I have lots and lots of ideas of what refactoring is. I've worked on a number of projects where the term was used, and in every one, the definition was different. Usually there were groups using different definitions, and wasting a lot of time trying to convert each other to their terminology.

I've concluded that there's a core of a Good Idea in there, but it has been so buried in buzzwordism that it's really hard to spot the Idea.

And most of the cases I've seen where a bunch has done refactoring has produced a mass of write-only code that they didn't even understand themselves. This was obvious from all the bugs that appeared which they couldn't find and fix. Or, more often, we got behavior that was baffling to users, but defended by the developers as how it has to work due to their clever (re)design.

But I don't blame the programming languages for this.

Re:Put up or shut up, please

[davegaramond]

Take a look at Komodo IDE. There used to be a Visual Studio plugin for Perl or something made by the same guys, but due to lack of demand development has ceased.

Re:Put up or shut up, please

[coryking]

How about just consider "refactor" to be a condensed version of "I want to reorganize my code" :-)

It is hard to reorganize your code without a good IDE. Conversely, in my experience it is much easier to generate "write only" code that needs reorganization when you lack an IDE. It doesn't help that perl makes write only code a trivial task :-)

IDE's cut down on the cognitive load and make it easier to visualize what goes where. My perl classes are almost always a mess because I forget what I'm inheriting. To find out, I have to brute force my way through some times dozens of perl modules to get a mental model of what is happening in my codebase. In Visual Studio (and EPIC + Eclipse in perl land to some degree) I see right away what methods I'm inheriting and can just double click to go right to the code.

But yeah... what were we talking about?

Re:Put up or shut up, please

[ctzan]

It's just you who don't know how to use the tools, and stupidely ASSUME that people who are using vi or emacs are 'manually searching and replacing' (which is hilariously incorrect). YOU are probably doing that, and find it easier to do it with click-click and dialog boxes.

Well, I could draw you with pencil and paper the whole structure of any program I've worked on.

The simple idea that the program you're working on is a kind of make where you need smart tools to 'guide' you means you're better finding another job: you're fucking with (and modifying!) things you don't understand.

IDE tools are just like GPS-interactive maps for taxi drivers - they're only useful if the people themselves are off-the-boat novices or hopelessly incompetent.

Re:Put up or shut up, please

[chromatic]

By the time Perl6 gets out, if it ever does, nobody will care about it because the open source market will be dominated by Mono.

Not everyone wants to suckle at the teat of Microsoft hanging out of a Novell uniform.

At this rate, the perl crew might be better served by just compiling down to MSIL and leveraging Mono for cross-language compilation.

Ideas are cheap. Let's see your code. You can find my Perl 6 code all over the Internet. Start with Parrot.

Re:Put up or shut up, please

[Anonymous Coward]

My perl classes are almost always a mess because I forget what I'm inheriting.

Sounds like you're just a shit programmer, or possibly you're using overcomplicated poorly-designed third-party libraries that you don't actually have any understanding of. Seriously, you forget what you're inheriting? And it's all the fault of the IDE?

Re:Put up or shut up, please

[asuffield]

There is a large amount of programmers who found their comfort zone in certain loosely-typed languages, typically they did a lot of C, moved on to Perl and realized that they were much more productive in Perl, but not really realizing why, only thinking that Perl must be some holy grail. They are programmers who have never used Visual Studio or Eclipse or similar IDEs for strongly typed languages, they have *no* *idea* what refactoring is, and what it can do for your productivity, or how easy it makes your job of reading other's code with functions like "find usage".

There is a large number of programmers who have found their comfort zone in glossy editors for certain limited languages; typically they went to a JavaSchool and went on to be an intern. They have it fixed in their head that the world is divided into "programming language" and "editor", and cannot understand why Perl programmers (who do all their work in Perl) don't need a fancy editor.

Perl programmers don't use their editor to perform non-trivial modification or analysis on their code. They use Perl. They would wonder why you could ever need an editor with a stack of limited features for performing certain tasks when you can perform any task you want in a few lines of code.

Re:Put up or shut up, please

[joto]

It's just you who don't know how to use the tools, and stupidely ASSUME that people who are using vi or emacs are 'manually searching and replacing' (which is hilariously incorrect). YOU are probably doing that, and find it easier to do it with click-click and dialog boxes. Well, I could draw you with pencil and paper the whole structure of any program I've worked on.

Actually, I think he had a point. I'm an emacs user myself, and I've certainly done my share of "manually searching and replacing" over the years. And when it comes to the majority of programs I'm working on, I rarely have any clue about what I'm doing, and can certainly not draw you a clarifying picture of anything but the very big picture. And that's the way it has to be when you are working on multiple projects with varying levels of integration. You rarely know more than one of them well.

IDE tools are just like GPS-interactive maps for taxi drivers - they're only useful if the people themselves are off-the-boat novices or hopelessly incompetent.

If you take a great Taxi-driver from Madrid, and put him into a the driver seat of a cab in Quebec, a GPS would be a big productivity booster. Not all of us have the luxury of working on the same program for all of our lives.

Re:Put up or shut up, please

[joto]

By the time Perl6 gets out, if it ever does, nobody will care about it because the open source market will be dominated by Mono.

Not everyone wants to suckle at the teat of Microsoft hanging out of a Novell uniform.

"Not everyone" does in no way contradict "be dominated by". In the limiting case, "not everyone" simply means that you will not use Mono, while everyone else does.

At this rate, the perl crew might be better served by just compiling down to MSIL and leveraging Mono for cross-language compilation.

Ideas are cheap. Let's see your code. You can find my Perl 6 code all over the Internet. Start with Parrot.

Mono is already here, and does useful stuff. I'm sure it's possible to do useful stuff with Parrot and Perl6 too, but so far nobody has done just that. Perl6 is the Duke Nukem Forever of computer languages.

Re:Put up or shut up, please

[skrolle2]

Like I said, it falls deaf ears. If you think modern IDEs are useless "click-click and dialog boxes" and that they are smart tools that guide people, you are mistaken. Emacs and Vi have no semantic understanding of your code. They can't tell two variables apart that have the same name but are in different scopes. They can't show you where a variable was defined. They can't show you where a variable was used. They can't help you rename a variable in its scope. They can't tell you when the interface you are inheriting from changed so that your class now needs to implement one more function. When you read through others' code, you need to read all of it and build a map of it in your head.

Modern IDEs like Visual Studio and Eclipse are tools that help you with all of the above. You still need to know how to program, you still need to know how to structure your programs, but for navigating, changing, and reading code, they help you a lot more than a mere text editor can do.

But you will never realize this, because you are stuck in your comfort zone, you think your text editor has everything in the world one could ask for, and that people who use IDEs are point and click morons who can't really program. I'm so sorry for you. I hope I won't end up like you when something better than IDEs appear.

Re:Put up or shut up, please

[Anonymous Coward]

It is primitive crap when you cannot find all references to a function.

You have to be working in a relatively primitive language, in which references to a function are hard coded, if you expect to be able to find all references to a function.

Re:Put up or shut up, please

[chromatic]

Perl6 is the Duke Nukem Forever of computer languages.

Duke Nukem Forever is written entirely by volunteers for almost no money, and is being developed entirely in public, with the source code available now and forever? Someone tell George Broussard.

Re:Put up or shut up, please

[joto]

I'm shure you know what I was referring to. That one of them is open source and the other is not, is irrelevant in that respect (although I certainly consider the distinction important in other respects, but that was not what I was referring to). I doubt any Duke Nukem fans would be satisfied if 3D Realms released a version of the game as unfinished as the current version of Perl6, even if it was open source.

Look, I'm not against people having fun trying to make Perl6, I'm just a bit tired of hearing people advocating it, when there's still close to nothing to show for it after 7 years of planning and some rudimentary prototyping.

Re:Put up or shut up, please

[chromatic]

I'm just a bit tired of hearing people advocating it, when there's still close to nothing to show for it after 7 years of planning and some rudimentary prototyping.

That's nice.

I'm a lot tired of Internet blowhards thinking that they have all of the brilliant answers to the thorny software development problem of "Good, cheap, or fast -- pick two!" when we've already chosen "Good" and we've never not been able to pick "Cheap". I'm sure I don't have to tell you that Microsoft spent more money on paying the salaries of its Vista developers during their coffee breaks for one week than we've spent on Perl 6 in at least the past three years.

If you have a solution, please join one of the IRC channels or one of the mailing lists and enlighten us. "Code faster", "Stop trying," and "Release something that's not what you want to release nor meets your standards of quality or the reason you started this project," are unacceptable solutions. (See Can't You Just...? and Can't You Just...? redux.)

Re:Put up or shut up, please

[joto]

If you have a solution, please join one of the IRC channels or one of the mailing lists and enlighten us. "Code faster", "Stop trying," and "Release something that's not what you want to release nor meets your standards of quality or the reason you started this project," are unacceptable solutions.

Look, you can do whatever you want to do. I'm not in any way complaining about, or suggesting a better way, to do Perl6 development, as I have absolutely no stake in it, and just don't care anymore. I'm merely pointing out that the Perl6 crowd has, due to the second-system effect, painted themselves into the corner of irrelevancy. If some of the Perl6 people feel offended by that, that's ok by me, as I'm not afraid of offending someone, although it was not my goal in this case.

Re:Put up or shut up, please

[phaylon]

So please, put up or shut up.

Nah, please do it right, rather than doing it quick.

Re:Put up or shut up, please

[phaylon]

Like I said, it falls deaf ears.

You're not exactly a differenciating butterfly either.

When you read through others' code, you need to read all of it and build a map of it in your head.

Oh dear Cthulhu! Thinking! I'm sorry, but you will have to understand the code with either method, unless VisualStudio includes an USB brain-dongle. Now, do you really think you're in the position to tell me if I'm more comfty in dialogs and a GUI, or by reading the code itself?

(Hint: If you do, that's not a good thing)

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

[tuba_ranger]

This attitude is a big part of the problem, IMHO. I have worked with Perl, but have dealt with too many coders who feel they need to "prove" there's another way to do it (or that they know every nook and cranny of a particular part of the language) by using another convoluted way to "do it". If I have the nerve to ask how or why I get flamed for not being a serious enough disciple of the language and told to look it up myself (I even had a colleague tell me that it is his right to do so because I was wasting his time and next time I would think twice before asking). It's the same "if you can't run with the big dogs, stay on the porch" attitude displayed by the parent.

So, If it appears that I don't want to run with the big dogs in Perl, it's because I choose to run with the grown ups over in the Python community.

Awk is pretty clean ...

[wsanders]

... in it's own foul way. But I know what you are saying. MY analogy would be to say that the whole world speaks one language, and if an English-speaker has trouble understanding Chinese, well, then, you just haven't read that part of the manual.

Personally, I take care to write my Perl in grunts and whistles, which are fairly universally understood. Except in those equivalent places where "nodding your head" means "no" and "extending your middle finger" means "hi there!"

You're doing it wrong.

[Anonymous Coward]

If you can rub two thoughts together you'll realize that a group of X-enthusiasts are going to do little else than squabble over the finer points of X. They're not there to help you polish its more obtuse features. Then again, if you could rub two thoughts together you'd have worked it out on IRC with someone, which is exactly why a room full of nerds thought you were the loser: at least they knew what the party was about. Mission statements notwithstanding.

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

[LittLe3Lue]

Sounds like a good episode of 'Does it shred?'

So where IS perl 6, Larry?

[theolein]

Perl 6 has been in development now for some 6 years or so, before I even learnt perl. Since then I have come to love Perl's text handling features, hate Perl's bastard syntax for anonymous hashes and array references and the fact that really simple stuff, like automatic de-referencing of references is STILL not in there, or that array walkers or other features that have been in PHP for years now, are still not there. I hardly ever use Perl now. When I need to shell script, I use Bash (because it works in all Unix environments and I don't have to worry about version 5.6 vs. 5.8 etc), or Python (which has a kinky, but very quick syntax and is very fast). For the web, I still use PHP, since just about everyone and his mother has it installed, or Java, because, despite its atrocious verbosity, has an enormous amount of power in its class libraries and enterprise level tools. I also used ASP on Windows and hated it for its primitive libraries, but loved the simple syntax.

Perl is dying, Larry. New coders and scripters on Unix platforms are learning Python, PHP or Ruby. Windows people have moved to C# en masse. Active State Perl is no longer as powerful as Powershell and is also dying.

There have been God knows how many State of the Onion addresses. None of them have announced a final release of Perl 6. I think that by the time you finally do release Perl 6, Larry, Ruby will have gotten to the point that it runs as fast as Perl does (and the syntax is far, far simpler) and sadly, Perl 6 will not be able to find a niche or enough mindshare to really matter any more.

Re:So where IS perl 6, Larry?

[Anonymous Coward]

judging by the summary traffic still posted to use.perl.org, i would make an guesstimate of 2009 for a beta. they just transitioned ownership of a substantial coder ownership/rewrite project (perl6 on parrot) to patrick michaud...my guess is that it will take him a year to get something useful.

there have been a lot of false starts. pugs was interesting but incomplete, and in any case was never going to be a release platform. there was some perl6-on-perl5 work, which likewise never really materialized as anything useful

in my opinion they did not market the project correctly. they should have called it perl-labs or perl-skunkworks or something else that indicated that this was going to be a place for conceptual discovery, new code ideas, new models, etc. instead they sold it as an engineering project to create the next version of perl...which makes people think they should expect a tarball RSN. i'm not sure people realize how many times this thing has been re-conceived.

they have also had some interesting..."personnel" issues over the years. dan sugalski and audrey tang were people who could have potentially pushed this over the goal line but for one reason or another left the project. i maintained some interest in it all this time, but likely after dan sugalski packed it in, i should have just fired up the python tutorial and moved on.

Re:So where IS perl 6, Larry?

[Anonymous Coward]

You think traffic statistics to the Perl website are indicative of when a release is going to be made?

Excuse me while I go and literally laugh the ass off of my body.

Re:So where IS perl 6, Larry?

[asuffield]

New coders and scripters on Unix platforms are learning Python, PHP or Ruby.

Cite your source.

Don't have one, do you? That sums up your entire post.

Re:wanna be annoyed? try this

[doom]

This doesn't sound anything like the San Francisco Perl Mongers group I hang around with... neither does it sound much like the gang at perlmonks.org.

Sorry if you were traumatized by Tom Christensen, but maybe you need to grow some skin, you know?

Blah, blah, blah.

[Anonymous Coward]

Every one of these "State of the Onion" addresses can be summed up as follows:

1) Perl 6 will be great when it comes out, any day now!
2) Here's how I thought up the great features of Perl 6, which will be out any day now, and how I came up with them!
3) Few stupid jokes and attempts at off-the-wall humour to distract people from the fact that Perl 6 _WON'T_ be out any day now!

How about a progress report? How about why we shouldn't just forget Perl and move onto Ruby and Python, which are actually showing signs of progress, unlike the stagnant bog that is Perl 6/Parrot? How about something for developers to work with, instead of blowing smoke out of your ass like you're some kind of Internet celebrity? Think you could manage any of those, Larry?

Unlikely. There's a better chance of Jesus coming back on Christmas Day than there is of Larry Wall actually doing something useful.

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

[Krishnoid]

A language with a clean design means that you can collaborate with others.

Like English?

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

[krog]

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.

Where do people get the idea that a programmer should be able to work on code -- professionally -- without learning the damn language? And that if this condition is not met, it's the language's fault?

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.

This is not lost on the designers of Perl 6. One of the design goals of Parrot (the bytecode backend to Perl 6) is that it should be able to support many dynamic languages (including Python, Ruby, JavaScript, etc) and that it should be easy to share data and code among them. So for those cases when using another language is the right call, Parrot is on the scene. (Or will be. Someday. Hopefully.)

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.

That is worse-is-better thinking, and like it or not, Perl 6 is an attempt at a better-is-better language. (It sounds so much more eloquent when Larry Wall says it.)

BINGO (Re:the provocative larry wall)

[Anonymous Coward]

Only things worse than Perl are the books/speech by Larry and Co., and their rabid fans. An earlier camel book listed Perl functions alphabetically only - fine reference for those who memorized all the function names. Sane people call that a dictionary.

Damn, now I have to admit Perl has niche where it is rather useful (I've paid my due writing shell/sed/awk scripts across different UNIX variants back in the days, and that's why I know why Perl has its use).

Multiple dispatch

[Webz]

I was wondering if anyone would be so kind as to explain multiple dispatch, as mentioned in the State. What is it that multiple dispatch solves that an if tree that detects object types doesn't do currently?

People keep using asteroids and windows as examples but I still don't understand. I figure collisions would be a function of The Universe and window handling would be written as a function of, well, the window.

Re:Multiple dispatch

[rewt66]

Here's my understanding. (Your mileage may vary.)

Regular polymorphism works like this: I've got a base class B that has a polymorphic function f. I've got derived classes B1 and B2. If I've got an object that is a B, I can call B.f(), and I'll either get B1.f() or B2.f(), depending on whether the object is a B1 or a B2.

But suppose f takes a parameter of type P. And suppose that P is a base class, and I want slightly different versions for f depending on whether the parameter is a P1 or a P2. Then I've got four versions of the f: B1.f(P1), B1.f(P2), B2.f(P1), and B2.f(P2). And I've got a problem. If I've got a B and a P, how do I get the right version of f called?

You can't use function overloading to accomplish this (at least not in C++), because that's done at compile time. It doesn't work if you don't know the types until run time.

In C++, you can do something called "double dispatch". It works like this: You don't call B.f(P). Instead, you call P.g(B), where g is a polymorphic function on P. So if P1's version of g gets called, you know that P is a P1; if P2's version is called, P is a P2. Then g calls B.f(this). Since the type of this is known at compile time, the compiler can distinguish between a call to B.f(P1) and B.f(P2). And polymorphism gets you the correct one of B1.f() and B2.f(). The net result is that the right one of the four possible f() functions is called.

You can start to think about trying to do that with three or four parameters, and you can see why what Larry is talking about - letting the language do it - is a lot better than the way you have to do it in C++.

Re:Multiple dispatch

[davegaramond]

Err, the other guy's explanation might be a bit complex. :-) Here's my attempt: basically you can define two or more subs with the same name but different number/types of args, e.g.: add(Int, Int), add(Float, Float), add(Complex, Complex). the runtime will automatically choose the right sub for you.

We have seen this used in several other places. PostgreSQL comes to mind.

Re:Multiple dispatch

[davegaramond]

And if your language doesn't support it natively, usually there's a library for it, as it's pretty easy to do (just create a wrapper sub which checks the args and choose the right sub).

Re:Multiple dispatch

[joto]

What is it that multiple dispatch solves that an if tree that detects object types doesn't do currently?

Nothing. A computer language is Turing-equivalent, regardless of object-orientedness, or multiple dispatch. Many people like object-oriented languages. Some of those people also happen to like multiple dispatch. Perl, and Perl6 needs to include everything and the kitchen sink, so therefore it also includes multiple dispatch. End of explanation.

People keep using asteroids and windows as examples but I still don't understand. I figure collisions would be a function of The Universe and window handling would be written as a function of, well, the window.

Just like you can always get by without OO, you can always get by without multiple dispatch. It just gets a bit more cumbersome at times. The standard method of getting by without multiple dispatch is to apply the Visitor Pattern. It is also a good place to start reading if you are trying to understand why people want multiple dispatch.

Idiots

[Anonymous Coward]

PHP sucks, and Wall is better than all of you. When you've created a language big enough to whine and complain about, then come whine and complain about Perl.

Bingo.

[2short]

My standard is, when do I expect to be done writing this program?

An hour from now: use a scripting language, maybe Python.

Six months from now, in cooperation with 4 other developers: C++ please.

They're just radically different beasts. Trying to use either in the others role will naught but tears.

C'mon

[Anonymous Coward]

Larry & Co are on the right track, and you know it, really.

perl5 is everywhere and perl6 will be a faster, more flexible, powerful and expressive perl than perl5. My guess is that all *NIX systems will have it in their repos within a week after release, CPAN growth will accelerate, n Linux distros will have new system configuration tools written in it for their next release... and biosciences will find the universal cure for cancer X years quicker ;-)

Now if you want to monitor perl6 developments I recommend grabbing the feeds from Planet Perl Six http://planetsix.perl.org/ and check http://www.perlfoundation.org/perl6/index.cgi for more info.

Larry has an appealing balance between academic beard striking and pragmatism in his ideas and I am sure we will all benefit from perl6. And yes perl6 will be a wonderful mix of cleaned up oddities, new ideas and stolen concepts...

"All Your Paradigms Are Belong To Us"

Re:C'mon

[Anonymous Coward]

I am sure we will all benefit from perl6 Yep, all 11 of you still using perl will. C'mon, perl is dead, and you know it, really.

Languages and user needs

[Rimbo]

One thing I'll say for Wall's writing -- he gets me thinking.

And while he's discussing the new language paradigms we're moving towards and the changes that have occurred, in the back of my mind I'm thinking of the old complaint, that computer hardware keeps getting faster, but the software gets slower, or stays the same.

As a geek, I find that I'm always going to be at odds with salesmen -- assuming the salesman is good at his job. This is true for two reasons. One, salesmen don't really have a grasp of what I do; two, I don't really have a grasp of what a salesman is trying to do. I work on things because they are interesting to me for one reason or another, not because I think these things will make the product more useful to someone else. And good salesmen will know what the customer wants, and are going to be upset when I tell them that I need to refactor the code or rewrite it, which will cause a delay in shipping the feature they've been asking for.

And when I'm looking at what Wall is talking about here, while I agree with the concept that new language features make up for the increased slowness in favor of producing paradigms that make coding easier, I hear this buzzing in my ears that I've heard before: "Why is my 3GHz dual-core PC so slow?"

And when I look at most of the code I've ever seen, what I see is that whenever a language allows people to use a new paradigm, they use it to death. I've seen a lot of Android developers comment on how nice it is that Google doesn't recommend building factories and iterators and accessors for efficiency. And coming back to Java after having been doing embedded C work for a while, I find myself accessing: Well, why would you do it any other way? Why would you use an iterator class rather than a simple integer index, when only on rare occasions you would need anything else?

What it all comes down to is that there needs to be less thought about how various languages do things and more thought about how to do things in various languages.

Ruby screwed up its declaration syntax?

[piojo]

Larry wrote, "Ruby kind of screwed up on its declaration syntax". What is he referring to? Is this what he means by "declaration syntax"?

a=
puts a

Re:Ruby screwed up its declaration syntax?

[chromatic]

Larry wrote, "Ruby kind of screwed up on its declaration syntax". What is he referring to?

Ruby variables automagically spring into existence on first declaration. This happened in Perl 1 - 4 and also Perl 5 by default, though if you use the strict pragma, Perl will warn you about the use of undeclared variable names. (This is why he mentioned the my operator in Perl somewhere near that quote.)

Perl 6 requires variable declarations for everything except one-liners.

The second page

[Joseph_Daniel_Zukige]

Anybody besides me that can't find the second page?

I had to manually change the page parameter on the url to page=4 to get the last page.

Hmmm. page=2.5 seems to get a page between the first and last. I wonder if there are more.

leaky attention span

[epine]

Absolutely. When I program in C++ on top of a sane foundation, I have no expectation of leaking memory any more so than I would in any other language. What I might say, though, is that C++ is a little less tolerant of divided attention. I rarely program in C++ while monitoring IM sessions or RSS feeds. Maybe the proper definition of a scripting language is a language where you can program approximately between the lines while moaning about your weekend hangover to your buddies list.

http://www.rotor.com/portals/12/Safety2002-2006.pdf

Accident rate for helicopters in America is 1 per 100,000 flying hours (11.4 S.R.Hadden-years) and trending downward. This includes the significantly more dangerous reciprocating designs. Few helicopter pilots chat on IM while flying, and only a vanishing minority shows up to work within 48 hours of non-subsistence substance ingestion.

I think C++ partially gets the bad reputation because so many dabblers out there have applied the worse-is-better philosophy to rotor proliferation. It's easy to architect a system in C++ with seven rotors. Not recommended; however, there is nothing to stop you but your own good judgment. Which seems to be the core problem with C++.

Larry is right on the money with his distinction about what a language forces you to say. C++ can become terrifically cumbersome in this department, to the point where C++ is a bad language choice by default unless you know in advance what abstraction C++ brings to the table (with some work) that simplifies your problem domain.

For example, as a C++ programmer I know exactly what Larry was talking about in his dispatch-by-committee passage. You can easily achieve this in C++ (on a compile-time basis for the idiom I have in mind): create a template function that does nothing but dispatch according to any set of rules concerning the types supplied that you can devise (which can be supplied to the template as policy templates, if you wish to do so). These dispatch functions can become ugly creations, but manageable if you are careful and not chatting on IM at the same time.

Personally, I wouldn't code in any multi-dispatch language with a lingering hangover from the previous morning.

One more parting shot about "leakage". It's like Gere's "The gun, the gun, the gun" ditty in Chicago: the purpose of his obsession with the gun is to dim the mind of the jury on related concerns such as motive and opportunity. I don't think about leakage when I'm writing C++ code. I think about correctness, establishing my post-conditions, and not violating my preconditions. Obviously, this can't be achieved if you are programming on top of a hideous library where a complete statement of such is too complex (or too mysterious) to write down for any given routine you need to call. But then you can't write correct code by any metric on top of such a library, so it fails my comprehension that any serious programmer would brag about not leaking memory faced with such an abomination. Many a sailor has drowned going to sea in a ship that never leaked.

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

[jc42]

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.

But it does. Consider the system command, or the `...` syntax. You can even embed code in another language inside a perl program, via the operator.

These ways of invoking a subprocess (that's usually in a different language) was the original reason for calling perl a "scripting language", though reading other messages here shows that there's little actual agreement on what people mean by that phrase.

Anyway, one of perl's original uses was as a replacement for older "scripting languages" such as sh and csh, done in a way that both makes it less often necessary to call a subprocess, and also makes it simpler and more efficient when you do so.

Of course, those of us who have used it from the early days are quite aware that perl 1 and perl 2 weren't at all the powerful, high-level language we have today. Larry's first goal was to simplify the complex tasks that were done with tools like sh, grep and awk, and do them all with a more consistent syntax.

But it did eventually get out of hand, and turn into a real programming language. The good thing was that Larry (and others) discussed this process all along, didn't pretend that it wasn't happening, and applied a lot of the lessons of history to avoid the mistakes of earlier languages. For example, perl got variables with actual types, and builtin operators on those types, at an early stage. Try doing arithmetic in any of the descendants of sh if you don't understand this. And perl has data structures for storing masses of data, doing away with most of the need for temp files (at the cost of using more memory).

Still, invoking subprocesses is a normal part of perl programming, so it has kept its "scripting" roots while it developed a syntax that most people don't want to use as an interactive "shell".

Ruby declarations

[General Lee's Peking]

Am I misreading what he's saying about Ruby? It looks like he's saying that because Ruby doesn't explicitly declare the kind of scoping with which a variable is associated, the scopes of its variables are difficult to understand (it's ``asking for trouble''). And then he says declaring your variables as ``my'', ``our'', and ``local'' makes things much simpler. Am I crazy or does this make absolutely no sense at all? Where I work, I've personally seen struggles taking hours understanding and untangling the effects of those declarations in Perl 5. I have seen few difficulties concerning scoping in Ruby, and those I've seen had been resolved without that much trouble or time.

Re:Ruby declarations

[Anonymous Coward]

If you understand the Perl declarations, they don't take long to figure out at all. Often, spending more time with the language docs is a better investment than staring at code.

The problem with Ruby (and Python) is that there's no way to ask the interpreter to help save you from typos. If you declare a variable %match and then later by mistake refer to it as %matches, Perl will complain loudly (under strict mode in Perl 5), but the equivalent in Ruby will silently create a second variable for you.

Don't get me wrong, I love Ruby, and I'm training myself to use it instead of Perl for any script beyond a few lines long. But I really do miss something akin to Perl's strict feature -- especially with larger scripts. Computers will always be more detail-oriented than programmers, so why not use this to our advantage? Wouldn't that be yet another example of a "higher order" language?

Re: It's sorta liek, but not ...

[Anonymous Coward]

Every year, he describes the state of Perl and its community through metaphor and analogy.

Ya. Tell him to hold off coming back until he thoroughly knows a human spoken language or has some blindingly brilliant transportatiom metphors. I'm totally cooked off on metaphors and analogies at this time in history. Which is to say, all the cybernetic philosophers can wank off their half-formed attitudes on their own time. My time's taken, now and for a long time into the future.

Oh dear

[bob.appleyard]

From the article:

I will say that the continued evolution of the shell shows just how crufty a language can get when you just keep adding on ad hoc syntactic features. PKB! PKB! PKB!!!!

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

[sootman]

Congratulations on the best mental image, evar. And yeah, it's taking a while: here he is talking about Perl 6 over five years ago. (Home of the famous "big knob" quote.)

I wonder how this guy turned out: "Given this approach to learning Perl (just for a general working knowledge, maybe light usage,) is it really worth spending a lot of my time learning Perl now, or should I wait for the big Perl6 revision?" :-)

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

[chromatic]

A language with a clean design means that you can collaborate with others.

That sounds great, until you're trying to work with code written by a barely-competent monkey who has no business sitting in front of a keyboard, or in a business domain where you have absolutely no experience, or any of a dozen scenarios that have a greater influence on maintainability than choice of language.

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

[chromatic]

I've had working Perl 6 code running (and published on the Internet publicly for everyone to see) for two and a half years now. Please try to keep up.

Reads like grade A bullflop

[Anonymous Coward]

His views are so outdated with respect to his review of some languages. Tcl has had a loadable extension mechanism that uses dlopen/dlsym in Unix-like systems, and LoadLibrary, etc. in Windows for over 10 years (perhaps more). The Tcl C API is very similar to Perl's in some respects, with Tcl_Objs, that SUPPORT BINARY DATA. And my, if he only knew how much effort goes into optimizing Tcl's performance...

I wouldn't recommend this article.

The Usual Self-important Nonsense From Wall

[Anonymous Coward]

As usual Wall rambles on self importantly about how much of a linguist he is. The truth is he knows just enough to be dangerous. The proof is right there to be seen in the utter cruft that is Perl5 and the developing pile of steaming poo that is Perl6. Shoving every feature you've ever heard of into a language because you think it is cool shows immaturity and lack of comprehension of the nature of real languages. Real languages don't do that. They tend to simplify over time.

I expect Wall to not know what a scripting language is, but I would have thought at least someone on Slashdot would know better. A script is something which can be run directly by a command-line shell. Not by some other interpreter like perl, php etc. So bash is a shell with a scripting language.

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

[Hognoxious]

Perhaps they're both arguing that there's more than one way to suck?

here you go, bumfuck

[theolein]

sums up your IQ

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

[Anonymous Coward]

Either you didn't understand what I said or you don't understand the concept of language.

Forth isn't actually

[Anonymous Coward]

low-level in that it permits very high level abstractions. (Yes, the lowest level of Forth is very low-level, but that doesn't say anything about the levels of abstractions you can _reach_.)

oh, sorry, i thought you were talking about

[vaporland]

The Onion

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

[JoshJ]

Hey, that explains Duke Nukem Forever...

the meaning of byte poems

[igjav]

scripting languages are stuff that matters, programming languages are stuff that worries

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

[phaylon]

Good for you! But some people prefer to run with the grown ups in the Perl community. Myself included, of course.

Re:wanna be annoyed? try this

[phaylon]

Never happended to me. I find the community as a whole rather helpful and professional. Of course there are always people who can be annoying to someone else. But it's up to you if you're annoyed or just ignore it.

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

[tuba_ranger]

> Good for you! But some people prefer to run with the grown ups in the Perl community. >Myself included, of course. Aye, there are some, I will grant you that. And you are welcome at my table anytime!