Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Perl6's future

Name: Anonymous 2011-02-16 12:29

Hai gais

What do you think will happen to perl6 ???

1) Will have the same fate as Haskell...
2) Python3's snake will eat the Perl6 butterfly
3) Only ParrotVM will be succesfull
4) Perl6 will become the new Java
5) faggot

Name: Anonymous 2011-02-20 6:14

>>40
>>30

Name: Anonymous 2011-02-20 18:16

I don't give a shit about Perl. I can use Python, Ruby, Common Lisp, Scheme, Haskell, even JavaScript, if I want to script. People building real applications (not scripts -- what does ``script'' mean? It's one of those we all understand but can't directly define...) will use a decent high level language, not that steaming pile of shit. Apart from the grammar needing an AI to be parsed, generally being a big stack of special cases that a well-defined core could make trivial, it breeds write-only programming.

I hope that Perl and PHP will be replaced in web development and sysadmin scripting in the next ten years. It seems the failings of Perl 6 will help it along out the door and it will become irrelevant. It has metaprogramming capabilities but so do most languages. I don't even know why they are bothering.

Name: Anonymous 2011-02-20 18:29

>>42
Alright, we get that you're dumb.  That's fine, there are plenty of dumb people and they get along alright.  The question is: why do you want to hang out in a programming community when you don't have the intellect for it?

Name: Anonymous 2011-02-20 18:29

<-- that's cool and all, but check 'em

Name: Anonymous 2011-02-20 18:34

>>42
has metaprogramming capabilities but so do most languages.
Like Ruby, JavaScript and FIOC? No.

Name: Anonymous 2011-02-20 19:33

>>43
Do you have something more interesting to say than "you're dumb"?

Name: >>46 2011-02-20 20:10

>>43
Or is that your way to say ``I haven't read SICP''?

Name: Anonymous 2011-02-20 22:14

>>42
I don't give a shit about Python. I can use Perl, Ruby, Common Lisp, Scheme, Haskell, even JavaScript, if I want to script.
I don't give a shit about Ruby. I can use Python, Perl, Common Lisp, Scheme, Haskell, even JavaScript, if I want to script.
I don't give a shit about Common Lisp. I can use Python, Ruby, Perl, Scheme, Haskell, even JavaScript, if I want to script.
I don't give a shit about Scheme. I can use Python, Ruby, Common Lisp, Perl, Haskell, even JavaScript, if I want to script.
I don't give a shit about Javascript. I can use Python, Ruby, Common Lisp, Scheme, Haskell, even Perl, if I want to script.

<3 Haskell

Name: Anonymous 2011-02-20 22:40

>>42
(not scripts -- what does ``script'' mean? It's one of those we all understand but can't directly define...)
When a (usually interactive) program had a bundled (also usually interactive) programming language that allowed the user to automate tasks to be done with/in that program, those task automations came to be called ``scripts'', and the bundled language a ``scripting language''. Since scripting languages tended to be lightweight (as in having simple interpreters/compilers, not as in being frugal in usage of computing power), dynamic and interactive, over time any interactive, dynamic and lightweight language also came to be called a scripting language.

Name: Anonymous 2011-02-20 23:05

>>40
VALID PERL PERL

Name: Anonymous 2011-02-21 0:32

>>42
What exactly do you think are Perl 6's failings? In a big way it's Haskell-but-really-Lisp with a more convenient syntax.

If people decide they've done that wrong, then it will be a small amount of time before someone gives it a new Setting, and/or grammar. At the very least the Perl 6 grammar system (or something very much like it) is a real need that nothing else is filling. (On a few PL-development mailing lists I'm on, they still talk of keeping the grammar simple so it can be parsed with prehistoric tools.)

Name: Anonymous 2011-02-21 2:29

>>51
I think the time spent developing it is a big problem. The new features are still informally specified or incomplete. Technically it is just starting from scratch with something Perlesque and adding features we all like but in an ad-hoc fashion, but this seems to be the Perl way. Throwing backwards compatibility away is convenient for them but I suspect a large part of reason for using Perl is because there's a lot of code in it already (CPAN), not because it's such a great language. It supports a trivial type system (that is optional, which defies the point if you ask me). Junctions are a curiosity that can be implemented with mere lists or classes in the rare case that one needed such a thing. Again, ad-hoc special cases. Aiming at multiple implementations is disregarding Perl 5's single-implementation strength. The Lisps aimed at mulitple implementations and look at the state of them.

Name: Anonymous 2011-02-21 2:36

>>51
And if it was Haskell it would have a proper, static, powerful type system. Having some ad-hoc lazy constructs doesn't really matter. Clojure has the same.

Name: Anonymous 2011-02-21 3:45

>>52
I think the time spent developing it is a big problem.
That is a problem for using it today but I don't see how it's going to kill it in the end. JavaScript didn't exist when I started programming, yet I enjoy using it today.

Throwing backwards compatibility away
Perl 6 defines a new language, not a new version Perl 5 (which is still being developed, expanded, and getting backported features--if you want a shinier Perl 5 get a new version of Perl 5.) Also, you could make the same argument to some degree about Python 2 vs Python 3.

Not only that, but backwards compatibility is being maintained. There's a means of loading Perl 5 modules, and the spec says (and has always said) any conforming 6 implementation will also execute unmodified Perl 5 sources.

The "gradual" type system is there to permit optimization/analysis, overloading/constraints and type checking to whatever degree is desired. It's optional, sure, but I reflexively use it as much as I can. A lot of others do too. It's a good thing.

Junctions autothread and will dispatch individually in parallel where appropriate. What you say about them makes it obvious you don't know how they work underneath. I don't think they're very important (I don't blame you for not caring or knowing much about them), but the implementation is impressive.

multiple implementations
Nothing wrong with that. C, JavaScript (the weakness here is different amounts and kinds of conformity--not implementations), Python, every successful CLR/DLR language, and so on all have multiple implementations. The Lisp problem is the same as the JavaScript problem, but it's a slightly different world now. JavaScript is successful anyway. As long as implementations keep to the spec (or people can at least write portable code between them without jumping through flaming hoops) it will work out in the end. CPAN incentivizes conformity among implementations anyway. (One thing Perl taught the world: community as technology.)

>>53
The important part to take away from the Haskell comment is the "but-really." It will look like Haskell if you squint from a distance. If you take a really close look you'll find it's more like Lisp. It's not really like either if you look at it too hard. Uh... try not to stare?

Name: Anonymous 2011-02-21 3:45

<-- check 'em dubz

Name: Anonymous 2011-02-21 9:52

(<*>)((<|>)<$>((<|>)<$>(!!0)<*>(!!1)))(!!2)[x<|>y|x<-["om"],y<-(<*>)(:)(:[[]])"-n"]

Valid Haskell code.

Name: Anonymous 2011-02-21 10:52

>>56
U `MENA` Perl6

Name: VIPPER 2011-02-21 13:18

There's a means of loading Perl 5 modules, and the spec says (and has always said) any conforming 6 implementation will also execute unmodified Perl 5 sources.

Im not a language expert, but doesnt this contradict the idea of making a ``new'' language which ``supposedly'' is not backwards compatible and even add up the fact that perl6 is meant to fix the mess that perl5 is?

Name: Anonymous 2011-02-21 13:31

>>58
Any code is valid Perl 6 code.

Name: Anonymous 2011-02-21 14:24

>>58
It would, if any of those things were remotely like the goals of Perl6.  And if there were anything wrong with Perl.

Name: Anonymous 2011-02-21 22:29

>>58
The Perl 6 language does not include Perl 5. The conforming Perl 6 compiler/interpreter will recognize and execute Perl 5 code by some means (emulation, or a Perl 5 grammar or whatever) as Perl 5 code, not as Perl 6 code. You can't just switch to Perl 5 without ceremony for a couple of lines or anything like that.

Loading modules is just a kind of feature like FFI but taken to Perl extremes and should surprise no one, really.

Name: Anonymous 2011-02-21 22:44

>>61
blizkost is the name of the Perl 5 module loader.

Name: Anonymous 2011-02-22 4:18

>>54

That is a problem for using it today but I don't see how it's going to kill it in the end. JavaScript didn't exist when I started programming, yet I enjoy using it today.

I meant that when they're finished coming up with crackpot ideas people it'll be too little too late.

Junctions autothread and will dispatch individually in parallel where appropriate. What you say about them makes it obvious you don't know how they work underneath. I don't think they're very important (I don't blame you for not caring or knowing much about them), but the implementation is impressive.

I had a look at them before writing the post. The data structure as itself is kind of boring. The autothreading is good, of course. There are similar efforts in the Haskell world (DPH). I wouldn't be surprised if there was some overlap there.

multiple implementations
Nothing wrong with that.

We'll see, I suppose. C and JS had the advantage of having inertia already. C was already popular before it had many implementations. JavaScript rode on the back of browsers which were already popular -- it's not like people had a choice to use it. Python, too, has had CPython for a long time. I don't know how long (and I need to get back to work) but I'm pretty sure it was (and still is) the main implementation for a while.

You didn't address the case of Common Lisp, a very old language, which has a standard spec, but which has the shittest implementations ever (though SBCL is getting fairly acceptable these days).

CPAN incentivizes conformity among implementations anyway. (One thing Perl taught the world: community as technology.)

That's a good point -- if it does. How does it do that? Hackage has helped the Haskell community bring its efforts to one place (as I expect Quicklisp will do for CL) but everyone pretty much targets GHC and if it works on Hugs or whatever else then that's nice. I'm with PG that a single implementation that is the default choice is better than an array of choices.

There's a means of loading Perl 5 modules

Doesn't sound great but I'll take your word for it.

Perl 6 has no traction or inertia, no one's using it yet, so how it will overcome the challenges above is a matter of "we'll see", I think.

Name: Anonymous 2011-02-22 11:11

I wonder if there are any operators left that people could want that aren't in perl6

Name: Anonymous 2011-02-22 12:28

>>63
I meant that when they're finished coming up with crackpot ideas people it'll be too little too late.
This argument doesn't really make any sense. It's not like it is hardware that will run too slowly by the time it makes it to market, nor will it be overpriced to pay for all the R&D. As far as PL technology goes, nothing has come along in the past 10 years and filled the niche that Perl 6 is targeting, with the minor exception of some of the feature backports to Perl 5.

I had a look at them before writing the post. The data structure as itself is kind of boring. The autothreading is good, of course. There are similar efforts in the Haskell world (DPH). I wouldn't be surprised if there was some overlap there.
So, you know that they're a lot more than 'just' lists. (It's not the representation which probably isn't even spec'd, it's the implementation.) Few languages could implement them in the same seamless manner without building them in. I wouldn't be surprised about Haskell having them either. I don't think anyone who says "junctions are a must-have feature" without qualification is to be taken seriously so it's not really an important point either way.

You didn't address the case of Common Lisp,
I sort of did: basically the world is different now. I think we could have invented Common Lisp today and gotten different results. The comment about CPAN comes in here, Common Lisp didn't have that...

That's a good point -- if it does. How does it do that?
The short version is Perl needs CPAN. If you can't run the same code (modules) as everyone else your implementation is not going anywhere. On the other hand, the various implementers are all working together. Everyone seems to expect that one implementation or another will take the lead, presently Rakudo seems to be doing that, in a scenario much like GHC. But betting is still open.

Name: Anonymous 2011-02-22 15:00

poo poo dubs

Name: Anonymous 2011-02-22 15:35

>>63
but which has the shittest implementations ever
Really? I've got a handful installed and they're pretty decent. There's so many choices that it's hard not to find what you're looking for.

Name: Anonymous 2011-02-22 17:54

>>67
How do you do sockets and threading in your "decent" implementations?

Name: Anonymous 2011-02-22 18:20

>>68
That's not part of standard CL, however when I do need sockets and threading, I use usocket, iolib (trivial-sockets also works) for sockets and bordeaux-threads for threading, also CFFI and UFFI for any FFI needs. Implementations also provide their own internal FFIs, sockets and threading packages if you don't want to write portable code (which works in the majority of implementations) using the libraries I listed before.

The CL code I've written works on all implementations I use (SBCL, ClozureCL, Lisp-Works and sometimes ECL; on bad days, CLISP). I can't say the same thing about the C code I write (usually either compatible with MSVS or gcc, and tends to have the usual OS-specific #define mess if I want portability, not that I don't use #+/#- reader macros in CL to implement things differently(for example, I could write some SBCL specific optimizations and use a #+sbcl for the SBCL code and #-sbcl for the generally portable version)).

Name: Anonymous 2011-02-23 3:14

That's not part of standard CL

Language of the future amirite?

Name: Anonymous 2011-02-23 4:05

>>70
At the time CL was standardized *nix wasn't even big enough for them to implement unix sockets, and threading was too experimental and platform specific to implement (even though specific platforms did have their implementations). I think it's pointless to argue about this today as long as you have de-facto portable libraries for anything you want, and in the rare event that you don't, making one yourself isn't that hard ( I wrote a smallish one myself, it involved having some macros generate optimized inline asm for certain supported platforms and standard CL for everything else. Perfectly portable, very fast in a few implementations, average/slow in the rest. )

Name: noko 2011-02-23 9:10

OMG!!!!![b][i][u]5+34-23+56*2-54-2 GET!!!!!![/u][/i][/b]

Name: Anonymous 2011-02-23 13:06

>>69,71
TOO LISP; DIDN'T READ

Name: Anonymous 2011-02-23 20:14

>>69
pthreads and UNIX sockets are not in the C standard library. Or regexp. Or anything.

Name: Anonymous 2012-07-29 23:57

>>77

Nice lucky dubs!!!!

Name: Anonymous 2012-07-30 0:10

dubz incombing

Name: Anonymous 2012-07-30 0:18

>>74
threads are in the C standard library.

Name: Anonymous 2012-07-30 0:42

PHP CRITICAL: dubz capture failed. halting thread.

Name: Anonymous 2012-07-30 11:23

5) faggot

Name: Anonymous 2012-07-30 11:27

http://freecode.com/articles/critique-of-where-perl-6-is-heading
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode -