The number one priority of those maintaining a DB system isn't performance or clarity, it's the integrity of the data.
Extra code for clarity is extra code that can have bugs which can have an impact on data integrity.
|Replies are listed 'Best First'.|
Re^3: Have SQL standards gone too far?
by betmatt (Scribe) on Jan 04, 2021 at 17:53 UTC
You gave one fairly general example of where you are coming from:
The more logic one puts into a single statement the harder that becomes. For me SQL is the obvious case in point. But the same may also be true for Perl code. Perl code development could be impeded by excessive compacting of code.
To give us a clearer understanding of where you are coming from, please give us specific examples of how "excessive compacting of code" impeded Agile development or of SDLC problems that could be solved by the programming language becoming more agile.
BTW, I laid down what I consider important in programming in On Coding Standards and Code Reviews, for example:
and many more. I went through these just now, but struggled when trying to decide which of these were more "agile" (update: they seem to be more aligned with Software Craftsmanship than Agile Software Development; see also Readability vs Maintainability).
What is an Agile Programming Language?
The agile manifesto defines agile development:
To be anti-agile therefore, a programming language needs to:
It's hard to imagine such a language.
Updated Jan 7 2021: Added "What is an Agile Programming Language?" section.
Let me give an example. Imagine a T-SQL or SQL system. In doesn't really matter if it is that or a Perl or Python program. There are equivalences in data structures and associated commands. In this system there is a requirement to perform complex statistics. The requirements of the system are not laid out from the beginning. So what we have is a set of interrelated statistic related calculations performed. Over time there are new datasets, different types of datasets, variation on the statistical methods, transformations and adjustments on the data and also variations in how the data is presented to the user of the system. Non of this is known from the onset by the developer. The developer is forced (rightly or wrongly) to follow an agile approach. If I was to develop such a system then would I want to use the SQL-92 standard or the most modern standard for SQL. Given the list that you link to I would argue that the SQL-92 standards would be better. More than that, it may be essential. Therefore an agile team should perhaps enforce the SQL-92 standards.
Now imagine that the system was developed using Perl and not SQL, which it could be using map functions instead of SELECT etc. The same would apply. Therefore there could be restrictions put on code to facilitate Agile development. Am I right?
Agile isn't the only methodology...
Besides, not everyone writes to suit a methodology community. I sure don't. One last thing, someone is less likely to change something they don't understand, so if a DB routine that works exactly as it should while keeping with the integrity mantra, I say golf the crap out of it to the point of near non-existence, so people will be far less likely to muck with it in an attempt to make it more efficient, or to make it more readable to those who don't understand it and shouldn't be playing with it in the first place ;)