47 ms·

I was disappointed by how much of the previous discussion [1] avoided what (in my reading) was the most interesting point -- the absolute situated and interacti

I was disappointed by how much of the previous discussion [1] avoided what (in my reading) was the most interesting point -- the absolute situated and interactive nature of development which almost no other language/system supports. (Hell, it was even in the damn title!) It would be really nice to see a thorough discussion focusing on that. ---- In the spirit of the author's desire to "get weird", I’m struck by how often people’s choice of programming languages (and tools, more generally) is from a defensive stance. I understand that when working on problems where better technology is unlikely to lead to significant advantages (so you’d prefer to cap the potential downsides), but I’m still surprised by the sheer paucity of examples where people are willing to make aggressive technology choices to get leverage on their goals, and solve interesting & worthwhile problems. ---- [1]: https://news.ycombinator.com/item?id=28345617 https://news.ycombinator.com/item?id=28345617

tialaramex 5y ago
In the same way that in theory "This language can do everything" seems good but "This languages does only one thing, very well" often works out better I think that in practice you more often benefit from building special purpose tools than just always having the REPL. In the video game examples, that would include "god mode" and the family of similar cheats. A clear benefit of such tools over a REPL is that they're something you can realistically train non-programmers to use. You can even polish them up and ship them in the finished product if you choose to do so. On getting weird: If you work in a team, choices affect the whole team. So you need a rationale for moving the whole team (or, a rationale for why it's OK that your work is in one language but everybody else uses a different language). The bigger wins are generally going to be from paradigm shifts, so we're talking about a fundamental shift to how those team members think about programming. Unless you're hiring from scratch for new work.
rodgerd 5y ago
> In the spirit of the author's desire to "get weird", I’m struck by how often people’s choice of programming languages (and tools, more generally) is from a defensive stance. "I want to get weird" is great for a hobby, but if it was said as a justification for Perl rather than LISP, I doubt it's a sentiment that would get the time of day.

tialaramex 5y ago

In the same way that in theory "This language can do everything" seems good but "This languages does only one thing, very well" often works out better I think that in practice you more often benefit from building special purpose tools than just always having the REPL. In the video game examples, that would include "god mode" and the family of similar cheats. A clear benefit of such tools over a REPL is that they're something you can realistically train non-programmers to use. You can even polish them up and ship them in the finished product if you choose to do so. On getting weird: If you work in a team, choices affect the whole team. So you need a rationale for moving the whole team (or, a rationale for why it's OK that your work is in one language but everybody else uses a different language). The bigger wins are generally going to be from paradigm shifts, so we're talking about a fundamental shift to how those team members think about programming. Unless you're hiring from scratch for new work.

rodgerd 5y ago

> In the spirit of the author's desire to "get weird", I’m struck by how often people’s choice of programming languages (and tools, more generally) is from a defensive stance. "I want to get weird" is great for a hobby, but if it was said as a justification for Perl rather than LISP, I doubt it's a sentiment that would get the time of day.