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

Black Triangles (2014)

rampantgames.com

Post reply on HN
Print view View original

31–40 of 79 posts

Re: Black Triangles (2014)

#31

Post by 0xfffafaCrash »

One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times in favor of shiny demo projects that demo well but can never go much further. Black triangle projects require time investments that at least big companies only rarely bet on despite being in possibly the best position to do so.

I think a part of it is that humans, or at least those that make their way into management, are in large part very visual creatures. If you can’t show them progress in a traditional visual way you sort of have to figure out some contortion to show some visual thing to use as a proxy of progress to keep the faith. Sometimes it can be achieved through selling some abstract progress metrics about work remaining (most often entirely detached from reality) but that only works so long.

More often you end up knowingly spending a large percentage of resources on vacuous side projects solely because they demo well to management in the short term — it’s a distraction but a way to keep the faith and the resources. I find it funny how much time and energy we’re willing to waste to play the game — paying the souped up visual taxes for decision makers, while doing the real work independently, often in the dark because we know management will react short sightedly to the black triangles.

Re: Black Triangles (2014)

#32

Post by johnnyanmac »

therealcamino wrote: post #21
mensetmanusman wrote: post #18

Earlier quoted context omitted.

[flagged]

Nobody owns it, obviously. It can be helpful however to be aware of the associations your terminology already has. From a practical perspective, it interferes with getting your point across to overload a symbol that already has strong associations. From a social perspective, it's considerate not to use symbols that have strong negative associations for others (which is not a view shared by the "fuck your feelings" cr…

On the other hand, if you go into history deep enough you'll find symbolism for any and everything being a hate symbol. The okay hand emoji Of all things had a controversy so nothing is safe.

Triangles are the most basic shape available so you'll find any and all kinds of symbols to represent good and bad things. I don't think it's very productive to worry about how it was used 70 years ago unless you're talking to a very old person.

Re: Black Triangles (2014)

#33

Post by jacquesm »

ianbutler wrote: post #29
jacquesm wrote: post #7

Earlier quoted context omitted.

I like such projects. They're the programming equivalent of making jewelry. Is your code public?

Thanks for your interest! It was definitely rewarding though I’m sure I can optimize a few things still. The code is public: https://github.com/iantbutler01/dart

Neat, thank you. I will give it a read later tonight.

Re: Black Triangles (2014)

#34

Post by y-curious »

segfaultbuserr wrote: post #11

> It wasn’t just that we’d managed to get a triangle onto the screen. That could be done in about a day. It was the journey the triangle had taken to get up on the screen. If anyone wants to experience something like that today, just follow an introductory tutorial on Vulkan programming. Vulkan is a programming model that gives so much low-level control directly to programmers. As a result, this "Hello Triangle" exam…

Thanks for sharing this, I was thoroughly tickled. The optimistic tone of the tutorial stands in stark contrast of the convoluted path to drawing an object.

Re: Black Triangles (2014)

#35

Post by fingerlocks »

segfaultbuserr wrote: post #11

> It wasn’t just that we’d managed to get a triangle onto the screen. That could be done in about a day. It was the journey the triangle had taken to get up on the screen. If anyone wants to experience something like that today, just follow an introductory tutorial on Vulkan programming. Vulkan is a programming model that gives so much low-level control directly to programmers. As a result, this "Hello Triangle" exam…

If you RTA, that’s a perfect example of drawing a black triangle versus “A Black Triangle Moment”.

That tutorial is a general overview of all the possible boilerplate you would expect to see in a template project, and just happens to end in a triangle being drawn on the screen.

You could skip a lot of those steps. Is that 5 page section on constructing validation layers and fine tuning the debugger really necessary if your end goal was a triangle?

You can draw a triangle in Metal in thousands of lines of code too. And it’s common to have several hundred lines of pipeline descriptors, buffer management, and debug tooling before you even started encoding into your shaders. But it’s not necessary for _just a triangle_.

Re: Black Triangles (2014)

#36

Post by avg_dev »

sitkack wrote: post #28
cybrexalpha wrote: post #23

So this is a 10-year old repost (2014), of an original article 10-years older than that (2004), describing and event that happened ten years before that (1994)?

I am looking forward to seeing this post in 2034!

tbh, i personally think the article is timeless and beautiful

Re: Black Triangles (2014)

#37

Post by [deleted] »

0xfffafaCrash wrote: post #31

One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times…

[deleted]

Re: Black Triangles (2014)

#39

Post by ryandrake »

0xfffafaCrash wrote: post #31

One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times…

I've worked in places where management understood the idea of laying a foundation, and building up the abstractions and information architecture, and understood that the result of the first 50% of the project could be a single text log showing all the data paths working, but those companies are rare. Most places are like you said: they won't believe any work is happening until they are bamboozled by a visual demo of the software--and they think it's "close to done" when the visual demo matches what they think the software should eventually look like. That's why so many places ship unfinished demo-ware: Engineering shows off the proof of concept that only scales to 10 customers and doesn't actually write to the database, and then management demands they ship it because it looks done and the deadline is coming up.

I wish I could figure out, as a candidate, a good question to ask in order to suss out which kind of company is interviewing me.

Re: Black Triangles (2014)

#40

Post by ryandrake »

dahart wrote: post #25
ReactiveJelly wrote: post #10

Earlier quoted context omitted.

I don't consider it an OS if it needs an OS to run. Something like a "Ship can carry a boat, boat can't carry a ship" rule.

Have you written a serious game engine? Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS ( if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling, that counts as Operating System. This is becoming less true today, as the hardware gets better and bigger and faster and resources are less constrained, but it wasn’t…

> Parent is right, a bunch of them basically are a real-time OS sitting on a small amount of the underlying OS (if one exists). When you have to write your own malloc() and fopen(), and your own thread scheduling,

I don't doubt that game developers do this, but I've never really heard a satisfying reason why, besides vague hand-waving about "needing more performance". I'm not a game developer though, so maybe it's truly needed. Or maybe it was needed in the 80s and 90s but not anymore, and maybe the mentality is simply stuck in the minds of game developers.

I remember interviewing a former game developer at a [not game] company, and we started talking about the C++ Standard Library. Candidate insisted that "the STL is slow," and that you shouldn't use it in any production software, and that if he worked on a project that used it, the first thing he'd want to do was re-write it using his own containers and allocators and so on. I would ask him questions like "what is slow about it" and "how do you know where it's slow, as used in our company's application" and "have you profiled any code that used it to find out where it's slow" and so on, and it became clear (to me) that he was probably just operating out of some ancient tribal believe that "STL = slow" that was organically passed on to him from other game developers throughout the decades.

Post reply on HN