10 ms·

I use Python as my primary scripting language but I spent some time looking at Perl 6 in the context of Parrot and it really has a lot of good ideas that post m

by prog 16y ago

I use Python as my primary scripting language but I spent some time looking at Perl 6 in the context of Parrot and it really has a lot of good ideas that post mentions: - multi-methods - rules (builtin parsing capability) - macros - and a whole bunch of other good stuff. I really made me want to use Perl6 and Parrot. That said the only reason I couldn't what perhaps the same reason I use Python over Perl5. I somehow couldn't get myself to go with such a _rich_ syntax. But if Perl5 is your thing then Perl6 is something that you will definitely like.

stcredzero 16y ago
The industry as a whole errs too much on the side of syntax as the focus of the community. Syntax should fade out of the way. It should be infrastructure, not features. Libraries are the proper object of focus. Libraries can be modified, forked, debugged without dividing a language community. Doing that to a programming language syntax weakens and divides such communities. In contrast, those actions on libraries actually strengthen programming language communities.
- torial 16y ago
  While I agree in general thrust with your focus on infrastructure -- one may argue that a lot of improvements of ignoring language have occurred. .Net allows for multiple languages on a single infrastructure, I believe Java VM does as well, and there is Parrot too. I do think that there is a healthy focus on syntax -- at least my own experience bears it out. It was the syntax of doing things the python way that allowed me to grok polymorphism and MVC despite programming in an OO language for .Net for years. I find that if I want to learn a concept, the syntax is extremely helpful. I also find that if I have to program quickly, syntax being close to how I think is also helpful, and will get frustrated having to make yet another translation of my thought into a syntax that wasn't well thought out. I would also bet that a lot of people find a different syntax to intuitive, and others counter-intuitive than I do. And I'm fine w/ that! Just because there is difference doesn't mean there has to be division!
- loup-vaillant 16y ago
  Syntax has two problems: (1) it is the most visible thing in programming languages, and (2) there is only one per language. I believe we should be able to modify, fork, or debug syntax the same way we do libraries. So what about a syntax meant to be read by computer instead of by humans? # Factorial example, machine syntax fac -> int int \ 0 -> 1 n -> * n - n 1 It could be displayed in human readable form by an IDE or converted back and forth by suitable preprocessors: -- Factorial example, Haskell syntax fac :: int -> int fac 0 = 1 fac n = n * fac (n - 1) // Factorial example, C syntax int fac(int 0) { return 1; } int fac(int n) { return n * fac(n - 1); } No more quibbling over prefix vs infix, curly braces vs indentation, familiarity vs terseness… That would take a flame war away from language design and put it where it belongs: the IDE.
  - jimbokun 16y ago
    I'm pretty sure the C example will not compile with a C compiler. Which may seem like a nit, but the reason is because the semantics of Haskell and C are extremely different. Furthermore, the semantics strongly influence the design of the language. In Haskell, whitespace denotes function application, because the most common thing to do in Haskell is to apply a function. C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. In Haskell, you cannot guarantee the exact order in which things happen without going to great lengths (monads, etc.). In short, I don't think offering a skinnable syntax buys much, and is likely to just generate greater confusion.
    - eru 16y ago
      > C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. Actually that would be an argument for making newlines delimit statements, like in, say, Python. Instead of requiring extra work by the programmer.
      - pyre 16y ago
- arohner 16y ago
  Libraries are heavily influenced by the semantics of the language they're written in / designed for. It's quite easy to see this in the Clojure community today, by Java libraries are good from the clojure perspective. The goodness of a java library has little to do with syntax (because clojure can easily call any java library), but semantics. For instance, java commonly uses mutable state. A fundamental principle of Clojure is that data should be immutable. Immutability makes testing easier, it makes parallelization easier. Clojure was built to make pmap easy. If I have a java library where I have to remember that Foos are thread-safe, but Bars are not, that adds to the incidental complexity of my solution, and reduces my ability to bring Clojure's new tools to bear on the problem. As another commenter pointed out, syntax of a language is heavily influenced by the semantics of the language. A language starts with a few high level principles, and a favorite hammer or two. The syntax of the language is designed around making those common operations easy. Libraries written in that language will tend to follow those same principles. Having Java libraries available to Clojure is a huge advantage, but it's not the be-all end-all, because the semantics of those libraries may be incompatible with your new language. Instead, focus on semantics. Figure out which high level principles are good. What abstractions and design principles result in better, easier to understand solutions? From that follows your libraries and syntax.
draegtun 16y ago
And Perl5 already has some of those features: * multi-methods - There are two implementations on CPAN, Class::Multimethods (old) and MooseX::MultiMethods * rules - Ditto. Perl6::Rules (old) and Regexp::Grammars * macros - Have a look at Devel::Declare. Not Perl6 macros but still powerful stuff! * and a whole bunch of other good stuff - Lots have been backported to Perl5 (direct and into CPAN). For eg. smart match, given/when, Perl6::Junction, Perl6::Gather and also things like Moose & Class::MOP which are heavily influenced by Perl6
- avar 16y ago
  For some value of "already": * multi-methods: MooseX::MultiMethods and MooseX::Method::Signatures add a lot of overhead to subroutine calls (blogged in http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/moosexmethodsignatures-is-really-slow.html http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/...). Sometimes this doesn't matter, but they're certainly not a replacement for having a native type system. All the magic is done at runtime. * rules: Perl6::Rules and Regexp::Grammars are both depended on by a grand total of 0 CPAN modules. They're interesting experiments but not something in use, and not a replacement of rules with its "your regex opcodes are a normal method" model. * macros: Devel::Declare and the B::* modules are usable but they're a long way away from the Lisp model of being able to easily write macros. TryCatch is 800 lines of Perl and C to implement try { ... } catch { ...}. In any Lisp this would be trivially done with a macro in under 50 lines. As for the other stuff pretty much anything except smart match (which is now in Perl 5 core), Class::MOP and Moose falls under the "neat but some combination of: underused, slow, unstable, epic hack nobody wants to use".
  - autarch 16y ago
    Huh, Moose is underused? There a lot of modules on CPAN using Moose, and a lot of modules extending Moose. Also, in what way is Moose unstable? Moose, and modules which use Moose, are used in production at a lot of places (if you use a recent Catalyst, you're using Moose). Edit: doh, totally misread the OP's sentence.
    - 16y ago

by prog 16y ago

stcredzero 16y ago

The industry as a whole errs too much on the side of syntax as the focus of the community. Syntax should fade out of the way. It should be infrastructure, not features. Libraries are the proper object of focus. Libraries can be modified, forked, debugged without dividing a language community. Doing that to a programming language syntax weakens and divides such communities. In contrast, those actions on libraries actually strengthen programming language communities.

torial 16y ago
While I agree in general thrust with your focus on infrastructure -- one may argue that a lot of improvements of ignoring language have occurred. .Net allows for multiple languages on a single infrastructure, I believe Java VM does as well, and there is Parrot too. I do think that there is a healthy focus on syntax -- at least my own experience bears it out. It was the syntax of doing things the python way that allowed me to grok polymorphism and MVC despite programming in an OO language for .Net for years. I find that if I want to learn a concept, the syntax is extremely helpful. I also find that if I have to program quickly, syntax being close to how I think is also helpful, and will get frustrated having to make yet another translation of my thought into a syntax that wasn't well thought out. I would also bet that a lot of people find a different syntax to intuitive, and others counter-intuitive than I do. And I'm fine w/ that! Just because there is difference doesn't mean there has to be division!
loup-vaillant 16y ago
Syntax has two problems: (1) it is the most visible thing in programming languages, and (2) there is only one per language. I believe we should be able to modify, fork, or debug syntax the same way we do libraries. So what about a syntax meant to be read by computer instead of by humans? # Factorial example, machine syntax fac -> int int \ 0 -> 1 n -> * n - n 1 It could be displayed in human readable form by an IDE or converted back and forth by suitable preprocessors: -- Factorial example, Haskell syntax fac :: int -> int fac 0 = 1 fac n = n * fac (n - 1) // Factorial example, C syntax int fac(int 0) { return 1; } int fac(int n) { return n * fac(n - 1); } No more quibbling over prefix vs infix, curly braces vs indentation, familiarity vs terseness… That would take a flame war away from language design and put it where it belongs: the IDE.
- jimbokun 16y ago
  I'm pretty sure the C example will not compile with a C compiler. Which may seem like a nit, but the reason is because the semantics of Haskell and C are extremely different. Furthermore, the semantics strongly influence the design of the language. In Haskell, whitespace denotes function application, because the most common thing to do in Haskell is to apply a function. C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. In Haskell, you cannot guarantee the exact order in which things happen without going to great lengths (monads, etc.). In short, I don't think offering a skinnable syntax buys much, and is likely to just generate greater confusion.
  - eru 16y ago
    > C has semicolon delimited statements, because imperatively executing statements one after the other is a very common thing to do in C programs. Actually that would be an argument for making newlines delimit statements, like in, say, Python. Instead of requiring extra work by the programmer.
    - pyre 16y ago
arohner 16y ago
Libraries are heavily influenced by the semantics of the language they're written in / designed for. It's quite easy to see this in the Clojure community today, by Java libraries are good from the clojure perspective. The goodness of a java library has little to do with syntax (because clojure can easily call any java library), but semantics. For instance, java commonly uses mutable state. A fundamental principle of Clojure is that data should be immutable. Immutability makes testing easier, it makes parallelization easier. Clojure was built to make pmap easy. If I have a java library where I have to remember that Foos are thread-safe, but Bars are not, that adds to the incidental complexity of my solution, and reduces my ability to bring Clojure's new tools to bear on the problem. As another commenter pointed out, syntax of a language is heavily influenced by the semantics of the language. A language starts with a few high level principles, and a favorite hammer or two. The syntax of the language is designed around making those common operations easy. Libraries written in that language will tend to follow those same principles. Having Java libraries available to Clojure is a huge advantage, but it's not the be-all end-all, because the semantics of those libraries may be incompatible with your new language. Instead, focus on semantics. Figure out which high level principles are good. What abstractions and design principles result in better, easier to understand solutions? From that follows your libraries and syntax.

draegtun 16y ago

And Perl5 already has some of those features: * multi-methods - There are two implementations on CPAN, Class::Multimethods (old) and MooseX::MultiMethods * rules - Ditto. Perl6::Rules (old) and Regexp::Grammars * macros - Have a look at Devel::Declare. Not Perl6 macros but still powerful stuff! * and a whole bunch of other good stuff - Lots have been backported to Perl5 (direct and into CPAN). For eg. smart match, given/when, Perl6::Junction, Perl6::Gather and also things like Moose & Class::MOP which are heavily influenced by Perl6

avar 16y ago
For some value of "already": * multi-methods: MooseX::MultiMethods and MooseX::Method::Signatures add a lot of overhead to subroutine calls (blogged in http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/moosexmethodsignatures-is-really-slow.html http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/...). Sometimes this doesn't matter, but they're certainly not a replacement for having a native type system. All the magic is done at runtime. * rules: Perl6::Rules and Regexp::Grammars are both depended on by a grand total of 0 CPAN modules. They're interesting experiments but not something in use, and not a replacement of rules with its "your regex opcodes are a normal method" model. * macros: Devel::Declare and the B::* modules are usable but they're a long way away from the Lisp model of being able to easily write macros. TryCatch is 800 lines of Perl and C to implement try { ... } catch { ...}. In any Lisp this would be trivially done with a macro in under 50 lines. As for the other stuff pretty much anything except smart match (which is now in Perl 5 core), Class::MOP and Moose falls under the "neat but some combination of: underused, slow, unstable, epic hack nobody wants to use".
- autarch 16y ago
  Huh, Moose is underused? There a lot of modules on CPAN using Moose, and a lot of modules extending Moose. Also, in what way is Moose unstable? Moose, and modules which use Moose, are used in production at a lot of places (if you use a recent Catalyst, you're using Moose). Edit: doh, totally misread the OP's sentence.
  - 16y ago