Sunday, June 10, 2012
Kotlin - Yet Another Language
What is the point? Yet another language on the JVM which has some syntactical sugar variance from everything else available. What for?
The next real programming language that changes something will do something that cannot be done in current languages. Python has its low barrier of entry and dynamic interpreting. Ruby has its textual flexibility so it is used as a DSL, and really showcased in Rails. Scalla has its static typing, with some flavor of functional programming. Functional programming in general is a different paradigm, and its flagship language is OCaml.
So what is the point of Kotlin? Just a slight twist on the same paradigms. Really not worth it. It didn't even do anything original with checked exceptions - it just got rid of them for the usual flimsy reasons.
The next language that will be significant will enable something that wasn't possible, or wasn't possible elegantly, previously. I suppose there may be space for a language designed so well that it eliminates pain points. Like IDEA used to be for IDEs. In truth, what bothers me most about the language is that it takes away resources from making IDEA truly great again.
Anyway, here are some things I would love to see in a new language:
1. Natural Database access, with static checking. So much business programing is done against the database, but lining those up (especially in the context of refactoring) is a major pain. Even Rails doesn't quite hit the sweet spot.
2. Natural XML access with static checking. When you do a lot of XML programming, it gets very hairy very fast. But the biggest problem is that it is a different language, essentially, with its own types and its own syntax, and you have nothing but string literals to deal with it in your programming language. How about variables that are XML types, loaded from the XSD (or a WSDL directly) by the compiler, and statically checked?
In the HTML world, you kind of have PHP for this, but it has problems, enough to justify a new language.
We spend way to much time either building RAD environments that are inadequate or creating glue code for no reason other than keeping a language general purpose. Solving this problem is what will make the next great language.
Subscribe to:
Posts (Atom)