34 replies to this topic

[poita]

http://golang.org/

Language summarized:

- Type-safe, but no generic programming (because that made early Java and C# soooo much fun to code in)

- Similar syntax to C++/Java/C#, but just different enough to confuse you. e.g. flow statements are the same, but without the parentheses.

- Maps are built in, but you cannot use structs or arrays as keys...

- ++ and -- are NOT expressions. So you can't write i = j++;

- No pointer arithmetic (but this is meant to be a systems programming language....)


In other words it's just another failed language that has somehow managed to learn absolutely nothing from other languages. I really thought Google were better than this.

[v71]

Do we really need another language , i mean , why don't they improve c++ adding libraries to handle web programming and other sort of stuff ?
I agree that we never stop to learn, but why change the syntax ?
With c++ plus libraries you can do almost anything that java can, i recently came across the c++ web toolkit this library gives you functions much like java to handle web development.
Now let's go on with the flame war
Ah no, wait , this is not gamedev

[poita]

We do need new programming languages. C++ is fundamentally broken with its horrible syntax, especially with templates. D is a step in the right direction, but I don't know what this Go is supposed to be. It really is just a stereotypical "hey look, I wrote a language too!" They haven't added or improved anything -- they've just mixed and matched features from other language with little rhyme or reason.

And yeah, I guess this isn't gamedev, but this place is hardly bustling with activity at the moment, so a little discussion can't hurt. If a mod feels this would be better in Off Topic then feel free to move it.

[Mihail121]

poita said:

We do need new programming languages. C++ is fundamentally broken with its horrible syntax, especially with templates. D is a step in the right direction...

Big 'YES". C++ is indeed broken, although it's powerful if YOU know what YOU are doing. C++ is strictly forbidden where I work except for the case you've wrote a portable library, verified and validated that compiles with any compiler so no one will ever have to look at the source. D... oh God, where do I start, it has a nice concept, smooth learning curve, it is compiled, but if you start comparing the productivity against C#, Java etc. it quickly comes out of the picture.

Quote

, but I don't know what this Go is supposed to be. It really is just a stereotypical "hey look, I wrote a language too!" They haven't added or improved anything -- they've just mixed and matched features from other language with little rhyme or reason.

No, it's not, Google does have a clear idea of what the language is supposed to do. Well, they claim stuff, but the language is in my eyes far from giving them so easily, as site claims. Good concurrency support? There is already a language for that and it's name is Erlang. Compare Go to Erlang, please, and tell me what's different?

[StudioFortress]

Mihail121 said:

No, it's not, Google does have a clear idea of what the language is supposed to do. Well, they claim stuff, but the language is in my eyes far from giving them so easily, as site claims. Good concurrency support? There is already a language for that and it's name is Erlang. Compare Go to Erlang, please, and tell me what's different?

This is more of a dynamic vs static reason, but I would love to have full static typing support in Erlang. I often have bugs in my code where some process has passed the wrong value to another process, who then crashes some time later. It's this delay which is the issue as it makes debugging the code more difficult.

Static type checking would find most of my bugs for me and at the point where they occur. Once found these are typically just a 1 line fix.

I personally find Erlang to be quite slow and it also doesn't have any proper tool support. There are editor plugins for Eclipse and NetBeans and a bunch of different tools you can run but there is no do-all Erlang IDE. Most of the tools available are usually buggy, badly supported or both. It's not in the same league as say the tools for C#, Java, C++, etc. If Google build some good tools for Go then I'd be happy to switch.

[alphadog]

Is it a Pythonic C++, or did they jam C++ into Python?

There's a lot of experimentation going on with getting the right mix of various factors into a language that does concurrency well and with ease. Expect lots of languages to resurface (Erlang), and others to come and go (Go, Axum, etc.).

Yes, it may fail and there will be many more. Nothing wrong with it. The churn is inevitable with the void being created by the umpteen-core systems coming into the hands of all kinds of users.

The key is to not be a fool and invest too much time in any language that doesn't have a full tool chain and a big community behind it...

[fireside]

Ars Technica did an article on it also:
http://arstechnica.c...from-google.ars

I'd like to see some compiled language take off like this, nearly as fast as c with built in garbage collection, but dropping OO was a mistake in my mind. They say there are some work arounds but no sub-classing. I don't know if it was for speed or what, but that would put a damper on design usability. I'm not sure I could even write a program that wasn't OO anymore.

[v71]

So which features would you like in your ideal langauge ?

[poita]

fireside said:

Ars Technica did an article on it also:
http://arstechnica.c...from-google.ars

I'd like to see some compiled language take off like this, nearly as fast as c with built in garbage collection, but dropping OO was a mistake in my mind. They say there are some work arounds but no sub-classing. I don't know if it was for speed or what, but that would put a damper on design usability. I'm not sure I could even write a program that wasn't OO anymore.

While I obviously dislike the language, I think dropping type hierarchies was a good idea.

They are absolutely right when they say that programmers spend too much time thinking about the correct tree structure to use, and the reason is simply because you cannot organize the world into a tree. The relationships between real-world concepts do not fit into a trees topology. Category theorists would be laughing their heads off if they knew what programming language designers had been doing for the past 20 years.

[fireside]

Quote

Category theorists would be laughing their heads off if they knew what programming language designers had been doing for the past 20 years.

I find it useful and I think most people do, that's why it's so popular. It's like arguing that shoes are useless or something. Everyone already wears shoes and they know they are useful. A theorist isn't really necessary anymore because it's used in practice in countless large programs. I use very few interfaces and that's what they say is a replacement. Extending base classes is an excellent way of designing and enlarging programs.

[poita]

fireside said:

I find it useful and I think most people do, that's why it's so popular. It's like arguing that shoes are useless or something. Everyone already wears shoes and they know they are useful. A theorist isn't really necessary anymore because it's used in practice in countless large programs. I use very few interfaces and that's what they say is a replacement. Extending base classes is an excellent way of designing and enlarging programs.

Most people find it useful because it IS useful, but only in a very limited capacity.

Try to write a large program using type hierarchies and you'll see how problematic they are. Concepts simply do not fit a tree structure.

[alphadog]

fireside said:

dropping OO was a mistake in my mind

The issue is that OO and concurrent are orthogonal concepts. Many times, objects represent things or states that use/depend on/implement threading and other similar concurrent ideas.

To combine them is to increase the complexity of that language. That's why you find most concurrent languages do not follow an OO paradigm. Some do, but most steer clear.

poita said:

the reason is simply because you cannot organize the world into a tree.

While I do think that many developers see too much of the "Shape-Circle-Square" approach to architecting in an OO setting, it's a stretch to sya that we should drop that as a tool available to developers. To use an analogy, if a carpenter relies on the hammer too much, you don't take away the hammer, you make sure the worker knows about the power nailer, and the other tools and when to apply them.

[poita]

v71 said:

So which features would you like in your ideal langauge ?

I haven't decided yet. It's something that I discuss with myself on a daily basis.

But here are some minimum requirements:

1. Don't force anything onto the programmer (e.g. mandatory GC)

2. Wherever possible, any language feature should be part of its libraries rather than being hard-coded into the compilers.

3. Languages features should be axiomatic, by which I mean, if a feature can be constructued from other features, then it should not be a feature of the language. For example, for-loops should not be a built in construct as they can be built up from an if-statement and a goto. I imagine my ideal language would define a for loop as something like:

for (init; cond; iter) {block} :=

init;

start:

if (!cond) goto end;

block;

iter;

goto start;

end:

Obviously the syntax there is missing a lot of information and there's no way I'd actually advocate that syntax. I'm just demonstrating the fact that it could have been defined in terms of more axiomatic language features. Of course you need extra code there to handle breaks and continues, but that's easy.

4. Your code should have as much access to compiler information at compile time as possible. Compile time reflection is really important.


One thing that I'm currently mulling over is whether or not types are axiomatic. In one sense, types are just a set of requirements on the layout and semantics of the data that is passed around a program.

What I'm wondering is whether or not you could construct a language were the type system is part of the standard library rather than being hard-wired into the compiler.

Some languages have preconditions for their functions, for example:

float sqrt(float x)

precondition (x >= 0)

{ ... }

could it not be the case that the type is just a precondition, too?

float sqrt(x)

precondition(typeof(x) == float && x >= 0)

{ ... }

Of course, writing it in the second form would be tedious, so the first syntax could be provided as short-hand.

That's just a few things. I could go on forever, but that's what's currently running round in my mind.

[SamuraiCrow]

poita said:

3. Languages features should be axiomatic, by which I mean, if a feature can be constructued from other features, then it should not be a feature of the language. For example, for-loops should not be a built in construct as they can be built up from an if-statement and a goto. I imagine my ideal language would define a for loop as something like:

for (init; cond; iter) {block} :=
init;
start:
if (!cond) goto end;
block;
iter;
goto start;
end:

Obviously the syntax there is missing a lot of information and there's no way I'd actually advocate that syntax. I'm just demonstrating the fact that it could have been defined in terms of more axiomatic language features. Of course you need extra code there to handle breaks and continues, but that's easy.

Your language has an extra goto inside the loop. It should be:

for (init; cond; iter) {block} :=
init;
goto start;
continue:
block;
iter;
start:
if (cond) goto continue;
end:

Note that the end label is only called by a break statement implemented as:

goto end;

poita said:

4. Your code should have as much access to compiler information at compile time as possible. Compile time reflection is really important.


One thing that I'm currently mulling over is whether or not types are axiomatic. In one sense, types are just a set of requirements on the layout and semantics of the data that is passed around a program.

What I'm wondering is whether or not you could construct a language were the type system is part of the standard library rather than being hard-wired into the compiler.

I'm tinkering with the idea of an extensible programming language also. I'm having fun with a PEG parser generator and that will probably be the basis for my work. But for now, I'm going to translate code into LLVM Assembly language.

This is getting off topic and should probably be its own thread but what do you want in your language, poita? BTW, you should try LLVM Assembly. There are a few preconditions to running it through the optimizer but it would have caught that loop inefficiency earlier.

[poita]

Quote

Your language has an extra goto inside the loop. It should be:

Hmm? I don't see how that will do any less jumps.

Quote

This is getting off topic and should probably be its own thread but what do you want in your language, poita? BTW, you should try LLVM Assembly. There are a few preconditions to running it through the optimizer but it would have caught that loop inefficiency earlier.

I'm not sure what I want yet. Those things I listed are the minimum requirements.

I've been trying to think of ways to organize and parameterize code, but I'm struggling to find something that will consistently produce optimal code.

One particular problem that has stumped me is with list splicing.

As I'm sure many programmers know, splicing a linked list is a constant time operation if you don't need to keep track of the size. If you do need to keep track then it becomes O(n).

But here's the thing: it's only O(n) because you don't know how many list elements you're removing. If you knew how many elements you were removing then you could write a splice function that accepted the number of elements removed as an additional parameter to do the splice in O(1) time.

The funny thing is: you *could* always know how many items you removed. List splicing requires that you have iterators for the positions that you want to splice, and the only way to get iterators from a list is to linearly traverse them. So, some time prior to the splice, you have traversed the list to get the splice position iterators -- you just haven't kept count of how many elements you've traversed. If you did, then the splice could continue in O(1).

But how would you deal with this? You could have retrieved the iterators using std::find. Should std::find also return a count of the number of elements traversed? Is that all it should return?

The STL algorithm functions are very good at returning useful information, and in Alexander Stapanov's book, Elements of Programming he recommends that a function should return all useful information that it has computed in the process of its execution.

But how much useful information should you return? Should std::find also return a set of objects that it passed on the way? There are certainly scenarios where that information would be useful, but of course it would not be useful in the vast majority of cases.

Let's just say you parameterize your functions so heavily that you could pick and choose what was calculated along the way. What about higher level functions that were composed of several of these highly parameterized functions? The number of parameters for that higher level function will grow exponentially.

As far as I'm aware, there are only a few options you have:

1. Stop caring about linear optimizations and just accept that you can't write optimal programs in a top-down fashion.

2. Make the language declarative, so that you don't actually write these functions, but instead write what you want them to accomplish and the compiler figures out the best way to implement them.

3. Something else.

So that's currently where I'm at, and I'm undecided about what to do. Reductionism or holism?

[Mihail121]

Look, poita, I generally agree on everything you've said, but you, I and A. Stapanov will leave this world unchanged as proposing ultimate solutions like 'world does not fit into a tree -- do not use OOP' will make people wonder why not to when it has proven to work very well in practice. Can you suggest a method that allows simple design for complex relations and processes? Can you suggest how to reimplement Microsoft Office 2007 for example with another concept such that the development wont take years? There is the concept of complexity in the world, for example the Kolmogorov complexity. I need to invest an effort, and it has a certain lower bound, to achieve something. OOP helps us reduce the source code complexity towards the lower bound AND get a meaningful (for us) model of it. I see you want innovation, I see you have plans and ideas and so do I, but what do people want? Completely parameterized functions returning all potentially usefu information along the way? Yeah, right... In our engineer mind it's a nice and useful idea, we know what's going on, we know what we want and how it should be, but the 16 year old that SAP just hired and teached .NET does not care, is not aware of the situation, he's happy to inherit the Dictionary class and customize it, because it works! That's how reality is and it has always been like that. Think about something else, according to research humanity is ready to accept the fact that at least 100 people die in car accidents every week. It's ready to accept two planes crash every year. Of course we can make things better, but nobody wants to, they are still considered high-technology and enough to keep people happy. People need concurrency? They use Go.

[poita]

Mihail121 said:

Look, poita, I generally agree on everything you've said, but you, I and A. Stapanov will leave this world unchanged as proposing ultimate solutions like 'world does not fit into a tree -- do not use OOP' will make people wonder why not to when it has proven to work very well in practice.

Well first off, Stepanov already has changed the way programming works by co-inventing generic programming and developing the concept of iterators.

Second, if OOP works so well in practice then why has Go removed it? Why is C still such a popular language?

And where is your evidence that OOP is working "very well" in practice? It is used in practice, yes, but that doesn't mean that it is working, or that it cannot be improved. Sure, programs are being written in the OOP style, but who's to say that they couldn't have been written twice as quickly or perform twice as well using some other method?

Quote

Can you suggest a method that allows simple design for complex relations and processes? Can you suggest how to reimplement Microsoft Office 2007 for example with another concept such that the development wont take years?

Not yet, but I'm working on it, and I like to think that I'm getting somewhere.

Quote

OOP helps us reduce the source code complexity towards the lower bound AND get a meaningful (for us) model of it.

Prove it, or at least show some justification for the claim. I've only found OOP useful when I need run time polymorphism, which is fairly rare.

Quote

I see you want innovation, I see you have plans and ideas and so do I, but what do people want? Completely parameterized functions returning all potentially usefu information along the way? Yeah, right...

No? Might want to read my last post again. The idea of completely parameterizing every function is absurd to me.

Quote

In our engineer mind it's a nice and useful idea, we know what's going on, we know what we want and how it should be, but the 16 year old that SAP just hired and teached .NET does not care, is not aware of the situation, he's happy to inherit the Dictionary class and customize it, because it works!

20 years ago people just wrote min and max functions for floats, ints, doubles and whatever type they needed, and it worked! Does that mean that templates haven't helped? No.

Again, just because we can get by with the status quo doesn't mean that it cannot be improved, and it doesn't mean that the status quo cannot change.

Quote

Of course we can make things better, but nobody wants to, they are still considered high-technology and enough to keep people happy.

Umm, what? Everything continually changes and improves. I'm not sure what you're trying to say here.

[SyntaxError]

All I can say is it isn't for me because I don't want to be forced to use a GC all the time. Also even though C++ isn't perfect, it has the features I like so until something better (as defined by me) starts to take hold, I'm going to stick with it.

[fireside]

I think what's happened is that people use c or c++ for speed/low level libraries and managed languages as a layer above that. It would be hard to imagine something really changing that because there's so much c code out there. Go may or may not end up being a specialized language, but that's all it will be. I wish they would clean up c++ and make it more consistent but even that would be hard to do now. With it's concurrency or whatever, Go is still "almost as fast as c". Where is the advantage?

[alphadog]

I love it. In the past, lots of programmers complained about memory management.

Along came languages that solved this boilerplate-ish type of coding and "liberated" the developer.

So what happens?

Developers now bitch about being "forced" to use GC.

Funny how that works out, huh?