If UT were to add a new programming language what one would be best?

Dude, what kind of logic is that? Why to even ask such question, if there is a way where you just don't have to ask such questions in the first place?

Geez... No wonder that OOP still reigns supreme. -.-

It's like me saying: There are no functions in C#. Then numb skull #1 says: But these terms are interchangeable. Really, dude? So, they are called "method" in every freaking manual because they are the "same" as "functions"? GG, "programmer".

And this lack of actual understanding, is the very reason why OOP still reigns supreme. So, I can cancel now my appointment with the psychologist. Now, I'm in anti OOP yelling mood. Because I seem to start to understand what kind of programmer is defending "bad" and "garbage" OOP. :0

 

There isn't. You still have to ask the questions, because they're important. Procedural languages just allowed you to hack your code together without ever asking them, so you could try to solve problems you didn't entirely understand.

That's true. Now, answer me this.

Why is a function better than a static class method?

See, here's a function.

Code (csharp):

1.  
2. int AddFour(int i)
3. {
4.     i+=4;
5.     return i;
6. }
7.  

And here's a static class method.

Code (csharp):

1.  
2. public static class StuffToDo {
3.     public static int AddFour(int i)
4.     {
5.         i+=4;
6.         return i;
7.     }
8. }
9.  

What amazing wonderful thing do you have with that function, which you do not have with the static class method?

"WHARRGARBL it's not called a FUNCTION anymore"

The name of a thing is not the thing.

But yes, you are right. There are no functions in C#. However, there are plenty of ways to accomplish the same things you used to accomplish with functions, so this criticism amounts to nothing. It doesn't matter. You can still get the job done, and the discipline of explicitly specifying visibility and access will serve you well in more complex projects.

Of course, if you never intend to build complex projects, because you're never going to be on a sizeable team, and you're never going to collaborate across time zones, and you don't use source control, and nothing you do needs to be managed through a QA and release pipeline... well, bluntly speaking, you don't count. Your opinion means nothing. Write your code however you want, nobody cares.

 

@cdarklock C#6 also has the "using static" statement as well, lets you use the static methods in a static class directly.

Code (CSharp):

1. using static System.Console;
2.  
3. public class Example {
4.     public static void Main() {
5.         WriteLine("Hello, World!");
6.     }
7. }

But yeah for everyone bashing on one paradigm or the other, everything has its time or place. I can work fine in C#, or F# and when it comes to doing simple things i really enjoy languages like Python that just let you use anything you want at anytime without forcing classes or any 1 approach on you.

 

I didn't want to confuse the poor man.

 

Technically C# does have functions using System.Func so the person who really was having a brain meltdown "C# doesn't have functions!!" could do this...

Func <int, int> Add4 = AddFour;

or even inline it...

Func<int, int> Add4 = (i) => (i+=4);

That should keep the function purists content.

 

That's not the same kind of function that you find in the rest of the ALGOL-60 lineage, though. It's more akin to LISP and Scheme.

 

This is really just a convenience... predefined delegate signatures and return types. But it does enforce the return of a value.

In practice though I can't see why anyone would have a problem with using a method. Obviously, if the return type is not void it is a function. Even if it has void it may be a function using Out in the signature. Hmm... well maybe there is a reason they want it locked down.

I am not familiar with any of those 3 things: the ALGOL-60, Lisp or Scheme. lol

I thought the example originally was people griping about using a method that can work as either a subroutine or as a function depending on its return type. Using Func solves that by forcing a non-void return type.

 

Important how? F# does have compiler source order. F# is immutable by default.

This is one of the many ways how F# enforces structure, that not even C# does . Immutables are a big plus to begin with, since they are thread safe. But also, immutables don't change, so there is less need. If any need at all, for encapsulation to protect members.

I never said that functions are better than a static class method. And in F#, actually, a function is part of a static class. It's just called a module. No, it's not a namespace, that is in F#, too. A namespace cannot have Values.

And again, there is more structure. Because I can pack my "named code" a.k.a. "function", into Modules or "static classes." You do miss your Class instances called objects? Ever heard of the Billion Dollar Mistake?

This is not what I said... you idiot... -.-

Do you know in which programming language the F# compiler was written in? Is your brain able to handle a paradox, or would you just die a horrible blue screen of death?

Yes, but it only works on static classes. And in F#, since Modules are a Static Class under the hood. It ALWAYS works. That's one of the reasons along code noise reduction, why F# code requires less typing and can get shorter than C# code.

Where does this "function purists content" come from now?

And if I wanted FP. Then I wouldn't even use C# in the first place. I would use F#, that works to some extend at least, over the managed API of Unity already.

If I can take a shorter way of achieving the same result. Then I will take. -.-

 

Ha ha! I wasn't directing that at you specifically. Just saying there are "truer" functions in C# than the general purpose methods. For those people who want a more formalized spec for their functions ("purists" was my shorthand for that preference).

I actually thought you were also saying something along the lines of they are making a big deal out of nothing... just use methods to get the functionality of functions.

 

Actually, it's a quite crucial distinction to make, in order to fully grasp the object oriented principle.

A function, is as you know, the same concept as that of mathematics - a blackbox which gives you certain output when you put certain input.

But method, on the other hand, defines a behavior which presupposes the existence of a specific type of an object. And it's important to understand that a class is not the same thing with just a source file where you put bunch of related 'functions'.

In fact, some OOP languages, including C# 7.0, enable you to define an actual function, in addition to normal methods, which also implies they are not the exact same thing.

All that matters in software designing is how you 'model' the real world domain you are dealing with. And with OOP, you analyze and abstract it using hierarchical concepts, and make each concepts to have its own properties and behaviors.

Why you want to do that when you have functions? Because it enables you to understand or create something very complex in a piecemeal manner. If methods and functions are the same thing with just different names, things like C# core APIs or Java Spring Frameworks would be just a gigantic mess of functions which you need to memorize all to be proficient with it.

But OOP also enables hierarchical and structural understanding of the whole, which significantly makes the life easier for everyone who wants to use or extend such frameworks.

On a side note, it's also the reason why I still cannot see Functional Programming as the complete replacement of OOP even though I can see its benefits in many situations.

Although there are some concepts that fit nicely with the concept of 'function', like constant flow of events, streams, manipulation of data structure, and etc, I believe at least some things are better understood as hierarchical concepts with their own states.

In a game, there can be a character which has its own properties, like a name, movement speed, and etc. And a character can either be an autonomous NPC, or the player, and there are certain behaviors that would only make sense in either contexts.

Of course, you can see an NPC simply as an aggregation of data, which you can manipulate with bunch of independent functions. But it's much more intuitive to assume it as what it actually is in the gaming context - a character which as certain attributes and can behave in certain ways, and etc.

And that is the reason why a 'method' in OOP context is not simply a 'function' with a different name.

 

If you ever ask yourself "should my class be abstract or sealed?" you do not even understand what those things mean, let alone how to answer the question.

Then why does it matter if we don't have them?

I don't care.

Oh, are you going to explain it was written in F#? Because that's not a paradox. One of the first things you should do when designing a new programming language is use it to write its own compiler, because if you can't even do that the language is garbage.

Choosing shorter instead of better is a great way to suck at everything.

 

Self-hosting is a common concept. Just about every modern programming language does it.

https://en.wikipedia.org/wiki/Self-hosting

 

Yeah, and it's even possible with such esoteric languages like Brainfuck

• https://github.com/matslina/awib

 

Totally agree.