4 ms·

Author of the article here. > parsing text files is literally the only thing Perl is the best tool for To be honest, Ruby has built-in regexps also and Rebol

Author of the article here. > parsing text files is literally the only thing Perl is the best tool for To be honest, Ruby has built-in regexps also and Rebol has built in recursive descent parsing (and has no regexp support at all). So I disagree with you on two counts, the first is that Perl is the best tool always for parsing text files. To some extent it depends on what you are doing. What I do think that Perl is really good at is building frameworks and the reason here is that what you can do (and what I highlighted in the article) is create mini-dsl's for common tasks which can then be seamlessly worked into the general purpose programming environment. Lisp can do this too, as can Rebol, but these each have other tradeoffs (I found the Lisp learning curve to be rather steep, Rebol 2 is not open source, Rebol 3, though open source, is still in alpha, and has no Linux GUI support yet). > But as a tool to be learnt, it wouldn't be the 'best' tool for a new person to learn from scratch. I don't know that there is a best tool for a new person to learn from scratch. One should generally apply tools I think with an intent of doing something with them. IMO, Perl excels at very big projects and very small projects. It's in the middle that things get less than ideal.

danellis 13y ago
Don't languages with native MOPs, such as Python and Ruby, create better internal DSLs than Perl?
- kbenson 13y ago
  The best I've come up with so far searching for information on MOPs (of the explicit, controllable sort) in those languages is sort-of/almost for Ruby and no for Python. Is there some other name they go by in those languages that I should be aware of?
  - danellis 13y ago
    In Python the actual features that implement that would be metaclasses and descriptors.
- einhverfr 13y ago
  > Don't languages with native MOPs, such as Python and Ruby, create better internal DSLs than Perl? Why would you say that? It seems to me that a DSL's function is at least reasonably decoupled from the method it uses behind the scenes, and that there is no real difference between a native MOP (like that in CLOS -- I don't really see an equivalent in Python or Ruby) and a non-native one like Class::MOP in Perl in this regard.
  - danellis 13y ago
    > Why would you say that? It helps you strip out code that isn't related to the DSL. For example, the mechanisms of class definitions in things like MongoEngine or Django's ORM. You end up with something that looks a lot more declarative.
- draegtun 13y ago
  Nope. * Some of the best languages for producing an internal DSL (dialects) don't have a "native MOP". For eg. Lisp, Rebol or Forth. * Python & Ruby don't have native MOP's anyway :) NB. I wonder what you mean by "native MOP" is baked-in OO? Python & Ruby OO systems do come with MOP like abilities. However for full blown (metacircular) MOP (http://en.wikipedia.org/wiki/Metaobject#Metaobject_protocol http://en.wikipedia.org/wiki/Metaobject#Metaobject_protocol) you need to look at things like CLOS & Perl's Moose/Class::MOP.
  - danellis 13y ago
    By "native MOP" I really mean things like Python's metaclasses and descriptors (and whatever Ruby's equivalents are called), as opposed to an add-on library to simulate them like Moose.
    - draegtun 13y ago
      A bit of apple & oranges going on here because you don't need Moose (or more precisely Class::MOP) to simulate Python metaclasses and descriptors. Because you could, if you so wished, build a Python metaclasse/descriptor based OO system in Perl's native OO. To clarify things: * Python comes with a pre-defined OO system with metaclasses/descriptors for dynamically building new Python classes/objects. * Perl comes with OO lego blocks from which you build you own OO system. * Class::MOP is a metacircular MOP mainly written in Perl using these lego blocks (it's turtles all the way down). * A MOP (like Class::MOP) provide an API for building & managing extendable OO systems. * Moose is an advanced OO system built on Class::MOP. * Moose provides features like Roles, Method Modifiers, lazy attributes and many more. There have been two attempts, that I know of, to bring (a subset of) Moose to Python: https://pypi.python.org/pypi/bullwinkle/0.3.6 https://pypi.python.org/pypi/elk/0.2 There have been many clones of Moose to other languages as well, including Ruby (multiple clones/ports), Javascript & Lua. For something comparable to Moose/Class::MOP then have a look at CLOS (Lisp).
draegtun 13y ago
>Rebol 3, though open source, is still in alpha, and has no Linux GUI support yet Just to note that the first beta version of the Linux GUI for Rebol 3 was released a couple of weeks ago - http://atronixengineering.com/downloads.html http://atronixengineering.com/downloads.html
- einhverfr 13y ago
  How could I miss this? Awesome! Edit: It looks like that is Saphiron's repo, not the main one, so still waiting on it becoming an official build, I see :-P
  - draegtun 13y ago
    Yes that's correct. Atronix efforts have been towards producing 64-bit versions + the Linux GUI from the Saphiron code base (which was 32-bit and Windows GUI). Here's the Atronix announcement - http://rebol.info/altme/105/announce#msg0688 http://rebol.info/altme/105/announce#msg0688 I believe you can consider this as the official build for Rebol3 View/GUI because Saphiron took over the RebGUI/R3-GUI project from Rebol Technologies. But yes some of the Rebol 3 Core stuff that Saphiron/Altronix have done do need merging back into main open source core [1], which itself as moved on from the Saphir codebase (Saphiron Rebol build) [2]. [1] - https://github.com/rebol/rebol https://github.com/rebol/rebol [2] - https://github.com/saphirion/saphir https://github.com/saphirion/saphir Also see Rebolsource repo where lot of the community changes go before merging back into [1]. Ref: https://github.com/rebolsource/r3 https://github.com/rebolsource/r3 | http://www.rebolsource.net http://www.rebolsource.net PS. I know that you're aware of some of this info. Posting for the eyeballs of others :)

danellis 13y ago

Don't languages with native MOPs, such as Python and Ruby, create better internal DSLs than Perl?

kbenson 13y ago
The best I've come up with so far searching for information on MOPs (of the explicit, controllable sort) in those languages is sort-of/almost for Ruby and no for Python. Is there some other name they go by in those languages that I should be aware of?
- danellis 13y ago
  In Python the actual features that implement that would be metaclasses and descriptors.
einhverfr 13y ago
> Don't languages with native MOPs, such as Python and Ruby, create better internal DSLs than Perl? Why would you say that? It seems to me that a DSL's function is at least reasonably decoupled from the method it uses behind the scenes, and that there is no real difference between a native MOP (like that in CLOS -- I don't really see an equivalent in Python or Ruby) and a non-native one like Class::MOP in Perl in this regard.
- danellis 13y ago
  > Why would you say that? It helps you strip out code that isn't related to the DSL. For example, the mechanisms of class definitions in things like MongoEngine or Django's ORM. You end up with something that looks a lot more declarative.
draegtun 13y ago
Nope. * Some of the best languages for producing an internal DSL (dialects) don't have a "native MOP". For eg. Lisp, Rebol or Forth. * Python & Ruby don't have native MOP's anyway :) NB. I wonder what you mean by "native MOP" is baked-in OO? Python & Ruby OO systems do come with MOP like abilities. However for full blown (metacircular) MOP (http://en.wikipedia.org/wiki/Metaobject#Metaobject_protocol http://en.wikipedia.org/wiki/Metaobject#Metaobject_protocol) you need to look at things like CLOS & Perl's Moose/Class::MOP.
- danellis 13y ago
  By "native MOP" I really mean things like Python's metaclasses and descriptors (and whatever Ruby's equivalents are called), as opposed to an add-on library to simulate them like Moose.
  - draegtun 13y ago
    A bit of apple & oranges going on here because you don't need Moose (or more precisely Class::MOP) to simulate Python metaclasses and descriptors. Because you could, if you so wished, build a Python metaclasse/descriptor based OO system in Perl's native OO. To clarify things: * Python comes with a pre-defined OO system with metaclasses/descriptors for dynamically building new Python classes/objects. * Perl comes with OO lego blocks from which you build you own OO system. * Class::MOP is a metacircular MOP mainly written in Perl using these lego blocks (it's turtles all the way down). * A MOP (like Class::MOP) provide an API for building & managing extendable OO systems. * Moose is an advanced OO system built on Class::MOP. * Moose provides features like Roles, Method Modifiers, lazy attributes and many more. There have been two attempts, that I know of, to bring (a subset of) Moose to Python: https://pypi.python.org/pypi/bullwinkle/0.3.6 https://pypi.python.org/pypi/elk/0.2 There have been many clones of Moose to other languages as well, including Ruby (multiple clones/ports), Javascript & Lua. For something comparable to Moose/Class::MOP then have a look at CLOS (Lisp).

draegtun 13y ago

>Rebol 3, though open source, is still in alpha, and has no Linux GUI support yet Just to note that the first beta version of the Linux GUI for Rebol 3 was released a couple of weeks ago - http://atronixengineering.com/downloads.html http://atronixengineering.com/downloads.html

einhverfr 13y ago
How could I miss this? Awesome! Edit: It looks like that is Saphiron's repo, not the main one, so still waiting on it becoming an official build, I see :-P
- draegtun 13y ago
  Yes that's correct. Atronix efforts have been towards producing 64-bit versions + the Linux GUI from the Saphiron code base (which was 32-bit and Windows GUI). Here's the Atronix announcement - http://rebol.info/altme/105/announce#msg0688 http://rebol.info/altme/105/announce#msg0688 I believe you can consider this as the official build for Rebol3 View/GUI because Saphiron took over the RebGUI/R3-GUI project from Rebol Technologies. But yes some of the Rebol 3 Core stuff that Saphiron/Altronix have done do need merging back into main open source core [1], which itself as moved on from the Saphir codebase (Saphiron Rebol build) [2]. [1] - https://github.com/rebol/rebol https://github.com/rebol/rebol [2] - https://github.com/saphirion/saphir https://github.com/saphirion/saphir Also see Rebolsource repo where lot of the community changes go before merging back into [1]. Ref: https://github.com/rebolsource/r3 https://github.com/rebolsource/r3 | http://www.rebolsource.net http://www.rebolsource.net PS. I know that you're aware of some of this info. Posting for the eyeballs of others :)