[rootusrootus]

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.

[foobiekr]

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

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.

[cestith]

Perl6 is now of course Rakulang. 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.

[chrisseaton]

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.

[goto11]

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.

[autoexec]

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

I think you might be right. Perl is a lot of fun to write, and it's still my language of choice for log parsing and automating sys admin stuff, but while it's possible to write Perl in a way that's easy for others to maintain and understand most people don't (less fun?) and for small projects it's even sometimes faster to rewrite something than mess with what someone else left you.

Actually... now that I think about it, is it ever a joy to work with someone else's mess in any language?

[goto11]

> Actually... now that I think about it, is it ever a joy to work with someone else's mess in any language?

Not really, but not every language is equal. Wen developing for my own sake, I enjoy Scheme or Haskell, but I would rather maintain code written in C#.

[agumonkey]

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.

[ThinkBeat]

C# keeps accumulating "more than one way to do it with every (too frequent) update.

A guy who is an expert lets say C# 2.0, would have no way to just read code for C# 9 that took advantage of new features and syntax.

It can be procedural, object oriented, functional, in a limited way aspect oriented, it can be data oriented in a way and all of those at the same time.

[polynomial]

And then there was the rise of Javascript, which also allows for many many ways of doing the same thing.

[chrisseaton]

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.

[giantrobot]

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

[MadWombat]

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

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.

[agumonkey]

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.

[svachalek]

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.

[didip]

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]

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.

[baq]

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

[kazinator]

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.

[bombcar]

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

[cutler]

Nubank is built exclusively in Clojure, proving large-scale projects can be developed with a Lisp. Same goes for Paul Graham and Viaweb.

[wwweston]

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