Given that AI-generated code is not 100% perfect, we need to take into account the time and cost of reviewing when we discuss the productivity boost AI developers receive from code.
I convinced a software company to use a version control system (RCS on shared disk) back in 1993. To make it work we had to setup a network — Ethernet over (thin) coaxial cable at the time. This was so new to us that we didn't know we needed to use terminators on the two cable ends.
30 years ago (1995) open source offerings: mostly CVS for large projects and RCS for smaller ones. On the proprietary side, the aged SCCS was available and used, while Perforce and Microsoft Visual Source Safe were being launched.
I published an updated extension of this post's linked article in Empirical Software Engineering. You can read it without a paywall at https://rdcu.be/b7FzE. You may also be interested to see the actual GitHub repository at https://github.com/dspinellis/unix-history-repo.
That's the point: non-dependant tasks can run concurrently in Airflow. In sh/BAsh/dgsh dependant tasks can also run concurrently, as in tar cf - . | xz.
I'm curious: what do you mean by "dgsh will use iteration under the hood too"? Dgsh does several things under the hood, but I wouldn't characterize any of them as iteration.
I've found creating pipelines with Python to be messy and intuitive. Other than creating a DSL to express them I can't see how DAGs can be expressed naturally with Python's syntax.
Even creating tools in Python that can be connected together in a Unix shell pipeline isn't trivial. By default if a downstream program stops processing Python's output you get an unsightly broken pipe exception, so you need to execute signal.signal(signal.SIGPIPE, signal.SIG_DFL) to avoid this.
I went through two iterations before adopting the current syntax. Truth is neither me nor Doug McIlroy, the inventor of Unix pipes, who kindly and generously provided feedback during dgsh's development, had something better to propose.
Apache Airflow solves a very different problem. Its DAGs are static dependencies between sequentially executed processing steps, whereas the DAGs of dgsh express live direct data flows.