Monday, December 3, 2018

5 Reasons why Lisp Games Suffer and proposed solution

Lisp games, like the Lisp AI and Lisp Machine hype in the 1980's, has proven yet again to fail to deliver.

Let's say I'm a lisp noob, or even an average gamer. I think, hey, what's the state of Lisp in games? So I do some google searches:

"lisp games"
"lisp game engine"
"common lisp game engine"
"lisp game engine"

The following are some case studies from results that turn up:

Case studies 

  1. The Poverty of #Lispgames 
  2. Outnumbered by Blub
  3. Google Search Poor Examples
  4. The Sorry Tale of Those Who Tread the Great Lisp Path
  5. Difficult to install, difficult to run, difficult to edit, difficult to use
Conclusion:  What would a successful Common Lisp game engine IDE look like?

The Poverty of #Lispgames

TLDR: Lisp games has many channels, but not enough content

Lispgames accounts turn up a lot.
There's the lispgames twitter, wiki, group, irc, subreddit

Then there's lisp game jams 
https://news.ycombinator.com/item?id=16819226
https://github.com/lispgames/lispgames.github.io/wiki/Lisp-Game-Jams
https://itch.io/jam/lisp-game-jam-2018

But where are the games?

There are many lispgames accounts and lisp game jams but few games. There are 14 games on the lispgames wiki and 70 from all game jams = 84 games. Lispgames has existed since 2010, 8 years ago. That's about 10 games per year, or 1 small game every month.


Outnumbered by Blub

TLDR: For every lisp game, there are 10,000 blub language games. So much for being a "powerful" language.

How many C++ games are there? Java? Flash? Javascript? c? A search on github for "game" [dec 3 2018] results in 861,000 repositories. How many for "lisp game"? 379. There are 18.2 million programmers in the world, and 3.5 million github accounts, that is around 1/5 of programmers using github. So lets assume there are 5 * (379 github lisp games + 84 lispgame game jam + wiki) lisp games. That is 2315 in total.  2315 games in the world

How many games exist for other languages? (861,000 github repositories * 5 estimated programmers per github programmer) + 1,000,000 android apps that are likely games = around 5,305,000. If we add things like scratch, 36,273,545 scratch projects, its around 40,000,000. What about flash games? Java applets? HTML5 games? My guess is there are hundreds of millions of games made in the entire world. 

 Lets say there are 10,000 lisp games that have ever existed, but it seems like an over estimate. And there are 100,000,000 million games that have ever existed, which is probably an underestimate. (10^8)/(10^4) = 10,000.

Google Search Poor Examples

TDLR: Many of the lisp "game engines" which are on the front page of google do not demonstrate the power of lisp, they are toys or demos.
See: xelf, blackthorn, sketch.

The Sorry Tale of Those Who Tread the Great Lisp Path

TDLR: Ambition unrewarded

Rewarded for leaving CL for IOS:
There's this guy who paid for LispWorks, had to write his own OpenGL bindings, and eventually moved to ios to create mekorama, which has more than 3 million views on youtube and has been installed on millions of devices. So much for sticking to common lisp.

Gave up on extremely ambitious engine for Unreal:
There was Clinch, that had ambitious goals, and there were nice 3d demos, but the author moved to seems to have abandoned it and moved to Unreal. youtube before. youtube after . I also remember reading somewhere we he recommends CEPL instead.

Poor video editing:
Trial looks promising, as in trial's youtube demonstrations. But the only games that have been shared are here. Then there's shinmera's treehouse which is like a trial tutorial, but each video is an uncut 2 hours, and there are 39 of them. 2* 36 = 80 hours/ 13 hours watching a day = would take an entire week to watch

Is Baggers leaving?:
CEPL looks promising. However, it is starting to look like the author is moving away from CEPL towards TaleSpire.

Difficult to install, difficult to run, difficult to mod, difficult to use

TDLR: There must be an extremely simple installation process.

Most lisp games require a working knowledge of quicklisp, common lisp, common lisp implementations, and the command line. And in order to mod the game you most likely need SLIME + emacs. This basically equates to a tiny subset of Linux users. Where is the one-click install for Windows? Like having a single .exe that just runs? Downloading, running, and modding needs to be a dead simple process, as simple as possible. Complexity of installation drives users away and wastes loads of time. Think of how hard it is to set up a development environment on windows. Examples of projects trying to address this problem are portacle, quicklisp, and roswell.

Summary

Lisp games has the social media infrastructure but no content. Despite the proclaimed "power" of lisp, lisp games are less than 0.01 % of market share. Google search does lisp games no favor by providing toy examples. Those who have attempted to create an ambitious CL engine so fervently abandon it at the drop of a hat when they are tempted. Tutorials are lacking. And worst of all, lisp games all basically require time and effort to install and experience with linux, CL implementations, CLHS, quicklisp, and SLIME and emacs.

What could a successful Common Lisp game engine IDE look like? 

TDLR: One click install. Runs on Windows. Portable Common Lisp. Portable editor. Very few dependencies. State of the art OpenGL graphics. Dedicated quicklisp installation. Trivial game servers.


- One click install Common Lisp game + IDE on windows, in a similar vein to portacle, but only using SDL2, libffi, and a Common Lisp implementation
- Run on Windows with 96% steam market share. Instead of just Linux, which is around 1.5% desktop market share. 96 / 1.5 = 64, which means the Common Lisp games, instead of being confined to Linux, might run in an area 64 times larger.
- CEPL for graphics
- lem editor using CEPL as a frontend, replacing the arcane installation for emacs
- quicklisp as package manager

Friday, November 30, 2018

What does it take to understand the true power of [Common] Lisp?

Originally posted as a comment on reddit: link

In order to understand the true power of Common Lisp, you must understand its greatest weakness.
Common Lisp is unrestrained power. What does this mean? Any one can make a huge mess since there are macros, eval, CLOS, etc. People coming from overly restricted languages like C++ can and will use every "powerful" feature they find to walk code, change semantics of the language, repackage built-in symbols, and do all other sorts of impossible nonsense. Why does this happen? Because when you are weak, like a C++ developer, you never learn restraint. Because of this, Common Lisp suffers from a management problem. If all your developers are using a weak language, there is only so much damage one developer can do. Here is a similar idea by Fare who pointed out that CL is a "hippie language". He has experience managing CL projects with ASDF. There was another blog post by another author about how CL is too powerful but I can't seem to find it.

If all developers could exercise restraint then perhaps Common Lisp could flourish. But this is like saying if everyone in the world was good there would be world peace. That will never, ever happen, except if your world if small enough or everyone is homogeneous. This is why Common Lisp projects start small and stay small. It's like communism, you need everyone to follow the rules. Thus the link between communism, open source, and common lisp.

However, there might be hope for a solution in a lisp that incrementally adds power [at one point the X3J13 committee was debating whether common lisp should be separated into different parts like a "core"] and/or permissions/capabilities like scheme48. I think it was Paul Graham who said that as time passes, weak languages like C++ absorb features from common lisp. Or see Greenspun's tenth rule. In common lisp, everybody gets absolute power no matter what, their is no social hierarchy, thus no government, it's anarchy. That's why fundamentally weak languages with things tacked to mimic Common Lisp on succeed economically but Common Lisp does not. Self plug: I'm trying to figure out how a lisp bytecode interpreter could have capabilities, not extensively, but similar to the JVM.

TLDR: To understand the true power of Common Lisp, you MUST exercise restraint, otherwise you will make a complete mess of things while you are inexperienced.

Friday, November 16, 2018