Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I was wrong, reflecting on the .NET design choices

ayende.com

Post reply on HN
Print view View original

91–100 of 139 posts

Re: I was wrong, reflecting on the .NET design choices

#91

Post by Jach »

sqeaky wrote: post #83
nickbauman wrote: post #76

Earlier quoted context omitted.

I have many years of programming in Java under my belt. Until I started using dynamic languages I thought static typing was really important. It's not.

It rules out certain categories of bugs, makes it hard to assign a string to an int, etc... If you are writing a small one time use script to accomplish a task clearly this that kind of protection is of low value. If you are trying to write or maintain a system intended to last 20 years and keeps bugs out of 100 millions lines of code, every kind of check that can be automated has extremely high value. Most projects…

Simple designations like "static typing" and "dynamic typing", even when you bring in the concept of strong vs. weak (Java allows concatenating an int to a string, Python throws an error), aren't very helpful when languages like Common Lisp exist. (Edit: nor "compiled" vs. "interpreted" either for the same reason but especially in current_year when just about everything compiles to some form of bytecode, whether that is then run by assembly or by microcode running assembly a small distinction.) Specific languages matter more, specific workflows within languages matter more too. And as you say what you're trying to build also matters, but not all that much.

Re: I was wrong, reflecting on the .NET design choices

#92

Post by hyperpape »

MichaelGG wrote: post #67
hyperpape wrote: post #41

Earlier quoted context omitted.

This may be true in general, but the CLR uses bytecode and a JIT compiler, so that point may be a lot less relevant to it. In addition, devirtualization is apparently valuable enough that they're going to add it to the CLR, per the article.

Java compiles to bytecode and most implementations JIT, just like .NET. JVMs are more advanced than the CLR at optimization.

Yes, my point is that once you're comparing two environments that use bytecode and a JIT, you can't necessarily cite the cost of startup time and the cost of JIT compilation as a reason to avoid possibly-virtual calls.

Re: I was wrong, reflecting on the .NET design choices

#93

Post by dragonwriter »

nickbauman wrote: post #76
dahart wrote: post #7

> However, given that I’m working on a database engine now, not on business software, I can see a whole different world of constraints. This might be my own confirmation bias, but this is my takeaway: point of view and the constraints that you see or believe are there are the main determinant of choices, and not whether some particular pattern or feature of a language is intrinsically good. The older I get and the mo…

I have many years of programming in Java under my belt. Until I started using dynamic languages I thought static typing was really important. It's not.

> I have many years of programming in Java under my belt. Until I started using dynamic languages I thought static typing was really important. It's not.

Static typing is useful, especially in large projects, if it provides the right guarantees.

OTOH, whether it does that depends on the type system. Go, Java, Pony, Rust, and Haskell are all static, but their type systems offer very different capacities. If you have a type system that has a lot of ceremony, and fails to provide the guarantees that are actually needed in your project, it's a pure burden. If it's low-ceremony and provides guarantees important to your project, it's a clear, undiluted benefit. Reality often falls somewhere in between.

Re: I was wrong, reflecting on the .NET design choices

#94

Post by specialist »

jasode wrote: post #4

If I attempt to generalize it, I think most of C#'s differences in language design that have opposites in Java are superior. Examples include: + not virtual by default (so base classes can be changed more easily without breaking/recompiling downstream clients that the base class writer doesn't know about; specifying something as "virtual" should be a deliberate conscious decision by the class author) + value types (f…

Java's virtual by default methods has never been an issue for me. On the other hand, some clown making their classes and methods final has been a recurring thorn.

David Bacon's Kava's approach to lightweight objects remains the correct answer and is sorely missed.

The only case for unchecked exception is mitigating terrible design choices. Like using Spring or Hibernate/JPA. When the client code can't do anything with a caught exception, it shouldn't even be thrown. Meaning, they're doing it wrong.

The omission of signed integers has caused me unnecessary pain a few times. Original bindings for OpenGL, a DICOM parser, etc.

--

Properties are the one C# feature sorely missed in Java. JavaBeans is silly.

Syntactic sugar for reflection would be nice, maybe something like 'Method m = myClass#myMethod( String )'.

Java has done plenty of terrible things, crimes against productivity and design rationality. Chiefly annotations, lambdas, and the silly Optional. C#'s equivalent quixotic fever dream is probably LINQ.

I have a laundry list for Java, JDK (especially), and JVM. Who doesn't? Mostly undoing bad ideas and culling deprecated stuff, plus some sugar to reduce the verbosity.

--

Unfortunately, Java's language is hard to separate from its culture. The taint of all the enterprise minded stuff (XML XSD etc, J2EE, Spring, excess indirection caused by design pattern newbies) has been hard to shake off.

Re: I was wrong, reflecting on the .NET design choices

#95

Post by acchow »

skybrian wrote: post #86
sqeaky wrote: post #80

Earlier quoted context omitted.

Garbage collection is the bane of smooth framerates. Players notice when the framerate drops. Presuming a pretty typical 60 Frames Per Second you have a tight 16.6ms time budget to do all of the work for the entire frame. All of the physics, all of the sound processing, all of the AI and everything else needs to be sliced up into little bits that can be distributed across the time the game is played. There are many g…

I wonder if the very low-latency GC in Go would be good enough, though? The occasional dropped frame doesn't seem like the end of the world, so long as it remains rare. In practice, most games don't have entirely reliable performance, particularly on low-end hardware.

Gamers hate dropped frames. They can also easily ruin multiplayer games.

Re: I was wrong, reflecting on the .NET design choices

#96

Post by paulddraper »

emodendroket wrote: post #78
rjeli wrote: post #51

Earlier quoted context omitted.

I like type erasure and depend on it a lot for Scala and Clojure interop. Any JVM language works with the same objects and methods, and can implement its own type system/syntax on top.

That's true in the clr too as long as everything supports generics.

Things that have CLR-like generics work on the CLR. Anything else doesn't. E.g. Scala.

Re: I was wrong, reflecting on the .NET design choices

#97

Post by OniBait »

psyc wrote: post #56
klodolph wrote: post #13

Java and C# are seen as "old news" by some here on HN but there's a trove of software engineering wisdom in there. It was a huge boon for Microsoft to be able to learn from Sun's mistakes when they were designing a language that, on paper, is basically the same thing. C#, Java, and Go are all "wonderfully boring" languages which is a divisive topic, but they're all very good at being boring languages. It's not just l…

As a low-level game dev, I consider C# a nearly perfect, wonderful language, tragically self-defeated by garbage collection.

You can use things like System.GC.TryStartNoGCRegion and GCLatencyMode.SustainedLowLatency to help mitigate the GC pauses though. There is a lot of work that has been going on with the CLR GC code somewhat recently.

Re: I was wrong, reflecting on the .NET design choices

#98

Post by jameslk »

matchagaucho wrote: post #52

"Another issue is that my approach to software design has significantly changed. Where I would previously do a lot of inheritance and explicit design patterns, I’m far more motivated toward using composition, instead." This, more than anything, has dramatically improved the quality of my designs... and made coding fun again. Immutability and Lambda functions have also had a tremendous impact on my designs. Is the ter…

I don't see how preferring composition over inheritance makes OOP less relevant. In fact, GoF even suggests using composition over inheritance in OOP. Nor do I see how immutability and lambda functions are mutually exclusive to OOP either. You can have all of these things and still reap plenty of benefits from OOP. The benefits of OO polymorphism and several decades worth of architectural design patterns are not irrelevant just because functional programming concepts exist. Both should be used advantageously and when appropriate.

Re: I was wrong, reflecting on the .NET design choices

#99

Post by sqeaky »

Jach wrote: post #91
sqeaky wrote: post #83

Earlier quoted context omitted.

It rules out certain categories of bugs, makes it hard to assign a string to an int, etc... If you are writing a small one time use script to accomplish a task clearly this that kind of protection is of low value. If you are trying to write or maintain a system intended to last 20 years and keeps bugs out of 100 millions lines of code, every kind of check that can be automated has extremely high value. Most projects…

Simple designations like "static typing" and "dynamic typing", even when you bring in the concept of strong vs. weak (Java allows concatenating an int to a string, Python throws an error), aren't very helpful when languages like Common Lisp exist. (Edit: nor "compiled" vs. "interpreted" either for the same reason but especially in current_year when just about everything compiles to some form of bytecode, whether that…

You are right that the type system waters are muddied by a variety of technologies and perhaps that isn't the best line to draw. I think your focus on the semantics of static vs dynamic dodges much of my point.

The crux of my argument was the larger and more complex the work the more important it is to find errors early. It seems obvious to me that languages like Java, C++ and Rust do much more to catch errors early than languages like Ruby, Python and Javascript which are easier to get started with and make a minimum viable product. Put those two things together and it seems like strong heuristic to use when starting a project.

Re: I was wrong, reflecting on the .NET design choices

#100

Post by le-mark »

ska wrote: post #14
oop17 wrote: post #11

One of the greatest lingering flaws in both C# and Java is the lack of metaclasses. Because classes aren't real objects and therefore not necessarily also instances of other classes (their metaclasses) as they would be in Smalltalk, there is no class-side equivalent of "self/this," nor of "super." In effect, you cannot write static (class) methods that call other static methods without explicitly referencing the clas…

Whatever the reasons behind it, it is clear that a lot of the effective and high impact industrial languages at various levels of the stack (e.g. c++, ada, Java/C#, python, perl, javascript,etc.) have not managed to incorporate some of the real wisdom learned in earlier systems (e.g. smalltalk an some lisps for OO, etc.) If this was in fact avoidable, it is a sad fact.

This type stupid bloviating is why programming will never be a proper engineering discipline. There are two ways to implement oop: classes aka "object templates" or prototypes. Educate your selves people!
Post reply on HN