Which programming language?

[ToBeFrank]

an interesting take on the topic...

http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/

I hope you mean by the rather good reply in the comments by Christian Posta. Otherwise, the Intel guy's blog post is a rather sad.

[gregariz]

an interesting take on the topic...

http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/

I hope you mean by the rather good reply in the comments by Christian Posta. Otherwise, the Intel guy's blog post is a rather sad.

The article is not well written but there are a few good points in it, particularly regarding flow. I guess I have always been a bit sceptical of OO as everyone seems to have a different take on what it actually is. There's a fuzziness about its very essence, and alot of academic hubris going on. Polymorphism, Inheritance etc are central concepts but I've always been around projects that are not so complicated as they were difficult. For me, when I see good procedural programming, I would argue that in a way these procedures themselves evolve into 'objects'. Is this OO? depends who you talk to. When I hear programmers who have grown up with OO only, and to be honest these days it seems to me most of them, it scares the crap out of me.. because I know I'm in for trouble. In most projects I know I can get a result from good procedural programming. I don't know that for OO.

[Semantics]

OO has it's place and it's certainly not everywhere. It's a tool, and like any tool is can be completely misused. Do you need it to write complicated stuff? Well, define complicated. Writing hardware driver software is complicated but my first instinct would be to not consider OO for that problem. And I've personally seen solutions developed in C# that were a complete disaster resulting from what I will euphemistically call "over-zealous application of indirection". And, while OO concepts are well defined, the application of them aren't. For example, I don't buy into the Gang of Four & all their application patterns, but some of them are pretty useful, if not just to remember. The nice part is that nothing exists in a vacuum.

You first understand the problem and then select your tools. Letting the language embed itself in your requirements without a compelling reason is a mistake. All the smack-talk about certain paradigms seem to center around specific misapplications. As if my stepping into a puddle is clearly the fault of the manufacturer of my shoe!

Or you could just grab an opcode list and get to work hand compiling. But I wouldn't expect my shoe manufacturer to make my shoe atom by atom. 

[sacherjj]

Or you could just grab an opcode list and get to work hand compiling. But I wouldn't expect my shoe manufacturer to make my shoe atom by atom. 

Of course not.  That is silly.  There is no reason to get below the molecule level.  Nobody works with just atoms any more.

[alm]

You mean like C, which I've spent many years with? The best C code is structured in an OO-way where you use file scope (static) for encapsulation. This makes it maintainable, reusable, and less error prone. This isn't OO, but it's using OO concepts. A file essentially is an OO "class".

I was thinking more like scheme, ML, Haskell or something completely different.

Reread my statement. I didn't say OO. I said "OO concepts".

If OO is not a useful tool in a certain case, the same applies to OO concepts. They are certainly useful, but not the right tool for every job.

Yep, I had a semester of scheme. You get really good at recursion.

I think good knowledge of recursion (something that languages like C and Java don't encourage as much) is also mandatory to be a good programmer, just like OO. The solutions to some problems is much more elegant in a recursive algorithm than iterative. Even if you end up implementing it in an iterative fashion because the recursion implementation in your current programming language doesn't support tail recursion. Trying to solve every program with recursion is just as bad as solving everything with OO, however.

It certainly is not, but I most definitely would not want to work with the code of the person who didn't understand it and use its concepts in non-OO code and/or OO code.

Not suggesting that it's not important for people to understand it, just like a carpenter should probably be familiar with a hammer. Doesn't mean I want the carpenter to apply it to every problem.

You've made the assumption that's all I know, which is incorrect. Guess what, I also work with Python almost every day. Golly gee whiz, I'm one of those multi-language guys.

Sorry for the bad assumption. An important feature in Python is list comprehensions (and related things like generator expressions). I would not consider these OO, familiarity with functional languages like Haskell is very useful for this.

It's funny you ask that because that is exactly the code I work with everyday. I put the algorithms our math and physics PHDs come up with on big clusters. The answer is... "very".

Is encapsulation really worth the performance hit in that case? Scientific data tends to be fairly homogenous, so I don't see a major advantage to polymorphism.

[ToBeFrank]

Is encapsulation really worth the performance hit in that case?

If you think there's a performance hit by using encapsulation (there's not), and thus don't use it on code that runs parallel on thousands of cores, you're in for a serious world of hurt should you ever need to debug that code.

[IanB]

My ultimate aim is to be able to cobble together some PC software with gui that can send commands to or recieve
data from the microcontroller via either rs232 or usb.

OK, ignoring the language wars and philosophical debates that filled this thread, there are two important keywords: PC and GUI. I think your sensible choice is to use Visual Studio (get the express editions for free) and C#. GUI programming on Windows is no picnic, and the .NET/C#/Visual Studio environment is the most accessible path for someone new to the scene. Yes, you could try Java, but then you would have to get and learn an IDE like Eclipse, and no way would I recommend Eclipse to beginners. Forget C or C++ for this, they don't (natively) do GUI.

On the philosophical side of things, programming is programming; if you are an engineer you can apply engineering skills to programming in any language to hand. Don't get hung up on languages and IDE's--learn how to program in a general sense and let the world be your oyster.

[ThePranksta]

Assuming you are EE student you most probably are only going to use C and C++ when working with MCU's. I use C 99% of the time.

I would recommend going with C, no ide, just a good programmer editor (I used Kate and Vim on my linux machine and Zues on my windows machine) and a makefile.

If you've got all the basics then move on to C++; I would also recommend some literature on design patterns.  If you go into embedded programming definitely get a book on the general workings  of processors and do some assembler, decompiling and reading the assembler code is a very valuable tool to have.

If you want to later master an IDE I would recommend Eclipse since it is used a lot and a number of the chip manufactures base their IDE on Eclipse.

And as IanB mentioned getting the general programming and design skills down is the most important; consider some books on the workings of compilers it will make things clear on when A is better than B.

[ChrisKiwi]

We used Microsoft C++ at Auckland University of Technology.  The differences between C++ and C# are not that great but it seems harder (so I am told) to move from C# to C++ then it is to move from C++ to C#.  If you are a student it is possible to download full "professional" ISO's from Microsoft as part of their "Dreamspark" program.  The best idea is to use the same software that you would be using at your university if possible, that way you can get a lot more support from staff.

[bruce273]

visual c# or basic on a pc are really easy to use for rs232 stuff when you use .NET. Python is also quite nice for programming for serial ports as well.

[JuKu]

For language: In embedded world, C. Scroll down, far, to see C++. C++ has its use, but its use is much rarer in embedded applications. Any other language, and you've painted yourself in corner - an obscure language that is usable with only one processor family, one tool and one tool provider. An OS is not a language, strictly speaking, although it adds many concepts, words and expressions. Learn embedded Linux and an RTOS, and learn those good. It doesn't really matter which Linux version or what RTOS as again, it is the concepts that matter.

It does make much sense to learn the ideas of object oriented programming, as well other programming techniques. The ideas, concepts and good writing skills matter much more than the implementation tools. As my professor used to say: "You can write object oriented AI software in assembler; you can also write hairy assembler in Ada." (Ada is/was the most structurally sound language at the time.)

What is the point of the no IDE recommendations? As I see it, I graduated almost 30 years ago, and even for me, makefiles and assembler are something that I can read and I can also write them if I have to, but those are definitely low level stuff that we have tools for. If I would be hiring and the applicant says he choose not to use an IDE, it would tell me that the person likes to do things the hard way, does not care about efficiency, quality or productivity and is not, and does not want to be, up-to-date technically. I can also cut a tree with a pocket knife if I have to, and you can argue I would learn a lot of the internal structure of a tree while doing that. I still prefer my chainsaw for that job.

[baljemmett]

What is the point of the no IDE recommendations? As I see it, I graduated almost 30 years ago, and even for me, makefiles and assembler are something that I can read and I can also write them if I have to, but those are definitely low level stuff that we have tools for.

(I haven't read back through this thread, which had lain dormant for a while, so I'm basing this on what I remember of the discussion originally, but...) I believe that recommendation was more to learn a language instead of just learning an IDE.  So by all means learn an IDE or two, once you've got the language worked out; even whilst you're learning the language.  But if you can't work with the language outside the IDE, you don't know the language -- see, for instance, the sort of programmer who thinks the only way to define a class in C++ is to click Insert and then New Class..., type in a name and then maybe select a base class from the drop-down list, then use the wizards to add members and -- argh.  Trying to work with code written by someone with that level of 'understanding' of the language is pretty unpleasant, as I'm sure many of us know from bitter experience!

[JuKu]

@baljemmett: Ok, very valid point, especially if talking about programming on Windows or Qt and such. You can indeed put together a nice, fancy, relatively big Windows application in Visual C# with just a hint of actual programming know-how.

[Psi]

The point about IDE's that i was trying to make a few pages back was that an IDE is something you "interface with" where as a language is something you "learn".

Once you learn a language that's pretty much it, you know the language (excluding maybe a few advanced features you might pickup later).
With an IDE your using it all the time.

So it's very important that the IDE is designed well.


Take the AVRStudio IDE for example, it doesn't let you change the entire color scheme to be light text on dark background.
Sure, you can change some of the windows, but others are fixed with a white background.
It's really annoying if you're the kind of person who finds it hard to concentrate when staring at an entire screen of white.
NOTE: The new version may have fixed that.