Hacker News Reader

Comment by rednafi | Hacker News Reader

C# is a nice language, but it has a huge surface area in terms of syntax. Also, Microsoft’s past behavior makes a lot of people avoid it entirely before even considering it.

Plus, many, like myself, just don’t want to write OO code, no matter what. I simply don’t want to spend my time working that way. This makes hiring difficult, especially when many young engineers who start their careers with non-OO languages instinctively shy away from Java-esque languages.

That said, I welcome language diversity in the backend and love that new startups no longer default to Node. I’d rather deal with OO than fiddle with a poorly designed language that was never meant for anything but throwaway frontend code.

View on HN

>C# is a nice language, but it has a huge surface area in terms of syntax.

If you compare it to something like Java, yes, it has much richer syntax. But having to process some extra unfamiliar syntax is compensated by removing a lot of boilerplate once you get familiar with the features. Also, Java's simpler syntax is far overshadowed by much bigger complexity and cognitive load in other areas of the Java project, including the entire plumbing besides the code itself. Ergonomics, simplicity and comfort of a .NET Core project infrastructure is pretty much unmatched.

Can’t argue with this. .NET is like RoR or Django, just more tightly integrated. The dev experience is better than Node with its thousand dependencies or even Python at times—with its better type system but a zillion ways to manage dependencies.

However, I was mostly talking about the cognitive load that comes with a large syntax surface and GoF-style OO, and how starting with something like Go is just easier.

Java nowadays basically means Spring Boot. Which is just best practices anyway. And every Spring Boot project looks the same. It's boring and it works. So from a technological standpoint, it doesn't really matter which one you choose. .NET might have an advantage here and there, but for my taste they are trying a bit too hard to sell me their cloud stuff.

> Plus, many, like myself, just don’t want to write OO code, no matter what.

There's a good pluralsight course by Zoran Horvat called, "Writing purely functional code in C#" ( https://www.pluralsight.com/courses/writing-purely-functiona... ), where he explores exactly that.

Modern C# has added a bunch of things which means you don't need to write it in the OOP style, although if you find yourself working for others then OOP is what they'll likely expect.

Wait, why would you not write F# then? I assume that's explained in the course, but could you summarize the reasons?

This leaves very few mainstream languages left like C available, as everything else does support some form of OOP, regardless of the shape it is exposed on the programming language type system.

OOP is not going away from mainstream.

Most modern codebases in Node and Python are devoid of OO—at least in the ones I’ve worked on over the last half-decade. Go is mainstream now too, and it doesn’t even allow writing OO code.

People love Python because it’s still one of the easiest languages to start with, as it doesn’t force any particular coding style on you. Underneath, it supports a bastardized version of OO, but it doesn’t care if you just use simple types and pass them around to mostly free-floating, stateless functions. This is how startups write Python anyway.

Add a huge ecosystem of libraries and a fairly well-designed type system, and you’ll appeal to a ton of people—despite being quite sluggish. C# and Java struggle to attract this crowd, which is gradually becoming the majority as the industry ages.

It is impossible, when Python and JavaScript have OOP concepts as integral part of their basic types.

Go is also a OOP language, regardless of how people without CS degrees fool themselves it is not one.

Not having inheritance one OOP language doesn't not make.

By definition they are OOP languages, and anti-OOP folks could do better learning about type systems.

This sounds like the pedantry FP folks are infamous for. By definition, Rust is also OO.

But I’d rather write Python, Node, Go, or Rust in a bastardized, data-oriented, faux-OO way than deal with GoF-style OO in Java, Kotlin, or C#. Sure, you can write code in a non-OO way in C#, but no one does. Whereas in Python, these days, people default to a data-oriented style.

This is just how I like to program. Plenty of folks enjoy OO thinking, and I have nothing against that. But when choosing a workplace, I’m fortunate enough to be able to ask if the codebase is OO-heavy—and politely decline if it is.

Indeed, I have ported Weekend Raytracing Project from C++ OOP into Rust OOP, just fine and is available as contributions to mankind on Github.

Are you aware Python basic types like numbers and functions are objects with methods and inheritance?

    num=23
    print(num)
    print(type(num)) 
    print(dir(num))
 
    23

    <class 'int'>

    ['__abs__', '__add__', 
     '__and__', '__bool__', 
     '__ceil__', '__class__', 
     '__delattr__', '__dir__', 
     '__divmod__', '__doc__', 
     '__eq__', '__float__', 
     '__floor__', 
     '__floordiv__', 
     '__format__', '__ge__', 
     '__getattribute__', 
     '__getnewargs__', 
     '__getstate__', '__gt__', 
     '__hash__', '__index__', 
     '__init__', 
     '__init_subclass__', 
     '__int__', '__invert__', 
     '__le__', '__lshift__', 
     '__lt__', '__mod__', 
     '__mul__', '__ne__', 
     '__neg__', '__new__', 
     '__or__', '__pos__', 
     '__pow__', '__radd__', 
     '__rand__', '__rdivmod__', 
     '__reduce__', 
     '__reduce_ex__', 
     '__repr__', 
     '__rfloordiv__', 
     '__rlshift__', '__rmod__', 
     '__rmul__', '__ror__', 
     '__round__', '__rpow__', 
     '__rrshift__', 
     '__rshift__', '__rsub__', 
     '__rtruediv__', '__rxor__', 
     '__setattr__', 
     '__sizeof__', '__str__', 
     '__sub__', 
     '__subclasshook__', 
     '__truediv__', '__trunc__', 
     '__xor__', 
     'as_integer_ratio', 
     'bit_count', 'bit_length', 
     'conjugate', 'denominator', 
     'from_bytes', 'imag', 
     'is_integer', 'numerator', 
     'real', 'to_bytes']

How do use them in Python without OOP?

I’ve learned programming with OOP in Turbo Pascal, C++ and Java. Switching to a different programming style, more data-oriented, using free-floating functions, in languages such as Python, Go, or more recently Zig, has been liberating. I have inherited a C# code base and I have to say that I’m not super excited about going back to using classes and objects everywhere. It’s really hard for me now to “unsee” the problem with that unnecessary complexity.

Quite relatable. Writing a lot of Go and a bit of Rust has changed how I write Python and TypeScript. Most newcomers in startups write Python in a data-oriented manner, but that’s not the case even in new Java or C# codebases I’ve seen.

One reason I dislike Kotlin is that, despite being fairly new, Java has infected it with OO, and most Kotlin code looks exactly like Java. The whole point of Kotlin was to escape Java’s OO baggage and appeal to a new generation of coders, but it flopped hard. I guess old habits die hard, and way more Kotlin is written by Java veterans than by the younger devs it was supposed to attract.

I'm wondering if the solution to my problem could be to start using F#, which seems to encourage a data-oriented style over an object-oriented style, while staying in the same C# and .Net ecosystem. F# has a concept of modules, holding all executable code and data. They elegantly replace C# static classes, and are mapped to static classes in the CLR.

Modules come from ML linage.

https://smlhelp.github.io/book/docs/concepts/modules/

However they aren't as powerful, because ML modules are the way to do OOP like stuff, via what is called functors.

F# as .NET language naturally has other mechanisms for this, hence why it is a basic module concept, more in the linage of Modula-2 modules.

What is happened is that a guest language cannot avoid the platform ways of working.

Scala, Clojure do support OOP just as well.

Glad to know you don't make use of methods, polymorphism and dynamic dispatch in Go, Python and Typescript.

For data-oriented style you can use records, tuples and structs.

You can import all methods from a static class to use them as free-floating functions.

C# started as OO so older codebases are OOP heavy.

I still like C# more than Java and know that the language now allows you to break out of GoF-style OO. But the issue is, few people actually do, and those who want to aren’t writing C#.

> Also, Microsoft’s past behavior makes a lot of people avoid it entirely before even considering it.

I never really understood this argument. The runtime, libraries and compilers are all open source now, and all cross-platform. If MS decided to suddenly be a dick again, there is no danger of being locked in to anything.

The correct amount of OO in any language is ”as little as possible”. It’s quite possible to do this well in C#. There are levels of OO to not just on or off. E.g there is a difference between order.Process() and OrderProcessor.Process(order) and GetOrderProcessor().Process(order)

Which level of OO is correct is context dependent.

A C codebase, and a C# codebase can have the same amount of OO in it. But while its easy-ish to write Procedural or functional C# it’s quite cumbersome to write good OO in C.

It’s possible to write good code in JavaScript too; VSCode is a great example of this.

However, that doesn’t mean the language won’t fight against you. Yes, you can write data-oriented code in C# as well, but most people don’t because C# has historically been an OO language, and doing so would feel jarring to many. As a result, getting dropped into an existing C# codebase won’t be pleasant if you don’t enjoy GoF-style OO.

Go, Rust, and Zig don’t have this issue, but the latter two don’t directly compete with C#. Go does and is preferred by those who want to avoid traditional OO. That’s hard to do in an ecosystem that’s pivoting only because people are moving away from it.

It’s obviously more likely to find a C# codebase riddled with obsolete OO patterns than a Rust one.

But I think the strongest signal for that would rather be e.g the code being related to web/service backends of some kind. I much more rarely see that kind of thing in any other context (games, mobile, scientific, desktop, …).

I stay as far as possible from web stack stuff more than specific languages, but probably for the same reason.

While C# started as OO, it has become multiparadigm over the years. Even more non-OO features are planned for future versions.

Main frameworks are usually still OO based, but you can write your code on top with minimal OO style.

Big surface area in terms of syntax is not really an issue anymore as LLMs will quickly explain to you anything you don't understand about the syntax.

This is true in theory. However, Python also supports a wishy-washy version of OO, and most people don’t write code in an object-oriented style.

Modern Python in startups uses loose types and fairly stateless functions. But that’s not the case in C#. Most C# code I’ve come across is extremely Java-like, and while some people find it appealing, I prefer the Go, Rust, and Zig way of coding.

Both strategies have their place. It’s just that in the startup space, OO has fallen out of grace, and no one I know is excited about using C# to solve a novel problem. Also, CTOs always complain about how hard it is to hire for OO languages these days.

Reply on news.ycombinator.com