Which programming language to learn?

Status
Not open for further replies.
Necronic

Necronic

Staff member
Except that they can't do it quickly or easily.

High level languages are amazing for their ability to produce code that is easy to read/write and is intrinsically secure (to a point), and to do so very very fast. They show a human/deployment-side efficiency.

Low level languages are amazing for their ability to get down into the guts of what's going on. They require a LOT of expertise to properly write and take a ton of time and effort to do so. They show a hardware/execution-side efficiency.

Saying that C/C++ can do everything a high level language is like saying that my Hinkel knives are superior to a chainsaw. Sure, the chainsaw would mangle a steak, and technically the Hinkel knife could cut down a tree. But is that mean that the Hinkel can do all the same stuff the Chainsaw can?
 
Eriol

Eriol

Necronic said:
Low level languages are amazing for their ability to get down into the guts of what's going on. They require a LOT of expertise to properly write and take a ton of time and effort to do so. They show a hardware/execution-side efficiency.
Click to expand...
And that's the fallacy I run into a lot, even at work. There's an old saying that "An engineer can write FORTRAN in any programming language." And that's what C++ used to be capable of too, and that was best practices even. But it isn't anymore. There's very little intrinsically in the coffee languages that you can't write "like" in C++. Want easier memory management? Declare all your variables with "new" and store them in a shared_ptr<> for everything. Boom, you have "garbage collection" of a sort. You'll never need to call delete again. Care about array out-of-bounds? Use the "at" method of the standard containers so that you catch array-out-of-bounds at runtime (ref here). And that's 90% of the argument for the coffee languages shot to hell right there. Those are the two most common programming mistakes out there for amateurs that the coffee languages will catch at runtime (well, kinda catch, in that they still throw exceptions. You're still just as screwed if you're doing it wrong in either type of language) but C++ wouldn't by default. Now it does if you use it correctly.

What I'm saying is that most of the "justification" for those languages either come from memory management arguments, which disregard the ability to DO these things already, or from "look how rich our standard library is!", which is really just an argument to use the right libraries, and standardize better, but the libraries are there already in C++. It's possible, but I challenge you to find a library that only exists in C# or Java for a reasonably standard task that doesn't exist for C/C++. The C# and Java languages are no "easier to use" than C++, and they don't have many (if any) significant language features that make things easier than C++ either anymore (they used to). You can write well and horribly in all 3 of them. But C++ has advantages the others don't, and the advantages that used to be there for C# and Java are mostly gone now.

Dynamic languages? That's a whole other ball game, and I'd say that they have a bright future, but the coffee languages are rapidly getting edged out at BOTH sides of the equation. They're too rigid to fill the dynamic language role (specifically the not-needing-to-compile part), but not fast and specific enough to be the full-bore systems languages either. I'd say that the CLR and the JVM will survive, but under different languages as their flagships. So you'll be running F# and IronPython/Ruby/etc on the CLR/.NET, and Scala on the JVM, but not C# and Java respectively (at least not as much as today).
 
Covar

Covar

Oh god yes. Power of the pointer makes Arrays far more powerful in C/C++ than other languages. Remember arrays are just pointers to blocks of memory, with some behavior to access them.

Code: 
char* array = malloc(sizeof(char) * 256); // 256 item array of chars, a.k.a. a string
 
char* array2d[256]; // array of pointers, gives you an array of arrays
char** another_array2d; // pointer to pointers is another way of having 2d arrays
The direct access to memory pointers give you is a crazy powerful tool. It's more to worry about, but you get more flexibility. Like an automatic vs a manual transmission.
 
Eriol

Eriol

The way I'd do a jagged array is a vector of vectors, to the N-th deep level of how big I wanted it to be. See below:

Code: 
#include <vector>
using namespace std;  // so I don't need to put "std::" in front of everything.  NEVER use this in header files, but it's usually OK in .cpp files
 
int main(int argc, char** argv)
{
    vector<int> fibon = {0, 1, 1, 2, 3, 5, 8};  // check your compiler to make sure it supports this syntax.  Most do these days
    for(auto x: fibon) // need C++11 for this one  GCC 4.7 or VS11 beta
    {
        cout << x << ", ";
    }
    cout << "done!" << endl;
 
    // Jagged now
    vector<vector<int> > jagged2D;
    vector<int> tmp = {0, 1, 2, 3, 4};
    jagged2D.emplace_back(move(tmp)); // C++11 again, but you can just push_back() the other vector too.  I'm trying to be efficient here with std::move() and emplace_back()
 
    tmp.clear();
    for(int i = 0; i < 10; i++)
    {
        tmp.push_back(i);
    }
    jagged2D.emplace_back(move(tmp));
 
    // Now you have a 2D array with 5 elements in the first row, and 10 in the 2nd.
    cout << "jagged2D[0][4] is: " << jagged2D[0][4] << endl;
    cout << "jagged2D[1][8] is: " << jagged2D[1][8] << endl;
    //cout << "jagged2D[0][8] is: " << jagged2D[0][8] << endl; // Don't do!  No array index checking on the [] operator so undefined behavior.  You may be accessing anything at this point.
    cout << "jagged2D.at(0).at(8) is: " << jagged2D[0][8] << endl; // throws a std::out_of_range exception
 
    return 0;
}
So yes, jagged arrays are no problem in C++, even re-sizable at runtime. Non-jagged n-D arrays are also possible, but the syntax is "funky" but useful when you need screaming efficient access to a lot of elements.
 
fade

fade

Staff member
I am a big C++ proselytizer. I do find that when you mention that C++ is your favorite language, people tend to treat you like you just said Hitler was Jesus. Then they go off on some rehearsed list of things that are wrong with C++, and usually why Java is better. That very attitude is responsible for most of the complaints. C++ ain't Java. Sure, there is no garbage collection. Use the RAII paradigm, and you're golden 99% of the time. Scope isn't something that should only come up at debug time. It's a tool to be used like anything else in your toolbox. This is just an example of the kinds of complaints out there, that lead to stupidity like (most of) the C++ FQA.

I don't really have anything against Java, but you can keep your class proliferation. If you're inheriting the crap out of everything, then it's possible you need to redesign. Use templates and/or policies, for example. I certainly don't think of Stroustrup as holy, but he does have a great FAQ that does a a pretty good job of explaining how to think of C++ as C++. It's not Java, so not everything needs to be a class. I much prefer this over Java because you can restrict classes to things that should be instantiated that have some cohesive invariant that defines the class as what it is. You get structs to use as collection of POD, and namespaces to throw all of your mangled globals into. Also STL. People still use 15 year old invalid arguments against it, which is like arguing that you can't right click on a Mac.

Sorry for the rant. Too much time on stackoverflow lately looking at dumb answers.

---

To answer the OP though, I would suggest something that you could put to immediate use. As PatrThom pointed out, (for all that ranting) it doesn't matter what language you use. They all basically do the same thing in slightly different ways. Remember it's the slight differences that start holy wars. I would suggest staying away from things with wacky syntax like Haskell, though. Here's a breakdown of the languages I think you'd have the easiest time with AND that would translate well to general situations.

  • Matlab: If you have a copy, go for it. You can see immediate results, see the values of variables as the program runs, and with the click of a mouse, you can stop the program anywhere in the middle of its run. The syntax is easy, and it's very close to both C(++) and Fortran. You can be procedural or object oriented. This is my #1 pick for new languages IF you have something to practice on.
  • Javascript: You'll use it, and it's easy. On the other hand it doesn't really get you into thinking of a program as a whole.
  • Python: Free and useful. Good on the resume. Good tutorial on its home website. Poor man's matlab for the most part so the same arguments generally apply
  • C/C++: good next step up. My advice is to pick one at the beginning and stick with it. Don't try to learn both at the same time. If you want to learn both, I think it's easier to go from C to C++. Also best compiler out there is free.
  • Fortran: People love to rag on Fortran, but when it comes to scientific programming, Fortran is still one of the best. It is designed for science, unlike C, and it has a lot of builtin stuff to help you with scientific programming. If you learn it, best to stick to Fortran 90. A lot of tutorials on the web are for Fortran 77 (yes as in 1977), which is still the most widespread. But it's dated.
  • Ruby: Lifehacker has this one as its top pick, but I think the whole "everything is an object" idea might be confusing for newbies.
  • Java: Want a job? This is it. Probably one of the most popular languages right now. Similar to C++ in many ways (I know--I just said C++ isn't Java, but they are very similar in a lot of ways).
These are just my opinions of course.
 
Eriol

Eriol

fade said:
  • Matlab: If you have a copy, go for it. You can see immediate results, see the values of variables as the program runs, and with the click of a mouse, you can stop the program anywhere in the middle of its run. The syntax is easy, and it's very close to both C(++) and Fortran. You can be procedural or object oriented. This is my #1 pick for new languages IF you have something to practice on.
Click to expand...
The biggest problem with learning that one IMO is that you may get into the wrong mindset with arrays. I remember that was my biggest problem with Matlab when I used it in school (Engineering) was that Matlab uses math-style vector/matrix indexes (starts at 1) and every other programming language anywhere uses zero-based indexes (starts at zero) and the number of times I screwed it up because I've been programming a long time was embarrassing. So anybody trying to learn on that language may get into habits there that will screw them over in a big way anywhere else. Given that one-off errors are some of the most common anyway (in any language), starting somebody off in a language that's different than all others seems inadvisable.
 
Status
Not open for further replies.
Top