Case 3 was sort of a gotcha that I didn’t explain well. In C++, the methods that return iterators, begin() and end(), are overloaded so that they can return both const and non-const versions. If you use auto which do you get? I’m guessing the const version. The issue with auto is it’s “fine” unless the compiler isn’t inferring the type the same way you’re inferring the type. It’s not always so obvious and the code has the risk of looking kind of non-uniform. I’m okay using it in case 3; I don’t think it really smells of abuse as much as some of the other cases.

As for this being out of context:

var myVar = new MyClass().DoThis().DoThat().DoSomethingElse().NowGet();

You have a good point about it being out of context. I can’t think of a great example right now, but I have certainly seen code like in production. Let’s say DoThis() returns an instance of class B, DoThat() returns an instance of class C, DoSomethingElse() returns an instance of D and NowGet() returns an instance of class E.

The problem here is it’s really not obvious that you’re getting an E. Moreso, maybe you weren’t expecting to get an E in this case. You’re not really using the type system to its fullest.

My dislike of the use of var/auto has to do with the fact that you’re working in a strongly-typed language. You’re supposed to get compile errors when you write code that doesn’t meet the assumptions you had. When you use var/auto, you reduce the compiler’s ability to help you in these cases. In some cases, it’s relatively harmless, because the compiler will just bark at a later line. In other cases, it can lead to code with subtle errors.

“Also, I can’t help but point out that inferring the type on the right hand side of the assignment wouldn’t make any sense for a language where classes are reference types, because the compiler would have to guess which constructor out of every subtype of Y you want to call.”

It would have to be a language feature, of course. Inferring on the right-hand side is not unheard of. Java can do it, for example. Here’s one example:

public class Utility
{
public static ArrayList newArrayList()
{
return new ArrayList();
}
}

… to use …

ArrayList arrayList = Utility.newArrayList();

This is kind of the idea I had in mind, except it would have to invoke the constructor on the type rather than just passing it as a generic argument to another, so it’s a slightly different concept, but the idea is similar.

I think you covered Lua and Ruby well. It’s the general downside of interpreted languages with a dynamic type system: errors that could be caught easily by the compiler may not appear until much later, so you need good tests to exercise all code paths. Code coverage is not as critical in a compiled language, but I think it’s almost essential when using an interpreted language with a dynamic type system.

C is tricky to make an argument about: C is actually very simple to start out with, but, the devil is in the details. I would say see C looks deceptively simple, but there are a lot of gotchas, but, not nearly as many as there are with C++.

Good discussion overall. Thanks!

First thing I’d drop a nuke on is Visual Basic. NO. WAY. Steer clear of that.

Lua is a fairly simple language, and it has absolutely no notion of a Goto, which is a start. It also has a fairly reasonable standard library, and you can actually do a lot with it (you can even learn about closures while you’re at it).

Just be careful with Lua, because if you’re going to do, say, object oriented programming (OOP), you need to hack your way around the language. With that said, it’s still very powerful, so it’s a good choice for an embedded scripting language, but I advise you start with another language instead.

Which leaves us with Ruby. Really nice to program with. The syntax is really weird, though… not in the sense of “what does this do”, but “where’s my syntax error” – when I was screwing with Eversion’s Ruby code, it took a while to actually get a syntax error.

However, it’s still a very powerful language – there’s a LOT of standard library available at your fingertips. It’s just not particularly fast, that’s all (it’s slower than Python from what I gather).

Not sure what languages I’d add to the table. C isn’t an easy language as a starting language (heck, I learnt x86-16 assembler before I learnt C). People have managed to survive learning Java, though… I don’t really know. Should I recommend assembler?

Yes, I highly recommend Python, but I forbid that you read the “Learning Python the Hard Way” book, it’s TRULY HORRIBLE… use the official tutorial instead, it at least assumes you know how to add numbers together.

As for ActionScript, I don’t know.

There’s my rant.

The point of auto, as i can see it, is that you are aware of the code’s context – most people writing code can right click a function call and go and look at the signature if they’re not sure of the type. Staring at a piece of code like “var myVar = new MyClass().DoThis().DoThat().DoSomethingElse().NowGet();” out of context is not a real situation faced by a programmer.

Also, I can’t help but point out that inferring the type on the right hand side of the assignment wouldn’t make any sense for a language where classes are reference types, because the compiler would have to guess which constructor out of every subtype of Y you want to call.

Such latency is too much to cope with. We must to find a way to avoid it.

Must we call commit() after executing query SQL? I found an example from http://www.sqlapi.com/Examples/step4.cpp. Are there some problems if we don’t use commit() or rollback() . From the description of commit() or rollback(), seems there are just impact the records changed.