Linked by Thom Holwerda on Tue 4th Sep 2012 20:04 UTC, submitted by MOS6510
General Development "Computer programming is the art, craft and science of writing programs which define how computers operate. This book will teach you how to write computer programs using a programming language designed by Google named Go." Freely available book on Go.
Thread beginning with comment 534099
To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

This complaint can also be addressed to Ada, Modula-3, Delphi, C#, Scala, Lisp, Haskell, ML...

Considering that most of these have either fallen into disuse or been restricted to a niche these days, I am not sure how this large list is supposed to impress me.

Programming is a complex subject and invariably all languages that start as a movement against complex languages, end up getting complex as people realize that the features the designers left out actually exist for a reason.

Please correct me if I'm wrong, but you give me the impression that in your view, programming languages are mostly interchangeable, to the point their features might easily be enumerated in a standard way and compared using giant tables without further information.

It seems to me that to the contrary, if you want to get the most out of a programming language, you need to stop blindly looking for familiar features from other languages which you already know, and instead learn through tutorials the idiomatic constructs that achieve the same goal in your new language. Here are some examples :

-In C/++, arrays and pointers are closely related. To parse an array, most C devs take a pointer to the first element and increment it on every loop iteration with the ++ operator. Many other programming languages, on the other hand, won't have such a basic array implementation because it is a recipe for buffer overflow. Are they worse because they ask you to use either range-based fors or counter variables and square brackets ?

-In C/++, parsing an array is typically done using for loops, complete with some iterator magic if you're using C++'s containers. In MATLAB, interpreter performance is not a priority for devs so for loops are horribly slow, however you have efficient built-ins for matrix manipulation and the idiomatic way to do most repetitive mathematic operations on some set of data is to express them as a matrix operation. Would you use for loops anyways ?

-In C++, if you want a bunch of objects that share some common methods, say Save() and Load(), you make yourself some gigantic class hierarchy and put near the bottom of it some basic class that has Save() and Load() as pure virtual methods. In Go, you create an interface that has methods Save() and Load(), and use it as a generic way to designate any object that has these methods. Is the latter way of doing things somehow worse than the former, in spite of requiring much less design work ?


If you follow this reasoning, you will find that it does not really matter if a given programming language has a specific feature X or Y. Feature parity is useful for beginners, because it means that they can reuse their knowledge from another language right away, but from the point of view of expert users, the only thing that matters is that the language should offer a way to achieve the same results with comparable efficiency. Only the end matters, not the means used to reach it.

The way Go throws out the window two decades of language research made me change from a initial contributor to the language, to a D/Rust fan.

How exactly does Go fail to take into account all these years of language research ? In which way is it more comparable to languages from 20 years ago than more modern languages ?

Reply Parent Score: 2

moondevil Member since:
2005-07-08

"This complaint can also be addressed to Ada, Modula-3, Delphi, C#, Scala, Lisp, Haskell, ML...

Considering that most of these have either fallen into disuse or been restricted to a niche these days, I am not sure how this large list is supposed to impress me.
"

Some of those languages failed in the market due to the way their owners/designers tried to promote them, not because of lack of technical merits.


"Programming is a complex subject and invariably all languages that start as a movement against complex languages, end up getting complex as people realize that the features the designers left out actually exist for a reason.

Please correct me if I'm wrong, but you give me the impression that in your view, programming languages are mostly interchangeable, to the point their features might easily be enumerated in a standard way and compared using giant tables without further information.
"

To a certain extent yes.

In proper software engineering you should learn about algorithms, data structures and ways to organize code (OO, FP, Logical, ...).

Then you need to have a broad set of programming languages background that enables you for a given project, using all requirements as input, to choose the best set of languages/libraries/operating systems to solve the real problem the customer has.

Getting to know every detail of a specific tool leads to useless specialization.

I would rather leave my plumbing repairs to a plumber that knows how to get the job done, than to one that knows every detail of the special wrench XTY.

The way Go throws out the window two decades of language research made me change from a initial contributor to the language, to a D/Rust fan.

How exactly does Go fail to take into account all these years of language research ? In which way is it more comparable to languages from 20 years ago than more modern languages ? [/q]

Actually Go is even worse than that if we take in consideration that languages like Turbo Pascal or Ada are older than 20 years, and already have richer data structures available.

Go lacks:

- exceptions;
- enumerations;
- generic types;
- direct use of OS APIs, without the need of writing wrappers;
- currently only static compilation is available;
- due to static compilation only model, there are issues with 3rd party code;
- no support for meta-programming;
- rich set of available libraries;
- the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages

Go is just a re-branded Limbo (Plan9) with ADT data type exchanged by interfaces.

I bet that if it wasn't being developed at Google, almost no one would care for it. All their Go PR talks is about showing web applications that can be equality easily done in any available mainstream language.

Try to find one that is not about doing REST APIs, or front-ends with Ajax calls.

Anyone with a proper compiler design curriculum in their CS degree can easily find languages/libraries that offer similar features.

Most people at Lambda the Ultimate seem to agree with this, http://lambda-the-ultimate.org/node/4554

Reply Parent Score: 2

satsujinka Member since:
2010-03-11

Lambda the Ultimate seems pretty evenly split to me...

It occurs to me that you miss the entire point of Go. It was never about having all of the features, it was always about choosing features that compliment each other and work well together (while achieving most functionality.) It doesn't matter if other languages provide a feature Go does, what matters is if it's as easy to use (and it usually isn't.)

You'll probably disagree, but static linking is a good thing. There really isn't any benefit to dynamic linking these days (well, there really never was.)

Reply Parent Score: 1

Neolander Member since:
2010-03-08

"Please correct me if I'm wrong, but you give me the impression that in your view, programming languages are mostly interchangeable, to the point their features might easily be enumerated in a standard way and compared using giant tables without further information."

To a certain extent yes.

In proper software engineering you should learn about algorithms, data structures and ways to organize code (OO, FP, Logical, ...).

Then you need to have a broad set of programming languages background that enables you for a given project, using all requirements as input, to choose the best set of languages/libraries/operating systems to solve the real problem the customer has.

Getting to know every detail of a specific tool leads to useless specialization.

I would rather leave my plumbing repairs to a plumber that knows how to get the job done, than to one that knows every detail of the special wrench XTY.

I think that we are each defending extreme sides of what is in reality a compromise there.

I don't think that devs should necessarily know "every detail" about their programming language either, but some level of specialization seems still necessary if you want to make proper use of your specific tool.

In your plumber example, if my plumber had bought one of these fancy keys with a free-wheeling functionality, I would expect him to know how to use it, and not spend a few minutes randomly flinging it around or parsing the manual while trying to find the switch that toggles fastening mode and loosening mode. I agree, however, that he doesn't need to know the specific procedure required to clean and grease it in order to do that job.

Can we agree on that ?

Actually Go is even worse than that if we take in consideration that languages like Turbo Pascal or Ada are older than 20 years, and already have richer data structures available.

Go lacks:

- exceptions;

Wrong (see panic/recover)

- enumerations;

Wrong (see iota)

- generic types;

Although the specific feature is not there, Go provides generics-like features through interfaces. The language FAQ states that they will add some if someone can clearly point out why they are needed and how they are worth the complexity cost : http://golang.org/doc/go_faq.html#generics

- direct use of OS APIs, without the need of writing wrappers;

That's cheating, OS APIs will always look fugly in any language but the one in which these APIs have been written (see Windows API in Delphi back in the day, yuck !)

- currently only static compilation is available;

Same in C/++ to the best of my knowledge, and that never prevented them from being largely successful. Dynamic compilation is only useful in some specific use cases, such as when the code is supposed to run on heterogenous architectures and cannot be easily recompiled after development.

- due to static compilation only model, there are issues with 3rd party code;

Such as ?

- no support for meta-programming;

See comment on generic types above.

- rich set of available libraries;

There's already quite a bit of packages available for such a young language, if you ask me, and the use of a standard package manager makes it easier to deal with third-party libraries than in, say, C.

- the PR about go routines and channels, usually forgets to mention that similar features do exist as libraries for other languages

They exist elsewhere indeed, go simply acknowledges their importance in today's programming landscape and thus propose a standard, well-integrated, less cumbersome way to use them.

It's as if you said that C++ is a garbage-collected language because there are C++ libs that implement garbage collection. Sure, C++ *can* be garbage-collected, but it is not a standard part of the language, students do not learn it, those who learn it as part of their work will often separately use gazillions of different, incompatible libraries... And I guess you see where I'm going from there.

Go is just a re-branded Limbo (Plan9) with ADT data type exchanged by interfaces.

I don't know much about Limbo, but if it was a fine language recycling ideas from it sounds sensible. No need to reinvent the wheel every time.

I bet that if it wasn't being developed at Google, almost no one would care for it. All their Go PR talks is about showing web applications that can be equality easily done in any available mainstream language.

Try to find one that is not about doing REST APIs, or front-ends with Ajax calls.

I am not interested in Google's PR, only in Go as a publicly documented programming language that sounds interesting and happens to have gained a bit of traction, so I won't discuss that part.

Anyone with a proper compiler design curriculum in their CS degree can easily find languages/libraries that offer similar features.

Such as ? (Genuine question)

Most people at Lambda the Ultimate seem to agree with this, http://lambda-the-ultimate.org/node/4554

It seems to me that if you scroll down a bit, the debate is a bit more balanced than you seem to imply.

Edited 2012-09-07 10:56 UTC

Reply Parent Score: 2