7 ms·

It's hard being an old programmer as some technologies that you used in the past, that were more productive than certain technologies today, are no longer popul

• jayd16 6y ago
  I can't help but feel cynical that a fair bit of modern complexity comes from the sheer amount of features that didn't exist. The variety of screens, interfaces, OSes and the accessibility aren't free. Those are why we use all these cumbersome frameworks after all.
• chrisco255 6y ago
  Oh really? Please tell me about the ultra-productive "Built For Internet Explorer" days of web dev.
  • icelancer 6y ago
    >> client side apps
    • smt88 6y ago
      Web apps are still client-side apps. OP likely meant "native apps" and mistyped it, but GP was justifiably confused.
  • cttet 6y ago
    In 2008 I only tested my CSS-heavy small website on my only browser, which is IE6 and quite content with it. Until I knew more later and it became a disaster.
  • watersb 6y ago
    Most development in the 20th century was not web development. Sure, there's always a tension of "simple" versus "limited". But simple was fun.
• dleslie 6y ago
  You've even drank some of the koolaid by calling them "client side apps". They're simply applications, or if you must, native applications! ;) I'm heavily reticent towards using web-based interfaces to remote services, and I think that's healthy and fine. As a developer, of course it's less complicated to not be negotiating network communication in order to create an application!
  • ithkuil 6y ago
    You've even drank some of the koolaid by the personal computer industry to call them applications: real applications clearly run on mainframes and reach the end user via terminal display units!
  • colejohnson66 6y ago
    So if a client side app is just an “app”, what differentiates it from a server side app?
    • dleslie 6y ago
      All of the user's data is controlled, managed, stored, and owned by the user; there are no remote servers.
• beamatronic 6y ago
  I very badly want to get back to this. Maybe with Python and Qt on Mac?
  • AlexanderDhoore 6y ago
    I don't trust Qt licensing anymore. Whatever company owns Qt will forever try to squeeze it for money. They recently changed their licensing AGAIN: https://www.qt.io/blog/qt-offering-changes-2020 https://www.qt.io/blog/qt-offering-changes-2020
    • tim-- 6y ago
      They have not changed any licensing. They have changed the way they are releasing their product. The only thing really that is different here is the fact that they are pushing less code as open source for their stable LTS releases. If you rely on having a stable Qt, why not pay the company that develops the software? You and I, the developers that use Qt without paying for it, still get the latest and greatest Qt, with all it's source code for free, under the same LGPL license that Qt has always been under.
      • ognarb 6y ago
        Actually Qt was not always LGPL, it was first under the QPL, then the GPL, and now the LGPL. So it is quite an improvement from a license forbidding commercial uses to a permissive license. There is also a legal framework to make sure Qt will remain open source forever: the KDE Free Qt Foundation.
        • tim-- 6y ago
          Historically you are correct, yes. I should have had an asterisk and explanation next to 'always'. The fun fact that this also brings up is that the KDE Free Qt Foundation also means that if Qt does not keep supporting open source Qt, then the framework code becomes licensed under the BSD. It is literally in Qt's best interests to keep the open source community by it's side. This does not detract from my point that the license of Qt is not changing.
• rubber_duck 6y ago
  Creating hello world and drawing trivial forms is just as simple with HTML/CSS/JS, you don't need a SPA MVC framework or component libraries or state management framework. Looking back to VB and other WinForms RAD tools it's easy to do that stuff and there are HTML WYSIWYG tools but that double-click code behind logic doesn't scale - software these days is distributed, has more complex requirements and expectations. Once you bolt MVC or MVVM or whatever to one of those GUI toolkits you get very close to modern JS framework complexity.
  • nightski 6y ago
    I laugh because you'd think the distributed part would be the toughest one. But nope, it's pretty easy. In fact the client/server model was pretty well understood even in the 90s (or well before that even). In my opinion what has exploded the complexity is the proliferation of environments. The execution environment of our software provides very few guarantees on what is available (no standard library) or even what language is supported (many JavaScript features and versions with varying support). That, combined with the explosion of devices including input modes, screen sizes, and resolutions has just made it extraordinarily difficult. We don't even have standard ui primitives like we did in the past. Every major website is expected to have a team of world class designers and reinvent the wheel. It doesn't need to be this way. But it's the way we have chosen. It has advantages, but I'd imagine the economic cost is enormous.
    • trixie_ 6y ago
      ExtJS was pretty close, but its license model was never good enough for mass adoption.
      • guggle 6y ago
        There's a free edition for small business and personal use and a perpetual "enterprise" license for $1,895. Not so bad for a commercial product. But yes, no free software.
    • rubber_duck 6y ago
• me551ah 6y ago
  Not to mention how native client-side apps consume far less memory and CPU than their web/electron counterparts. I miss those days when I would have a bunch of native apps constantly running and minimized. These days it's considered normal for a music player to consume 500MB of memory and for chat apps to consume multiple GBs of RAM.
  • jjeaff 6y ago
    But if you spent the same amount of money on your dev system adjusted for inflation, of course, then it could probably handle everything you could throw at it.
    • me551ah 6y ago
      It's only true if a handful of apps do it, but if everyone starts to do it then you end up with a scenario where RAM isn't enough for every application. And also from an end user perspective, not everyone has a powerful dev machine.
    • jonnypotty 6y ago
      It's ridiculous that we've relied on hardware to save us and that we do more and more every day. We clap our hands at a bit of text and some pictures on a screen taking hundreds or thousands of megabytes of memory. This incredible ineffecincy means that computers cost more than they should, not as many people have them as could, that we spend more resources than necessary to make them and more electricity to run them than we need to. Why don't programmers generally understand how incredibly wasteful we are with the resources we've been given.
    • deleted 6y ago
      [deleted]
• danielbarla 6y ago
  Delphi certainly was supremely productive for the kinds of one-off, bespoke enterprise apps that I was involved with, and it is valid to question why that was the case. I don't think the tooling was necessarily all that superior, the industry trend was simply way towards "slap a grid on top of that SELECT * FROM Orders". Clearly, there are many things wrong with that, but the fact that one could whip up several screens and essentially ship them in a few hours makes it a worthwhile thought exercise to think about what has been gained, and what lost. Most enterprise apps that I encounter seem to be massively overcomplicated for what they actually do.
  • gonzo41 6y ago
    Most enterprise apps that I encounter seem to be massively overcomplicated for what they actually do. I think the big issue is every app I use/develop in the enterprise needs single sign on and fine grained access control. Those modern requirements create a minimum layer of complexity that really slows things down. But yeah, the whole enterprise programming world really missed an opportunity with JavaFX. For all the shit they get being able to deploy desktop apps in a virtual environment is really powerful.
  • jonnypotty 6y ago
    What the hell else to business apps do? I'm genuinely interested to know what you think is the clear issue with showing users data from database tables.
    • danielbarla 6y ago
      I'm not sure I 100% understand your question, and it's also hard to respond without more context. Many Delphi apps back in those days were very lazily slapped together, with thin layers of code (or none) on top of whatever queries got the job done. There are performance issues, security issues, correctness issues (in terms of: does the app allow you to do some things that should not be allowed). There are also meta-level issues that came into play, as anything that did not fit into the out of the box patterns was so outrageously more expensive to develop that companies opted away from it, and in many cases UX suffered. On the other hand, we have now overreacted in the opposite direction, with many business apps having empty layers of code that do nothing except pass on the exact same message to the next layer, because, well, "that's how it's done in the real world", or something. Tons of boilerplate code get created that never end up adding any real value. Other than this specific example, there are plenty of YAGNI violations. I prefer something of a balance between the two.
• nikanj 6y ago
  Back in those days, one could take a full two-week summer vacation, and come back to the company still using the exact same stack!
• emmanueloga_ 6y ago
  but you can still use those tools on your own projects right? I've been learning and using XQuery and XSLT 3.1 and I really enjoy them! Also, common lisp :-) But yeah, it will be harder to use tech like that on my day job, wish I could.
• seangrogg 6y ago
  Isn't a day on HN unless someone complains about web development while pining for the days when they were building command line calculators in COBOL on their mainframes while sipping espresso with Turing and Dijkstra.
  • trixie_ 6y ago
    Don't worry, eventually the web development will be figured out and it retrospect we'll look like cavemen rubbing two sticks together.
    • seangrogg 6y ago
      I honestly hope so. Sticks are passable enough for addressing today's CRUD apps but I'll readily take scalpels and plasma torches as they become available.
  • jonnypotty 6y ago
    Are you really gonna defend the current state of Web development?
    • seangrogg 6y ago
      Nope. Web development could (and should) be much cleaner. But it doesn't get there by tirelessly adding to the list of curmudgeonly comments over and over and over. As a web developer who made zero choice for HTML, CSS, and JavaScript to be in the position they are today and who is wholeheartedly open to seeing the chances that things like wasm could bring it is honestly more tiring reading yet another derisive comment about JavaScript fatigue than it is actually dealing with the churn in the ecosystem.
• goto11 6y ago
  The advantage of web apps is in deployment. Developing a stand-alone app in Delphi or Visual Basic was highly productive, but distribution, installation and updating was a headache. And it would only run on one platform.
  • trixie_ 6y ago
    Ease of deployment does not preclude ease of development.
  • FpUser 6y ago
    " but distribution, installation and updating was a headache" I am not sure what headache are you talking about. My product/s are usually single exe with dependencies statically linked and acting in dual role: setup and the end software itself. Installation goes like this: 1) customer clicks on link 2) setup.exe is downloaded and ran. 3) setup copies itself to a proper location and renames itself to yourwonderfulsoftware.exe. 4) When running it may communicate to servers to get whatever data/files/licenses it needs if any. 5) It also checks for new version and if there is any it can self update if you click that "update" button. 6) Before update starts the old version and data are always backed up. Yes it does lack that instant satisfaction experience that comes with good web applications. But then again the if software I want to make looks like a good candidate for Web target way I will implement it as a web app. In hopefully not too distant future Web assembly may make the difference minimal but we will have to wait and see how it goes.
• namelosw 6y ago
  It's strange we eventually reached a place where things go unproductive... Similar to Smalltalk, and Common Lisp are super fast to develop things. Maybe it is they were relying too much on their superior environment? So that other languages cannot easily replicate so that more generic but not so productive technology stand to the last?
• kbenson 6y ago
  There's always a trade-off in technologies between things that are easier to learn, and things that are easier to use once you've learned them. When there's a steady state of people cycling through the system, it's easy to cater to specific segments of the population with different types of tools. Those that don't need hand holding and want the extra bells and whistles to get exactly what they want out of something will likely find their needs met in such a situation. Now, consider that there's far more new people coming into programming each year than the prior year (or even if it's not strictly true on a year-over-year basis, there are far more software engineers with 1-10 years of experience than there are with 10-20 years experience, possibly even than those with 10+ years experience). In a market such as that, ease of use is paramount and the killer feature that drives almost all you usage. Catering to amateurs is the path to increased usage, and mind-share, and market-share where applicable. With that in mind, is it really any wonder that amateurs are catered to so much that there's actually a regression in tools that cater to professionals? My guess is that if you look into subgroups which are not friendly to new users for one reason or another (most commonly because of complexity and skill), yet still have retained users for some reason, you'll find high quality professional tools. I think C/C++ probably fits this, as well as systems programming, and kernel development. I'm not part of any of those subgroups, but my guess is they have not only retained the quality of their supplemental tools, but increased them.
  • pjmlp 6y ago
    If you code in C++ with tooling like QtCreator, Clion, VC++, C++ Builder and everything enabled (static analyses), it can be quite productive and even quite secure. However it still largely ignored as good practices, in a world where teachers still use IDEs like Turbo C++ as teaching tool.