When will your project ‘grow up’ and require typesafe code?

There is common belief that after an initial very agile development period,  “grown up projects should switch to a static typed language”.  This also raises the question, “are type-safe languages less suitable for early stage development?”  This page considers the evidence for these beliefs, plus considers if there is a benefit to starting dynamic and switching to static, what is the crossover point?

TL;DR? As usual, read the headings and choose only read beyond the heading when you choose.  But in summary, modern statically typed language, and specifically kotlin, are bringing forward the point where adoption is logical, to the point it can now be argued that any project that justifies its own repository, would benefit from starting out as a kotlin project. For smaller projects that will live a short time…. Python is still king.

• Background
• Two Families of Language:
  • Dynamic
  • Static Languages
• Projects as Acorns (will your project grow)
• Why Dynamic Languages for New Projects?
• Why Static typed languages?
• Choosing a Language
  • Java Vs Python?
  • Python Vs Kotlin?
• Conclusion: The game has changed.
  • Python for small familiar project
  • Kotlin for larger projects

Background

A talk suggesting grown up web companies become Java shops started me thinking.  Discussion on that talk can be found here. The title suggests that start-up companies at an early stage do not use Java, but once business scales, the projects migrate to Java.  The author clarified that he was not suggesting that projects completely migrated to Java code, but rather, these project added Java to the mix.  Curiously one of the key examples referenced,  heroku, (originally a Ruby project) is cited as adding not actually Java, but Scala as development tool.  Another example, google, (with a strong Python base) is cited as adding C++ and Go language.  These examples illustrate that when tech companies mature, they may add static typed languages, but not necessarily Java.

I suggest the original statement represented a java centric view of the world. Since 1996, most programs written in a statically typed language were written in Java, and for most of that time there was far less choice for statically typed languages than available today. Consider this data on which languages programmers like vs dislike (as opposed to stats on how often the language name appears in searches) which is data suggesting that the most popular languages are all statically typed, and are all new languages.  Best choices for a static typed language, and perhaps for any language, are all new.

There does seem to be even official recognition within Java ranks that Java is more likely to be introduced later in the product lifecycle.  Oracle with the  Java first and Java always message is clear on this.

“If you take an honest look at where we are today,” he said, “we can apply that famous Redmonk quote: ‘When companies grow up, they turn into Java shops.’ That tells us something, though. It tells us that people are writing in something first and then rewriting in Java. We need to change that… We want the next decade to be Java first and Java always.”     – Mark Cavage, Oracle VP of Java Product Development at Java One 2017

At the same Java One conference, Niklas Gustavsson, principal architect at Spotify,  told how they converted from Python to Java, and that python was great to get started, but Java is better once the project scales up.

Projects As Acorns (Will Your Project Grow)?

Projects can grow from a tiny acorn into the largest oak tree.  But some acorns just get eaten by squirrels.  I guess every project has a potential to grow, even those that had no intention of growing.  There are loads of small projects with no intention of ever growing into that oak tree, and realistically, for a really small project it is really hard to go past Python.  Changing to a new language will take time that will not have suifficient time to be recovered in a small project.  With a static language there is a build process, and the smaller the project the more relatively significant that complication.  Plus, Python has libraries for everything.  Ok, Java has just as many libraries so most things will be covered by both, but Java is just verbose and even using Java libraries from Kotlin does not isolate from that verboseness culture having crept into the libraries.

There is a point in scale below which the disadvantes of dynamic languages become an advantage.  When only the author will read the code, and even they wont be reading it after a month,  those ambiguities arising from not knowing type are not relevant.  Great libraries, and a simple start are what matters for projects similar to the one last week.  Think a data science one of data analysis. Think a series of student projects. Short lived simple programs are numerous, and what happens when they grow up is irrelevant.

Two families of language?

Languages such as python, perl, ruby, and javascript are generally known as dynamic typed languages, or scripting languages, while C, C++, Objective C and Java are generally known as statically typed languages.   I suggest these names do not describe what is meant, just as Random Access Memory does not describe what we mean by RAM.

Dynamic/Scripting Languages.

Spiritual descendants of interpreted languages such as the original BASIC(1964)  and APL(1964), these languages have a clear focus on allowing programs to be built from the minimum code.  Saving the code that specifies type can be part of that philosophy, but generally only a small contribution, although it is one languages tend to share.

In fact origins of being interpreted is more clearly a common characteristic than how these languages handle types.  For example, The python official documentation describes the language as strongly typed. Python, for example, is described as a strongly typed language, only with the data, rather than the variables.

Languages often quote the “hello world” program.  With dynamic languages, you type the (often only one line) example and the program runs instantly.  No need to even save a file.

Static Typed Languages.

These languages are the logical descendants of compiled languages such as ALGOL(1958) and FORTRAN(1957).  To run the ‘Hello World’ program not only will the program normally need to be saved to file, it will also have to be compiled and ‘built’ into a program which will need one or more additional files.  Normal practice will often dictate that the program will be in a folder of its own, or in fact require a whole tree of folders.

While these languages do have static types,  as a family the static types themselves could be seen more as symptom of the differences rather than the entire set of differences.

Why Dynamic Languages for New Projects

Two key points in favour of dynamic languages:

• The most cited: the language is more concise
• In practice: the language environment delivers a program for very little effort

More Concise? Credit pragmatic syntax, not lack of types

Languages like Java or C++ are certainly for more verbose than languages like Python or Ruby, but the type declarations are not a significant part of this.  Typescript, which largely adds types to JavaScript, neither becomes more verbose, nor become less desired as a result adding types.  In fact typescript is one of the most loved languages.  Groovy, a language bringing dynamic types to the JVM, ranks below Scala and Java on the same survey.

A program with least effort.

To make a python program, you need only a single file. Contrast this with Java where not only does each program need its own folder, it typically needs several sub folders, plus build files to instruct on the build and dependencies.  In python or ruby, one file, acts as both source and executable and requires no build.  Libraries installed are available to all applications by just adding an import statement.  A key attraction to dynamic languages is that the effort to start a project is minimal.  Agile methodologies stress the importance of getting a running program early, and dynamic languages deliver.

If you already have the libraries installed and know those libraries, if the program

 

Why Static Typed Languages for Mature Projects Only?

The original quote specifically reference Java as inevitably playing a key role in mature projects, but even in the early 2000s when practically the only choices available were Java and C++,  not everyone chose java. Google added C++ and then build their own language in Go, and more recently some others have chosen Scala.

Certainly, especially given the language popularity, when a project felt the need for a static typed language, Java logically would most often be the choice,  but all we can say with real confidence is that projects move to add statically typed languages.  But why?

Regardless of a choice of Java, Go, Scala, Objective-C or C++, there is a genuine and significant list of projects that started out with a dynamic language and then added static languages at a later stage.  So why not just stay with dynamic languages?

Logically the answer is that on larger projects, the features of these static languages become more relevant, but something counts against them on smaller projects.  Given that the analysis of dynamic language indicated that static types can even strengthen dynamic languages, then static types is not to blame for the disadvantage with smaller projects.

So what counts against these static typed languages as an initial project choice? It has to be other factors count given that even adding static types to dynamic languages does not seem to deter from dynamic languages.  So what is the barrier and how do the relevant ‘features’ block the choice as an initial language choice?

I propose that this first language vs mature project language battle has not static types itself, but the characteristics of the language types people actually identify.   While some of these points may typically follow from static typing vs dynamic typing, perhaps they do not need to follow.   Here is one of the first results I found with a search for the advantages of dynamic types, and it is quite representative of community opinions. Repeatedly, what is stated is:

• The strongest argument for dynamic languages is: “It’s more concise”
• The strongest argument for static typed languages is: “Better (or more robust) design”

I would point out that the ‘more concise‘ that people perceive, actually relates no just to program source code, but the total files and folders of the project, which included build files, object files etc,  Robust code is very much that automated tools, including the IDE and compiler can pick up potential bugs. Static types clearly gives those tools a starting point.

So concise syntax and easy setup wins at project start, more robust wins later.  But when does a project cross over?

Language Choices Round 1: Java vs Python.

Java is the current champion of static typed languages according to the indexes of pypl, tiobe, stackoverflow and github.  The same indexes show Python is the overall leader of dynamic languages, (although javascript is slightly ahead on some indexes, but significantly behind on others).  Comparing Java vs Python, most (tiobe, pypl) put Java ahead, but not all (stackoverflow, github).  Almost all have the trend suggesting one day python will lead if current trends continue.

There is little doubt that java sees python as the challenger, particularly for those first stage projects where Java is seen as currently losing already.  Can ‘Java first’ ever be realistic, and if not, how early in project scale does java become a contender?

The key points are:

• Concise syntax and low effort for project setup
• robust code, assisted by static types and build process tools

On these key points, while Java as a language is improving, the result is neither to become as concise as python nor as simple to run a simply program.  In fact, despite the claim that mature projects move to Java, I cannot find a single indicator that suggests Java has a growing share of language popularity, while other static typed language clearly are growing in popularity, although from a much smaller base. Java has added language features such as lambdas, but it difficult to see how it was the lack of those features that resulted in projects that start in another language before eventually migrating to Java. I suggest Java may have addresses some reasons project defect from Java, but not the reasons Java was no chosen for a project from the outset.

In summary, moving a project to java is only a choice because the popularity of Java, and that itself is declining.  Starting a new project in Java is only really logical if the development tool has stronger experience with Java than with any other language.

Language Choices Round 2:  Kotlin vs Python.

Kotlin seems to be able to deliver a similar level of ‘concise’ to that offered by python, while delivering the same static capabilities as Java.  While measure programmer likes vs dislikes, programmer like python better than Java, they also like kotlin better than python.

Python is still left with some advantages, such as the extremely readable code partially due to the significant whitespace. Beginners can start with a REPL With a strong IDE like Intellij, kotlin can have similar readability, but unless well formatted there is still a beginner advantage to python.

The biggest advantage for python in this contest is the popularity, and strong base of libraries or ‘batteries included’.  Yes, there are many Java libraries, but resorting to Java libraries steepens the learning curve. Plus, python’s popularity means far more training material is available and questions answered on stack overflow.

As far as simplicity for a simple one file program, Kotlin does not yet quite match python. I will paste a specific page on this issue in future looking at what is required to enable kotlin to match python in this way. One key issue is the build process which will be helped significantly once the gradle dsl-kotlin project is well documented from a kotlin-dsl perspective.

For deployment, while the JVM does not necessarily ensure wider deployment possibilities than are possible with python, the addition of kotlin native does take deployment possibilities to a new level.  Python apps can be built for mobile (kivy) or run in the browser (brython) but with python these are fringe initiatives not endorsed by the core python community in the way kotlin gives support for mobile apps or javascript.

In summary, kotlin provides a valid contender for a true ‘choose first, choose’ always language.  The language is still new but the potential is there.  Current market share has the language as still fringe and there are key projects such as kotlin native and kotlin-dsl gradle that are early stage needing further progress to ensure this is the language of choice for all project phases.

Conclusion: The Rules have Changed.

Kotlin first, kotlin always, is now a valid choice, and language projects can follow that path now: for the right projects.

Many of the problems that made Static typed languages too time consuming for that simple ‘acorn’ level of the project have gone.  If there is faith that the ‘acorn’ will grow even a small tree, Kotlin offers a viable choice.

The Bleeding Edge

Acorn scale projects being efficient in Java has not yet happened.  With Kotlin there are still prickles to starting a project.  Does everyone know the language?  Are the libraries mature?  Does everyone know the build process?   These questions are far more significant for Kotlin native and other new areas, but these are aspects of a project not feasible in Python anyway.   Be aware that if the temptation of multiplatform tempts the project, then the project has grown beyond what it could be in Python, with a negative impact on delivery.

Summary:

Stay with what you know for project up to one month with one person, try Kotlin from the outset for anything else.  This is a guideline, you could move those goal posts depending on what is availbe at the outset with each language, but creating a rule such as this may help.