[deleted]
Reflections of an “Old” Programmer
91–100 of 339 posts
Re: Reflections of an “Old” Programmer
#92One of the consequences of this wide-spread ageism is the amount of unnecessary, ill-conceived, and often dangerous wheel-reinvention that 20-something hipster programmers get away with.
Exhibit A would be NoSQL. Little more than a rehash of the hierarchical and network (graph/pointer) databases popular in the 1950s before the ascent of relational databases, these systems enjoy increasing popularity despite few, if any, advantages over relational databases besides allowing 20-something hipster programmers to avoid learning SQL and the ins-and-outs of a particular relational database (like PostgreSQL) and allowing VC-backed tech companies to avoid paying senior developers who already possess that knowledge what they're actually worth.
If these new data stores were at last as reliable as the older relational databases they are supplanting, it wouldn't be so bad. But they aren't. Virtually all of them have been shown to be much less reliable and much more prone to data loss with MongoDB, one of the trendiest, also being one of the worst[1].
And these systems aren't even really new. They only appear that way to young developers with no sense of history. IBM's IMS, for example, is now 50-years-old, yet it has every bit as much a right to the label "NoSQL" as MongoDB does--and amusingly, it's even categorized as such on Wikipedia.[2]
1) https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-read...
2) https://en.wikipedia.org/wiki/IBM_Information_Management_Sys...
Re: Reflections of an “Old” Programmer
#93Earlier quoted context omitted.
What's the last truly new thing you can think of? I'm interested because I am young (22) but have studied programming language paradigms and history and I also agree a lot of "new" stuff is old.
A history of new things geared toward web app developers, starting with relevant popular technologies: Late 1970s: microcomputers, explosion of BASIC and ASM development Early 1980s: proliferation of modems, BBS's become big, Compuserve becomes big- people able to read news online and chat in real-time (but not popular like much later). software stores, software pirating, computer clubs, widespread use of Apple II's…
Trends:
Ajax, Long polling, WebSockets
jQuery/MooTools/Prototype, Bootstrap/CanMVC, Angular/React
Javascript debugging tools, profiling, 60fps, responsive pages, AMP
RSS, Web Push, WebRTC
HTTP Auth, Cookies, oAuth, new social protocols
Perl, Java, PHP, Node.js, Go
Re: Reflections of an “Old” Programmer
#94Earlier quoted context omitted.
Good one. Trite comments like yours always make for good discussion. Care to elaborate on why you think I'm wrong?
That would take a novel. The overarching theme would end up being that you don't know as much about front-end development as you apparently think you do. Which is what I said in the first place anyhow.
So, another non-response response. I don't think you have a leg to stand on and you just enjoy feeling superior (for no good reason as far as I can tell.)
Re: Reflections of an “Old” Programmer
#95Earlier quoted context omitted.
Well, sorry, but... it is. Maybe you find it interesting, that's subjective, but there's no real technical challenge in front end stuff. You're not solving hard engineering problems; you're pasting together libraries other people wrote on top of libraries other people wrote (and on it goes) and searching google to figure out why your opaque stack doesn't seem to be working. Developing a good UI is difficult, no quest…
"but there's no real technical challenge in front end stuff." oh boy, you are so wrong! as an old fart having spent a number of years building UIs, can tell you, this is hard! information layout, controls, flow - it can be tangled into a total CF, or it can be seamless. you are not pasting libs on top of libs - that is the job of a monkey, front or back end alike. normal devs start their day with talking to end users…
You're describing a task which is more frustrating than technically challenging. Nothing you described requires a high degree of intelligence or training, only time. Of course some are better than others at it, but that's true of anything.
Think; designing the CV systems for self driving cars (since that's a hot topic at the moment) vs designing a UI which works seamlessly across browsers. One is a real, honest to God engineering challenge; the other is an exercise is patience and perseverance. There are many more people in this world who could pull off the latter than could the former.
If you truly, honestly believe that UI dev work is technically difficult when measured against the rest of the engineering world then I can't imagine you've been solving hard problems throughout your career. UI layout is not "hard" and it's certainly not engineering, nor is 'cleaning toilets'. of course creating UI's comes with its own set of challenges, but I'm specifically talking about technical difficulty.
Re: Reflections of an “Old” Programmer
#96We work in a surreal field were knowing a bit of Node.js and nothing else is considered superior to knowing a bit of Node.js and alot of .NET
Obviously you may substitute any fashionable/unfashionable language pair in the above.
Re: Reflections of an “Old” Programmer
#97Earlier quoted context omitted.
Well, sorry, but... it is. Maybe you find it interesting, that's subjective, but there's no real technical challenge in front end stuff. You're not solving hard engineering problems; you're pasting together libraries other people wrote on top of libraries other people wrote (and on it goes) and searching google to figure out why your opaque stack doesn't seem to be working. Developing a good UI is difficult, no quest…
> You're not solving hard engineering problems What, in your mind, makes an engineering problem hard? I've certainly had to dig out CS algorithms and 'clever' applications thereof to reach desirable performance out of some custom widgets in front end projects. I don't know if that can considered hard – hindsight tends to make everything seem easy – but it is certainly beyond pasting in a library like you describe. I…
>What, in your mind, makes an engineering problem hard?
A problem which requires a high degree of creativity, intelligence, and technical ability, likely one which hasn't been solved before. You're right; it's a bit difficult (at least for me) to define, but we know it when we see it. Sending men to the moon was a hard engineering problem; implementing the UI for gmail was not.
You speak of using 'CS algorithms' in your UI's. I assume you're talking about things like optimizing a search of a list by using a better data structure or sorting algorithm. C'mon. You didn't solve these problems, other people did, you just did a little research, and this is basic stuff most of us can pull off fairly easily.
The vast majority of web development is not engineering. It is in fact just pasting together code other people wrote to solve a particular, relatively trivial problem.
Re: Reflections of an “Old” Programmer
#98If somebody had found himself in Edinburgh in 1986 and bumped into a tall gentleman called Robin, who was a bit familiar with this new-fangled thing called computers, and had asked Robin, what kind of programming language should one learn to use these computer thingies, what would Robin have said? Not sure, but maybe something along the lines of "well ... there are many interesting languages, and different languages are suitable for different purposes. But if you are interested, I'm dabbling in programming language design myself. Together with my students I've been developing a language that we call ML, maybe you find it interesting. With my young colleagues Mads and Robert, I'm writting a little book on ML, do you want to have a look at the draft?"
Maybe such a person would have chosen to learn ML as first programming language. If this person had then gone on to work in programming for 3 decades, and if you'd asked this person 30 years later, i.e. today, what's new in programming languages since ML, what might have been his answer?
Maybe something along the lines of: "To a good first approximation, there are three core novelties in mainstream sequential languages that are not in ML:
- Higher kinded types (Scala, Haskell).
- Monadic control of effects (Haskell).
- Affine types for unique ownership (Rust).
Could I be that somebody?
Re: Reflections of an “Old” Programmer
#99A lot of old guys(40 is old eh!) I meet are into managerial/advisory roles and even though they wont know the underlying details of the framework it does not take them much time to understand it, because there is always something similar they had during their time.
The time I spent mastering, adobe flex, javas struts framework, GWT and the likes. Could seem like wasted time. But in the larger scheme of things it just made me smarter. I know what worked for them and what didn't and that helps me understand the future frameworks better.
Re: Reflections of an “Old” Programmer
#100I'm a bit older than the author. Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. I tend to discover that the core principles are the same, this time someone has added another C to MVC; or the put their spin on an API for doing X; or you can tell they didn't learn from the previous solution and this new one misses the mark, but it'll be three years before anyone noti…
What's the last truly new thing you can think of? I'm interested because I am young (22) but have studied programming language paradigms and history and I also agree a lot of "new" stuff is old.
New stuff: Machine learning that works. Rust's borrow checker. 3D SLAM that works. Voice input that works. Lots of image processing stuff. Machines with large numbers of non-shared-memory CPUs that are actually useful. Doing non-graphics things in GPUs.
The webcrap world is mostly churn, not improvement. Each "framework" puts developers on a treadmill keeping up with the changes. This provides steady employment for many people, but hasn't improved web sites much.
An incredible amount of effort seems to go into packaging, build, and container systems, yet most of them suck. They're complex because they contain so many parts, but what they do isn't that interesting.
Stuff we should have had by now but don't: a secure microkernel OS in wide use. Program verification that's usable by non-PhDs. An end to buffer overflows.