20 minutes
Any
English
One of the things that makes Perl so useful is that there’s almost always more than one way to solve a problem. But those choices often exist at very different levels of abstraction.
Take databases. At one end, we can construct SQL strings and send them directly to a database. We can move up to DBI, use a query builder, or let something like DBIx::Class represent our database as Perl objects.
The same thing happens in web development. We can deal directly with HTTP requests and responses, use PSGI/Plack as an abstraction over the web server, build applications with frameworks such as Dancer2 or Mojolicious, and then add further abstractions for routing, templates, configuration and data access.
Every abstraction hides complexity. That's its job. But every abstraction also introduces its own concepts, assumptions and constraints. Move too far down the stack and you spend your time reinventing solved problems. Move too far up it and you can find yourself fighting a framework — or struggling to understand what it is doing on your behalf.
In this talk, we'll explore some of the abstraction layers available to modern Perl programmers, concentrating on database and web programming. We'll look at what each layer gives us, what it hides from us, and what it costs us.
The aim isn't to identify the "best" abstraction. It's to get better at recognising the level of abstraction that's appropriate for the problem we're actually trying to solve — and to understand enough about the layers below it that we know what's happening when the abstraction leaks.
Sponsors
Silver:
More information about all of our valued sponsors is available on our sponsors page.