Live data from Hacker News

Reflections of an “Old” Programmer

bennorthrop.com

231–240 of 339 posts

Re: Reflections of an “Old” Programmer

#231

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…

I didn't know intercooler existed, so thanks for the link. For anyone else, it's worth reading about, it actually has a very well written introduction, guide and examples.

Re: Reflections of an “Old” Programmer

#232

Earlier 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.

Is the web browser the best technology to achieve "multiplatform" for an office suite? It makes sense from a purely practical sense but technologically it's pretty terrible.

Re: Reflections of an “Old” Programmer

#233
post #97

Earlier 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…

> I assume you're talking about things like optimizing a search of a list by using a better data structure or sorting algorithm.

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

#234
post #157
post #13

I'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…

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 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

#235
post #70

Earlier 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.

You're like a living version of this comic but for IT nerds...

https://xkcd.com/435/

(Just to be clear, in the IT version, you're not standing where the mathematician is.)

Re: Reflections of an “Old” Programmer

#236

Earlier 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…

> And yet "open mail in new tab" in Gmail has been dead for at least a couple of years now.

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

#237

Very 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...

And make it a little clearer that they aren't his ideas, so noobs don't get the wrong impression.

Re: Reflections of an “Old” Programmer

#238
post #198

Earlier 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.

Yeah, there definitely isn't a silver bullet. However, intercooler stays a bit closer to the metal than the old ASP.NET stuff, so it doesn't have the opacity problems that came with it.

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

#239
post #157

Earlier 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…

You forgot microservices. I'd forgotten Java Server Faces, was that related to Java Beans?

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

#240
A guy from Oracle advised me on I chat we had, on early days of the Google Talk. His name was Matthias Weßendorf (I don't forget people I am grateful) and the advice was something like this: "Study software engineering, it's more difficult to change than technology, and you will use it for all your life".

I 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.

Post reply on HN