Live data from Hacker News

Notch, WebGL, Dart, and ramping up quickly

blog.tojicode.com

191–200 of 204 posts

Re: Notch, WebGL, Dart, and ramping up quickly

#191
post #159

Earlier quoted context omitted.

Well if we're singling out maintenance programmers, lets also talk about programmers who use "maintenance" as a dirty word. They tend to be the type to vomit out whatever immediately comes to their head and ship when it just barely works, with no thought or consideration for maintainability. Because, hey, they're going to move on to their next project anyway, and "getting things done" in the short term is far more im…

There is a middle area here, where one doesn't worry about perfect code, but still takes a moment to consider design. Who said otherwise? The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted. Yet he did build a large product from nothing, that has provided millions of hours of enjoyment to user…

>Who said otherwise?

Apparently a lot of HN posters. Looking at the siblings, you see the exact circle-jerk I criticized: "Only launching matters. Builders are so much smarter and more talented than maintainers. Code quality is a secondary concern that can be addressed later." And lets be honest, your comment itself did not really hint at any sort of balance -- it was highly insulting to anyone not writing code from scratch. "... tosses to feel better about themselves as they try to feed the family with sloppy seconds." Really? REALLY? That's horribly dismissive to anyone who has to work in an existing code base. Its shamefully dismissive.

> The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted.

Said poster did not make the claim solely on the lack of mod-ability, but also on things like poor use of OpenGL APIs and extreme duplication of code. Some point between version 0.1 and release, one should take a step back, refactor, and clean up with an eye for maintainability.

Also, the fact that something is version 0.1 is not really an excuse for things like writing code that duplicates functionality. Its entirely possible to write an initial version that has passable code quality -- I've done it many times (and had coworkers comment on how easy it was to maintain). You just have to keep in mind that if you're writing throwaway code, it must be thrown away, and if that's not acceptable that you need to spend a little extra time on a maintaining a minimum level of quality.

> And yes, there is a type of maintenance programmer that I will absolutely disparage. It is the perpetually over-their-heads developer who is always surrounded by purportedly terrible code because it doesn't have a "insert your specific need here" structure.

Said programmers are often interested in improving the quality of the code-base. Your disparagement is misplaced. They are the people that take an unmaintainable mess and mold it into a reliable system. But of course, since the work" is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident" that's work that anybody can do. And that statement is not horribly dismissing and insulting at all. Right.

I've had more sleepless nights due to "special snowflake" developers than the maintenance programmers you disparage.

Re: Notch, WebGL, Dart, and ramping up quickly

#192
post #163

Earlier quoted context omitted.

I guess it's a balance between over and under-engineering. The thing is, more often that not the person coming along to do 'external modifications' to that code is actually you, a few months after you wrote it. You can adopt some good coding practices that ensure that the code isn't a spaghetti mess that's hard to understand when you come back and look at it. That's different than designing a system to be pluggable f…

As you build and explore, you find patterns, see repetitive code, or get frustrated at the hassle it takes to add a new feature. This is when you refactor. It's that moment of realization when coding and you say to yourself "ah, if I had a compositional object model instead of a god object inheritance nightmare I could introduce new objects so much faster and without destroying the interface of CEntity." You quickly…

>What's necessary about being great? Nothing, but being great is Awesome.

Not really. It's rather pointless, time consuming, and often deleterious to one's work/life balance. Not to mention it can mean that the end result might never ship at all, in an endless pursuit of "greatness".

Re: Notch, WebGL, Dart, and ramping up quickly

#193
post #151

Earlier quoted context omitted.

> Not sure what the CS curriculum is in other countries but back where I'm from they had basically taught us enough by the middle of the second year for one to be able to design something like DCPU16 using only that knowledge. Same with us. That doesn't mean that 90% of the graduates out there, that even have taken such as class, will be able to do it. Heck, a surprising majority of them (like 30% or more), even fail…

A majority of 30% of more?...

Non native speaker meets pedantic distinction.

Replace majority with slice/share/percentage what have you.

Re: Notch, WebGL, Dart, and ramping up quickly

#194

Earlier quoted context omitted.

There are lots of problems with it. Here are a couple: He uses poor OpenGL practices, and sees poor performance as a result. He also designed the entire product in a way that makes it cumbersome to mod, without a consistent interface or a logical way for mods to work together. Modding Minecraft as a whole is one big hack. I'm more familiar with the networking side of things. The Minecraft networking protocol is a mes…

Could you provide more specific examples and possibly detail how you would do it better? If Notch is making these errors you speak of, other programmers probably are too. You've got the perfect platform here to correct the problem.

It's very simple:

-Don't make up things where existing tech would do (ala NBT, entity metadata, etc)

-Don't use a signed number if negative values don't make sense in that context

-Include versioning if something needs to work across versions

-Choose consistent scemantics for data encoding (and anything else you can)

All of this will make it easier for you, too. Focus on reducing internal code reuse, maximizing external code reuse, and simplifying things.

Re: Notch, WebGL, Dart, and ramping up quickly

#195

Earlier quoted context omitted.

Your post has many implied dichotomies and correlations that simply aren't true. For example: I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed Not really. It simply shows that bad software is commonplace and often not important enough factor to kill an entire company. It still costs compa…

FYI - You replied to the wrong post. I'll just leave it at this -- despite protestations to the contrary, I would wager that the majority of developers, if not the overwhelming majority of developers, claim to do no wrong when coding. They claim to plan and design and develop with best practices, creating clean, maintainable code. And those same developers almost universally declare the majority of code they come in…

This reminds me of how some people argue that morality is hard, because everything is relative, while doing thing they themselves clearly do not consider "right".

Aside from a few inexperienced or delusional engineers, most people I've seen in my professional life are cognizant of the quality of code they produce. The main difference is in how they respond to the cases when that quality dips below a certain level.

Re: Notch, WebGL, Dart, and ramping up quickly

#196
post #168

Now I feel bad for slowing up my current pet project by getting bogged down writing polygon collision detection when axis aligned bounding boxes would have done for prototyping. (I'm not as quick as Notch!)

Well, this can actually have a pretty significant effect on the feel of the game so depending on what kind of game you were prototyping, it might be worth it (though, your better off hardcoding a few cases of SAT than trying to get it working completely generally in a prototype).

How would one hard code SAT cases? Just curious I've got the general code working now.

Re: Notch, WebGL, Dart, and ramping up quickly

#197
post #11

Now I feel bad for slowing up my current pet project by getting bogged down writing polygon collision detection when axis aligned bounding boxes would have done for prototyping. (I'm not as quick as Notch!)

My understanding is that usually you want both because AABB is good for broad-phase because it's so quick then true polygon collision can be done in a narrow phase.

Absolutely.

Re: Notch, WebGL, Dart, and ramping up quickly

#198
post #177
post #124

Earlier quoted context omitted.

Notch tweeted this in, I'm assuming, response to this thread: > "Just saw a nerd flamewar debating if I'm a bad programmer. I'm self-taught, prefer working along, and program for fun. Don't learn from me." Take it for what you will. https://twitter.com/notch/statuses/408011329237049344

Does he mean "alone"?

Yes.

Re: Notch, WebGL, Dart, and ramping up quickly

#199
post #163

Earlier quoted context omitted.

As you build and explore, you find patterns, see repetitive code, or get frustrated at the hassle it takes to add a new feature. This is when you refactor. It's that moment of realization when coding and you say to yourself "ah, if I had a compositional object model instead of a god object inheritance nightmare I could introduce new objects so much faster and without destroying the interface of CEntity." You quickly…

> What's necessary about being great? Nothing, but being great is Awesome. Not really. It's rather pointless, time consuming, and often deleterious to one's work/life balance. Not to mention it can mean that the end result might never ship at all, in an endless pursuit of "greatness".

Sure. My whole point is you have to believe its the right thing, and be good enough to execute on a large refactor like that without getting stuck in the never-ship mud, or endless pursuits.

Being great is overcoming the reasons you are giving not to do it. Being great is having the vision to see how these decisiosn impacts your ability to deliver in the future.

Being great isn't necessary. And you've pointed that out. Your attitude ensures that the code you write meets your standards. Your standards, aren't "great."

Post reply on HN