3 ms·

Your requirements are contradictory and incomplete: - No single language can do all of that successfully, unless you ditch GUI and client-server models - W

Your requirements are contradictory and incomplete: - No single language can do all of that successfully, unless you ditch GUI and client-server models - Without external dependencies you will either be reinventing the wheel or adding lots of layers - All software will require maintenance, more layers equal more maintenance - All software can be compromised or hacked, more layers equal more attack surface - If it has to last a long time, it cannot use anything that moves fast (or without LTS releases), but it depends on what you define by 'last' and 'a long time' This doesn't mean your question is stupid, it's just not something that is simple and resilient while also being those other things. If it is a single-user, single-machine "app", you could use a plain UTF-8 text file which can be read and written to by any relevant text editor. No app is the best app in this case. This does depend in what kind of information you intend to CRUD.

oneplane 5y ago
If I were to make a lot of assumptions, you are probably going to need something that can compile statically into a (mostly) self-sustainable binary. That means Java and C# .NET are out. You can use a GUI, but only if you pin yourself do a single OS and single GUI system. For a macOS/iOS target, I would say: Swift. It mostly compiles down to a single application (well a bundle...) and the native frameworks supply persistence and UX methods that last long enough to be considered 'a long time' by my personal vague concepts. For Windows, you'll be stuck with something like Win32 C++. For Linux, you'll probably be stuck with a choice between GTK and Qt, and again something like C++. If you don't need to target any of those systems specifically, or you don't need to make use of a UI, you can do Rust or Go for all/any of them. If you want to do something for the web, you are screwed. You'll always end up targeting a scoped set of browser versions, use something that either is or compiles down to CSS, JavaScript and HTML (3 languages at least), and if you run a server component, that requires maintenance too (even static file serving). Nothing on the web really 'lasts a long time' as-is.
johnmorrison 5y ago
Typescript/JS React FE + Node BE - one language.
- oneplane 5y ago
  No, that's more like four languages: Typescript, CSS, HTML and the JavaScript the TS gets compiled down to. You can't just write TS once, and never touch it again, because you are now targeting a webbrowser and running a webserver, and are probably using a billion NPM packages. None of those are 'static' for a year, let a long a 'long time'.
  - johnmorrison 5y ago
    Overly pessimistic view. You do only have to write one language, and web pages are highly backwards compatible. You don't need to use any NPM packages.
    - oneplane 5y ago
      We're talking about low maintenance, low security risk and long lasting. None of those are compatible with transpilers, node, javascript or web tech in general.
Supermancho 5y ago
> If it is a single-user, single-machine "app", you could use a plain UTF-8 text file which can be read and written to by any relevant text editor. No app is the best app in this case. This does depend in what kind of information you intend to CRUD. I would similarly say a Rails app that uses a filesystem DB for records, sessions, logging, etc despite never having touched Ruby more than 3 times in the last 2 decades. Many of your listed points are puzzling though. > No single language can do all of that successfully, unless you ditch GUI and client-server models There's nothing in the requirements about a GUI or client/server model. A CRUD app by API is pretty common. > - Without external dependencies you will either be reinventing the wheel or adding lots of layers No need for reinventing or using additional "layers" (whatever that's supposed to mean). > - All software can be compromised or hacked, more layers equal more attack surface "not easily" can be interpreted many ways, but assuring that nothing is 100% secure is irrelevant. The question is quite sophisticated, within modern technology choices. However, the ease of CRUD app generation has been streamlined by Ruby to a ridiculous degree. Ruby has been great for this kind of thing for a long time, despite it's problems as a language for larger applications. People who are recommending Java, using Spring or not, are either ignorant or in denial. Java is a horrific choice for development speed and reliability for what amounts to requirements for a small application. Additionally, big/popular frameworks like Laravel/Django etc are also going to slower to develop and more problematic than a simple Rails app. This is primarily because of the ecosystems that shun the concept of a filesystem as a DB because it breaks their sensibilities about "the right way to do things".
- oneplane 5y ago
  As I described: the requirements do not list enough. I use the word 'layers' as a loose term to describe anything from APIs between code written in different languages that needs to interact, modules within languages, frameworks, libraries, package managers and other 'things' that end up in your development lifecycle that can all introduce vulnerabilities, incompatibilities and other maintenance tasks. If you want less maintenance, you have to reduce your dependencies, and to do that you might need to (partially) re-implement some of the features in your dependencies to be able to discard them, thus re-inventing the wheel. Most of your other replies are not really up to you, and can only be answered by mouzogu.

oneplane 5y ago

If I were to make a lot of assumptions, you are probably going to need something that can compile statically into a (mostly) self-sustainable binary. That means Java and C# .NET are out. You can use a GUI, but only if you pin yourself do a single OS and single GUI system. For a macOS/iOS target, I would say: Swift. It mostly compiles down to a single application (well a bundle...) and the native frameworks supply persistence and UX methods that last long enough to be considered 'a long time' by my personal vague concepts. For Windows, you'll be stuck with something like Win32 C++. For Linux, you'll probably be stuck with a choice between GTK and Qt, and again something like C++. If you don't need to target any of those systems specifically, or you don't need to make use of a UI, you can do Rust or Go for all/any of them. If you want to do something for the web, you are screwed. You'll always end up targeting a scoped set of browser versions, use something that either is or compiles down to CSS, JavaScript and HTML (3 languages at least), and if you run a server component, that requires maintenance too (even static file serving). Nothing on the web really 'lasts a long time' as-is.

johnmorrison 5y ago

Typescript/JS React FE + Node BE - one language.

oneplane 5y ago
No, that's more like four languages: Typescript, CSS, HTML and the JavaScript the TS gets compiled down to. You can't just write TS once, and never touch it again, because you are now targeting a webbrowser and running a webserver, and are probably using a billion NPM packages. None of those are 'static' for a year, let a long a 'long time'.
- johnmorrison 5y ago
  Overly pessimistic view. You do only have to write one language, and web pages are highly backwards compatible. You don't need to use any NPM packages.
  - oneplane 5y ago
    We're talking about low maintenance, low security risk and long lasting. None of those are compatible with transpilers, node, javascript or web tech in general.

Supermancho 5y ago

> If it is a single-user, single-machine "app", you could use a plain UTF-8 text file which can be read and written to by any relevant text editor. No app is the best app in this case. This does depend in what kind of information you intend to CRUD. I would similarly say a Rails app that uses a filesystem DB for records, sessions, logging, etc despite never having touched Ruby more than 3 times in the last 2 decades. Many of your listed points are puzzling though. > No single language can do all of that successfully, unless you ditch GUI and client-server models There's nothing in the requirements about a GUI or client/server model. A CRUD app by API is pretty common. > - Without external dependencies you will either be reinventing the wheel or adding lots of layers No need for reinventing or using additional "layers" (whatever that's supposed to mean). > - All software can be compromised or hacked, more layers equal more attack surface "not easily" can be interpreted many ways, but assuring that nothing is 100% secure is irrelevant. The question is quite sophisticated, within modern technology choices. However, the ease of CRUD app generation has been streamlined by Ruby to a ridiculous degree. Ruby has been great for this kind of thing for a long time, despite it's problems as a language for larger applications. People who are recommending Java, using Spring or not, are either ignorant or in denial. Java is a horrific choice for development speed and reliability for what amounts to requirements for a small application. Additionally, big/popular frameworks like Laravel/Django etc are also going to slower to develop and more problematic than a simple Rails app. This is primarily because of the ecosystems that shun the concept of a filesystem as a DB because it breaks their sensibilities about "the right way to do things".

oneplane 5y ago
As I described: the requirements do not list enough. I use the word 'layers' as a loose term to describe anything from APIs between code written in different languages that needs to interact, modules within languages, frameworks, libraries, package managers and other 'things' that end up in your development lifecycle that can all introduce vulnerabilities, incompatibilities and other maintenance tasks. If you want less maintenance, you have to reduce your dependencies, and to do that you might need to (partially) re-implement some of the features in your dependencies to be able to discard them, thus re-inventing the wheel. Most of your other replies are not really up to you, and can only be answered by mouzogu.