Please, no Fortran in my LabVIEW

[Aristos Queue]

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.

[ShaunR]

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 June 11, 2013 by ShaunR

[JackDunaway]

+1; incidentally, for the good article; fundamentally, for what's in the pipeline.

[Phillip Brooks]

+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...

[crelf]

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

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!

[crelf]

I used that language professionally years ago... please don't dredge up those nightmares.

 

I kinda miss FORTRAN77.

[flintstone]

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.

[jzoller]

My favorite from the comments:

 

#define HaltAndCatchFire for(; fork();

[viSci]

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

 

Brilliant!

I thought my mutex'd singletons were a good idea but now it seems I have blood on my hands...

[Daklu]

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?

[Aristos Queue]

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.

[ShaunR]

Once we can save VIs as text, there's no reason to prevent us from writing VIs using text.

You can already. It's called C++, C#, VB, Python or any other text language. Choose your poison.

[Daklu]

You can already. It's called C++, C#, VB, Python or any other text language. Choose your poison.

 

None of those have the same multi-threading or message passing semantics as Labview.

[flintstone]

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.

[Daklu]

...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.

[flintstone]

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.

[Phillip Brooks]

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.