Which programming paradigm to choose for college kids?

[NapDynamite]

Hi,

Though not designed to throw such questions overhere but I guess it will help me best. I teach programming to Electrical and Mechatronics Engineering students where they learn to interface real-world stuff with software. My senior faculty always push me to teach them assembly and C and actually, which is harsh, discourage the use of graphical programming like LabVIEW merely because of the reason that, and I quote,"is too easy".

I have supported LabVIEW throughout my career. From grad to the middle of postgrad and all of my projects were based on LabVIEW and NI's hardware. In my point of view, giving students a basic idea of "programming" is enough. And then switch to that paradigm which takes less development time and more learning outcomes. The reason I support is that Electrical and Mechatronics Engineers differ from Software ones. It may be crucial for Software guys to master C or assembly but for mechatronics and electrical guys, creating a system full of sensors and actuators and a processing part designed in some language which takes less time to develop and has more learning in it. But still LabVIEW isn't much supported in my department. May be because the authority has some emotional attachments with text-based programming.

What do you guys think should the percentage of every programming paradigm for students of such technology? Keep in mind that my course does not empahsize of "programming" but creating systems using software based control and "brains". 


Regards.

[crossrulz]

I remember my Embedded coarse.  The programs were not exactly hard to write, but took a lot of time.  We had to write it in assembly in order to program a microcontroller.  But the part that the professor really wanted to emphasise the hardware interfacing.  This usually just involved simple digital buffer circuits and then interface to the LCD, stepper motor, or whatever other hardware we were trying to control.  I now look at the myRIO and think how stupid easy that coarse would be.

Here's the thing for me: a class is to teach principles.  You still need to follow programming priciples in LabVIEW.  You still need to figure out how to interface the hardware to whatever.  Those are the important things.  So who cares what language you wrote your programs in!

[NapDynamite]

"Best reply ever". 

The best analogy I can give to my superiors is that in this era of high performance cutting edge integrated circuits, you need to teach students "what's in and what's hip" in science and engineering of ICs; CMOS, MOSFETS. But if you are still stuck in spending first quarter of game trying to make students realize vaccuum tubes, you sure are going to lose the game. 

Same goes with the prgramming. Teach one how to deliver a message. the choice of language is purely one's discretion. 

[johnsold]

Quite a few years ago I was involved in teaching beginning Circuits courses and the labs to EE students. We started with opamps and later moved to discrete transistors. Why? Because op amps are so nearly ideal (at the level of first circuits courses) that concepts like gain and feedback were easily demonstrated without needing to worry about biasing, impedance levels, and so on. Compare the difficulty of designing a simple AC coupled gain-of-ten amplifier with an op amp to the same design with a BJT.

The students can design, build, and test three variations of the op amp circuit in the time it takes them to design for the transistor operating point in a suitable region.

The first programming course I took (long before LV) required the students to draw and submit flow charts before writing any code. Teach them to design the programs first. Implementation of the code is secondary.  For good teaching it is important that the students have success. Syntax errors and hard to debug code do not help that. Precisely because LV is "easy," especially when working from a good set of design documents, it is a better learning tool.

Just as is it much easier to teach digital design to an "analog" engineer than to teach analog design to a "digital" engineer, teaching assembly language to a competent LV programmer may be easier than breaking all the text-based code habits of a C or assembly language programmer when learning LV.

Lynn

[nyc_(is_out_of_here)]

I use other languages other than LabVIEW, so I am not as much as rah-rah supporter of LabVIEW as you seem to be.

The most important thing for a student to be able to do is think logically.

The language is irrelevant.

I had a very smart colleague who was a terrific programmer. He started out as a photographer.

Personally, I like the Arduino Uno. "Free" software. Lots of hardware to interface to.

[ToeCutter]

I would not suggest LabVIEW, because it's proprietary and it's quite a niche language, plus it is very expensive for non-educational use.

There's no need to go to the level of assembly these days. however I think C is still actually a pretty solid option.

If it fits the bill on the hardware side, I agree the uno is a decent idea, and that again is pretty much programmed in C.

[Jacobson-ni]

As a recent graduate, I think it would be best to teach them whatever they are most likely going to use in industry.  Some of the most helpful classes I took had professors that regularly talked to engineers in industry and recruiters to see what skills they valued and were in demand.

As a mechanical engineer this wasn't a big issue but it was incredibly frustrating having to tell every potential employers that I had not used AutoCAD or Solidworks because our school used and taught NX.  It's nice to be able to talk with a potential employer and tell them how you have used the same software they are using for projects in your classes.  

On the other hand, if your department mostly teaches one language it can be very nice to expose your students to other languages.  For LabVIEW in particular some potential employers did seem interested in the fact that I was CLAD certified because it was something that they used but didn't see a lot of students using.  I will tell you that the same people were not nearly as interested in my Fortran77 knowledge (it did lead to some fun conversations though).

[NapDynamite]

I use Arduino bundles and ATMEL studio to employ C/C++ to interface hardwares (after being rejected to use labVIEW). The reason why I am a supporter of LabVIEW is not educational but industrial. In real life industrial applications, which students will eventually be exposed to, time is a big invesment which big guys don't have. And he less time it takes to develop a system, the better it is. 

The same concept of "fast delivery" I tend to support in programming in academics. I don't despise text-based programming, and it's true that if students are well trained on how to grab a hold of design on system/block/flow chart level, I guess anyone can design anything in any language. 

[Stuart.Parkinson]

I would suggest covering a range of languages (so students are familiar with the different choices available to them) but weighting the emphasis in favour of what is most used and desired in the industry to which they are targeted. I have no actual figures but I strongly suspect that probably 80%+ of software which is required to interface to hardware is written in a C type language (ie. C++, C#, Java, etc) with a little assembler. LabView is a wonderful language, excellent for education because of its visual implementation, but very much a niche one.

There are many many computer/microprocessor controlled machines, (washing machines, CNC lathes, robots, trains, planes, and automobiles) and NONE of them run on labview. Much of their test equipment runs on LV and some of the process controll equipment used in their manufacture, but I would suggest that the majority of mechatronics skills required by industry are text based.

Thats not to say LV is not a very valuable learning platform - it is. Particularly because of the ease of knocking up a program and SEEING the results in real time in charts and dials and volts and revs very quickly and easily. That makes it great to experiment with and probably much faster to learn mechatronic principles with. But don't forget that 80% of your students will end up using text and you will help them in their job interviews if they are well versed in those skills more than LV.

[Sam_Sharp]

I think that one of the great things about LabVIEW is that it is so easy to 'get started' - within a few hours of playing around and/or following some simple tutorials you can create some pretty powerful applications that can interface with hardware, analyse data and display it. To do the same in other languages would require a significant investment in not only knowing the basic constructs/syntax of the language that you're using but also how to use that to implement the functionality you require.

The student edition of LabVIEW is free (for students) and there is quite a lot of hardware available that students can interface with (e.g. myDAQ, myRIO and even things like arduinos). This makes it pretty well suited towards group/individual projects.

I think in any sort of science/engineering field, there would be no harm in having a basic LabVIEW course included as part of the curriculum as not only does it lead to potentially a job in LabVIEW programming, but also useful for research/test/measurement jobs.

You should also check out the NI Academic Alliance - in the UK many universities have a program for teaching LabVIEW courses.

I'm not saying that you should teach LabVIEW exclusively - there are many cases where text-based languages need to be used (e.g. embedded microcontrollers / PLCs etc.).

Finally - a lot of the skills needed to be a programmer are language irrelevant. If you learn LabVIEW, a lot of the general programming concepts and skills can easily translate across to other languages and vice-versa. I personally don't think that Jacobson's point about Solidworks/AutoCAD is too relevant....he learnt the skills/knowledge required to be a mechanical engineer and it only takes a little bit of effort to translate those skills between different tools that you use.

(Sorry for the sort of disjointed ramble!)