5 ms·

On the related subject of the Meta Object Protocol, Gregor Kiczales talked at a meeting of the Vancouver Lisp Users Group in 2006, which they called a MOP retro

On the related subject of the Meta Object Protocol, Gregor Kiczales talked at a meeting of the Vancouver Lisp Users Group in 2006, which they called a MOP retrospective [1]. He gave some thoughts on subjects like why more recent languages don't have MOPs. The link below is to archive.org's copy of the page and the .ogg recording of the talk along with Q&A throughout and after. [1] https://web.archive.org/web/20060821003818/http://bc.tech.coop/blog/060709.html https://web.archive.org/web/20060821003818/http://bc.tech.co...

7thaccount 3y ago
I'm not a hotshot developer, but I'd guess a lot of recent languages (e.g. golang) are more structured around how to keep things simple (not necessarily easy) and uniform to where there aren't many surprises for new developers and the company can more or less turn coding into something more like an assembly line (to use an overly simplistic metaphor). Contrast that with languages like Lisp with crazy amounts of flexibility that really cater to small teams of rockstar developers (to use another overly simplistic metaphor) and you can see the problem. Most companies want the former and not the latter.
- leetrout 3y ago
  I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work. Horses for courses - I will never be a language designer / developer with this attitude.
  - sph 3y ago
    > using my brain power on business problems not what makes me more productive This doesn't make any sense. It's like saying you prefer hitting rocks together to make music because you don't have to use all your brain power at operating something complex like the sax or the piano. Tool enable, or kill, creativity. I'd rather not use my brain power to fight an obtuse tool, like Go can be, but instead choose to become a violin, or Lisp, virtuoso. The real issue is that many people don't want to become virtuoso, but just want to learn as little from their tools to make rent. That's fine, but let's not blame the tool, then. You know who doesn't like rockstars and soloists? Large companies, so they make us feel as if we're weird, unruly, opinionated, just because we don't conform to the Standard Programmer mould to fit inside the cubicle. Whenever I hear someone mention rockstar engineers, I wonder if they mean it as an insult, instead of something to be encouraged and celebrated.
    - coldtea 3y ago
      >This doesn't make any sense. It's like saying you prefer hitting rocks together to make music because you don't have to use all your brain power at operating something complex like the sax or the piano. It's more like saying that he'd rather play the piano and get musical results faster, than study some instrument much fewer people use, with 200 microtonal keys, 10 pedals, additional sliders and rotary switches, and a microprocessor that you can study a 500 page guide to learn and create custom sounds for, and the music scores for which look like line noise.
      - leetrout 3y ago
        This is correct. Thank you for the defense.
    - mathisfun123 3y ago
      To abuse the metaphor - lisp and lispers are completely tone deaf. There's an enormous number of people writing code that don't care one wit about "elegance" or "power" or "beauty" or whatever weird intangibles lisp has pretensions to. These people (such heretics) in fact don't care about software unto itself at all. They only care about using software to accomplish some goal, finish some task, solve some real (earthly) problem. > The real issue is that many people don't want to become virtuoso, but just want to learn as little from their tools to make rent. I would love to be a virtuoso pianist or painter or singer. I can't fathom the desire to be a virtuoso programmer - it would be like being a virtuoso widget assembler. I mean sure our bosses wishes all of us were virtuoso widget assemblers. But me by myself? Nah. And also don't give me that protestant work ethic shpiel about taking pride in your work - I have plenty of other things I can be proud of instead. > That's fine, but let's not blame the tool, then. A tool that no one uses isn't some lonely pitiable misunderstood emo child - it's just useless. It's dead simple: if lisp were the key to building fantastically successful software we would all swallow our pride and use the stupid parens language. I don't know how such a clear and obvious argument never gets through to people in language communities. If you have to fight, for decades, to convince people that your tool is superior and still no one is using it, you should reflect deeply on whether you're wrong.
  - lispm 3y ago
    One of the ideas of Lisp is that you can extend/change the language to bring it near the actual domain level. The so-called "Embedded Domain Specific Language" is common in Lisp.
    - leetrout 3y ago
      In my VERY limited experience this is only maintainable in very capable hands. They all start off OK and then creep and bloat.
      - taeric 3y ago
        In my not so limited experience, this is true of all programming.
      - wtetzner 3y ago
        To be fair, I don't think I'd want someone who's not very capable working on anything important, no matter what language they're using. I know it happens all the time, but I don't think that's a particularly compelling argument.
      - p_l 3y ago
        I'd argue that's usually the case, because writing little language inside your normal language is full of problems, compiler writing is neither taught much anymore nor well supported (this is not a dig on the programmers - it's more that it feels like we're told that this and that is magic and should be left for the wizards). So then you finally find yourself needing to do something that requires DSL, and you quickly end up on the annoying self-destructive treadmill of growing from small simple grokkable config file to something that should be put out of its misery (and the misery it forces on developers). FWIW, some languages make it (IMO) much easier to handle that, if one decides from start to "embed" the DSL - Lisps are infamous on this, but this works just as well with Ruby, builder patterns in various languages (this can be a bit more prone to error though), or the less liked languages like poor TCL.
      - deleted 3y ago
        [deleted]
  - panick21_ 3y ago
    Go concurrency is lots of magic.
    - BaculumMeumEst 3y ago
      It's also dramatically more useful than CLOS, and its real-world impact has far outweighed that of CLOS. Having excellent concurrency features built into a language turns out to be pretty important.
      - deleted 3y ago
        [deleted]
  - wtetzner 3y ago
    > I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work. This seems like a false dichotomy. Boilerplate-heavy code is the opposite of focusing on business logic. Incidental complexity ends up being intertwined with business logic everywhere. More powerful languages allow programmers to do clever tricks and make a mess, but they don't require it. Those languages also allow programmers to abstract away incidental complexity and expose business logic more clearly. I think the future of programming languages is going to be in finding a balance that allows powerful abstractions while still making the semantics as clear as possible. Though I have to say, I don't really see what Go buys you over something like OCaml, which is still very explicit (in many ways more so than Go) while still providing powerful abstraction facilities. It even competes with Go on the compile-time front.
    - LanceH 3y ago
      Go hits that niche of "read from a queue/endpoint, write to a queue/endpoint", and there is an awful lot of that going on. It's just practical for getting (some kinds of) work done. > I don't really see what Go buys you over something like OCaml Easy installation on windows for one.
    - Kamq 3y ago
      > Though I have to say, I don't really see what Go buys you over something like OCaml, which is still very explicit (in many ways more so than Go) while still providing powerful abstraction facilities. I mean, the thing it provides is that it doesn't provide powerful abstraction facilities. There's a fundamental limit to how bad the code can get. You can wind up with really gronky code, but you can't experience the horrible abstraction collapse that is experienced in extension heavy OO programming or certain flavors of functional programming. You also can't get the heights of truly amazing abstractions, but that's a trade-off a lot of devs are willing to make. Edit: I should clarify. The above reasoning is generally only true for enterprise projects. I'm a pretty big advocate for go in enterprise settings for the above reason as well. But in my own time, when I'm programming for fun, I tend to go with elixir/common lisp/scala or something else fun.
- ecshafer 3y ago
  Go was made popular and successful for only one reason, google used/made it. And this was at the height of googles coolness. So other companies followed on the bandwagon, or were made by former google developers and brought it over. The success is completely secondary to how many people like go or the features it has. As far as simplicity I think I would disagree and agree with that. Rust is not a simple language. Other languages like F# or Scala or Kotlin that have arisen in the same timeframe as go are also not simple. But they do try and make some hard things easier, like concurrency or type safety.
  - coldtea 3y ago
    Well, Google also made Dart and it went nowhere. So it's not necessarily that. Go had a simple familiar syntax that's easy to pick up, decent tooling from the get go, good enough speed and memory use, and promised easy parallelism. It also arrived at 1.0 relatively quickly and quite mature with few rough edges and a feature full standard lib. Most "indie" languages don't have those even after 10 years of development.
    - syntheweave 3y ago
      Go's good parts are basically the parts inherited from Bell Labs - the channels are an echo of Plan9's 9p protocol being used everywhere, and the style syntactically and in metaprogramming capability remains close to C, but with refinements like using Unicode. Which adds up to it being a decent language for making networked software and small "one-thing-well" utilities. If it were actually used in production on Plan9, a lot of the idioms would become that much more powerful, as more of the interfacing glue could be handled by the shell and 9p namespaces, but as it is, it gets bogged down by compatibility issues.
      - p_l 3y ago
        Some of the things that people found confusing in Go (GOPATH etc) are due to the fact that Go's native environment is Plan 9, down to using Plan 9 libraries and compilers before the full self-hosting rewrite was done
  - 3y ago
- wtetzner 3y ago
  I don't really buy into this view of Go. Go doesn't keep things simple and uniform. It's more limited in many ways than other languages, but it's feature set is largely arbitrary, and not particularly simple. Limited and simple are not synonyms.
  - MobiusHorizons 3y ago
    > Go doesn’t keep things simple and uniform This is a bold statement, care to back that up with examples? In my experience go is the most uniform language I have used due in large part to having very good abstractions available in the standard library, as well as the way interfaces are used. > Limited and simple are not synonyms Agreed. Simple refers to how much context you me to keep track of as opposed to the capabilities of the system (which is how I interpret limited). What aspects of go you you find limited?
    - wtetzner 3y ago
      > This is a bold statement, care to back that up with examples? I would argue it's less bold than claiming Go does keep things simple and uniform. It's weird to require someone to prove that a language doesn't have nice properties. In any case, one glaring example of non-uniformity is how slices and maps are magically generic. I would also argue that Go's error handling solution of returning a pair is not very simple. Returning two things when only one of them should ever be populated is incidental complexity, and adds cognitive load. Something like a sum type is simpler, as you only get a value or the error.
      - MobiusHorizons 3y ago
        It's not about if it has or doesn't have nice properties. It's about going against conventional wisdom. Conventional wisdom is often wrong, so go right ahead, but you need at least some evidence in a public forum when you say things that are generally established not to be true.
- gleenn 3y ago
  People tend to say Lisps cater towards smaller dev shops. Clojure spends a lot of time trying to keep things simple though. They are relatively opinionated about a lot of stuff. I've seen some relatively large projects with a lot of devs using it too. So I don't think your statement is universally true
- FpUser 3y ago
  There is a big difference between "a lot of recent languages" and "golang". Also Google solves Google's problems. They do not give a fuck about rest of the world. If what they do helps you personally then adopt it. If not let them go play hide.

7thaccount 3y ago

I'm not a hotshot developer, but I'd guess a lot of recent languages (e.g. golang) are more structured around how to keep things simple (not necessarily easy) and uniform to where there aren't many surprises for new developers and the company can more or less turn coding into something more like an assembly line (to use an overly simplistic metaphor). Contrast that with languages like Lisp with crazy amounts of flexibility that really cater to small teams of rockstar developers (to use another overly simplistic metaphor) and you can see the problem. Most companies want the former and not the latter.

leetrout 3y ago
I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work. Horses for courses - I will never be a language designer / developer with this attitude.
- sph 3y ago
  > using my brain power on business problems not what makes me more productive This doesn't make any sense. It's like saying you prefer hitting rocks together to make music because you don't have to use all your brain power at operating something complex like the sax or the piano. Tool enable, or kill, creativity. I'd rather not use my brain power to fight an obtuse tool, like Go can be, but instead choose to become a violin, or Lisp, virtuoso. The real issue is that many people don't want to become virtuoso, but just want to learn as little from their tools to make rent. That's fine, but let's not blame the tool, then. You know who doesn't like rockstars and soloists? Large companies, so they make us feel as if we're weird, unruly, opinionated, just because we don't conform to the Standard Programmer mould to fit inside the cubicle. Whenever I hear someone mention rockstar engineers, I wonder if they mean it as an insult, instead of something to be encouraged and celebrated.
  - coldtea 3y ago
    >This doesn't make any sense. It's like saying you prefer hitting rocks together to make music because you don't have to use all your brain power at operating something complex like the sax or the piano. It's more like saying that he'd rather play the piano and get musical results faster, than study some instrument much fewer people use, with 200 microtonal keys, 10 pedals, additional sliders and rotary switches, and a microprocessor that you can study a 500 page guide to learn and create custom sounds for, and the music scores for which look like line noise.
    - leetrout 3y ago
      This is correct. Thank you for the defense.
  - mathisfun123 3y ago
    To abuse the metaphor - lisp and lispers are completely tone deaf. There's an enormous number of people writing code that don't care one wit about "elegance" or "power" or "beauty" or whatever weird intangibles lisp has pretensions to. These people (such heretics) in fact don't care about software unto itself at all. They only care about using software to accomplish some goal, finish some task, solve some real (earthly) problem. > The real issue is that many people don't want to become virtuoso, but just want to learn as little from their tools to make rent. I would love to be a virtuoso pianist or painter or singer. I can't fathom the desire to be a virtuoso programmer - it would be like being a virtuoso widget assembler. I mean sure our bosses wishes all of us were virtuoso widget assemblers. But me by myself? Nah. And also don't give me that protestant work ethic shpiel about taking pride in your work - I have plenty of other things I can be proud of instead. > That's fine, but let's not blame the tool, then. A tool that no one uses isn't some lonely pitiable misunderstood emo child - it's just useless. It's dead simple: if lisp were the key to building fantastically successful software we would all swallow our pride and use the stupid parens language. I don't know how such a clear and obvious argument never gets through to people in language communities. If you have to fight, for decades, to convince people that your tool is superior and still no one is using it, you should reflect deeply on whether you're wrong.
- lispm 3y ago
  One of the ideas of Lisp is that you can extend/change the language to bring it near the actual domain level. The so-called "Embedded Domain Specific Language" is common in Lisp.
  - leetrout 3y ago
    In my VERY limited experience this is only maintainable in very capable hands. They all start off OK and then creep and bloat.
    - taeric 3y ago
      In my not so limited experience, this is true of all programming.
    - wtetzner 3y ago
      To be fair, I don't think I'd want someone who's not very capable working on anything important, no matter what language they're using. I know it happens all the time, but I don't think that's a particularly compelling argument.
    - p_l 3y ago
      I'd argue that's usually the case, because writing little language inside your normal language is full of problems, compiler writing is neither taught much anymore nor well supported (this is not a dig on the programmers - it's more that it feels like we're told that this and that is magic and should be left for the wizards). So then you finally find yourself needing to do something that requires DSL, and you quickly end up on the annoying self-destructive treadmill of growing from small simple grokkable config file to something that should be put out of its misery (and the misery it forces on developers). FWIW, some languages make it (IMO) much easier to handle that, if one decides from start to "embed" the DSL - Lisps are infamous on this, but this works just as well with Ruby, builder patterns in various languages (this can be a bit more prone to error though), or the less liked languages like poor TCL.
    - deleted 3y ago
      [deleted]
- panick21_ 3y ago
  Go concurrency is lots of magic.
  - BaculumMeumEst 3y ago
    It's also dramatically more useful than CLOS, and its real-world impact has far outweighed that of CLOS. Having excellent concurrency features built into a language turns out to be pretty important.
    - deleted 3y ago
      [deleted]
- wtetzner 3y ago
  > I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work. This seems like a false dichotomy. Boilerplate-heavy code is the opposite of focusing on business logic. Incidental complexity ends up being intertwined with business logic everywhere. More powerful languages allow programmers to do clever tricks and make a mess, but they don't require it. Those languages also allow programmers to abstract away incidental complexity and expose business logic more clearly. I think the future of programming languages is going to be in finding a balance that allows powerful abstractions while still making the semantics as clear as possible. Though I have to say, I don't really see what Go buys you over something like OCaml, which is still very explicit (in many ways more so than Go) while still providing powerful abstraction facilities. It even competes with Go on the compile-time front.
  - LanceH 3y ago
    Go hits that niche of "read from a queue/endpoint, write to a queue/endpoint", and there is an awful lot of that going on. It's just practical for getting (some kinds of) work done. > I don't really see what Go buys you over something like OCaml Easy installation on windows for one.
  - Kamq 3y ago
    > Though I have to say, I don't really see what Go buys you over something like OCaml, which is still very explicit (in many ways more so than Go) while still providing powerful abstraction facilities. I mean, the thing it provides is that it doesn't provide powerful abstraction facilities. There's a fundamental limit to how bad the code can get. You can wind up with really gronky code, but you can't experience the horrible abstraction collapse that is experienced in extension heavy OO programming or certain flavors of functional programming. You also can't get the heights of truly amazing abstractions, but that's a trade-off a lot of devs are willing to make. Edit: I should clarify. The above reasoning is generally only true for enterprise projects. I'm a pretty big advocate for go in enterprise settings for the above reason as well. But in my own time, when I'm programming for fun, I tend to go with elixir/common lisp/scala or something else fun.
ecshafer 3y ago
Go was made popular and successful for only one reason, google used/made it. And this was at the height of googles coolness. So other companies followed on the bandwagon, or were made by former google developers and brought it over. The success is completely secondary to how many people like go or the features it has. As far as simplicity I think I would disagree and agree with that. Rust is not a simple language. Other languages like F# or Scala or Kotlin that have arisen in the same timeframe as go are also not simple. But they do try and make some hard things easier, like concurrency or type safety.
- coldtea 3y ago
  Well, Google also made Dart and it went nowhere. So it's not necessarily that. Go had a simple familiar syntax that's easy to pick up, decent tooling from the get go, good enough speed and memory use, and promised easy parallelism. It also arrived at 1.0 relatively quickly and quite mature with few rough edges and a feature full standard lib. Most "indie" languages don't have those even after 10 years of development.
  - syntheweave 3y ago
    Go's good parts are basically the parts inherited from Bell Labs - the channels are an echo of Plan9's 9p protocol being used everywhere, and the style syntactically and in metaprogramming capability remains close to C, but with refinements like using Unicode. Which adds up to it being a decent language for making networked software and small "one-thing-well" utilities. If it were actually used in production on Plan9, a lot of the idioms would become that much more powerful, as more of the interfacing glue could be handled by the shell and 9p namespaces, but as it is, it gets bogged down by compatibility issues.
    - p_l 3y ago
      Some of the things that people found confusing in Go (GOPATH etc) are due to the fact that Go's native environment is Plan 9, down to using Plan 9 libraries and compilers before the full self-hosting rewrite was done
- 3y ago
wtetzner 3y ago
I don't really buy into this view of Go. Go doesn't keep things simple and uniform. It's more limited in many ways than other languages, but it's feature set is largely arbitrary, and not particularly simple. Limited and simple are not synonyms.
- MobiusHorizons 3y ago
  > Go doesn’t keep things simple and uniform This is a bold statement, care to back that up with examples? In my experience go is the most uniform language I have used due in large part to having very good abstractions available in the standard library, as well as the way interfaces are used. > Limited and simple are not synonyms Agreed. Simple refers to how much context you me to keep track of as opposed to the capabilities of the system (which is how I interpret limited). What aspects of go you you find limited?
  - wtetzner 3y ago
    > This is a bold statement, care to back that up with examples? I would argue it's less bold than claiming Go does keep things simple and uniform. It's weird to require someone to prove that a language doesn't have nice properties. In any case, one glaring example of non-uniformity is how slices and maps are magically generic. I would also argue that Go's error handling solution of returning a pair is not very simple. Returning two things when only one of them should ever be populated is incidental complexity, and adds cognitive load. Something like a sum type is simpler, as you only get a value or the error.
    - MobiusHorizons 3y ago
      It's not about if it has or doesn't have nice properties. It's about going against conventional wisdom. Conventional wisdom is often wrong, so go right ahead, but you need at least some evidence in a public forum when you say things that are generally established not to be true.
gleenn 3y ago
People tend to say Lisps cater towards smaller dev shops. Clojure spends a lot of time trying to keep things simple though. They are relatively opinionated about a lot of stuff. I've seen some relatively large projects with a lot of devs using it too. So I don't think your statement is universally true
FpUser 3y ago
There is a big difference between "a lot of recent languages" and "golang". Also Google solves Google's problems. They do not give a fuck about rest of the world. If what they do helps you personally then adopt it. If not let them go play hide.