5 ms·

No 100%, but close. 1- Shield away from dependencies. Use languages that are robust (no JS, no PHP) and if possible, generate native .exes (Delphi, Rust, Go,..

• Crinus 7y ago
  I mostly agree except the Java part. AFAIK Java (at least J2SE) has been very stable with backwards compatibility going back to the 90s.
  • DannyB2 7y ago
    Furthermore, you can package a JDK or JRE with the application, such that the application uses the packaged JDK/JRE, and ignores any that may be installed on the OS. JDK/JRE's are open source, and binaries are available from AdoptOpenJDK, Red Hat, Azul Zulu, and others. "Maintenance" might be to simply swap out one JDK with a newer one and then make sure the app still works -- which it should. But there ARE some ancient things in Java that are being deprecated. Or moved out to separate libraries not bundled into the JRE. I would also point out that with Docker you could package every possible dependency into the container. The container is now portable and has no dependencies outside of what is packaged in the container. To the user, they don't care what technology or Rube-Goldberg contraptions exist within the container. Also see AppImage.
  • mamcx 7y ago
    Is similar with .NET and other environments (C++, js), where is possible to get his metric IF you know what you are doing. But the ecosystem push harder away from this.
  • altmind 7y ago
    java had: * bundled xerces around 1.6, breaking apps that also carried their own xerces * removed sun.misc.Unsafe from v11, breaking legit apps the apps that use off-heap memory * sun and later oracle made everything to make applets useless, creating ridiculous security requirements and no clear way for a user to whitelist trusted applets. same for java web start. they had no problem disabling MD5 and RSA in their SSL impl, breaking the old clients.
• austincheney 7y ago
  > JS is the anti-tesis of zero maintenance. If you know what you are doing you can write zero dependency code that works well with old and modern browsers alike. This isn't as hard as it sounds either.
  • tmikaeld 7y ago
    Not sure why you're downvoted, back-end JS written from the ground up and hardened by usage really do not require maintenance. Especially with solid API's like with Cloudflare Workers V8 variant.
  • Silhouette 7y ago
    Sure you can, but it might take you 2-3x as long to get the same results as you could have got by using modern JS features and APIs that aren't supported in older browsers, and it might take you 10-20x as long if you also have to reinvent the wheel for everything instead of using a few good libraries. For most projects in the real world, that is not going to be a trade-off worth making.
    • austincheney 7y ago
      The only way that is true is if your friendly abstraction is producing your test automation for you. Having no understanding of the DOM and the standard APIs then writing without dependencies might take 1000x longer. I was assuming a competent developer when I mentioned this isn’t that hard.
  • BjoernKW 7y ago
    Case in point: https://bjoernkw.github.io/hexrgb/ https://bjoernkw.github.io/hexrgb/ Zero JavaScript dependencies. The only dependency is Bootstrap and that's just used for hassle-free layout and styling. The application works just as well without it. Admittedly, it's not a huge application but there's nothing in principle that would preclude a more complex application. The use of const prevents Internet Explorer up to IE 10 to run the application but that's a small trade-off I was willing to make in favour of more robust code.
• itake 7y ago
  > 2- If possible (mobile) use iOS. Android is not robust at all for long term prospects You can't use mobile at all. Apple requires you to update your app every year to support their new tooling. Just in iOS 13, if your app uses FB login, you need to add Apple Login. Or, every year, you need to re-generated and update your push notification certificates. Apple releases a new iPhone and then you have to update your marketing images in the iOS store with the new pixel dimensions. Its never ending.
  • mamcx 7y ago
    > Apple requires you to update your app every year to support their new tooling. ????. I barely do this each 2 or 3 years. Also, I keep away to high dependencies, so maybe I get lucky. I do small stuff like - re-generated and update your push notification certificates. - update your marketing images - Recompile once per year? That is so close to zero maintenance as is possible to get.
    • wlesieutre 7y ago
      The current language Apple is using is: >Starting April, 2020, all iPhone and iPad apps submitted to the App Store will need to be built with the iOS 13 SDK or later. They must also support the all-screen design of iPhone XS Max or the 12.9-inch iPad Pro (3rd generation), or later. If you want to properly support iOS 13, that also means implementing dark mode support and breaking your application delegate apart to a scene delegate for multiple instances. In addition to the notched screen "safe area" changes that most developers have probably caught up on by now but are becoming mandatory. Previous years it's meant supporting flexible sizes for new devices, sizes for split screen multitasking, drag and drop, siri intents, adding @3x retina assets, changing out UIWebView to the (not directly compatible) WKWebView, and a million other things. For a simple app with minimal support for iOS's growing featureset, maybe some years you can get away with loading it into this year's XCode, clicking the automatic code update button, and compiling. But polished iOS apps put a lot more work into keeping up. I don't have any knowledge of how Android compares, but iOS is definitely a moving target and Apple isn't afraid of deprecating things or mandating support for newer features.
    • 7y ago
• throwaway_bad 7y ago
  > if possible, generate native .exes Exe is exactly what I think of when I think of bitrot though. None of the games from my childhood can run on a modern OS. If you're running js or python etc, even if the interpreters are no longer widely available in the future, people using your code can still try to port it themselves (instead of demanding that you support them throughout the eons).
  • bradhe 7y ago
    > None of the games from my childhood can run on a modern OS. I don't think that's within the time horizons that OP is trying to consider. That's kind of like saying "no one (or very few people with great effort) can read the books that we wrote in the middle ages!"
    • throwaway_bad 7y ago
      I hate that you're right that a mere decade is an impossible time horizon for the vast majority of apps. Low maintenance simply means they can afford to give a few months to shut down a service rather than the next day.
  • Crinus 7y ago
    .EXE games do not work out of the box but because of existing overall backwards compatibility support and the effort of some enthusiasts, they are still the most likely to work compared to anything else. For Win32 pretty much anything can be made to work with Windows' own compatibility settings, dgVoodoo2 (for games) and minor tweaks. I have many applications and games from the 90s and 2000s, both in digital and physical form and the only issue i face to make them run in modern Windows 10 is the DRM some games in the mid-2000s had (i avoid anything with DRM nowadays). For 16bit Windows on 64bit OTVDM (https://github.com/otya128/OTVDM https://github.com/otya128/OTVDM) should make most stuff work (especially games). This is also great for installers. For DOS, DOSBox for games and vDos for applications should run pretty much anything better than when they were new. DOSBox also works if you have Windows 3.1 installed. Yeah these aren't exactly native (vDos does try to use some OS services though) but the UX is pretty much the same with what you'd get even back in the 16bit Windows days when trying to run a DOS application.
• kyriakos 7y ago
  I will disagree there. I have an application generating revenue running on apache / php for the past 2 years unattended. Basically I have no spare time anymore to maintain it, just paying the server costs and it keeps going.
  • SavageBeast 7y ago
    You might want to ssh in there and do a "df -k /" just to see that your system isn't near running out of disk. Systems that log will do this sooner or later and no house keeping in 2 years makes you a prime candidate. Nice work building a revenue generator that can run untouched!
  • deweller 7y ago
    "Robust" has different meanings. I think the OP is equating robust with strongly typed and compiled. I have found well written PHP code requires very little unplanned maintenance. When I package the application in a docker container along with its dependencies and a webserver (nginx), I find that I can run a PHP application for years without having to worry about it. In this sense, PHP code can be very robust in the sense that there are little surprises once the application goes into production. The PHP ecosystem is very mature.
    • jitendrac 7y ago
      That is true, I created a college website in 2009, it used legacy MySQL drivers and ie6 compatible code. Every year I go back to visit the url, it works flawlessly with latest content. They even didn't bothered to change admin creds till 2017. Site is still up and running
• ooooak 7y ago
  not true, I have lots of experience in PHP and if I write code in go sure it will have more bugs than my PHP implementation. how familiar are you with your current stack matters a lot. Also, That does not mean you should use a runtime where 100 things can go wrong (talking about node). if the goal is to maintain an application and catch issues at compile time. go with a better type system Haskell/Ocaml/Rust. Another option would be to use generative testing where you have tight control over what gets in, for example, Clojure/Spec.
• deleted 7y ago
  [deleted]
• NohatCoder 7y ago
  Wanna play some 11 years old bootleg Tetris? http://nohatcoder.dk/scriptris/ http://nohatcoder.dk/scriptris/ I coded that to run in every browser I could get my hands on. Browsers of the last 10 years have been very good at maintaining backwards compatibility, so no updates needed, at all. They may rewrite the OS cores from scratch (or in Scratch) and replace all the current instruction sets, browser vendors may come and go, and new features will keep on being added, but none of that will break my game. Care to explain how JavaScript is not robust?
  • mamcx 7y ago
    You do JS in the old days. JS today is a bigger mess. Is possible to avoid problems I use vue, without npm, package managers or anything else than direct link in the head. But I need to be care-full in what to code and check support across browsers. --- About "not robust". In fact what need to be defended is how is possible to call it robust! But anyway: JS is a badly designed language, have weird edge cases, and will fail silently (the worst of all) in many ways. A robust language not only catch stupid errors, but have a better std support (like having integers!) and better defaults and ways to do data transformations.
    • NohatCoder 7y ago
      It is not moving the foundation I have built on, a working program continues to work, that is more than one can say about most platforms.