Don't see why you are being downvoted, missing one common supported hardware has always been a big problem in the linux community, always chasing crazy combinations of drivers.
Of course if you control the hardware and software stacks, it's leads to a better experience and community can build on it.
Microsoft Surface and Google Pixel are both similar examples, but they don't really feel substantially better than alternatives where the hardware and software stacks are less unified. The primary difference between Steam Deck and other Linux experiences isn't really that the hardware and software are unified, it's that you're actually running a supported configuration in the first place. Almost all Linux setups are ultimately ran on hardware that was built to run Windows in the first place. Even System76 laptops ultimately (today) come from hardware designed for Windows laptops. Steam Deck is flat out, start to finish, all the way down to the APU, designed to boot into Linux, and it shows. On the contrary, booting Windows on it gives you some of the hallmarks of a typical Linux experience on less supported hardware.
But I don't think that's really what the comment was about. I think what is really interesting here is the community.
I think the close collaboration between Valve and the Linux community is pretty unique. Mac has always had a very vocal fanbase, but Apple is a notoriously secretive and stubborn company. Valve is doing all of this work in the open including customer support, which is fostering quite a community. I think to compare it to Mac computers misses the point; Mac has an unusually large base of enthusiasts, much larger than the Steam Deck userbase, but it's not strength in numbers that is intriguing here.
That's not what OP was mentioning as the benefit. They were specifically mentioning the simplicity of a single common hardware base, not the openness of Valve. That this simplicity was making it super easy to pool resources with other users. The Mac always had that common pooling of resources amongst users, and it has been useful despite Apple's stringent secrecy.
> > An insanely helpful community. Tons of knowledge out there for getting it to do anything you can dream of.
> This may actually be one of the biggest lasting impacts of the Steam Deck. It puts a lot of enthusiasts with a common interest on a highly reproducible and officially supported configuration. If a game doesn't work, you can file a bug with Valve on Github about it and most of the time it'll be fixed within a week. If the system itself is misbehaving, you can feel safe knowing that there are thousands of others on the exact same configuration.
The community building that Valve does is important for this in my opinion.
The ease-of-use of software or hardware can unintentionally filter for a certain profile of user base.
If it’s hard-to-use, Kafkaesque, or unforgiving, users who are able to integrate the hardware/software into their daily lives are likely to see it as a trial-by-fire and be gatekeepers to others.
Yes, architecture, medicine and metallurgy have been improved for millenniums. Next to that, IT is a baby that can barely walk. Of course we have too much grunt work.
But also because every time we remove grunt work, the customer expectation increase, the market adapts, and now you have to use new tools that are productive enough to do what the users want with the resource they are willing to pay.
So you don't have to hand write assembly but you do have to have an app that works on 16 screens ratios. You have amazing databases ready to handle your data, but you should update the UI live.
> We continue to narrow the path to get experience as an engineer.
Like in most industries, we are starting to move from "everyone needs to be an experts" to "90% of the daily tasks really just need good technicians". That's fine. That's how it is supposed to be.
At some point only experts could duplicate your house keys. Now you have convenience key stores everywhere.
We are on the right track.
Next stop, the equivalent of residential building codes, but for public facing apps.
Because IT is so new and can be done in your garage, we thought it was special. It was not.
Knowing the subtlelties of memory management in the 80' didn't help the Ruby coders to create RoR and run Basecamp, or the Python coders to create Django and run the Washington Post.
People jumped at ORM, CSS frameworks and JS wrappers, and won the day because they traded memory and CPU for what the user wanted.
The new generation will do the same. They will figure out how to be super productive with AI, way more than what we are. And our superpower will be useful in specialized cases, but mostly, their impacts will be small compared to the order of magnitude of speed they'll gain by using the new paradigm.
People said interpreted languages were a waste, that you had to learn SQL, that Electron was an abomination.
But the people building stuff always win, not what we think is the right way.
That's why PHP won at some point. JS won at some point.
And something super practical (but that will make us say uhh...) made by AI will win at some point.
That's also why all the open letters and ethics committees will have no impact: the short term advantage given to AI users will be such that they will take everything over by storm.
It's already happening in porn: we just gave millions of teenage boys a shiny new toy, and they are spending days and nights on it. New incredible models come out every day. Some hyper specialized. Last week, I saw a publication of a new model specially trained on only vagina called "bettervulva" and one for boobs called "breastinclass". Somebody spent hundreds of hours on those, collecting the data, annotating it, and training.
I guarantee each niche of the world is doing exactly the same. Not to mention each new model is coded with somebody who has the previous models to help with the new one, code included.
You are sort of ignoring the bias in your own AI extremist prediction.
People who have decided to go all in in learning an interpreted language like Perl or even PHP, had to continuously also learn react, js, ruby,... and gazillions of other languages and frameworks to remain in business over the last two decades.
While people who invested in learning C, Java or SQL have as much healthy opportunities to pursue today with almost the same amount of knowledge that they had accumulated three decades ago. Their life has been much less stressful, pretty much on auto-pilot, while those who were pursuing the latest technology are constantly living on the edge having to continuously relearn entire new framework on average every 3-5 years to remain relevant.
So yes all these glitzy languages have "won" but it wasn't by these "ancient" languages losing.
If I had to bet I would say a decade from now, based on the last 50 years history of computing, I can easily imagine the same amount of jobs for C programmers as we have today but there will be as many Ruby jobs as we have perl jobs today.
Reskilling has its upsides, you are exposed to many more paradigms and communities that do things completely differently which allows for a lot of cross pollination. living life on autopilot isn’t usually a source of great insights.
Reskilling is much more productive and fun when you are doing it for the intellectual journey and insight, rather than because you need to do it to find a job.
Indeed being able to auto-pilot your job allows you an amazing amount of time and freedom to learn new things deeply. See also the detrimental effects of "publish or perish" mindset in academia.
Which pretty much sums up today's work culture. I was just talking about this same exact thing, yesterday.
That's absolutely heartbreaking.
In the old days, we would have a team, that would compete, as a team, against other corporations. Our team would stick together, work together, and, quite often, function as a unit; leveraging each others' strengths, and compensating for each others' weaknesses.
Nowadays, we look at our team members as "the competition." In fact, we may actually be making plans to move to the other team.
But I have written programs in C, that were still in use, 25 years later. I have written programs in PHP, that were still (are still) in use, 15 years later.
There'll always be room for the classics.
That said, I'm quite looking forward to seeing what I can do with the new AI stuff.
I never publish or react to individual velocity as a manager. It's all about what the dev and QA team gets across as a whole to the Done pile each week, and I use a rolling ten week average. I know what each person is doing still but if they spend four hours collaborating on something nobody loses points.
Well my team wins more than most others and we've replaced teams and fixed many failed projects so that helps too. And if the company is dense there's others that aren't and lots that will follow where I go to next.
Everyone is at best a temporary ally, friends and community groups are just atrophying daily as we continue to not invest in people and community and invest in more alienation.
The idea that nobody saw their coworkers as competition for a promotion, or bonus, or face-time with the boss in the past, and that there are no teams that stick together and work together today, is fanciful at best.
These are "Because I can find an exception, your position is invalid." arguments. Not sure I can recall the exact fallacy title, but it's a fairly typical debating tactic.
I disagree that there's a fallacy at play here. The GP (GGP) should support their bold claim that "times have changed" and "people/teams aren't the same as they used to be." If anything, that's an extremely common fallacy and is not to be believed without sufficient evidence.
Actually, that's a fairly typical thing to say to someone that's older, and has lived through those times.
And I am sorry. Things definitely used to be better than they are now, in some ways, and definitely used to be worse, in other ways (for example, it used to be a very white, very male demographic). It's not my fault that things went the way they did. Folks liked money, so folks built a culture that maximized profit, and eschewed humanity.
I am quite sorry about that, but it doesn't change the fact that it was not always so.
It's not in my personal interest to go about creating a slideshow on "how things used to be." I know what I know. I lived it. I ran teams, exactly like I described, and I was a proud member of very large, high-functioning teams that stuck together for decades without stabbing each other in the back.
I don't disbelieve you, but I'm saying your experience can't be generalized in that way. Only aggregate data can tell us these things. Your experience may well have followed the exact trajectory you've described, but maybe 90% of people see the opposite.
While maybe it does sum up our work culture it shouldn't influence how you work. Rarely have I seen someone who "runs faster" be more valued (monetarily or among senior peers) than someone who churns out quality and runs "a little slower".
Team is still very much a thing and if your team members are looking at each other as competition then that sounds like a culture thing, maybe the norm, still not acceptable.
The collateral damage of careerism is objectifying your coworkers as either enemies or things to manipulate in order to advance yourself. It's the belief that all software devs are temporarily embarrassed FAANG devs.
This mindset will damage you over the long run, and the resulting career success may or may not be able to offset it. A zero sum mindset will lock you into this view along with the accompanying anxiety.
Given how quickly income inequality is rising, can you blame people for taking any advantage possible to try to stay ahead of the curve? If it means throwing your teammates under the bus to get more money, that's unfortunate but it's going to happen.
With those new interpreted language that are easy to pick and have a low-barrier of entry you are constantly having to run faster than an influx of fresh energetic high school dropouts and boot camp graduates.
With less fashionable language that require significant expertise and experience in picking them up like C (understanding the hardware level) and Java (understanding the JVM and OOP concepts) the barriers of entry are much higher and this will mean you have to outrun fewer people in the long run to survive.
I am pretty sure that you can programm java without knowing details about the JVM and I would think, that most java programmers do exactly this. I think only in high performance scenarios knowing more is beneficial?
But I have not touched java in a long time .. as I have indeed choosen the web as plattform.
But I don't feel threatened by the high school kids coming from boot camps.
Edit:
I know what a pointer is, so I can work closely with wasm libaries.
I know algorithms and how to structure data and why I am structuring data this way in this case, so I can adopt in another case.
I know how to achieve performant simple code.
I know how to debug layers of code with sideeffects over sideeffects. Raceconditions, memory leaks, etc. (All a thing in js, too). Using and understanding the profiler etc.
Someone coming from a coding bootcamp, does not know this. He or she might learn it after years of practice, which is allright by me - but they are no direct threat to me, despite that I don't even really know react for example.
not feeling threatened doesn't mean you're not under threat.
It's entirely possible that between your skill level and those boot campers is a few(dozen) percents of workforce. But at the same time it's entirely possible that if you are not as quickly progressing as the growth of the industry, you could become a part of the same percentile as bootcampers in no time.
It's not only about performance, it's also about maintainability. Codebases written by inexperienced programmers are extremely convoluted, nothing is decoupled and functions are extremely long and do multiple things. Extremely hard code to maintain or add features to.
A lot of the Java programmers I know professionally know fuck all about JVM internals, etc. Its largely unnecessary unless you have to chase down some extremely subtle bug most of the time.
A lot of them are senior or principal product engineers at companies you will have heard of.
Whereas with C, its extremely necessary to get into the weeds - otherwise your code just crashes or suffers some memory corruption issue, race condition, etc etc.
> I am pretty sure that you can programm java without knowing details about the JVM
yeah that was the whole point of object oriented programming and Java to begin with. You don't need to know the details of the underlying implementation, focus on the problem you're trying to solve.
"You don't need to kill a chasing bear to survive, you just need to run faster than your friend."
Problem with this approach is you run out of friends quick. People in bear country cary bear spray, have dogs to scare off bears and electric fences to keep them out.
We have tools and culture to not have to deal with/rely on survival of the fittest if we don't let fear control us - whether at work or in nature.
I find it hard to believe people who learned Java don't have to learn new things every now and then. Yeah maybe they stuck to Java but the whole backend ecosystem looks way different than even 10 years ago.
Even C is debatable.
Of course, everyone is always learning, you can't remain static. But you could afford to become more and more of a specialist in Java and growing your job opportunities that you can apply to.
If you became more and more of a specialist in Perl on the other hand you would have had to completely relearn something new by now to find as many opportunities as you used to in the late 90s.
I don't think it made a huge difference in most of these guys careers. I'm sure Perl "specialists" were able to move stacks if they wanted to...and you learn most of it on the job anyway so its not like you had to take a year off to catch up learning Java. So yeah it was a time investment for people but I don't think its as dramatic as you're making it seem.
I'm saying this based on the fact the job market was amazing for software developers in the last decade or more.
Things now might be different.
There are a considerable number of Perl jobs out there - just not many "greenfield" perl jobs.
Most of them are maintaining existing codebases (not a fun job), and some are "help port this legacy codebase to not perl".
I'd not discount Perl. Its incredibly fast to develop services in, stable as fuck, runs anywhere, performant (relatively), flexible, and if you were a startup looking to get a product out the door, just offer decent TC to a couple of old hands you can ship something viable fast.
A horrifying amount of applications out there that I've seen are basically just that - wrassling some text around, but with a billion layers of unnecessary abstraction.
I get to see a lot of peoples code in my job. Most of it is ridiculous levels of over engineering
Exactly my point. You had proportionally as many perl jobs in the late 90s as you have Ruby jobs today. It even had early mover advantage in the scripting space and insanely good ecosystem of libraries.
I have not stopped messing with Stable Diffusion and llms for like 7 months now and I've been a software engineer for 20 years. I use copilot and chatgpt and my own brain and have released two compiled python apps on itch ( first real apps I've ever built and released from the ground up on my own) - both are ai tools, one for stable diffusion one for flan-t5. I'll be releasing a unity solitaire game soon as well, and ive been training my own models.
This is the most fun I've had creating things since I started programming.
> This is the most fun I've had creating things since I started programming.
Definitely getting that vibe over here. I've been revisiting the exploration-style programming I was doing when I was young - Mandelbrot sets, Truchet tiles, all the old Computer Recreations columns stuff. Things you code up just to see what they look like.
Being able to say "Turn this pseudocode into a Processing sketch" is a joyous thing.
I've gone from hating PHP for most of my career, to now having a grudging appreciation for it. Its a clusterfuck, but it works really well, and deployment barely gets simpler than "untar into webroot, done".
There is still required setup for things like PHP, like what reads from the webroot and serves the requests. Other things, like binaries, can be almost completely self-contained and do everything, and then you just move the binary to the server and run it, and you get the full environment needed, no Apache with mod_php required (or what the kids use nowadays)
I also forgot briefly what a complete fucking nightmare instrumenting/debugging PHP (on say, a LAMP stack) can be - which is the inevitable result when PHP decides to behave in "interesting" ways.
I think what the GP is getting at is that one’s personal feelings about Electron do not matter whatsoever. There are fantastic billion dollar products built with the framework, that’s an objective fact. We can criticize it from a technical standpoint all we like, but the market is not something we can out reason.
It’s a bit like calling e-scooters an abomination. It’s just an opinion, and one that certainly isn’t stopping money from being made.
Except that the pendulum has sung quite a bit in a few of those cases. Strong type systems that work best with a compile step have been clawing back ground from loosely typed dynamic languages, and the power and utility of Postgres/RDS has kicked off a mini SQL renaissance.
> Knowing the subtlelties of memory management in the 80' didn't help the Ruby coders to create RoR and run Basecamp, or the Python coders to create Django and run the Washington Post
Those programmers didn't need to know the subtleties of memory management because when they programmed in Ruby they didn't have to debug in C. GPT is very different.
Sort of off topic - but Django was actually created by the author of this post! But in Lawrence, KS to run a small little newspaper's site (Lawrence Journal-World). WaPo then adopted it, which was obviously a huge boon to the growth of the framework.
On the contrary, if you don't know, then you don't know. If you're always needing to use ChatGPT or other LLMs then what happens in a world where they're unreliable?
It think it depends on if your see SWE as creative or not. We've had plenty of tools to increase productivity and user experiences still suck too much too often.
Making something easier doesn't necessarily increase quality. It's early days. It's a fool's errand tp try to predict the future. Now more than ever.
That's pretty much the take of the article this one references.
The whole reason I posted this one is to justify the "just use -m pip and -m venv" stance I wrote in the article 4 days ago.
Because you will always have a very vocal minority of people that will fill the threads with counter arguments actually increasing complexity and risks of failure.
Believe it or not, it improved tremendously in the last 10 years:
- easy_install, distutils and eggs were deprecated
- ensurepip and venv were introduced
- the whole wheel ecosystem flourished
- a new dependency resolver was introduced to python
But:
- a lot of noise has accumulated. Hence the procedure in the previous article, to avoid the traps from all that noise and go back to what usually works.
- we have a long way to go, but it's not something easily fixed (hence the conclusion of the current article explaining why it's going to take a long time to get better).
Hopefully, the direction of that long way is relegate python (and javascript!) to legacy languages.
Something, hopefully, will come out of webassembly. Otherwise, the last decade only saw the rise of two fundamentally flawed languages as the most popular ones.
Ruby losing to both was not a good thing. And I'm not even a Ruby programmer! I hated the language back in the Rails vs Java days. But it is impossible to deny that great software came out of Ruby.
Javascript and Python has produced no great software, just ponderous stacks of crappy code and poorly organized libraries. They are popular because they are used for throwaway web applications and throwaway scientific / non-programmer code, and it shows.
The fact that golang is what is producing new "good" software: a language that is intentionally bad, as opposed to python and javascript being worse because of cruft accumulation or Eich writing it a weekend, is also not a great sign but it's not the step backward that javascript and python are.
> Hopefully, the direction of that long way is relegate python (and javascript!) to legacy languages.
People writing in JS are usually techies who could/would migrate. People writing in Python are on a wide spectrum that goes from "one-step-above-matlab" to "know-it-all-c-wizard". You won't actually get all these people to move on any reasonable timeframe.
HN is biased because we tend to love tech and a lot of us know several languages, but Python is much more democratized. My friends in physics, biotech, mechanical engineering, basically everyone in STEM is using Python and to them it's a tool that took a lot of time to learn and they won't drop it all because dependencies are hard.
"good software" is not a goal. My goal, especially if I'm a solo dev, is to make something cool, efficiently. Instagram is built on Django and probably lots of JavaScript too. Maybe their software is a slow, ponderous stack of crappy libraries, but if those languages can function at that scale they're probably good enough for 99% of people.
Besides, code at a large scale in any language is always messy. There are many ways to manage a growing codebase but if your only approach is relying a "good" language with static typing, verbose/explicit syntax, and a better built-in package manager, you are doomed to fail anyways.
Perhaps this is a case of correlation=/=causation? Python is more accessible so less adept programmers are more likely to use it.
Right. But the point is that if I have to have special knowledge or do tricky things with Python just to get end-user software to work right, that's a problem. You should just be able to install the software and have it work right. End-users who are not so technically oriented would never even know to look for those instructions, let alone be comfortable following them.
Python is the only language I've encountered that causes this sort of trouble for ordinary end-users. As a dev, I find this frustrating because the python scripts in question are clearly only "glue" in the first place. That's a lot of burden to put on the end user for just glue.
As for my issue, I did make it work in the end. I'm 90% sure I didn't do it in the right way and it will cause me problems at some point in the future, but that will be a problem for future me.
I am a huge fan of python and have rebutted some of the criticisms in this thread. I would also avoid shipping python to users because of the issue you point out. If it couldn't be avoided I'd probably package the version of python I want them to use, with my software.
It saddens me to say, but imports are indeed a complicated topic on Python. The PYTHONPATH is not something people know about, and once they do, it's not intuitive.
The weird handling of namespaces or relative paths doesn't help.
You are not telling them to use pyenv, you are telling them to use a totally different tool that happen to have a similar name and provide a similar interface.
This procedure was valid 5 years ago, and all the alternatives have changed a lot in the same time period.
So if I had to chose one way for the next decade, I would bet on this.
But I will not pretend we can be sure about anything on this matter.
In fact, my hope is that we can improve the process tremendously by creating an unified way of bootstrapping Python for all OS. If this ever happens, the procedure would become mostly obsolete.
At the end of the week I will write about this, and the various experiments the community have done so far in that regard.
Of course if you control the hardware and software stacks, it's leads to a better experience and community can build on it.