Spaghetti code

I'm pretty sure the best "spaghetti" environments are:

1. Matlab
2. Visual Basic
3. Javascript
4. Simulink
5. Labview

Sadly, you're only 5th. :cool:

Now a days a lot of so called AAA-Indie hybrid game codes are dice cut spaghetti visualized in VR layed across continents. With groups getting smaller and smaller and spread across the world in a soup, farther and farther away from bigger cities, and to the remotest tire two or three cities, into their garages.

Most of the bugs are version control related and quite a lot are novice.

Experienced game developers are just too good experienced, enough to be head hunted by companies of another industry that have huge patience for deadlines and a lot of coffers filled with generous cash to the tops. And a whole lot better perks.

Spaghetti code is obsolete. Real programmers use ravioli code.

I'm pretty sure the best "spaghetti" environments are:

1. Matlab
2. Visual Basic
3. Javascript
4. Simulink
5. Labview

Sadly, you're only 5th. :cool:

I have a particular vendor-developed application at work, that I inherited :(, where the only enhancement portions of the application that aren't black-boxed by the vendor is the database.

Which means all business logic is written in the forms of sprocs and triggers.

Which means after 15 years of multiple developers digging their grubby hands in the database, it's become a Cthulu named SQL.

It's scares me.

Ruby and Javascript were pretty bad back in the day for me.

I started one job maintaining a backend server that was of absolute critical importance to the company, and operated on a state machine where each transaction used a struct with the variables i,j,k.

The moment I got free reign to clean the application up, my first checkin read something like "cleaned up some stupid variable names that have been in place since 2009". The changelist was about fifteen files, one of them being a file that clocked in at over 12000 lines long. I think that speaks for itself.

I'm pretty sure the best "spaghetti" environments are:

1. Matlab
2. Visual Basic
3. Javascript
4. Simulink
5. Labview

Sadly, you're only 5th. :cool:

Haven't used Matlab, but the Maple projects I wrote as a senior in CS looked worse than the ruby programs I wrote when I was learning to code in High School, and ruby isn't exactly known for clean structured code to begin with.

I've been doing a lot of development in Labview recently at my dayjob and I just realized it's probably the best programming language to make actual spaghetti code. I'm currently struggling refactoring it to make it maintainable the next time I'll have to look into it in 6 months.

labview.png

Labview, that is a love/hate relationship. Unfortunately, its not really feasible to "write" useful "code" in labview without it becoming spaghetti. My suggestion is use labview to handle the GUI stuff, and pipe all the data from the various dials etc into a DLL, then use C++ or your favorite language to do the actual computation and export it to labview for display.

Labview looks like UE4 Blueprints to me. Probably mostly the same problems too.

It has been one year and fingers crossed, I didn't have to look back into the code yet! (not because there isn't any need to, but because I was "prioritized" on other projects and we are letting this one slowly rot).

And yes I agree that labview is great for the GUI part, it's the rest that can be a pain. I've never used blueprints but I guess it is a similar problem. Using a graphical representation for code only works when your task is very simple.

As for using a dll, I don't have a C++ environment installed on the machine (and I'm not sure I'd like to, it's a PXI system similar to this one, it's hard drive performance isn't that great and I don't want to bloat it with more software).

I found somewhere a module that lets you extend Labview with Lua scripts and I may look into that one day, if I have the time.

@Kylotan and @Daixiwen what do you think are the problems/why does visual programming only work for simple tasks in your opinion? I kinda wonder if it's only the same mistakes being made in such environments like a lack of hierarchies (or maybe just the use thereof? although that labview image in the first post looks like there are hierarchical blocks but they are always displayed inline, never worked with it though, only simulink) or that some abstractions like repeating the same operation on multiple inputs are missing.

I think it's quite subjective. Visual programming like this tends to obscure the code flow. But I wouldn't go so far as to say it only works for simple tasks. I think that someone who was good at visual programming might say the same about text-based programming: "How are you supposed to follow the flow when it jumps in and out of a ton of different files and functions? How are you supposed to see how everything fits together?"

I think the main problem is the lack of comments or variable names. Sure you can add some text blocks if you want but it's still a lot more difficult to comment something done with a visual programming tool.

Organizing your code is also easier in a text based programming language in my opinion. You can organize in different text blocks and insert code where needed. In a visual programming language if you haven't planned enough space around your first blocks you may spend a good amount of time just moving things around to make enough space for new blocks you want to insert. Also when trying to understand what a block does, the lack of variable names means often that you have to follow back the signal from its source to see what it actually is, and it can be time consuming when dealing with some code you are not familiar with.

(I'm only going to base this on Unreals Blueprints, since they are the most advanced and best visual programming language I know)

I think the main problem is the lack of comments or variable names. Sure you can add some text blocks if you want but it's still a lot more difficult to comment something done with a visual programming tool.

Actually, its quite easy: Select all nodes, rightclick, add comment block, type text. This also has the advantage of clearly indicating which nodes belong to the comment, whereas in textual languages, you have to come up with custom commenting schemes to mark blocks of code. You can also add a comment so single nodes, group functions in categories, etc... in Blueprint, so I wouldn't say its more difficult, but merely uncommon for most programmers :)

You can organize in different text blocks and insert code where needed. In a visual programming language if you haven't planned enough space around your first blocks you may spend a good amount of time just moving things around to make enough space for new blocks you want to insert.

Well, that is a fair point actually. Unreal already attempted to combat this problem by adding auto-formatting options, which just aren't optimal yet. You have to keep in mind though that with textual programming, if you didn't have IDEs/text editors with auto-formatting, then you'd spend a lot of time formatting your code as well, like indenting. Also Blueprints don't require syntactical whobble like ";" at the end of lines, or () {} "" for marking different blocks of code. Again IDEs take some overhead away by ie. automatically closing brackets after you, and being used to typing for a lot of years gets you really used to so you do it without thinking - but the same thing will happen if you get used to Blueprints, you get a lot more effective after a few months of using them.

Also when trying to understand what a block does, the lack of variable names means often that you have to follow back the signal from its source to see what it actually is, and it can be time consuming when dealing with some code you are not familiar with.

On the contrary, Blueprint shows you the name of parameters:

https://docs.unrealengine.com/latest/INT/BlueprintAPI/Rendering/Debug/DrawDebugLine/index.html

which totally makes up for the lack of local variable names. Compare ie. with the C++-variant:

DrawDebugLine(FVector(0, 0, 0), FVector(100, 100, 100), FColor(255, 0, 255), 10.0, 2.0)

Here you don't know which parameter is which without a little quesswork or knowledge of the function. So you'd have to create constants, just to make up for the fact. In general, Blueprints handle functions with multiple parameters much better. Every parameter has a default value. If you want to draw a line for 10 seconds and don't care how it looks, just change the "time" parameter, no need to supply default values for eigther the caller or the callee most of the time; and every parameter behaves the same regardless of position (ie. if you want to have explicit default values, you don't have to move the parameter to the end of the parameter list.

There's some more advantages like working with an all-present, insanely good autocompletion, where you cannot mix type-connections that don't match. Which brings me to the main point about visual scripting languages and their pro/contras - the're only as good as the tools they supply. Same goes for textual languages, but probably to a lesser degree. For example, think about having to code without autocompletion/intellisense. Or not having auto-formatting. Or not having helpfull functions like goto definition, create definition, global search & replace etc... at some point or the other, those things didn't exist; or wheren't as well-rounded as they are now. Same thing applies to visual scripts:
Today we are probably lacking a f*ckton of features that make working with them so much easier. Unreal have already taken a huge step forward with their language IMHO, and I wouldn't want to use another type of visual scripting system for the life of me (but theirs pretty much replaced most of my gameplay coding workflow). So just think about what will probably happen in the future - ie. there's certainly no reason why it shouldn't be possible to create a global auto-formatting for the nodes, that will drastically reduce having to drag nodes around manually. Just little stuff that adds up - and hopefully makes (good) visual scripting languages more approachable for more people :) Because:

Labview looks like UE4 Blueprints to me. Probably mostly the same problems too.

I find that comparsion unjustified, they pretty much look nothing alike (and labview pretty unbearably compared to blueprints), except they are visual languages. Now that to me sounds like saying C# looks a lot like malbolge, because, you know, they both use characters to represent their code ;)
(not sure if you're just too unfamiliar to blueprints; or I'm too overly biased towards them though, so don't take this too serious)

labview and blueprints have a few things in common:

• implied left to right execution flow
• operations connected by lines
• commenting implemented as blocks surrounding operations

There are other ways to do visual programming which works in quite a different way, e.g. Scratch, which is a tree of blocks. So, I don't think it's unreasonable to say that this looks more like Blueprints than any other arbitrary visual programming language.

Either way, it wasn't meant as a criticism of Blueprints. I think they can be messy; but I think text-based languages can be messy too. I was saying above that someone very used to visual programming might legitimately find text-based programming awkward, because you can't easily see which functions relate to others, they're spread over arbitrary different files, a single typo can 'disconnect' one function from another, it's not easy to see at a glance how many different routes through a function there are, etc.

labview and blueprints have a few things in common: implied left to right execution flow operations connected by lines commenting implemented as blocks surrounding operations

Ok, to be fair they are alike in those points. I was just baffled at how visually ugly labview is, that I felt a comparsion to blueprint somewhat odd. Like, I didn't even notice that labview had comment blocks from the picture posted above.

There are other ways to do visual programming which works in quite a different way, e.g. Scratch, which is a tree of blocks. So, I don't think it's unreasonable to say that this looks more like Blueprints than any other arbitrary visual programming language.

Ok, another fair point. Didn't even knew things like scratch existed - looks like its similar to what the Rpg-Maker series does, only a lot more visual.

Either way, it wasn't meant as a criticism of Blueprints. I think they can be messy; but I think text-based languages can be messy too. I was saying above that someone very used to visual programming might legitimately find text-based programming awkward, because you can't easily see which functions relate to others, they're spread over arbitrary different files, a single typo can 'disconnect' one function from another, it's not easy to see at a glance how many different routes through a function there are, etc.

Yeah, I can totally agree to that. I'm being so used to Blueprints now that I do tend to find textual coding messy for a lot of cases - I wouldn't implemented a render-queue in Blueprints by all means, but highlevel gameplay logic just feels way cleaner doing visually. Quess in addition to being used to, also using the right tool for the right job is something to consider.

EDIT: Ah, another thing that I forgot to mention, that can lead to blueprints feeling messy: In textual languages, having (pseudo)code like that in multiple places is not a big deal:

for(auto& element : world.objects[index].GetCollection())
{
      // do anything
}

In blueprint, this requires 3-5 nodes (including the for-loop), which take up a lot of space and can be quite annoying if you have to create over and over again. So it is quite imperative to create a method/macro every time you have the same set of nodes in more than 2 places. While you should probably do that regarless of what type of coding you use, in blueprints its a much bigger deal (also since for-loops, ifs etc... are more "costly" in terms of typing-efficiency) than otherwise, so the difference between "mindlessingly recreating the same code in different places" and "properly removing instances of duplicate code" has an enormous impact on both the perceived and actual productivity and messy-ness of the created visual code, in my experience at least.

Ruby and Javascript were pretty bad back in the day for me.

Javascript by nature is still a spaghetti mess almost everywhere. When you combine an intrinsically messy language along with novice web developers who link every library recommended to them by stack overflow, you get a bloated codebase that's very difficult to debug. This is especially true when developers spread event triggers across multiple files. js is almost impossible to debug.

The fact that Unity needs typescript to make js useful says a lot about the language.

I'm not familiar with Blueprints, I was mostly talking about Labview. Yes it does look messy, and from what you are saying Blueprints is better designed. Labview is also a lot older and as such carries a lot more baggage.

You can put text blocks for comments but it's not always easy to see what the comment is actually commenting and sometimes you need to add arrows or other visual indications. It doesn't add to the script's prettiness ;)