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?

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 ... None of this is known from the onset by the developer. The developer is forced (rightly or wrongly) to follow an agile approach ... an agile team should perhaps enforce the SQL-92 standards.

Unclear requirements are a very common problem. I see them so often I wrote a series of articles about it. If you and your team are suffering from chronically unclear requirements, the SQL-92 standards won't save you.

Instead, you need to have the courage and honesty/transparency (often lauded in Agile) to have a serious conversation with your Product Owner, explaining that it is wasteful and disrespectful to your Dev team to ask them to proceed with unclear requirements. Be proactive: if your Product Owner is lacking resources (goes with the territory in my experience) volunteer your team to do an initial sprint with the sole goal of clarifying requirements, using some of the techniques mentioned in Building the Right Thing (Part III): Customers such as:

• Distill customer interviews and customer conversations into a manageable set of Personas. Make these personas visible to everyone.
• Ask why. Understand why.
• Find the root of the problem.
• Understand the problem.
• Define the solution.
• User Journey Mapping. Shows end to end flow of a persona using a feature, starting with installation.
• Get the user journey right (e.g. map out how someone enters/exits a feature).
• Value-stream mapping.
• Fake it till you make it. Use a variety of Pretotyping techniques.

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