in reply to Re: Have SQL standards gone too far?
in thread [OT] Reflecting on SQL. Meditating on Perl. Do languages meet requirements of Agile?

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
    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?

      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.

        The document that you link to (that you wrote) seems very good. On the post here that I comment on here I don't quite agree with your final point.

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