Things that used to be hard and are now easy

https://jvns.ca/blog/2022/02/20/things-that-used-to-be-hard-and-are-now-easy/

by pingiun • 4 years ago

371 305 4 years ago

jvns.ca

myself248• 4 years ago

Until "large prime factorization" makes this list, I think we're cool.

adrift• 4 years ago

"Building fast programs, with Go/Rust"

Sure, bud.

adamnemecek3• 4 years ago

They are both so much more pleasant to work with than C.

anthk5• 4 years ago

Golang was created from the same people of C, it's what C++ should have been. It takes lots of background from plan9, the 'Unix++' OS.

kqr• 4 years ago

In contrast to building fast root escalation exploits which perform useful functionality on the side, which is what we get with less safe memory models.

dang2• 4 years ago

Could you please stop posting unsubstantive and/or flamebait comments to HN? You've been doing it a lot, unfortunately, and we ban that sort of account. It's not what this site is for, and it destroys what it is for.

https://news.ycombinator.com/newsguidelines.html

jacobmartin• 4 years ago

I've only been using desktop Linux for 15 years, but it is vastly easier to use it as a daily driver than it used to be. It still has its problems--just yesterday I sunk an hour into an elusive bug. But when I was doing that, I remembered that such things used to be nearly constant and aren't any longer.

iforgotpassword3• 4 years ago

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 been more lightweight, but ultimately found that only kde of all things gave an acceptable user experience while not feeling overly slow.

I don't remember which was which, I tried mate, cinnamon, lxqt And maybe something else I'm forgetting now. One of them was really slow to react to the multimedia keys, and then would appear to buffer the keystrokes from the key repeat like it's the MS-DOS days, ie you press brightness up, nothing happens, so you hold the key, and when it finally starts adjusting the brightness you immediately let go of the key but it still goes on and on to maximum brightness. Then another one couldn't be convinced to behave in a consistent way when it comes to screen brightness wrt (un)plugging mains power and using the brightness keys. It was something like: unplug, screen goes brighter as I manually adjusted it way down before on mains power (sitting in dark room), and the default setting for battery happened to be higher. Annoying but ok, but then if you touch the brightness controls again it first goes up again and then very low and whatnot. Like, there might be some very clever intentions behind this that I didn't catch right there, but then I doubt the non-tech-savby person this was intended for would get what kind of 4D chess magic was going on there. It just felt like it was spazzing around. Then the third one installed and had all its icons missing and the font rendered way too large. That's just the three most blatant issues I ran into. Installed KDE last and everything was sane and usable, to my surprise.

Granted, some of the issues, especially the icon/font one are probably just packaging mistakes on debians side; I don't know how often people really install multiple DEs in parallel, so this might be untested territory, but still, showed me once again that as much as I like Linux, I'm never gonna claim it's the year of the Linux desktop for probably another decade, and only would encourage curious tinkery friends to actually try Linux as a daily driver if they do more than just browse the web, and then probably never use anything besides KDE or Gnome 3 at least for a start.

nerdponx2• 4 years ago

KDE is amazing, as in I am constantly amazed by how good it is.

Don't forget to donate to free software projects that make your life better!

fsflover2• 4 years ago

You should try xfce.

SyzygistSix2• 4 years ago

I agree. I've used Mint since Daryna and since version 19 it has not worked on my older, but still quite good laptops. A similar issue with having to choose between dual monitors or having brightness buttons working. It's a shame, since it has always "just worked" for me, unless I was doing something complicated. And this is for a very beginner friendly distro.

SyzygistSix2• 4 years ago

I find it harder to understand internally though. Maybe I just have not kept up, but it seems that since SystemD was added, the additional complexity is significant.

reidjs2• 4 years ago

As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledge.

I’m in the middle of a mongoDB to Postgres migration for a product with 0 users. When you’re trying to scale from 0 to 1 user then everything should help you explore the user’s problem space, even if it seems backwards to build the UI before the backend.

awb• 4 years ago

Scaling from 0 to 1 user? Is this a personal project?

reidjs2• 4 years ago

Nope

teaearlgraycold• 4 years ago

What is there even to migrate??

unnouinceput4• 4 years ago

Maybe you meant from 1 user to more than 1? I mean, unless is building dust on a shelf, anything running in a computer has at least 1 user.

smoe• 4 years ago

Agree with starting focusing on UI first. But haven’t seen a speed advantage at this stage of serverless vs a simple monolithic backend app with a bunch of endpoints. You can get something in front of users within hours. Either way allows you to overengineer and focus on the wrong thing.

freedomben3• 4 years ago

Agreed, and the upside to to having a monolithic backend is that if/when your app gets serious you don't have to port it or redo it. Sure there are definitely large apps that use Firebase et al, but much more often than not for reasons of cost or compliance or customization, the backend ends up getting written later anyway and APIs usually need to change.

mmcnl2• 4 years ago

Agreed, I can get something up and running using Express or FastAPI (frontend + backend) easily in a few hours, whereas Firebase would be new to me. Use whatever you know/can to get something in front of the user.

learc834• 4 years ago

As someone who leans frontend
I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play

Do you not see the problem with these 2 statements. Of course not dealing with non JavaScript is easier for a JavaScript developer.

You can get something in front of your users tomorrow.

This is something we’ve been able to do with Rails or Django for nearly 2 decades now. I can do something similar with more interactivity with Phoenix LiveView and Postgres these days.

mmcnl2• 4 years ago

The logical conclusion would be that you need more frontend than backend when you're trying to scale from 0 to 1.

earthboundkid3• 4 years ago

In my experience, if you're not using Heroku, getting a Rails/Django app launched requires at least a day or two dedicated to devops faffing about (creating server instances, setting up CDNs, making sure the database is minimally correct, having some kind of deploy script or something). This won't even get you nice to have things like multiple environments with CI and deploy previews. Switching over to serverless can reduce that to less than one day and get you deploy previews. Is that a good tradeoff? It just depends on the app, and how long lived it will be, what the performance requirements are, the costs of hosting, etc. For my needs, it's often easiest to just use Netlify's AWS Lambda adaptors.

madmax96• 4 years ago

+1 on Firebase. I recently helped a buddy build an app and decided to give it a try. Holy crap. All we had to was build the app! significantly faster than either of us estimated.

nicoburns3• 4 years ago

Be careful with this, especially with mobile apps that can't be easily updated. Using Firebase has a tendency to put what would otherwise be backend logic into the frontend, which can make it much harder to make changes quickly once your app has users.

nicoburns3• 4 years ago

I would recommend learning backend (which is much easier than frontend!). If you have basic backend skills then you can do the frontend and the backend just as easily, and it gives you a lot more flexibility going forwards.

strken2• 4 years ago

I don't necessarily disagree with this, but I think the difference isn't between frontend and backend, it's between strongly typed and weakly typed, or structured and unstructured. The strength and weakness of Firebase and MongoDB is that they let you shove unstructured data into the db without defining a schema.

Once you have any users at all, you need to migrate that data every time your data model changes. When you need to migrate data, not having a schema goes from a blessing to a curse, because you're trying to change the structure of unstructured data.

For this reason, I'm skeptical of both sides of the coin. I'd almost rather start with an ephemeral in-memory store that forces you to rewrite before you have actual users, rather than be tempted by MongoDB or Firebase.

grishka12• 4 years ago

Building cross-platform GUIs, with Electron

How about no. I so want this abomination of a technology uninvented.

shrimp_emoji3• 4 years ago

But it's the only reason Discord, Slack, VS Code, and other apps exist on operating systems other than Windows/MacOS.

grishka12• 4 years ago

Tbh the world would've been better off if these apps didn't exist. Especially VS Code.

dysoco• 4 years ago

Those are built by large teams with a lot of backing, and still suffer from many issues (mainly performance; Slack crawls very badly, VSCode and Discord not so much); I think it's gotten easier but still wouldn't call it "easy".

rightbyte• 4 years ago

The reason being those are proprietary tools.

PragmaticPulp2• 4 years ago

I really don’t care at all about the resource usage or speed of Electron apps in 2022.

Any semi-modern PC has no problem running Electron apps. Download sizes aren’t an issue with modern internet speeds. It doesn’t make sense to try to optimize for people with the slowest systems when everything is only getting faster.

grishka12• 4 years ago

A fast CPU and plentiful RAM isn't a license to not optimize your code. A fast internet connection isn't a license to not optimize your binary size.

sharikous• 4 years ago

Even in the sort of modern systems available to wealthy developers try to run more than two Electron apps at a time and tell me if you don't feel the slugginess

tomjen32• 4 years ago

I keep hearing that argument, but I also dropped Evernote for Apple notes because Evernote was too slow, even on my M1 mac. So there is definitely such a thing as optimizing your programs.

is_true• 4 years ago

More resource usage = more energy wasted

dmitriid2• 4 years ago

Ah yes. Semi-modern PC shouldn't have trouble... Download sizes shouldn't be a problem...

Do you realize that you are essentially running a supercomputer? And that this supercomputer is struglling to display even the simplest things? Slack's CPU usage shoots up to 20% of cpu to display a single animated reaction to a post. Run a few of those "shouldn't have trouble" in parallel, and suddenly a computer that can run a 4k next-gen Unreal shooter at 60fps struggles to even maintain cursor latency.

adwn3• 4 years ago

Then create an open source cross-platform GUI framework/toolkit that's technologically superior to Electron and also at least as easy and convenient to use and deploy, and people will dump Electron in droves.

I mean, please do! I would be delighted about an efficient, cross-platform, cross-language, convenient GUI toolkit. But I'm not holding my breath, and I'm tired of people complaining about Electron without offering an alternative that's superior along all relevant axes.

grishka12• 4 years ago

Cross-platform GUIs shouldn't exist. That's it. They always inevitably are worse then native ones.

dang2• 4 years ago

Please don't take HN threads on repetitive flamewar tangents.

https://news.ycombinator.com/newsguidelines.html

indymike2• 4 years ago

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 of the capability in their GUI.

You know what I want as a user? I want to be able to buy Affinity Designer and run in on whatever device I have. I don't want to care about Mac, Windows, Linux Chromebook or whatever. I would love to have some real Adobe apps on Linux.

As a software developer, it's about time that we stop having the native vs. whatever universal GUI layer debate, too. I've never seen a single ticket for an Electron app where the user was reporting that my app wasn't MacOS-y or Windows-y enough. I have seen plenty of tickets with native apps where something isn't right with the clipboard, print menu or or some component wouldn't correctly embed on a paste.

grishka12• 4 years ago

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?

theden• 4 years ago

Would be interested in also seeing a "things that used to be easy but are now hard list". Feels like basic stuff is harder now:

* Privacy online

* Google search for niche or exact matches

* Browsing without captchas and blockers, especially if you don't adhere to big tech's rules for the internet

* Sending emails without worrying about spam filters being way too aggressive

* SEO before it got hacked to hell

* Barrier to entry for creatives to build things on the web (for all the flaws flash had, it bridged the gap)

* Finding real discussion and information. The growth of bots posting, misinformation, blogspam, and toxic echo chamber partisan discussion online (maybe it was always like this, i.e, eternal September?)

* MacBooks being easier to upgrade before when things weren't soldered on

* In general anti right to repair hardware

* Not having to worry about dongles, i.e. connecting USB devices to your machine

* Ransomware wasn't a thing. Nothing like a non-technical user needing to learn BTC or XMR to maybe get their data back

* Being able to buy software once vs a subscription, e.g., photoshop

* Work was easier to disambiguate from life before chat apps like Slack made employees always reachable

* CGNAT not being as common

* OAuth is still annoying to implement

* Blocking ads was easier

* Getting a job was easier for a lot of people prior to whiteboarding, leetcode tests, assignments, multi-day interviews and trials, etc. becoming more common

* GDPR making infra+dev work harder because big tech companies don't understand consent and couldn't behave, also leading to performative/annoying cookie banners we see everywhere

* Needing an internet connection for software+tools that used to be able to run locally on your OS

* Website responsiveness was easier before all the devices and monitors with different viewports

* Archival (or scraping) was easier before the majority of human generated content was placed behind login walls (fb) and rendered content needing headless browsers

Edit: Call me cynical if you want—yeah some of those programmer things listed are easier now, but improvements on the core regressions I listed would help programmers (and non-programmers!) all across the world and in developing countries more than some niche highly paid SV engineers using terraform to orchestrate infra on GCP.

jbarham• 4 years ago

Installing Windows without a Microsoft account

unnouinceput4• 4 years ago

That's false. You can still install Windows without a Microsoft account. Granted, it's harder now to see "Use local account", but it's still there.

jeauxlb• 4 years ago

* email delivery

fay59• 4 years ago

The Flash authoring tools still exist, they’ve just been renamed Animate, and they export to HTML5.

jagged-chisel• 4 years ago

I suggest that "barrier to entry" also includes getting started programming in general. Too much to choose from, large leap in skill level required from text in a terminal to graphics on the screen, etc.

ghaff9• 4 years ago

I question if that's really true given all the libraries for languages like Python, online tutorials/projects, and various types of low code environments. Sure, you need to figure out what your options are (or have someone show you) but I question whether it's really more difficult to do something than firing up the BASIC interpreter and typing in code from a magazine.

umvi2• 4 years ago

Logging into an online account on a computer you don't normally use when you don't have your phone. This can range from "had to jump through a bunch of extra hoops" to impossible if you haven't saved backup codes ahead of time (Google).

My wife lost her phone when we were on vacation and it was literally impossible for us to login into her Google account in order to use find my Android.

We were trying to login on a relative's PC to use find my phone, but it was a catch 22 because we need a phone to login to Google on a relative's PC.

I pity the fool who loses their phone in the age of 2FA.

kingcharles2• 4 years ago

I pity the fool who loses their phone in the age of 2FA.

This keeps me awake at night. Especially as it is no longer possible to contact humans at a lot of sites to prove who you are. I went to jail for eight years, when I got out I could only access two of the thousands of accounts I had made over the previous 20 years.

My wife lost her phone when we were on vacation and it was literally impossible for us to login into her Google account in order to use find my Android.

This is a really frustrating situation.

toomanydoubts2• 4 years ago

That's why you always copy the secret recovery codes for the 2FA(which may not be helpful if you left your notebook in your home country during vacantions).

sofixa2• 4 years ago

That's why Google often prompt you for backup information - backup phone number, email address, which can be used to recover an account if you've lost your phone.

ghaff9• 4 years ago

I try to be disciplined about having critical information printed out, especially when traveling internationally. I expect more so than most people. And I do still carry a separate (small) wallet. But we're pretty much all increasingly dependent on our phones for more and more things.

ADDED: And thank you for mentioning that. I just realized I never transferred my Google authenticator setting to the new phone I got last year.

b3morales2• 4 years ago

I can't really see this as the negative you imply it to be. This seems like complaining that you might get locked out of your house if you lose your keys. There are certainly better and worse forms of 2FA, but I would like more pervasive (well-implemented) account security, not less.

sdoering5• 4 years ago

I agree. My SO is nowadays so frustrated by all the security hoops and pseudo-security hoops like Gmail regularly stopping to work with her Thunderbird (she regularly needs to setup a new app specific PW). Other spps/sites sending SMS, others forcing you to use their app for verification and not one standard to get used to.

I am used to this from work but even there MS pesters me to install MS authenticator while I clearly always just use my regular 2fa solution.

And because I think the state of 2fa is not user friendly my own solution is not very secure by using Authy with a client on every device. So there is no second factor. I just copy paste from the app on my computer and don't need to grab my phone.

EdwardDiego2• 4 years ago

My phone screen suffered a bad accident, to the level of unusable. 4 weeks for a repair.

I needed 2FA to access company services. Email, chat, VPN etc. Which of course, was on my phone.

I emailed IT Support from my personal email to request a temp token. My ticket was closed, with a message saying "Email tickets are no longer accepted, use the service portal."

I needed 2FA to access the service portal.

Luckily I had a co-worker on a non-company chat service, so they opened a ticket on my behalf...

theshrike792• 4 years ago

* Privacy online

Privacy is a lost cause, the younger generations don't care.

I remember when people were warned about sharing their real information online. over 50% of people I knew were just nicknames on the internet. I had zero clue about their gender, where they lived or what they did for a living. Didn't affect our conversations the least bit.

Now everyone is plastering their faces everywhere they go. Every picture they take has their face next to it. Usually along with their name, the location and the exact time they were in there and who they were with.

ghaff9• 4 years ago

over 50% of people I knew were just nicknames on the internet.

Depends on the circles.

On the other hand, I accessed Usenet from a company computer which had my real name and company email. And the local forum on my BBS, most people used their real names and we even got together in person from time to time.

yepthatsreality• 4 years ago

I’d say the non-technically inclined groups of people do not care. Instead of privacy being dead there will always be a corner of the population that does not care. That is okay, let them be the fuel for the corpo machine.

Tijdreiziger5• 4 years ago

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.

ayushnix2• 4 years ago

CGNAT will be here for the forseeable future and I wouldn't be surprised if ISPs end up deploying some version of CGNAT on IPv6, assuming they're somehow forced to use IPv6 in the future.

nickysielicki• 4 years ago

Why would they want to run CGNAT on ipv6?

titzer• 4 years ago

Not having to worry about dongles, i.e. connecting USB devices to your machine

The dongles. OMG. It's worse than the parallel printer age. I cannot recall another period in history where I needed a dongle so often. USB-C only on Macbooks was such a huge design mistake. Especially in the era of USB-A! Soooooo many things are still USB-A. All for a little more thinness! It's really grating.

noobermin2• 4 years ago

USB C and the removal of headphone jacks are an example of how not everything in American society is "market driven" but can easily be imposed on the whole market and consumers by a single big player.

codeflo3• 4 years ago

I agree with all of those. More things that are harder now:

* Finding honest product impressions/reviews.

* When looking for a configuration setting or tip to use any piece of software, find a one minute article with clear bullet points instead of an 11 minute YouTube video with a personal backstory and a VPN sponsorship.

* Finding a cooking recipe that isn’t padded with SEO nonsense.

* When finding an online discussion or blog article in a search result, being able to read it straight in the (mobile) browser without hostile prompts to make an account and/or download an app.

* (Europeans only.) Publish a simple website without worrying that the hosting provider you choose doesn’t perfectly conform to privacy laws that even lawyers won’t explain to you and you’re personally liable for ridiculous damages.

* Run software developed by hobby programmers on machines you own.

* Connect devices like speakers, keyboards and mice to computers. (Edit: You mention that.)

And, completely disagreeing with the article on this one point, this is also harder:

* Writing cross-platform UIs. As someone with a lot of hate for Java from back in the day, this is painful to write, but: Java Swing might not have produced the nicest GUIs, but the stack was so much simpler than Electron+Node+Express+Webpack+React+TypeScript (substitute Svelte, Vite or whatever you want), it’s not even funny.

sofixa2• 4 years ago

* (Europeans only.) Publish a simple website without worrying that the hosting provider you choose doesn’t perfectly conform to privacy laws that even lawyers won’t explain to you and you’re personally liable for ridiculous damages.

I'm sorry but that's just FUD. GDPR fines are only for serious infractions with intent, most violators get off with a warning. Furthermore, access logs are OK because they're a legitimate purpose, as long as there's rotation.

PaulDavisThe1st• 4 years ago

"cross platform" isn't well defined these days, since it may or maynot include mobile and/or browser platforms. That said, Qt is much better to use than Swing ever was, and really no more complex until you want to do things you could not do in Swing anyway. Gtkmm too, from my personal (21+ years) experience.

EdwardDiego2• 4 years ago

Recipes: finding a recipe that doesn't start with 1000 words on why this dish makes the author cry because it reminds them of their dearly departed Nana, followed by anecdotes about Nana.

toomanydoubts2• 4 years ago

* Making sure you're not being spied on

Not sure if this was ever easier, but to me it seems it got harder. With all the possible attack vectors, ranging from chain of supply attacks hard-coded deep down on the cpus, up to malicious dependencies being replaced everyday on npm, how does anyone trust their machine?

noobermin2• 4 years ago

The worst part is when people somehow think all these things necessarily must follow from the things that are easier rather than suggesting we could have the good things without the worse off things.

codeflo3• 4 years ago

The “old web” — the one before the rise of the trillion dollar engagement optimizing platforms — is probably completely foreign and unimaginable to those who haven’t experienced it.

daxfohl2• 4 years ago

Getting a job

Though negotiating is way easier with things like levels.fyi and blind.

ghaff9• 4 years ago

The points made upthread would seem to apply to a very narrow slice of jobs. In general, finding info about companies, reaching out to people you have connections with, etc. seems easier than newspaper ads, form letters to HR departments, etc. Though then and now, personal networks are probably still the most effective path for many.

mwcampbell5• 4 years ago

Our online discourse is already saturated with cynicism and pessimism. Do we need to bring it to this thread as well?

Then again, given the contrarian bias of HN comments, I guess it's natural.

FearlessNebula2• 4 years ago

I would argue getting a job is easier now. Prior to whiteboarding and take home assignments, if you didn’t go to a top tier target school and have excellent 3.5+ GPA it was really difficult to even get your foot in the door for an interview.

learc834• 4 years ago

When was this? Maybe If you’re talking exclusively about FAANG.

raverbashing• 4 years ago

Makes me wonder how many sites are still useable with Lynx

tryauuum• 4 years ago

Connecting your laptop to internet via an Ethernet cable

eatonphil6• 4 years ago

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 toy implementations of things.

linux2647• 4 years ago

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

eatonphil6• 4 years ago

That's true, but it's still quite rare to see.

UncleEntity• 4 years ago

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.

TheCondor• 4 years ago

It’s been a minute but parsing with decent performance is what caused all the parser generator stuff. It is a historically hard problem.

PEGs allow the generator input to more closely match the mental model programmers have, *LR require the language to be structured just a little differently than how most people think it.

eatonphil6• 4 years ago

Well if most production parsers use hand-written parsers (and aside from SQL databases, they mostly do) I don't think performance would really make sense to be the reason anyone chooses parser generators.

I'd be curious to read any posts/papers you've got that have benchmarks that show performance to be a reason.

sillysaurusx2• 4 years ago

I recently used lark and liked it. To my surprise.

smilekzs• 4 years ago

IMHO the barrier of entry really came down because with PEG-styled parser libs they put you back in the comfortable "declarative land" where you specify what you want using roughly the same mental model as RegEx without having to worry too much about quirks caused by implementation (i.e. leaky abstraction).

chrisseaton• 4 years ago

IMHO the barrier of entry really came down because with PEG-styled parser libs they put you back in the comfortable "declarative land"

The whole idea of PEGs is that they’re specifically not declarative - they’re an imperative way to express a parser.

lopis• 4 years ago

I really like that XKCD comic about identifying birds in a photo, so it's unfortunate that it didn't age that well. How could we rewrite that comic to today's tech? I was thinking something like:

A: I want to create an app that scans good feedback of our brand online...

B: there's a li rary for that, consider it done

A: ... and understand if they are actually being sarcastic.

B: I'm gonna need 5 years and a lab of experts.

orsenthil2• 4 years ago

When was that XKCD published (https://xkcd.com/1425/) ? Yeah, I remember seeing for the first time, I don't remember my reaction then. But now when I see it, I am stumped!

Darkstryder• 4 years ago

September 24th, 2014.

To know the date of publication of a given xkcd comic, go to https://xkcd.com/archive/, search for the title you're after, then the date of publication is displayed in the mouse-over text.

paulnpace2• 4 years ago

Somewhat relevant:

TornadoGuard https://xkcd.com/937/

nerdponx2• 4 years ago

It aged perfectly IMO. Maybe the timeline was a little bit off, but it did indeed take several years and a huge amount of effort by experts to make object recognition available "off the shelf".

And even then, problems can quickly escalate from "any programmer with a little experience can do it" to "we need a team of data scientists and data engineers".

ghaff9• 4 years ago

Yeah, and even though Merlin and Google Photos (for a broader set of things) are pretty amazing, a naturalist familiar with the area will probably still blow them with the things they can recognize quickly even without having a great view.

ignoramous2• 4 years ago

Things that used to be hard and are now easy:
Concurrency, with async/await (in several languages)

The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it.

Coming from the world of threads, I've found Kotlin's structured concurrency approach the best of the lot I've used so far, even if it isn't with out its quirks: https://kotlinlang.org/docs/composing-suspending-functions.h...

tonyedgecombe• 4 years ago

Yes, the message was you could write asynchronous code as if you were writing synchronous code but that really isn't the case. It is easier but it isn't a panacea.

skulk• 4 years ago

The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it.

Got any examples? I've mucked around a fair bit with JS's async and never felt like it got in the way. (Other than the whole function coloring ordeal)

ignoramous2• 4 years ago

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 Errors 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 understanding the microtask queue and its place in the event loop.

   // traps all errors from a1 and a2, or so we hope
   async function trapAllErrs() {
     try {
       const p = Promise.all([a1(), a2()])
       const results = await p
     } catch (err) {}
   }

   // sync code in a1 never throws
   async function a1() {
     // do something sync
     // ...
     // a3 and a4 may throw errs
     return Promise.any([a3(), a4()])
   }

   // sync code in a2 may throw
   async function a2() {
     // do something sync
     // ...
     // a5 never throws
     const x = await a5()
     // ...
     return ans
   }

1ris2• 4 years ago

Oh yes. I hate async/await so much. If I could uninvent one thing in programming it would be async/await. I wrote async/await code in C# for about a year. I did really try to learn it. I invested a lot of time. I did read Stephen Cleary. It often made sense for a split second only to fade away immediately. Usually the software would work, but i didn't understand what was going on in my own code.

And others don't understand it either. Neither my code, nor the async/await concept. Stack overflow is filled with accepted answers that are just doing it wrong. This was part of the frustration. I did know enough to see that proposed idea was wrong, but didn't have a better idea. Most programmers don't even seem to understand that there is a difference between a C# Task<T> and a C++ Future<T>. I do. And it doesn't help one bit.

My lack of understanding is not for lack of trying. I'm interested in different paradigms in programming. I'm eager to learn new things. While I'm programming OOP on the job, i learned Haskell [1], Idris and Prolog on my spare time. I mean, i can actually programm in these. I think esp. learning prolog shows I have some flexibility in thinking when it comes to programming. I would consider myself an above average programmer, compared to my colleges.

But async/await is simply above my mental capacity. After 1 miserable year the of desperation with in C#, I quit my job and started a new C++ job in a new city. Life is good again. When this company adds async/await to their C++ (not yet in the language thankfully) I will quit again.

I can't even describe what i don't understand about this concept, so far out is it. I only remember the purely practical anecdote that i could make a WPF command execute async but it was well-nigh impossible to make canexecute async. While completely absurd, the actually problems where way more conceptual.

[1] Kind of ironic that everything in Haskell in async, i know. But it never got in the way there.

Quikinterp• 4 years ago

I hope someone can reply to this and help me learn more about async/await in c#. I'm finding it confusing too, and I can't put my finger on why.

klysm2• 4 years ago

I think async/await is kind of a didactic mistake. It’s marketed as a way to not have to think about the underlying abstraction, but lack of the understanding about how it works under the hood will almost certainly bite you in this ass. This I find to be especially true when people are writing mixed async and sync code. The best way for me to learn was writing all of the code before the async/await sugar existed (scala in my case).

strken2• 4 years ago

I have a pretty good mental model of it in JS and TS, because it builds on the pre-existing Promises API, because the transpilation process let me see the equivalent vanilla code while I was learning it, and because the event loop plus the single threaded nature of JS meant that libraries were already using asynchronous code everywhere.

When it comes to other implementations, though, I find them much harder to work with. In particular, existing synchronous or threaded code can block them, there's no good way to fix it without rewriting the synchronous code or shoving execution into a traditional thread, and all the existing libraries are synchronous. It feels like you need a completely new standard library to take advantage.

eternityforest2• 4 years ago

I've never had any trouble with async await in JS and Python. It's pretty close to being just like threading if everything were under one giant GIL.

It's just "Stop here and wait till the task finishes" and "Only one thing happens at a time and you don't go till someone stops".

If you quit rather than got fired, it seems like you must have learned async well enough to do your job.

I almost wonder if C/C++ et al aren't teaching people bad habits of thinking about how things work behind the scenes instead of just just trusting the language.

Haskell probably has the same effect, but it is also said to have some benefits too. It teaches people to look for underlying mathematical patterns in everything.

The thing with modern programming is it seems to be designed assuming you're thinking in terms of the language and libraries you are using at the moment, and building your architecture the way the language designers intended.

As soon as you try to actually understand how it works, or you try to get creative and do anything outside their opininated boxes, it gets ugly, otherwise it's usually fine.

continuational• 4 years ago

You can't add async programming to a blocking language like Java or C#. It doesn't mix well, and will fragment the ecosystem with libraries that mustn't be used together.

wackget• 4 years ago

Eh... I'd argue against quite a lot of those being "easier" than doing things manually.

Docker is a prime example. It's supposedly easier to spin up a docker container for a basic web server stack, but to be honest I'd rather install PHP/MySQL and an SSL certificate manually, rather than spend time finding a decent container from a trustworthy source, and then spend 20 minutes trying to figure out how and why it's been configured the way it has, etc. etc.

Plus there's the need to actually install docker itself and learn how to use it in the first place.

Every one of these comes with its own learning curve which isn't always better than just learning how the actual tools underneath work.

unnouinceput4• 4 years ago

So once you did your own trusted setup - who is stopping you to create a docker container to your liking and use that onward?

I don't trust anything, hence all my docker containers are created personally and use them moving forward. At first it will seems like it's a never ending job to create another docker, but eventually you'll have all your needs fulfilled. Nowadays it can go a month without needing to create another one since I already did this A+B+C combination in the past.

cm2187• 4 years ago

In .net, mandatory async/await for new API is also making things that were easy harder. Async introduces multithreading where there wasn’t, breaks call stacks (debugging harder), deadlocks in certain conditions but not others (asp or winform vs console), forces you to handle what happens if the user interacts with the UI before your function is done executing, etc.

kingcharles2• 4 years ago

This is definitely true. Just trying to download a file can become an async chain hell-hole.. it's asyncs all the way down!

Too• 4 years ago

forces you to handle what happens if the user interacts with the UI before your function is done executing

Thank goodness for that. No more of UI suddenly freezing completely and stops accepting input just because internet connection is flaky. Async or other slow operations should not be running on the UI thread.

xxs• 4 years ago

indeed, concurrency being 'easy', nice one. Concurrency is only 'easy' if there is no shared mutable state.

dimgl• 4 years ago

I highly disagree here. Within seconds I can have all the technology I want running in a Docker container with little to no setup. Just make a docker-compose.yml file with the services I want, say Postgres and Redis, mount my local folder to a Golang Docker image, and then I just do `docker compose up` and all three are running and communicating with each other with little to no effort.

flumpcakes• 4 years ago

I don't think these points address the original post's points. Specifically they highlighted the issues of _finding_ images to run and having the _knowledge_ on how to use these tools in the first place for abstraction.

bonoboTP2• 4 years ago

Thats how you get people who have no idea what the underlying tools can do and bloat the high level abstraction.

Complexity has to go somewhere. If something is easier, something else is harder. These things may make the bog standard use case easy but woe to you if you ever try to go another path or change something. Then you need to figure out if the abstraction layer allows you to tweak the underlying software layer, or invent your own way of reaching into that layer which may break when any update comes in a higher layer etc.

Its more learning upfront to get familiar with the basic Linux tools and services, but it is very versatile and flexible and will stay mostly the same for decades.

paulnpace2• 4 years ago

I don't have any issues with containers, but it seems like many newer projects in the last five years or so the developers are nearly exclusively developing for containers.

My current impression is this violates the spirit of POSIX, because figuring out configurations without containers can become a non-trivial effort, especially for those of us who have not yet learned how to configure containers.

omarhaneef• 4 years ago

“Everything” that is easy used to be hard, depending on your time scale.

I’m certain that COBOL programmers were raving about the ease with which you could program the computer back in the day.

The items on this list sort of happen within a career so an individual had to experience how hard it was before. It probably reads different to someone coding for 5 years vs 30 years.

ghaff9• 4 years ago

There is probably a "Law" to the effect of "The complexity of the task increases to the limits of the current tooling."

anticensor• 4 years ago

Parkinson's law: "Work expands to fill available time".

globalise83• 4 years ago

IE support for JS/CSS has been massively simplified by not supporting IE any more.

nozzlegear• 4 years ago

It’s honestly freeing. I was so happy when the last holdout among my clients told me they no longer need to support any version of IE. Removing all of the IE polyfills and babel transformations from package.json felt so good.

earthboundkid3• 4 years ago

I browsed the Washington Post and NYTimes with IE11 the other day and was pleased to see they looked like absolute garbage. :-)

buescher• 4 years ago

How about things that used to be easy and now are hard? Or things that used to be hard, and now are intractable?

fareesh• 4 years ago

I find the serverless frontend to be way more tedious than a monolith approach.

antirez3• 4 years ago

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 memory safe. So Rust made memory safety simpler, but writing a fast program in C is often simpler compared to writing a fast program in Rust, if we ignore memory safety. Overall Rust made programming harder: something that I'll hardly excuse to it.

EDIT: The blog post was modified, so it only lists "Go" in the section about fast programs. My comment refers to the version of the blog post I read.

vvanders• 4 years ago

Reading the article and I didn't see writing fast Rust programs as easier listed(only Go). The callout was for sharing data between threads which I think is an area where Rust has the edge over other languages.

sillysaurusx2• 4 years ago

Why do you feel that way?

antirez3• 4 years ago

Because the article was modified.

[Note] Another HN user mentioned that the statement was dubious, cited the original statement, got downvoted to hell: https://news.ycombinator.com/item?id=30406644

jwolfe• 4 years ago

I suspect it's pretty hard to make the case that the average Rust program is harder to write than the equivalent C program. I suspect it is quite the opposite. The language provides so many tools that didn't exist in the age of C -- high level concepts like Iterators, destructuring match statements, deriving debug printing for free, etc.

But both of our opinions are just opinions.

tele_ski2• 4 years ago

I think you're point is correct around rust in that writing rust is harder than writing C due to the constraints the compiler places on what you can do. So far I'm happy with this tradeoff because I've had some very gnarly C concurrency bugs that took weeks to understand and debug. If the rustc compiler can point out that I'm doing something stupid and save me two weeks for a bit of pain immediately I'm all about it.

oconnor6632• 4 years ago

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 designing new data structures and doing unsafe things with pointers can be more complicated.

Overall Rust made programming harder

This is certainly a matter of opinion, but I like to argue that writing large, correct systems software was always this hard. Rust frontloads a lot of the difficulty, forcing you to handle every error condition, lifetime mismatch, and potential data race before it will even consent to run your tests. When you're first learning Rust, or when you're writing toy code where safety doesn't matter to you, this can feel like an unnecessary burden. But I think we've learned from experience that writing large systems software without this discipline leads to an endless stream of memory corruption and concurrency bugs.

tonightstoast• 4 years ago

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 structure their software to look like ours.

echelon• 4 years ago

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

Rust isn't much harder than any other language once you understand lifetimes. Non lexical lifetimes made it easier than ever. It's a month of dealing with speed bumps as you learn, and then you're good to go.

Rust makes it insanely easy to write multithreaded applications. I write servers on a daily basis with shared in-memory caches, worker thread pools, async jobs, and all kinds of fun and useful things that I wouldn't dare do in any other language.

I'm developing apps in Rust at near Rails speed.

kilburn• 4 years ago

Would you care to share your library stack for that?

I've sometimes dreamt of trying playing around with building a rust-based web site/app, but then I spend that afternoon reading about different web frameworks, db access libraries, etc. and never really got started.

Given you seem to have a beaten path here I'd love to know what it looks like :)

1vuio0pswjnm7• 4 years ago

Here is the initial version before it was modified.

https://web.archive.org/web/20220220150536if_/https://jvns.c...

"Building fast programs, with Go/Rust"

ParetoOptimal• 4 years ago

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.

throwawaaaaay17• 4 years ago

NLP with HuggingFace

jvns• 4 years ago

I'd never heard of this, thank you! I was hoping for people to provide more examples of things that have gotten easier in this thread but I'm happy to see one or two at least :)

romaniv• 4 years ago

The general theme of this list is that technology gives us more and more hoops to jump through, then provides some trampoline to jump through them. We're supposed to be eternally grateful. I'm not. I want to focus on problem-solving, not masterfully using trampolines.

SSL certificates, with Let’s Encrypt

Semi-mandatory SSL certificates weren't a thing on the web until fairly recently. Not managing them at all was certainly easier than managing them with Let's Encrypt, which has a lot of gotchas, requires tooling, knowledge and can suddenly break your website if something is off.

Concurrency, with async/await (in several languages)

async/await usage is literally the main reason why my recent project is written in Go instead of C#. I like C#. I don't like Go. But dealing with all the gotchas of .NET Core async/await APIs drove me away.

Moreover, Erlang had a much more sane and powerful parallelism model way before async/await.

Centering in CSS, with flexbox/grid

Again, like with SSL, this is technically correct, but generally incorrect. Centering in CSS has gotten much easier with flexbox/grid. However, centering in HTML only became hard because tables were abandoned as the layout mechanism. Sure, they're not "semantic". But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc.

Configuring cloud infrastructure, with Terraform

Again, there used to be no Cloud infrastructure to configure. Personally, I find Terrafrom annoying more than anything else.

Setting up a dev environment, with Docker

As opposed to doing what? Keeping my dev environment simple is a constant battle and most of the time Docker is the weapon used by the other side. In 00s my dev environment was a text editor and some upload tool.

I haven't used PHP in well over a decade, but for my latest personal project I've decided to brush up on PHP 8.1. Despite awful syntax, I can do stuff by writing a handful of lines of code in a text editor. It's very refreshing. 100% focus on the outcome rather than tooling.

tele_ski2• 4 years ago

I've been on teams that haven't used docker for dev envs and teams that do in the last 5~ years. The teams that used docker were significantly more productive since each dev env was a replica and forced the team to maintain a common env. The dev env drift without it is huge and causes so many "it works on my machine". I can see a one man show or maybe two not needing a docker dev env but any sizable team IMO it is absolutely required now. You're absolutely right that it is a hoop to jump through, but its a hoop I find very necessary.

taeric5• 4 years ago

Oddly, my experience is a mixed bag here. Teams I've been on that went for rigid standardization with docker have largely been much harder to upgrade than those that allow local dev however the dev wants.

This is subtle. There are more bumps along the way. However, the task of upgrading isn't neglected forever. Instead, it usually seems that each new member winds up upgrading some small piece and making sure the code works with a small change in environment.

tsm• 4 years ago

I've worked on Rails, Node, and Clojure teams where Docker was optional and was always glad I avoided it. There has never been something important in my dev environment[1] that couldn't be responsibly managed by rbenv and bundler (or their equivalents for other languages).

[1] The one exception is SQL DBs and redis, but I have always been fine using brew, linuxbrew, or apt for them.

nirvdrum• 4 years ago

How did you handle differences in macOS/Windows and Linux? The last team I was on that tried to do all local development in Docker kept running into breakages. To allow the devs to use whatever editor or IDE they wanted, the source code was stored in the host system and mounted as a Docker volume. While that sounds simple, it's amazing how many times things broke depending on who set it up.

By default, Docker runs everything as root. This isn't a huge problem on macOS or Windows, where Docker runs in a VM and there's some sort of UID mapper mediating things. If a file is generated from a process within Docker (e.g., temporary or log files) and you're running in Linux, now you have files in your local system that you can't edit without "sudo". Fine, don't run the container as root. I'd have expected that to be a best practice, but it doesn't come up in Docker's best practices guide [0]. Adding our own user and switching to that isn't a huge hurdle, although this didn't seem to be an area that we'd have to chart our own path. Unfortunately, some 3rd party images don't run particularly well, if at all, if not run as root.

Once we got that running, we hit our next issue. Although things were working well for one developer, they broke for another because there still existed the same basic problem with Linux users ending up with files owned by UIDs other than their local account. It turns out that not every dev is running with the same UID. Okay, so now we need to map the UID and GID at image build time, but that might break things for people on macOS.

All of our Dockerfiles ended up with something like:

  ARG app_user_uid=61000
  ARG app_user_gid=61000
  ENV APP_USER="app"
  RUN groupadd -g $app_user_gid -o $APP_USER
  RUN useradd --no-log-init --create-home --shell /bin/false --gid $app_user_gid --uid $app_user_uid -o $APP_USER

And needed to be built on Linux with:

  docker-compose build --build-arg app_user_uid=$(id -u) --build-arg app_user_gid=$(id -g) ...

While macOS users used the simpler:

  docker-compose build ...

This all took quite some time to figure out. The person working on it would get things working, think it was all good, push it up, and only find out later that it wouldn't work on another dev's system. CI couldn't catch everything. The point of using Docker was to ensure there weren't inconsistencies against dev environments and that dev matched production. That seems like a fairly common use case, but we couldn't find anything on how to simplify this setup for teams other than mandating every user run the same exact system configuration. I have to believe we were doing something wrong, but we really couldn't find anything on the topic. I'd love to hear how you solved the problem.

[0] -- https://docs.docker.com/develop/dev-best-practices/

mwcampbell5• 4 years ago

But we're talking about what became easier, right? Not about what became more ideologically correct, semantic, etc.

Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance).

I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doesn't directly affect many of us so we tend to ignore it.

taeric5• 4 years ago

Sorta. Screen readers, being external programs, really had no trouble dealing with tables. The tag wasn't semantic, sure; but the intent and reasoning wasn't exactly difficult.

I suspect that the giant explosion in primitives for a screen reader to deal with had actually made the job harder.

And this is ignoring the explosion in nested divs that most modern sites have.

UglyToad• 4 years ago

Out of curiosity what were the

[...] gotchas of .NET Core async/await APIs drove me away.

I kind of lost track of the framework to core changes but I think it became simpler with the removal of synchronization contexts?

MaXtreeM• 4 years ago

Async/await is not for parallelism.

dehrmann• 4 years ago

The article actually said "concurrency." In the case of the article, it's being oversold because it's not that much better than the old one thread per request model. Cross-request interactions are rare, so you're more or less writing the same code, only with async, you have to be careful not to accidentally do something CPU-intensive for 50ms, and if your runtime supports multiple cores (so not Ruby or Python), you still have to be careful with race conditions and locks.

Writing parallel code that isn't clearly a divide and conquer variant is hard. Async doesn't help with that at all; it gives you more efficient context switches.

I personally find threaded code easier to reason about because there can be a context switch anywhere, so you always need to think about locks and coordination. With aysnc code, a block of code without locks and be correct...until you add an await in the middle, and this isn't always obvious.

BenoitEssiambre• 4 years ago

Yeah I may be the only one, but I still think async/await was a huge missed opportunity to get rid of promises like I proposed here for javascript:

https://es.discourse.group/t/callback-based-simplified-async...

It seems quite inneficient to me to wrap every function call in a caching layer and state machine that pretty much goes unused in the context of async/await and makes things unecessarily hard to undertand for new programmers.

nokamok• 4 years ago

Easy doesn’t (always) equal good.

oefrha2• 4 years ago

Cross-compilation (Go and Rust ship with cross-compilation support out of the box)

That's not right? Go has builtin cross-compilation. Rust does not, you need to bring your own cross toolchain even after adding rust-std for the target with rustup, unless there are recent changes I'm not aware of.

steveklabnik4• 4 years ago

It works for pure Rust code but once you bring in C, you need another tool chain too. Same as Go, as far as I know.

Zig has both beat right now, as you do not need anything else in either case.

oefrha2• 4 years ago

Oh, my bad, now that I think about it, all my Rust projects have -sys dependencies so I somehow assumed a cross toolchain is always required.

glandium2• 4 years ago

Even if you don't bring in C, you need a cross linker and some libraries to link against. Rust doesn't come with those, except maybe for the mingw target.

CTmystery• 4 years ago

Fun list. The only nitpick I have is for Spark. I would not consider it easy at all. From my experience, team members that needs to come up to speed on Spark usually take about a month to do so.

firefly284• 4 years ago

Writing code that runs on GPU in the browser (maybe with Unity?)

Is the author referring to WebAssembly ?

eatonphil6• 4 years ago

WebGPU? https://web.dev/gpu/

pleb_nz• 4 years ago

I would love to see the reverse of this 'things that used to be easy and are now hard'

That would be an interesting read

pphysch• 4 years ago

- registering internet resources (e.g. IPv4 block or desirable domain), due to scarcity

- various features that are harder to implement due to changing user/regulator expectations (from simple websites to stuff like GDPR)

- multimedia in the browser post-Flash, pre-WASM

fenesiistvan• 4 years ago

- sending emails (spam filters)

- publishing apps (app store / google play rules)

crummy• 4 years ago

I think browser security has made a lot of stuff harder. E.g. CORS has made loading JSON off a remote server harder, chrome now won't load mic/webcam feeds off non-HTTPS.

(Not saying these are bad things! Just annoyances I've run into during development.)

perlgeek• 4 years ago

* Running any website with user-contributed content. Spam is just everywhere nowadays, and you cannot publish a simple hiscore list for your game anymore without some kind of anti-spam measures, otherwise the spammers find it astonishingly fast and flood it with spam, even if it doesn't allow any clickable links

* Thinking about it some more, everything related to security. Back in the days, the whole Internet wasn't port-scanned for known vulnerable services multiple times a day, and you could get much further with less refined security practices.

* Drawing things on screen. Back in the days of DOS and QBasic, it was just a single line of code to put the screen into a different mode and start to paint lines and rectangles on it, placing text at certain coordinates. Now you have to have a GUI (though canvas elements in web pages make it a bit simpler again; still not quite as simple as in the 80s/90s)

* Getting access to a particular memory location, without layers and layers of virtualization in between

tester7562• 4 years ago

Thinking about it some more, everything related to security.

wasn't it more like "nobody gave a f back in the days"? :P

Back in the days, the whole Internet wasn't port-scanned for known vulnerable services multiple times a day, and you could get much further with less refined security practices.

what years are you talking about? seems like a lot of decades ago

scotty79• 4 years ago

Maybe OpenGL?

Nowadays to draw a triangle you have to write, compile and attach two shaders written in it's own separate language that interface with the main code

actuallyalys• 4 years ago

I'm not sure about drawing things on screen, actually. There are still tools similar to QBasic: Processing and Python's turtle module, in particular.

jonnycomputer2• 4 years ago

Logging in.

jonnycomputer2• 4 years ago

Submit and post a link to submission here. I'll vote it up.

slyall• 4 years ago

Running your own email server. Receiving email is easier since mail routing and spam filtering has matured. But sending email is now hard with authenticating yourself everywhere and making sure you are not blocked by the big providers.

I'd also say that even with letsencrypt it is harder to setup a web server than 10 years ago when you didn't need https at all.

mikewarot• 4 years ago

Writing programs that most users could run. It used to be a matter of firing up Delphi, moving some widgets around in a form, writing event handler code, and compiling. The install builder had it all done in less than an hour. It would run on almost any Windows PC in the world.

Now everything has to do Unicode, be piped through the internet, work on MacOs, Linux, Windows, iOS, Android and the web.

anthk5• 4 years ago

Lazarus works on Linux, Windows, Mac and even Win 9x.

remus• 4 years ago

I think you can argue this one either way. For example, I would say that writing a little html+js calculator web app these days is very easy and works on billions of devices around the world (approx anything with a web browser and an internet connection). I'd say this is reaching more users more easily than your delphi example.

ospider• 4 years ago

Search.

In the past, Google just works. Nowadays, Google must be used with uBlacklist or something like that to yield decent results.

hiepph• 4 years ago

Back then you had a few programming languages. Now you have hundreds to make a decision.

Back then you had a few tech stacks. Now you have thousands to choose from.

dan_hawkins• 4 years ago

Creating and publishing animated/interactive stuff (aka Flash.)

tomaloner2• 4 years ago

There's another facet I've watched with interest:

> Building videogames, with Roblox / Unity

This has resulted in something like 90 new games entering Steam every day. While some games may still be art, they're increasingly difficult to find among the noise. I've heard the mobile game market is in worse shape[1] by the deluge of games. "More games for everyone!" sounds great - but note that definitely doesn't mean more "good" games - or more "innovative" games all the while encouraging rampant copying/stealing of ideas.

[1] https://www.youtube.com/watch?v=Q30qZSEnI9Q

CharlesW• 4 years ago

Is there a law for "when a thing becomes easier and/or cheaper to do, more of that thing is created, and the mean quality of that thing goes down"? Of course, there are positive effects as well — desktop publishing was responsible for countless design crimes, but it also unlocked some real innovation during print's last stand.

milesward• 4 years ago

Jevon’s Paradox

taylorlunt• 4 years ago

The mean quality goes down, but the total number of games above a certain threshold goes up, which makes discoverability a bigger problem than it used to be, but, assuming we can solve that problem, makes the gaming industry better.

ChrisMarshallNY3• 4 years ago

Writing GUI apps for Apple products.

Too many variables to mention, but I wrote my first Apple application in 1986. It took several weeks, and wasn't much to look at.

These days, I can spin out a full-fat, shippable app, in a couple of hours. I do that all the time, for my test harnesses.

freedomben3• 4 years ago

I would extend this to GUI apps for every system. Even GTK apps on Linux have gotten there.

fsflover2• 4 years ago

Related recent discussion: https://news.ycombinator.com/item?id=30364337.

nly• 4 years ago

Packaging is still a nightmare if you want to ship closed source binaries on Linux.

Too many options (flatpak, apt, rpm, appimage, snap). No simple "please turn this directory tree in to a package" options. Dependency hell due to lack of binary compatibility (and no simple way of putting DLLs in the app directory like on Windows or in the dpkg like on macOS).

andrewstuart• 4 years ago

> These days, I can spin out a full-fat, shippable app, in a couple of hours.

How do you do that? What's your approach?

ChrisMarshallNY3• 4 years ago

I write native MVC, using Swift, UIKit/AppKit/WatchKit, and storyboards (I'll get around to SwiftUI, but it's not a hurry).

If you do that, the template is basically a functional app, and you really just need to tweak the storyboard, and supply any ViewControllers. Most of the time spent, is in Adobe Illustrator, generating graphic assets.

Most of my test harnesses are simple, 1-screen apps (with a couple of significant variations). I did, however, use the test harness apps for my BlueThoth library[0], as the starting points for the various Blue Van Clef apps[1] (Bluetooth browser apps for all Apple platforms -yes, you can use your Apple Watch or AppleTV to sniff BLE).

I also have a lot of published modules[2] that help mitigate a lot of the “niggles,” involved in app development. That probably helps a ton.

To be fair, if I am actually shipping an app, as opposed to just using it as a test harness, I spend a lot more time on it, than a couple of hours. I've been working on the app I'm currently developing, for over a year and a half.

[0] https://riftvalleysoftware.com/work/open-source-projects/#bl...

[1] https://apps.apple.com/us/developer/rift-valley-software-inc...

[2] https://riftvalleysoftware.com/work/open-source-projects/

fiddlerwoaroof• 4 years ago

I used to do this on Windows in the 90s with Delphi: this is only really remarkable because we lost all the good tools somewhere along the way.

mwcampbell5• 4 years ago

Languages that are good at arbitrarily composing many modules into a stand-alone executable are becoming more popular. Rust is my favorite; one can even package wrappers over C or C++ libraries in a way that fits seamlessly into the cargo build process. Go is good here as well, as long as you stick to pure Go. As soon as you introduce cgo, that adds a hurdle for any user of the library, particularly on Windows. Zig looks like it's on the right track, though we still have to wait and see what the package manager will look like. And I'm sure there are others.

We also don't know yet if any of these languages will develop strong ecosystems for rapid GUI development.

And of course, Lazarus (for Free Pascal) is still a thing, though it doesn't have hype, or more importantly, large mindshare.

kwhitefoot• 4 years ago

I wrote plenty of GUI applications for IBM PCs in the '80s. It wasn't difficult with Turbo Pascal.

ChrisMarshallNY3• 4 years ago

When Turbo Pascal came to the Mac, it made life MUCH easier. I started with MPW.

What was always difficult, was the toolkit. Apple had MacApp (but not when I started). In fact, the original Adobe Photoshop was a Pascal/MacApp (1.0b9) app.

throwthere• 4 years ago

Visual Basic 6.0 chiming in from the 90s.

henvic• 4 years ago

VPNs, with Wireguard

I'd say: Tailscale.

I'd also add Kafka for integrating different systems/databases, etc.

tooltower• 4 years ago

What a great list of "Things I've been meaning to learn for years!"

I was all hip and cool once, and now feel like a dinosaur. This should help me catch up

Etheryte2• 4 years ago

I would also add something along the lines of "building big webapps". Large frontend codebases used to be scary Lovecraftian horror where things were only touched out of utmost necessity. Runtime errors for weird corner cases. Dangling dependencies that no one could figure out whether they're safe to update/remove or not. Refactoring was both an art and an arcane incantation at the same time. Modern tooling and best practices have made most if not all of these problems nearly non-existent, and I'm grateful for it.

freedomben3• 4 years ago

Oh man, this brings back nightmares of upgrading jQuery, and third party components that were copy/pasted into the codebase and modified/customized. Large frontend codebases are indeed miles ahead of where they used to be.

earthboundkid3• 4 years ago

The step backwards is that before, you couldn’t upgrade jQuery because the CDN script tag was on thirteen different partials, and you weren’t sure which were still in use, and now you can’t upgrade React because it depends on v4.3.2 of chalk-babel-duster-pack-plugin and that’s insecure but it has a breaking change in v5 you don’t know how to fix, so you’re just waiting for a total rewrite of the app to pull out CRA and replace it with Vite or some such.

georgeecollins• 4 years ago

The first commercial game I ever designed was built on a custom made 3d render. All sorts of things you do in harware now had to be done in code and you could seriously push like 1k triangles at 20 fps. And that was really good! It took the smartest programmers I have ever known to get that to work on a 486.

Now you have Unity, Unreal and hardware acceleration.

theonemind• 4 years ago

Regarding chocolate quality discussions: when Hersey started up, they couldn't get any European chocolatiers to share their process, so they had to invent one. They used lipolysis, which creates butyric acid, the chemical that gives vomit its distinctive smell and aftertaste.

You can definitely taste it if you pay attention, like "yep, that's it, it's that vomit aftertaste."

https://www.google.com/search?q=hershey+vomit

WillPostForFood• 4 years ago

Interesting article that suggests the context in which you smell the same scent is almost entirely determinant of your response to it:

Moreover, motivational responses were entirely different as a function of label. For example, when isovaleric + butyric acid was called “parmesan cheese” it inspired participants to say they would like to eat it, while when it was given the negative label (“vomit”) it provoked the wish to escape from it. The effect was so strong for certain odors, that participants could not believe that the same odorant had been presented to them at both sessions

https://web.archive.org/web/20090203043112/http://www.senseo...

PolygonSheep• 4 years ago

Yeah I've noticed this too. Everyone says Hershey's tastes like vomit but you never see anyone calling Parmesan cheese "vomit cheese".

astura• 4 years ago

Rounded corners and gradients on the web. When I started both required background images, now they are just a css property.

eatonphil6• 4 years ago

That's right! I almost forgot about needing background images.

mahoro2• 4 years ago

Wow! Let me continue :)

- Text-to-speech and vice versa, using cloud APIs. - creating a solid objects from 3D models (3d printing) - messaging: pub/sub, message buses (kafka, redis, postgresql channels, rabbitmq etc) - advanced data structures are more available (sets/hashes/etc now in standard libraries of any language, and in many databases)

Things that surprisingly still a pain: - scanning documents preserving formatting (there are niche solutions but they are too expensive for a person who needs it a couple times a year)

raleigh_littles• 4 years ago

Elaborate a little bit on what you mean by "preserving formatting"?

mahoro2• 4 years ago

When you scan a document with tables, indentation and get exactly the same document in, say, docx format.

I know there are solutions from ABBY but to me they are too complex and probably expensive (checked the price several years ago).

Aqueous• 4 years ago

While I agree that many of these items are way easier than before, it still comes at a cost. Making a lot of these things easy has actually caused new problems that are once again, hard, mostly because of emergent complexity. For instance - configuring cloud infrastructure declaratively has made it very easy to stand up vast numbers of computational instances and distributed systems that now have to be reasoned about, monitored and managed effectively. CI/CD pipelines means we are able to deploy code way more quickly and efficiently and with less manual testing, likewise causing an explosion in complex business logic that's been deployed. If you're not careful, the complexity enabled by these developments can quickly overwhelm you and your team.

digitalsanctum• 4 years ago

Perhaps a good follow-on thread would be new things that have solved multiple other things that use to be hard or impossible.

For example, Rust comes to mind as something that has improved error messages, elimination of most memory-related bugs and "fearless concurrency." All while being fast and having support for cross compilation.

jbpnoy6fifty• 4 years ago

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 society.

Cool stuff really.

monktastic1• 4 years ago

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

mchusma• 4 years ago

Developing for mobile is so much easier overall with the Ionic framework.

It's not for every application but I would say most applications it's great for. My first startup we needed iOS, Android, and web teams. For my current startup, we have one frontend team using Ionic/Angular and we just deploy to all 3 places with the same codebase.

midislack• 4 years ago

Laundry list of terrible stuff.

Let's Encrypt is a headache and roots your box.

Concurrency was solved eons ago with common libraries widely used today. Erlang has had it as a design requirement since the beginning.

Centering in CSS! Heck isn't that just an HTML tag?

Building fast programs... with a certain language. Admitting it's slow? I don't get it.

I could go through the whole little list like this.

daxfohl2• 4 years ago

I'll add, "knowing what you're worth". I keep thinking levels.fyi, blind, etc. are underappreciated in their value as "disruptive" initiatives of the last few years, and will have a far greater social impact than bitcoin, self-driving cars, etc.

Corrado• 4 years ago

What about spooling up 10,000 servers to do a job and then deleting them when it's finished? I've literally done this for image processing and it's not something that I could ever have done in the past.

singularity2001• 4 years ago

  >>> VPNs, with Wireguard

Just tried it on iOS, please scratch it from the list

orsenthil2• 4 years ago

One thing, I will like to add this. Learning new things and gaining mastery has become approachable too. Note, it is approachable, and as gaining mastery is intensely personal endeavor.

Learning new things via youtube, coursera, udemy, udacity, edx, many things. Mastery via project based learning, Github, tests in courses, certification exams, exercism, etc.

terom• 4 years ago

I would add also PCBs for hardware prototyping. Ordering custom PCBs is ridiculously cheap and easy now.

JattMannu• 4 years ago

I use to have a very boring job of compareing 2 forms and check for discrepancy. Quite a meaning less job nowday We just use tools like

https://www.freetextcompare.com/

Things that used to be hard and are now easy

Related Stories