6 ms·

> Different people like different things, and that's OK. Drink whatever is the best fit for your palate, and code in whatever is the best fit for your brain.

> Different people like different things, and that's OK. Drink whatever is the best fit for your palate, and code in whatever is the best fit for your brain. Doesn't this ignore the need to work together and build on each other's work? To me, that's not about companies being able to treat programmers as interchangeable, but about us collectively building higher, i.e. building towers of Babel rather than suffering from the curse of that story.

Twisol 4y ago
Take one: We need people moving together just as much as we need scouts who can push ahead and find the best paths for the rest of us. Take two: Working in the best fit for your brain is not incompatible with working with others -- enough companies are Java shops, why can't there be CL shops? (There are assuredly Clojure shops at the very least.) Take three: Not everything has to be about work. Programming is a skill, not an occupation; there are lots of ways to apply programming as a skill that don't require you to build large edifices in teams.
- jvanderbot 4y ago
  And how nice when those scouts lay groundwork that is useful for others, rather than creating something only they can use? Yes, you may think better in lisp than c++, but that doesn't help your team when you created something and moved right along. Better to speak the same language.
  - Twisol 4y ago
    I was referring to the discipline as a whole, not scouting at the granularity of a single team. Also refer to take three: working in an industrial team is not a prerequisite for an application of programming to be valid. But to your very specific point: I have in the past developed prototypes in Rust whilst on a Java-only team. It's actually a good thing: these prototypes were meant to be thrown away, so working in a different language (and one that helped me model things effectively) meant we were forced to throw it away then write it right in Java once we knew what we were doing. (We did the same thing for another feature, but it was someone else and they preferred Python. Again, we were able to prototype more rapidly and then implement a solid solution in Java once we knew how things should shake out.)
    - tlavoie 4y ago
      Another thing that is good to encourage is portable data. It's good for its own reasons, and it makes that sort of exploratory environment much more flexible. I've reimplemented a few side projects more than once, using common data back-ends because I can. I find it helps for say, messing with a new programming language, because I can apply it to a task I'm already familiar with.
  - GrumpySloth 4y ago
    Better for the others, but is it better for the scouts? Too often individuals are treated as drones obliged to work for a collective, which feels entitled to the work of the drones. From your perspective, they're not a good team mate. From their perspective, they're not part of your team.
    - jvanderbot 4y ago
      I think this example is being carried to extremes unproductively. All being equal, it's better to have a team writing code that is useful to the system or project or whatever ASAP. If an individual insists on prototyping in a language that nobody else can use, then they should either carry that prototype into the team's ecosystem, or start prototyping in that ecosystem and learn to be productive that way. If option A, let's hope that "write twice" is fast enough that they are productive. If option B, they may take a productivity hit but will probably catch up. The third option of "I'll do lisp you do <teams ecosystem>" is not very pro-social. Come integration and debugging and maintenance time, that Lisp-er is not in a position to help. That's an undue burden in the rest of the team.
      - GrumpySloth 4y ago
        I think you're excessively hung up on the example of everything happening within a single team inside a single company or some such thing, when the author of the submission wrote about making a choice for themselves. You don't start coding in Lisp out of nowhere when working in a Java shop on a CRUD app. But if you're charting your own course, it's great to be able to choose whatever suits you best. I can't count the number of times someone published their open source project and inevitably people in the comments started questioning their language choices, because they wouldn't be able to use it in their "team", and how that choice is ultimately harmful for "the community". Now, you're not doing that exact thing here. I'm just thinking about how all that focus on "the team" and "the community" often goes too far. Personally, I'm not going to do anything in Common Lisp, but I'm always happy seeing other people doing their projects in that language (and many others).
        4y ago
  - fithisux 4y ago
    So we are doing now what the others do? It defies any reason.
    - AnimalMuppet 4y ago
      If you are part of a team, then yes, do what others do. And no, it doesn't defy reason. Code is written once, but it's maintained for a long time. Or it's thrown away. But if it's thrown away because nobody else on the team knows that language, that's pretty wasteful. And if you make someone on the team learn a new language just to maintain that one program that's also wasteful. The person who insisted on using their language is optimizing for their own programming, but actually slowing down the team as a whole. We have words for that kind of behavior; they aren't compliments. Now, in any given instance, it could be that the program is much easier to write in one language, and more difficult (or even impossible) to write in others. But even in that case, if you're in an organization, you need to get buy-in from the team or management or both, rather than just doing your own thing because you can make it work. Otherwise, your program may work, but it's an orphan. You need the organization to be willing to maintain your special program, or it dies.
  - spfzero 4y ago
    Sometimes hard to predict whether something that works well for you would, or would not, work well for others, and whether others could, or could not use it.
082349872349872 4y ago
Take four: what, specifically, about ergolib should prevent anyone from building on top of something written with it? [Edit: A programmer should be able to Reverse Polish Notate, nested-paren a tree, reduce some arrays, make references in nested scopes, evaluate without mutation, send a message, spin up a fail-fast supervision tree, produce finite answers from infinite graphs, synchronously react, rendezvous with logic variables, combine the above. "Specialization is for insects."]
- jvanderbot 4y ago
  Maintainability. If you're the only person who can edit the library, you've just created a bus factor that would be unacceptable to most project managers.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - ravi-delia 4y ago
    I mean, that specific library isn't really all that hard to work with. It's not doing anything completely crazy, just somewhat unusual. But in general I think it's probably better to keep the crazy custom environment to personal projects- at least for awful utility macro libraries like mine.
    - jvanderbot 4y ago
      Narrowing down on a single library is one thing. Maybe case by case it's ok. In general if someone showed up and said "I will prototype everything in lisp and you can take it from there" I'd say they are a bit egotistical and not being much of a help to the org. Prototypes are 1% of the work. And I say this as someone whose full time job was to do research prototypes of robotics libraries for a while.
  - Twisol 4y ago
sph 4y ago
I'm waiting for WebAssembly components to be standardised then I don't care anymore. The idea is to create "libraries" written in any language that can be used by any other language, with WASM being the low level ABI. When that happens, I can go all in with Lisp because I care about my personal productivity (I have always been a lone wolf programmer) yet still being able to use code written by anyone in their comfy language. As I get older, I find I just want to mold and bend the computer to my every will, and Lisp is the tool to do so. That the resulting code is hard to understand for a junior engineer is not my concern. But one thing is for sure: I want to be able to create any abstraction, and I am done writing glue code, writing yet another PostgreSQL library for yet another language. How many date/time libraries have been written since the invention of UNIX? Imagine the amount of wasted time, money and effort. Then multiply by the number of languages that have been invented because the syntax of the previous one is too inflexible. I stand by the Lindy effect: the longer something has been around, the longer it will survive. Looking forward to Wasm Components to use a language from 1960 to its full potential. Then the goal is to have a WASM-native Lisp that can dynamically load any other WASM library, and I don't have to write yet another date/time library ever again nor care about junior engineers getting confused by crazy macros in my code. (I have been suffering from the Lisp curse for 6 months and counting. Please send help.)
- SkyMarshal 4y ago
  I sympathize, but if you're working for a company then somebody is either going to need to be able to read and understand your Lisp code, or the WASM it generates, in order to maintain it after you move on to some other company.
  - turtleyacht 4y ago
    sph probably has a clause in there to own the code. A traveling salesman among a graph of corporate nodes. Their own tools, always honed; their own solutions, always at hand.
    - xwolfi 4y ago
      But owning the code doesnt mean removing the runtime after he "blessed" the company with his proprietary "help" and some poor underpaid sob now has to "only maintain" the work of the great master. He'll code it in C or Java or Javascript and that'll be it thank you very much, so that we can maintain it forever.
brudgers 4y ago
When collaborating by the mechanisms you describe is not a priority, it is reasonably sound engineering practice to ignore those mechanisms. Though there are tradeoffs (and assuming 10x programmers exist) a ten-ex programmer can replace a team of ten one-ex programmers and eliminate mechanisms facilitating intra-team efficiency from the process. Anyway, to me the Tower of Babel is a metaphor of collective action...building construction requires teamwork. Icarus is better for lone wolves.
jcelerier 4y ago
exactly, in the author's vision the individual matters more than the group ; I couldn't disagree more with this.

Twisol 4y ago

Take one: We need people moving together just as much as we need scouts who can push ahead and find the best paths for the rest of us. Take two: Working in the best fit for your brain is not incompatible with working with others -- enough companies are Java shops, why can't there be CL shops? (There are assuredly Clojure shops at the very least.) Take three: Not everything has to be about work. Programming is a skill, not an occupation; there are lots of ways to apply programming as a skill that don't require you to build large edifices in teams.

jvanderbot 4y ago
And how nice when those scouts lay groundwork that is useful for others, rather than creating something only they can use? Yes, you may think better in lisp than c++, but that doesn't help your team when you created something and moved right along. Better to speak the same language.
- Twisol 4y ago
  I was referring to the discipline as a whole, not scouting at the granularity of a single team. Also refer to take three: working in an industrial team is not a prerequisite for an application of programming to be valid. But to your very specific point: I have in the past developed prototypes in Rust whilst on a Java-only team. It's actually a good thing: these prototypes were meant to be thrown away, so working in a different language (and one that helped me model things effectively) meant we were forced to throw it away then write it right in Java once we knew what we were doing. (We did the same thing for another feature, but it was someone else and they preferred Python. Again, we were able to prototype more rapidly and then implement a solid solution in Java once we knew how things should shake out.)
  - tlavoie 4y ago
    Another thing that is good to encourage is portable data. It's good for its own reasons, and it makes that sort of exploratory environment much more flexible. I've reimplemented a few side projects more than once, using common data back-ends because I can. I find it helps for say, messing with a new programming language, because I can apply it to a task I'm already familiar with.
- GrumpySloth 4y ago
  Better for the others, but is it better for the scouts? Too often individuals are treated as drones obliged to work for a collective, which feels entitled to the work of the drones. From your perspective, they're not a good team mate. From their perspective, they're not part of your team.
  - jvanderbot 4y ago
    I think this example is being carried to extremes unproductively. All being equal, it's better to have a team writing code that is useful to the system or project or whatever ASAP. If an individual insists on prototyping in a language that nobody else can use, then they should either carry that prototype into the team's ecosystem, or start prototyping in that ecosystem and learn to be productive that way. If option A, let's hope that "write twice" is fast enough that they are productive. If option B, they may take a productivity hit but will probably catch up. The third option of "I'll do lisp you do <teams ecosystem>" is not very pro-social. Come integration and debugging and maintenance time, that Lisp-er is not in a position to help. That's an undue burden in the rest of the team.
    - GrumpySloth 4y ago
      I think you're excessively hung up on the example of everything happening within a single team inside a single company or some such thing, when the author of the submission wrote about making a choice for themselves. You don't start coding in Lisp out of nowhere when working in a Java shop on a CRUD app. But if you're charting your own course, it's great to be able to choose whatever suits you best. I can't count the number of times someone published their open source project and inevitably people in the comments started questioning their language choices, because they wouldn't be able to use it in their "team", and how that choice is ultimately harmful for "the community". Now, you're not doing that exact thing here. I'm just thinking about how all that focus on "the team" and "the community" often goes too far. Personally, I'm not going to do anything in Common Lisp, but I'm always happy seeing other people doing their projects in that language (and many others).
      - 4y ago
- fithisux 4y ago
  So we are doing now what the others do? It defies any reason.
  - AnimalMuppet 4y ago
    If you are part of a team, then yes, do what others do. And no, it doesn't defy reason. Code is written once, but it's maintained for a long time. Or it's thrown away. But if it's thrown away because nobody else on the team knows that language, that's pretty wasteful. And if you make someone on the team learn a new language just to maintain that one program that's also wasteful. The person who insisted on using their language is optimizing for their own programming, but actually slowing down the team as a whole. We have words for that kind of behavior; they aren't compliments. Now, in any given instance, it could be that the program is much easier to write in one language, and more difficult (or even impossible) to write in others. But even in that case, if you're in an organization, you need to get buy-in from the team or management or both, rather than just doing your own thing because you can make it work. Otherwise, your program may work, but it's an orphan. You need the organization to be willing to maintain your special program, or it dies.
- spfzero 4y ago
  Sometimes hard to predict whether something that works well for you would, or would not, work well for others, and whether others could, or could not use it.

082349872349872 4y ago

Take four: what, specifically, about ergolib should prevent anyone from building on top of something written with it? [Edit: A programmer should be able to Reverse Polish Notate, nested-paren a tree, reduce some arrays, make references in nested scopes, evaluate without mutation, send a message, spin up a fail-fast supervision tree, produce finite answers from infinite graphs, synchronously react, rendezvous with logic variables, combine the above. "Specialization is for insects."]

jvanderbot 4y ago
Maintainability. If you're the only person who can edit the library, you've just created a bus factor that would be unacceptable to most project managers.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- ravi-delia 4y ago
  I mean, that specific library isn't really all that hard to work with. It's not doing anything completely crazy, just somewhat unusual. But in general I think it's probably better to keep the crazy custom environment to personal projects- at least for awful utility macro libraries like mine.
  - jvanderbot 4y ago
    Narrowing down on a single library is one thing. Maybe case by case it's ok. In general if someone showed up and said "I will prototype everything in lisp and you can take it from there" I'd say they are a bit egotistical and not being much of a help to the org. Prototypes are 1% of the work. And I say this as someone whose full time job was to do research prototypes of robotics libraries for a while.
- Twisol 4y ago

sph 4y ago

I'm waiting for WebAssembly components to be standardised then I don't care anymore. The idea is to create "libraries" written in any language that can be used by any other language, with WASM being the low level ABI. When that happens, I can go all in with Lisp because I care about my personal productivity (I have always been a lone wolf programmer) yet still being able to use code written by anyone in their comfy language. As I get older, I find I just want to mold and bend the computer to my every will, and Lisp is the tool to do so. That the resulting code is hard to understand for a junior engineer is not my concern. But one thing is for sure: I want to be able to create any abstraction, and I am done writing glue code, writing yet another PostgreSQL library for yet another language. How many date/time libraries have been written since the invention of UNIX? Imagine the amount of wasted time, money and effort. Then multiply by the number of languages that have been invented because the syntax of the previous one is too inflexible. I stand by the Lindy effect: the longer something has been around, the longer it will survive. Looking forward to Wasm Components to use a language from 1960 to its full potential. Then the goal is to have a WASM-native Lisp that can dynamically load any other WASM library, and I don't have to write yet another date/time library ever again nor care about junior engineers getting confused by crazy macros in my code. (I have been suffering from the Lisp curse for 6 months and counting. Please send help.)

SkyMarshal 4y ago
I sympathize, but if you're working for a company then somebody is either going to need to be able to read and understand your Lisp code, or the WASM it generates, in order to maintain it after you move on to some other company.
- turtleyacht 4y ago
  sph probably has a clause in there to own the code. A traveling salesman among a graph of corporate nodes. Their own tools, always honed; their own solutions, always at hand.
  - xwolfi 4y ago
    But owning the code doesnt mean removing the runtime after he "blessed" the company with his proprietary "help" and some poor underpaid sob now has to "only maintain" the work of the great master. He'll code it in C or Java or Javascript and that'll be it thank you very much, so that we can maintain it forever.

brudgers 4y ago

When collaborating by the mechanisms you describe is not a priority, it is reasonably sound engineering practice to ignore those mechanisms. Though there are tradeoffs (and assuming 10x programmers exist) a ten-ex programmer can replace a team of ten one-ex programmers and eliminate mechanisms facilitating intra-team efficiency from the process. Anyway, to me the Tower of Babel is a metaphor of collective action...building construction requires teamwork. Icarus is better for lone wolves.

jcelerier 4y ago

exactly, in the author's vision the individual matters more than the group ; I couldn't disagree more with this.