22 ms·

Things that used to be hard and are now easy

371 points by pingiun 5y ago

pleb_nz 5y 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 5y 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 5y ago
    - sending emails (spam filters) - publishing apps (app store / google play rules)
- crummy 5y 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 5y 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
  - tester756 5y 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 5y 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 5y 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.
- jonnycomputer 5y ago
  Logging in.
- jonnycomputer 5y ago
  Submit and post a link to submission here. I'll vote it up.
- slyall 5y 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 5y 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.
  - anthk 5y ago
    Lazarus works on Linux, Windows, Mac and even Win 9x.
  - remus 5y 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 5y ago
  Search. In the past, Google just works. Nowadays, Google must be used with uBlacklist or something like that to yield decent results.
- hiepph 5y 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 5y ago
  Creating and publishing animated/interactive stuff (aka Flash.)
myself248 5y ago
Until "large prime factorization" makes this list, I think we're cool.
adrift 5y ago
"Building fast programs, with Go/Rust" Sure, bud.
- adamnemecek 5y ago
  They are both so much more pleasant to work with than C.
  - anthk 5y 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.
    - adamnemecek 5y ago
      > 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++.
      - anthk 5y ago
        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.
        adamnemecek 5y ago
        > 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.
        anthk 5y ago
grishka 5y ago
> Building cross-platform GUIs, with Electron How about no. I so want this abomination of a technology uninvented.
- shrimp_emoji 5y ago
  But it's the only reason Discord, Slack, VS Code, and other apps exist on operating systems other than Windows/MacOS.
  - grishka 5y ago
    Tbh the world would've been better off if these apps didn't exist. Especially VS Code.
    - adwn 5y ago
      > Tbh the world would've been better off if these apps didn't exist. Especially VS Code. You're confusing "I personally don't like X" with "the world is better off without X".
    - shrimp_emoji 5y ago
      >Especially VS Code. Why? :c The next best thing is Atom. And, tragically, Atom is way worse. (Believe me, I wanted it to win the hackable-lite-IDE war, but... it didn't.) I don't like Microsoft, but VS Code won. Although, technically, I use "Code - OSS", which is the no-proprietary-code version.
      - grishka 5y ago
        Atom is also Electron-based. Why Electron text editors at all? I personally use Sublime and vim and don't even consider the electron ones.
        shrimp_emoji 5y ago
        If Sublime is as good, then you got me. :p (I can't say; I still need to try it.) I love Kate, although it's less configurable/powerful than Code/Atom, but it's Linux-only. As to vim, I use it for quick things, but I'm not hardcore enough to feel comfortable with editing in a terminal and having to re-memorize how to highlight and copy-paste text.
jacobmartin 5y 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.
- deleted 5y ago
  [deleted]
- iforgotpassword 5y 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.
deleted 5y ago
[deleted]
reidjs 5y 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 5y ago
  Scaling from 0 to 1 user? Is this a personal project?
  - reidjs 5y ago
    Nope
- teaearlgraycold 5y ago
  What is there even to migrate??
- unnouinceput 5y 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 5y 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.
  - freedomben 5y 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.
theden 5y 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.
- FearlessNebula 5y 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.
eatonphil 5y 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 5y ago
  CPython appears to use a PEG parser for its implementation: https://github.com/python/cpython/blob/b77158b4da449ec5b8f682816a79d004fd65ed07/Grammar/python.gram https://github.com/python/cpython/blob/b77158b4da449ec5b8f68...
  - eatonphil 5y ago
    That's true, but it's still quite rare to see.
  - UncleEntity 5y 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.
    - eatonphil 5y ago
      No they moved from pgen, a custom parser generator, to this PEG parser. The parser was never handwritten.
- TheCondor 5y 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.
lopis 5y 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.
- orsenthil 5y ago
  When was that XKCD published (https://xkcd.com/1425/ 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 5y ago
    September 24th, 2014. To know the date of publication of a given xkcd comic, go to https://xkcd.com/archive/ https://xkcd.com/archive/, search for the title you're after, then the date of publication is displayed in the mouse-over text.
    - elygre 5y ago
      So, five years and a pandemic. Not too shabby of a prediction, that!
- paulnpace 5y ago
  Somewhat relevant: TornadoGuard https://xkcd.com/937/ https://xkcd.com/937/
- nerdponx 5y 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".
ignoramous 5y 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.html https://kotlinlang.org/docs/composing-suspending-functions.h...
- tonyedgecombe 5y 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 5y 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)
  - ignoramous 5y 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 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 }
wackget 5y 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.
- unnouinceput 5y 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 5y 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.
  - Too 5y 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.
  - kingcharles 5y ago
omarhaneef 5y 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.
- ghaff 5y ago
  There is probably a "Law" to the effect of "The complexity of the task increases to the limits of the current tooling."
  - anticensor 5y ago
    Parkinson's law: "Work expands to fill available time".
globalise83 5y ago
IE support for JS/CSS has been massively simplified by not supporting IE any more.
- nozzlegear 5y 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.
- earthboundkid 5y ago
  I browsed the Washington Post and NYTimes with IE11 the other day and was pleased to see they looked like absolute garbage. :-)
buescher 5y 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 5y ago
I find the serverless frontend to be way more tedious than a monolith approach.
antirez 5y 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 5y 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.
  - sillysaurusx 5y ago
    Why do you feel that way?
  - antirez 5y 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 https://news.ycombinator.com/item?id=30406644
    - Etheryte 5y ago
      They got downvoted not because of their disagreement, but because their comment was low quality. "Sure, bud." is a mere quip and doesn't add anything substantial to the discussion.
      - 5y ago
throwawaaaaay17 5y ago
NLP with HuggingFace
- jvns 5y 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 :)
nokamok 5y ago
Easy doesn’t (always) equal good.
romaniv 5y 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_ski 5y 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.
oefrha 5y 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.
- steveklabnik 5y 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.
  - oefrha 5y 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.
    - steveklabnik 5y ago
      Yeah. C deps are culturally tolerated by Rustaceans more than Gohers, so it can feel like this even if it isn’t literally the case.
  - glandium 5y 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.
    - steveklabnik 5y ago
      I don't think of downloading the libraries as being a "cross toolchain", but that is true. Common cross-compiled components default to lld, which is a cross linker. That said, yes, there are some *s here depending on what exactly you're doing.
deleted 5y ago
[deleted]
CTmystery 5y 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 5y ago
> Writing code that runs on GPU in the browser (maybe with Unity?) Is the author referring to WebAssembly ?
- eatonphil 5y ago
  WebGPU? https://web.dev/gpu/ https://web.dev/gpu/
tomaloner 5y 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 https://www.youtube.com/watch?v=Q30qZSEnI9Q
- CharlesW 5y 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 5y ago
    Jevon’s Paradox
    - jrc2022 5y ago
      wikipedia : In economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons' effect) occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
      - gwern 5y ago
        I would call it just "demand elasticity". Jevons paradox is a subset of demand elasticity where there happens to be some relatively fixed 'resource' like oil. There's no 'resource' equivalent for something like video gaming; it's just demand for writing games is elastic and when a game gets easier to build, people demand more supply, which comes into existence then.
ChrisMarshallNY 5y 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.
- freedomben 5y ago
  I would extend this to GUI apps for every system. Even GTK apps on Linux have gotten there.
  - fsflover 5y ago
    Related recent discussion: https://news.ycombinator.com/item?id=30364337 https://news.ycombinator.com/item?id=30364337.
  - nly 5y 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 5y 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?
  - ChrisMarshallNY 5y 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/#bluethoth https://riftvalleysoftware.com/work/open-source-projects/#bl... [1] https://apps.apple.com/us/developer/rift-valley-software-inc/id1448933102 https://apps.apple.com/us/developer/rift-valley-software-inc... [2] https://riftvalleysoftware.com/work/open-source-projects/ https://riftvalleysoftware.com/work/open-source-projects/
henvic 5y ago
> VPNs, with Wireguard I'd say: Tailscale. I'd also add Kafka for integrating different systems/databases, etc.
tooltower 5y 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
Etheryte 5y 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.
- freedomben 5y 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.
  - earthboundkid 5y 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.
    - nicoburns 5y ago
      Or you can avoid CRA in the first place. CRA is frankly a hot mess. But React itself, and for the most part even Webpack are quite reasonable.
      - prashaantt 5y ago
        What are your issues with CRA?
    - gdulli 5y ago
georgeecollins 5y 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 5y 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 https://www.google.com/search?q=hershey+vomit
- WillPostForFood 5y 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.senseofsmell.org/feature/odor/odor_whitepaper_3.php https://web.archive.org/web/20090203043112/http://www.senseo...
  - PolygonSheep 5y ago
    Yeah I've noticed this too. Everyone says Hershey's tastes like vomit but you never see anyone calling Parmesan cheese "vomit cheese".
- avgcorrection 5y ago
astura 5y ago
Rounded corners and gradients on the web. When I started both required background images, now they are just a css property.
- eatonphil 5y ago
  That's right! I almost forgot about needing background images.
mahoro 5y 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 5y ago
  Elaborate a little bit on what you mean by "preserving formatting"?
  - mahoro 5y 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 5y 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 5y 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 5y 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 5y ago
  The flip side is that because we treat cheap things as disposable, we are accelerating the collapse of the biosphere.
mchusma 5y 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 5y 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.
daxfohl 5y 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 5y 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 5y ago
>>> VPNs, with Wireguard Just tried it on iOS, please scratch it from the list
orsenthil 5y 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 5y ago
I would add also PCBs for hardware prototyping. Ordering custom PCBs is ridiculously cheap and easy now.
JattMannu 5y 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/ https://www.freetextcompare.com/

371 points by pingiun 5y 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 5y 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 5y ago
  - sending emails (spam filters) - publishing apps (app store / google play rules)
crummy 5y 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 5y 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
- tester756 5y 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 5y 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 5y 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.
jonnycomputer 5y ago
Logging in.
jonnycomputer 5y ago
Submit and post a link to submission here. I'll vote it up.
slyall 5y 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 5y 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.
- anthk 5y ago
  Lazarus works on Linux, Windows, Mac and even Win 9x.
- remus 5y 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 5y ago
Search. In the past, Google just works. Nowadays, Google must be used with uBlacklist or something like that to yield decent results.
hiepph 5y 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 5y ago
Creating and publishing animated/interactive stuff (aka Flash.)

myself248 5y ago

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

adrift 5y ago

"Building fast programs, with Go/Rust" Sure, bud.

adamnemecek 5y ago
They are both so much more pleasant to work with than C.
- anthk 5y 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.
  - adamnemecek 5y ago
    > 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++.
    - anthk 5y ago
      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.
      - adamnemecek 5y ago
        > 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.
        anthk 5y ago

grishka 5y ago

> Building cross-platform GUIs, with Electron How about no. I so want this abomination of a technology uninvented.

shrimp_emoji 5y ago
But it's the only reason Discord, Slack, VS Code, and other apps exist on operating systems other than Windows/MacOS.
- grishka 5y ago
  Tbh the world would've been better off if these apps didn't exist. Especially VS Code.
  - adwn 5y ago
    > Tbh the world would've been better off if these apps didn't exist. Especially VS Code. You're confusing "I personally don't like X" with "the world is better off without X".
  - shrimp_emoji 5y ago
    >Especially VS Code. Why? :c The next best thing is Atom. And, tragically, Atom is way worse. (Believe me, I wanted it to win the hackable-lite-IDE war, but... it didn't.) I don't like Microsoft, but VS Code won. Although, technically, I use "Code - OSS", which is the no-proprietary-code version.
    - grishka 5y ago
      Atom is also Electron-based. Why Electron text editors at all? I personally use Sublime and vim and don't even consider the electron ones.
      - shrimp_emoji 5y ago
        If Sublime is as good, then you got me. :p (I can't say; I still need to try it.) I love Kate, although it's less configurable/powerful than Code/Atom, but it's Linux-only. As to vim, I use it for quick things, but I'm not hardcore enough to feel comfortable with editing in a terminal and having to re-memorize how to highlight and copy-paste text.

jacobmartin 5y 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.

deleted 5y ago
[deleted]
iforgotpassword 5y 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.

deleted 5y ago

[deleted]

reidjs 5y 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 5y ago
Scaling from 0 to 1 user? Is this a personal project?
- reidjs 5y ago
  Nope
teaearlgraycold 5y ago
What is there even to migrate??
unnouinceput 5y 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 5y 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.
- freedomben 5y 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.

theden 5y 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.

FearlessNebula 5y 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.

eatonphil 5y 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 5y ago
CPython appears to use a PEG parser for its implementation: https://github.com/python/cpython/blob/b77158b4da449ec5b8f682816a79d004fd65ed07/Grammar/python.gram https://github.com/python/cpython/blob/b77158b4da449ec5b8f68...
- eatonphil 5y ago
  That's true, but it's still quite rare to see.
- UncleEntity 5y 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.
  - eatonphil 5y ago
    No they moved from pgen, a custom parser generator, to this PEG parser. The parser was never handwritten.
TheCondor 5y 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.

lopis 5y 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.

orsenthil 5y ago
When was that XKCD published (https://xkcd.com/1425/ 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 5y ago
  September 24th, 2014. To know the date of publication of a given xkcd comic, go to https://xkcd.com/archive/ https://xkcd.com/archive/, search for the title you're after, then the date of publication is displayed in the mouse-over text.
  - elygre 5y ago
    So, five years and a pandemic. Not too shabby of a prediction, that!
paulnpace 5y ago
Somewhat relevant: TornadoGuard https://xkcd.com/937/ https://xkcd.com/937/
nerdponx 5y 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".

ignoramous 5y 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.html https://kotlinlang.org/docs/composing-suspending-functions.h...

tonyedgecombe 5y 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 5y 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)
- ignoramous 5y 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 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 }

wackget 5y 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.

unnouinceput 5y 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 5y 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.
- Too 5y 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.
- kingcharles 5y ago

omarhaneef 5y 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.

ghaff 5y ago
There is probably a "Law" to the effect of "The complexity of the task increases to the limits of the current tooling."
- anticensor 5y ago
  Parkinson's law: "Work expands to fill available time".

globalise83 5y ago

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

nozzlegear 5y 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.
earthboundkid 5y ago
I browsed the Washington Post and NYTimes with IE11 the other day and was pleased to see they looked like absolute garbage. :-)

buescher 5y 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 5y ago

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

antirez 5y 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 5y 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.
- sillysaurusx 5y ago
  Why do you feel that way?
- antirez 5y 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 https://news.ycombinator.com/item?id=30406644
  - Etheryte 5y ago
    They got downvoted not because of their disagreement, but because their comment was low quality. "Sure, bud." is a mere quip and doesn't add anything substantial to the discussion.
    - 5y ago

throwawaaaaay17 5y ago

NLP with HuggingFace

jvns 5y 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 :)

nokamok 5y ago

Easy doesn’t (always) equal good.

romaniv 5y 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_ski 5y 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.

oefrha 5y 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.

steveklabnik 5y 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.
- oefrha 5y 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.
  - steveklabnik 5y ago
    Yeah. C deps are culturally tolerated by Rustaceans more than Gohers, so it can feel like this even if it isn’t literally the case.
- glandium 5y 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.
  - steveklabnik 5y ago
    I don't think of downloading the libraries as being a "cross toolchain", but that is true. Common cross-compiled components default to lld, which is a cross linker. That said, yes, there are some *s here depending on what exactly you're doing.

deleted 5y ago

[deleted]

CTmystery 5y 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 5y ago

> Writing code that runs on GPU in the browser (maybe with Unity?) Is the author referring to WebAssembly ?

eatonphil 5y ago
WebGPU? https://web.dev/gpu/ https://web.dev/gpu/

tomaloner 5y 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 https://www.youtube.com/watch?v=Q30qZSEnI9Q

CharlesW 5y 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 5y ago
  Jevon’s Paradox
  - jrc2022 5y ago
    wikipedia : In economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons' effect) occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand. https://en.wikipedia.org/wiki/Jevons_paradox https://en.wikipedia.org/wiki/Jevons_paradox
    - gwern 5y ago
      I would call it just "demand elasticity". Jevons paradox is a subset of demand elasticity where there happens to be some relatively fixed 'resource' like oil. There's no 'resource' equivalent for something like video gaming; it's just demand for writing games is elastic and when a game gets easier to build, people demand more supply, which comes into existence then.

ChrisMarshallNY 5y 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.

freedomben 5y ago
I would extend this to GUI apps for every system. Even GTK apps on Linux have gotten there.
- fsflover 5y ago
  Related recent discussion: https://news.ycombinator.com/item?id=30364337 https://news.ycombinator.com/item?id=30364337.
- nly 5y 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 5y 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?
- ChrisMarshallNY 5y 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/#bluethoth https://riftvalleysoftware.com/work/open-source-projects/#bl... [1] https://apps.apple.com/us/developer/rift-valley-software-inc/id1448933102 https://apps.apple.com/us/developer/rift-valley-software-inc... [2] https://riftvalleysoftware.com/work/open-source-projects/ https://riftvalleysoftware.com/work/open-source-projects/

henvic 5y ago

> VPNs, with Wireguard I'd say: Tailscale. I'd also add Kafka for integrating different systems/databases, etc.

tooltower 5y 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

Etheryte 5y 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.

freedomben 5y 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.
- earthboundkid 5y 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.
  - nicoburns 5y ago
    Or you can avoid CRA in the first place. CRA is frankly a hot mess. But React itself, and for the most part even Webpack are quite reasonable.
    - prashaantt 5y ago
      What are your issues with CRA?
  - gdulli 5y ago

georgeecollins 5y 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 5y 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 https://www.google.com/search?q=hershey+vomit

WillPostForFood 5y 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.senseofsmell.org/feature/odor/odor_whitepaper_3.php https://web.archive.org/web/20090203043112/http://www.senseo...
- PolygonSheep 5y ago
  Yeah I've noticed this too. Everyone says Hershey's tastes like vomit but you never see anyone calling Parmesan cheese "vomit cheese".
avgcorrection 5y ago

astura 5y ago

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

eatonphil 5y ago
That's right! I almost forgot about needing background images.

mahoro 5y 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 5y ago
Elaborate a little bit on what you mean by "preserving formatting"?
- mahoro 5y 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 5y 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 5y 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 5y 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 5y ago
The flip side is that because we treat cheap things as disposable, we are accelerating the collapse of the biosphere.

mchusma 5y 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 5y 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.

daxfohl 5y 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 5y 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 5y ago

>>> VPNs, with Wireguard Just tried it on iOS, please scratch it from the list

orsenthil 5y 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 5y ago

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

JattMannu 5y 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/ https://www.freetextcompare.com/