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

The computers are fast, but you don't know it

shvbsle.in

Post reply on HN
Print view View original

191–200 of 819 posts

Re: The computers are fast, but you don't know it

#191

Post by bb88 »

bayindirh wrote: post #170
bb88 wrote: post #158

Earlier quoted context omitted.

Java and Go were both responses to how terrible C++ actually is. While there are footguns in python, java, and go, there are exponentially more in C++.

As a person who wrote Java and loved it (and I still love it), I understand where you're coming from, however all programming languages thrive in certain circumstances. I'm no hater of any programming language, but a strong proponent of using the right one for the job at hand. I write a lot of Python these days, because I neither need the speed, nor have the time to write a small utility which will help a user with C…

I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java.

Writing good C++ is hard. People who think they can write good C++ are surprised to learn about certain footguns (static initialization before main, exception handling during destructors, etc).

I found this reference which I thought was a pretty good take on the C++ learning curve.

https://www.reddit.com/r/ProgrammerHumor/comments/7iokz5/c_l...

Re: The computers are fast, but you don't know it

#192

Post by zozbot234 »

skybrian wrote: post #178
zozbot234 wrote: post #136

Earlier quoted context omitted.

Please don't write programs in bare C. Use Go if you're looking for something very simple and fast-enough for most uses; it's even memory safe as long as you avoid shared-state concurrency.

I mean, he just explained that after rewriting his program in Dart, it was fast enough? That's not really the point here. On the other hand, I tried writing a Wren interpreter in Go and it was considerably slower than the C version. Even programming languages that are usually pretty fast aren't always fast, and interpreter inner loops are a weak spot for Go.

> I mean, he just explained that after rewriting his program in Dart, it was fast enough?

Yes, and that makes his C advocacy even less sensible. Dart is a perfectly fine language, even though it seems to be a bit underused compared to others.

Re: The computers are fast, but you don't know it

#193

Post by staticassertion »

zozbot234 wrote: post #136
munificent wrote: post #68

Earlier quoted context omitted.

I agree 100%. I wish every software engineer would spent at least a little time writing some programs in bare C and running them to get a feel for how fast a native executable can start up and run. It is breathtaking if you're used to running scripting languages and VMs. Related anecdote: My blog used to be written using Jekyll with Pygments for syntax highlighting. As the number of posts increased, it got closer and…

Please don't write programs in bare C. Use Go if you're looking for something very simple and fast-enough for most uses; it's even memory safe as long as you avoid shared-state concurrency.

Unqualified "fast enough" is pretty much exactly the problem being pointed out. Most developers have no idea what "fast" is let alone "fast enough". If they were taught to benchmark at with a lower level language, see what adding different abstractions causes, that would help a ton.

I would personally suggest C++ though because there is such a huge amount of knowledge around performance and abstraction in that community - wonderful conference talks and blog posts to learn from.

Re: The computers are fast, but you don't know it

#194

Post by throwaway894345 »

KronisLV wrote: post #164
michaelsshaw wrote: post #156

Earlier quoted context omitted.

Nothing wrong with any of these languages, especially C. It's been around since the early 70s and is not going anywhere. There's a very good reason it (and to an extent C++) is still is the default language for doing a lot of things since everyone understands it.

C and C++ both have excellent library support, perhaps the best interop of any language out there and platform support that cannot be beat. That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later. Thus, unless you have a good reason (of which, admittedly, there are plenty) to use C or C++, somet…

> That said, they're also challenging to use for the "average" (median) developer who'd end up creating code that is error-prone and would probably have memory leaks sooner or later.

Many of the most highly credentialed, veteran C developers have said they can't write secure C code. Food for thought.

> Go is a decent choice, because of a fairly shallow learning curve and not too much complexity, while having good library support and decent platform support. Rust is a safer choice, but at the expense of needing to spend a non-insignificant amount of time learning the language, even though the compiler is pretty good at being helpful too.

Go doesn't have the strongest static guarantees, but it does provide a decent amount of static guarantees while also keeping the iteration cycle to a minimum. Languages like Rust have significantly longer iteration cycles, such that you can very likely ship sooner with Go at similar quality levels (time savings can go into catching bugs, including bugs which Rust's static analysis can't catch, such as race conditions). Moreover, I've had a few experiences where I got so in-the-weeds trying to pacify Rust's borrow-checker that I overlooked relatively straightforward bugs that I almost certainly would've caught in a less-tedious languages--sometimes static analysis can be distracting and in that respect, harm quality (I don't think this a big effect, but it's not something I've seen much discussion about).

Re: The computers are fast, but you don't know it

#195

Post by dylan604 »

tomcam wrote: post #153
zozbot234 wrote: post #136

Earlier quoted context omitted.

Please don't write programs in bare C. Use Go if you're looking for something very simple and fast-enough for most uses; it's even memory safe as long as you avoid shared-state concurrency.

Some of us know how to program. Some of us know the fundamentals.

Fewer know both

Re: The computers are fast, but you don't know it

#196

Post by [deleted] »

jcelerier wrote: post #87
varispeed wrote: post #44

I wonder if eventually there is going to be consideration for environment required when building software. For instance running unoptimised code can eat a lot of energy unnecessarily, which has an impact on carbon footprint. Do you think we are going to see regulation in this area akin to car emission bands? Even to an extent that some algorithms would be illegal to use when there are more optimal ways to perform a t…

> Do you think we are going to see regulation in this area akin to car emission bands? it has thankfully started: https://www.blauer-engel.de/en/productworld/resources-and-en... I think KDE's Okular has been one of the first certified software :-)

[deleted]

Re: The computers are fast, but you don't know it

#197

Post by dylan604 »

grishka wrote: post #77
marcosdumay wrote: post #19

Earlier quoted context omitted.

It's not only a matter of 750ms instead of 200ms. I'm astonished every time I open some tool like Visual Studio, SAP Power Designer, or Libre Office that can stay for the most part of a minute on its loading screen. What do those tools even do for that long? They can read enough data from the disk to overflow my computer's main memory a few times during it.

I remember a video of a guy running an old version of Visual C++ on an equally old version of Windows, in a VM on modern hardware, to try Windows development "the old way". It took about one frame to launch. One. Frame. By the way, Apple isn't much better. Xcode takes around 15 seconds to launch on an M1 Max. edit: probably this video https://youtu.be/j_4iTovYJtc?t=282

One. Frame. Of. What?

I've never heard of someone describing how long something took like this without at least defining the frame rate.

Re: The computers are fast, but you don't know it

#198

Post by dfgqeryqe »

bornfreddy wrote: post #9
wodenokoto wrote: post #2

Did the author beat pandas group an aggregate by using standard Python lists?

Yes. Apparently they have used Python lists to beat highly optimized library which builds upon numpy, in C. Yeah right. Note that I'm not saying that their second version of the code wasn't faster, just that this has nothing to do with python vs. pandas.

You would think that, wouldn't you? But every time I've worked on a Python code base I have torn out Pandas and replaced it with simple procedural code, getting at least an order of magnitude.

Pandas is spectacularly slow. I don't understand how or why, but it is.

Re: The computers are fast, but you don't know it

#199

Post by zozbot234 »

staticassertion wrote: post #193
zozbot234 wrote: post #136

Earlier quoted context omitted.

Please don't write programs in bare C. Use Go if you're looking for something very simple and fast-enough for most uses; it's even memory safe as long as you avoid shared-state concurrency.

Unqualified "fast enough" is pretty much exactly the problem being pointed out. Most developers have no idea what "fast" is let alone "fast enough". If they were taught to benchmark at with a lower level language, see what adding different abstractions causes, that would help a ton. I would personally suggest C++ though because there is such a huge amount of knowledge around performance and abstraction in that commun…

It's not an "unqualified" claim, Go really is fast enough compared to the likes of Python and Ruby. I'm not saying that rewriting a Go program in a faster language (C/C++/Rust) can't sometimes be effective, but that's due to special circumstances - it's not something that generalizes to any and all programs.

Re: The computers are fast, but you don't know it

#200

Post by bayindirh »

bb88 wrote: post #191
bayindirh wrote: post #170

Earlier quoted context omitted.

As a person who wrote Java and loved it (and I still love it), I understand where you're coming from, however all programming languages thrive in certain circumstances. I'm no hater of any programming language, but a strong proponent of using the right one for the job at hand. I write a lot of Python these days, because I neither need the speed, nor have the time to write a small utility which will help a user with C…

I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java. Writing good C++ is hard. People who think they can write good C++ are surprised to learn about certain footguns (static initialization before main, exception handling during destructors, etc). I found this reference which I thought was a pretty good take on the C++ learning curve. https://www.reddit.com/r/ProgrammerHumor…

> I've seen a lot of bad C++ in my life, and have seen Java people write C++ like they would Java.

Ah, don't remind me Java people write C++ like they write Java, I've seen my fair share, thank you.

> Writing good C++ is hard.

I concur, however writing good Java is also hard. e.g. Swing has a fixed and correct initialization/build sequence, and Java self-corrects if you diverge, but you get a noticeable performance hit. Most developers miss the signs and don't fix these innocent looking mistakes.

I've learnt C++ first and Java later. I also tend to hit myself pretty hard during testing (incl. Valgrind memory sanity and Cachegrind hotpath checks), so I don't claim I write impeccable C++. Instead I assume I'm worse than average and try to find what's wrong vigorously and fix them ruthlessly.

Post reply on HN