screenshotbot-oss VS talk-transcripts

Examples (for Common Lisp, so not citing Emacs): reddit v1, Google's ITA Software that powers airfare search engines (Kayak, Orbitz…), Postgres' pgloader (http://pgloader.io/), which was re-written from Python to Common Lisp, Opus Modus for music composition, the Maxima CAS, PTC 3D designer CAD software (used by big brands worldwide), Grammarly, Mirai, the 3D editor that designed Gollum's face, the ScoreCloud app that lets you whistle or play an instrument and get the music score,

but also the ACL2 theorem prover, used in the industry since the 90s, NASA's PVS provers and SPIKE scheduler used for Hubble and JWT, many companies in Quantum Computing, companies like SISCOG, who plans the transportation systems of european metropolis' underground since the 80s, Ravenpack who's into big-data analysis for financial services (they might be hiring), Keepit (https://www.keepit.com/), Pocket Change (Japan, https://www.pocket-change.jp/en/), the new Feetr in trading (https://feetr.io/, you can search HN), Airbus, Alstom, Planisware (https://planisware.com),

or also the open-source screenshotbot (https://screenshotbot.io), the Kandria game (https://kandria.com/),

and the companies in https://github.com/azzamsa/awesome-lisp-companies and on LispWorks and Allegro's Success Stories.

https://github.com/tamurashingo/reddit1.0/

http://opusmodus.com/

https://www.ptc.com/en/products/cad/3d-design

http://www.izware.com/mirai

https://apps.apple.com/us/app/scorecloud-express/id566535238

This LispWorks comment on reddit is very interesting:

---

[cite]

As a Lispworks user, yes it is super pricey, but it does make sense for certain people. Arguably, Lispworks provides features that aren't available in any other programming language, Lisp or not.

* Support for just about every platform I can imagine. Yes it's expensive, but if I want to port to a new platform I can pay Lispworks, and get it over with. It'll mostly work without too much changes. It works on Android, iOS, Windows, Linux, Mac, and some really obscure systems.

* Application delivery with tree shaking. May be there are other languages that do this, but I haven't worked with something like this before in my career. (Maybe proguard for Java, but that's very rudimentary compared to LW's delivery). The tool I work on delivers a binary that people need to download during the CI jobs for every run, so having it be 100MB is way too big. After compression, my LW delivered binaries come to around 9MB.

* You mention support being expensive. Actually, for simple support questions LW does a pretty good job of responding back to you. I've asked tonnes of questions over the years, and have not paid for a separate support contract apart from the yearly maintenance contract. I suspect they like people asking questions, because then they fix those bugs and it becomes even more rock solid.

* The documentation is glorious. And in the off-chance that I need to know something that's not documented, I just mail them and they'll respond usually by the next working day.

* Very stable Java support (although the API could be better), let's me use the entire Java ecosystem of libraries when I need it.

* The platform itself is rock-solid. Now SBCL is fantastic, but when I ran my servers on SBCL, I would have a crash every now and then. With LW, I can have my server running weeks (current uptime is a month) with reloading code multiple times a day, and everything is still super stable.

There's more, but I think the rest is more negotiable. For instance, the FLI is a lot more polished than using CFFI, which makes a huge difference in productivity when writing native code. Or the fact that its remote-debugger facility can be used as a very stable protocol to programmatically control a remote LW process. I don't use the IDE btw, so I'm not even considering that. I don't use CAPI either, but I mean to someday.

2023, Arnold @tdrhq of Screenshotbot (https://github.com/screenshotbot/screenshotbot-oss) on reddit: https://www.reddit.com/r/Common_Lisp/comments/11979q4/common...

[/cite]

You can avoid having to do the step of recording screenshots if you use a tool like Screenshotbot (https://github.com/screenshotbot/screenshotbot-oss) or Vizzy (https://github.com/workday/vizzy)

Oh yeah, github.com/screenshotbot/screenshotbot-oss :)

There are open source tools to achieve this workflow. I've personally built screenshotbot (https://screenshotbot.io / https://github.com/screenshotbot/screenshotbot-oss), I've also built the screenshot testing infrastructure at Facebook. Workday has open-sourced their own tool at https://github.com/workday/vizzy. AirBnb uses another commercial tool called Happo (https://happo.io). Use any of these services with Paparazzi.

There are a few open source tools to do this: there's a tool I built: https://github.com/screenshotbot/screenshotbot-oss similar to the infrastructure at Facebook, and there's another one built at Workday: https://github.com/workday/vizzy. These are screenshot-library agnostic services to notify you on Pull Requests when screenshots change.

Screenshotbot is completely open-source by the way: https://github.com/screenshotbot/screenshotbot-oss

So, I'm in the process of defining something I'm calling an easy-macro. (You can see the code here, but I'm going to extract this into a quicklisp library once I'm happy with it: https://github.com/screenshotbot/screenshotbot-oss/blob/main/src/util/macros.lisp)

I'm the author Screenshotbot (https://github.com/screenshotbot/screenshotbot-oss) , and I think this is exactly what you need. Although the README claims to not support browsers, it does actually support browsers, both in the open source and non open source version. I just need to update the docs.

Reminds me a little of hammock-driven development [1]

> the background mind is good at synthesizing things. It's good about strategy

[1] https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Thank you for this recommendation. I've never heard of it before and now I'm reading: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

It's giving me energy this Monday holiday(USA)!

race?

> [Audience reply: Sprinter]

> Right, only somebody who runs really short races, okay?

> [Audience laughter]

> But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

>So this is 10x, a full order of magnitude reduction in (?) severity before we get to the set of problems I think are more in the domain of what programming languages can help with, right? And because you can read these they'll all going to come up in a second as I go through each one on some slide so I'm not going to read them all out right now. But importantly there's another break where we get to trivialisms of problems in programming. Like typos and just being inconsistent, like, you thought you're going to have a list of strings and you put a number in there. That happens, you know, people make those kinds of mistakes, they're pretty inexpensive.

[0] Video: https://www.youtube.com/watch?v=2V1FtfBDsLU

[1] Slides and transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

[2] Video https://www.youtube.com/watch?v=YR5WdGrpoug

[3] Slides and transcript https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

This is tangentially related to Puzzles-vs-Problems in Rich Hickey's Effective Programs

> Eventually I got back to scheduling and again wrote a new kind of scheduling system in Common Lisp, which again they did not want to run in production. And then I rewrote it in C++. Now at this point I was an expert C++ user and really loved C++, for some value of love. But as we'll see later I love the puzzle of C++. So I had to rewrite it in C++ and it took, you know, four times as long to rewrite it as it took to write it in the first place, it yielded five times as much code and it was no faster. And that's when I knew I was doing it wrong.

[...]

> So I mean for young programmers, if everybody's tired and old, this doesn't matter any more. But when I was young, when I was young, I really, you know, when you're young you've got lots of free space. I used to say "an empty head", but that's not right. You've got a lot of free space available and you can fill it with whatever you like. And these type systems they're quite fun, because from an endorphin standpoint solving puzzles and solving problems is the same, it gives you the same rush. Puzzle solving is really cool. But that's not what it should be about.

Talk: https://www.youtube.com/watch?v=2V1FtfBDsLU

Slides and transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Using triggers + history tables (aka audit tables) is the right answer 98% of the time. Just do it. If you're not already doing it, start today. It is a proven technique, in use for _over 30 years_.

Here's a quick rundown of how to do it generically https://gist.github.com/slotrans/353952c4f383596e6fe8777db5d... (trades off space efficiency for "being easy").

It's great if you can store immutable data. Really, really great. But you _probably_ have a ton of mutable data in your database and you are _probably_ forgetting a ton of it every day. Stop forgetting things! Use history tables.

cf. https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

Do not use Papertrail or similar application-space history tracking libraries/techniques. They are slow, error-prone, and incapable of capturing any DB changes that bypass your app stack (which you probably have, and should). Worth remembering that _any_ attempt to capture an "updated" timestamp from your app is fundamentally incorrect, because each of your webheads has its own clock. Use the database clock! It's the only one that's correct!

Rich Hickey (creator of Clojure) references Polya several times in his classic talk "Hammock Driven Development". Here's a transcript:

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

I've long been impressed by Hickey's problem solving skills, so I took much of this talk to heart, and even bought a copy of HTSI. Can't say it really helped me any more than Rich's talk (as a programmer) but I'm thinking I'll give it another look.

>Great product designs require no manual, and similarly, great interfaces need no documentation. Imagine having to read a manual on how to use a coffee mug.

This could not be more wrong.

Not everything is easy. If a library is addressing a complicated domain, solving by definition a complicated problem, it is fine if it requires some learning.

When did expertise and learning become bad things? If software is an engineering discipline, why would people in it ever promulgate the idea that any random cog can step in to any “engineer”s shoes?

Rich Hickey analogizes this mentality to the world of music, where it taken for granted that learning an instrument requires a lot of study:

“ We start with the cello. Should we make cellos that auto tune? Like, no matter where you put your finger, it's just going to play something good, play a good note.

“[Audience laughter]

“Like, you're good. We'll just fix that.

“ Should we have cellos with, like, red and green lights? Like, if you're playing the wrong note, you know, it's red. You slide around, and it's green. You're like, great! I'm good. I'm playing the right song. Right?

“ Or maybe we should have cellos that don't make any sound at all. Until you get it right, there's nothing.

“ [Audience laughter]”

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

You might find adjacent talks and speakers here ... https://github.com/matthiasn/talk-transcripts

Many languages merge the two concepts, and implement procedures as functions that return void. This may muddle/complect their distinction, causing programmers to call procedures from within functions, thereby making those functions into impure functions (meaning that they affect the world outside of themselves, through side-effects like I/O or mutating state). This should be avoided, especially if you care about debug-ability and Functional Core, Imperative Shell architectures (see Gary Bernhardt's Boundaries talk at 31:56) (which make testing your system easier, without mocking).