Jump to content

Please, no Fortran in my LabVIEW


Recommended Posts

I have often thought how useful it would be to have a text save format for LabVIEW VIs. But then I read this and I think maybe it is better that we don't have it. Why? Because someone will create a preprocessor. And then this...  http://www.dadhacker.com/blog/?p=1274

 

Let me just state now, for the record, in some future LabVIEW where such features exist, if you ask me to look at your VI, and I open that VI and find the entire block diagram written in Fortran, and you failed to adequately warn me ahead of time, I cannot be held responsible for any retributive actions I may take during my psychotic breakdown. I used that language professionally years ago... please don't dredge up those nightmares.

  • Like 1
Link to comment

My definition of "Code Smell" is completely different to that in the article. To me it is a behaviour that indicates a particular bug or type of bug.

Let me just state now, for the record, in some future LabVIEW where such features exist,

They are already here if you are talking about pre-processor commands - Conditional Disable. But I feel your pain, not necessarily with FORTRAN, but certainly C where everyone has their own definition of INT and "macros" that can be considered cryptographically secure.

Edited by ShaunR
Link to comment
+1; incidentally, for the good article; fundamentally, for what's in the pipeline.
5. Abstraction layers that just pass the buck, with each layer adding, recomputing, removing or re-arranging parameters. Abstractions are like peanut butter; a layer or two is fine, but once you’re down five or six layers and nothing has fucking happened yet you’re in definite “even if I could get my mouth open to scream now, that would just let in the evil stuff I’m swimming in” territory.I'm living this every day. I support a homegrown script processor, switching abstraction tables with their own macros, poor instument drivers and multiple spreadsheet files to enforce configuration all glued together with TestStand that has patterns required in v 1.0 (input buffer and seq context). Some developers got creative and accessed TestStand vars using the seq context, others built elaborate TestStand expressions in the pre expressions while others used the properties page. Throw in a bunch of dynamically loaded sequences from external sequence files with parameters passed by ref and you can't change anything without causing the apple cart to dump it's rotting load in the middle of the road.Sorry, I've been keeping this steaming pile running for too long...
Link to comment

"...every time you make a singleton, God kills a start-up, two if you think you’ve made it thread-safe." :D



Abstractions are like peanut butter; a layer or two is fine, but once you’re down five or six layers and nothing has fucking happened yet you’re in definite “even if I could get my mouth open to scream now, that would just let in the evil stuff

 

Brilliant!

  • Like 1
Link to comment
My definition of "Code Smell" is completely different to that in the article. To me it is a behaviour that indicates a particular bug or type of bug.

They are already here if you are talking about pre-processor commands - Conditional Disable. But I feel your pain, not necessarily with FORTRAN, but certainly C where everyone has their own definition of INT and "macros" that can be considered cryptographically secure.

 

... and still the definition of an "int" in the C standard beats about every definition in the LV standard by it's mere existence.

Link to comment
I have often thought how useful it would be to have a text save format for LabVIEW VIs.

 

That would be nice to have.  It would certainly simplify diffing and merging.  Not too long ago I speculated someone who knows scripting well could write a utility to save VIs in an xml format.

 

What you're be doing is creating a text-based version of Labview.  Once we can save VIs as text, there's no reason to prevent us from writing VIs using text.  I think that'd be an interesting experience.  Which current text languages do you think most closely mimic what Labview presents users?

Link to comment
What you're be doing is creating a text-based version of Labview.  Once we can save VIs as text, there's no reason to prevent us from writing VIs using text.  I think that'd be an interesting experience.  Which current text languages do you think most closely mimic what Labview presents users?

The dot language used by Graphviz comes most easily to mind. Next closest would be XAML, in my observation. Both of those are declarative languages, meant for describing layout and connection. dot can express cycles in graphs, but it lacks the positional information (as that is supposed to be inferred by automatic layout). XAML has the position and is richer in its syntax checking. Although scripting either of those would be easy enough, programming in them would be very hard. Graphviz separates declarations of nodes from declarations of connections. XAML would require something similar... you would have to declare wires separate from nodes or something weird like that because XAML expresses a tree natively, and any time two parallel paths came together, you have to introduce some sort of "that's me over there" notation. As for the procedural, dataflow and functional languages... any save format that allowed you to write G would look *nothing* like any of those programming languages. There are things we could do in other languages that we could *interpret* as a VI (for example, single assignment C), but to save all the positional/configuration information, you need more notation than any of the textuals generally have.

Link to comment

I guess it would have some resemblence to languages like VHDL, Verilog, SystemC with in- and out- ports for VIs and some means of describing the connections. For the layout something XML-based. Logic description and layout description separated in two files.

 

Regarding mutli-threading and message-passing Erlang has a good name.

Link to comment
...to save all the positional/configuration information, you need more notation than any of the textuals generally have.

 

I agree, dealing with all the position/configuration information would be a pain.  When I'm diffing VIs 98% of the time I don't care about block diagram positions; I just want to what functional changes have occurred.  I've been idly wondering about ways to get a text-based diff engine to ignore certain elements, like position tags.

 

It's interesting you mentioned Graphviz.  Occasionally I wish I had an editor that allowed me to write certain parts of my applications using text code.  Over there (*waves vaguely in the direction of the NI forums*) I suggested opening the compile chain to provide developers with a way to compile code from DFIR instead of from G source.  Then the other day I found out you can use Graphviz to view DFIR.  Even though it does me no good to write or modify DFIR files directly, perhaps diffing them would be useful?  I think I'll have to spend some time looking into that...

 

 

 

Regarding mutli-threading and message-passing Erlang has a good name.

 

Yeah, I've heard good things about Erlang.  It's one of the long list of languages I'd like to learn, along with Haskell, F#, XAML, Ruby, Lua, Smalltalk, x86 asm, etc.  My next language (other than Python, which I'm learning with my daughter over the summer) will probably be Oz.  I find the idea of supporting many different programming paradigms intriguing.

Link to comment

Somehow my interest in new programming languages has gone mostly, in most cases it's anyway C-style syntax and looking up stuff in the documentation. I wrote several Python programs for my old company and I couldn't do a "Hello World" now because I forget everything about it so quickly. I'll go for the simply and powerful stuff: VHDL together with C/C++ to implement application-specific soft-core processors in FPGAs ... this is something which I'd find extremely interesting, as there's almost everything: from hardware design to driver implementation to user interfacing.

Link to comment
Abstractions are like peanut butter; a layer or two is fine, but once you’re down five or six layers and nothing has fucking happened yet you’re in definite “even if I could get my mouth open to scream now, that would just let in the evil stuff

 

Just remembered this Randall Munroe (XKCD) comic.

 

the_general_problem.png

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.