3 ms·

Enlightenment comes from exposure to alternate paradigms and being forced out of your comfort zone. When you must do without, you will learn, and you will be re

Enlightenment comes from exposure to alternate paradigms and being forced out of your comfort zone. When you must do without, you will learn, and you will be ready to rely on alternate approaches to problems. Example: I thought I understood the importance of decoupling policy from implementation, but Haskell reminds me frequently that I often overlook this detail when hacking. Rather than tying the side effects (send this HTTP request) to the algorithm that produces what I need to send, I should split them apart, and have a tiny bit of glue code for them both. It's also worth examining and trying out a particular language community's values to see if they mesh with yours. I found it hard to stay with the Ruby community because of certain stances that are made concerning program design. Everything seems tailored for easy, rather than simple. I learned a lot from Ruby, but I never found the metaprogramming/DSL creation to be particularly inspiring. I've made some pretty wacky/cool stuff with it, I just got bored with it ultimately -- it felt like it was piling more things on for people to learn, rather than actually abstracting things away.

vinceguidry 12y ago
> I never found the metaprogramming/DSL creation to be particularly inspiring. I've made some pretty wacky/cool stuff with it, I just got bored with it ultimately -- it felt like it was piling more things on for people to learn, rather than actually abstracting things away. DSL creation is all about firming up your domain model. If all you're doing is shifting complexity around, then sure, you won't get anything from the easy refactoring/metaprogramming. But if you're gradually learning more and more about how concepts work outside of programming and inside the underlying business, (Ruby works best when you're supporting a revenue-generating business rather than something more abstract) then you're actually getting somewhere. So what you do is you leave your complex methods where they are and think really hard about exactly what it is you're trying to do, what semantics you need to have. Then when you do refactor/redesign, the language you're using to create your classes isn't arbitrary, it's well-thought out and reflective of something that is needed. Ruby does seem tailored for easy rather than simple, I'll give you that. But you don't have to accept that lying down. Simplicity is well within the ability of the programmer to attain, he doesn't have to rely on the community.
- mattgreenrocks 12y ago
  > Then when you do refactor/redesign, the language you're using to create your classes isn't arbitrary, it's well-thought out and reflective of something that is needed. This is how I generally like to design systems. But it also sounds more like DDD than a DSL; especially the concept of ubiquitous language. I prefer OOP to DSLs, mostly because OOP composes well since it's a first-class citizen in the paradigm.
  - vinceguidry 12y ago
    I find myself refactoring to DSLs when I have a lot of composition to do and I want to cut the verbosity out of doing all of it. I'll take everything and turn it into something I can compose with and the DSL just knits everything together. For example, I made an application that generates different kinds of feeds from a database. I found myself making a bunch of classes that responded to .call with similar interfaces, arrays of hashes. So I refactored everything to composable method classes and even identified and extracted concepts inside the composable methods so that I could compose even the method classes. All the DSL does is compose the feed objects from the method classes. Each feed is composed of transformers, each transformer is a class with a .call method that takes an array of hashes and returns an array of hashes, unless it's pulling directly from the database, one of these is always the first of the transformers in the list. Or it's returning the end product, in which case it's always the last in the list. That app is just way too much fun to work on now. It has the kind of design I would have thought of if I'd done it in BDUF fashion, only instead of coming up with it up front, I refactored working code to it. And I would not have wanted to do it in anything but Ruby.
  - sklogic 12y ago
    DSLs compose much better than anything OOP. OOP is not nearly a replacement for DSLs. Mind designing, say, an OO parser generator?
sklogic 12y ago
> I never found the metaprogramming/DSL creation to be particularly inspiring This is only because it's a totally broken thing in Ruby. Try a proper metalanguage instead, you'll see a huge difference.

vinceguidry 12y ago

> I never found the metaprogramming/DSL creation to be particularly inspiring. I've made some pretty wacky/cool stuff with it, I just got bored with it ultimately -- it felt like it was piling more things on for people to learn, rather than actually abstracting things away. DSL creation is all about firming up your domain model. If all you're doing is shifting complexity around, then sure, you won't get anything from the easy refactoring/metaprogramming. But if you're gradually learning more and more about how concepts work outside of programming and inside the underlying business, (Ruby works best when you're supporting a revenue-generating business rather than something more abstract) then you're actually getting somewhere. So what you do is you leave your complex methods where they are and think really hard about exactly what it is you're trying to do, what semantics you need to have. Then when you do refactor/redesign, the language you're using to create your classes isn't arbitrary, it's well-thought out and reflective of something that is needed. Ruby does seem tailored for easy rather than simple, I'll give you that. But you don't have to accept that lying down. Simplicity is well within the ability of the programmer to attain, he doesn't have to rely on the community.

mattgreenrocks 12y ago
> Then when you do refactor/redesign, the language you're using to create your classes isn't arbitrary, it's well-thought out and reflective of something that is needed. This is how I generally like to design systems. But it also sounds more like DDD than a DSL; especially the concept of ubiquitous language. I prefer OOP to DSLs, mostly because OOP composes well since it's a first-class citizen in the paradigm.
- vinceguidry 12y ago
  I find myself refactoring to DSLs when I have a lot of composition to do and I want to cut the verbosity out of doing all of it. I'll take everything and turn it into something I can compose with and the DSL just knits everything together. For example, I made an application that generates different kinds of feeds from a database. I found myself making a bunch of classes that responded to .call with similar interfaces, arrays of hashes. So I refactored everything to composable method classes and even identified and extracted concepts inside the composable methods so that I could compose even the method classes. All the DSL does is compose the feed objects from the method classes. Each feed is composed of transformers, each transformer is a class with a .call method that takes an array of hashes and returns an array of hashes, unless it's pulling directly from the database, one of these is always the first of the transformers in the list. Or it's returning the end product, in which case it's always the last in the list. That app is just way too much fun to work on now. It has the kind of design I would have thought of if I'd done it in BDUF fashion, only instead of coming up with it up front, I refactored working code to it. And I would not have wanted to do it in anything but Ruby.
- sklogic 12y ago
  DSLs compose much better than anything OOP. OOP is not nearly a replacement for DSLs. Mind designing, say, an OO parser generator?

sklogic 12y ago

> I never found the metaprogramming/DSL creation to be particularly inspiring This is only because it's a totally broken thing in Ruby. Try a proper metalanguage instead, you'll see a huge difference.