Declarative Programming is a business model

[bedman12345]

Strap in for some truth: Declarative programming isn't a programming language paradigm, but a crafty business model. Marketed as a solution, it's as declarative as a mute parrot.

Let's be clear: the order of SQL statements matters. Duplication matters. The illusion that you can cook up a random program and it will work is pure fantasy.

However, if you're a big-time enterprise customer with rented SQL software from a cloud provider, you're in luck. You can create subpar programs and point the finger at the provider when things go south.

The unsung hero? A tech maestro at the provider's end who manipulates the database internals to transform your blundering query into something palatable. Yet, they call this 'declarative'?

What's truly declarative is the farcical agreement between customer and provider, not the code. The next time you hear 'declarative programming', remember: it's less about the code and more about the customer's audacious demands.

[nivertech]

1. back in the day high-level programming lanaguages were also a business model. In order to sell their computers the HW vendors would provide a FORTRAN compiler for free.

2. Declarative programming can work for narrowed problem domains using DSLs/middleware, but not in the generic case. If you don't want to be locked, either chose a standardized DSL (e.g. BPMN), or implement compiler/interpreter/runtime/middleware by yourself.

3. SQL originary targeted end users (Analysts), but today it mostly target developers and DBAs. Today end users would mostly use BI tools or dashboards, not SQL directly. So I wouldn't use it as an example of Declarative Programming.

[quickthrower2]

That was a fun read. Not sure what to do with this information? When I write SQL I don't think of it as declarative - I think "what is the computer doing" roughly. Which is why I have found ORMs used in teams to be a bad idea because:

1. Step 1: use ORM - it's nicer and you can use C# or whatever.

2. Step 2: build an OO library of classes that call the ORM to do what ever.

3. Step 3: compose these, to build more complex operations. After all it is all free, you just compose the "InvoiceSubuery" and nest that inside the "UserSubquery" and so on

4. Step 4: production issue, database maxing out at 100%, sql query is 1000 lines long and about a million characters. It is joining 50 tables and aliasing them as EXTENT1, EXTENT2 and so on. Query plan is doing more scanning than the USS Enterprise in an unknown quadrant it got teleported to by the Q. You are having a bad week my friend.

5. Step 5: Step 4 happens every night, pager wears out.