I can see that it could work beautifully if you can develop a customer base 100-200 customers who sell products based on these maps.
Incidentally this is where I think Common Lisp will win big. Small companies or research groups who keep developing special products and expertise over long time.
Are you able to speak a little to the Lisp engineering without giving away "secret sauce"? Is Lisp serving the web pages too or only generating the star maps? Did you use CLOS heavily? MOP? FFI? Anything else "exotic" that I've failed to ask and you can speak about?
I use some CLOS, but most of it is plain old Lisp trying to avoid side-effects. Deploying is just dumping an SBCL core with the right functionality in it. It lives in a private server inside a VPN, listening to a port. Nothing fancy, really. I did consider at some point serving the web with Lisp as well (https://edicl.github.io/hunchentoot/, because I trust Edi Weitz's code) but I ended up doing it in python.
I had no idea what this did until I watched the video.
Suggestion: let people play with the map customization tool directly on the landing page, then charge them for changing the date/location and for hi-res exports.
Reading PG's ANSI Common Lisp was a pivotal event on my career as a programmer. I wrote a high-resolution star map generation tool in CL about 14 years ago, and have been working on it and selling the maps it produces for many years.
Now I am moving away from the things I don't do well (ranking in Google and promoting) to what I think I do best (making beautiful maps) with this new site, where I open the engine to people who want to add custom star maps to their own products.
Would you say PG's ANSI Common Lisp is better or worse (as a zero-to-hero intro to CL for an "experienced" programmer in other languages) than Peter Seibel's Practical Common Lisp?
I'm curious because I'm currently teaching myself CL (slowly, as a leisurely hobby), mainly because I realized that I need a hyper-flexible un-opinionated language in my toolkit for some types of experiments I want to try on and CL seems to fit the job. But I found the "practical" part missing from Practical Common Lisp with the non-plausible problems/examples and also missing stuff about packaging/ecosystem and little on modern concurrency patterns...
PG's ANSI common lisp was one of the first books I learned to program from. I still prefer it over Practical Common Lisp, partly because I appreciated the greater depth (I felt) it covered the basics in, and in that it was slightly more abstract...
But mostly because Appendix D gives a really succinct description of the language, key functions, all the different parameters to FORMAT and LOOP, and all the different read macros. Never underestimate the value of a good appendix!
OK "modern" might be a misnomer, all concepts are 20+ yo here, but... async with promises (like in basic concurrency without execution parallelism, just io p), channels, then actors, stm maybe. Most books seem to have a chapter on threads and stop there. I know CL has libs for all these and the libs have docs, but was hoping for some "big picture" summary of what's worth using and learning from the entire ecosystem and when etc.
If you find a good actors library, let me know. I've been using CL for 20 years and have not found a satisfying one.
[edit]
CL is in a slightly uncomfortable position here; scheme has first-class continuations, which makes implementing actors and async the sort of thing that could be an undergrad assignment, most other languages have a single source of truth (either with a language committee like C++ or with a one-true-implementation like Python).
Packaging and ecosystem has changed a lot recently, so On Lisp or ANSI Common Lisp would both be outdated quickly (as would Seibel’s PCL; PG does not have a book with that title). Most of that you can find online: practically everything is available through Quicklisp and it’s a very intuitive piece of software. Concurrency is harder and Bordeaux Threads might be too new for detailed inclusion in On Lisp or PCL.
I would highly recommend On Lisp once you have gotten the syntax down. I ordered a printed copy of the PDF (legal since PG released it) and have been working through it. On Lisp won’t show you things that are easily done in other languages; its goal is to teach the power of CL. Certainly by the time you’re done you’d be comfortable with many types of macros, closures, the REPL-based workflow, and other strengths if CL, able to find more about how one uses it in practice without much trouble.
Be aware that On Lisp was written before ANSI common lisp was standardised so there are a few areas towards the end (if I recall, in the continuations chapter) that won't work as written.
PG's Lisp books don't deal with packaging and ecosystem at all, do they? I think they are still very much relevant, and I completely agree with your recommendation.
ANSI Common Lisp from PG gives you a basic overview of the language, has some examples and has also a short reference section. It doesn't teach you anything useful about the eco-system, IIRC.
Practical Common Lisp teaches the language a bit more by example tasks...
I learned with ANSI CL, then read PG's On Lisp (which I downloaded from somewhere and printed, I don't think it was available). ANSI CL is great, the chapter where he writes an OO framework is just amazing. And On Lisp blew my mind.
Seibel's Practical Common Lisp is a good book, worth reading, but quite lacking in the "practical" aspect, which tends to be implementation-dependent.
The site and overall feeling looks clean, focused and built with a lot of love and passion. Kudos! I'd be happy to see more products like this, instead of frequent mishmash where visitor has no idea what it is looking at.
Are you able to sustain yourself with this app and selling maps?
I have no idea what a free account gets me, but the fact that the lowest "Explorer" tier costs $39/month for 1 map per month causes me to lose interest immediately.
I have two suggestions:
1. Show a bunch of prominent examples of star maps on giftable items like mugs and shirts memorializing various events like a birth or a wedding. The more explicit you are about the stars matching the night sky on the day and place of the event, the better. I could see these making for cool party favors, but I think the concept will go over a lot of people's heads (pun intended) unless it's spelled out for them.
2. Offer a la carte pricing. The couple planning their wedding on a shoestring budget might buy a star map for $40, but starting and cancelling a $40 subscription could be too much of a hassle.
Longer term, I might look into partnering with a company like
zazzle.com and integrating into their create-your-own-shirt-or-mug-or-whatever pipeline for a royalty.
Thank you for the feedback. The key addition that you get with the Explorer is access to bulk prices and bigger maps, but I probably don't say that clearly enough... you can actually buy and make maps with a free account.
Even after reading this and now knowing that you can make and buy free maps with a free account, it's still really not clear from your website that is the case.
My recommendation: make it as stupidly easily possible to buy a single map whenever you want, with the option for no account at all (and make it clear you can do that through your website).
I could conceivably see myself using this, the output looks really nice. But as soon as I need to sign up for an account, even if it's free..... ugh :-/
Make it easy for people like me who might be on the fence to give you my money :)
Hmm, I suspect you are right, thank you for the feedback. I think my customers will be business owners with some technical expertise (you need to at least understand what a transparent PNG is, and be able to paste it on your background), but I don't want to discourage end customers. I need to think about enabling map creation without accounts. I am requiring accounts now because you'll have to design a theme before you make your map (star colors, labels, fonts, etc) and I am assuming you'll want that to be saved. But I could make it optional...
You could also build up a temporary pseudo-account based on an anonymous user's session that could optionally be upgraded to a permanent account with an ID and password at any time.
This is common with e-commerce sites. Many don't require you to make an account to add items to your shopping cart or even to check out. But if you want to make an account, they make it super easy prefilling info they already have, and they certainly won't make you lose what's in your cart.
Another customer segment you could go after: I generated the star map from the day/time/location of my wedding, and themed the colors to match the wedding colors. My wife thought it was a great idea to print + frame it.
I have just updated the Plans page. I hope with the new changes the pricing is more clear, and also the benefits of subscribing. The rest will take a bit longer...
I think another problem you have is that there are a lot of potential customers who don't even know they want this yet, and you need to educate them so they understand why star maps are a cool idea particularly as a party favor.
I think you'll be able to improve your conversion if all your sample images included text describing what the star map is commemorating. Ideally there should be at least one such image on the homepage.
I know this may sound dumb, but before I saw the video, I hadn't considered why I'd want to generate my own star map over just using an existing one someone else had already generated.
Most of your customers are probably going to put commemorative text on the poster/shirt/mug anyway, because star maps don't really stand well on their own IMHO. I doubt many people other than astronomers and star geeks would be able to remember the difference between two night skies commemorating different events particularly if there in the same hemisphere and season.
You might think your customers won't be as thick headed as me, but now that I understand it, I'm seriously considering becoming a customer someday.
It's still unclear to me who the plans are targeting. I'm guessing maybe you're targeting creators (Etsy store owners, etc), and not the end consumers? That isn't clear if so, and I would still expect to be able to use your site to buy one-offs as a consumer.
I've tried again, thank you for the feedback. I have added the prices in the Plans page, I hope this will make it crystal clear what you can do. Today is being a very instructive day!
I'd drop the tattoo example on the gallery page. You would have a very difficult time finding an artist who'd even attempt that, much less one who'd do it well - and you'd be wanting to have it covered up inside a decade, most likely, in any case, given the way ink gradually migrates under the skin.
This is really cool, and I'm heartened that you've formed a business around this. What kind of projection do you use? DO you select the displayed stars from the zillions in that azimuth by their distance to Earth, or brightness on earth?
Thanks! It has been an amazing experience, if a bit exhausting (I am a single founder and the only developer). I did it because it was cool, started giving them to friends, and then it became obvious that they were making a very large impact in some people's lives. So I decided to try to reach a larger audience, which had the nice side effect that now I can make a living from it.
I am using the stereographic projection, and I display up to magnitude 7. The conversion from magnitude to diameter is one of the key elements of getting a beautiful result.
It's just fun to program in. You write something, see that your code is getting repetitive, write an elaborate macro that generates the repetitive parts, suddenly your program is 50% shorter. CLOS is ridiculously powerful. I love that I can connect to my live server's REPL and hotswap any code or basically do anything.
Speaking of REPL, it's basically your new shell: you almost never have to restart it and you can load all your projects into it, and get access to all sorts of tools that you wrote specifically to be used from REPL.
For me the Eureka moment with Common Lisp came when I read 'The Art of the Meta Object Protocol' (Kiczales) [1], which made me rethink OOP, the power of macro's and the power of Lisp.
Lisp is an extremely fundamental and deep language, but although it is conceptually interesting, I find it rather unpractical. A language needs some syntactic structure to help in pattern matching.
We read code more like a map than a book: scanning, skipping between files, functions and expressions. And, like a good map, it should guide our eyes: highways and byways are differently coloured and a quick glance tells us whether we are seeing a forest or a city. Code should be similar and due to the syntax of LISP, we have little to no guidance on what we are scanning, except by manually reading the code.
I don't think Lisp is the only language suffering from this. There are similar problems at the deeper end of the functional programming scene: we have to read map, flatMap, fold, apply, etc. in order to make sense of the code. We cannot 'scan' the code to understand its structure. It does not help that, for a syntax highlighter, these methods all get the same formatting.
The solution? Personally, I think we should seriously consider enhancing our editors to project our code based on the type-classes it participates in to enhance guidance.
I program in Common Lisp professionally on a sizable team of other Common Lisp programmers, and I find Lisp to be much easier to explore and navigate than other languages, by a huge margin. Why? Lisp IDE’s don’t need to build indexes of your projects that go out of date or anything like that. IDE’s participate by interacting with the running Lisp image itself.
I’m not sure what you’re missing about syntax. Indentation by default gives an excellent view of what’s going on, and most editors color important symbols as needed.
I find the lack of syntactic noise makes you focus on the important aspects of the program in the big picture.
Lisp has actually lots of structure, but it is expressed in lists. You need to see past the list, guided by symbols, blocks and indentation.
It's a bit like bicycle riding or learning to drive a car: while you are starting out and still thinking too much, it feels difficult. Once one has trained enough, one can read Lisp code quite fluently.
But there are pitfalls: the code might need to stay in the typical standard conventions for style. One CAN go in Lisp way be beyond standard code, reprogram the language -> it can get arbitrarily difficult to understand the code and may require learning new ways to program... but there are some expressive languages which have the same problem.
If you want to have a thriving community around your software and have bazaar-style development process, you better go with mainstream languages (C, C++, Go, Rust, Python, Java, etc.) The community is a great thing as projects like Linux and Kubernetes can show us. Yet there can be situations where you're the single developer on the project, or there are just 2-3 devoted hackers doing all the coding and for a variety of reasons there are little chances of inviting more people to join (niche projects ... closed projects w/o too much funding ... or maybe you're just not a good community builder). From my experience, Common Lisp with all its power is a perfect language for the latter situation. For me, it's also "thinking" language, as you can do exploratory programming easily compared to other modern languages. Source: I've built a control system for industrial electron accelerators using Common Lisp.
I held off learning LISP for many years, always thinking "one day I'll get to it". Because the syntax looked funky (even though I used other languages such as Haskell which has a "non-traditional" syntax).
Eventually I just dove in, and grew to appreciate the language. The homoiconicity (the code is data, and thus data can be used as code) is something that did excite me.
Unfortunately, I never got good with LISP. Whenever I wanted to do a 'real-world' thing, I ended up fighting with the package manager. Having outdated dependencies, not managing my deps correctly or just not finding deps for things that I wanted to use.
Which also deepened my believe that programming is more about the ecosystem than the language. I love functional programming, I really enjoy Haskell and I'll solve small things (Advent of Code) in LISP. But once I need a library I'll use Go, Python or Java, or _any_ other common lang.
I'd recommend learning it though!
EDIT: I just said LISP here, but I always used the CL (Common Lisp) implementation. And I run it with SBCL (Steel Bank Common Lisp)
I find the package manager actually great. Quicklisp works with monthly "distributions" that are tested to load together, rather than libs that must be strictly pinned and updated separately like everywhere else. I can understand the ecosystem problem, but it might be way better than one thinks: https://github.com/CodyReichert/awesome-cl
Also, Quicklisp can be completed with http://ultralisp.org/, a distribution that builds every 5 minutes and to which it is trivial to add a library. There's also Qlot for local dependencies, and more.
I'm here too. Niche languages are great when you're a solo developer or own your own company.
If you have to work in a large company, you have to deal with other technologies and people you'd normally avoid. That usually necessitates a larger ecosystem.
The secret of lisp is it's an abstract syntax tree (AST). When you compile a C or Java program it is first converted to an AST. With lisp you are already there. It's kind of a big deal and amazing it was invented in the 1950's. It's hard to "get it" without guided hand holding and a lot of deep thinking.
The structured nature of the code allows structured edits. Via tools like lispy. These ideas are floated for other languages but never get implemented due to difficulty and it's not an itch most people have.
Coding is against a live image. This allows really nice workflows. Other language users consider it an anti feature or incorrectly assume that means you can't use source control or do a full rebuild.
There tons of little niceties with lisp that add up to a sum greater than the parts. But the AST is the big one that no one understands.
It's usually the homoiconic syntax that you "get." Your mind is usually blown once you start taking advantage of that.
Keep in mind that this applies to all Lisps--not just Common Lisp. I never even bother with CL myself because I find it ugly and full of cruft. Most Scheme implementations will blow your mind just fine.
That depends on what other languages you have programmed in. The "get it" and "mind-blowing" hyperbole comes from a time when people had perhaps only programmed in Basic or C. Especially people the latter group would have issues with how easy Lisp makes programming.
If you have the time, I'd recommend reading SICP and working the exercises. It was a great experience for me. (If you are experienced with other Lisps or Schemes then ignore this comment.)
I think they're asking what makes CL noteworthy among all the other PLs such that it keeps getting brought up, even though it's not new and shiny or widely popular these days. Same sort of question you'd get about Smalltalk or Haskell.
Lisp evangelists always talk about a moment of profound clarity where the beauty and utility of Lisp just clicks in their brain somehow. I've done a little functional programming here and there so I know what it is, but I just can't fathom why Lisp is so beloved. I can't help but wonder if I knew Lisp (or some other functional language) intimately if I would approach problem solving completely differently.
Objectively, I felt the "power" when I learned macros. You can create any programming construct you like which will be executed at compile time / load time, and usable at runtime.
You will see the magic when you actually try it. No other language family that I know of (except forth or prolog maybe) can do this. Lisp still has the best macro system of all.
I can see that it could work beautifully if you can develop a customer base 100-200 customers who sell products based on these maps.
Incidentally this is where I think Common Lisp will win big. Small companies or research groups who keep developing special products and expertise over long time.