4 ms·

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific lan

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I've always enjoyed Perl as a language. But I walked out of that presentation thinking "That was so beautiful, and I don't want it anywhere near my business." Because the last thing I need is software written in a language I can't hire anyone else to maintain. At some level that's what I think has happened to Perl in general. I never liked Python much, until I got forced to use it on a new team. Now I'm convinced that it has a really distinct advantage -- there aren't too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. But Perl programs are frequently art pieces that take a lot of effort to truly grok.

cestith 4y ago
Perl6 is now of course Rakulang. https://raku.org/ https://raku.org/ The folks responsible for that are still growing and improving their own ecosystem. It's a Perl-family language but it's different enough that they stepped away from the name so both Perl and Raku can flourish.
svachalek 4y ago
This is one thing I'm certain of after 40 years of programming: successful programs will need to be read more often than they are written. Language features that make programs cool or fun or "easy" to write are generally counter-productive to readability. Even things like this that are meant to make a program "expressive" are in fact just gimmicks if they are unique to one program. Features that make a language expressive in a consistent way are very valuable though. Python is a good example of this, even people who don't know anything about Python can generally read a Python program.
giantrobot 4y ago
> I never liked Python much, until I got forced to use it on a new team. Now I'm convinced that it has a really distinct advantage -- there aren't too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. This is why I picked up Python many years ago. I had been using Perl 5 for my scripting and system administration needs. While it worked just fine any project larger than a few hundred lines needed a lot of discipline to keep maintainable. Perl encouraged too many line noise shortcuts, reading unfamiliar code was too often an exercise in looking up uncommon operators. It's elegant when writing but frustrating when reading. Python not only read a bit more like it executed but didn't lend itself to unreadable shortcuts. If your code is elegant to write it tends to be straightforward to read. When Perl 6 was still Perl 6 the DSL stuff sounded interesting until like you I realized it would just turn large projects into unreadable messes. It wouldn't help the small Perl scripts be more readable nor would it help the large projects be more maintainable.
- agumonkey 4y ago
  beware, when reading django faux-metaclass based declarative ORM it feels not very far from a bad DSL. In the end you have no clue about what's what or the meaning of things.
- MadWombat 4y ago
  "It's elegant when writing but frustrating when reading" As a person who used to use Perl 5 rather extensively back in the day for all sorts of things, I fondly remember the joke that Perl is a "write-only language" :)
  - giantrobot 4y ago
    I'd joke about Perl 5 being write-only until I had to go read my own code from only months prior. I would get so mad at myself for making it so hard to follow but then for expediency I'd go and do the same damn thing in the current batch of code. Then months later curse myself. I've opened Perl files that I swear had bitrot but nope, not corruption, just a bunch of sigils and weird operators.
didip 4y ago
Everything you loved about Perl is exactly why I hate it. The syntax noise is too great and it has too many ways for people to be too clever with it.
- rootusrootus 4y ago
  I totally agree. That's why I loved it for me, but hated it if I ever had to deal with someone else's code. And why I never use it any more, unless I'm doing a bunch of text processing on my own workstation.
foobiekr 4y ago
The problem is, as appealing as building a DSL (in or out of another language) is to engineers, turning your source base into a pool of pidgins where there are no native speakers and all new hires or people moving between parts of the code base will need to learn a new language is not an advantage. It is completely unnecessary friction. We all get this when we encounter jargon-crazy groups, but somehow forget it when it comes to code.
- astrobe_ 4y ago
  OTOH an application does have its own language. Someone said "When you devised an application you wrote a hundred words [(functions)] or so that discussed the application and you used those hundred words to write a one line definition to solve the application. It is not easy to find those hundred words, but they exist, they always exist." I think for non-trivial programs it is not avoidable to have to learn first the terminology of the domain and the terminology of the program (how things were named when it was not dictated by the language of the domain). However, hacking the syntax of the language is a whole different story, and perhaps that's where DSL-ready languages go wrong. That's ironic coming from someone that just quoted the author of a language that has no syntax to speak of, and macro powers that are sometimes compared to Lisp macros. Just use them wisely, one would say, but that kind of wisdom comes with experience.
baq 4y ago
you've also described the reason lisp ultimately failed IMHO - it's selling point is creating first-class DSLs, but you can't hire anyone experienced in the DSL you've got...
- bombcar 4y ago
  Being skilled in Lisp or other DSL producers can be amazing for one-man projects. Above that sticking with standard languages really is useful. I remember seeing a "DSL cycle" somewhere - http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...
- kazinator 4y ago
  There is no such thing as a software shop with no local DSLs, in any language. All the in-house abstractions constitute DSLs. Without syntactic abstraction (function and data only), things are worse, because those abstractions have to be coordinated together into proper usage scenarios, and those are written by hand in multiple places. So you're looking at eye-glazing repetitions. Oh, and just because a language doesn't have macros doesn't mean you won't see any syntax-level DSL. You may find textual code generation in a project in any language. C++, Go, Java, you name it. Understanding a large amount of unfamiliar code is a challenge no matter how it is organized. Whether it uses syntactic abstraction is a minor factor, and it is not an iron clad truth one way or the other whether that helps or hurts. If you can learn a complex API where you have to take several kinds of objects through a multi-step workflow, you can probably learn a syntactic construct that does it for you; especially if it is documented and has test cases. You will never hire anyone who is experienced in the vocabulary of your code base, unless it was someone who was previously laid off.
- cutler 4y ago
  Nubank is built exclusively in Clojure, proving large-scale projects can be developed with a Lisp. Same goes for Paul Graham and Viaweb.
chrisseaton 4y ago
I think Perl fell victim to a huge change of fashion around the 2000s. 'There's more than one way to do it' and the whimsical, deliberately slightly obtuse design of Perl used to be what people valued. Then something happened (perhaps it was how people started building much larger apps in 'scripting' languages, to use an out-dated term) and I think to most people under 35 deliberately having 'more than one way to do it' sounds like an atrocious idea and something they don't want anything to do with. Same with linguistic whimsy in their language design - they don't want to have to look up why a method to do with objects is called 'bless' for example. Look at the success of languages like Go, which are the polar opposite of Perl's philosophy.
- agumonkey 4y ago
  Interesting question, maybe computing was still a wildlife space to explore and 'more than one way' was felt like a challenge in creativity.. then the field decided it had to become industrial (the term that comes to mind thinking about all the professors talking about UML, diagrams, build swap-in packages like ICs) and suddenly, standardization is the only way.
- polynomial 4y ago
  And then there was the rise of Javascript, which also allows for many many ways of doing the same thing.
  - chrisseaton 4y ago
    Hmmm I'm not sure I think so? JavaScript is a pretty simple and compact language. Referencing object fields yes... but that's because of a uniform model of arrays and objects afforded different syntaxes. That's not really what I mean.
- goto11 4y ago
  Perl is a great language if you are a single developer. I think there is some "reverse network effect" for Perl, where people might enjoy writing in the language but nobody enjoys having to maintain Perl written by someone else. So basically you don't encourage others to use it.
deleted 4y ago
[deleted]
wwweston 4y ago
Do you remember the title or any other details of Conway’s presentation? I’d like to look for this.

cestith 4y ago

Perl6 is now of course Rakulang. https://raku.org/ https://raku.org/ The folks responsible for that are still growing and improving their own ecosystem. It's a Perl-family language but it's different enough that they stepped away from the name so both Perl and Raku can flourish.

svachalek 4y ago

This is one thing I'm certain of after 40 years of programming: successful programs will need to be read more often than they are written. Language features that make programs cool or fun or "easy" to write are generally counter-productive to readability. Even things like this that are meant to make a program "expressive" are in fact just gimmicks if they are unique to one program. Features that make a language expressive in a consistent way are very valuable though. Python is a good example of this, even people who don't know anything about Python can generally read a Python program.

giantrobot 4y ago

> I never liked Python much, until I got forced to use it on a new team. Now I'm convinced that it has a really distinct advantage -- there aren't too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. This is why I picked up Python many years ago. I had been using Perl 5 for my scripting and system administration needs. While it worked just fine any project larger than a few hundred lines needed a lot of discipline to keep maintainable. Perl encouraged too many line noise shortcuts, reading unfamiliar code was too often an exercise in looking up uncommon operators. It's elegant when writing but frustrating when reading. Python not only read a bit more like it executed but didn't lend itself to unreadable shortcuts. If your code is elegant to write it tends to be straightforward to read. When Perl 6 was still Perl 6 the DSL stuff sounded interesting until like you I realized it would just turn large projects into unreadable messes. It wouldn't help the small Perl scripts be more readable nor would it help the large projects be more maintainable.

agumonkey 4y ago
beware, when reading django faux-metaclass based declarative ORM it feels not very far from a bad DSL. In the end you have no clue about what's what or the meaning of things.
MadWombat 4y ago
"It's elegant when writing but frustrating when reading" As a person who used to use Perl 5 rather extensively back in the day for all sorts of things, I fondly remember the joke that Perl is a "write-only language" :)
- giantrobot 4y ago
  I'd joke about Perl 5 being write-only until I had to go read my own code from only months prior. I would get so mad at myself for making it so hard to follow but then for expediency I'd go and do the same damn thing in the current batch of code. Then months later curse myself. I've opened Perl files that I swear had bitrot but nope, not corruption, just a bunch of sigils and weird operators.

didip 4y ago

Everything you loved about Perl is exactly why I hate it. The syntax noise is too great and it has too many ways for people to be too clever with it.

rootusrootus 4y ago
I totally agree. That's why I loved it for me, but hated it if I ever had to deal with someone else's code. And why I never use it any more, unless I'm doing a bunch of text processing on my own workstation.

foobiekr 4y ago

The problem is, as appealing as building a DSL (in or out of another language) is to engineers, turning your source base into a pool of pidgins where there are no native speakers and all new hires or people moving between parts of the code base will need to learn a new language is not an advantage. It is completely unnecessary friction. We all get this when we encounter jargon-crazy groups, but somehow forget it when it comes to code.

astrobe_ 4y ago
OTOH an application does have its own language. Someone said "When you devised an application you wrote a hundred words [(functions)] or so that discussed the application and you used those hundred words to write a one line definition to solve the application. It is not easy to find those hundred words, but they exist, they always exist." I think for non-trivial programs it is not avoidable to have to learn first the terminology of the domain and the terminology of the program (how things were named when it was not dictated by the language of the domain). However, hacking the syntax of the language is a whole different story, and perhaps that's where DSL-ready languages go wrong. That's ironic coming from someone that just quoted the author of a language that has no syntax to speak of, and macro powers that are sometimes compared to Lisp macros. Just use them wisely, one would say, but that kind of wisdom comes with experience.

baq 4y ago

you've also described the reason lisp ultimately failed IMHO - it's selling point is creating first-class DSLs, but you can't hire anyone experienced in the DSL you've got...

bombcar 4y ago
Being skilled in Lisp or other DSL producers can be amazing for one-man projects. Above that sticking with standard languages really is useful. I remember seeing a "DSL cycle" somewhere - http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html http://mikehadlow.blogspot.com/2012/05/configuration-complex...
kazinator 4y ago
There is no such thing as a software shop with no local DSLs, in any language. All the in-house abstractions constitute DSLs. Without syntactic abstraction (function and data only), things are worse, because those abstractions have to be coordinated together into proper usage scenarios, and those are written by hand in multiple places. So you're looking at eye-glazing repetitions. Oh, and just because a language doesn't have macros doesn't mean you won't see any syntax-level DSL. You may find textual code generation in a project in any language. C++, Go, Java, you name it. Understanding a large amount of unfamiliar code is a challenge no matter how it is organized. Whether it uses syntactic abstraction is a minor factor, and it is not an iron clad truth one way or the other whether that helps or hurts. If you can learn a complex API where you have to take several kinds of objects through a multi-step workflow, you can probably learn a syntactic construct that does it for you; especially if it is documented and has test cases. You will never hire anyone who is experienced in the vocabulary of your code base, unless it was someone who was previously laid off.
cutler 4y ago
Nubank is built exclusively in Clojure, proving large-scale projects can be developed with a Lisp. Same goes for Paul Graham and Viaweb.

chrisseaton 4y ago

I think Perl fell victim to a huge change of fashion around the 2000s. 'There's more than one way to do it' and the whimsical, deliberately slightly obtuse design of Perl used to be what people valued. Then something happened (perhaps it was how people started building much larger apps in 'scripting' languages, to use an out-dated term) and I think to most people under 35 deliberately having 'more than one way to do it' sounds like an atrocious idea and something they don't want anything to do with. Same with linguistic whimsy in their language design - they don't want to have to look up why a method to do with objects is called 'bless' for example. Look at the success of languages like Go, which are the polar opposite of Perl's philosophy.

agumonkey 4y ago
Interesting question, maybe computing was still a wildlife space to explore and 'more than one way' was felt like a challenge in creativity.. then the field decided it had to become industrial (the term that comes to mind thinking about all the professors talking about UML, diagrams, build swap-in packages like ICs) and suddenly, standardization is the only way.
polynomial 4y ago
And then there was the rise of Javascript, which also allows for many many ways of doing the same thing.
- chrisseaton 4y ago
  Hmmm I'm not sure I think so? JavaScript is a pretty simple and compact language. Referencing object fields yes... but that's because of a uniform model of arrays and objects afforded different syntaxes. That's not really what I mean.
goto11 4y ago
Perl is a great language if you are a single developer. I think there is some "reverse network effect" for Perl, where people might enjoy writing in the language but nobody enjoys having to maintain Perl written by someone else. So basically you don't encourage others to use it.

deleted 4y ago

[deleted]

wwweston 4y ago

Do you remember the title or any other details of Conway’s presentation? I’d like to look for this.