Making a website you with functioning log-in and log-off.
This was the 90's. It was surprisingly hard to implement this in a workable, reliable, secure way, and no one in our company of 50 programmers had ever done such a thing before!
I recall being puzzled for way too long at how to prevent someone from coming to a browser that had just logged off from our web app, and clicking the back button a couple of times to be logged in again.
I coded the same thing (actually an online magazine with comments on articles, a forum, and a form for signing up for email updates), around the same time. I used classic ASP. I shudder to think of all the security holes I must have had.
I was in Kuala Lumpur, Malaysia a few months ago. I wanted to see a film. I searched in Google for films showing in Kuala Lumpur. I found myself on a web page that, while accurately listing movies and schedules currently showing, looked like it had been created around 2000.
This made me somewhat sad, because it showed me what the web browsing experience could have been today.
I'm glad I got off the train as web sites became web apps. I made one of the latter, though it actually was designed to complete certain tasks as opposed to being a container for content.
Websites now seem to be trying to emulate native apps - not just in terms of cramming a bunch of UI into a page, but also in the closedness. I hate how 95% of content sites bury the hyperlinks to anything that takes you off their site, including the source.
Right, and then you'll add images because you're not a monk. Remember when images were content and not chrome? That's another practice to bring back.
Even with @2x images or whatever, they at least can avoid blocking the load of the rest of the page and rendering the layout. As you add a bunch of other files that have to be fetched over another HTTP connection and then affect the rendering of the page (for example, fonts), we're back to sluggishness.
Yes I agree here. When I was in high school in the mid 90's I was able to create my own html pages in a text editor. The web was simple back then we had frames and tables and that was enough.
Webpages are massively over engineered you shouldn't need a scripting language to display an article of text and some links.
And now that we have HTML5 and CSS3 the technology for writing web pages with a text editor is better and simpler; many techniques and features have transitioned from impossible to easy or from convoluted hacks to straightforward.
Do we know that though? Many people who are users or are web devs or project managers or executives? I think that's why there's been a trendy towards minimalist design; it looks pretty good and it's typically fast.
I've been programming in Java since Java 1.1.8 and I hazily recall several regression problems under Sun's stewardship. My gut feeling is that the rate of regressions in Java updates has remained steady.
If the rate has increased significantly under Oracle's stewardship, this is something I'd like to write about in my Java newsletter.
Do you have some statistics to demonstrate that regressions have become substantially worse since Oracle took over Java? I'd happily acknowledge you as a source!
I recently started to write an article describing how java.lang.String was one of the classes that the Java creators got mostly right in Java 1.0. This contrasts to other Java 1.0 classes such as java.util.Date, which, as the usage of Java spread, and some good practices emerged, revealed itself to be poorly implemented.
I wanted to show in my article how one of String's strengths is that String efficiently shares memory with substrings. But then when I looked into Java 8's String source code, I was surprised to find that this was not the case. It seemed I had been working with false assumptions for years.
Now, thanks to Heinz's article (OP), I discover that this was a change in the String class.
Long ago, a man who had been programming for 30 years told me about his theory of the half-life of programming knowledge being roughly 18 months. Today, Java has made me believe his theory a little bit more.
> Today, Java has made me believe his theory a little bit more.
I think Java is sort of an exceptional case here in that the language stays relatively stable and evolves very little over time. Also they tend to not change internal details of the standard library without reason, so even lots of things programmers shouldn't rely on, such as behaviour of substring() will stay unchanged for quite long.
JS now is moving fast but for the longest time it was stuck in stasis with various incompatible implementations floating around. And almost any knowledge on it was probably invalid in one of those implementations.
So would I. But another way to look at this is, instead of "I'd quit", saying "they'd have to pay me 3x more to work in a place like that". At which point you can again start looking at it as an economic problem.
If you work at a company with more than 500 employees that does all but two of those, I'd like to hear more about that. As I wrote those bullets, I filtered them through my experience of consulting for F500 companies, and when I found myself writing something I'd seen reliably deployed across entire organizations, I edited the bullet until that was no longer the case.
About the closest I've come to seeing any of these bullets deployed reliably is Microsoft's developer training and deprecation of the standard C library, and that initiative was so out-of-the-ordinary that it was newsworthy, and widely reported.
But to actually earn that bullet, Microsoft would need to deploy those same measures across all its contractors, and, more importantly, deploy them on internal IT and line of business systems, not just the Windows and Office codebases.
When I learn a new, perhaps hyped-up computer language, I soon run into difficulties, no matter what the merits of the language. The difficulties are lack of tooling. eg, no debugger - or only a rudimentary one, no static analysis, no refactoring, no advanced code browser.
If the language is successful, these things come with time.
When you develop an in-house language, you'll never get the advanced tooling that makes for a great software development experience. This, for me, was why I was surprised by Joel Spolsky's announcement of an in-house language.
(Although, to be fair, these things didn't really exist of VBScript nor for PHP at the time Wasabi came to be.)
I think your bracketed comment says it all; there was no obvious alternative at that time which would satisfy the market conditions. The VBScript version was super easy to install for most companies with the servers they already had available. They had a selling feature which was entirely dependent on this terrible technology. So they mitigated it. It's all pretty reasonable.