I get where the guy is coming from, I'm right there as an old guy. On the other hand, I think there is a bit too much fatalism in the article. Sometimes the kids are being stupid, and they need to be told so. The vast majority of web apps could be built in 1/10th the code with server-side rendering and intercooler.js. All this client-side crap is wasted when you are trying to get text from computer A into data-store…
Reflections of an “Old” Programmer
231–240 of 339 posts
Re: Reflections of an “Old” Programmer
#232Earlier quoted context omitted.
Browsers have improved greatly and new web development frameworks are necessary to make use of those improvements but the actual process of building usable web application doesn't seem that improved. It's certainly not any easier to achieve pretty much the same results. > The idea o a web-based office suite on the web would have been laughable 20 years ago. What's laughable is how much effort has gone into rebuilding…
20 years ago there was exactly one multiplatform office suite, and if you think StarOffice was better than the current incarnation of Google Apps I'm not sure how to respond to that outside of laughter.
Re: Reflections of an “Old” Programmer
#233Earlier quoted context omitted.
> 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 y…
You assume wrong. They were not straight up textbook problems, but I agree that I used a wealth of existing knowledge to apply it to my specific problems. That's what engineering is.
> You didn't solve these problems, other people did
Naturally. If you are working on finding novel discoveries the world has never seen before, you would be appropriately labeled a scientist working on science. Hence, also why we consider the algorithms I mentioned before to come from computer science, not software engineering.
Re: Reflections of an “Old” Programmer
#234I'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…
There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there? Because the profession is so heavily skewed towards the young and self-taught, people don't seem to know about the solutions of a decade ago and their merits and demerits. This is partly why software componentisation as "parts catalog" has never really taken off. It's easier to reimplement or independently r…
Shall I list the componentization tech of yore? CORBA, OpenDoc, Java Server Faces, COM, DCOM (oh god, CORBA again!), SGML (the original component framework), XML zoo (oh god, CORBA a third time).. JSON zoo, (a flippin' fourth time, are you kidding?!)
componentization is something we're still figuring out. Alan Kay and SmallTalk were the closest to get to it (see previous comment about practicality though) and the mainstream just now is starting to think of JS and Ruby as "novel". NPM? Please.
We have a long way to go before componentization actually works. So yes, I guess I agree that it's simply easier to reinvent things to a specific context than solve the problem of sharing code context-free.
Re: Reflections of an “Old” Programmer
#235Earlier quoted context omitted.
Reduction to absurdity isn't a valid argument. The Wik says Aristotle called it " ἐις ἀτοπον ἀπαγωγή " and reductio ad absurdum has been considered an important and valid form of argument for at least 2500 years. [0] [0] https://en.wikipedia.org/wiki/Reductio_ad_absurdum
That's nice. Not here though. Equating the technical complexity of learning a UI framework and designing back end systems is just silly and you know it. This is also not a form of reductio ad absurdum which fits the definition; it's just a silly linguistic reduction which excludes many important details.
(Just to be clear, in the IT version, you're not standing where the mathematician is.)
Re: Reflections of an “Old” Programmer
#236Earlier quoted context omitted.
Hasn't improved websites much? I remember the days of iframes and jquery monstrosities feigning as web "applications". The idea o a web-based office suite on the web would have been laughable 20 years ago. My guess is you haven't actually built a real web application. The progress we've made in 20 years is astounding.
> The progress we've made in 20 years is astounding. And yet "open mail in new tab" in Gmail has been dead for at least a couple of years now. In fact, I'd say that "open link in new tab" is dead on most of the new web "applications", I'm actually surprised when it works. The same goes for the "go back with backspace" thingie, which Google just killed for no good reason. Copy-paste is also starting to become a nuisan…
Use the basic HTML version. It's worse in a few ways but better in most others. Including speed.
Re: Reflections of an “Old” Programmer
#237Very sad that the author aspires to be Martin Fowler. Fowler is an adept populariser of other people's ideas, and he does that as marketing effort for Thought Works. AFAIK he has not originated any innovation over the last twenty years, whether it be patterns, enterprise architecture, microservices, generators, refactoring or agile. Basically he's a corporate shill trolling round the conference circuit drumming up co…
I don't see anything wrong with picking up ideas like that and promoting them, if he didn't rename so many of them...
Re: Reflections of an “Old” Programmer
#238Earlier quoted context omitted.
Thank you for mentioning intercooler.js. After skimming through the docs for five minutes I am sure I will use this regularly from now on.
After skimming through the docs, my mind went all the way back to ASP.NET Web Forms days :) This model, unsurprisingly, brings it's own problems when things get complex.
You can think of it as a declarative syntax and a few extras layered on top of the standard AJAX function call.
Re: Reflections of an “Old” Programmer
#239Earlier quoted context omitted.
There's an eternal war between "avoid reinventing the wheel" and ahistorical "not invented here", isn't there? Because the profession is so heavily skewed towards the young and self-taught, people don't seem to know about the solutions of a decade ago and their merits and demerits. This is partly why software componentisation as "parts catalog" has never really taken off. It's easier to reimplement or independently r…
Software componentization never took off because every attempt at it either leaks abstractions like a sieve or is so purely functional as to be impractical for real world use. Shall I list the componentization tech of yore? CORBA, OpenDoc, Java Server Faces, COM, DCOM (oh god, CORBA again!), SGML (the original component framework ), XML zoo (oh god, CORBA a third time).. JSON zoo, (a flippin' fourth time, are you kid…
I'll join you in a glass of "oh god, CORBA!" At least one good thing about the web is that people have given up hoping that RPC could be transparent.
Re: Reflections of an “Old” Programmer
#240I got lucky to have this advice 10 years ago. I did a Master degree on this area and my life changed, my software has high quality, evolve fast and I sleep nice every night with all the "chaos" under control. I can change languages and development processes fast and painless. I think the point is: you have to understand the abstract concepts of technology rather than languages or frameworks. As an example, if you understand Object Orientation, new languages will appear and disappear while your abstract concept will still be completely useful and applicable. If you study software engineering, it does'n matter if you will use scrum, RUP, you will get it fast because you already have all the base.