dancek

Thanks for the tip and for telling me about function trains.

Also great work on Dyalog, which I had a personal license to back when I experimented a couple of years ago. I can't recall what my problem with GNU APL was but I quickly found it too painful to try and learn with.

I'd love to have a language that combines the notation of APL with the ergonomics of J (ie. hooks and forks enabling functional-ish programming, a de facto open source implementation and a working Android "IDE").

Really? I use IntelliJ on an external 4k display every day at work with a 2016 MBP. I seem to recall having some issues in early 2017 (when I started at $company), but nowadays it works fine.

EDIT: I'm quite sure I have scaled resolution but can't check.

Or you can set up a relay in weechat and connect with glowing-bear (html5) or android-weechat. Works great. The glowing-bear community have good tutorials iirc.

Learn an aphorism by heart and think of situations it applies to. Pick something important that you believe in. Then, over time, you'll remember the aphorism in various situations and slowly adopt it as a life value.

Examples:

- Getting what you want will not make you happy.

- It's hard to get what you want. But it's easy to want what you get.

An interesting point.

I think it would be better to merge ASTs rather than text files that represent code. The annoying issues with merges are all about the text representation. When there's actually different logic changes in two different directions the merges cease to be annoying and start to require domain knowledge.

Of course getting from this hand-wavey thought to working software is difficult. Perhaps we first need to start focusing more on the tree nature of code even in the editing tools?

That's an interesting idea. Many instruments have greatly varying timbres, though. Combining the timbres back to instruments would require another level of processing.

Blog post about shhgit: https://darkport.co.uk/blog/ahh-shhgit!/

But clearing snow takes time and equipment and main routes have the priority.

For example my commute of about 20km has about 10km that gets cleared early in the morning if humanly possible; maybe 9km that usually gets cleared during the evening; and maybe 1km that may take 3-5 days after a big snowstorm.

And when there's a lot of snow, a bicycle is "wrong gear".

(N.b. I ride in the snow for hundreds of kilometers every winter. I know you can take a fatbike to powder snow but that's just too strenuous for most people.)

Nit: flowing water does go below 0°C without freezing, as does water with impurities (sea water).

Not out of the box, probably because java.util.function.Function seems like an afterthought in a strictly object-oriented language while Clojure has first class functions. In practice you don't interop with Java very much, let alone functional Java (as Clojure itself is a much better fit). But if it was useful, it'd be easy to write helpers for converting functions back and forth.

Raitit (rye-tit) is a Finnish word too: the plural of "a lone village road splitting the village in half".

Would make a nice library name. Wonder if Metosin takes requests...

We don't have instrumentation in production, ie. we spec much more at dev time. But for things you'd validate anyway spec is a good match and probably about as performant as hand-written validation.

The only strange use of spec I mentioned is validating db queries. For us updates and deletes are rare enough that perf doesn't matter.

What parts of compatibility are missing? The interop works just fine, as with all other Java.

  ; example: Stream.of(1,1,2,3,5).map(x -> 2*x).collect(Collectors.toList())
  user=> (.. (java.util.stream.Stream/of (to-array [1 1 2 3 5]))
             (map (reify java.util.function.Function 
                    (apply [this x] (* 2 x)))) 
             (collect (java.util.stream.Collectors/toList)))
  [2 2 4 6 10]

Of course it's not practical to convert lists and functions to their Java counterparts like that, but if you need to work with Java objects it's possible.

That is true for guest languages designed to overcome specific issues in a given language (think CoffeeScript vs. JavaScript in 2012 and then in 2019). But I don't think it really applies to Java vs. Clojure, which both pretty much force a specific (different) programming paradigms and have completely different design.

Spec is great for validation. For example, we have a HTTP API built using https://github.com/metosin/reitit where we have specs for each endpoint. We have a coercion middleware that checks each request (and optionally response) conforms to a spec (and coerces things like integer ids from path to the correct type). And there's a swagger handler that automatically generates a full documentation of the API just from the route tree and specs, including samples of input and output for all routes.

Similarly you can do HTML form validation, etc.

We even use honeysql with nice helper functions that ensure that data-changing SQL queries are of the expected form. Say, you want to update just one row, you have a helper function that checks the honeysql data has a where clause with a unique column and only then runs the query. Someone should maybe blog about that sometime.

What I've found, though, is that trying to use spec like type checking is usually not a great idea. I expect better from static analysis / compile-time checking, with clj-kondo being the most promising tool atm.

A matter of taste, probably. I love every other game by Zachtronics except Opus Magnum. With TIS-100 the clear favorite.

Somehow the highly geometrical puzzles don't give me a feeling of achievement. They're not very interesting but do become quite difficult towards the end. But of course many other people just love them.

They're very different. SHENZHEN I/O is mostly about microcontroller programming. KOHCTPYKTOP has you building semiconductors by drawing lines. Of course the latter influenced the former, but the gameplay is just completely different.

There are videos of both online if you want to get a better idea.

Just a thought: making cars comfortable and safe for the drivers also makes them weigh A LOT. Which makes for huge emissions. If we were to consider ecology, taking a 70kg individual somewhere shouldn't be by a 2000kg vehicle.

As a pedestrian/cyclist/driver I'd love to see cars that are basically motorized tents weighing something like 100kg. That would make me feel much safer when outside the car, and much more considerate of others while inside.

What do you mean by penalising?

If a road has a 40km/h speed limit, and then road features designed for 40km/h are added, what's the penalty? The point is to require the driver to focus, which a good driver does anyway.

Sounds to me like you have a biased sample. In my surroundings many of the experienced people prefer simplicity and avoid premature optimization.

Agreed. Modeling your own keyboard chassis is possible, and there's plenty of open source models to start from. If you have access to a 3d printer you get down to normal mechanical keyboard price range.

My own attempt is at https://github.com/dancek/dactyl-keyboard/tree/less-aggressi... . While I only have the left half built, I'd say that measuring fingers and tuning an ergonomic layout to your preferences works well. I don't expect to see a production keyboard as ergonomic. Ever.

N.b. the amount of work needed for this build is pretty ridiculous. There's a reason that keyboards are usually flat.

"I have so much to do that I shall spend the first three hours in prayer." -Martin Luther

I can see where you're coming from. My native language (Finnish) also uses letters with diareses, mostly ä and ö but also å. But I did make sure my kids' names are easy to spell and pronounce in English. A name like Ääliö would be just asking for trouble, in many senses. ;)

It's Åkesson, actually. Quite cool to have your initial mostly unused as a one-letter abbreviation/name. Except for ångström (Å), of course.

Extreme ownership probably refers to the book Extreme Ownership: How U.S. Navy SEALs Lead and Win.

All processes running on your computer can read the clipboard at any time. Many have plugin systems that expose clipboard contents to plugins.

Normally when you use a password manager you have to trust the password manager, the browser and the OS. By copying to clipboard you have to trust every piece of software you ever installed and every update they later got.

I don't have that many and the ones I use tend to enforce password type (say, a 4-number PIN as part of MFA).

But yes, I do remember a bunch of important unique passwords, and I do have to reset them occasionally by physically visiting and showing my id.

I'm not sure if I believe that, but I'd never trust anyone with bitcoin seeds. I'm not sure what the risk is for passwords I'd type in my browser anyway and that I could reset with my Gmail account.