Live data from Hacker News

Reflections of an “Old” Programmer

bennorthrop.com

251–260 of 339 posts

Re: Reflections of an “Old” Programmer

#251
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.

I don't see the obfuscation of the client and server separation .Net Web Forms have.

It is declarative, just like the .Net, but I don't think it will bring the same kind of problems. What will probably happen is that when things get complex, you'll have to manually write the complex parts - that's a very sensible "problem" in my opinion.

Re: Reflections of an “Old” Programmer

#252

Hm. The author works for a web/mobile development agency and uses React Native and GWT as examples of the new and the old, respectively. I hope it isn't news to anybody here that this sort of work is a race to the bottom and has such turnover precisely because it's mostly being done by junior developers. Linux systems programming arcana, for instance, doesn't disintegrate so quickly as the ten years the author cites.…

What option do people have?

We created a universal interface for computing, and it is web programming. It does not matter if you are creating a CRUD application of an improved Google search, you'll have to present it the same way. Thus, unless you are willing to give up control on the presentation of your work, you'd better learn it.

Re: Reflections of an “Old” Programmer

#253
post #242

Earlier quoted context omitted.

Dejavu: > Early 2010s: Cloud computing 1960s: Client/Server Architecture. Big servers and small clients. > Mid 2010s: Quantum computing before 1950s: Analog Computers https://en.wikipedia.org/wiki/Analog_computer There is nothing new under the sun. Analog computers passed away because they were not usable. Ok, quantum computing may be different but their practical use is also questionable.

> Dejavu: [...] 1960s: Client/Server Architecture. Big servers and small clients. This is right and wrong at the same time. Right, because the Cloud reuses some basic concepts from the mainframe era (e.g., virtualization), which had been neglected for some time. Wrong, because writing your application to run efficiently on a mainframe is totally different from writing your application to run efficiently on Cloud infr…

> there is no thing such as small clients anymore

This is also right and wrong :-) Right regarding your perception, wrong regarding relative power. 1960s clients were small compared to today's small clients. However, 60s server were also small in relation to cloud servers. Today our small clients provide browsers and stuff like that but they aren't useful without servers. They can't run top-notch 3D games without high-end servers. The third wave of C/S will be in the area of A.I. with (small) clients which will possibly as powerful as today's cloud servers.

Re: Reflections of an “Old” Programmer

#254
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…

CORBA and DCOM were really not great but I don't think you're qualified to have a go at these things if you think that SGML is related to DCOM or that XML and JSON are "componentization tech".

I'd also note that despite how unfashionable it is and was, COM was a remarkably successful component framework. A lot of Windows apps use COM heavily and not because they were required to do so - they componentized themselves using COM because they wanted to and it delivered real value to them.

In addition, I'm not sure how you are defining "component", but the term is rather similar to library, and modern apps frequently pull in enormous quantities of libraries. It worked out OK, actually.

Re: Reflections of an “Old” Programmer

#255
post #211

Earlier quoted context omitted.

"If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing?" Because if it hasn't "succeeded", for suitable definitions of "succeeded" in 50 years, as an old fart approaching 40 myself my assumption is that there is a good reason. I was much more willing to believe the "everybody else is just stupid and can't see the obvious brilliance" reason when I was younger, but as I…

The reason why Lisp is not mainstream is its power. It makes writing DSLs extremely easy so that everyone can write his own DSL to solve a certain problem. Such style of writing however makes Lisp code unsuitable for group working, and hence unmaintainable. It explains (imho) why there are so many unmaintained Lisp projects. Clojure has a different problem. It is based on the JVM infrastructure which was (imho) an un…

There's a lot of truth to this. One thing I've noticed is that there are many different styles of writing Common Lisp; many of the older styles (heavy use of lists as data structures or very heavy use of macros) tend to not work well (at all!) in team software engineering environments. OTOH, if you agree on some coding standards with your team, team software engineering with Common Lisp can be a real pleasure. Of course that's true in any language, but if you're a lone ranger, CL makes it much easier to shoot yourself and your team in the foot than most other languages.

Re: Reflections of an “Old” Programmer

#256

Earlier quoted context omitted.

The reason why Lisp is not mainstream is its power. It makes writing DSLs extremely easy so that everyone can write his own DSL to solve a certain problem. Such style of writing however makes Lisp code unsuitable for group working, and hence unmaintainable. It explains (imho) why there are so many unmaintained Lisp projects. Clojure has a different problem. It is based on the JVM infrastructure which was (imho) an un…

I have felt some of the pain and gripes you have with Clojure and while I am not denying that some of them are very real, I am not sure if you understand the mentality and philosophy behind Clojure as far as most of us who use it seem to have decided at least. Put succinctly, it is to balance practicality with features to get real work done. Clojure is quite wisely based on the JVM because the idea was not to create…

I understand why Clojure deliberately focuses on the Java ecosystem. If I still would be in Java development today I likely would use Clojure. If I were in web development I likely would use Clojurescript. Currently I prefer the Emacs/SLIME/SBCL toolbox which is more responsible (and Nim by the way).

My humble two cents to the Clojure team:

1) You should implement a cache mechanism ("save-image") for native code so that at least the annoying startup time of clojure apps is gone. I wonder why Java doesn't support native caches to this day.

2) The weird Java stack trace problem could be solved by providing an individual stack tracer which is close to the source code. I know that this is not possible for Java libraries but at least clojure stack traces should be presented in a more convenient manner.

Re: Reflections of an “Old” Programmer

#257
post #198

Earlier quoted context omitted.

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.

I don't see the obfuscation of the client and server separation .Net Web Forms have. It is declarative, just like the .Net, but I don't think it will bring the same kind of problems. What will probably happen is that when things get complex, you'll have to manually write the complex parts - that's a very sensible "problem" in my opinion.

Bingo.

Re: Reflections of an “Old” Programmer

#258

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.

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…

What kills me about a lot of the technology we use today is that few people, at least in positions of power are brave enough to pause every now and then and say, "WTF are we doing?" So many technologies live on because of so-called "critical mass," big investments, marketplace skills, and other things that are about anything other than the technology itself. These of course are mostly practical reasons and important ones at that, but at some point it becomes impractical to continue to cling to the practical reasons. IMO, the ability to do something truly different to make an advancement is often what separates innovators and intelligent people from the rest. When someone does try to act, the market essentially crushes them accordingly, making most efforts null and void, and dulling the senses and hope of everyone else watching, warning them not to try anything themselves.

x86 CPUs, web browsers, popular operating systems, and so on are all examples of this problem. At some point I really wish we could do something different, practical reasons be damned. It's sad that as many cool, "new" things we have, some of the core, basic ideas and goals are implemented so poorly and we are effectively stuck with them. This is one reason I hate that almost all software and hardware projects are so rushed, and that standards bodies are the opposite, but with only the bad things carried over. The cost of our bad decisions often weighs for much longer than anyone could imagine, just ask anyone who has designed a programming language or something major in software ecosystems.

As much as I enjoy all the new, shiny stuff, it makes me sad thinking about BBSs and old protocols Gopher that represented the old guard, alternate routes, and the fact that we really haven't come that far. Overall things of course are a lot better, but in many ways I often feel like we're treating the symptoms and not the cause or just going around in circles.

I could go on, but the rant would be novel length.

Re: Reflections of an “Old” Programmer

#259
post #211

Earlier quoted context omitted.

> why should we suddenly start writing Lisp? The language is older than C, for god's sake. If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing? All those nice "new" features which Python and C++ are praised for (lambdas, closures, list comprehensions) have been available for almost 50 years. Lisp was way ahead of its time. It just lacked the hardware power which we…

"If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing?" Because if it hasn't "succeeded", for suitable definitions of "succeeded" in 50 years, as an old fart approaching 40 myself my assumption is that there is a good reason. I was much more willing to believe the "everybody else is just stupid and can't see the obvious brilliance" reason when I was younger, but as I…

> Clojure seems to not be growing … that was Lisp's best chance for growth I've seen in a long time

I wouldn't call Clojure a Lisp; it's a Lisp-like language with some interesting ideas, but not really Lisp at all.

As to why Lisp has failed to take hold where other languages have succeeded, I'll use a G.K. Chesterton quote: 'Christianity has not been tried and found wanting; it has been found difficult and not tried.' It's not that Lisp itself is difficult; it's that Lisp is different from lesser languages, and people have difficulty learning something different from what they're used to. Lisp has not been tried and found wanting; it has been found different and not tried.

So … try it! You may be surprised.

Re: Reflections of an “Old” Programmer

#260
post #35

This is the first time in history there are a huge number of "old", nay, wizened, programmers around in comparison to young ones. Make of that what you will. As a 40+ programmer, who knows what becomes of those who move into management, I am seeing lots of my cohort falling back into actually making things, as a way to preserve our hard-won value. This makes me happy. And you whippersnappers better watch yourselves ;…

As a 40+ web dev, who doesn't know what becomes of those who move into management, I'd be interested to know: what becomes of them?
Post reply on HN