Jump to content

What other languages do you use?


TheBoss

Recommended Posts

My first attempt (successful) at writing a machine control program was in several thousand lines of Perl/Tk. It was talking to a pair of LabJack controllers and ran an automated test rig for cycling contaminated fuel through jet engine nozzles. The GUI part was a major pain. I shouldn't like to do it again, but could if I had to.

Getting a little rusty in Perl, mainly because of having LabVIEW. And with Tk having been semi abandoned by Perl, I might be inclined to switch to Python. Not because I find Python superior for a particular reason, but only because I'm getting interested in 3D with Rhino 4 and Blender 5.56. Python is ubiquitous in the 3D realms.

Are there any Open Source graphical programming languages? Would be major cool to find out that there are. I'd give one a whirl.

Link to comment
  • 4 years later...

LabVIEW is cool.  National Instruments, Agilent are hard to beat for measurement apps.

 

Object Oriented Fortran looks good, the Object Oriented features are great.

The version numbers are like Fortran 95, Fortran 2000, or something.

g95 is the name of the compiler.

 

If C++ gets you upset, try an Object Oriented version of Fortran.

 

It allows the programmer to produce a true interface within code and produce

compiled modules for code reuse.  Unfortunately, one would have to combine

it with something else for a GUI.  It can be combined with Octave to do

matrix math and produce plots.

 

After you try Object Oriented Fortran, Fortran IV and Fortran 77 code

looks like a different language.....

Link to comment
  • 2 weeks later...

Well. As this is cropping up again I might as well come clean and admit I've been doing a lot of text programming recently :wacko:

 

I've been using a package called Codetyphon which is a bundle consisting of a heavily modified Lazarus (Freepascal Visual RAD IDE), shedloads of components/examples and, very importantly, cross-toolchains for a huge range of platforms that you don't have to solve Cicada to install.

Edited by ShaunR
  • Like 1
Link to comment

I've been using a package called Codetyphon which is a bundle consisting of a heavily modified Lazarus (Freepascal Visual RAD IDE), shedloads of components/examples and, very importantly, cross-toolchains for a huge range of platforms that you don't have to solve Cicada to install.

I understood some of those words...okay no I didn't.

  • Like 2
Link to comment

I took up C as an elective while studying Electrical Engineering, and discovered that I really enjoyed programming. So, I learnt C++ as a hobby, which opened doors to an internship to develop a small embedded system. Then, I used my hobby and internship portfolio to land myself a full-time job in a LabVIEW house :-D

Link to comment

I've been looking at nodejs a lot lately.  

 

Its basically server side javascript.  Lets you do the backend and frontend in the same language.  Obviously you still need to learn HTML and CSS but i think the browser is the future for HMI and GUI's for most of my projects.  Its hard to beat the amount of open source material there is out there for the front end browser experience.  

 

I still want to learn C++ for embedded stuff.  

Link to comment

I've been getting my hands dirty with embedded C programming lately for AVR chips. A fascinating reversal of perspective from LabVIEW where resources are so abundant you don't need to think of them. I think it's good to rotate skills from time to time, lest one become overly focused on a single tool.

Link to comment

I've been getting my hands dirty with embedded C programming lately for AVR chips. A fascinating reversal of perspective from LabVIEW where resources are so abundant you don't need to think of them. I think it's good to rotate skills from time to time, lest one become overly focused on a single tool.

 

I spent more time in cross-platform C than LabVIEW in 2014. My respect and awe for LabVIEW was previously naïve and fanboy-ish, and is now tempered with scars inflicted by kernel-level resource management.

 

Will report back in 2016 on how my 2015 view of LabVIEW was naïve.

 

(eyeballing Rust)

Link to comment

A fascinating reversal of perspective from LabVIEW where resources are so abundant you don't need to think of them. I think it's good to rotate skills from time to time, lest one become overly focused on a single tool.

 

Yes, we need to pick the right tool for the job at hand.

 

Also, I think spending some time to do things the low-level way helps us understand how to optimize our use of high-level tools. Learning how registers are implemented helped me write better C code. Learning memory management in C helped me understand and appreciate what LabVIEW is doing behind the scenes, so I can write better LabVIEW code.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.