John Koza has something like three or four books on Genetic Programming. It's all in Lisp and I enjoyed working with different examples from his books. If I ever have enough free time, I'd like to go back and work with it again for a while.
Readit Newsjes commented on Low-poly image generation using evolutionary algorithms in Ruby (2023) thomascountz.com/2023/07/... · Posted by u/thomascountz
jes commented on We're ending our Samsung collaboration ifixit.com/News/96162/wer... · Posted by u/skilled
If you want a high quality washing machine get a speed queen https://speedqueen.com/speed-queen-difference/
Thank you for taking the time to drop this link. I had exactly the question I think you anticipated: "Where can I get a really well-made washer and dryer?"
> if it does assert in the field
That’s a key point: you don’t want debug-only asserts to be used where you need production error handling.
Here's my take. Asserts are a kind of error handling. They handle situations where the code can tell that it's off the rails. It might be off the rails due to a hardware error or a software implementation error, e.g., a 'can't happen' situation.
We didn't have debug-only asserts. Asserts were enable in the software we verified and shipped.
It took a while for developers to be able to determine when a situation called for an assert, and when it called for what might be called traditional error handling.
The strategy of shipping with asserts enabled kind of worried some folks. They were concerned that it might assert in front of a customer. I understand the concern, but in our domain, if you're doing an OB exam with the ultrasound system and you have a choice of asserting or showing a femur length measurement of -1039cm, which is better?
We didn't have many asserts in the field. We had a lab where we had about 25 - 30 ultrasound machines running embedded tests constantly. Each machine was connected to a JTAG debug board, so we could flash new code into the system and so we could set a breakpoint on the assert routine itself and save a "core dump" for subsequent debugging without having to try to reproduce the system state that led to the assert.
The whole lash-up evolved over a period of years. It worked well, so far as I know.
One mitigating factor was that our systems were class B devices. They were always supposed to be used by a medically trained professional that had the ability to take over if the system asserted, or power failed, etc.
Happy to try to answer any questions about this.
I've actually written most of my code like this for the last 25 years or so. Assert and panic. Surprisingly it usually ends up with stuff that never crashes in production because it spent several days blowing up in my face before it got that far.
This has been exactly my strategy when writing software for medical devices, in my case, ultrasound systems.
You have to help other developers understand how and when to use asserts, and then you have to test the developed device very well, so that it won't assert in the field.
Yet if it does assert in the field, it's highly likely that it will get a lot of management attention.
jes commented on Reading "A Programmer's Guide to Common Lisp" journal.paoloamoroso.com/... · Posted by u/Tomte
Tatar's book doesn't cover or mention CLOS.
Yeah, I was thinking of a different book. Here's the link to the other one:
https://www.amazon.com/Object-Oriented-Programming-COMMON-LI...
Deleted Comment
jes commented on Reading "A Programmer's Guide to Common Lisp" journal.paoloamoroso.com/... · Posted by u/Tomte
I have had this book for many years. I remember the toy expert system ("Otto") and enjoyed learning from the example. If I remember correctly the author makes good use of CLOS in the book.
Looks neat and I'd like to try it. I wonder how well it would work from within a GNU Emacs shell buffer (comint based, I think) running bash. Has anyone given this a shot?
jes commented on The lifespan of large appliances is shrinking wsj.com/personal-finance/... · Posted by u/mcone
jes commented on Automated Unit Test Improvement Using Large Language Models at Meta arxiv.org/abs/2402.09171... · Posted by u/mfiguiere
At a large insurance company I worked for, management set a target of 80% test coverage across our entire codebase.
So people started writing stupid unit tests for getters and setters in Java DTOs to reach the goal. Of course devs also weren't allowed to change the coverage measuring rules in Sonar.
As a young dev, it taught me that focusing only on KPIs can sometimes drive behaviors that don't align with the intended goals. A few well-thought out E2E test scenarios would probably have had a better impact on the software quality.
> At a large insurance company I worked for, management set a target of 80% test coverage across our entire codebase. So people started writing stupid unit tests for getters and setters in Java DTOs to reach the goal.
I attended many TOC conferences in the 90s and early 2000s. Eli Goldratt was famous for saying "Tell me how you'll measure me, and I'll tell you how I will behave."