6 ms·

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 n

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.
  - gleenn 3y ago
    I hardly think being a virtuoso programmer is something to shun. Not everyone has to do it but it's not a bad thing. Also, as the speed of processors has basically stopped but we get more and more cores, things like Clojure's atoms, STM, and core.async make it really easy to do parallel computations without the utter insanity that using mutexes or Futures or whatever leads to. Clojure definitely makes it way easier to write clearly correct multi-threaded code in very few lines of code. You would be shocked what you can get out of the box. So there is a lisp that targets exactly what you want: something for laymen to use to effectively get the job done correctly and way easier than the competition. I've seen FAANG engineers screw up simple locks etc. If Clojure can hand you tools to get that done then why wouldn't you be trying it (despite your aversion to parens).
  - sph 3y ago
    > I can't fathom the desire to be a virtuoso programmer - it would be like being a virtuoso widget assembler. Only if all the programming you do is assembling widgets, which given your tone might be the case. For some it is a form of art, just like a paintbrush or a musical instrument. Imagine if we were in a bizarro world where you go to violin university not because you like it, but because it's a good career that pays well; after 20 years doing 40 h/wk playing the violin for a nameless Big Orchestra playing day in day out what is frankly trite crap for pointy haired composers, you'd find it very hard to imagine a world where people play the violin for fun. I sense a LOT of hostility on your part against me defending what is just, simply a tool, because Big Orchestra has killed your creativity and imagination. Again, it is not the tool's fault. Nor am I fighting for the world to adopt this tool as you claim. It's not a tool that meshes well with pointy haired bosses, and sadly they rule the world. In any case I'm not a "lisper", which seems to be a convenient category to put people in so they can be berated by your enormous frustration. I doubt all this rage comes because of deep seated trauma with S-expressions themselves. Glancing at your recent comment history, it sounds like you might need a holiday, Internet stranger.
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.

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.
- gleenn 3y ago
  I hardly think being a virtuoso programmer is something to shun. Not everyone has to do it but it's not a bad thing. Also, as the speed of processors has basically stopped but we get more and more cores, things like Clojure's atoms, STM, and core.async make it really easy to do parallel computations without the utter insanity that using mutexes or Futures or whatever leads to. Clojure definitely makes it way easier to write clearly correct multi-threaded code in very few lines of code. You would be shocked what you can get out of the box. So there is a lisp that targets exactly what you want: something for laymen to use to effectively get the job done correctly and way easier than the competition. I've seen FAANG engineers screw up simple locks etc. If Clojure can hand you tools to get that done then why wouldn't you be trying it (despite your aversion to parens).
- sph 3y ago
  > I can't fathom the desire to be a virtuoso programmer - it would be like being a virtuoso widget assembler. Only if all the programming you do is assembling widgets, which given your tone might be the case. For some it is a form of art, just like a paintbrush or a musical instrument. Imagine if we were in a bizarro world where you go to violin university not because you like it, but because it's a good career that pays well; after 20 years doing 40 h/wk playing the violin for a nameless Big Orchestra playing day in day out what is frankly trite crap for pointy haired composers, you'd find it very hard to imagine a world where people play the violin for fun. I sense a LOT of hostility on your part against me defending what is just, simply a tool, because Big Orchestra has killed your creativity and imagination. Again, it is not the tool's fault. Nor am I fighting for the world to adopt this tool as you claim. It's not a tool that meshes well with pointy haired bosses, and sadly they rule the world. In any case I'm not a "lisper", which seems to be a convenient category to put people in so they can be berated by your enormous frustration. I doubt all this rage comes because of deep seated trauma with S-expressions themselves. Glancing at your recent comment history, it sounds like you might need a holiday, Internet stranger.

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.