* 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.
* Finding honest product impressions/reviews.
* When looking for a configuration setting or tip to use any piece of software, find a one minute article with clear bullet points instead of an 11 minute YouTube video with a personal backstory and a VPN sponsorship.
* Finding a cooking recipe that isn’t padded with SEO nonsense.
* When finding an online discussion or blog article in a search result, being able to read it straight in the (mobile) browser without hostile prompts to make an account and/or download an app.
* (Europeans only.) Publish a simple website without worrying that the hosting provider you choose doesn’t perfectly conform to privacy laws that even lawyers won’t explain to you and you’re personally liable for ridiculous damages.
* Run software developed by hobby programmers on machines you own.
* Connect devices like speakers, keyboards and mice to computers. (Edit: You mention that.)
And, completely disagreeing with the article on this one point, this is also harder:
* Writing cross-platform UIs. As someone with a lot of hate for Java from back in the day, this is painful to write, but: Java Swing might not have produced the nicest GUIs, but the stack was so much simpler than Electron+Node+Express+Webpack+React+TypeScript (substitute Svelte, Vite or whatever you want), it’s not even funny.
I'm sorry but that's just FUD. GDPR fines are only for serious infractions with intent, most violators get off with a warning. Furthermore, access logs are OK because they're a legitimate purpose, as long as there's rotation.
I’ve recently tried to figure out if it’s okay to use something like Cloudflare Pages to host a blog. That’s not an esoteric question, but I was unable to get an answer. They’re not based in Europe, the log retention policy is a bit unclear, regulators seem to be disagreeing on whether even their CDN is okay (and Pages is built on top of the CDN). And in Germany, the real danger isn’t a regulator fining you, it’s a private lawyer sending you an “Abmahnung”. Which they will do for any trivial infraction, often using automated platforms.
At least when hosting with an European host.
One needs an imprint and data privacy page. But both is easy (except in specific cases like for MDs that need to add just a little bit of information in the imprint).
I support small businesses with their web activities. It did not get overly complicated through GDPR.
My wife lost her phone when we were on vacation and it was literally impossible for us to login into her Google account in order to use find my Android.
We were trying to login on a relative's PC to use find my phone, but it was a catch 22 because we need a phone to login to Google on a relative's PC.
I pity the fool who loses their phone in the age of 2FA.
ADDED: And thank you for mentioning that. I just realized I never transferred my Google authenticator setting to the new phone I got last year.
This keeps me awake at night. Especially as it is no longer possible to contact humans at a lot of sites to prove who you are. I went to jail for eight years, when I got out I could only access two of the thousands of accounts I had made over the previous 20 years.
> My wife lost her phone when we were on vacation and it was literally impossible for us to login into her Google account in order to use find my Android.
This is a really frustrating situation.
I needed 2FA to access company services. Email, chat, VPN etc. Which of course, was on my phone.
I emailed IT Support from my personal email to request a temp token. My ticket was closed, with a message saying "Email tickets are no longer accepted, use the service portal."
I needed 2FA to access the service portal.
Luckily I had a co-worker on a non-company chat service, so they opened a ticket on my behalf...
I am used to this from work but even there MS pesters me to install MS authenticator while I clearly always just use my regular 2fa solution.
And because I think the state of 2fa is not user friendly my own solution is not very secure by using Authy with a client on every device. So there is no second factor. I just copy paste from the app on my computer and don't need to grab my phone.
Privacy is a lost cause, the younger generations don't care.
I remember when people were warned about sharing their real information online. over 50% of people I knew were just nicknames on the internet. I had zero clue about their gender, where they lived or what they did for a living. Didn't affect our conversations the least bit.
Now everyone is plastering their faces everywhere they go. Every picture they take has their face next to it. Usually along with their name, the location and the exact time they were in there and who they were with.
Depends on the circles.
On the other hand, I accessed Usenet from a company computer which had my real name and company email. And the local forum on my BBS, most people used their real names and we even got together in person from time to time.
On Instagram, I've also noticed a lot of young people who share e.g. art have a completely anonymous profile (and I guess probably another, non-anonymous profile for their friends only).
Not sure about Snapchat or TikTok, though.
Let's say you want to keep your work, hobby and private profiles completely separate. You'd need to have one with the official client and the other two with a separate browser each. Also you'd need to be super careful when joining a new server for any category to make doubleplussure you're not joining with the wrong profile.
The dongles. OMG. It's worse than the parallel printer age. I cannot recall another period in history where I needed a dongle so often. USB-C only on Macbooks was such a huge design mistake. Especially in the era of USB-A! Soooooo many things are still USB-A. All for a little more thinness! It's really grating.
Not sure if this was ever easier, but to me it seems it got harder. With all the possible attack vectors, ranging from chain of supply attacks hard-coded deep down on the cpus, up to malicious dependencies being replaced everyday on npm, how does anyone trust their machine?
- they get money for selling static/public IPv4 addresses right now and they wouldn't want this money going away when IPv6 arrives
- can't imagine how the world will look like with shitty insecure routers everywhere and everyone having a public IPv6 address, ISPs might provide NAT connections to protect non-tech people
If I'm not mistaken, one of the largest ISPs in my country has begun to roll out IPv6 but it was either broken the last time I checked or it had some form of NAT on it.
Then again, given the contrarian bias of HN comments, I guess it's natural.
Though negotiating is way easier with things like levels.fyi and blind.
How about no. I so want this abomination of a technology uninvented.
Good enough beats perfect almost every time. The real fail is that the major desktop OSes have spent the last 20 years jockeying for a monopoly on how software is made on and distributed their platforms. Apple and MS (and even the Linux desktops to a lesser degree) want me to have to build and maintain completely separate apps for their platforms to unlock all of the capability in their GUI.
You know what I want as a user? I want to be able to buy Affinity Designer and run in on whatever device I have. I don't want to care about Mac, Windows, Linux Chromebook or whatever. I would love to have some real Adobe apps on Linux.
As a software developer, it's about time that we stop having the native vs. whatever universal GUI layer debate, too. I've never seen a single ticket for an Electron app where the user was reporting that my app wasn't MacOS-y or Windows-y enough. I have seen plenty of tickets with native apps where something isn't right with the clipboard, print menu or or some component wouldn't correctly embed on a paste.
Any semi-modern PC has no problem running Electron apps. Download sizes aren’t an issue with modern internet speeds. It doesn’t make sense to try to optimize for people with the slowest systems when everything is only getting faster.
Do you realize that you are essentially running a supercomputer? And that this supercomputer is struglling to display even the simplest things? Slack's CPU usage shoots up to 20% of cpu to display a single animated reaction to a post. Run a few of those "shouldn't have trouble" in parallel, and suddenly a computer that can run a 4k next-gen Unreal shooter at 60fps struggles to even maintain cursor latency.
I run more than two Electron apps at a time and everything is fine.
Unless you’re running ancient hardware with 4GB of RAM and trying to load up many intensive applications (Electron or otherwise) it’s not a problem. If anything gets “sluggish” then you’re probably swapping, but it’s difficult to actually reach that point with just two Electron apps.
Your users won't see your "write less code" crap and all your other "elegant" overengineered solutions that use 5 libraries for something that should be a trivial 10-line function. They'll see that your app is an unreliable resource hog that looks and feels like it's not from this world. And it's never finished. It's constantly updating but always broken one way or another. And they'll suck it up because there are no alternatives and most software these days is like this.
I'll do everything in my power to change this. It's my mission in this world. I want people to rediscover non-crappy software and have their minds blown by what modern computers can do when programmed by people who actually know what they're doing.
I mean, please do! I would be delighted about an efficient, cross-platform, cross-language, convenient GUI toolkit. But I'm not holding my breath, and I'm tired of people complaining about Electron without offering an alternative that's superior along all relevant axes.
Just wanted to state that in other worlds, like C++, there exist tools like wxWidgets which provide cross platform GUI.
That would be an interesting read
* 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
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
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
(Not saying these are bad things! Just annoyances I've run into during development.)
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.
Now everything has to do Unicode, be piped through the internet, work on MacOs, Linux, Windows, iOS, Android and the web.
- 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
- publishing apps (app store / google play rules)
In the past, Google just works. Nowadays, Google must be used with uBlacklist or something like that to yield decent results.
Back then you had a few tech stacks. Now you have thousands to choose from.
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.
> I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play
Do you not see the problem with these 2 statements. Of course not dealing with non JavaScript is easier for a JavaScript developer.
> You can get something in front of your users tomorrow.
This is something we’ve been able to do with Rails or Django for nearly 2 decades now. I can do something similar with more interactivity with Phoenix LiveView and Postgres these days.
Once you have any users at all, you need to migrate that data every time your data model changes. When you need to migrate data, not having a schema goes from a blessing to a curse, because you're trying to change the structure of unstructured data.
For this reason, I'm skeptical of both sides of the coin. I'd almost rather start with an ephemeral in-memory store that forces you to rewrite before you have actual users, rather than be tempted by MongoDB or Firebase.
* 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.
I think it really depends on what you need to do. If you need a HashMap or a BTree, getting your hands on high-performance implementations of those structures in Rust is much easier than in C. Also "sprinkling some threads" on existing serial code can be much easier in Rust, using a library like Rayon. But I take your point that designing new data structures and doing unsafe things with pointers can be more complicated.
> Overall Rust made programming harder
This is certainly a matter of opinion, but I like to argue that writing large, correct systems software was always this hard. Rust frontloads a lot of the difficulty, forcing you to handle every error condition, lifetime mismatch, and potential data race before it will even consent to run your tests. When you're first learning Rust, or when you're writing toy code where safety doesn't matter to you, this can feel like an unnecessary burden. But I think we've learned from experience that writing large systems software without this discipline leads to an endless stream of memory corruption and concurrency bugs.
Related anecdote: I have been using GraphQL at work and holy shit it is boilerplate galore but I swear we hardly have to train new hires on how to structure their software to look like ours.
We're also going to be seeing more and more pressure to make things multithreaded. So so much of the old software was designed back when concurrency just wasn't in the picture. That's why PID reuse races are so nasty in child process management. And why anything that touches the environment (which lots of standard libc functions do under the covers: https://rustsec.org/advisories/RUSTSEC-2020-0159) is unsound in multithreaded programs. Making everything threadsafe is genuinely hard.
But both of our opinions are just opinions.
https://web.archive.org/web/20220220150536if_/https://jvns.c...
"Building fast programs, with Go/Rust"
Rust isn't much harder than any other language once you understand lifetimes. Non lexical lifetimes made it easier than ever. It's a month of dealing with speed bumps as you learn, and then you're good to go.
Rust makes it insanely easy to write multithreaded applications. I write servers on a daily basis with shared in-memory caches, worker thread pools, async jobs, and all kinds of fun and useful things that I wouldn't dare do in any other language.
I'm developing apps in Rust at near Rails speed.
I've sometimes dreamt of trying playing around with building a rust-based web site/app, but then I spend that afternoon reading about different web frameworks, db access libraries, etc. and never really got started.
Given you seem to have a beaten path here I'd love to know what it looks like :)
[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
Shouldn't this also be:
Overall Rust made programming harder if we ignore memory safety: something that I'll hardly excuse to it.
> Concurrency, with async/await (in several languages)
The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it.
Coming from the world of threads, I've found Kotlin's structured concurrency approach the best of the lot I've used so far, even if it isn't with out its quirks: https://kotlinlang.org/docs/composing-suspending-functions.h...
And others don't understand it either. Neither my code, nor the async/await concept. Stack overflow is filled with accepted answers that are just doing it wrong. This was part of the frustration. I did know enough to see that proposed idea was wrong, but didn't have a better idea. Most programmers don't even seem to understand that there is a difference between a C# Task<T> and a C++ Future<T>. I do. And it doesn't help one bit.
My lack of understanding is not for lack of trying. I'm interested in different paradigms in programming. I'm eager to learn new things. While I'm programming OOP on the job, i learned Haskell [1], Idris and Prolog on my spare time. I mean, i can actually programm in these. I think esp. learning prolog shows I have some flexibility in thinking when it comes to programming. I would consider myself an above average programmer, compared to my colleges.
But async/await is simply above my mental capacity. After 1 miserable year the of desperation with in C#, I quit my job and started a new C++ job in a new city. Life is good again. When this company adds async/await to their C++ (not yet in the language thankfully) I will quit again.
I can't even describe what i don't understand about this concept, so far out is it. I only remember the purely practical anecdote that i could make a WPF command execute async but it was well-nigh impossible to make canexecute async. While completely absurd, the actually problems where way more conceptual.
[1] Kind of ironic that everything in Haskell in async, i know. But it never got in the way there.
When it comes to other implementations, though, I find them much harder to work with. In particular, existing synchronous or threaded code can block them, there's no good way to fix it without rewriting the synchronous code or shoving execution into a traditional thread, and all the existing libraries are synchronous. It feels like you need a completely new standard library to take advantage.
It's just "Stop here and wait till the task finishes" and "Only one thing happens at a time and you don't go till someone stops".
If you quit rather than got fired, it seems like you must have learned async well enough to do your job.
I almost wonder if C/C++ et al aren't teaching people bad habits of thinking about how things work behind the scenes instead of just just trusting the language.
Haskell probably has the same effect, but it is also said to have some benefits too. It teaches people to look for underlying mathematical patterns in everything.
The thing with modern programming is it seems to be designed assuming you're thinking in terms of the language and libraries you are using at the moment, and building your architecture the way the language designers intended.
As soon as you try to actually understand how it works, or you try to get creative and do anything outside their opininated boxes, it gets ugly, otherwise it's usually fine.
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)
When functions return more than one Promise, or when one chains async functions calls, it isn't really clear Errors from which functions are likely to break out and result in an unhandled exception (read also: https://archive.is/ULT7P).
For example, does trapAllErrs() below trap 'em all? Not really. Why? The answer involves understanding the microtask queue and its place in the event loop.
// traps all errors from a1 and a2, or so we hope
async function trapAllErrs() {
try {
const p = Promise.all([a1(), a2()])
const results = await p
} catch (err) {}
}
// sync code in a1 never throws
async function a1() {
// do something sync
// ...
// a3 and a4 may throw errs
return Promise.any([a3(), a4()])
}
// sync code in a2 may throw
async function a2() {
// do something sync
// ...
// a5 never throws
const x = await a5()
// ...
return ans
}You only need to understand basic JS to know why this doesn't work. You don't need to know anything about the microtask queue or event loop.
Or am I missing something?
> 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.
[1] The one exception is SQL DBs and redis, but I have always been fine using brew, linuxbrew, or apt for them.
This is subtle. There are more bumps along the way. However, the task of upgrading isn't neglected forever. Instead, it usually seems that each new member winds up upgrading some small piece and making sure the code works with a small change in environment.
By default, Docker runs everything as root. This isn't a huge problem on macOS or Windows, where Docker runs in a VM and there's some sort of UID mapper mediating things. If a file is generated from a process within Docker (e.g., temporary or log files) and you're running in Linux, now you have files in your local system that you can't edit without "sudo". Fine, don't run the container as root. I'd have expected that to be a best practice, but it doesn't come up in Docker's best practices guide [0]. Adding our own user and switching to that isn't a huge hurdle, although this didn't seem to be an area that we'd have to chart our own path. Unfortunately, some 3rd party images don't run particularly well, if at all, if not run as root.
Once we got that running, we hit our next issue. Although things were working well for one developer, they broke for another because there still existed the same basic problem with Linux users ending up with files owned by UIDs other than their local account. It turns out that not every dev is running with the same UID. Okay, so now we need to map the UID and GID at image build time, but that might break things for people on macOS.
All of our Dockerfiles ended up with something like:
ARG app_user_uid=61000
ARG app_user_gid=61000
ENV APP_USER="app"
RUN groupadd -g $app_user_gid -o $APP_USER
RUN useradd --no-log-init --create-home --shell /bin/false --gid $app_user_gid --uid $app_user_uid -o $APP_USER
docker-compose build --build-arg app_user_uid=$(id -u) --build-arg app_user_gid=$(id -g) ...
docker-compose build ...
Then think of it this way: it became easier to make the content/UI both good looking and fully accessible (e.g. to screen reader users, for whom layout tables are indeed a hindrance).
I think the same applies to the other hoops to jump through; they're solving a real problem, just perhaps one that doesn't directly affect many of us so we tend to ignore it.
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.
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 worked on. And some (most?) screen readers automatically announce any table that they don't detect as a layout table, even when continuously reading straight through the document. Notably, the screen reader I developed myself, which was the first one I routinely used, doesn't automatically announce tables unless the user is manually moving through the page, because I wanted to minimize verbal clutter when casually browsing the web. But when I went to work at Microsoft and started using Narrator to read my work email, I found the tables in certain HTML emails very annoying. Granted, Narrator didn't yet have a layout table heuristic at that time, but even when it did, that didn't entirely solve the problem. Luckily, there was also an overhaul in Narrator's verbosity levels while I was there, and that allowed me to eliminate the clutter of layout tables by reducing the verbosity level in my personal Narrator settings, perhaps at the cost of missing some other things.
Nested divs per se aren't a problem. Implementing a widget as a div without the appropriate ARIA markup is a problem.
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 libraries.) Nested divs with a mish-mash of poorly applied ARIA can get pretty bad though!
Table layouts are also terrible for anyone who is not viewing the site at the browser width you designed it for. Accessibility is more than screen readers, and the ability to zoom or adjust browser width or display on a different device (hello mobile) is incredibly valuable for a lot of people. And I'd argue that the "ease" of using table layouts disappears as soon as you try to accommodate for any of that.
https://es.discourse.group/t/callback-based-simplified-async...
It seems quite inneficient to me to wrap every function call in a caching layer and state machine that pretty much goes unused in the context of async/await and makes things unecessarily hard to undertand for new programmers.
> [...] gotchas of .NET Core async/await APIs drove me away.
I kind of lost track of the framework to core changes but I think it became simpler with the removal of synchronization contexts?
Writing parallel code that isn't clearly a divide and conquer variant is hard. Async doesn't help with that at all; it gives you more efficient context switches.
I personally find threaded code easier to reason about because there can be a context switch anywhere, so you always need to think about locks and coordination. With aysnc code, a block of code without locks and be correct...until you add an await in the middle, and this isn't always obvious.
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.
Complexity has to go somewhere. If something is easier, something else is harder. These things may make the bog standard use case easy but woe to you if you ever try to go another path or change something. Then you need to figure out if the abstraction layer allows you to tweak the underlying software layer, or invent your own way of reaching into that layer which may break when any update comes in a higher layer etc.
Its more learning upfront to get familiar with the basic Linux tools and services, but it is very versatile and flexible and will stay mostly the same for decades.
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.
My current impression is this violates the spirit of POSIX, because figuring out configurations without containers can become a non-trivial effort, especially for those of us who have not yet learned how to configure containers.
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.
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.
We also don't know yet if any of these languages will develop strong ecosystems for rapid GUI development.
And of course, Lazarus (for Free Pascal) is still a thing, though it doesn't have hype, or more importantly, large mindshare.
What was always difficult, was the toolkit. Apple had MacApp (but not when I started). In fact, the original Adobe Photoshop was a Pascal/MacApp (1.0b9) app.
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).
How do you do that? What's your approach?
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/
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.
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.
I'd be curious to read any posts/papers you've got that have benchmarks that show performance to be a reason.
…which also implies that it used to be hard and now isn’t.
The parser was never handwritten.
The whole idea of PEGs is that they’re specifically not declarative - they’re an imperative way to express a parser.
>> 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.
But Jevon's would apply a step before that. The "demand" is really the people wanting to write games. When they do that, they then create "supply" in the video game market.
Per the parent comment however, Jevon's doesn't address the mean "quality" of games decreasing.
Similar things happened to published writing (prior to the Internet, published writing typically involved editors and professional writers) or Photography prior to digital cameras. That is - technology made something far easier to create so, it was indeed more commonly created and the mean quality (at least in the artistic sense) went down.
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.
Don't forget to donate to free software projects that make your life better!
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.
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".
To know the date of publication of a given xkcd comic, go to https://xkcd.com/archive/, search for the title you're after, then the date of publication is displayed in the mouse-over text.
TornadoGuard https://xkcd.com/937/
Sure, bud.
No. There's a large class of programs that you can't write in Go that you can write in C++.
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.
Zig has both beat right now, as you do not need anything else in either case.
You can definitely taste it if you pay attention, like "yep, that's it, it's that vomit aftertaste."
Moreover, motivational responses were entirely different as a function of label. For example, when isovaleric + butyric acid was called “parmesan cheese” it inspired participants to say they would like to eat it, while when it was given the negative label (“vomit”) it provoked the wish to escape from it. The effect was so strong for certain odors, that participants could not believe that the same odorant had been presented to them at both sessions
https://web.archive.org/web/20090203043112/http://www.senseo...
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.
- 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)
I know there are solutions from ABBY but to me they are too complex and probably expensive (checked the price several years ago).
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.
Is the author referring to WebAssembly ?
Now you have Unity, Unreal and hardware acceleration.
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.
Learning new things via youtube, coursera, udemy, udacity, edx, many things. Mastery via project based learning, Github, tests in courses, certification exams, exercism, etc.
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.
I was all hip and cool once, and now feel like a dinosaur. This should help me catch up
>>> VPNs, with Wireguard
I'd say: Tailscale.
I'd also add Kafka for integrating different systems/databases, etc.
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.