5 ms·

No the demo went so badly for them that we never invited them back. I kinda felt sorry for them. They had no clue how uncompetitive they were compared with the

No the demo went so badly for them that we never invited them back. I kinda felt sorry for them. They had no clue how uncompetitive they were compared with the tools we were already using. One of the two demo guys kept going on about how better it was because it was using Lisp. While also acknowledging that it was missing pretty much all the features we needed. The “it’s easy to implement yourself because Lisp!” argument was laughable given that Maya already had the features we needed and used every day.

Jach 5y ago
> They had no clue how uncompetitive they were compared with ... Sadly not that uncommon in Lisp advocates for a number of different things even today... though I think that's been slowly changing as more Lispers either become aware of what's out there, or come with experience of what's out there and bring that knowledge with them to Lisp. The reverse direction seems to happen at least as slowly -- I've commented before that a JRebel setup is very close to bringing the still largely unique interactive development mode of Lisp over to the Java world, but it's also in important ways not fully there and may never be. Meanwhile many other languages don't even care about that development style at all. > The “it’s easy to implement yourself because Lisp!” argument was laughable I guess this would be kinda analogous to when Blender first added Python support, if they told everyone to just do expected things themselves. It may be true that such-and-such task is relatively easy to implement (if indeed it's possible to do at all without changing something about the application itself) but it's also just a terrible thing to focus sales on when the value seems like it'd mostly be measured by how useful the tool is to non-programmers. I hadn't really looked much at the "Wide Open World" doc on the archive since it's not mentioned in the other docs except vaguely in like one spot I had to search for, but if a customer had heavy scripting needs to accomplish things not already provided or easily done with the graphical tools, now the customer's not only being sold on a graphics tool but also on learning to program in Lisp using their bundled xemacs. And as you note it's even worse when that work is already done in another tool that can't be integrated with. Though I see they provided an FFI so there could be a possibility of integrating C code the customer or others wrote. If a customer was expecting to have to do a bunch of new custom stuff regardless of tool maybe it'd have made more sense... But now at least I have an additional insight into why they weren't very successful. I'm appreciating anew a lot of things the last products I worked on got right in terms of providing a good enough and frequently improving out of the box set of components and workflows while paying some attention to competitors to see what key things were lacking on either side, while streamlining development and deployment of custom components, and also providing a platform for customers to share their own custom work with each other either openly or by putting a price on it.
- mbrodersen 5y ago
  Not only that but Maya already supported custom code. I wrote a few plugins for Maya to export models and animations to our own optimised-for-N64 format. I wrote it in C (BK was all written in C). Maya also had (has?) a scripting language (called MEL I think?) that other teams used. It apparently made it super easy to do even advanced stuff. So given that, the “Lisp advantage” made even less sense. I must admit (again) that I felt really sorry for them. It is hard to watch somebody failing that badly doing a demo. But I will also say that making a sales call without first figuring out what they were up against (Maya) was a bad move. They had no clue what they were competing against. I think you are right that the “Lisp is awesome” thinking let them down the wrong path.

Jach 5y ago

> They had no clue how uncompetitive they were compared with ... Sadly not that uncommon in Lisp advocates for a number of different things even today... though I think that's been slowly changing as more Lispers either become aware of what's out there, or come with experience of what's out there and bring that knowledge with them to Lisp. The reverse direction seems to happen at least as slowly -- I've commented before that a JRebel setup is very close to bringing the still largely unique interactive development mode of Lisp over to the Java world, but it's also in important ways not fully there and may never be. Meanwhile many other languages don't even care about that development style at all. > The “it’s easy to implement yourself because Lisp!” argument was laughable I guess this would be kinda analogous to when Blender first added Python support, if they told everyone to just do expected things themselves. It may be true that such-and-such task is relatively easy to implement (if indeed it's possible to do at all without changing something about the application itself) but it's also just a terrible thing to focus sales on when the value seems like it'd mostly be measured by how useful the tool is to non-programmers. I hadn't really looked much at the "Wide Open World" doc on the archive since it's not mentioned in the other docs except vaguely in like one spot I had to search for, but if a customer had heavy scripting needs to accomplish things not already provided or easily done with the graphical tools, now the customer's not only being sold on a graphics tool but also on learning to program in Lisp using their bundled xemacs. And as you note it's even worse when that work is already done in another tool that can't be integrated with. Though I see they provided an FFI so there could be a possibility of integrating C code the customer or others wrote. If a customer was expecting to have to do a bunch of new custom stuff regardless of tool maybe it'd have made more sense... But now at least I have an additional insight into why they weren't very successful. I'm appreciating anew a lot of things the last products I worked on got right in terms of providing a good enough and frequently improving out of the box set of components and workflows while paying some attention to competitors to see what key things were lacking on either side, while streamlining development and deployment of custom components, and also providing a platform for customers to share their own custom work with each other either openly or by putting a price on it.

mbrodersen 5y ago
Not only that but Maya already supported custom code. I wrote a few plugins for Maya to export models and animations to our own optimised-for-N64 format. I wrote it in C (BK was all written in C). Maya also had (has?) a scripting language (called MEL I think?) that other teams used. It apparently made it super easy to do even advanced stuff. So given that, the “Lisp advantage” made even less sense. I must admit (again) that I felt really sorry for them. It is hard to watch somebody failing that badly doing a demo. But I will also say that making a sales call without first figuring out what they were up against (Maya) was a bad move. They had no clue what they were competing against. I think you are right that the “Lisp is awesome” thinking let them down the wrong path.