3 ms·

One thing that annoys me about static typing is that most of the CRUD programming I do merely martials data back and forth between the screen and database. Only

by tabtab 8y ago

One thing that annoys me about static typing is that most of the CRUD programming I do merely martials data back and forth between the screen and database. Only a fraction is processed, or should be processed by the application. Things like null-ability, base-type, and max length should be supplied by the database and therefore not echoed in source code per the Don't-Repeat-Yourself principle (DIY). If the screen validation needs to know such info, it can get it from the database dynamically. But, our stacks don't typically do this for unknown reasons, and thus we reinvent the field attribute wheel in app code. (I posted a question similar to this on HN recently: https://news.ycombinator.com/item?id=19146439 https://news.ycombinator.com/item?id=19146439 )

maxxxxx 8y ago
I am a big friend of static typing but I agree that there should be a better connection between the types in the database, the types in the programming language and the UI validation logic. Some ORMs help but I think this could be simpler.
- tabtab 8y ago
  ORM's have a big learning curve, especially troubleshooting, and tie your stack to an ORM brand. But the worth of ORM's are probably another topic. I'd like to see a data-dictionary-driven approach where most of field info comes from a data dictionary, and only deviations need to be defined locally. (Or perhaps create and mark dummy columns in the data dictionary that are slated to be used for local customization.) I suppose one could push a button and have static classes or definitions generated for the source code from the data-dictionary, and thus still have a statically typed system. It's still duplication of field attribute info, but at least it's systematic duplication. I used to use systems/tools that integrated the database, business logic, and UI; and they reduced the amount of typing and code rework by a large amount. The multi-layered approach may give us cross-vendor flexibility, but at the cost of more code diddling to wire up the interfaces between all the layers. Layer independence seems to increase duplication of field-related info. Back then I could spend more time on requirements and analysis and less on code wiring and re-wiring. Now we waste too much time dealing with low-level repetitious grunt work.

by tabtab 8y ago

maxxxxx 8y ago

I am a big friend of static typing but I agree that there should be a better connection between the types in the database, the types in the programming language and the UI validation logic. Some ORMs help but I think this could be simpler.

tabtab 8y ago
ORM's have a big learning curve, especially troubleshooting, and tie your stack to an ORM brand. But the worth of ORM's are probably another topic. I'd like to see a data-dictionary-driven approach where most of field info comes from a data dictionary, and only deviations need to be defined locally. (Or perhaps create and mark dummy columns in the data dictionary that are slated to be used for local customization.) I suppose one could push a button and have static classes or definitions generated for the source code from the data-dictionary, and thus still have a statically typed system. It's still duplication of field attribute info, but at least it's systematic duplication. I used to use systems/tools that integrated the database, business logic, and UI; and they reduced the amount of typing and code rework by a large amount. The multi-layered approach may give us cross-vendor flexibility, but at the cost of more code diddling to wire up the interfaces between all the layers. Layer independence seems to increase duplication of field-related info. Back then I could spend more time on requirements and analysis and less on code wiring and re-wiring. Now we waste too much time dealing with low-level repetitious grunt work.