Live data from Hacker News

Fashionable Problems

paulgraham.com

191–195 of 195 posts

Re: Fashionable Problems

#191

Earlier quoted context omitted.

There are a large number of people working on inequality. The two most common fields studying it are: 1) Development 2) Labor Although there are a number of Macro-Economists who have studied the impact of inequality on growth. The reason you may not read about it is that the relationship between inequality and growth is a largely "solved" problem. It is "unfashionable" because of that.

The fact that the field thinks it is a solved problem is a marvelous example of what the essay is talking about!

Not exactly. It is a political problem not an economic one.

Re: Fashionable Problems

#192
post #155
post #134

Earlier quoted context omitted.

> It’s literally EVERY web browser that anyone uses. And is a fine example of path dependence. No one can write a browser in any other language not because C++ is necessarily better but because the activation energy to bootstrap to a useful browser is so large (for example, one must provide a smoking fast Javascript engine before one even considers the web page rendering pipeline). It will be interesting to see how m…

Basically, C++ developers (like me) are stupid. We're like primitive species, stuck with C++ because we can't understand superior languages. The Lisp developers tried to bring us the light, but we chased them away by throwing rocks at them. Now the Rust evangelists are doing the same thing, but I'm afraid we might take a break from writing video games, stock exchange software, safety-critical software, CAD packages,…

> My point is: maybe C++ actually _is_ the superior language. It can't be a coincidence that all the best software projects tend to be written in C++, and not in Haskell or whatever.

If we're going by best software written, I suspect that means C is the better language than C++ by a wide margin. It would be interesting as to whether Visual Basic would be superior on that axis as well.

C++ is the better language--except that we always have to expose a C FFI because nobody seems to have enough critical mass to stabilize the library ABI. C++ is the better language--except that Apple wrote another language because they don't believe that and that Mozilla wrote Rust because C++ wasn't good enough. C++ is the better language--as long as you have a new codebase that only uses the latest features and Satan help you if you have stuff from pre-2005 because God won't be enough. C++ is the better language--as long as compile time isn't an issue.

I can go on if you wish...

I don't think C++ developers are stupid and those choosing to start new projects in it generally have really good reasons for doing so. I also think that many older projects are in C or C++ via path dependence because C++ was the superior choice when the project started and now they have far too much code to switch.

I also believe this will be why Rust eventually becomes a very important language--Rust allows you to modernize that old codebase in a piecemeal fashion.

Re: Fashionable Problems

#193
post #173

Earlier quoted context omitted.

Well, you just kinda answered your question. There is STL, Qt and Boost. Like all other languages. They do the same thing but in different capacities, you should select based on your needs. I think std::string can be supplemented for Unicode support, I am gonna say the fmt library was the supplement but I feel like I am wrong. I used std::string and QString extensively for 4-5 years and find QString inexplicably bloa…

I don't understand your problem with QString, but anyway, AFAIK the common way to get Unicode support with std::string is ICU. ICU is quite large (~15-20 MB binary) and it breaks binary compatibility with every release.

I don't do C++ anymore professionally, but from I remember, std::locale was very useful: https://en.cppreference.com/w/cpp/locale

And QString had no magic to it other than wrapping its underlying data in ytf-16 which std::u16string does too.

It's not perfect but it gets the job done, IIRC.

Re: Fashionable Problems

#194
post #117
post #93

Earlier quoted context omitted.

There is a lot of evidence for what Paul says once you dig into a specific field. Taking two fields I know well: in physics, there was decades of work on fundamental questions on systems in equilibrium, while many obviously important open questions in out-of-equilibrium systems went neglected until the last 10 years or so when there's been a huge upsurge. These questions were known to be open 20 and 30 years ago, but…

I know next to nothing about physics, but I do know some about ML. I think the reasons tensor networks are unexplored is interesting: The tools and techniques for dealing with them build on those for neural networks and the theoretical benefits are not clear cut enough to gain them a foothold over the practical results of neural networks.

Forgot to mention, but here is a recent theoretical result (prediction of generalization performance giving size of training set) based on tensor networks: https://itensor.org/miles/GenerativeMPS.pdf

Re: Fashionable Problems

#195
post #139

Earlier quoted context omitted.

There's also the cost that you are likely to just spin your wheels retreading old ground. Examples to the contrary are notable, but notable because they are rare .

This here is the real danger. Many people choose to reinvent the wheel and end up finding out that their approach was actually horribly flawed compared to what already existed, or they turned out not to have the resources to see it through. It takes a brilliant person with a lot of luck to make this work in an advantageous way. Two great examples come to mind right away, both from Elon Musk. SpaceX was founded on fir…

>Conversely, his attempt approaching car manufacturing from first principles in the gigafactory has proven to be a complete disaster.

Nonsense. What is that based on?

Post reply on HN