Oh, nevermind. I thought UFCS was something else for some reason. I was thinking of the way lisp’s built-in semantics have the same syntax as user-defined semantics. Yeah, I agree UFCS doesn’t solve the problem you are describing here. Python has something like that and it always irked me. Like, if you are locked into a classical OOP mindset and everything is always a method.. maybe it makes sense.. but then why did you want UFCS to begin with.

I kind of like the way JavaScript does this (I also hate the way JavaScript does this for other reasons). In JavaScript methods are just functions that happen to also be properties of objects. In a weird way it’s almost the opposite of UFCS..

How is it *not* an overcomplication?

You have two totally parallel systems and syntax-sets that do the same thing. (“Object method calls” and “procedures taking a struct pointer as their first argument”). Why?

This seems to me like a bold statement in need of some justification. Like, I’m not advocating for writing games in lisp, the library support isn’t there. But from the perspective of a brand new programmer, how is uniform function call syntax an overcomplication?

btw: I loved The Witness, thanks for making it :)

The model works around defining a type and the smallest set of methods necessary to work with its state, the rest of logic is likely best off implemented as “free functions” (which then brings us to UFCS), since they can match and cover several types horizontally too (ducktyped – “it has the methods needed? It works.” [Of course sumtypes, virtual (“ancestor”) types, generics and unique typing is fully available also – pick and choose, mix and match.]) (DRY!), and has to go through accessor methods for the data (encapsulation).

Pretty much win win in my book.

Somehow it also got posted to hacker news and made it front page: https://news.ycombinator.com/item?id=10346985

Whomever did this, thank you!

Regards,
Tom.

Being able to call member functions with the same syntax as regular functions (and vice versa) is very nice – just so long as you don’t loose sight of the value of having a closed set of member functions.

Member functions have privileged access to the data inside an object. It is often crucial that object data be accessed in a particular way to ensure correct function (eg: locking mutexes in the correct order). If the designer of a class cannot restrict the access to a known set of functions at design time it becomes impossible to write robust code.

Still – I do like the idea of being able to call free functions, which are themselves only implemented using the original class interface, as if they are members.

There are many profits:
1. you can easily add any “extension” to any object by just declaring usual function.
2. your IDE knows what to show after your “obj.”
3. it is simplification for user, not a complication (as extensions, for ex.)

My ideal language will behave just in that way.

(I think that ArrayList would be a better illustration than Vector3)

PS: I respect your opinion, did not want to sound mean!

Not really:

> So in reality, you want Vector3 to define only a common piece of data to be exchanged

Precisely how it’s done in MonoGame PCL.

> You can provide default functions for operating on Vector3, but in a way that people can easily shadow them with their own functions or else use a completely disjoint set.

Precisely achieved by extension methods.

> I wish people would stop telling me that member functions are good because you can do obj . and get a list of procs in the IDE after typing the dot.

I wish people would stop saying object model is bad just because it can be abused :).

However, I’m not aware of any prototypal languages that would be suitable for performance critical systems like game engines (not saying they don’t exist).

Not really. I think though you are confusing “OOP” with “providing an abstract interface for some data you don’t need to think about the specifics of”. The latter I do all the time, yes.

In my opinion “extension methods” are just a further complication of something that should not have been complicated to begin with.

https://en.wikipedia.org/wiki/Extension_method

http://www.extensionmethod.net

https://msdn.microsoft.com/en-gb/library/bb383977.aspx

One way to solve this problem is to make regular functions callable with the dot syntax, so that you could rewrite this:
function(object, somethingA, somethingB);
as:
object.function(somethingA, somethingB)
Basically, when using the dot syntax, the parameter before the dot goes as the first parameter of the function.

This semantics would allow for things like:
x.factorial();
“%, %”.format(x, y);
and so on.

This is the issue because now I am have to program with a GC in *mind* and that seriously adds to my overall mental friction. And, of course, the possible usage of the standard libraries that may allocate from the heap. On a very large project, this starts to add up. So, a GC is just a non-starter.

http://comments.gmane.org/gmane.comp.lang.go.general/37934

This thread was interesting to me.

The GO garbage collector is fairly flexible though, no? You can explicitly set how often it should run. And also inspect how often it’s running through profiling.

http://comments.gmane.org/gmane.comp.lang.go.general/37934

Is < 2% of time spent collecting memory just by restructuring your program data and workflow a little bit that bad?

vs what you save by not using GC at all… Which I understand can be a lot in some cases. But I've read other people saying that the way Go works, it almost depends on the existence of a GC unless you want to not have certain features and / or manage their memory yourself. That comes with the runtime.

This is why I like the way Go deals with member functions. It is a good compromise in the sense that you get clean data structures to share and reason about with the benefits of function fluidity, code reuse, in addition to a convenient mechanism for operating on that data without the rigidity of C++ member function. An example can be found here:

https://golang.org/ref/spec#Method_expressions

I use strictly C in the embedded space and I get real tired of the following pattern:

struct hardware;
struct hardware_ops{
int (*read)(struct hardware *hw);
};

struct hardware{
char data[MAX_DATA_SIZE];
struct hardware_ops ops;
};

static int hardware_read(struct hardware *hw)
{
return 0;
}
void hardware_init(struct hardware *hw)
{
hw->ops.read = hardware_read;
}

struct hardware hw;
hardware_init(&hw);

/* Just to do this: */
hw.ops.read(&hw);

Lastly, golang got so much right in so many ways but the GC – can’t have pauses in critical medical devices.

Recently I figured out that OOP is kinda BS, and I’m unlearning it. Golang has been great for me on that matter (I’m using it in both work and in a toy project).

Recently I’ve been assigned in a task, and for it’s nature it was well suited to Python (“company’s native language”). At some point a “Object pattern”
started to appear heavily, and I said: “Ok. time to be mature and reasonable and take advantage of some real OOP, and put aside my recent feelings about it”. At the first couple days it was all great, and the more functionality I stuffed on my “main object” the easier thinks became, but didn’t took long before it started to smell.

This should be really obvious but: This kind of tight coupling start to fall apart when you have to change things more deeply. You usually have to that once in awhile, unless you’re doing BigDesignUpFront (which is another counter-productive pain in the ass in most contexts).

The idea is: allowing types to be extensible, and to use functions on them by properly controlling a static namespace. Theferore they feel likes functions, but they are polymorphic on the objects type (or with multi-methods, of the type of all or any of the arguments).

Worthy mention: Prolog replaces this with whole notion with unification, which is a more general and powerful concept than patter matching / ad-hoc polymorphism (it is aslo a lot harder to reason and implement).

A Vector3 is a very simple case. It’s unlikely to ever consist of anything but 3 numbers, probably indexed as 0, 1, and 2. And any three numbers make a legal vector, and callers probably want to access the individual numbers, so you might as well let them (though you might want to make them read-only). But for anything much more complicated, if you just let all callers access the raw data without imposing some rules, you’re asking for trouble. (Sorry to be so vague; don’t have time to write an essay on the reasons for data abstraction.)

Not that I think you should always impose strict abstraction on every data object. There are different considerations for every project.

I believe that your APIs do matter, and that the way things are expressed does matter. I also don’t buy into the idea that I shouldn’t need to know how anything works under the hood, because more often than not, that’s where the actually difficult problems lie.

I think OOP and OOD has largely been a failure, and rigidly and inflexibility provides certain relationship or expressive mechanisms which some people find useful. I haven’t followed your language enough to comment much further, and my language design experience is next to none, but I’m not opposed to closures and some alternative means to OO-mess to establishing contracts between data and processing algorithms.

func (i32 by_ref_arg1, i32 by_ref_arg2)my_func(i32 by_val_arg1, i32 by_val_arg2) {…}

so at the call site it’s clear which args could be modified by the function, and which are read-only:

(a, b).my_func(2, 4)