Re: Have SQL standards gone too far?

[Bod]

Any thoughts on all that?

Adding extra functionality doesn't necessarily come at the expense of previous ways of doing things. I cannot think of anything I wrote in SQL 20 years ago that would not work now subject to being tailored to the RDBMS in use. Although, like LanX I'd need some examples to be able to properly comment.

Compactness of code seems to me to be unimportant relative to clarity

I don't universally agree.
If it is a SQL query for a non-techie manager then sure, clarity is the priority. But the same isn't true for a query that is black boxed in a piece of code. Provided the creator and maintainers of that query understand it, nobody else need care about its clarity. Performance is probably the greatest concern followed by compactness.

[stevieb]

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.

[betmatt]

I agree with your first line. However I don't quite agree with your second. My thinking has been that all too often programming languages have not adequately taken into consideration the needs of the Agile community. If you were developing an analytical database, for example, in a Agile way, then logic separation might be key to that process of incremental development. 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. I'm in no way criticising the Perl community. It is however something that maybe the designers of the language, SQL in this case, but Perl also, should consider. Am I right?

[eyepopslikeamosquito]

So after a month of research into "agile languages", I must conclude there is no such thing. Barbarian coders are constantly looking to increase their speed to build the next new thing. Java developers are frustrated with their language's bureaucracy. Students entering the workforce are disappointed when a programming career is less fun than they imagined. None of these things relate to agile development. I'm not convinced a language could be built that would be a significant advantage to agile development. Software development methods are mainly concerned with people, while programming is about crafting code. They are really two separate problem domains. Anyone claiming a language is agile is trying to deceive you with hype.

-- What is an Agile Language? by Ken O. Burtch

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:

• Correctness, simplicity and clarity come first. Avoid unnecessary cleverness.
• Establish a rational error handling policy and follow it strictly.
• Plan to evolve the code over time.
• Don't optimize prematurely. Benchmark before you optimize. Comment why you are optimizing.
• Write the test cases before the code. When refactoring old code (with no unit tests), write unit tests before you refactor.

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:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

To be anti-agile therefore, a programming language needs to:

• Inhibit interaction between individuals and demand business process
• Prevent working software while forcing the writing of unhelpful docs
• Block collaboration with customers and refuse to function without a legal contract
• Make code changes impossible without compliance to a project manager's plan

It's hard to imagine such a language.

Updated Jan 7 2021: Added "What is an Agile Programming Language?" section.

[stevieb]

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 ;)