[Seattle] Fwd: Seattle CL People?
Oops, meant to send to the list. On Thu, Feb 12, 2015 at 8:32 PM, Clint Moore <clint@ivy.io> wrote:
Am I the only human left on this list?
I'm on the list. But I've not been in Seattle since 2007, and the last time I remember attempting to do something with a lisp community was in a similar time period. I remember there being some guy who had worked on a lisp distro packaging technology, me getting on his mailing list, and me getting kicked off his mailing list. I probably said something about how I thought a packaging system should work.
That would be rather sad.
It's still sad. Actually I say I'm designing my own language now, something "better than assembly code". But not much progress lately. As of a few years ago, my assessment of the Common Lisp universe was that anyone who once had the energy for standards, promotion, adoption, etc. is now too old, and past their generational energy, to bother with such things. New generations learn their own things, and although they may use many design ideas of lisp, they're just not going to use Common Lisp for the most part. For instance, Julia claims some lisp ancestry. http://julialang.org/ Cheers, Brandon Van Every
On Fri, Feb 13, 2015 at 7:22 AM, Brandon Van Every <bvanevery@gmail.com> wrote:
As of a few years ago, my assessment of the Common Lisp universe was that anyone who once had the energy for standards, promotion, adoption, etc. is now too old, and past their generational energy, to bother with such things. New generations learn their own things, and although they may use many design ideas of lisp, they're just not going to use Common Lisp for the most part. For instance, Julia claims some lisp ancestry. http://julialang.org/
It strikes me as rather sad that, while it's stylish to declare that a language borrows ideas from CL, it's not stylish at all to actually use it.
On Fri, Feb 13, 2015 at 1:10 PM, Clint Moore <clint@ivy.io> wrote:
On Fri, Feb 13, 2015 at 7:22 AM, Brandon Van Every <bvanevery@gmail.com> wrote:
As of a few years ago, my assessment of the Common Lisp universe was that anyone who once had the energy for standards, promotion, adoption, etc. is now too old, and past their generational energy, to bother with such things. New generations learn their own things, and although they may use many design ideas of lisp, they're just not going to use Common Lisp for the most part. For instance, Julia claims some lisp ancestry. http://julialang.org/
It strikes me as rather sad that, while it's stylish to declare that a language borrows ideas from CL, it's not stylish at all to actually use it.
I think a reality of software that some techies have a hard time acknowledging, is that they're social processes. "Technical merit" doesn't get very far in the social world. We all know that languages with deep pocketed corporations behind them see widespread adoption, unless the language *truly* sucks. An average and uninspired language with a corporate backer will be promulgated far and wide. Many other patterns of adoption are social; "worse is better" has a social analysis. But I do think the dearth of Common Lisp is fundamentally generational. New programmers want to make their mark, and they aren't intellectually invested in what came before, at least not a priori. Stakeholders in Common Lisp have aged out. There's also enough cumbersome and unwieldy about Common Lisp to envision something "better", if one is being honest. But what is "better" ? Go the Scheme route, and eventually you discover that it's not enough to do big picture industrial everything and the kitchen sink kind of development. So then the Scheme communities try to "modernize" and it starts to look like they're walking towards Common Lisp. Maybe where they end up isn't as bloated. Or maybe they don't end up in a similar place at all, even though it looks superficially like they might, because they're a distinct community in time with specific problems they're interested in. How much "betterness" does one throw at something? Most language designers don't seem to be fans of incrementalism, just gradually improving something that already exists. There's no early career credit for that sort of thing, no way to stand out from the crowd. Also there's the problem of controlling one's destiny in the face of other stakeholders. For instance, if you're "merely" improving the build system for a language primarily authored by someone else, and that author decides he doesn't like the build system after all, guess who's shown the door? Social process again. The merit of various components is not likely to be objective, it's probably all down to subjective criteria and design tradeoffs. Tradeoffs create developer drama and heads roll. Or, only the most patient people can stand to put up with committee / standardization dynamics, and to what ultimate end? Cheers, Brandon
That's very well put. I suspect I'll be mulling "There's no early career credit for that sort of thing, no way to stand out from the crowd." for quite some time.
"Technical merit" doesn't get very far in the social world.
And no amount of me standing with my fist in the air (other hand possibly steadying myself with a cane) and yelling "But it should, damnit!" is going to change that. On Fri, Feb 13, 2015 at 1:40 PM, Brandon Van Every <bvanevery@gmail.com> wrote:
On Fri, Feb 13, 2015 at 1:10 PM, Clint Moore <clint@ivy.io> wrote:
On Fri, Feb 13, 2015 at 7:22 AM, Brandon Van Every <bvanevery@gmail.com> wrote:
As of a few years ago, my assessment of the Common Lisp universe was that anyone who once had the energy for standards, promotion, adoption, etc. is now too old, and past their generational energy, to bother with such things. New generations learn their own things, and although they may use many design ideas of lisp, they're just not going to use Common Lisp for the most part. For instance, Julia claims some lisp ancestry. http://julialang.org/
It strikes me as rather sad that, while it's stylish to declare that a language borrows ideas from CL, it's not stylish at all to actually use it.
I think a reality of software that some techies have a hard time acknowledging, is that they're social processes. "Technical merit" doesn't get very far in the social world. We all know that languages with deep pocketed corporations behind them see widespread adoption, unless the language *truly* sucks. An average and uninspired language with a corporate backer will be promulgated far and wide. Many other patterns of adoption are social; "worse is better" has a social analysis. But I do think the dearth of Common Lisp is fundamentally generational. New programmers want to make their mark, and they aren't intellectually invested in what came before, at least not a priori. Stakeholders in Common Lisp have aged out.
There's also enough cumbersome and unwieldy about Common Lisp to envision something "better", if one is being honest. But what is "better" ? Go the Scheme route, and eventually you discover that it's not enough to do big picture industrial everything and the kitchen sink kind of development. So then the Scheme communities try to "modernize" and it starts to look like they're walking towards Common Lisp. Maybe where they end up isn't as bloated. Or maybe they don't end up in a similar place at all, even though it looks superficially like they might, because they're a distinct community in time with specific problems they're interested in.
How much "betterness" does one throw at something? Most language designers don't seem to be fans of incrementalism, just gradually improving something that already exists. There's no early career credit for that sort of thing, no way to stand out from the crowd.
Also there's the problem of controlling one's destiny in the face of other stakeholders. For instance, if you're "merely" improving the build system for a language primarily authored by someone else, and that author decides he doesn't like the build system after all, guess who's shown the door? Social process again. The merit of various components is not likely to be objective, it's probably all down to subjective criteria and design tradeoffs. Tradeoffs create developer drama and heads roll. Or, only the most patient people can stand to put up with committee / standardization dynamics, and to what ultimate end?
Cheers, Brandon
_______________________________________________ Seattle mailing list Seattle@common-lisp.net https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/seattle
On Fri, Feb 13, 2015 at 4:51 PM, Clint Moore <clint@ivy.io> wrote:
"Technical merit" doesn't get very far in the social world.
And no amount of me standing with my fist in the air (other hand possibly steadying myself with a cane) and yelling "But it should, damnit!" is going to change that.
I've given up. Really. My last round of trying to figure out whether someone else's language was worth something, was a tour of Julia, Clojure, Rust, and Scala. Julia is LLVM based and claims a lot of stuff, but when you dig down you realize they don't have incremental garbage collection yet. They just have "stop the world" garbage collection which is totally inappropriate for soft realtime systems, i.e. games. Their target market is to replace Fortran and Matlab. They can get away with offline batch processes where only "throughput overall" matters, latency at the moment doesn't. So they can make all kinds of performance claims, but my real world problems don't currently match their real world problems, and nothing says they ever have to get there. I'll keep my eye on it, but I'm not expecting them to deliver in a timeframe that matters to me. It's a young language. Rust is LLVM based as well. I can't remember my specific objections to it, although I know I've written them down somewhere. My impression is that it's pretty "early days" for the language. Clojure is a lisp on top of the JVM. I'm a performance oriented guy. Apparently in their culture, if they want something to go fast, they throw it over the fence to Java. Which isn't saying that much. I just don't expect them to ever embrace my game developer concerns. Scala is a FP language on top of the JVM, with more concern for performance. It's also more mature, it's been around longer. I don't think I either rejected or accepted it. My issues were compounded by me ditching Linux after a 3 year experiment and going back to Windows. "What's going to play well with MSVC and DirectX?" became noteworthy issues, and I don't remember the Scala ecology providing good answers. YMMV per what you actually need your language for. The game industry pretty much stagnated in C++. C++ has added some features over time, which also adds complexity to an already too complex language. I'm simply not a fan. Could also be that growth in the gaming industry has been in the mobile space, a segment I hate for its wimpy devices, small screens, and short attention span players. I'm a desktop gamer. Anyways I think the lack of any serious need of resources in the mobile space, has probably meant people can implement those kinds of games in "whatever" and don't really have to think about performance. Cheers, Brandon
On Fri, Feb 13, 2015 at 3:29 PM, Brandon Van Every <bvanevery@gmail.com> wrote:
I've given up. Really.
Don't do that, you have to remain optimistic! Sure, there's a lot of stuff that isn't exactly what you want, but there are a ton of really good ideas. And hey, if you lack optimism, there's quite a few tools out there that will help you write your own language - LLVM chief among them. It seems interesting to note that, in the vein of game development, NVIDIA's CUDA compiler is written on top of llvm. https://developer.nvidia.com/cuda-llvm-compiler When you're about to give up, try to remember that you're living in 'the future' and the idea of creating your own language to solve a problem like yours isn't quite so crazy as you might have been led to believe. Then again, there's Haskell, which might very well be a good solution these days. There's a 4 year old thread on SO at the bottom of this message if you're curious. Haskell is my #2 language, especially when speed is a concern. I had thought I had grown out of evangelizing languages but here we are: Haskell is worth the effort, but that's just my opinion. http://gamedev.stackexchange.com/questions/374/what-are-the-challenges-and-b...
On Fri, Feb 13, 2015 at 7:29 PM, Clint Moore <clint@ivy.io> wrote:
And hey, if you lack optimism, there's quite a few tools out there that will help you write your own language - LLVM chief among them.
My view of LLVM is it's not a "tool", it's a commitment to a *huge* chunk of code and infrastructure. A rather particular way of doing things that embodies a highly industrialized mentality for how a language developer will spend his/her time. This ain't a clean bootstrap ala a Forth or Scheme.
It seems interesting to note that, in the vein of game development, NVIDIA's CUDA compiler is written on top of llvm. https://developer.nvidia.com/cuda-llvm-compiler
Sure, but unless NVIDIA is giving that code away, or unless you're going to write all your game logic in shader or GPGPU stuff, who cares? I think it says something about writing low level 3D graphics code, but that's only part of game development. An AI for instance, why would you commit the architecture of that to a GPU? Even more generalized geometry processing or game physics, you have to be careful what you lock yourself into. Also whether you've lost track of what the game is and are just writing tech sim code.
Then again, there's Haskell, which might very well be a good solution these days. There's a 4 year old thread on SO at the bottom of this message if you're curious. Haskell is my #2 language, especially when speed is a concern.
I'm trying to remember why I last gave up on Haskell, other than the usual weirdness issues. I think because, FP purity doesn't seem relevant to game simulations? Keeping and modifying state seems to be what many games actually are. Then there are some practical issues like garbage collection behavior and whether anybody bothered to talk to DirectX. Cheers, Brandon
On Sat, Feb 14, 2015 at 9:29 AM, Brandon Van Every <bvanevery@gmail.com> wrote:
On Fri, Feb 13, 2015 at 7:29 PM, Clint Moore <clint@ivy.io> wrote:
And hey, if you lack optimism, there's quite a few tools out there that will help you write your own language - LLVM chief among them.
My view of LLVM is it's not a "tool", it's a commitment to a *huge* chunk of code and infrastructure. A rather particular way of doing things that embodies a highly industrialized mentality for how a language developer will spend his/her time. This ain't a clean bootstrap ala a Forth or Scheme.
It seems interesting to note that, in the vein of game development, NVIDIA's CUDA compiler is written on top of llvm. https://developer.nvidia.com/cuda-llvm-compiler
Sure, but unless NVIDIA is giving that code away, or unless you're going to write all your game logic in shader or GPGPU stuff, who cares? I think it says something about writing low level 3D graphics code, but that's only part of game development. An AI for instance, why would you commit the architecture of that to a GPU? Even more generalized geometry processing or game physics, you have to be careful what you lock yourself into. Also whether you've lost track of what the game is and are just writing tech sim code.
Then again, there's Haskell, which might very well be a good solution these days. There's a 4 year old thread on SO at the bottom of this message if you're curious. Haskell is my #2 language, especially when speed is a concern.
I'm trying to remember why I last gave up on Haskell, other than the usual weirdness issues. I think because, FP purity doesn't seem relevant to game simulations? Keeping and modifying state seems to be what many games actually are. Then there are some practical issues like garbage collection behavior and whether anybody bothered to talk to DirectX.
Ok then. Nevermind.
On Sat, Feb 14, 2015 at 1:25 PM, Clint Moore <clint@ivy.io> wrote:
I'm trying to remember why I last gave up on Haskell, other than the usual weirdness issues. I think because, FP purity doesn't seem relevant to game simulations? Keeping and modifying state seems to be what many games actually are.
Ok then. Nevermind.
This is the core point worth discussing, as pure vs. impure and strict vs. lazy can definitely impact certain application areas. I did go around the block with OCaml back in the day. My issues with it were more on the practical implementation side. It had a tedious C FFI that wanted to steal bits of numerical representations for its own GC benefit, and IIRC it didn't believe in single precision floats. Those were pretty important to the memory and processing constraints of games 10 years ago, and probably still are now. F# came along and I've looked at that more than once. I've always been struck by how lackluster the interfacing to the DirectX universe is from the .NET side of things though. First MS pretty much made a turkey of Managed DirectX. Then they shipped XNA for several years, got a fair amount of indie interest, and then abandoned it. The leading DirectX / .NET bridge is a third party library, SharpDX. SlimDX was another one but IIRC they're in remission now. Going the .NET route, you still deal with GC. I looked at some of the F# benchmarks recently and I don't remember them being all that great. Pretty sure I looked at Haskell benchmarks too recently. Cheers, Brandon
So what implementations of CL are people using? I've been toying with ClozireCL and SBCL, but I would love to do some Lisp on my mobile device. Jay — Sent from Mailbox On Sat, Feb 14, 2015 at 1:45 PM, Brandon Van Every <bvanevery@gmail.com> wrote:
On Sat, Feb 14, 2015 at 1:25 PM, Clint Moore <clint@ivy.io> wrote:
I'm trying to remember why I last gave up on Haskell, other than the usual weirdness issues. I think because, FP purity doesn't seem relevant to game simulations? Keeping and modifying state seems to be what many games actually are.
Ok then. Nevermind.
This is the core point worth discussing, as pure vs. impure and strict vs. lazy can definitely impact certain application areas. I did go around the block with OCaml back in the day. My issues with it were more on the practical implementation side. It had a tedious C FFI that wanted to steal bits of numerical representations for its own GC benefit, and IIRC it didn't believe in single precision floats. Those were pretty important to the memory and processing constraints of games 10 years ago, and probably still are now. F# came along and I've looked at that more than once. I've always been struck by how lackluster the interfacing to the DirectX universe is from the .NET side of things though. First MS pretty much made a turkey of Managed DirectX. Then they shipped XNA for several years, got a fair amount of indie interest, and then abandoned it. The leading DirectX / .NET bridge is a third party library, SharpDX. SlimDX was another one but IIRC they're in remission now. Going the .NET route, you still deal with GC. I looked at some of the F# benchmarks recently and I don't remember them being all that great. Pretty sure I looked at Haskell benchmarks too recently. Cheers, Brandon
I'm using sbcl, and waiting for llvm to build so I can build clasp. For mobile, I've heard mixed opinions about mocl. It got a lot of attention when it was released, but I didn't, and still don't, have the resources (money) to spend on an implementation that I can't try first. If someone has it, I'd love to see it in action sometime. On Sat, Feb 14, 2015 at 2:34 PM, Jay Kint <bilbo@hobbit-hole.org> wrote:
So what implementations of CL are people using? I've been toying with ClozireCL and SBCL, but I would love to do some Lisp on my mobile device.
Jay
— Sent from Mailbox <https://www.dropbox.com/mailbox>
On Sat, Feb 14, 2015 at 1:45 PM, Brandon Van Every <bvanevery@gmail.com> wrote:
On Sat, Feb 14, 2015 at 1:25 PM, Clint Moore <clint@ivy.io> wrote:
I'm trying to remember why I last gave up on Haskell, other than the usual weirdness issues. I think because, FP purity doesn't seem relevant to game simulations? Keeping and modifying state seems to be what many games actually are.
Ok then. Nevermind.
This is the core point worth discussing, as pure vs. impure and strict vs. lazy can definitely impact certain application areas.
I did go around the block with OCaml back in the day. My issues with it were more on the practical implementation side. It had a tedious C FFI that wanted to steal bits of numerical representations for its own GC benefit, and IIRC it didn't believe in single precision floats. Those were pretty important to the memory and processing constraints of games 10 years ago, and probably still are now.
F# came along and I've looked at that more than once. I've always been struck by how lackluster the interfacing to the DirectX universe is from the .NET side of things though. First MS pretty much made a turkey of Managed DirectX. Then they shipped XNA for several years, got a fair amount of indie interest, and then abandoned it. The leading DirectX / .NET bridge is a third party library, SharpDX. SlimDX was another one but IIRC they're in remission now. Going the .NET route, you still deal with GC. I looked at some of the F# benchmarks recently and I don't remember them being all that great.
Pretty sure I looked at Haskell benchmarks too recently.
Cheers, Brandon
_______________________________________________ Seattle mailing list Seattle@common-lisp.net https://mailman.common-lisp.net/cgi-bin/mailman/listinfo/seattle
On Tue, Feb 17, 2015 at 3:08 AM, Clint Moore <clint@ivy.io> wrote:
I'm using sbcl, and waiting for llvm to build so I can build clasp.
A LLVM infrastructure might be a healthy development. One of those "wait and see" propositions though. Clasp upon its release was cautioning it was 100x slower than SBCL. Clasp 0.2 claims a "2x" improvement over something; does that mean it's now only 50x slower? https://drmeister.wordpress.com/2015/01/25/release-0-2-of-clasp-is-available... I'll leave it to others to chase down the benchmarks. I just expect these things to take a long time to bear fruit. Like the Julia guys for instance, their performance claims and desire to compete with FORTRAN sound great, until you drill down and realize they only have "stop the world" garbage collection. Meaning, they haven't even gotten into the real work yet. Cheers, Brandon
participants (3)
-
Brandon Van Every -
Clint Moore -
Jay Kint