Can really say anything about the products, but https://ultimatehackingkeyboard.com/ looks very similar.

I have an ergodox first generation. I have short fingers, and thus for me it was even worse than a normal keyboard as I couldn't properly easily reach the farthest keys of the thumb cluster. But it might have been fixed in ergodox-ez, which IIRC is an updated version.

Ergodox ez here. Had to swap a key last week after 3 years of use, but that's about it. (Newer models come with a swapping mechanism, so you wouldn't even need to solder things) Can confirm that some keys, specially on the thumb cluster, are definitely a bit too far (and my hands aren't particularly small) Regardless, there's no going back. No more pain + programmable. The sole contender would be keyboardio, but it has a larger footprint.

Co-worker has one and he seems to enjoy it. I thought it was a little awkward when I tried it but I am guessing you get used to it

i have small hands and i am afraid it might be too big for me now

I saw that there are a lot of keycap types to choose from. Are any of them 'small' or intended for us with smaller hands

> both have their advantages and disadvantages You're definitely right here. At some point, I was fed up with dealing with namespaced keywords. So now I just work with the plain ones, unless there's a really good reason to use the namespaced ones.

Honestly, I kind of hate namespaced keywords :p

A love/hate relationship I'd say

My rule is generally that I only use them for keys

And only when they are for shared concepts

So normally in combination with spec

So in your example, when using keyword as values I wouldn't namespace them, so it would be :default

I also don't generally include the app name

Unless the data was to be shared with other apps, but even then, most often you wouldn't comingle it without some other partitioning.

So I'd just do: #:user{:id #uuid ... :role :default}

I even dropped the #:user bit from most of the places. Suppose you have #:cat {:children [...]} and #:dog {:children [...]}. Well, now you cannot have code that operates on :children because there are no :children, there are only :cat/children and :dog/children. And passing the ns or the particular kw get ugly real fast.

And I stopped using :: and all that, as it just creates monster namespaces on the keys which I don't find particularly useful. Also, you cant refactor as easily since it complects the key and the namespace it is in

Ya that's true. That's what I meant by shared concept though

If children is shared, I'll spec it and give it a namespace like: :acme/children

Or :animal/children

Eh... maybe I should just drop them all together as well 😆

:: is nice with spec and re-frame, especially given that you can use namespace aliases with it. And for keywords that server as an implementation detail, like ::not-found or something like that.

Now that I think of it, I'd actually do {:type :dog :children []} for your example, and create a multi-spec over type

Whats the point? That you can tell the namespace in case of an error?

You mean with ::?

Ya?

Like you said its nice with spec and reframe

Why is it nice?

With spec I stopped using it, because it coupled my spec with its location in code. Like you can't just move the spec to a different namespace later

Or rename the namespace

atm I'm using a namespaced keyword as a tombstone value in an immutable db to signal a deletion. It means you can't store the value ::tombstone in the database, though :rolling_on_the_floor_laughing:

With spec - because you no longer need to think of some particular ns that somehow corresponds to the current ns, you just use the current ns. Since you can avoid using ns here altogether for a good reason, :: makes sense here. With re-frame - because it makes it much more obvious what ns you need to require to dispatch a particular event or subscribe to a particular subscription. :common-ev/get-updates can be easily dispatched without requiring the file where the corresponding reg-event-fx is called. But something like :acme.data/get-updates will make you think and provably do a (require '[acme.data :as ad]) and dispatch ::ad/get-updates instead.

Moving a spec or renaming its namespaces doesn't differ from any other refactoring. It's just a bit more places where you have to make the change. NS aliases with :: make it a bit easier as well.

Ive just been burned by them. As long as they are only local and in memory it works great, but persist any data with them and you're stuck

The biggest issue is, you can't alias if there is no corresponding namespace

Its rare I'll rename or move a namespace. But its common I'll move fns out of it into another one

Yeah, but not having a corresponding ns is an issue separate from :: though. Also, I think there's a ticket to support such aliasing.

And so I find it weird, the namespace doesn't own the data, it all feels so OOP to me

@U064X3EF3 mentioned something in relation to human editing vs computer at some point as rationale for deps.edn

Right, I like the idea of ::, but tying to code modules I think was a mistake

@U09LZR36F I'm struggling to tie something as a rationale for deps.edn to the talk about namespaces, to be honest. :)

Sorry, I meant the rationale for deps.edn not using namespaced keywords. Brain is done for today I think :)

Although deps.edn still uses namespaced keywords... So I guess there were other reasons at play, so to speak.

Someone had asked something I thought was possibly the missing piece, chaining namespaces

Cause one annoyance now is: ":user.profile/id"

{:user/profile {:user.profile/id 123}}

This gets cumbersome real fast as you have more and more nested maps

Worse if you used ::

Family trees would be fun: {:mother {:mother/mother {:mother.mother/mother ...}.

If you have ::, you have com.acme.cool-app/user

But you can't do: ::cool-app.user.profile/id

And have cool-app expand

So now all nesting you need to type the full alias ugh

Anyways, I'm starting to think like you, do we need all these namespaces? What for? I can just start using :req-un and :opt-un everywhere. Then I'd only use ::for spec names.

Which by the way, I find strange as well. Why not use symbols for referencing specs? The only reason I can think is because of how the keys are meant to map to their spec

symbols are used for referencing function specs

symbols are annoying to use unresolved because quoting

True, but I've seen many people add back resolution to keywords just to make sure they don't have typos or forgot some spec, etc.

In general, I havn't found myself needing to spec things that depends on spec to be defined later

So I'd actually enjoy symbols throwing error if I do

Unless I'm missing something

And I feel in the case you do need too, declare could have been used similarly, like an s/declare

Hum...

user=> (def Int int?)
#'user/Int
user=> (def Foo (s/or :int User :string string?))
#'user/Foo
user=> (s/conform Foo 12)
[:int 12]

Okay, maybe I get it. If specs had used the same registry as var, it would be fine, but given it has its own registry, then all symbols must be quoted

Or they'll be looked up in the namespace symbol->var registry, and you won't find it there

But for FN specs, since there is a symbol of same name in the ns already for the actual function, this problem doesn't exist

This is dope. Thanks.

And Datomic.. :)