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

Programming culture in the late aughts (2022)

morepablo.com

Post reply on HN
Print view View original

51–60 of 123 posts

Re: Programming culture in the late aughts (2022)

#51

Post by aa-jv »

thoughtFrame wrote: post #5

I've only learned of the Good Ol' Days of the 90s from second hand sources, and I was in middle school throughout the aughts, so for me these periods are just a mirage of a better time. In high school I pursued reverse engineering and other stuff, so I could blissfully ignore the newer direction the industry was taking all the way until 2019. But now I'm close to graduating university. Is there any kind of job where…

Embedded. Things are getting fat and wide enough that you can apply all of that tech to an embedded system and, hopefully, no one will be any wiser that you've done so.

SOM-based development (system-on-module) in the embedded Linux world means that being able to productively pick and place the right software components is a highly sought after skill.

There is gold in them thar' repo's, especially if your shovel is a SOM and your mule is a functioning supply chain direct to the customer ..

Re: Programming culture in the late aughts (2022)

#52

Post by blt »

I got my first programming job in 2011, working on a specialized and computationally heavy desktop app. This already felt like a bit of an anachronism, but smartphones weren't central to our lives yet and Electron didn't exist.

I bet the total number of people who will learn a C++ GUI framework between now and the end of time is smaller than the number who know one now.

I was happy to work on anything algorithmic. It seemed like there was so much CRUD and foundational communication stuff happening. All the programming literature talked about "business logic". Now with the rise of machine learning, a new grad might have a better chance of doing non-CRUD work now vs. then.

Re: Programming culture in the late aughts (2022)

#53

Post by ep103 »

physicsguy wrote: post #45
ilrwbwrkhv wrote: post #38

Earlier quoted context omitted.

But you literally don't have to do any such thing though. A simple make file and maybe a load balancer can easily let you launch large web applications used by millions of users. I do not understand where people are getting stuck here that they need all of this complexity. How many users do these apps have?

Way less than people think they’re going to. When I started my current job, the project was veering into microservices hell by a team that did not understand how to build a web application. A rough back of envelope calculation of potential customer base and what the product was aimed at (B2B in renewables) told me that even with world domination, the backend of the application would at most have 50k active users ever…

Yup, this is what I'm working on right now.

10 microservices to support a 2 page static html webpage.

We "needed" microservices for "Scalability", but we will never have more than a few hundred users at a time.

We can't have simple logging of our services, because all logs have to go to Loki, and Loki only does full text search. So first, learn how to query with Grafana's querying language in order to do any searches at all, then figure out what you will ever need to search, and turn that into a prometheus metric, but wait, now we have to properly compose our metrics for queryability....

I need to implement retry logic in one of my microservices. Would be easily implementable with an Amazon SQS or RabbitMQ queue. But we can't have queues, because they aren't stateless. We need to use Kafka because it has the ability to scale to billions of events, never mind that we never see more than 10k events in a 24 hour period. So now we'll need to write custom logic for retries and managing state outside of the queue, which means we're back to using database tables, which means there's no point to using kafka to begin with for our application...

Our services build in gitlab to docker images which then are hosted in the cloud and managed by k8s in custom vpcs. Sure, makes sense. But also, can someone show me how the developers on the team are supposed to be able to run the system locally? What? Can't do it? Replicating the production environment for local builds is now too heavy a lift and has been deprioritized by management? So how are they supposed to develop again? Oh, they'll just never learn how the whole system works, and continuously make changes they assume are isolated to their specific microservice without realizing they've introduced an error into the wider system unless the lead/manager catch it? Got it.

I could go on. Architects choosing technologies over listening to their engineers, in order to pad their resumes with technologies that look good to other architects. Committees of middle-managers choosing the 'safe' enterprise technologies instead of what is actually needed.

Re: Programming culture in the late aughts (2022)

#54

Post by marginalia_nu »

divbzero wrote: post #22

12 years ago, even without AWS, you could get a Linode, host an app on its naked IP, and not made to feel too much like you weren't "serious" about hosting your app. These days you almost always need to know a fair bit of Docker and Docker Compose, a lot of people want to Kubernetes, ELBs got replaced by ALBs + NLBs which you gotta manage in VPCs which you gotta manage through Security Groups and your traffic gets ro…

Works better than ever. If anyone ever asks how my search engine, running on consumer hardware and hosted off domestic broadband, how it survives the hacker news front page time and time again without the load times even deteriorating a bit, while many other websites that are ostensibly static in nature tend to keel over?

Then the answer is something like this.

* nginx

* Java

* Macroservice architecture

* Vertical scaling

* Server-side rendering

* Minimal javascript, no session cookies. These things bump the cost of each page-load.

* /var/log with relatively sparse logging in the sunny day path

Like this is a pretty strict design philosophy. You can probably do more JS and front-end stuff than I do, but it should be understood it's not free. My page loads incur for the most part a single request each. There are websites where each page load incurs hundreds of requests. It's worth repeating: Back-end requests are not free. They are cheap, but they are not free. When you have a dozen users and they incur a few thousand requests, that may be within what your server can deal with. When you have a thousand users and they incur hundreds of thousands of requests, it's probably not as fine.

Re: Programming culture in the late aughts (2022)

#55

Post by Tade0 »

marginalia_nu wrote: post #54
divbzero wrote: post #22

12 years ago, even without AWS, you could get a Linode, host an app on its naked IP, and not made to feel too much like you weren't "serious" about hosting your app. These days you almost always need to know a fair bit of Docker and Docker Compose, a lot of people want to Kubernetes, ELBs got replaced by ALBs + NLBs which you gotta manage in VPCs which you gotta manage through Security Groups and your traffic gets ro…

Works better than ever. If anyone ever asks how my search engine, running on consumer hardware and hosted off domestic broadband, how it survives the hacker news front page time and time again without the load times even deteriorating a bit, while many other websites that are ostensibly static in nature tend to keel over? Then the answer is something like this. * nginx * Java * Macroservice architecture * Vertical sc…

Let's also not forget that browsers generally limit the number of requests they send at a time - IIRC the current limit is 6, so a site may be slow just because it sends many requests.

Even (or maybe especially?) popular products like Gmail are guilty of this, sending easily over 200 requests. That's 700ms(!) worth of stalled requests in the best case scenario.

Re: Programming culture in the late aughts (2022)

#56

Post by varjag »

radomir_cernoch wrote: post #44
varjag wrote: post #33

Earlier quoted context omitted.

Sure but you would have learned it in 1995 too.

From my freshman years around 2005, I vaguely remember that multi-thread GUI apps were: - a way to avoid blocking the UI, - tool to gain some perf. on new fancy multi-core processors, - making the code much harder to read and debug, which often makes them a victim in a cost-benefit analysis.

Point is the programming paradigm of POSIX threads or multitasking wasn't a new concept then and likewise been in the curriculum for a while. Multi-core only brought a new level of performance to it.

There were in fact attempts for new concurrency paradigms (like Software Transactional Memory) which however led nowhere outside academia.

Re: Programming culture in the late aughts (2022)

#58

Post by golergka »

agentultra wrote: post #18
stiglitz wrote: post #10

"12 years ago everyone was wondering how we'd program on multicore CPUs" is either laughable or enlightening to read as an OS developer.

Even in user space. Electron became de jeur for web developers to build desktop apps. Single threaded memory hogs. Thankfully many DAWs, video editing, CAD, servers and other useful software saw the value in multi-core workloads. It’s a thing… just not for web folks most of the time.

Most serious electron based applications are not single threaded.

Re: Programming culture in the late aughts (2022)

#59

Post by 59nadir »

Guthur wrote: post #43

I think IRC was a big part of community knowledge and also such a hot spot for weird inspiration. I can attribute my picking up of Common Lisp and ultimately getting a job in Australia from the UK to an off the cuff comment by someone in IRC.

I started learning programming (C++) when I was 12-13 (2000-2001) because a guy on QuakeNet told me I should learn how to code if I want to learn about hacking. All these years later I'm very well paid to create distributed systems in technologies I could've never imagined back then.

The funny thing is that I want to stop doing that and have other problems instead, because I'm just tired of everything that has to do with what (mostly) web development (and other distributed systems) has become and this incessant either layering more things on top of other things or adding extraneous things.

I'm currently re-orienting around a possible switch to game development.

(For those who might think I'm being impossibly naïve; I have plenty of lower-level experience and have worked at 2 game studios previously, it's not that foreign of a world. I originally left to do consulting because it paid significantly better.)

Re: Programming culture in the late aughts (2022)

#60

Post by golergka »

ryandrake wrote: post #20
thoughtFrame wrote: post #5

I've only learned of the Good Ol' Days of the 90s from second hand sources, and I was in middle school throughout the aughts, so for me these periods are just a mirage of a better time. In high school I pursued reverse engineering and other stuff, so I could blissfully ignore the newer direction the industry was taking all the way until 2019. But now I'm close to graduating university. Is there any kind of job where…

My experience of programming as a Junior Software Engineer in the '90s was replacing inner loops with inline assembly, avoiding cache misses (keep your code in the L1 cache) and making sure your memory accesses stayed on one page. Nobody seems to care even in the slightest about this stuff anymore, and the abysmal performance of modern software shows it. During the last 30 years, everyone's focus has drifted up the s…

There's a lot of places that care about performance now, but in many if them, instead of optimizing your own business logic, you would be building performant platforms so that others could build their own business logic on top of them, be it V8 or Unreal.

Honestly, I think that this separation of concerns makes much more sense.

Post reply on HN