this post was submitted on 01 Sep 2023
329 points (96.1% liked)
Programming
17494 readers
122 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You could be onto something. On of my first language was "dBase" (early 90s) which, through it's style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.
Learning SQL on an enterprise database is what started my journey into coding. It really forces you to think about what you're doing because of how structured the language is. It's also very immediate in that you do x and you get y.
It also makes you think more about data models which I'd argue is why we ended up with the garbage that is MongoDB. Developers not thinking about their data and how it relates enough.
For anyone with their rankles up. 99.9999999% of the time you want an RMDBS. That remaining 0.00000001% you want NoSQL. So any project you spin up? Guess what? You want an RMDBS.
Completely agree. I really love SQL, but I hate it's syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).
dBASE was not my first language, but learning normalization and modelling completely transformed my user interface design. Starting with dBASE, every UI I built used all available data to do some combination of reducing the potential for error and reducing user effort.
For example, choosing "Tesla" as the make of car should obviously hide "F-150" from the list of models and hide all fuel types except "Battery Only". This seems obvious to pretty much everyone, but there are a lot of UI designs that completely ignore analogous data relations. Less obviously, but just as important, having reduced the list of fuel types to one possibility, it should be automatically filled in.
I find web forms, especially government ones, to be particularly bad at this stuff.