HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kaveh808
kons-9
Common Lisp2022–2026
kaveh808 / kons-9

kons-9

Common Lisp 3D Graphics Project

8Distinct people
30Mentions
2Explicit recommenders
658GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Common Lisp 3D Graphics Project

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

Common Lisp is a curious creature. Ancient in some ways, prescient in others. It is not perfect by any means, and politics did play a large part in the 10-year ANSI…

kaveh808 used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year30 dated mentions

Observed mentions: 2022-06-14 23:38:27 UTC to 2026-08-26 21:08:37 UTC.

0510152022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 12 mentions; 5 submissions, 7 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 16 mentions; 2 submissions, 14 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20242025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC1257
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC16214
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

30 sources
I have always viewed the Emacs/Slime/CL development environment as being a more frictionless approach than the compile/link/execute approach of most other languages, but I get the impression there are people who evangelize "image-based coding" without having tried it out themselves. The idea of not maintaining properly documented sources would terrify me. As people point out, if you are not careful and execute arbitrary code in the REPL, your source and image can drift out of sync. When I was working on [1], I would go days without relaunching my image, but all the development was done by evaluating code in Emacs buffers and seeing the results right away. Occasionally, things got convoluted enough that I relaunched the process as a sanity check. For me, the real benefit of iteratively modifying a live image lies in the sense of flow it en
Read the rest
genders. I have not felt that sense in languages other than CL. I sometimes explain the feeling by saying than CL is the only language that I don't feel is fighting me. [1] https://github.com/kaveh808/kons-9
In A curmudgeon tries a language server
"Vulkan represents a low-level way of talking to the GPU more or less on the GPU's terms. As opposed to OpenGL which is a way of talking to the GPU on boomer CAD programmers' terms." Kind of like that description. I've been doing GL since before it was OpenGL. In my Common Lisp 3D system [1], I've been happily using very simple immediate mode OpenGL calls, taking advantage of CAD-like features such as drawing wireframes of various thickness over shaded polygons. OpenGL provides specific Z-buffer API calls to facilitate such things. Is there a simple way of doing such CAD-centric things in Vulkan? [1] https://github.com/kaveh808/kons-9
In Vulkan Documentation
"He can see far; further than in fact his strength allows him to travel. He conceives of brilliant ambitious projects requiring great resources, and he embarks on them only to run out of steam. It's not that he's lazy; its just that his resources are insufficient." This speaks to me. As I get older, I am tempted to start curating a list of my "failed" (or abandoned) projects. I have been fortunate enough to launch an open-source 3D graphics Lisp project late in life which has managed to keep my interest. Early on, I made a number of conscious decisions about how I would view this project and avoid some mistakes of my past. - No comparing to existing 3D packages. It's evident that I can't compete with commercial packages with decades of programmer effort. - No hunting for a "better" language (though this hasn't really been a problem). A
Read the rest
goal of the project is to develop a system where I can bring the power of Common Lisp to bear on 3D graphics. In some ways this is a throwback of work I did developing 3D graphics on Symbolics Lisp Machines back at the MIT Media Lab [0]. Returning to my youth? - Keep it simple. Or, does it need to be more complicated? Understandable code is a benefit, as is code you can (mostly) keep in your head. Avoid excessively clever code, which I have been guilty of in the past (macros, anyone?). Also (more controversially) avoid dependencies where possible; keep it in house. - Build a community. Having others involved is the best way I have found for not running out of steam. My other projects have invariably been solo efforts. Now I am interested in creating something which will outlast me. Hence the decision to put the project on Github [1]. - This "thing" has value in and of itself, and doesn't need to be "better" than what is out there. By virtue of being different enough, it is a worthwhile project to bring into existence. The world probably doesn't need another browser-based JavaScript package. - Keep the momentum going by working on whatever interests me at the time. Avoiding tedious development and yak shaving keeps me from losing motivation. I do realize the article touches on this as a weakness of the Lisp developer mindset, and I admit to not being motivated to build an industrial-strength system. E.g. my half-baked GUI built on top of raw OpenGL. - Finally (have to stop sometime), don't overthink things. Enjoy the journey. I am enjoying enhancing the system while not fretting over who will use it or for what purpose. The journey is the destination. [0] https://medium.com/@kaveh808/late-night-lisp-machine-hacking... [1] https://github.com/kaveh808/kons-9
In The Bipolar Lisp Programmer (2007)
I work in a slightly different way by always saving my code in emacs and loading it fresh each session (though I have gone a couple of weeks with a live image/session on my laptop). I am fortunate that my 3D system [0] compiles and loads in a few seconds. I also use the REPL for quick tests, and evaluate new code by writing it in emacs and compiling it one function at a time (C-c C-c). Finally, I keep files of tutorial/demo/test cases which work a bit like a notebook, allowing me to quickly verify that existing 3D scenes still work. [0] https://github.com/kaveh808/kons-9
In The Bipolar Lisp Programmer (2007)
kaveh808·Aug 3, 2023Recommendation phrase
Common Lisp is a curious creature. Ancient in some ways, prescient in others. It is not perfect by any means, and politics did play a large part in the 10-year ANSI standardization process. At the end of the day, for me, what makes it my favorite language is the principle that the language should provide the maximum possible power to the programmer, boosting productivity of (most evidently) the individual developer. It has served me well in my 3D graphics project [0], which is different enough from what is out there that it does feel like a worthwhile endeavor. [0] https://github.com/kaveh808/kons-9
In Common Lisp: The Good, the Bad, the Ugly, the Legacy, the Ambivalent
I began my 3D graphics development on a Symbolics workstation at the MIT Media Lab in the mid-80's. This was before the S-Graphics suite was released. [0] The outstanding feature of the S-Graphics suite was the polygonal modeler which used a winged-edge structure that was far ahead of its time. It survives conceptually in the Wings3D system, which is a quite faithful copy of that modeler. And of course you got the extensibility that came with the graphics system being built on Lisp. But Symbolics was never, as far as I saw, a serious or popular contender in 3D production. Not only was the system expensive, but the hardware could not keep up with SGI's graphics abilities. Furthermore, the mass of CG developers at the time came from a C/Unix background, and rendering especially was so speed critical that C (and Fortran) resulted in faster s
Read the rest
ystems. Almost 40 years later, I have returned to the idea of developing a 3D system in Common Lisp [1]. We shall see where it leads. [0] https://medium.com/@kaveh808/late-night-lisp-machine-hacking... [1] https://github.com/kaveh808/kons-9
In Symbolics Lisp Machines Graphics Demo (1990) [video]
Older developer here (I started my career by writing 3D graphics software in the mid-80's). I recently spent a number of years in semi-retirement, concentrating on my photography [0] and filmmaking [1] and thinking I was done with (and too old for) software development. Professional software development had lost its lure for me as the CG and VFX industry had grown into a massive factory-like industry. Though I had worked on some satisfying projects -- writing the animation code used in "Jurassic Park", leading the R&D team for "Final Fantasy: The Spirits Within", working on "The Hobbit" movies -- I had lost the desire to write software. Then about a year ago a friend asked me to teach him some Common Lisp online. So I wrote some tutorials and as we did our sessions [2] I got increasingly enthusiastic about developing for fun, especially i
Read the rest
f I could use the tool of my choice (Common Lisp) for the domain of my choice (computer graphics). So I started a new 3D graphics project and made it open source [3]. Even started a blog about the journey [4]. Although I don't consider myself to be up on the latest buzzwords and web architectures and the only scrum I'm familiar with is from my rugby-playing days, I have found -- rediscovered -- the pleasure of designing and implementing software. Surprisingly (to me at least), I don't feel over the hill. Yes, I probably can't do the marathon programming sessions I used to do, and all-nighters are a thing of the past, but I don't find my mind being any less sharp than it used to be. [0] https://www.kardanphotography.com [1] https://vimeo.com/kavehkardan [2] https://www.youtube.com/playlist?list=PLTA6M4yZF0MzsMlNL0N67... [3] https://github.com/kaveh808/kons-9 [4] https://medium.com/@kaveh808/once-more-into-the-breach-a-new...
In Ask HN: Resources for older developers?
A design decision which needs to be made is at what level of abstraction should the data be "fixed", i.e. not to be manipulated with the full power of CL. This is often a flexibility vs. efficiency tradeoff. In my 3D CL system [0], I have so far kept all geometric data as naive CLOS classes as the intent of the system is to provide a sandbox for experimentation. I have thought of, perhaps one day, representing the geometry as a foreign library for efficient passing to the GPU. [0] https://github.com/kaveh808/kons-9
In Why Lisp?

Showing the 15 most recent of 30 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.