HN user

svdree

272 karma
Posts6
Comments44
View on HN

Pat Metheny has done something similar with his orchestrion project, 12 years ago (https://www.youtube.com/watch?v=KsYEOUKS4Yk). At the time I went to see him perform with it in the Concertgebouw in Amsterdam, which was impressive, but still missing the band energy that normally makes the music come alive. He did mention that it was the first gig on the tour without major technical issues, it does seem like a nightmare to set it all up correctly.

It's a sad moment for gamers. He started working at Sharp, where he sold solar cell and light sensor technology, but he's best remembered for a long and highly influential run at Nintendo that effectively revived the video game industry following the 1983 crash.

I'll add my packages: xdoctest and mkinit as well. Also redbaron and astunparse are nice tools when doing static analysis.

Great article nevertheless!

[dead] 6 years ago

This post is about automatic generation of programs that in turn produce creative visuals.

[dead] 6 years ago

This post is about automatic generation of programs that in turn produce creative visuals.

Why is everybody always so concerned with developer time, but never with user time? The author of this tool even complains about the startup time of photoshop, but somehow has no problem with building a tiny tool on Electron. The irony is quite strong here.

Is C++ fast? 8 years ago

That sounds reasonable, until you have to debug an issue that only manifests itself when working with a huge dataset, in which case the whole thing becomes pretty much unusable. As the article says, debug mode is expected to be slower, but the difference between MSVC and the other 2 is just crazy.

Back in university I had a side job as a security guard in an office building, when this happened. Someone took the cargo elevator, which was built to carry a higher load than the regular elevators, so it had a massive counter weight. The thing slammed into the ceiling with a bang that could be heard through the entire building, and the damage was quite extensive. Took a while for the guy to calm down as well.

Yeah, I can understand preparing for the job itself, e.g. brushing up on your financial knowledge when applying for an HFT job or something. But interviews and actual jobs seem to have diverged to the point that there is now somewhat of an industry around 'preparing for the tech interview'. It's almost like a new branch of science.

Sean Barrett (who I think popularized the idea) has a FAQ on this (https://github.com/nothings/stb) where he justifies it by pointing at difficulties with deploying libraries on Windows. Which is a fair point, but by going straight to header-only he skips the step where you can also just distribute a bunch of headers and .C files. The convenience of only having to include a single header is nice for quick weekend projects, but for anything bigger you're dealing with dependencies and build issues anyway.

I get some of the reasons that you would initially start out with a header-only implementation, but when your library grows, you probably want to split it at some point. For me personally, that point would be some time before the header reached 25k (!!) lines.

If this line of thinking ever takes off, it will be just another one of those meaningless rituals you have to go through to signal that you're part of the club. Polish your resume, dress up nicely, read 'cracking the coding interview' the night before. There might actually be a great idea for a new book in there: "How to fill up your GitHub account with random crap so future employers think you're really really passionate".

Could it be that the distance between the top and bottom 20% is less in Canada, making it easier to move from one to the other?

It's not about wear and tear. Brakes heat up when they're used, and descending an entire mountain on the brakes is likely to overheat them to the point where you have no braking power left at all. Not a good situation to be in on a steep slope. Using engine braking to keep your speed under control prevents this.

What you'll often find however, is that in the last step ("make it fast") you have limited room to maneuver, because of the stuff you did in the first 2 steps. If you really need high performance, you need to design for high performance, not just leave it as an afterthought.

But at the point where you're ready for careful observation and measurement, you've already designed and written your solution, and the amount of room you have for optimization is constrained by the thing you just built.

If you want performance, you have to design for performance, not just build the first thing that comes to mind and try to optimize it later.

I like the "split ends" analogy. A lot of developers seem to worry too much about issues that aren't actual problems, other than that something is "not OO".

An actual example of this I saw recently, was when I got into an argument with someone over the use of standalone functions in C++. Apparently, these are evil, and functions should always be part of a class.

Of course, a class with only static functions is basically a namespace. No problem, apparently statics are also evil. So let's not make these functions static, even though they're not accessing any member data.

But now, when we want to use these functions, we need to instantiate an object, which is a bit silly. No problem, we'll just make it a singleton.

I shit you not, this actually happened.

Yeah, it's amazing. We've had decades of improvements in hardware performance, only to end up with software that's slower than anything that came before it. Yet apart from a small minority, nobody seems to bat an eye.

This bulletin is obviously aimed at scaring others who were thinking of doing something similar. Still, it's a bit heavy handed, isn't it? No one was hurt, no damage was done, CERN responded immediately when notified, and it turned out to be a dumb student who fucked up. Give the dude a slap on the wrist, and let it go.

I think it probably was more than worth the effort. This is of course not his main source of income, but it certainly strengthens his reputation as one of the foremost experts on C++.

At a company I worked for previously, some people thought it would be nice to invite him for giving a talk. Even though there was a reasonable budget available, it still didn't go through because the guy is apparently pretty expensive.

In the past 15 years I've been in a situation twice where shipping something NOW was more important than taking the time to do the needed cleanup. Simply because the competition was breathing down our neck, and taking a break to refactor stuff would just give them an opportunity to bury us. And who's going to care about your code quality then?

And it wasn't just crappy web apps or throwaway MVP stuff. The first one was in medical systems, where the suits figured we had a 6 month lead on our closest competitor, the other was in consumer electronics (navigation devices), in the time that competition was still stiff in that sector.

In both cases it was decided that releasing something was more important, knowing full well that we had to pay the cost later. Of course not everyone agreed with it, since no one likes having to work with legacy crap, and everyone and their mother always wants to refactor all the things, but guess what: code quality is not the goal of your company, making money is.

She and/or her husband probably checked you out on LinkedIn, that's how he shows up in your 'people I know'. It's not really that creepy.

Some time ago I was put on an assignment at another company, and suddenly people from that company started showing up in my 'people you may know' list. And vice versa probably, since I also checked out some of their profiles. This is just what people do these days when they get a job somewhere.