Clojurians Log v2
off-topic
FFS! We created a system I can't talk about. But the sytem supports foos (I cant' tell you what foos are), upto 4000 meters. When I was designing I asked multiple times is 4000m the max? I made it abundantly clear that I need to know that 4000m was the max. This sytem needs a small rugged touch screen monitor. Supporting 4000m of real time info was HARD to fit on such a small screen. I was repeatedly told that 4000m was the max. I designed it all for 4000m. EVen when it was finished and being Ok'd by the insurance / regulation body that reviews foos systems I asked is 4000 metres teh max? I was told yes! I was told to just hardcode a bunch of stuff for quickness on the assumption that the max was 4000 metres. We've potentialy sold 3 units, the units need the system to support more than 4000 metres. Fuck My Life. I'm tempted to just quit at this point. Updating it to support 50% more than 4000 metres is going to be such a pain the ass.
I am always so very, very suspicious of arbitrary numbers in requirements. But at the same time, I'm also surprised whenever an INT UNSIGNED AUTO_INCREMENT column in MySQL actually hits the maximum value. Seriously? Do you have any idea how many records of data that is?
That is only 4.2 billion
Not a big number in 2021
Stopped using int32 as primary key a long time ago
Having MySQL hit that number is a good reminder that it is, indeed, not really “big” number these days 🙂
problem is, the 4000m works on teh current hardware screen. 6000m wont work at all without rework, a LOT of rework 😞 I need a new job!
Harsh environment effects on hardware are a pain. I feel you. There are similar issues with chips and temperatures
Do you know what it means if on your companies Hackathon day you code in clojure and a butterfly 🦋 lands on your window? It means that summer is near.
M-x bufferfly
Yes, it’s nice, the grapevine in the front of the house is also starting to turn green,
I'm excited about the potential in this lib https://github.com/oakes/odoyle-rules to offer an abstraction level over web development that I feel I have been working toward for a number of years. What is everyone else's impression?
Is the ticket you’re referring to about truth maintenance? Just checked it out. There’s also a mention in the readme. Part of problem may be my inexperience with rules engines. Truth maintenance means you can add, change, or remove rules and it will update the derived facts to be consistent with the latest rule set. For repl driven development, my desired workflow was to be able to update the rule set while the app was running. It would probably be feasible to clear all the inserted data, update the rule set, and then re insert all the data, but that would just be implementing an inefficient form of truth maintenance. From, https://github.com/oakes/odoyle-rules/blob/master/bench-src/todos/README.md. > Yeah...obviously a lot more manual effort than that beautiful DataScript query we made earlier. But there are some distinct advantages to "building your own database" with a rules engine. In the spirit of honesty, though, I'll start with the downsides. That was more or less my experience. I felt like I was “building my own database” when I could just use a database. There may be an alternate, better approach, but I’m not sure what that would look like. Maybe I’ll give it another shot at some point in the future.
Very interesting. Thanks a ton for sharing, I'll leave more feed back when I get time.
I have a moment more 🙂. Fair warning, i'm a total novice to, given a deadline I wouldn't be pinning my hopes on my current understanding. > Truth maintenance means you can add, change, or remove rules and it will update the derived facts to be consistent with the latest rule set. That isn't my impression. To me TM is the guarantee that IF X Then Y. The absence of it in OD means that IF X then Y will happen, but then if NOT x then NOT y wont happen. thats confusing but an example should make it clear with TM: y= false -> x == false y = True -> x == true y = false -> x == false withtout: y= false -> x == false y = True -> x == true y = false -> x == true Will note just the last steps are different. But as the TM ticket suggests, you can implement that with a bit of code. > my desired workflow was to be able to update the rule set while the app was running I think theoretically there would be no reason why this couldn't happen. I'll read the link you attached... Thanks again, i wouldn't worry to much about not using odoyle. I'm just happy to discuss it with someone 🙂 .
Yea, I'm sure it's doable with a rules engine, but I'm not sure what the best way to leverage the rules engine would be. In my head, the approach would be something like: 1. write normal UI components and use general data access 2. have a way to automatically convert your UI to leverage the RETE algorithm for performance
I investigated using odoyle-rules to manage state for user interfaces and didn't find it to be a good fit. odoyle-rules does not support truth-maintenance which makes it harder to support repl driven development. In practice, that means that as you build your system by adding, changing, or removing rules, you have to reset the rules engine and re-add all the data to get your app in a consistent state. I then tried clara since clara does support truth maintenance. What I found is that I felt like I was spending a bunch of effort essentially building materialized views of the app's data for my views. I'm now using the in-memory dbs like datascript. I think there's still some room for a higher-level API that uses a rules engine under the hood, but using the rules engine directly felt clunky. It's also possible that it felt clunky because I don't have a lot of rules-engine experience. tldr: I think using rules engines for UI state is a cool idea, but I couldn't get it to work.
Did you see the ticket for it?
Why would it effect the repl specifically?