The comeback of static typing
kishorelive.com
kishorelive.com
Too bad too many people were too poisoned by Java et al to consider switching to one of the good statically typed languages; happily, their recent popularity (like this blog post :)) has gotten people to consider them.
If anything, I'd argue that Java is the main reason for the rebirth of the popularity of static typing.
Java is a C++ without the compiler getting in the way, so it exposed the power of what you can do with a type system (pretty weak one, but one anyway) when syntax is not tripping you every step of the way.
By making static typing popular, Java kickstarted a whole new generation of improved languages such as C#, Scala and Kotlin which leveraged all the good concepts introduced by Java (such as no more separation between headers and implementation) while adding important missing features, such as type inference and traits.
It's not like Sun took a gun to everyone's head and said "use Java, damn it". I mean, Microsoft might try that :-), but Java succeeded almost despite Sun (e.g. on its own merits as a language), instead of because of them.
And really it was Sun's bungling of the language evolution that led to Java's lack luster reputation today. In constract, Microsoft did a very admirable job with evolving C# to keep up with more modern syntax/semantic expectations.
I suggest that Java mostly caught on for two reasons (from a purely technical perspective):
1. It had automatic garbage collection.
2. It had a batteries-included approach to its standard library.
In practice, both of these had caused much pain for C and C++ programmers for a long time, and a platform where things Just Worked was very appealing for a lot of those programmers. That in turn led to non-technical advantages that drove the widespread adoption of Java for server-side/enterprise programming.
I don’t see that either of those technical advantages has much to do with the type system, though. In fact, of all the programming languages and type systems I’ve used, Java’s is probably still the worst by almost any interesting measure.
I don’t really accept the original premise that static typing is making a comeback; it never went anywhere. However, if it’s gaining renewed interest in certain parts of the industry, I suspect that has more to do with increasing experience of where dynamic typing can have disadvantages as more projects using it grow larger and are maintained for longer, and perhaps to some extent with aspirational statically typed languages like Haskell showing that some of the perceived disadvantages of static type systems are not inherent problems.
It is better these days, but even today Java programs tend to have more distribution issues than other languages.
In the olden days, besides the awful Swing GUI that made it immediately recognizable, gray squares and/or stack dumps when trying to execute Java applications or applets were common.
I would love to have a mainstream development stack with the kind of programming tools and expressive power that plenty of modern languages and libraries now offer, but which ultimately produced compiled and statically linked executables the old-fashioned way at least by default, without necessarily relying on package managers or heavyweight virtual machines or run-time linking or writing code just to describe how to install my code. Unfortunately, I doubt that such a language/tool chain exists today, though I’m optimistic that sooner or later someone’s promising niche language will break through.
The thing about Java is that it is really hard to write clever hard to maintain code in it. Sure, it makes it painful to develop with, but because it leads to maintainable code the code never gets thrown out and rewritten and almost by accident very large multi-million line code bases grow over time in it. These huge code bases lead to a lot of jobs for people doing maintenance on them, not because developers like the language, but because the code still works and never becomes impenetrable, as most large code bases often do.
A lot of "dependency injection" BS can also exceed the tolerance threshold of more experienced programmers.
The Go authors are saying that Go is for "systems programming". What they apparently mean by that is server side infrastructure stuff, the kind that is now frequently written in Java. Things like Hadoop, Tomcat or even database systems.
What they don't mean (I believe) is operating systems, device drivers, embedded systems, real time stuff including many trading and telecoms systems, graphics pipelines, signal processing, libraries that are too complex to rewrite in every language (like browser engines), etc. There's a very long tail of these things and it's growing as we get more intelligent connected devices.
Much of that is now written in C++. The question is, will C come back to replace C++? I don't think that's going to happen. I love C. It was my first language and I admire its simplicity. But there is one thing that C++ has over C: RAII. RAII is an ingenious universal resource management tool that gives us 90% of the productivity gains we get from garbage collection without any of the unpredictability, and it helps with resources other than memory as well.
Forget templates and all that fancy stuff. C++s raison d'etre is RAII. So, I think, Rust may have a chance to replace C++ (purely from a technological perspective) but Go unfortunately does not.
Only future will tell.
I have used in the past desktop operating systems (Native Oberon and AOS) without any single line of C++ code, written in GC aware system programming languages (Native Oberon and Active Oberon).
I do like C++ a lot, but I am quite confident that manual memory management will eventually be a sweet memory of old coders.
I don't mean that Go will be that language per se, but that whatever we might use for doing systems programming in future OSs will be GC enabled, even if it allows for some way to do unsafe/system local memory management.
http://blogs.perl.org/users/ovid/2010/08/what-to-know-before...
If you’re at all interested in the real strengths and weaknesses of different kinds of type system but don’t yet have much experience in the field, this is a solid and impressively neutral starting point.
The reason is that dynamic languages are so easy to build--they usually start out as hobbyist projects. Not to overly-trivial it, but these days most anyone can sit down with a compiler book and have an interpreted language up and going quickly.
So dynamic languages evolve quickly--it's easy to try new things, see if they work, see if they don't.
Static languages, on the other hand, are hard to build--you don't often see hobbyist language developers coming up with type systems in their spare time. Type systems are hard.
And the tooling for static languages is hard too--dynamic language users live in emacs/vim/Sublime, but static language users are going to want an Eclipse IDE, refactoring, etc., etc.
So, static languages evolve slower.
But once someone has put the time and effort into a static language, and has the tool chain polished, I assert that most programmers (of course not all) that sprinted ahead to the dynamic languages will find themselves tempted to wander back.
If the syntax is the same (once the static languages catch up), why wouldn't you want static typing, given that, even in dynamic language programs, 95%+ of the calls could be statically verified anyway?
(Admittedly, how you deal with the remaining 5% (reflection, macros, XML, whatever) is left an exercise to the reader.)
Great case in point: Groovy. The original creator, James Strachan, was a hobbyist, and I believe (admittedly putting words in his mouth), if not consciously, built Groovy as a dynamic language because it was easy. But now he prefers Scala, which is basically the same syntax, but with all of the extra infrastructure around typing/tooling/etc.
Then again, I design static-type systems in my spare time, so maybe I'm not the target of your comment :)
James has actually moved on from Scala to helping build statically-compiled language Kotlin!
But the funny thing about IDEs is that the best ones were originally made for dynamic languages (Smalltalk and Lisp Machines) and most IDEs are still lacking when compared to what those environments allowed feature wise.
While many hackers prefer to use 70's style vim/emacs editors.
I think that dynamic typing seems easier at first, but after a while you see how static typing would catch mistakes you make. While one programmer gains the experience necessary to appreciate static typing, a new programmer starts programming and doesn't have that experience yet, thus the static vs dynamic debate is always with us.
I described it here: http://www.databasesandlife.com/the-cycle-of-programming-lan...
this all boils down to skill with tools - cordless drills are amazing ..and so are floor drill presses
C is a bit of the one out here in that its static typing is a really thin veneer as you can cast things to whatever you want them to.
Python and Ruby (in particular these two) more than anything else allowed you to write really terse, expressive code. The canonical Python example of this is defining a tree data structure:
def tree(): return defaultdict(tree)
Java and C++ OTOH were (and are) much more verbose but only some of this has anything to do with static typing.
All of this is one reason I'm incredibly bullish on the future of Go for such reasons as:
- no interfaces. If an object implements the methods expected by a consumer then it compiles otherwise it doesn't;
- incredibly simple OO system;
- no exceptions as such (particularly checked exceptions in the case of Java, which IMHO are just horrible). Some consider this a minus. I tend to think that exceptions tend to get abused for flow control and aren't the panacea they're made out to be;
- simple semantics for function returns and the ability to return multiple items;
- opinionated formatting (I'm not one of those people who has almost religious zeal for the placement of curly braces and indenting so I'd rather just have a standard and stick to it, whatever it is);
- compiles to a binary rather than running on a VM;
- simple grammar with fast compilation. This last point is contrasted particularly well with C++;
- coroutines (or rather goroutines) as a first-class language citizen for solving concurrency problems;
- the "defer" mechanism for resource cleanup. I find this much easier to read than tortured try-finally semantics and nesting.
Another way to put it is this: a lot of vim/emacs users judge IDEs as horrible based on having (often briefly) used Eclipse, which is a bit like judging the car by having once driven a 1975 Trabant.
Don't judge static typing by Java or even C++. Judge it by Go.
[1]: http://rosettacode.org/wiki/N-queens_problem#Python
[2]: http://www.time.com/time/specials/2007/article/0,28804,16585...
To me, this is one the many reasons why Go will fail.
Which Go doesn't play well with.
Why the dependency on Oracle?
There are other many other JVM available, even not certified ones, and you can also use compilers to native code if you wish to do so.
Most languages that usually have a VM, also tend to have native code compilers available, it is just that most HN folks tend to be unaware of them.
If you like being able to write terse, expressive code, you'll love APL,[1] where Conway's Game of Life[2] can be written in one line as:
life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵}
I think a really simple rule of thumb-for-code is "can you dictate it?" through the phone.
My first introduction to functional programming was with J (APL but using ASCII) during my sophomore year of college and I definitely didn't have the chops to understand it at that point. I was scared of functional languages for another year until a different professor introduced me to Haskell.
def tree(): return defaultdict(tree)
Try defining say a RB tree without using builtin container types, and you quickly see how poor these languages' support for new data structures is.
That doesn’t negate dons’ point that if you need something other than those containers there is relatively poor support for defining your own.
In C++ "return std::set<int>" - there's your tree.
Who knows how it would have turned out if UNIX did not became as it turned out to be.
ML was an improvement on most of its successors, and if you trace the development of mainstream languages, you see that they are more and more becoming ML.
Java and C# also have native code compilers available to them.
This statement surprises me.
>>> monomials = [lambda x: x(star)(star)i for i in [1,2,3]] #(not sure how to escape stars for exponentiation properly, whatever)
OK, what will these functions evaluate to at the point 2.0?
>>> monomials[0](2.0), monomials[1](2.0), monomials[2](2.0)
(8.0, 8.0, 8.0)
The i variable was captured as an address which all the lambdas share. For an integer. Ouch.
You can do "lambda x,i=i: x(star)(star)i" and capture the value properly, but to me this is a landmine waiting to be stumbled upon every time I write a lambda. I for one will often forget to do this, at least so long as I also keep using other languages which can capture integers as values without hijinks.
[1]http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closi...
If you want to capture values, that's easy too, with:
lambda x, i=i: ...Haskell was amazing as long as try don't need to do much io. When I started spending more time fighting the constraints than being productive I stopped.
Ocaml was also not bad. But their strict restrictions on what opetators can be used with what types is annoying when you do lots of calculations. Having to explicitly cast numbers all the time was not inviting either.
Rust sounds great, but after a day of playing with it I saw it's really not ready yet. A couple of places needed wrapping in "unsafe" block to start working as expected. Some keywords and ideas were also going to change soon. I couldn't get used to the restrictions coming from not having exceptions or early function returns. It really adds some maintenance code.
Scala was probably the best so far, but the heavy vm is annoying.
So... still waiting for that perfect language.
- inherited null (I love Option<> and Either<> pattern and exceptions, nullable stuff is a problem)
- relying on foreign ecosystem (you end up with half functional, half "we have inherited all this mutable stuff, so let's use it" ugly mixture)
- startup time (if you write things that are script-ish in nature, this is really annoying)
Just compile your code to native using a native code compiler for JVM bytecodes. There are quite a few to chose from.
> Compiles super fast
Because it doesn't do anything. Seriously, it compiles fast because the type system is so trivial. No type inference (except the really restricted (:=) thing. And I can't even have polymorphic functions -- which we've known how to type check for around 40 years now.
This is a serious drawback if you are interested in type system support for code reuse.
VM != runtime system. VM == virtual machine, bytecode.
GHC for example targets the "Spineless, tagless G machine" by compiling to native code that calls runtime services defined by the (abstract) STG machine ISA (the "primops").
Similarly, Go targets the Go runtime, by compiling to native code that calls "machine" services like collecting memory or scheduling threads. It might be a thin wrapper over the underlying processor architecture, but the compiler is clearly targeting the Go runtime as its target "machine".
I'm probably being getting confused about what you mean here, but I thought you can return from anywhere in a function in rust using 'return'. I think Option types are one way to propagate errors back up the stack (with the compiler forcing you to handle them), but I don't know how practical that is in reality.
I agree that Rust isn't ready for production use though, even in the few weeks I've been trying it they have decided to change parts of the language. Also the standard library is lacking in documentation and is pretty inconsistent.
Return will only return from one of them, so to signal an error from the match block, you need to:
- save the result in a mutable variable in a function
- do something that results in "false" returned from each block
- return the result from the function (probably casting mut->immut on the way)
What I'd really like is either a stack unwinding exception, or a `return` keyword that's different from the "last expression in a block" syntax. Last expression could give a result for a closure, match, if, etc. while `return` could always break out of a function. For example (pseudo-code, proper syntax doesn't matter here):
fn parse_into_list(s: &str) -> Option<Stuff> {
let res = do s.map |c| {
match c {
bad_character => return None
...
}
}
Some(Stuff(res))
}
fn parse_into_list(s: &str) -> Option<Stuff> {
let mut result: ...;
let mut correct: true;
do s.each |c| {
match c {
bad_character => {correct = false; false}
good_character => { do_stuff_with_result; true}
}
}
if correct {
Some(Stuff(result))
} else {
None
}
}Have you looked at the new, post-Scala, generation of languages, such as Kotlin? http://blog.jetbrains.com/kotlin/
Well, they never said it was ready. Actually they say the exact opposite: that it's still a moving target. It's 0.5 for a reason. Hopefully around this time next year there will be a 1.0.
You generally shouldn't need to "pull IO through half this module", since you can just lift the large pure part with "fmap" to operate on the inner IO. But using these combinators effectively does take some learning.
The approach to IO that Haskell uses is not "academic", it is extremely practical: By typing effects you get immense practical, not academic, benefits.
Pulling and pushing bytes outside the system is trivial.
Though doing so with any performance, might not be.
Static typing means that the types cannot change. Dynamic languages can still declare types. It's just that they are allowed to morph. A good analyzer can track those changes and know when types are equivalent (TypeScript does this).
Furthermore, typing is one mechanism to express contracts within your code- such as 'this method takes argument X which is of the form Y and will return something which looks like Z'.
More complex analysis requires more and more annotations to specify the contracts of the methods. An example is a C function which takes a char* and an int. You want to annotate that the int indicates the length of the char* buffer, and have a static analyzer enforce that.
I am all about code contracts and enforcement of those contracts. But this is not necessarily tied to a static language.
In static typing context, "types" is a lexical construct of subexpressions. In this context, dynamically typed languages are "untyped" or "unityped" (one type for all expressions).
In dynamic typing context, "types" are the runtime tags of data with rules about dispatch and what kinds of tags are allowed with what operations.
I think for the benefit of communication, we should refer to the static, compile-time annotation on sub-expressions as "types", and the entity dynamic languages calls "types" as "tags".
Your example:
> More complex analysis requires more and more annotations to specify the contracts of the methods. An example is a C function which takes a char* and an int. You want to annotate that the int indicates the length of the char* buffer, and have a static analyzer enforce that
This is of course certainly compatible with types. Something like:
func : (n : Int) -> Ptr (Array n Char) -> ...
Static types and static analysis are basically variants on the same idea. However, static types is part of the ordinary workflow, and static analysis is often treated as an "after-the-fact" feature. This will not work as well, since much of the power of types relates to techniques to structure our programs so that types cover as much as possible.
$id = 1;
$dbh = new PDO($connectionString, $user, $password);
$sql = ' SELECT column';
$sql .= ' FROM table';
$sql .= ' WHERE id = :id';
$stmt = $dbh->prepare($sql);
$stmt->bindParam(':id', $id);
if($stmt->execute()) {
// Do stuff
}
//This echos ID: 1
echo "ID: $id";
if($id === 1) {
echo 'This should be true, we set $id = 1 at the top.';
} else {
echo 'Instead we get here because PDO casually changed our variable into a string and "1" != 1.';
die('in a fire dynamic typing.');
}You're confusing dynamic typing with weak typing. A language can be dynamically typed (types are checked at runtime) without doing things like automatically converting integers to strings, integers and strings to booleans, etc. etc.
Conversely, a language can be statically typed and still do some of those conversions.
My personal one is how fast it compiles, given I was doing the same thing with Modula-2 and Turbo Pascal in the mid-80's.
There is a reason why no one wants to use Java 1.4 anymore.
Go's "static typing" is next to useless.
However, for the user of the library, it simply gets in the way. This may be avoided though if the library has been designed well enough that strange internal types are not exposed to the user unless absolutely necessary.
Essentially, the types are compiler-enforced documentation. They also make discovering functions easier--a type is a succinct summary of what a function does, so I can just browse by types to find what I want quickly. Augment this with great tooling like Hoogle (a type search engine) and you've got a truly awesome development system.