SoylentNews is people
SoylentNews
Arthur T Knackerbracket has found the following story:
We are volunteers who make and take care of the Python programming language. We have decided that January 1, 2020, will be the day that we sunset Python 2. That means that we will not improve it anymore after that day, even if someone finds a security problem in it. You should upgrade to Python 3 as soon as you can.
We need to sunset Python 2 so we can help Python users.
We released Python 2.0 in 2000. We realized a few years later that we needed to make big changes to improve Python. So in 2006, we started Python 3.0. Many people did not upgrade, and we did not want to hurt them. So, for many years, we have kept improving and publishing both Python 2 and Python 3.
But this makes it hard to improve Python. There are improvements Python 2 can't handle. And we have less time to work on making Python 3 better and faster.
And if many people keep using Python 2, then that makes it hard for the volunteers who use Python to make software. They can't use the good new things in Python 3 to improve the tools they make.
We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020.
If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. You will lose chances to use good tools because they will only run on Python 3, and you will slow down people who depend on you and work with you.
(Score: 2) by DannyB on Tuesday September 10 2019, @07:39PM (5 children)
Not quite sure what you're saying. Java grammar has been pretty stable. Few additions over time. In fact the most new language features seem to begin at Java 8 and beyond. I think of libraries as JARs -- binaries. They continue to work even with newer compilers used to compile code calling old libraries.
I'm not sure what you mean. With C I can include a header, and at runtime be linked with a binary -- possibly written in a different language. With Java, I can include a class or classes, and at runtime be dynamically linked with those classes on the classpath -- possibly written in a different language.
I don't understand what you're getting at. There have been a few new languages, over time. Groovy. Scala. Clojure. Kotlin, come to mind. I know there have been a few others. Other than that these run on the JVM, I'm not sure why you blame Java. I could blame C that there are new languages that compile to code that can be called from C and vice versa. If you don't like a new language, don't use it.
This might be before I got into Java. I would appreciate an example.
I think for a very long time it was only AWT or Swing. A few years back Java FX was introduced, and then significantly improved. I could argue with C, should I use GTK, QT, wxWidgets, etc. I don't blame C that there are multiple GUI frameworks to choose from. In fact, I would consider that choice to be an advantage, as they probably offer various pros and cons. I have occasionally even seen projects that let you use QT or something from the C/C++ world in Java. I wouldn't blame any language for this -- even if I thought that was a bad thing that deserved some kind of blame.
I would really be interested in an example of what you mean. The biggest change I can think of in Java, before Java 8 / 9, was the introduction of Generics, which was completely backward and forward compatible at the source and binary level.
That has been going on in every area of the industry since at least the 1980's. There have constantly been new languages, compilers, libraries, frameworks, tools, IDEs, etc. It never has and never will stop. In the last decade, JavaScript has been especially bad for new web framework of the week -- on the front end. Java has had a number of server backend frameworks over time, but not so many as JavaScript. But again, I see this as a feature rather than a problem.
I can clearly see that you hate Java. And that's fine. Don't use it. It hasn't been the top or in the top few languages for years now for no reason.
I came from a Pascal background in the 80's. In the mid 90's I tried C and C++ quite seriously. (not just dabbling) For example, I wrote a BASIC interpreter just for fun that ran in the GUI. (Using Metrowerks CodeWarrior on both Classic Mac and Windows 95/98 ish) I wrote a tool to convert an old proprietary database format into DBF usable by dBase / FoxPro / etc. (Back in the early 1980's, in Pascal, on microcomputers, there weren't off the shelf databases we needed -- so we had to write our own, and it was uphill both ways!) My point is I didn't just dabble a little bit with C and C++. But I didn't consider them the future for our next generation of GUI software, and later Web software. And the rest of the industry seemed to agree. IMO, C, and also C++ are just too low level for application programming. Great for boot loaders, OSes, microcontrollers. But you shouldn't be writing applications in C.
A language is too low level when it forces you to think about things that are irrelevant to your problem.
The people who rely on government handouts and refuse to work should be kicked out of congress.
(Score: 2) by FatPhil on Tuesday September 10 2019, @11:20PM (1 child)
So one that makes you wonder whether the answer you want is 42 or Integer.valueOf(42) would be too low level.
Which reminds me of the "fix" that was the cache of Integers, that's just freaking hilarious; more language decisions like that please, they're laughs for the ages!
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by DannyB on Wednesday September 11 2019, @03:59PM
I never seem to have problems with boxed vs unboxed integers or other primitive types. I suppose back in the 90's the decision could have been made that all primitive types must always be an object in the heap. Every boolean, byte, characters, integer, etc. But I suppose nobody would have liked that.
Many languages make practical design decisions for efficiency.
The cache of integers is something that happens, again for efficiency, in the runtime engine, invisible to the programmer. That's a runtime efficiency implementation decision, not a language decision.
That would be like blaming C language for some highly optimized malloc library implementation that someone might find amusing for some reason -- despite its efficiency gains.
The people who rely on government handouts and refuse to work should be kicked out of congress.
(Score: 2) by ilsa on Wednesday September 11 2019, @08:07PM (2 children)
I got introduced to Java when it was still 1.0, and was doing more than just dabbling, at the 1.2 mark. Most of the issue's I'm talking about are pre-1.6. Another Java version, another major toolkit change and you were more or less expected to just... stop using the old versions. AWT vs Swing (and then JavaFX) thing was one of the most egregious examples. But more fundamental libraries had the same treatment. Luckily the more fundamental libraries stabilized pretty quickly because Sun was starting to seriously piss people off.
And while you're right that C/C++ also had a very diverse ecosystem, the difference is that all these Java packages were sanctioned by Sun. These were official libraries distributed by Sun/Oracle. In a matter of years, Java wasn't just Java anymore. It was now a massive ecosystem of conflicting libraries. It looked like Sun really had no vision, no idea what they were doing, so they were just going to shotgun every conceivable technology/paradigm/whatever and let God sort it all out. And I'm specifically speaking about just what Sun was providing. I am not even considering 3rd party libraries. It was total confusion and a lot of people got turned off from Java by the sheer immensity of it all. It became hard to tell what you *should* be using. They single-handedly proved the XKCD comic about standards.
C, by comparison, does have a massive ecosystem of libraries and whatnot. However most of those libraries were 3rd party. You want to use Boost? Sure no problem! But there is no question that Boost is an external library. Different vendors put out all sorts of different "standard" libraries, but that was typical vendor nonsense where they are trying to lock you into their platform. Borland, Microsoft, etc. They were all pulling these shenanigans, but at no point did anyone ever stand up and say that one of their versions was the "true" C. Of course, that's a mess until itself, but not one you can blame the language for.
Unfortunately at this point it's been years since I've seriously touched Java, so I'm having to work from now degraded memories. I haven't really touched Java as a language since 1.6, so I don't know how things have been going apart from news releases which inevitably talk about people's complaints about Java "not moving fast enough", etc. All that talk just makes me think that Java is again entering those bad old days where stuff will get introduced and deprecated ad nauseum, and I've basically tuned out completely now.
WRT Javascript, we'll have to agree to disagree because I cannot possibly fathom how you could see the sheer instability of that ecosystem as a good thing. The single biggest cost to all this churn is the complete lack of stability. That lack of stability also means a complete lack of security. But this doesn't affect the developer. The developer just cranks out code, and then drops the final product somewhere like a dog drops it's poop in the middle of the park, so someone else has to clean it up. And who are the ones that suffer? The poor suckers that bought the software that now have to spend even more money not just replacing the software but migrating their old data. Now take Javascript and it's "new framework a week" mentality... the tech stack will be not just outdated, but obsoleted, before the project is even finished. We are amassing technical debt at a rate so staggering, that keeping up is impossible. So we end up with software that gets written once, and is almost completely unmaintainable a week later because everyone has moved onto the new shiny and there's few people around familiar with the old tech. It's like the Y2K nightmare but at light speed.
I'm kinda rushing through this, but your final point is regarding C being too low level for things like GUI apps. I would say I sort of agree. Dealing with GUIs, especially in Windows, is SUCH a hassle. Microsoft has done a fantastic job of putting the AWT/Swing issue to shame with their 5 bajillion different libraries and paradigms and solutions. But at the same time, the argument is a cop out to allow for crap code. Languages that divorce people from the hardware allow for worse-than-failure levels of poor code quality and performance. But it compiles so who cares? The user can just buy more ram and storage, right? Look at Facebook for example. The last time I had their apps installed on my phone, they took up a solid GIGABYTE. For a freaking website portal and a messaging app. At that time, the entire microsoft office suite took up less space. When my phone "only" had 16GB of storage, that was devastating. As a user I shouldn't need to choose between dedicating a phone to just using facebook vs everything else. And people look to Facebook as a major player in the tech industry. It's depressing.
Personally, I have my eyes on Rust. It's been relatively stable and they are trying very hard to keep it that way (apparently v2018 introduced some backward compatibility breaking changes but based on their history that's an anomaly). Of all the languages I've seen lately, Rust is the first systems level language I've seen that is less risky than C(.*) while having strong interoperability with the C ecosystem. The single biggest advantage of Rust is that the model the language enforces, puts a very high barrier on software quality, so even if we do hit library proliferation like we see with Javascript, even abandoned libraries will be of a much high quality in all ways and won't be nearly as debt-ridden as what we see with current stuff. The one missing piece is decent GUI support. If they can crack that nut, then I see Rust exploding to the top of the charts.
(Score: 2) by DannyB on Wednesday September 11 2019, @08:17PM (1 child)
That is interesting. Thanks.
It sounds like you and I have experienced different "halfs" of the Java history. I got started at about 1.5 just as 1.6 was coming in.
As for JavaScript, my biggest gripe is not about the frameworks. But the language itself. I wish it had a lot more formal and less slapdash attention paid to it in its early days. JavaScript, as a language, has been massively improving in the last few years. But when I read of each great improvement, it is years before I can safely assume I can use those improvements, when they are commonly deployed in everyone's browser. And I know about polyfills.
I don't mind the number of frameworks in JavaScript -- because nobody is holding a gun to my head to force me to use any of them.
While I don't use C nor Rust, I also have the opinion that Rust is probably better for what C is mostly used for. I'm not criticizing anyone for using C just because I think it is wholly inappropriate for the problem domain I work in. Java seems to fit the bill rather nicely. And almost the very first thing I said is that Java does have some warts. It is not without its criticisms.
The people who rely on government handouts and refuse to work should be kicked out of congress.
(Score: 2) by ilsa on Wednesday September 11 2019, @08:38PM
Ugh... Don't get me started on the javascript language itself. It was originally designed to be a slapped together language to do very basic dom manipulation, and everything done to improve the language will never be able to fix some of the outrageous flaws introduced at it's very inception. If you haven't seen it already, I recommend watching this: https://archive.org/details/wat_destroyallsoftware [archive.org]
Javascript is the only language I am aware of, that have had other languages (typescript) written in order to remediate the most offending aspects.
I'm really hoping that WebAssembly hurries up and becomes popular. I believe most languages already have wasm compilers written (I know Rust does for sure...), and the sooner we kick Javascript out the door the happier I'll be.
I strongly recommend, if not actually trying rust, at least do some reading about it. It has the most unique and fascinating memory model I've ever seen (which is what gives it such robustness), and is a great thought exercise in how one designs their code. I haven't actually done anything with it yet (I'm primarily an IT Manager and Sysadmin, so there's not much call for heavy coding there...), but Rust is the first language I've seen in a while that really makes my coding fingers itch to start making something.