What happened was Barry McCarthy, who was CFO at Netflix till 2010, left Netflix. Barry was an exceedingly creative and forward thinking CFO. He was the CFO responsible for taking Spotify public via direct listing in 2018, which was an incredibly bold move at the time. Definitely creative as far as CFOs go.
Adobe used to do these designy annual reports as well [1], and it looks like they stopped in 2003. I wonder if something in that era encouraged them to knock it off.
Edit: for Adobe, it may have coincided with significantly cutting back their Marketing/Communications department, which had a huge staff of really great artists in the 90's. I believe this became viewed as an extravagance to have a stable of really talented and creative artists and designers on staff when you can hire this stuff out and get "reasonable" results.
What is impressive to me is, it still shows there is demand from accountants/investors and offer from authors for artistically pleasing documents.
It dwindled out, but it is similar to corporate websites like SAP which were boring to death and made life in corporate a bane (we should study suicide and boredom-from-boring-documents in corporates), until all layers of management were naturally attracted to software created by little startups, even if it didn’t track time correctly, but it was cuter and nicer and didn’t require IE7.
Boredom-from-documents-and-websites is a key factor for people’s choice of employment...
Ah yes this is exactly what I needed. I was recently trying to start a CL project but I had trouble wading through all the outdated material, especially with regards to including external packages. Thanks for putting this together!
I'm going through a similar process. My caution is that 'package' has a very technical meaning in Common Lisp that is at odds with how 'package' is used in other languages (and a bit at odds with how the author uses it in their tutorial).
A package in Common Lisp is a set of interned symbols. In Common Lisp, systems are more in keeping with an ordinary understanding of packages...but combined with the idea of a build system just for fun.
ASDF is a way for managing systems (but it is worth keeping in mind that Common Lisp does not have any 'official' understanding of systems). ASDF is pretty much a de facto standard by consensus.
Quicklisp is a 'package manager' in the sense that it will go out and fetch a dependency from a repository. But what it fetches is a system: it is usually not a package in Common Lisp's technical sense.
From the Quicklisp FAQ:
How is Quicklisp related to ASDF?
Quicklisp has an archive of project files and metadata about project relationships. It can download a project and its dependencies. ASDF is used to actually compile and load the project and its dependencies.
ASDF is a little like make and Quicklisp is a little like a Linux package manager.
On the other hand, Common Lisp is very stable around ASDF and SLIME and QuickLisp. ASDF was started in 2002. Quicklisp in 2005. SLIME in 2003.
0. It's a hard problem. I have a deep respect for your trying to tackle it.
1. The hard part is that it all matters on day one and everyone will get a lot of stuff wrong for a long while and some stuff wrong always when attempting non-trivial projects. This is the rule whether it's Python or Common Lisp or Racket.
2. I'm a fan of polyglotting languages in general and Lisp's in particular. For a person really just starting out, I'd point them at the Racket ecosystem because it is designed to be newbie friendly with student languages and Common Lisp is designed for production programming on hard problems.
2. For people with some programming experience and simple curiosity, I'd just advise them to install SBCL and play around in the REPL. With an exercise of adding a script to wrap it in readline. And some exercises using the text editor of their choice to load and read and write files and such.
3. I don't think that there's a way to add training wheels to SLIME and Quicklisp and ASDF as the development environment. It just won't ever be DrRacket. At best it produces something like Aphyr's Clojure from the Ground Up...which uses Emacs; is more like a book; and definitely a labor of love. It also dives into the details at day one.
None of which means I might not submit a pull request. But I take what Norvig says seriously -- http://norvig.com/21-days.html
The niche of "welcome to Lisp, here's how to code" has been super well filled over the years. And regularly people write sort of intros to SBCL, CCL, etc. articulate-lisp isn't intended to do that - there are a few notes in that regard, just to whet your thoughts - and because I was bored - but it's not a thing there really.
But what is typically lacking is how you go from just a Lisp environment to a development environment that lets you operate at a professional level. Articulate-lisp is intended to deliver the thumbnail of how to get that put together, along with assorted references to further study.
At the time I created it, there was nothing really suitable for pro development out there. I guess roswell and portacle are things now.
Training wheels aren't really my bag of things. I'm notorious for preferring to read the O.G. paper on subjects rather than work through tutorials and simplified whatsits. But giving all the data at once doesn't provide the map of the territory that newbies crave.
There's no Royal Road to Lisp... or geometry. But a map to get you to where you're going does exist for geometry, and Lisp, I think deserves one too.
I think a resource for "leveling up" is probably better if it is opinionated. I mean, there are reasons a person might not want to use Emacs for Common Lisp development (aside from using a product with a built in IDE), but there's no reason to handle edge cases which have little to do with "leveling up" on Common Lisp...there may be a SLIME mode for Atom, but someone who chooses it is swimming upstream in terms of Common Lisp.
The situation is similar in regard to Lisp installations. There are good reasons not to use SBCL, but they probably don't have that much to do with "leveling up" (again outside the commercial IDE world) and trying to cater to those non-leveling up reasons is a distraction.
To put it another way, a person who is just starting out is not in a position to make decisions based on experience. A year later, they may have the experience to make informed decisions because they have learned what matters and what does not.
I hopeful for Roswell and Portacle, but not terribly optimistic in ways that are similar to when I hear about a new Linux distro. The hard work is not the exciting honeymoon period. It's grinding out maintenance over the years without getting paid. It's designing good features for other people without getting paid. Most projects cannot do it.
Part of the problem is that leveling up on Common Lisp is mostly a matter of will to RTFM. Sure a site can have a great article explaining Common Lisp packages, but to understand packages, readers will need to understand symbols and so the options are:
1. Expect the reader to already understand symbols.
2. Describe all of Common Lisp.
3. Accept that the reader will still have a lot of work to do after reading the article.
1 and 3 collapse into similar requirements for an author. 2 works if the author writing a book and really knows their stuff.
I think you're a bit misinformed. Chicago has two large keystone industries that serve the global economy: (1) Industrial large scale manufacturing (Boeing, John Deere, Caterpillar), (2) Insurance (all of them); not to mention a ton of Food and Agriculture HQs are based there as well.
Slightly less so nowadays. I left that area and moved to a megacity so I could get into software dev without having to work at an insurance company (or ESPN). But there's a little bit more going on with CT nowadays, and I think the insurance companies are starting to spread out. They had a ton of leverage in the area and got away with a lot (not paying taxes, etc) but the well started to run dry and people started to push back. Before I left, the mere suggestion that we demand more from these huge companies always turned into highly publicized threats to take XX,000 jobs elsewhere.
The whole situation is dumb, overall I'd avoid living in CT for a ton of reasons. CT had a lot of industry going for it (Stanley Tools in New Britain, for example, and Hartford was the center of the gun industry 100 years ago) but those of course moved overseas. The insurance industry provided a safety net so it didn't go the way of the rust belt but, late capitalism y'know, so that was just a band-aid that's being slowly ripped off. This is happening everywhere but the systematic denial isn't as ingrained as in CT, it's weird.
No they did not leave Washington, that's ridiculous. Their executive HQ is in Chicago but that doesn't mean much. Many executive HQ are in Chicago but that's not many jobs.
