robto

I think you could argue that there is a third basic mode of development - the free and open source software. I'm not saying all FOSS software is artisan or cared for with excellent craftsmanship, but when I think of software that lasts FOSS software is what comes to mind: - emacs - PostgreSQL - linux

I really like the Postgres example because it was initially just a bunch of academics who refused to implement new SQL features until they could do it The Right Way. See how long it took them to get upsert.

I really hope that GNU Guix takes off in this way - just gradually doing things The Right Way until the product is just the default institution.

The other responses are good, but I'd recommend reading a book about improv comedy[0] (or better yet, trying it out yourself). They've got a lot of specific techniques that are meant to stretch your creative muscles. I did a bit of improv when I was younger and I still use those techniques all the time twenty years later, because they work!

Reading about the exercises is interesting but unless you actually try them out they are just a curiosity. I think the muscle analogy really fits when it comes to creativity.

[0]I like "The Improv Handbook" by Tom Salinsky and Deborah Frances-White

I don't think you are, and the IPFS ecosystem has already run into this problem. In IPFS, content is addressed by its hash, but different protocols are better suited to different encodings - browsers speak http, which is case insensitive.

And so they've worked out self-describing hashes! https://multiformats.io/multihash/

The basic idea is that you include the name of the algorithm as part of the hash. This allows changing the hash algorithm without breaking backwards compatibility.

It's a cool standard with implementations[0] for many languages. I don't know if it was considered for git, but it does seem likely that this issue will come up again before the end of time :)

[0]https://github.com/multiformats/multihash

I don't think they are - you can always sell libre software. Whether anyone is willing to buy it is another question, but at no point is your right to resell abridged.

I'm partial to kee-frame[0], which is the controller model from keechma implemented in re-frame. It's a tiny library but quite a nice starting place.

[0]https://github.com/ingesolvoll/kee-frame

I don't think it's that it's "criticism of the church" that people get touchy about. It's just that people tend to focus on the syntax in isolation and not acknowledge the tradeoffs that are involved with different syntaxes.

A lot of lispers are used to people complaining about the parens and syntax but not acknowledging the consistency, the macros, the language-design-as-a-library, the structural editing, and the easy repl integration story that you get in return. And those are the features that lispers are really excited about, and it's frustrating when people don't acknowledge that you give up all of those benefits when you choose algol-like syntax.

Now, I'm not saying that you're one of those people who doesn't understand that, but if you've met lispers who "get touchy" about it that's probably why.

I say you still do get a benefit from using because of the repl-driven development process. I miss that instantaneous feedback and the feeling that you are in dialogue with your program whenever I develop in other languages.

Add to that the fact that the language shepards you into using immutable datastructures and writing pure code, I still think Clojure is a significant advantage when writing distributed applications.

Coming from a lisp I often wish other languages had `cond` so I don't have to nest if statements. This looks like a poor man's cond.

So yes, I do find this more readable. It makes it clear that only one branch will get executed.

Do you know how to get SyncThing on an iPhone? This is the last piece in the synchronize-the-whole-family's-media-so-that-it's-easy-to-share-and-backup project! Last time I checked there was no iOS client.

We went to Clojure, and we've been very successful with it. But the BEAM is a great choice too! Immutable data structures make concurrency manageable, if not easy.

I found Designing Data-Intensive Applications[0] by Martin Kleppman to be the most eye-opening system design book that I've read. He really describes well how awful things get once you have to coordinate more than one physical machine - the number of things that can go wrong is staggering. I would say this book is as scary as Java Concurrency in Practice was - and that book was scary enough to get our company to change languages.

I think one of the best ways to learn software architecture is to have a clear view of what the challenges are, and the Kleppman book does a really good job of providing that clear view.

[0]https://dataintensive.net/

The Datafy[0] protocol can be implemented for literally anything, and some people have made some pretty nice pretty printers for it, like Rebl[1]

[0]https://clojure.github.io/clojure/clojure.datafy-api.html [1]https://github.com/cognitect-labs/REBL-distro

I use straight.el[0] for a reproducible package list. It basically clones the packages and stores a map of package->commit, so you can freeze your packages and reproduce them on another machine.

You could also use the Guix package manager[1] or the Nix package manager[2] to achieve a similar effect.

Reproducible software is much more stable!

[0]https://github.com/raxod502/straight.el

[1]https://guix.gnu.org/#guix-in-other-distros

[2]https://nixos.org/nix/

This reminds me a bit of hyperfiddle[0], which I've looked at a few times but never really explored. I know the author (dustingetz) hangs out around here, and I wonder if any of this interface builder stuff was prior art.

In any case, I wish we had more tools for interactivity these days. I use emacs and it's given me a taste for what's possible, and I'm excited to see Guix[1] mature because it has fantastic sympathies with emacs. But it seems destined to be niche, even though it's such a wonderful vision of what computing could be.

[0]http://www.hyperfiddle.net/ [1]https://guix.gnu.org/

I'm currently held back from going into the mechanical keyboard world because I'm hooked on the thinkpad trackpoint stick and mouse buttons below the spacebar - I've got a thinkpad and two usb keyboards with the dot and mouse buttons, and I use them on every computer I touch. Are there mechanical keyboards with built in mouse functionality?

I've been working my way through 'A comprehensive study of Convergent and Commutative Replicated Data Types'[0] and I've been finding them very approachable. I'm trying to implement them in Clojure as I go and that has been interesting. I've also starting looking at 'Mergeable persistent data structures'[1], and that one already has a repo with the code in Ocaml, but I have to admit that I don't understand that queue structure yet.

It does seem like a good way to dodge some of the tough problems that come up in distributed systems.

[0]https://hal.inria.fr/file/index/docid/555588/filename/techre... [1]http://gazagnaire.org/pub/FGM15.pdf

Is Lisp opinionated about side-effects? Maybe Clojure is, but have you looked at Common Lisp or Emacs? I can't think of a less-opinionated-about-side-effects application than Emacs.

Except that they are making progress. They've upstreamed some import work to the kernal, they've contributed to phosh and libhandy. They clearly aren't working as fast as they (or many others) would like, but they are working. And not many other people are.

I also support hardware projects like ZeroPhone, Pine Phone, and the Dragonbox Pyra and software projects like Plasma Mobile. When I saw Purism articulate a vision for what a phone could be I had to support them too.

I wish they collaborated and communicated better, and I wish they had made some different decisions regarding the stack, but at the end of the day they are slowly moving the ball forward. But when I gave them $600 I did it partly because they had a vision that I valued and I wanted to signal to others that it is a vision worth investing in.

So I'm disappointed when I hear these reports, but I'm still supporting them because they are part of a very small community doing very important work. And since it's free software, it's not work that's going to waste, it can always be picked up by someone else. That's part of why it's so important.

The Elements of Computing Systems: Building a Modern Computer from First Principles[0] and its accompanying class Nand to Tetris[1]. Starting at logic gates and moving up through the levels of abstraction until you can build a programming language and implement a video game is the most fundamental approach that I'm aware of.

[0]https://www.nand2tetris.org/book [1]https://www.nand2tetris.org/

Some alternatives to core async that I think are very thoughtful are promesa[0] and manifold[1]. We've got a large chunk of core async code that if I had to redo I would use one of those libraries. They are conceptually simpler, I think, and they don't have the same downsides as the `go` macro.

That said, our code works and I'm not about to rewrite it just because some new libraries came out.

As for spec and transducers, I do use spec quite heavily, though now that clojure.spec.alpha2 is on the horizon I'm holding off a bit - it will be really nice to have data-based specs instead of macro based ones.

For transducers I've only used them when I've found a performance bottleneck in a data transformation pipeline, which for me means only on toy algorithm problems and not in production code. But that says more about my line of work than their usefulness, I think. I didn't find them too hard to grasp.

There's some cool work being done with hooks that are mentioned up thread, and I think there a fork of reagent that is experimenting with them. This is actually a really exciting time in cljs-land, there are a lot of interesting projects exploring what we can do to build on ideas from React (hooks) and Svelte. The Svelte approach is especially interesting to me, since it's basically just a compiler, which we can do with a macro. And with shadow-cljs the build tools are better than they've ever been.

[0]https://funcool.github.io/promesa/latest/ [1]https://github.com/ztellman/manifold

Making programs concurrent is hard, especially if you don't have good support from the language. I, too, would hesitate before attempting to make a highly concurrent application in PHP, Python, or Visual Basic. And even then you're looking at considerable investment rewriting stuff that already works.

Maybe it works out if the cost savings from being able to purchase fewer machines outweighs the rewrite and the risk of new concurrency bugs.

There's a huge difference between global state in C and redux, though - redux state is immutable and updated atomically. And immutable state really is a game changer in reducing complexity.

When you're just dealing with functions and data, I don't know how it could get more simple. I know that it has made my code much more readable, testable, and organized.

If you get firefox working, please share your definition on the nonguix[0] repo. Lack of Firefox is what is currently holding me back from installing Guix on hardware. I don't know anything about package building, but I'd be happy to help collaborate if you need it.

[0]https://gitlab.com/nonguix/nonguix

You might want to check out Arcadia[0], a Clojure library for Unity game development. It's all done with ClojureCLR and it's pretty cool. Not saying you want to do game development, but they've definitely got a working product and you can see how they've set up their project.

They just got a round of funding this year, and they've got several good talks posted on their homepage about the quirks of working on .NET.

[0]https://github.com/arcadia-unity/Arcadia

My mouse is actually critical to how I use i3 - I've got a lenovo thinkpad usb keyboard, with the left, middle, and right mouse buttons below the spacebar and the red nub for the pointer. I use focus-follow-mouse and when I need to change my active window I just flick the mouse over to where it needs to be - it's super fast. It also works really well with laptop trackpads and an actual mouse.

I know other window managers allow you to use focus-follow-mouse, but I haven't found any that make it nearly as effective as i3.

The halting problem states that it's impossible to know if computation will terminate in the general case, but there are lots of specific cases where we can prove that it will terminate. The Idris language compiler (think haskell with dependent types) will actually warn/error if you've written a function that it can't prove will terminate. It's actually really cool! If you're interested in learning more, I'd check out any talks by Edwin Brady or pick up his book[0]

[0]Type-Driven Development with Idris

cljfx is actually inspired on fn-fx, and presents a much cleaner and more usable api, just by comparing the docs. I'm pretty sold on data-based apis instead of macro-based ones, though, so maybe it's just catering towards my preferred style of development.

I know about revery[0] and cljfx[0], though I haven't had the chance to use them in anger. These both seem like very nice approaches to me - I'm partial to cljfx because I've been utterly spoiled by the clojure/script development experience, but I've also come to enjoy the typescript environment and revery seems to another step along that road.

[0]https://github.com/revery-ui/revery [1]https://github.com/cljfx/cljfx

This actually seems like it would be pretty good on something like the Librem 5! I like the idea of a tiling-esque window manager with this level of flexibility, especially on a phone. The launcher/sidebar/fitting/pinning/minimization features seem like an improvement over existing touch interfaces, especially on linux.

I don't think I would abandon my i3 setup for something like this for work, but I could see myself happily using something like this in a more casual setting. I hope that some of these ideas see the light of day with an actual implementation.

I disagree. Suppose you have an election with 3 candidates that runs every year. If you predict candidate A win at 33% confidence, but that candidate gets elected every year, your calibration will be way off. Calibration is about aggregating, so you can't really cheat it. Your 33% prediction has to be right 33% of the time - it's really hard to fake that.

Maybe I'm misunderstanding your position, though.