> "I think IDEs make language developers lazy." -Larry Wall

Larry also considers Laziness one of the three primary virtues of programmers, so maybe he meant the above as a compliment.

I saw that part of the video too, and although Larry looked like he was having a fun moment, I think he was also quite insightful.

IDEs help people write programs, but to language developers, an IDE might be the easy and less elegant way out of a problem in the design of the language.

Anders Hejlsberg also made the point that types are documentation.

Programming language design is user interface design because programmers are programming language users.

"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.

But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)

Types as documentation is one of the things I like best about Perl6 types. Perl6 has the concept of a `subset` of a type. Let's say I want to write a function that takes a name which must be only one line of text, and a positive integer as arguments.

In Perl6 I can document those requirements in the subroutine signature:

  sub foo( Str $name where *.lines == 1, Int $count where * > 0 ) {
      say "Name is $name with count $count";
  }

Or if I want to name the concepts and reuse them, I can say:

  subset LegalName of Str where *.lines == 1;
  subset PositiveInteger of Int where * > 0;

  sub bar( LegalName $name, PositiveInteger $count ) { foo( $name, $count) }

You can use these subsets for multiple dispatch as well:

  # Print a single line argument.
  multi sub print-it( Str:D $it where *.lines == 1 ) {
    say $it;
  }

  # Print a multiline string as a single line
  multi sub print-it( Str:D $it ) {
    say $it.lines.join('');
  }

  # Handle anything that we didn't expect
  multi sub print-it( Any $it ) {
    Failure.new( "it was unprintable", $it.gist );
  }

IME, this makes it easy to write self documenting code.

Then you'd probably love ADA! Does Perl 6 have postconditions, too?

https://www.adacore.com/gems/gem-31

Gem #31: Preconditions/postconditions

>The notion of preconditions and postconditions is an old one. A precondition is a condition that must be true before a section of code is executed, and a postcondition is a condition that must be true after the section of code is executed.

http://www.ada-auth.org/standards/12rat/html/Rat12-2-3.html

>We will look first at the simple case when inheritance is not involved and then look at more general cases. Specific preconditions and postconditions are applied using the aspects Pre and Post respectively whereas class wide conditions are applied using the aspects Pre'Class and Post'Class.

>To apply a specific precondition Before and/or a specific postcondition After to a procedure P we write

    procedure P(P1: in T1; P2: in out T2; P3: out T3)
        with Pre => Before,
             Post => After;

>where Before and After are expressions of a Boolean type (that is of type Boolean or a type derived from it).

If your language supports preconditions, postconditions and invariants, then you can pursue the "Design by Contract" approach to programming, coined by Bertrand Meyer for Eiffel.

That's when you guarantee that if all the preconditions are met before calling a function, then all the postconditions will be met after it returns (but the object may go through intermediate states where the postconditions aren't met before it returns, like while inserting an item into a doubly linked list). Unfortunately that idea breaks down when you have multiple threads that might enter a function at the same time, so you have to use object level locks, which have their own problems.

https://en.wikipedia.org/wiki/Design_by_contract

https://en.wikipedia.org/wiki/Eiffel_(programming_language)

>The design of the language is closely connected with the Eiffel programming method. Both are based on a set of principles, including design by contract, command–query separation, the uniform-access principle, the single-choice principle, the open–closed principle, and option–operand separation.

>Many concepts initially introduced by Eiffel later found their way into Java, C#, and other languages. New language design ideas, particularly through the Ecma/ISO standardization process, continue to be incorporated into the Eiffel language.

Yes, Perl 6 has pre and post-conditions. They are available in the form of the `PRE` and `POST` phasers: https://docs.perl6.org/language/phasers#PRE , https://docs.perl6.org/language/phasers#POST

The prototypical example being getter and setter methods, which Java IDEs generate.

Or you could just let the language do it, as do Commonlisp and C++.

The important thing is that Larry say language developers get lazy because of IDEs, not programmers using the language.

A powerful IDE that automatically looks up documentation and guides you through writing a bunch of boilerplate lets a language designer skimp on figuring out ways to let you avoid writing the boilerplate in the first place.

Code generation in the IDE is a poor substitute for a well designed interface.

Which makes it deliciously ironic that Larry would bring that point up, since Perl's syntactic user interface is so terribly designed.

Perl5 has some design features that are not as good as they could have been if it broke backwards compatibility. So there were a lot of limitations on how things could get added. (Code written in 1987 will most likely still work on the latest version of Perl5 released last year, or even on the version coming out later this year.)

The Perl6 project was to reimagine the design by breaking things that needed breaking.

If your premise that Larry is bad at language design, then you should be able to find something in Perl6 that is “terribly designed”. I won't be holding my breath, so feel free to take your time.