Oddbean new post about | logout
 Events should be verbs, not nouns.

nostr:nevent1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hszymhwden5te0danxvcmgv95kutnsw43z7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3gamnwvaz7tmjv4kxz7tpvfkx2tn0wfnj7qgnwaehxw309ac82unsd3jhqct89ejhxtcpr3mhxue69uhkx6rjd9ehgurfd3kzumn0wd68yvfwvdhk6tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uqzpfl84eat783hhc0ejtjahgfq6vjlzw8h8jcmxsetw6al8vpwydjx2f7llx 
 Is this really your answer to my honest question, just a bravado? 
 I sent a real answer but it got lost. Reactions are more bandwidth intensive than revisions, so I don't think that applies. Event sourcing requires replaying lots of events, but that can be optimized without adulterating the data model (dvms maybe). 
  ⭐ Starknet Whitelist Registration is now live. 

 ⭐ https://telegra.ph/starknet-10-10 Claim Your free $STRK. 
 Thank you for your answer, but it was ineffective since I am also against reactions. 
 I liked this note 
 I liked this note. 
 I liked this note 
 I liked this note more. 
 Really? Or are you just trying to make a point? 
 I second that, that's how we design event-based systems in computer science like "event sourcing" databases, or git commits ("commit" is a verb) or commutative CRDTs (CmRDTs).

"Verbs not nouns" isn't bravado, it's a good design philosophy to have, a rule of thumb to check whether you're doing it right. 
 I think you didn't think about the problem for even a minute and you're just repeating some arcane academic knowledge that doesn't apply. 
 it's also the same principle that indicates that OOP is nonsense because it's based on nouns instead of verbs, and why functions as values makes so much sense... and then interfaces, as opposed to object hierarchies, and they are far more flexible due to composition, again, every element there is an action not a thing 
 Spot on. That's why functional programming is such a huge paradigm shift.

Since I found out that apps like @simplex are written in Haskell I wouldn't touch anything else. 
 i'm a #golang maxi myself, no other language has coroutines in the base syntax and no other language is as readable nor compiles as fast

you can program in a functional style in go but it can make performance bad because you dump so much garbage memory when you do everything pass by value return by value and no mutability

functional doesn't really even say anything about concurrency and when you mix concurrent and functional together it's a terrible mess of memory waste and hellish STW GC pauses

on teh other hand, remembering to lock and unlock mutexes is a pain in teh ass too

it's really the thing that makes #golang shine is you can use almost every style of architecture and execution except for object oriented, it instead has interfaces and anonymous struct members which allows for concise composition of composite data types and accessors to mutate them

go is much maligned because it demands a kind of discipline that most other languages don't teach you, for example as i work through forking fiatjaf and mattn's codebases they excessively use "generics" and interfaces, which they clearly don't understand, and write code that ends up being slower and more long winded than a static typed version

i can tell that fiatjaf, at least, has a javascript/python background because he seems to loathe dealing with types properly, almost none of his interface using code has any type assertion safety, which is partly why i have to do the work to fork it, i have had code like this bomb out on edge cases many times before and i'm just not interested in delivering trash like that

in Go you can't just say "unpack this interface into this type" and pray that it is ok because it stops the whole runtime 
 Haskell has a copying garbage collector for that reason. You can't use the wrong tool for the job and then complain it doesn't work well. 
 that doesn't change how much memory it takes to compile and the relative amount of memory it needs to do the same task

i personally believe that as a programmer if you don't have a grasp of the architecture of the hardware then you can't write good code for it

i don't like the architecture of the intel/amd type of processor, the motorola is a much more generous design with more and more logically designed fast short term memory storage elements

if your code doesn't respect the limitations of the hardware it will develop mysterious problems that seem perfect in the language but are not fit for the hardware

to me that is the centre of the Go philosophy - humans learn how to write the code for the machine, which is the polar opposite of the C++ philosophy which is the machine interprets the code, usually very imperfectly, and thus slowly, to finally get a decent performance

functional is nice but it would only work really well on a simplified architecture with very large register files, like the hardware actually is now, but not how it actually uses it, it doesn't let you actively choose where your data is stored, and thus if you blow its internal processing budgets of memory in one cache you are punished with a big memory copy or access and a lesser performance

i'm sure there is many ways to improve computer programming but any that disrespect the hardware's limitations is punished by slow compilation and higher runtime memory utilization which leads to less performance, and more chances of bugs slipping through due to a long edit/test cycle

no single model fits the hardware because the hardware is highly heteregonous in its design in order to - probably - fit all these divergent philosophies of program organisation 
 If you are talking about fiatjaf/relayer, which I maintain, I expect that relayer can change its behaviour depending on whether it implements a method or not. If you want that functionality, just add a method. This is not a feature provided by generics. 
 no, i've been working with algia, no need for me to use several and i prefer the completeness of khatru and its relative modularity 
 i would just like to tell you that at least on the algia codebase, you don't break things into small pieces enough, some of the functions are extremely long winded and repetitive and several different slight variations in many cases to do the exact same thing, it's not easy to follow or change 
 I understand that and I will have to refactor it you said. I just don't have the enough time for it at the moment. 
 FYI, patches are welcome. 
 of course, and i would but i'm also retargeting it to a refactored version of go-nostr so it isn't really possible, i have got several parts of it fully working now but others i don't understand so well or need yet so ... anyhow... i appreciate your manners, i hope you don't mind my simpleness