3 ms·
I think people are willing to pay for IDEs. PyCharm is a great example. But Python is wisely considered a commercially viable language whereas Lisp is... genera
by darkerside 5y ago
I think people are willing to pay for IDEs. PyCharm is a great example. But Python is wisely considered a commercially viable language whereas Lisp is... generally not.
Not to say it can't be or won't be, but most people won't pay for it for non-commercial projects, and it won't be used for commercial projects until there are many developers who consider it a good choice for commercial projects. Chicken and egg.
- chii 5y ago> won't be used for commercial projects until there are many developers this is the crux of "modern" software development. The implicit assumption by the stakeholder is that their engineers must be replaceable, and so will only choose a tech-stack which has existing engineers as a commodity. Whatever happened to specialized engineers - aka, craftsman - which you (as the stakeholder) hold on to for dear life, and pay _any_ price to keep? That is how you produce great products - talents that aren't bound by an ordinary, commodity language. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp for example, are used to produced some excellent games. But today, most AAA games are made via a commodity tech stack, and lacks the soul that would come from such a craftsman, using non-commodity stacks.
- lispm 5y agoThey early on used Allegro Common Lisp on SGIs for their game software development.
- MonkeyClub 5y ago> Whatever happened to specialized engineers - aka, craftsman - which you (as the stakeholder) hold on to for dear life, and pay _any_ price to keep? I'm not entirely certain about this, but I would say that management decided they didn't want to be "held hostage" by such craftsmen. Why pay ten times the price for a single developer, and be locked in to their presence and whims, while you can pay three times the price for three developers, and be able to manipulate them as desired? Of course, I'm not saying that's the ideal approach. It has rendered software a buggy and disposable commodity, one that both the creator and the user expect to be of limited life, aesthetic quality, and use. In software engineering, "survival of the fittest" rarely means what we would like it to mean, some beautifully crafted digital artifact that attains both immanence and permanence by the sheer force of pure virtue or something. It rather means "move fast and break things" on the back of a full stack of breakable and non-breakable things: from UX to, well, democracy, and including the well-being of the plug and play devs. Therefore Java is better than Lisp in this regard, design patterns are preferred over macros and DSLs, and a replaceable pool of fresh-out-of-school programmer are favored over an irreplaceable tenured craftsman. I (and you, and everyone of a similar bent) can certainly try and do "my bit", pour soul and art and craft into it to the limit of my abilities, and push these abilities to their next limits, by my deadlines are still going to be set by factors that don't consider craftsmanship a top driver, and I'll have to scrum alongside the other cogs to deliver and get paid on what is usually an internal proof of concept alpha christened a release on the basis of an arbitrarily chosen date. Occasionally, however, I get to brush up against the ideal for a few fleeting moments; either in code, or in thought and conversation. A glimpse of the sublime through the keyhole. But then it's time for a meeting, and a bunch of new tickets are -- ding-ding -- in my inbox. And, wouldn't you know it, that button now needs to be pink. Top priority, grab some coffee and get cracking, we need it yesterday.