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

Things that used to be hard and are now easy

jvns.ca

Post reply on HN
Print view View original

261–270 of 316 posts

Re: Things that used to be hard and are now easy

#261

Post by UncleEntity »

linux2647 wrote: post #45
eatonphil wrote: post #25

Personally, I disagree that parsing was hard before and made easy with PEG parsing. For decades it has been easy and common to implement parsers by hand. From what I can tell, universities and textbooks just overcomplicated the process by teaching parser generators. I have done a few studies of various open source ecosystems now and (edited: other than CPython) I haven't seen PEG parsers really used in anything but t…

CPython appears to use a PEG parser for its implementation: https://github.com/python/cpython/blob/b77158b4da449ec5b8f68...

Pretty sure that’s relatively new and had a hand written parser for most of their history.

…which also implies that it used to be hard and now isn’t.

Re: Things that used to be hard and are now easy

#262

Post by oconnor663 »

tonightstoast wrote: post #195
oconnor663 wrote: post #148

Earlier quoted context omitted.

> writing a fast program in C is often simpler compared to writing a fast program in Rust I think it really depends on what you need to do. If you need a HashMap or a BTree, getting your hands on high-performance implementations of those structures in Rust is much easier than in C. Also "sprinkling some threads" on existing serial code can be much easier in Rust, using a library like Rayon. But I take your point that…

I would agree. I feel like we keep seeing these “software has become more complicated!” blogs. But it’s really just that modern languages/stacks don’t focus on making software development easier for the individual, they focus on making it easier for the organization. Related anecdote: I have been using GraphQL at work and holy shit it is boilerplate galore but I swear we hardly have to train new hires on how to struc…

On top of that, our security standards have also gotten higher. No one was worried about corrupt spreadsheets causing segfaults in 1995. But today that corrupt spreadsheet is just as likely to be a malicious file from some attacker on the internet, deliberately crafted to exploit the buffer overrun behind that segfault. Any piece of software that might conceivably touch attacker-controlled input needs to be hardened against this sort of thing.

We're also going to be seeing more and more pressure to make things multithreaded. So so much of the old software was designed back when concurrency just wasn't in the picture. That's why PID reuse races are so nasty in child process management. And why anything that touches the environment (which lots of standard libc functions do under the covers: https://rustsec.org/advisories/RUSTSEC-2020-0159) is unsound in multithreaded programs. Making everything threadsafe is genuinely hard.

Re: Things that used to be hard and are now easy

#263

Post by iforgotpassword »

fsflover wrote: post #254
iforgotpassword wrote: post #21

Earlier quoted context omitted.

As an i3 user, basically going without a DE, I recently tried to breathe new life into an old core 2 duo laptop that was in very good shape and basically just used to browse the web and play spider solitaire. It was on Windows 7, and I don't think upgrading to 10 would have been worth it with that CPU and 2gb of RAM. I picked Debian, and put the different DEs through its paces. I started with those that should have b…

You should try xfce.

I think that was among them now that you mention it.

Re: Things that used to be hard and are now easy

#264

Post by monktastic1 »

jbpnoy6fifty wrote: post #218

I would also agree to this in MANY fronts, not just software. As a kid I dreamt of building a robot at ~6 years old. Just this past weekend, I helped my God-son build one (a solar kit for kids) and it was on sale for $10. Things are generally more affordable now than they used to be for the masses, and more easier to achieve and prototype, in less turn around time, with 1 day shipping, or the mall-ification of societ…

The flip side is that because we treat cheap things as disposable, we are accelerating the collapse of the biosphere.

Re: Things that used to be hard and are now easy

#265

Post by adamnemecek »

anthk wrote: post #249
adamnemecek wrote: post #151

Earlier quoted context omitted.

> it's what C++ should have been No. There's a large class of programs that you can't write in Go that you can write in C++.

No. I meant that C++ should have never been born. For high perf software C should be enough, while Go could work great for generic system binaries. Today's low end machines are not a Pentium 2 or 3, but a Raspberry Pi B+ with 512 MB of RAM (very low end, a real life machine would be a Pentium 4 with SSE2 and 1GB of RAM or a Core Duo with 2). Enough for Go and statically linked binaries a la plan9/9front.

> No. I meant that C++ should have never been born

C++ was an important stepping stone.

There's still a large class of software for which GC-ed languages are non-starters.

Re: Things that used to be hard and are now easy

#266

Post by whoisthemachine »

polishdude20 wrote: post #157
ignoramous wrote: post #106

Earlier quoted context omitted.

> I've mucked around a fair bit with JS's async and never felt like it got in the way. When functions return more than one Promise , or when one chains async functions calls, it isn't really clear Error s from which functions are likely to break out and result in an unhandled exception (read also: https://archive.is/ULT7P ). For example, does trapAllErrs() below trap 'em all? Not really. Why? The answer involves unde…

Would you do a .catch on the await p to fix that?

The solution to catch the errors for each function would be to catch errors from each promise individually (possibly within their functions, or within wrapper functions). This solution would also clearly state the intent. Performing concurrent tasks and only catching the errors at a higher level is a tricky thing to define behavior against; .Net/C# does it with the `AggregateException`, but even that comes with its own difficulties (which error comes from which promise? which came first? did one cause the other?).

Re: Things that used to be hard and are now easy

#267

Post by Tijdreiziger »

theshrike79 wrote: post #243
Tijdreiziger wrote: post #141

Earlier quoted context omitted.

Really? On almost all Discord servers I've visited, everyone has a nickname and doesn't share photos of themselves. On Instagram, I've also noticed a lot of young people who share e.g. art have a completely anonymous profile (and I guess probably another, non-anonymous profile for their friends only). Not sure about Snapchat or TikTok, though.

The problem with Discord and anonymity is the fact that it's really tedious to have multiple Discord accounts. Let's say you want to keep your work, hobby and private profiles completely separate. You'd need to have one with the official client and the other two with a separate browser each. Also you'd need to be super careful when joining a new server for any category to make doubleplussure you're not joining with t…

IME Discord anonymity is more like ‘your friends know it’s you, but strangers can’t find out your real identity’. But I agree, they could do with a profile switcher.

Re: Things that used to be hard and are now easy

#268

Post by eatonphil »

UncleEntity wrote: post #261
linux2647 wrote: post #45

Earlier quoted context omitted.

CPython appears to use a PEG parser for its implementation: https://github.com/python/cpython/blob/b77158b4da449ec5b8f68...

Pretty sure that’s relatively new and had a hand written parser for most of their history. …which also implies that it used to be hard and now isn’t.

No they moved from pgen, a custom parser generator, to this PEG parser.

The parser was never handwritten.

Re: Things that used to be hard and are now easy

#269

Post by indymike »

grishka wrote: post #250
indymike wrote: post #227

Earlier quoted context omitted.

> I so want this abomination of a technology uninvented. Good enough beats perfect almost every time. The real fail is that the major desktop OSes have spent the last 20 years jockeying for a monopoly on how software is made on and distributed their platforms. Apple and MS (and even the Linux desktops to a lesser degree) want me to have to build and maintain completely separate apps for their platforms to unlock all…

Almost everyone is making native mobile apps — two copies of the same thing, for Android and iOS — but for desktop, it's suddenly something infeasible? Why so? It has always been other way around in my mind — my phone is an auxiliary limited communication device that's awkward to type on. Yet for almost every IT company with a mainstream product, phones are first-class, and computers are an afterthought. How so?

More users.

Re: Things that used to be hard and are now easy

#270

Post by ParetoOptimal »

antirez wrote: post #70

It's very hard to accept the statement that writing fast programs is now simpler with Go/Rust. I think that what happened is more like this: * With Go is now possible to write reasonably fast (not as fast as C) programs in a simpler way. That's great indeed, but is not exactly the above statement. * With Rust it is possible to write programs that have a speed that is comparable to the one of C programs, that are memo…

> Overall Rust made programming harder: something that I'll hardly excuse to it.

Shouldn't this also be:

Overall Rust made programming harder if we ignore memory safety: something that I'll hardly excuse to it.

Post reply on HN