The language server in Visual Studio Code, and the extension to integrate it with the editor (both of which are developed by the Go team), are better than most others I've seen.
I know some people say that. It's an open debate, I think. At any rate, it doesn't have classes or inheritance which is the element of object orientation that I've concentrated on here.
@@vectorhacker-r2 Yes. A good point. Maybe this is something I should discuss more fully in another video? But the particular feature I'm exploring here is the nature of "class hierarchies". This is from the GO FAQ: "Is Go an object-oriented language? Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy." I can't think of any other language describing itself as OOP that omits class hierarchies. I think I've shown that indeed Go does make "an object oriented style of programming" reasonably easy. However, using any pure OO language (like Smalltalk) or any other mainstream OO language (C#, Java etc.) class hierarchies would normally be thought of as a fundamental feature.
Many software under the Linux/BSD world are written in C language, and if you take a look at the GUI libraries, for example GTK, they are using some rudimentary reimplementation of an object system. In some cases it's because of the age of the software, in other cases it's like that to provide stable ABI and compatibility with other languages, but mostly they use C because masochism ;)
I wrote console and PC games for years in pure C. We had hundreds of objects in each game. No masochism required! Objects just allow one to smush together structures and methods, that’s all. Whether you think this is a revolutionary advancement or just syntactic sugar is largely moot. If it works, who cares? P.S. in C, structs can include function pointers, so technically you can have methods too which can be arbitrarily assigned or replaced at will. Try doing that in C++!
Thank you very much for the excellent presentation. I think that being able to implement in either procedural or object oriented format is a very valuable skill. The dogma that is single philosophy is appropriate for all situations can be quite limiting.
Hmm, in fact what's happening here is not typical OOP, but in essence it is OOP. I thought it would be doing it in something like BASIC or a purely procedural language. I think that would have been more informative to seen the convenience that OOP brings.
I wanted to use a modern and widely-used language. But it's certainly possible to create something similar in Basic, if you put your mind to it. The adventure game I wrote in the 80s was in Turbo Pascal, which had nothing remotely similar to OOP.
The first adventure game I ever wrote was in Turbo Pascal - with no objects of any description. So all the "objects" were done using records (the Pascal version of structs). It's definitely easier to write this kind of code in Go than in (traditional) Pascal.
Ha! To be honest, I think many programmers do that anyway. They just don't realise they are doing it. A good idea for a video, though. I'll give some thought to that!
You could certainly define each struct independently of the others then create libraries of functions to act on those structs (as data) rather than being typed to work with specific structs. Give it a go and see which approach you prefer.
I do wish ( GO ) had a IDE like and as complete as Lazarus ( Object Pascal ) ;-)
Go in the full version of Visual Studio would be great. The Go support in Visual Studio Code is pretty good though.
The language server in Visual Studio Code, and the extension to integrate it with the editor (both of which are developed by the Go team), are better than most others I've seen.
I’d argue that Go IS object oriented
I know some people say that. It's an open debate, I think. At any rate, it doesn't have classes or inheritance which is the element of object orientation that I've concentrated on here.
@@LearnWithHuw I don't think you need classes or inheritance to do proper OO. I think the main focus is on messaging and encapsulation.
@@vectorhacker-r2 Yes. A good point. Maybe this is something I should discuss more fully in another video? But the particular feature I'm exploring here is the nature of "class hierarchies".
This is from the GO FAQ:
"Is Go an object-oriented language?
Yes and no. Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy."
I can't think of any other language describing itself as OOP that omits class hierarchies. I think I've shown that indeed Go does make "an object oriented style of programming" reasonably easy. However, using any pure OO language (like Smalltalk) or any other mainstream OO language (C#, Java etc.) class hierarchies would normally be thought of as a fundamental feature.
Many software under the Linux/BSD world are written in C language, and if you take a look at the GUI libraries, for example GTK, they are using some rudimentary reimplementation of an object system. In some cases it's because of the age of the software, in other cases it's like that to provide stable ABI and compatibility with other languages, but mostly they use C because masochism ;)
I use C for some projects too. It wouldn't be my language of choice for the sort of project I show in this video. But it certainly could be done!
I wrote console and PC games for years in pure C. We had hundreds of objects in each game. No masochism required!
Objects just allow one to smush together structures and methods, that’s all. Whether you think this is a revolutionary advancement or just syntactic sugar is largely moot. If it works, who cares?
P.S. in C, structs can include function pointers, so technically you can have methods too which can be arbitrarily assigned or replaced at will. Try doing that in C++!
Thank you very much for the excellent presentation.
I think that being able to implement in either procedural or object oriented format is a very valuable skill.
The dogma that is single philosophy is appropriate for all situations can be quite limiting.
I completely agree.
Hmm, in fact what's happening here is not typical OOP, but in essence it is OOP. I thought it would be doing it in something like BASIC or a purely procedural language. I think that would have been more informative to seen the convenience that OOP brings.
I wanted to use a modern and widely-used language. But it's certainly possible to create something similar in Basic, if you put your mind to it. The adventure game I wrote in the 80s was in Turbo Pascal, which had nothing remotely similar to OOP.
If you want a little bit more challenge you can try writing it in Erlang/Elixir 😂
Or, to backtrack from Erlang syntax, try Prolog. I was besotted with Prolog for a while. Maybe I'll do some viedos on that language some time?
Nice experiment. Is always interesting to see struct use in places were classes would make things a bit easier.
The first adventure game I ever wrote was in Turbo Pascal - with no objects of any description. So all the "objects" were done using records (the Pascal version of structs). It's definitely easier to write this kind of code in Go than in (traditional) Pascal.
you deserve more subs
Thank you!
Do Rust!
I was already thinking about that. I'll add it to my list! 🙂
i would love to see you writing Non OOP in an OOP language. that would be cool.
Ha! To be honest, I think many programmers do that anyway. They just don't realise they are doing it. A good idea for a video, though. I'll give some thought to that!
How would you change this code to use less OOP oriented approach?
You could certainly define each struct independently of the others then create libraries of functions to act on those structs (as data) rather than being typed to work with specific structs. Give it a go and see which approach you prefer.