What does ChatGPT think about improving Perl?
For kicks I asked GPT to speculate about how we might improve Perl syntax with types and better object orientation. It generated the follow code and descriptions. Yes I know there's some errors in the code, I'm just presenting this as Chat GPT wrote it.
FWIW it looks a lot like what I see coming out of Corrina.
JOHN: If you wanted to improve Perl by adding types and object orientation what would you do. Give an example.
CHATGPT: Perl already has a limited form of object orientation, and there are also ways to add type checking through modules like Type::Tiny and Moose. However, if you were looking to significantly improve Perl's support for types and object orientation, there are a few different directions you could take.
One approach would be to add support for static typing. This would involve creating a way to specify types for variables and function parameters at compile time, and then checking that these types are respected at runtime. This could help catch certain types of errors early, before the code is even executed. One way to implement this would be to add type annotations similar to what is found in other languages like Python, Java, or TypeScript.
Another approach would be to improve Perl's object system. One way to do this would be to make it easier to define classes and create instances of those classes. One possible solution would be to create a new syntax for defining classes, similar to what is found in modern languages like Ruby or Python. This would allow for more concise and readable code when working with objects. Additionally, it would be useful to add support for interfaces, which would allow for better code organization and more flexible design patterns.
Here's an example of what adding static typing to Perl might look like:
use strict;
use warnings;
use types;
sub add_numbers(Int $x, Int $y) : Int {
return $x + $y;
}
my $result = add_numbers(3, 4);
print $result; # prints 7
add_numbers(3.5, 4); # throws a type error
In this example, we've used a module like types to define a new Int type, and then added type annotations to our function addnumbers. This ensures that $x and $y are both integers, and that the function returns an integer as well. If we try to call addnumbers with a non-integer argument, we'll get a type error.
JOHN: improve the example to include your proposed new syntax for objects.
CHATGPT: Sure, here's an example of what using a new syntax for objects might look like:
use strict;
use warnings;
class Person {
has $name;
has $age;
sub greet() {
print "Hello, my name is $name and I'm $age years old\n";
}
}
my $person = Person->new(name => "Alice", age => 25);
$person->greet(); # prints "Hello, my name is Alice and I'm 25 years old"
In this example, we're using a new class keyword to define a class called Person. Inside the class definition, we're using a new has keyword to define instance variables. We've also defined a method called greet that uses those instance variables to print a greeting.
We then create a new instance of the Person class using a new new method. We pass in the name and age values as named arguments, and the new method creates a new object with those values. Finally, we call the greet method on the object to print the greeting.
This syntax is similar to what's found in languages like Ruby and Python, and can make object-oriented code more concise and readable. Additionally, this new syntax could be extended to support interfaces or abstract classes, which would allow for even more flexible code design.
JOHN: expand the example to include role and inheritance as well as ideas from Moose such as lazy attributes. be sure to include your proposals for adding types as well
CHATGPT: Sure, here's an example that includes roles, inheritance, and lazy attributes, as well as the type annotations proposed in the previous example:
use strict;
use warnings;
use types;
role Speakable {
requires 'speak';
}
class Person {
has Str $name;
has Int $age;
sub greet() : Str {
return "Hello, my name is $name and I'm $age years old";
}
sub speak() {
print "Hello, my name is $name";
}
}
class Robot extends Person with Speakable {
has Bool $is_on;
has lazy Str $model = sub { get_model_from_database() };
sub speak() {
if ($is_on) {
print "Beep boop, I am a $model robot";
} else {
print "I am currently turned off";
}
}
sub turn_on() {
$is_on = 1;
}
sub turn_off() {
$is_on = 0;
}
}
sub get_model_from_database() : Str {
# ...
}
my $person = Person->new(name => "Alice", age => 25);
print $person->greet(); # prints "Hello, my name is Alice and I'm 25 years old"
my $robot = Robot->new(name => "Robo", age => 5);
$robot->turn_on();
$robot->speak(); # prints "Beep boop, I am a XYZ-123 robot"
In this example, we've defined a new role called Speakable that requires an implementation of the speak method. We then define a new class called Person that has a name attribute of type Str and an age attribute of type Int. We've also added a return type annotation to the greet method.
We then define a new class called Robot that extends the Person class and includes the Speakable role. Robot has two additional attributes: a ison attribute of type Bool, and a model attribute of type Str that is defined lazily using a closure. We've also defined a new turnon method and a new turn_off method.
Finally, we define a new getmodelfrom_database function that returns a string. We create a new instance of Person and call the greet method on it, and we create a new instance of Robot, turn it on, and call the speak method on it.
This example shows how adding support for classes, roles, and inheritance can make it easier to organize and extend object-oriented code. We've also added lazy attributes to the Robot class, which allows us to defer the expensive operation of getting the robot's model until it's actually needed. Additionally, we've added type annotations to the attributes and methods to help catch certain types of errors early.
This is scary, scary stuff. At least Curtis should be pleased.
FWIW I asked it to redo the example but make it look more like Moose. I suspect there's going to be a segment of the Perl community that would prefer something 'more like what I'm already doing'. Here's what it came up with.