hawkeyedan

A little more context… This is a real decision I’m making with Common Lisp, Guile and Janet as my current leading options.

But … I feel like documenting all the thoughts in an essay/blog form may be helpful to others.

(And my post history will show I’ve gone down this path before. Trying again. Since last time I gave up due to the paradox of choice.)

Text run by an interpreter. Different strokes.

It’s not in my mix because it’s a fairly “big” language, which is a huge bonus once you’re proficient but makes it a poor choice for me to dive into Lisp(s). For someone else, that might not be true. But I like to be able to hold things in my head.

In the long run, CL is a great option. My theory is that it’s a place I could go if/when I’m up and running in another Lisp.

LFE lacks it’s own robust web app development stack … and translating between documentation in Elixir (Phoenix) and Lisp all day will make my head hurt.

Clojure is a tougher call. For this project it might be good.

However, I want to include some CLI scripts … and the JVM adds deployment complexity for those.

ClojureScript is tempting, but I don’t see a great story about the server piece for rapid web app development there.

While I’ve got you… What’s the state-of-the-art story for package management in Gambit?

Thanks, that’s a very helpful insight. You’ve put my mind a significant ease.

In my case, web-based just means "it is a piece of software you access via the web." Web application, website, SAAS, whatever.

And you're right, I should have considered Gambit. Dang, now I have a ternary decision to make.

Just to be clear: yes, there are other Lisps.

Yes, Clojure is cool.

Yes, LFE is a thing that exists. Yes Elixir is Lisp-adjacent.

Yes, any of those would give me access to a larger ecosystem and the resources of a well used, well supported VM.

I may be an idiot (it's been said), but I'm not a stupid idiot. I've ruled each of those out for good-ish reasons.

To be precise, applets were an early application of Java. But Sun Microsystems actually developed it in the long-standing dream of the “universal binary.”

The project began in 1991 targeting set-top boxes. [source](https://web.archive.org/web/20100210225651/http://www.java.c...)

WASM is another iteration of the same noble idea done with different technologies at a different moment.

Java and the JVM have been incredibly successful. WASM has the potential to bring the dream of a universal binary even farther.

This is a pretty great tool, despite the limitations of existing in iOS-land.

It obviously has the same problem any Tor browser has though, you run into bot blocking on a very large % of the regular (non .onion) interwebs.

Worth consideration for putting on your daily driver phone.

And yet I can only read Dante’s original work in Italian!

Arguments about the “superiority” of Python vs Ruby always sound a bit like arguments about the “superiority” of Italian vs Spanish. If you squint a bit they’re basically the same.

(By that simile, Lisp would be Sanskrit?)

So funny that Rails has gone from “exciting” to “boring” in (relatively) the blink of an eye. But boring is good, nice to see it embraced.

Best post I’ve read on this so far!

This is a really important story. I think about all the requests government agencies make for backdoors to things ... then I read something like this ... Ick.

Of course if you’re one of the platforms, owning some or all of other people’s login processes does happen to be a win for you.

As somebody who loves databases, I think the real issue that folks are meaning to critique isn’t actually using a “model.”

It’s using an ActiveRecord-style ORM (or any ORM) without grokking what lies beneath.

A database layer IS a model. It’s just not a class or an object.

ActiveRecord is a really nice trick when it works … but it can create some really performance-killing side effects.

Ruby’s Datawrapper ORM and its siblings in other languages requires understanding both sides (the object system and RDBMS) but can let you get your class/object semantics to play nicely with your database.

And just passing around database connections and arrays of hashes can get you awfully far.

But, if you want to not think about the database layer, ActiveRecord-style ORMs are a real win for developer ergonomics.

And that’s part of the win of Rails/Django/etc. You can live in a single mental model (classes/objects with references to each other) and ignore the database layer.

Except when you can’t.

One reason (not a criticism) that NoSQL can be such a win is that the semantics are closer to class/object semantics. So you’re not trying to manipulate data with an abstraction that doesn’t quite fit.

But most of our projects aren’t Twitter or FaceBook or Google or anything else functioning at galactic scale.

Bash is bad and ugly… But I just avoided a day’s worth of development of a little command line utility by adding two alias lines that go into .profile.

Sadly, that might not be a great bet. The world of government software procurement is very, very ugly.

Great idea! Thanks for making it!

Hopeful this will get noticed here and folks will go in and comment (presumably positively or with constructive criticism) to make this frequently used .gitignore better.

Jumping in on this late, but I think the haters and some of the lovers miss the point.

Perl doesn’t need to be Python. It’s great to be the #20 language.

Still wrapping my head around this. And hoping Raku will start to get some mainstream adoption.

This is a great example of the curative powers of even a little bit if sunlight. Good job PP!

Now if only Verizon had shame.

I'd suggest that the guest use case is the most important one and that account generation/creation/etc is for most sites the use case that should come second.

For a project I'm working on right now our team decided to simply eschew user accounts even though it's a site that is built around user generated content and comments. Everything is done by entering your email address (which the site doesn't surface) and then clicking a confirm link we send via email.

So far,our testers love it. It seems to have gotten them quickly past the user dread. It also means your first participation in our site can happen by submitting one form and confirming one email. That's somewhere between two and five steps shorter than had we required account setup. While it adds an extra step to subsequent interaction, email confirmation, we feel like it's a good trade off for them. After all, going through a password reset when you come back to the site is an easy way to lose people.

And for us, it eliminated a lot of development headaches. When a user first participates in the site we assign them a randomly generated username. And they can change it to whatever they like ... They just fill put the change my username form and confirm by email.

Obviously, if we wanted to save credit card info or something like that we might need to modify this approach for PCI compliance, but I believe a fundamentally similar workflow could be employed even then.