25
\$\begingroup\$

Inspired by this question, how would a LabVIEW program be scored?

As one of the only graphical languages in common use today, LabVIEW is a bit of an outsider. As odd as it is, LabVIEW is a serious language that is used everyday. And yet, it is rarely seen on StackOverflow and never on PPCG.

Is there room for this oddball language that brings the term spaghetti code to life? And if so, how should it be scored?

\$\endgroup\$
3
  • 5
    \$\begingroup\$ I've used lab view and it definitely satisfies our notion of language so answering in it should be allowed. The byte count is a trickier matter.. \$\endgroup\$
    – Calvin's Hobbies
    Nov 17, 2015 at 4:57
  • \$\begingroup\$ I seem to recall this being discussed before, but the search doesn't find it. \$\endgroup\$
    – Peter Taylor
    Nov 17, 2015 at 10:04
  • \$\begingroup\$ thing with labview is the blank vi alone has a size of 3 kb so its not the best code golf language. I posted one just a few hours ago and used the size that is shown when you save the vi. A possibility would be to count 1 byte for every verliable while loop operation and so on. \$\endgroup\$
    – Eumel
    Nov 27, 2015 at 14:22

2 Answers 2

Reset to default
11
\$\begingroup\$

Some time ago, there was a program for the Mac called "Quartz Composer" use for doing some graphic things.

The main thing I'm bringing up here is the interface...

enter image description here

The boxes and lines connecting to them. A simpler one:

enter image description here

When you actually dig into the file that is saved, it turns out to be an xml file.

<key>rootPatch</key>
<dict>
    <key>class</key>
    <string>QCPatch</string>
    <key>state</key>
    <dict>
        <key>connections</key>
        <dict>
            <key>connection_1</key>
            <dict>
                <key>destinationNode</key>
                <string>Camera_1</string>
                <key>destinationPort</key>
                <string>inputRotateX</string>
                <key>sourceNode</key>
                <string>Interpolation_1</string>
                <key>sourcePort</key>
                <string>outputValue</string>
            </dict>
            <key>connection_2</key>
            <dict>
                <key>destinationNode</key>
                <string>Camera_1</string>
                <key>destinationPort</key>
                <string>inputRotateY</string>
                <key>sourceNode</key>
                <string>Interpolation_2</string>
                <key>sourcePort</key>
                <string>outputValue</string>
            </dict>
            <key>connection_3</key>
            <dict>
                <key>destinationNode</key>
                <string>Camera_1</string>
                <key>destinationPort</key>
                <string>inputTranslateX</string>
                <key>sourceNode</key>
                <string>Interpolation_3</string>
                <key>sourcePort</key>
                <string>outputValue</string>
            </dict>
        </dict>
        <key>nodes</key>
        <array>
            <dict>
                <key>class</key>
                <string>QCInterpolation</string>
                <key>key</key>
                <string>Interpolation_1</string>
                <key>state</key>

I'm not going to claim that this the most efficient storage (that particular one goes on for 2465 lines). However, the thing that should be examined is the way to represent the labview in such a way that one could take the text representation and covert it back into a working graph.

Just counting wires as 1 byte is cheap.

While this may be a significant undertaking, consider trying to figure out how to represent the LabVIEW structure in JSON or another structured data language. The necessary thing is to be able to represent the program in text, and be able to convert it back to the same program in LabVIEW via a mechanical transformation. Otherwise, this feels very much like "I'm going to write in C, but I'm going to count if as one byte and switch(x) { 1: break; } as four bytes"... which, well, it's not. Golfing LabVIEW according to some scoring system is fine, but calling them bytes and comparing them with languages that actually use characters is like comparing apples and oranges. Call them "LabVIEW Primitives" or "weighted fundamental graphical programming primitives" - but not bytes.

Another (better?) way of getting an idea of how much information is in a given LabVIEW file is to take the save file for it, and compress it with a standard compression program at maximum space efficiency - and that is how big the 'program' is. Its kind of like how the byte counting of the golfing languages can encode things in there.

\$\endgroup\$
3
  • \$\begingroup\$ the compression method would not work well as the file saves coordinates that dont affect the functionality. Not calling it bytes has been adressed, i really like LabVIEW Primitves i will change it to that. Also in LabVIEW if isnt one Byte since you have to count the extra wires you need and if you golf C if will come out to ? so its 1 Byte ;) \$\endgroup\$
    – Eumel
    Dec 1, 2015 at 9:02
  • \$\begingroup\$ Since it's XML, it should be straightforward to write an XSLT that counts elements according to the conventions adopted? It's not a language I'm planning to learn, but it sounds like the way forward. \$\endgroup\$
    – Toby Speight
    Dec 3, 2015 at 12:55
  • \$\begingroup\$ @TobySpeight the xml example was from Quartz Composer. I don't know what the underlying LabVIEW file format is. This was more of an example of a different graphical programming language and what its underlying representation actually is. \$\endgroup\$
    – user12166
    Dec 3, 2015 at 14:14
10
\$\begingroup\$

I´m gonna propose some rules on counting Bytes in LabVIEW code, so tell me what you think.

As Bytes are not really what LabVIEW does they were renamed to LabVIEW Primitives.

  1. wires: each wire is 1 LabVIEW Primitive, splitting a wire makes it 2 LabVIEW Primitive and so on

  2. Constants: strings are 1 LabVIEW Primitive per character, bools are 1 LabVIEW Primitive, Arrays have 1 LabVIEW Primitive per Dimension Clusters are 1 LabVIEW Primitive.

    2.1 numerics are the size of their representation

    2.2 numerics are 1 LabVIEW Primitive per Digit

  3. VIs: LabVIEW intern VIs are 1 LabVIEW Primitive, SubVIs should not be used

  4. Structures: While and for loop each 1 LabVIEW Primitive case 1 LabVIEW Primitive per Case, Sequences are free, shift registers are 1 LabVIEW Primitive each

By average LabVIEW Primitive count this would probably place LabVIEW scores somewhere slightly above normal Languages like C but a good deal below golfing languages.

\$\endgroup\$
4
  • 9
    \$\begingroup\$ I think it's fine to make up an arbitrary scoring system for graphical languages as long as it's fair, but don't call it "bytes" because it isn't. Using "Bytes" means there is an actual representation of the program being stored. Could we call it "Equivalent bytes"? \$\endgroup\$
    – intrepidcoder
    Nov 30, 2015 at 20:11
  • \$\begingroup\$ sounds good i will use that from now on \$\endgroup\$
    – Eumel
    Nov 30, 2015 at 20:14
  • \$\begingroup\$ I think we can be a little more precise here. In terms of counting wires, let's define a "node" as the section of wire that gets highlighted on triple click. Then a "branch" is the number of dots on the node due to splitting the wire. Then the number of labview primitives due to wires is: total_nodes + sum_over_all_nodes(branches_per_node). In this example: i.imgur.com/MMIB89a.png there are 3 nodes; one connected to the string control, one inside the case structure, and one on the string indicator. There's only one branch, so the total wire primitives is 3 + 1 = 4. \$\endgroup\$
    – ijustlovemath
    Sep 14, 2016 at 14:27
  • \$\begingroup\$ Why would multidimensional arrays need to be >1 primitive \$\endgroup\$
    – ASCII-only
    Apr 17, 2018 at 1:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .