He created Meow Hash somewhat recently and open sourced that. It's not a huge project but it's very useful. A lot of his time goes toward education, his personal projects and contract programming. Not every programmer is dedicated to releasing their own open source or commercial software. I'd bet most programmers don't. Using this as a metric to claim that he has a bad coding approach is ridiculous and laughable. Especially using Handmade Hero as an example... It really reveals your ignorance.
Also, since you care so much, let's see what you've released, smart guy. Preferably code so that we can see how talented you are.
> Also, since you care so much, let's see what you've released, smart guy. Preferably code so that we can see how talented you are.
I'm not the one telling everyone they're doing everything wrong, and did it not occur to you that my perception of what his output ought to have been over that timeframe (especially for someone who rates his own abilities as highly as he does) is informed by my own?
Just because you haven't been exposed this issue doesn't mean it doesn't exist. "the real situation", "no one", "in real projects", "never pop up"...give me a break lol.
One can reasonably well guess/know the expected input sizes to their programs. You ain’t (hopefully) loading your whole database into memory, and unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop, that’s just not how most programs look like. If it is, then you should design for it, which may even mean changing programming languages for that part (e.g. for video codecs not even C et al. cut it, you have to do assembly), but more likely you just use a bit less ergonomic primitive of your language.
> unless you are writing a simulation/game engine or another specialized application, your application is unlikely to have a single scorching hot loop
If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board.
We should try to steal more ideas from different domains instead of treating them like entirely isolated universes.
> If everything was built with constraints like "this must serve user input so quickly that they can't perceive a delay", we would probably be a lot better off across the entire board.
Sure but it’s a question of tradeoffs.
If the wall-clock-optimized version creates a bus count of 1 for that domain or is difficult for a dozen engineers to iterate on, then that could be worse for the business and users.
Should we want better software? Yes. Should we learn from other domains? Absolutely. But we should ultimately optimize for the domain we’re in, and writing much product-focused software is ultimately best optimized for engineering team and product velocity.
Another example: would most software benefit from formal verification? Yeah, I guess, but the software holistically—as a thing used by humans to solve problems—might benefit considerably more from Ruby.
Product velocity is not increased by spending a ton of time on complex type hierarchies and premature extensibility. It’s increased by having fewer classes and simpler functions that are faster to write tests for to get good coverage via end-to-end tests. The patterns of OOP increase the amount of time spent not solving the business needs. They also infuse the entire system with unnecessary slowness.
> You ain’t (hopefully) loading your whole database into memory
I've basically built my career for the past decade by pointing out "yes, we can load our whole working set into memory" for the vast majority of problems. This is especially true if you have so little data you think you don't have CPU problems either.
Databases are often not used by a single entity, so while I am very interested in your experiences, I think it is a great specialization for certain problems, but is not a general solution to everything.
All in all, I fail to see how it disagrees with my points.
> e.g. for video codecs not even C et al. cut it, you have to do assembly
This is largely inaccurate. Video encoders/decoders are typically written in C, with some use of compiler intrinsics or short inline assembly fragments for particularly "hot" functions.
Exactly, and they only decided to write those bits in assembly when they identified it as a hot code path AND the assembly outperformed any C code they could come up with.
The times that assembly outperforms a higher level language has reduced as well over time, with compiler and CPU improvements over time.
I was talking about those hot functions only, not the rest of the program. But yeah a “sometimes” or a “may” would have helped in my original sentence.
But the point isn't that just the scorching hot loop is 20x slower, but that this penalty is paid everywhere. And it won't show up in profiling since there isn't a hotspot, it's death by 100 cuts.
Never look at the dispatch of a big company’s Java code base then. It’s dynamic dispatch 400 layers deep for a single network call or file op or small amount of math. Sure those are more expensive operations, but the dynamic dispatch has continually out scaled the problem.
But the company that uses Java quite often is writing the umpteenth line-of-business application, where dynamic dispatch is not going to cause a massive overhead
That is true. This feature has been around for many years and used to be advertised on their navbar before Google+ came about, but it never stood out as a prominent component of the Google experience. I figure they are pushing people to adopt Google+ as their "portal" but I'm likely wrong as the two products are quite different. It could also be that it doesn't generate any revenue and the experiment is nearing the end of its life cycle.
That's pretty harsh. I understand that it's silly to not proofread very carefully when doing a stunt like this, but language mistakes aren't a sign of incompetence.
Right, by incompetence I was referring to the parent's comment towards the guy not being able to build a quality product because he left an apostrophe out of a word.
I would like to hear your thoughts on Clojure's serious design flaws. I'm currently learning the language and haven't come across anything warning me of such things.
I have two years experience with Clojure and about a year working with Scala (plus use of Ocaml and a bit of Haskell). Clojure and Scala both have warts. Many, many warts, as all languages do. Still, I can't say that I've found major, intractable "design flaws" (as in, design decisions leaving me convinced I could do it better) in either. They run on the JVM, and they're ambitious languages, so warts are inevitable. That's hella hard, and both languages do an excellent job considering the constraints involved.
Most of the things I find myself disliking in these languages have more to do with JVM legacy (e.g. type erasure in Scala) but that's also what gave them a chance at being mainstream, so no complaints there.
It's worth noting that Reifeid generics also have their limitations. I believe Haskell also does a similar level of erasure. Reified generics makes it harder to include higher order types and so the level of abstraction in Scala's collections or monad transformers would be much harder without type erasure. Haskell's type system is better at keeping the annoyance of erased types away by not just casting every thing to a top type.
Cool idea! One thing you should do is add some feedback when someone tries to reserve a username that is already taken. It currently just refreshes the page. I wasn't sure if it worked for me until I tried something different.
Very interesting. I recently worked on a little side project using MongoDB and I noticed during testing that some records would disappear at random. Glad to see this has happened to others. I suppose it's time to check out Redis.
Also, since you care so much, let's see what you've released, smart guy. Preferably code so that we can see how talented you are.