Comments on: Are dynamic languages just a temporary workaround?

By: Kazimir Majorinc

Kazimir Majorinc — Sat, 28 Nov 2009 08:19:48 +0000

From my point of view – I do not need any kind of debugging help from programming language. I do not need static typing, lexical scope, asserts, contracts … I need only expressive power, and if I’ll need some debugging help, I’ll take care about that.

I understand that other people have other priorities, so it is only an illustration of possible opinion.

By: RogerV

RogerV — Fri, 27 Nov 2009 19:54:08 +0000

Go has the benefit of static type checking and type inference as well for eliminating unnecessary syntactic cruft.

Unlike Perl and Python, or other scripting language solution approaches, it blazingly compiles/links into a single executable for ease of deployment to the end user.

Deploying script languages solutions to end users is just a mess. You have to insure the user has the right runtime version and often times they’ll need certain C libraries to be installed too, and then for complex apps/tools, there may be many script files involved and you have to deliver the app in such a way that none of the package/module references get screwed up at runtime. Or else buy a commercial SDK from ActiveState to roll Perl or Python apps into a single executable (which, doing that with such solutions is still not a simple endeavour).

The shear simplicity of the Go approach (static linking) is a breadth of fresh air relative to the scripting languages. Plus the compile/link process is lightening fast.

The crown jewels of Go, though, tend to be the goroutines and channels approach to concurrency programming. Facilitating robust, scalable, and low boiler plate concurrent programming will be important in programming languages going forward. Go will be stellar in this regard.

Plus the approach to OOP in Go is rather interesting and refreshing too.

Alas, Go is so young that there’s not (to my knowledge) any IDE support that does code completion yet.

By: Cyril Gupta

Cyril Gupta — Fri, 27 Nov 2009 04:38:02 +0000

Pablo, you’ve already noticed that statically typed languages are taking on the characteristics of dynamically typed ones. C# 4 has enough dynamic typing features to make a lot of things possible, and Scala too introduces new synergy between statically typed and dynamic typed languages.

So I guess the right path is the medium path, just as Buddha said.

By: sys

sys — Thu, 26 Nov 2009 21:01:35 +0000

Man, I sure hope so. That’s why I hope Go will catch on and become as ubiquitously available as perl is.

IMHO, loose coupling isn’t always a good thing. I’ll take Ada over Ruby any day of the week.

By: josh

josh — Thu, 26 Nov 2009 16:06:36 +0000

You example for static typing being more verbose is a straw man argument. It doesn’t show how type inference makes things less verbose, and it is also trivially small.

By: dirtside

dirtside — Thu, 26 Nov 2009 15:31:19 +0000

Human beings and “their” toy computers? Are you suggesting someone besides humans is going to be looking back on our programming architectures 100 years from now? ;)

By: GDR!

GDR! — Thu, 26 Nov 2009 14:11:18 +0000

Hueoogle – I can’t agree with you. If you were given C code (C is a static language), you will probably fail as hard as when you are given Javascript. Every C project has its own way of managing memory, usually also its own implementation of data structures and such.

It’s more about programming philosophy – Python’s “there is only one way to do it” makes it easy to read *good* code, even though it’s dynamic.

By: Onne

Onne — Thu, 26 Nov 2009 06:45:15 +0000

Imagine sending a message to a remote server? Can your compiler know how to invoke that routine on the remote server? Can it statically check it? Does the remote server have to be implemented in your language?

No.

So dynamic typing is something akin loose coupling.

By: Hueoogle

Hueoogle — Sat, 31 Oct 2009 09:35:28 +0000

Pablo, I think you are asking a rediculous question. Its not a question of which one is better. Its a question of which one is better for the requirements of the current project. If this means, that I need to purchase widget A from Widgets incorporated, I want it in a static language. Ever try to learn hundred of lines of code of a third party API in a dynamic language? When docs are horible to begin with? My hats off to you if thats what you can do. But static languages have there place when you are learning that third party, which, in a sense, you could even say that ‘JAVA’ IS….. with all of its SUB-API’s, could you imagine all of that being written in a dynamic language and trying to master it? No way. I am saying, statics dominate currently for a reason. Dynamics do certainly have there place. But have you been at a new job, sat down, and been given 10 thousand lines of dynamic written code in javascript that isn’t working properly to fix? GOOD LORD, you just want to get up and leave. Written in Java? or any other strong typed language, you might go home happy your first day!

By: Nes

Nes — Tue, 20 Oct 2009 17:57:56 +0000

It is more of a trade-off. The fundamental problem is that to get good type inference is hard and takes a lot of compiler effort (LOC/size in the compiler). The second is that you can’t properly typecheck 50% of a program with the rest provided in the future as plug-ins. That makes it a bad fit for a small implementation of an embedded scripting type language.

Also type errors in inference based languages like Haskell can sometimes be really hard to understand. And it is frustrating for a programmer to have a compiler error and not knowing how to fix it. Runtime type errors on the other hand are very specific: “this particular thing didn’t work”.