3 ms·

Oh, this one is great! I always disagree with the people that dismiss "CRUD-apps" or languages/tools made for "simply (ja!) crud code!". I do CRUD for life. I

by mamcx 9y ago

Oh, this one is great! I always disagree with the people that dismiss "CRUD-apps" or languages/tools made for "simply (ja!) crud code!". I do CRUD for life. Is NOT simply. Ever. Sometimes, for relax, I toy with language design. Maybe I must do some assembler or APL. Certainly easier that try to implement the crazy scheme of "discounts" of my customers!

kbenson 9y ago
I do quite a lot of integration with our Point of Sale, directly through it's SQL back-end. Occasionally I represent partial or all inventory in a separate DB which is easier to deal with, isn't subject to their odd schema, and so I can tie it in more directly with lots of other data we've acquired. Occasionally the owner brings up that maybe we should just write our own POS, to which I very quickly back-pedal and let him know that's not a good idea. As much as the actual inventory tracking isn't that hard compared to what we've done, the accounting portion is not something I want to touch with a ten-foot pole. Let someone else make sure the accounting reports we do our taxes from don't have odd bugs, and spread the gains of bug-testing and fixing across thousands of customers. I've already got plenty on my plate before trying to take on a massive project with huge downsides like that. > Certainly easier that try to implement the crazy scheme of "discounts" of my customers! Any billing system that can correctly account for all the various ways businesses and sales departments want to display, link, sell and promote services over time quickly approaches a complexity which is hard to to explain, and without conscious effort also quickly becomes the domain of a few select people that have bothered to actually dive into the mess, leading to silo'd expertise. Additionally, if you try to make it easy for non-programmers to use, you quickly end up with a DSL which while it may get the job done admirably, is necessarily powerful and expressive enough that you end up having pseudo programmers to write and read them anyway.
- mamcx 9y ago
  > you quickly end up with a DSL which while it may get the job done admirably, is necessarily powerful and expressive enough that you end up having pseudo programmers to write and read them anyway. Yes! Now I truly converting that "toy with language design" to actually "maybe use it for my apps!". P.D: And yes, I know is good to use any lang already made, like Lua or TCL or similar. But CRUD-apps are not very well served by most languages today. If wanna know what kind of language is almost ideal check it FoxPro (or the dbase family)

by mamcx 9y ago

kbenson 9y ago

I do quite a lot of integration with our Point of Sale, directly through it's SQL back-end. Occasionally I represent partial or all inventory in a separate DB which is easier to deal with, isn't subject to their odd schema, and so I can tie it in more directly with lots of other data we've acquired. Occasionally the owner brings up that maybe we should just write our own POS, to which I very quickly back-pedal and let him know that's not a good idea. As much as the actual inventory tracking isn't that hard compared to what we've done, the accounting portion is not something I want to touch with a ten-foot pole. Let someone else make sure the accounting reports we do our taxes from don't have odd bugs, and spread the gains of bug-testing and fixing across thousands of customers. I've already got plenty on my plate before trying to take on a massive project with huge downsides like that. > Certainly easier that try to implement the crazy scheme of "discounts" of my customers! Any billing system that can correctly account for all the various ways businesses and sales departments want to display, link, sell and promote services over time quickly approaches a complexity which is hard to to explain, and without conscious effort also quickly becomes the domain of a few select people that have bothered to actually dive into the mess, leading to silo'd expertise. Additionally, if you try to make it easy for non-programmers to use, you quickly end up with a DSL which while it may get the job done admirably, is necessarily powerful and expressive enough that you end up having pseudo programmers to write and read them anyway.

mamcx 9y ago
> you quickly end up with a DSL which while it may get the job done admirably, is necessarily powerful and expressive enough that you end up having pseudo programmers to write and read them anyway. Yes! Now I truly converting that "toy with language design" to actually "maybe use it for my apps!". P.D: And yes, I know is good to use any lang already made, like Lua or TCL or similar. But CRUD-apps are not very well served by most languages today. If wanna know what kind of language is almost ideal check it FoxPro (or the dbase family)