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

Things that used to be hard and are now easy

jvns.ca

Post reply on HN
Print view View original

201–210 of 316 posts

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

#201

Post by ChrisMarshallNY »

andrewstuart wrote: post #196
ChrisMarshallNY wrote: post #165

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.

>> 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?

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/

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

#202

Post by FearlessNebula »

learc83 wrote: post #171
FearlessNebula wrote: post #105

Earlier quoted context omitted.

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.

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

I’m too young to know from my own experience but from what I’ve heard early 2000s.

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

#203

Post by axiosgunnar »

bonoboTP wrote: post #159
dimgl wrote: post #83

Earlier quoted context omitted.

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.

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 laye…

I understand you manually manage the kernel and wrote your own TCP library? I sure hope you didn‘t just pass all of that complexity down!

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

#204

Post by madmax96 »

reidjs wrote: post #7

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 knowledg…

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

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

#205

Post by Aqueous »

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.

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

#206

Post by digitalsanctum »

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.

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

#207

Post by earthboundkid »

freedomben wrote: post #183
Etheryte wrote: post #178

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…

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.

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.

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

#208

Post by chrisseaton »

smilekzs wrote: post #145
eatonphil wrote: post #25

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

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

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

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

#209

Post by taeric »

mwcampbell wrote: post #169
taeric wrote: post #149

Earlier quoted context omitted.

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.

Considering that I've developed a screen reader from the ground up, worked on the Narrator screen reader shipped with Windows, and routinely used screen readers to browse the web for almost 20 years, I think I know a thing or two about this. So, it's true that screen readers have heuristics for detecting layout tables. But those heuristics aren't perfect. They're not even that sophisticated, at least the ones that I…

This feels inline with what I intended. Used sparingly, tables probably weren't that atrocious to figure out. Similarly, deliberate use of semantic tags is likely better. I question if things are deliberate are much better now. But, you provide a convincing and authoritative answer there.

Html email feels like a trap. They are about turning up the volume and getting returns. Not about being accessible. Is that not the case?

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

#210

Post by taeric »

kalensh wrote: post #161
taeric wrote: post #149

Earlier quoted context omitted.

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.

It really depends. If table cell order happens to conform with a logical reading order, yeah, screen readers generally figured out when to ignore table semantics. But if the reading order does not make sense going row by row, then they are terribly broken. Nested divs aren't that bad. (Ignoring overall performance considerations. And even then I'd suspect that's less a concern than download and running all these JS l…

Right, my complaint in nested divs is more when they are a giant mix of different levels with no real discernable logic at the markup level. I think my memory is more from the garbage we made in early 2000s, though. I haven't tried to look at any modern page markup lately.
Post reply on HN