|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On December 09 2017 06:32 sc-darkness wrote:Show nested quote +On December 09 2017 05:36 Manit0u wrote:On December 08 2017 07:54 TMG26 wrote:Everything. Trying to hide both hardware and math under the desguise of 'domain'. Hiding file globals under the desguise of instace variables. Promises of reusabile that were never kept. Idiot ways of handling state. It's pros are 'easyness to understand' and 'mapping to domain' which are both full of crap. Easyness to understand is a falacy, peopele start to apply real world logic to computers which never cared about it, and don't get the realiabilty of good old math. This meme of easyness makes sure that OOP code is full of bad practices from programmers that didn't understood neither CS math concepts or the underlying hardware. And abstracting to domain is crap, you should abstract math concepts, xenturies old categories used by everyone which makes the code actually reusable, rather than looking reusable. Old full OOP languages are full of bad legacy stuff given by the necessary OOP things of the time and ignorance of math concepts. Then there is the whole 'adding OOP stuff' to languages that never needed it. I'm a bit drunk so I not gonna expand more. I dobhave more complains about it, and OOP is what I do for a living! I mainly devolep in Java and ruby, with some bash scripting for the whole CI/CD thing to work. All my hobby work is eiher in Haskell, C, Erlang and shell scripting though... Here's a nice list of quotes from relevant people: http://harmful.cat-v.org/software/OO_programming/A warning the site is full of very extremist opinions in more than just software, something that is interesting because!it makes you think. What you forgot to mention is that most software is created to be used by people and that's where OOP really shines. Procedural programming is mostly used for system level programming (people hardly interact with kernel drivers directly) and functional programming is used for highly theoretical academic stuff (math proofs) and multi-threaded/asynchronous systems (telecoms come to mind). The vast majority of software that is being built though are applications that require user interaction (games, websites, ERP systems etc.) and those benefit greatly from this "dreadful domain approach". Sure, you probably could do it "the proper way" (like people who are trying to build website frameworks in Haskell, LOL), but you must realize that the demand for such software is so high that there's constantly a shortage of developers. If you were to raise the barrier of entry to people who have at least PhD in maths and are fluent in functional programming then nothing would get done. It's a compromise, you get less reliable systems but can build them much easier and faster (and worry about making them reliable later down the line) because what's the most important in programming is actually getting shit done, not making sure that it's "pure" or "proper". Weren't you against OOP in the past? Have you changed your mind?
I was not against OOP  I started programming with LPC then moved on to PHP and now Ruby. How could I be against OOP?
I'm just against C++ in general and Java pre 8 (and even after that I'm not super fond of it). That's just a personal preference based on how ugly code in those languages looks most of the time.
|
I don't enjoy OOP, but I have to imagine that when a project becomes sufficiently large, OOP has some big advantages. It would seem to me that well written OO code is largely self-documenting, which is probably incredibly advantageous for big teams or situations where you don't know who is going to have to mess with the code in the future.
But what do I know, I have never actually worked on projects of that scale. So feel free to shit on me if I am way off base.
|
On December 09 2017 07:17 travis wrote:
I don't enjoy OOP, but I have to imagine that when a project becomes sufficiently large, OOP has some big advantages. It would seem to me that well written OO code is largely self-documenting, which is probably incredibly advantageous for big teams or situations where you don't know who is going to have to mess with the code in the future.
But what do I know, I have never actually worked on projects of that scale. So feel free to shit on me if I am way off base.
You're pretty much on point. When a project becomes sufficiently large, it's impossible not to use OOP. Imagine trying to mix git pushes when everyone is working on the same bits of code.
edit: and, of course, since you can't always know how large your project is going to end up, or who's going to work on it afterwards, OOP should always be a consideration from the very beginning.
|
On December 09 2017 07:17 travis wrote:
I don't enjoy OOP, but I have to imagine that when a project becomes sufficiently large, OOP has some big advantages. It would seem to me that well written OO code is largely self-documenting, which is probably incredibly advantageous for big teams or situations where you don't know who is going to have to mess with the code in the future.
But what do I know, I have never actually worked on projects of that scale. So feel free to shit on me if I am way off base.
OOP has a structure or patterns if you want. People can learn them, so it's a bit easier when you come across new code. When you have procedural code, I'm not sure you can tell that easily - you have functions all over the place in lots of files... Then again, I don't do procedural programming a lot - it's only one-off for me in most cases.
As I said previously, I don't know how you're even supposed to implement data structures without using classes (structures). It's in the name. So, if you're from academic background, you should be fine with OOP.
Also, BIG advantage of OOP is it can hide all the unnecessary details from you. Do you really want to mess with balanced tree's pointers to keep your tree balanced? Even if you balance it with helper functions in procedural code, the fact that pointers are still exposed lets other people break your data structure's internal data. Do you really want to get involved with that? It's very easy with OOP, you make such data private. You hide unnecessary complexity.
|
OOP means a lot of different things to people and the dislikes directed towards it, is not about encapsulation. Encapsulation is generally considered good. Though to be honest, encapsulation predates OOP and is present in the C system API for example.
The problem with OOP (in most of the languages) is that it only allows one form of polymorphism: sub-typing. Combine it with mutable methods and you get class hierarchies that are deep and illogical.
|
On December 09 2017 11:08 Hanh wrote:
OOP means a lot of different things to people and the dislikes directed towards it, is not about encapsulation. Encapsulation is generally considered good. Though to be honest, encapsulation predates OOP and is present in the C system API for example.
The problem with OOP (in most of the languages) is that it only allows one form of polymorphism: sub-typing. Combine it with mutable methods and you get class hierarchies that are deep and illogical.
That's why with most of the modern languages you should favor composition over inheritance. This allows you to keep things nicely modular and simple enough without the need to resort to deep class hierarchies.
Nowadays, you don't even really need abstract classes that much since most languages have adopted ways to go around that (Ruby modules or PHP traits for example). Anyway, some inheritance isn't always bad if it's going to make your code more understandable.
For me, the biggest advantages of OOP are:
1. structuring your code in a manner that's easily approachable
2. all of the reusable patterns that make both onboarding and jumping into other projects much easier
|
What others said. Where I work, at least half of my team would struggle way more with functional languages than the kinda-OOP C# we use (our OOP could be so much better too). We wouldn't get shit done. It certainly makes sense to incorporate functional approaches in some places, and keeping mutability in check is also a concern, especially with the rising need for multithreading. But at the end of the day, things need to get done.
|
The bottom line is: You shouldn't restrict yourself to a single paradigm. Use the best tool for the job. Some things require procedural approach, some functional and some object orientation. In my opinion, any language that doesn't support all of them is too narrow and will only find niche usage.
|
On December 09 2017 17:46 spinesheath wrote:
What others said. Where I work, at least half of my team would struggle way more with functional languages than the kinda-OOP C# we use (our OOP could be so much better too). We wouldn't get shit done. It certainly makes sense to incorporate functional approaches in some places, and keeping mutability in check is also a concern, especially with the rising need for multithreading. But at the end of the day, things need to get done.
Mutability isn't difficult in C++. You just pass objects by const reference. I don't know how C# would do it though.
On December 09 2017 11:08 Hanh wrote:
OOP means a lot of different things to people and the dislikes directed towards it, is not about encapsulation. Encapsulation is generally considered good. Though to be honest, encapsulation predates OOP and is present in the C system API for example.
The problem with OOP (in most of the languages) is that it only allows one form of polymorphism: sub-typing. Combine it with mutable methods and you get class hierarchies that are deep and illogical.
Encapsulation in C? How? Hiding functions in .c files instead of .h? Forward declarations? I can't think of anything else.
|
|
|
Forward declaration. You could have just confirmed.
|
On December 10 2017 02:34 sc-darkness wrote:Forward declaration. You could have just confirmed.
Thought I'd leave some more elaboration on that for anyone interested in the topic
Anyway, it seems really artificial and forced. I'd really like for C to include maybe not classes but something similar to Ruby modules. Those could act as a form of namespaces. What I'd add is also the ability to declare function visibility, that would help immensely (private, public and final would suffice).
|
I'm following this guide to do a little bit of C# experimentation and they have a member in their ValuesController that has... functions? Could someone explain to me what it actually is? I don't know what keywords to use to search it.
namespace WebDemo.Controllers
{
public class ValuesController : ApiController
{
private string[] lista
{
get
{
if (System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"] == null)
{
System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"] =
new string[] {"<em>\"value1\"</em>, <em>\"value2\"</em>"};
}
return
(string[])System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"];
}
}
}
}
|
On December 10 2017 06:43 WarSame wrote:I'm following this guide to do a little bit of C# experimentation and they have a member in their ValuesController that has... functions? Could someone explain to me what it actually is? I don't know what keywords to use to search it.
namespace WebDemo.Controllers
{
public class ValuesController : ApiController
{
private string[] lista
{
get
{
if (System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"] == null)
{
System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"] =
new string[] {"<em>\"value1\"</em>, <em>\"value2\"</em>"};
}
return
(string[])System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"];
}
}
}
}
Personally, I call it C# property because that's how it's called in Objective-C. It's syntactic sugar for getters and setters.
However, the aim is to reduce boilerplate code. Are you familiar with getter and setter methods? This is all it is.
Edit: There you go: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
Of course, you're also free to do the following.
private String[] lista;
public String[] getLista()
{
if (System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"] == null)
{
System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"] =
new string[] {"<em>\"value1\"</em>, <em>\"value2\"</em>"};
}
return (string[])System.Web.HttpContext.Current.Application["<em>\"lista\"</em>"];
}
It's definitely weird they declare a variable when they don't seem to use it in the usual way. I don't know about this HttpContext stuff though.
Also, you can use access modifiers for get/set. You can say "private set { something }".
Here is an example: https://stackoverflow.com/a/3847982/1091781
|
Thank you! I had heard of that idea earlier but forgotten how C# implemented it.
|
You're welcome! Ignore my previous manually defined getter. I forgot to remove get {} syntax, haha. It should be fine now.
Edit: I've just done a bit of "object-oriented" C with struct. While it's fun as an exercise, people are right when they say you end up rewriting what C++ does. Conclusion: use C++. :D
|
On December 09 2017 22:46 sc-darkness wrote:Show nested quote +On December 09 2017 17:46 spinesheath wrote:
What others said. Where I work, at least half of my team would struggle way more with functional languages than the kinda-OOP C# we use (our OOP could be so much better too). We wouldn't get shit done. It certainly makes sense to incorporate functional approaches in some places, and keeping mutability in check is also a concern, especially with the rising need for multithreading. But at the end of the day, things need to get done. Mutability isn't difficult in C++. You just pass objects by const reference. I don't know how C# would do it though.
Sadly C# lacks proper const semantics like C++ has them. The best you can have is make your fields readonly. Which is just the references, not the actual instances. So you have no reliable way of knowing if an object is immutable. Obviously if people don't changes state in getters and name methods properly, things get better. But there's a lot more convention involved than necessary in C++.
|
On December 09 2017 22:46 sc-darkness wrote:
Mutability isn't difficult in C++. You just pass objects by const reference. I don't know how C# would do it though.
In C++, "const" controls access to the resource but the resource remains mutable. In other words, the data could be mutated through another reference. Practically, const is more trouble than what it is worth especially when working with 3rd party libraries that do not use constness.
|
On December 10 2017 19:53 Hanh wrote:Show nested quote +On December 09 2017 22:46 sc-darkness wrote:
Mutability isn't difficult in C++. You just pass objects by const reference. I don't know how C# would do it though.
Practically, const is more trouble than what it is worth especially when working with 3rd party libraries that do not use constness.
I think you're a minority here. Most C++ developers appreciate const correctness. Yes, sometimes you can't pass a const reference but there will always be such cases even with your own C++ classes.
|
On December 10 2017 20:40 sc-darkness wrote:Show nested quote +On December 10 2017 19:53 Hanh wrote:On December 09 2017 22:46 sc-darkness wrote:
Mutability isn't difficult in C++. You just pass objects by const reference. I don't know how C# would do it though.
Practically, const is more trouble than what it is worth especially when working with 3rd party libraries that do not use constness. I think you're a minority here. Most C++ developers appreciate const correctness. Yes, sometimes you can't pass a const reference but there will always be such cases even with your own C++ classes.
I mean it's not that difficult to just clone a const variable before passing it if that's needed. That said I rarely use it myself. It's not that difficult to keep track of a variable and just not set it again if you need to. And if it can be defined before compile I just use #define instead (That said I don't really have an opinion on the subject. It's more preference than anything else).
|
|
|
|
|
|
EPT
