| |
| ▲ | treflop 7 days ago | parent | next [-] | | Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem. In fact, I wish everyone had just copied Java’s model instead of inventing their own worse model. I love Python but it has a terrible package ecosystem with mediocre tooling that has only gotten worse with time. JavaScript has gotten better but it seems they are just re-learning things that were long figured out. When I see new package managers, I just see a list of problems that they forgot to account for. Which I find strange when there have been many package managers that you can learn from. Why are you re-inventing the wheel? | | |
| ▲ | demosthanos 7 days ago | parent | next [-] | | In JetBrains's Developer Ecosystem 2023 survey, 50% of developers were still regularly working in Java 8 [0]—the exact kind of "stick with the old version of the runtime" solution described in TFA. [0] https://www.jetbrains.com/lp/devecosystem-2023/java/ | | |
| ▲ | lucianbr 7 days ago | parent [-] | | Java 8 is 10 years old. If you had a project with a Java version that was recent 4 years ago (11 - 14), you could run it without any problems or changes. | | |
| ▲ | demosthanos 7 days ago | parent [-] | | Because they made the design choice to stop making large breaking changes to the language and tooling. Java 8 to 9 wasn't easier than Java 8 to 17 is, it's getting off of Java 8 that is hard because they made the choice to break so much in 9. Node does not promise indefinite backwards compatibility, which is a design choice that they've made that allows them to shed old baggage, the same way that the Java developers chose to shed baggage in 8->9. Neither choice is inherently better, but you do have to understand which choice a language's designers were making during the time window in question when you go to run it later. |
|
| |
| ▲ | ahoka 7 days ago | parent | prev | next [-] | | "Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem." We just had to workaround breaking changes in a patch version update of Spring Boot. Maybe it was true in 2005, but certainly not the case today. I know of products that are stuck in Java 1.8 and not because they are too lazy to upgrade. | | |
| ▲ | cess11 7 days ago | parent [-] | | I've been involved in bringing real old Java 1.4 and 6 and whatnot up to 17 and from classic app servers into cloud, can take a bit of work but it's pretty straightforward, mostly switching out deprecated methods to their successors and copying over boilerplate config from similar applications. | | |
| ▲ | mleo 7 days ago | parent [-] | | Depends on the frameworks in use. I have done the same as you in bringing code that was originally started on 1.4 up to 17 and now 21 and it just took grunt work, but not too crazy since most of it was bog standard Java. However, some other projects around here using different application frameworks are stuck since the frameworks aren’t maintained or upgraded in ways that aren’t compatible anymore. Looking into old Java code, it is hard to remember a time before enums and what a pain that is to deal with int constants instead of typed constants. |
|
| |
| ▲ | wink 7 days ago | parent | prev [-] | | I am not sure you should put ant or maven as shining examples here, but I am kinda warming up to Gradle, at least without Groovy being involved. | | |
| |
| ▲ | skeletal88 7 days ago | parent | prev | next [-] | | Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages.
Python has a very rich standard library. You can do a lot with libc, if you had a c++ Qt project then it would provide you with basically everything you could ever need. | | |
| ▲ | cies 7 days ago | parent | next [-] | | > Javascipt is a horrible language because it basically is missing a standard library so you need external dependancies even for the most basic things that are already present in other languages That's not the only reason. :) Horrible syntax full of inconsistencies, bolted on type system with TypeScript helps but will always be bolted on, quirks everywhere, as if `null` was not bad enough they also have `undefined`, I can go on. I simply avoid it for anything but small enhancements scripts on otherwise static HTML pages. | | |
| ▲ | leptons 6 days ago | parent [-] | | It's okay for you to have the opinions you do, but I have zero problems programming very complex systems with Javascript, even without Typescript (before Typescript ever existed). Javascript has always been the easiest language to build anything with for me. And yes, I know a dozen other languages including C, C++, C#, Python, Go, various flavors of Assembly, and more - but Javascript is still my favorite. YMMV. | | |
| ▲ | cies 6 days ago | parent [-] | | > It's okay for you to have the opinions you do Likewise. > I know [...] C, C++, C#, Python, Go, various flavors of Assembly That's good. But these are all languages that either lack strong typing and or are themselves rather quirky. Only C# and Go stand out, IMHO, as languages that are recently designed. Even Python did not have user defined classes in the first versions, and some things thus feel off (__len__, __init__, etc.). Also C# and Go still have implicit nulls all over the place. Their designs show ignorance for modern language design. Sum-types, explicit null, immutability, sound type systems -- all lacking in all langs you mention. So what languages do have these IMHO "Game changers"? OCaml/ReScript/ReasonML, Haskell, Elm, Rust, Gleam, F#, Scala, Kotlin, ... Those languages really showed _me_ something important: how it could be better. There is another group of languages that also sits on a unique place in the solution space: the LISPs (incl. Racket, Schemes and Clojure). I found it very worth while to learn to program with them as well. | | |
| ▲ | neonsunset 6 days ago | parent | next [-] | | In the last few years C# did away with implicit nulls. Nullable and non-nullable object references are disambiguated with T? and T. There are multiple keywords and expressions to further make it nice to work with these. You would be correct to note that there are "nullability holes" in certain edge-case scenarios, particularly around JSON serialization. But other than that it's a pretty smooth sailing. If you do use C#, you may also want to add <WarningsAsErrors>nullable</WarningsAsErrors> to .csproj too. | | |
| ▲ | cies 5 days ago | parent [-] | | I know it's a bit like Kotlin. I heard though that C#'s move still has some std lib bits that are nullable. | | |
| ▲ | neonsunset 5 days ago | parent [-] | | The idea is not to never have nulls. It is pointless (ha) - the way to understand T? vs T in C# is like an optional. The entirety of standard library is annotated since long time ago. All new and not so new projects are also null-aware. Pretty much either completely legacy libraries or libraries that explicitly removed Nullable: enable that is set by default for all new project templates do not have those. As I mentioned previously - it isn't perfect, but the level of "good enough" of NRTs in .NET is such that the nullability is a solved problem. |
|
| |
| ▲ | leptons 5 days ago | parent | prev [-] | | I prefer Assembly before any of the fringe languages you mentioned. There are no types in Assembly, and I rather like it that way. If you know how to work with data, then there's very little confusion about what you're doing. And there's a reason practically nobody uses the languages you mentioned, and Javascript is so wildly popular. Most people don't really like or need type nagging systems. Sure, if you're trying to launch a rocket or doing something like building medical equipment or something else that requires covering your ass, then yeah, sure, go ahead and type the hell out of it. But for most programming tasks the languages you mentioned are overkill and frankly too obscure to use. | | |
| ▲ | cies 5 days ago | parent | next [-] | | JS is popular due to it being the only browser lang. Did you forget that? Also: TS popularity shows that not everyone in the JS community agree with you. For server side web dev you will find that statically typed langs (Java, Kotlin, C#, Go) are a big chunk of the pie. Sure it also comes down to taste, but if you work in a large team, having stronger types can greatly help to keep the codebase in shape. (better IDE refactor tools, clearer for noob, harder to hide/ check in rubbish to git) If you are afraid by obscurity, have a look at Kotlin! | | |
| ▲ | leptons 5 days ago | parent [-] | | Typescript is still nowhere near as popular as Javascript, and likely never will be. It's overkill for the vast number of uses of Javascript. | | |
| ▲ | cies 5 days ago | parent [-] | | JS's uses have been growing steadily. The language was clearly not "designed" (I saw a talk about the first 10d of JS, little actual designing happened). TS is to the rescue when you have a big JS project, because that's what JS is not good at: big projects and large teams. | | |
| ▲ | leptons 4 days ago | parent | next [-] | | Except big JS projects with large teams existed well before Typescript ever did, and it never stopped anyone from producing good results. Typescript really isn't making anything possible that wasn't possible before Typescript existed. | |
| ▲ | phatskat 4 days ago | parent | prev [-] | | I’d love a link to this talk if you happen to have it handy! |
|
|
| |
| ▲ | throwaway14356 5 days ago | parent | prev [-] | | only one type :p |
|
|
|
| |
| ▲ | leptons 6 days ago | parent | prev [-] | | A standard library is not a "language" feature. |
| |
| ▲ | liontwist 7 days ago | parent | prev | next [-] | | I check out C projects which have not been updated in 15 years and run make. | | |
| ▲ | icedchai 6 days ago | parent [-] | | I have C code that I wrote in 1995 that still builds. There are many warnings, however. |
| |
| ▲ | elashri 7 days ago | parent | prev | next [-] | | You can't use 'pip install' in debian because they chose to do that during the transition from python2 to python3. You should use 'pip3 install' which is provided by package python3-pip from debian. One can argue that this decision should be revised by debian but you should not install packages on system python installation for working into projects. Always use virtual environment. | | |
| ▲ | Ameo 7 days ago | parent [-] | | No that does not work either. You get an error like this: » pip3 install supervisor
error: externally-managed-environment × This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install. As far as I can understand, they did this on purpose to dissuade users from installing packages globally to avoid conflicts with other Python environments. Anyway, I'm not trying to argue about if that decision is right or not - I just wanted to use it as an example for my case that the JS ecosystem isn't alone and may even be far from the worst when it comes to this kind of issue. | | |
| ▲ | elashri 7 days ago | parent | next [-] | | I understand that, you can use `--break-system-packages` or change configuration `python3 -m pip config set global.break-system-packages true`. Python is different here because in many linux distributions, there are many tools that rely on you system python. Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. So while I understand you are using this as an example, I don't feel that your comparison is apple to an apple. | | |
| ▲ | LamaOfRuin 7 days ago | parent [-] | | >Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. They may or may not be running Node.js specifically, but I believe that many Linux distributions, as well as Windows, include JavaScript code in core applications. I don't see this as particularly different, except that they might choose to assume a single standard system Python that is able to be modified by standard Python development, whereas I would rarely expect that to be the case with however each component chooses to execute JavaScript. | | |
| ▲ | elashri 7 days ago | parent [-] | | Apps that rely on OS provided Webview and electron apps are totally different situation. This is exactly what I said. And no, they don't use any standard nodejs installation like python. And they are different as I said. so this is still apples to orange comparison. | | |
| ▲ | LamaOfRuin 7 days ago | parent [-] | | >Apps that rely on OS provided Webview and electron apps are totally different situation. No, they're not. I'm talking about core apps and services that are essential to a functional operating system. This is exactly the same situation. The difference is choices made by the OS and language ecosystem about how to manage dependencies in various use-cases. It is an apples to oranges comparison because of those decisions and not because of the language. | | |
| ▲ | jcelerier 6 days ago | parent [-] | | Which apps would that be ? I'm pretty sure there's zero node server running on my desktops & laptops at the moment |
|
|
|
| |
| ▲ | regularfry 7 days ago | parent | prev | next [-] | | My slightly heretical opinion is that Debian would have been better off removing system pip entirely. The system python is for the system. | | |
| ▲ | j1elo 7 days ago | parent [-] | | My not so heretical opinion is that PIP should behave like NPM by default, and work under a local environment subdirectory, just like "npm install" already creates a "node_modules" directory where to put all files, without the user needing to specify how and where and which env tool to use. | | |
| ▲ | regularfry 7 days ago | parent | next [-] | | Ah, but that would require that the python interpreter look first in the local directory in case there's a virtualenv there, which would mean your system could break depending on which directory you ran bits of it from. Less than ideal. It's better all round to just assume that unless you're building something to be a part of the system itself, that the system interpreters just aren't for you. There's a special case for shells where they're actually UI, but I've seen so much effort wasted over the years trying to let system interpreters do double-duty as both system tools and development environments that I've come to the conclusion that it's simply not worth the hassle. | | |
| ▲ | j1elo 6 days ago | parent [-] | | That's the idea, yes. Do you have by any chance any experience with Node.js? Running a JS script is usually done in two steps: 1. npm install
2. node my_script.js
First one downloads and installs all dependencies listed in a package.json file into a node_modules local subdir. This is equivalent to creating a pip venv, activating the venv, and running pip install against a requirements.txt file.Second one runs the interpreter with the script file and against the locally downloaded dependencies. I.e. the local env dirs in Node.js are not a suggestion that you need to learn about, make choices, and actually use; they are just how the tool works by default, which makes the experience of using Node.js with NPM by far much better and less confusing than the default experience of using Python with PIP. | | |
| ▲ | regularfry 6 days ago | parent [-] | | I have years of painful experience with node.js, yes. The critical difference between node and python is that there are no system-provided scripts on my system which have `#!/usr/bin/node` as a first line. There are a load of scripts with `#!/usr/bin/python` (or similar) in `/bin`, which means package resolution can't look first in a local subdir otherwise all bets are off. Again: your system will break depending on which directory you run bits of it from. The system-provided process would be loading dependencies that it was not tested against. In case this is unclear, you do not want that to happen. It would be bad. On my system I can see python scripts involved in driver management. I do not want them to do unexpected things. It would be bad. Python package management is a mess in lots of ways, but this particular choice isn't one of them. | | |
| ▲ | fragmede 6 days ago | parent [-] | | > which means package resolution can't look first in a local subdir Sure it can, it's just a matter of examining where it's being run from. I wrote python-wool to load packages from a venv if it finds one. https://github.com/fragmede/python-wool | | |
| ▲ | regularfry 6 days ago | parent [-] | | Yep. That comes under the category of "not default". Although now you've pointed it out I'll probably be using it. |
|
|
|
| |
| ▲ | secondcoming 7 days ago | parent | prev [-] | | Python is a scripting language. I shouldn’t need to faff about with environments if I want to run my script on another machine. |
|
| |
| ▲ | secondcoming 7 days ago | parent | prev [-] | | Encountered this too. So annoying. |
|
| |
| ▲ | d3VwsX 6 days ago | parent | prev | next [-] | | I don't know if any API does this, but I often wished that APIs I used could mark up just a tiny, tiny subset as @FutureSafe, like the opposite of tagging deprecated code, so that for smaller projects you could stick to only or mostly those parts and know that you can come back after 2 years or 20 years and things still work. Maybe throw in a compiler flag to verify that nothing not-@FutureSafe is used by accident. Sometimes you just want to write something small, once, and not have to actively maintain it forever. Outside of shell-scripts or retro-platform code you can barely write Hello World for any target today and feel confident that it will still run six months from now. | |
| ▲ | ramon156 7 days ago | parent | prev [-] | | Libraries in the project fixes this whole issue for C/C++. As for compiler issues, just run it with the same compiler. It really shouldn't take more than 20 mins of setup. | | |
| ▲ | lmm 7 days ago | parent [-] | | > Libraries in the project fixes this whole issue for C/C++. Yeah, make sure no-one can ever fix your security vulnerabilities. > As for compiler issues, just run it with the same compiler. And when the same compiler doesn't exist for your new machine? Freezing everything makes things easier in the short term, but much harder in the long term. |
|
|
