> Anyone who claims that FSD doesn't work is flat out lying.
i've had "fsd" for years and basically never use it now. i just don't trust it.
anytime there is a new version update, i do try to have it drive from the house to the market (about 3 miles: two rights at stop signs, two rights and 1 left at stop lights) and there has never been a single time where i didn't have to take over at least once.
and maybe the problem is that i have had "fsd" while it was going through development. the trust is low from the many times it has tried to kill me. so, whenever it is on, there is nothing but stress. and so i'm more apt than not to take over when i see anything even minutely out of the ordinary.
To help understand why a complex query with many joins comes back empty, I like to provide helper debug functions that builds the query step by step. Each block checks one prerequisite and tells the user what’s missing:
```sql
FUNCTION debug_user(user_id):
IF NOT (SELECT FROM user WHERE user.user_id = user_id) THEN
-- user doesn’t exist
END IF;
IF NOT (SELECT FROM user
JOIN user_addr ON user_addr.user_id = user.user_id
WHERE user.user_id = user_id) THEN
-- user has no address
END IF;
-- keep adding joins until you find the break
```
because when you have a query that involves 6 relations, and you don't get results, it is nice to know why.
i saw checked boxes hit almost 800K and then start dropping fast.
i've seen every other checkbox get checked on the entire screen in a second. some great scripting going on and i'm sure a lot insight is being learned by watching the tech stack handle these loads.
i noticed initially log messages were showing one check box change at a time but at some point updated to batching which is great. release and optimize!
A long time ago I was building a data entry system is Visual Basic for forms that, once entered, need to both store the input in a database and print out the form. There were hundreds and hundreds of different forms.
So, instead of making an interface for data entry and then a system to print the forms, the data entry UI for each form looked exactly the same as the forms themselves. Scrolling was needed because at the time there were only low resolution CRT screens.
However, for printing, I would draw the filled out form at a very high resolution in video memory "off screen" and print that.
So, the work to create one form resulted in supporting both data entry and printing.
It turned out that since the people doing the data entry also knew the forms really well, they were able to enter the data 2.5 times faster than initial estimates.
It's great to see a link specifically about Psytrance on Hacker News.
I enjoy trying to understand how Psytrance is made and if that is something you find interesting too checkout @Projector_music on youtube (no affiliation).
I would like to make a 120 square foot (internal dimensions) max 10 feet high roof to foundation listening room in the back yard. Very mild climate so heating/cooling is not necessary. Wall thickness is not an issue.
Do you think that is possible while still getting good base response and have minimal sound escape?
I spent quite a bit of time (about 8 years) looking into and working on VPLs. What I found was that our perceptions and interactions with various abstractions such as programming, mathematics, or even music (sheet music), are shaped by our individual mental models.
I code using programming languages because it was what I was taught in college and it's what I've used for decades. For me, something like SQL looks amazing and is super easy to rad. Whereas others may see SQL as something that is complicated to look at full of jiggling relations.
In the same way, a VPL may initially appear complicated, but this is often a reflection of unfamiliarity rather than inherent complexity.
As with many technologies, given time and development, there's potential for something groundbreaking to emerge.
What may seem complex today could become a new standard tomorrow.
> the reason why coding is so difficult is that interfaces are often too darn complicated to keep track of?
Haven't brought this up in a while. Ya. I feel coding is hard due to complex interfaces. I once worked on a programming abstraction, mechanisms, aiming for a consistent interface for easy composition.
Key features of mechanisms were:
1) All data types were mechanisms
2) A Mechanism needed no context (parameters) when invoked.
3) Composition of a mechanism could take any number of mechanisms (primitives at this point are treated as mechanisms) and return a mechanism.
4) Upon invocation, a mechanism functions in one or more modes, returning either a primitive data type or another mechanism.
Think of it as currying or Lisp's S-expressions, but supercharged, envisioned as a base for Visual Programming Languages.
> because it makes it look like applying an 1:1 relationship.
People can form different mental models of the same abstraction so I see what you are saying
I've never seen it that way because "Venn diagrams do not generally contain information on the relative or absolute sizes (cardinality) of sets." (see https://en.wikipedia.org/wiki/Venn_diagram).
> using the ORM that everyone else is familiar with
A relational database isn't always fronted by the same tech. You have RESTful APIs, GraphQL APIs, Low Code/No Code Solutions (like Retool), reporting tools, ETL systems, etc.
You have company mergers where that one familiar ORM is now five to six unfamiliar ORMs.
Ensuring data integrity is key and easiest way to do that is to push constraints as close to the persistence layer as possible.