SoylentNews is people
SoylentNews
Ilya Dudkin at Skywell Software has a story
Top 7 Dying Programming Languages to Avoid Studying in 2019 –2020.
Each language gets a paragraph's treatment as to why he thinks these languages are dead or dying. Those languages are:
- Visual Basic
- Objective-C
- Perl
- COBOL
- CoffeeScript
- Scala
- Lisp
Do you agree with his assessment? Are there any other language(s) you would add to the list?
This discussion has been archived.
No new comments can be posted.
Top 7 Dying Programming Languages to Avoid Studying in 2019 –2020
|
Log In/Create an Account
| Top
| 195 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Love is the delusion that one woman differs from another.
-- H. L. Mencken
(Score: 4, Informative) by TheRaven on Thursday March 12 2020, @03:26PM (1 child)
I am the author / maintainer of the GNUstep Objective-C runtime (used in a bunch of Android apps, in WinObjC, and a few other places, including some quite surprising ones - including some widely deployed SS7 routing stuff). I also maintain Objective-C support for non-Apple platforms, and have written a couple of books about the language, so I'll have a go at this one:
Objective-C is a great language for mid-90s computers. It provides late-binding and makes it easy to create stable ABIs for libraries. The original goal of Objective-C was as a language for packaging C libraries for use by high-level languages. It's still pretty good at that. The rich reflection means that it's trivial to write generic Objective-C bridges for scripting languages. It was a compromise between Smalltalk and C. C-level performance where you need it, but Smalltalk levels of abstraction (and, sadly, performance) for high-level abstractions.
Objective-C++ improved this a little bit by filling in the gap. C arrays are fast, Objective-C arrays are very slow but safe, std::vector can be safe and fast. With ARC, you can store Objective-C objects in C++ containers without having to think about memory management. For single-threaded programs, it's a pretty nice world.
Objective-C is not a great language for the 2020s. ARC is not memory safe in the presence of concurrent mutation. As with std::shared_ptr, it is safe to concurrently update the refcounts to the same object, but not safe to update the same pointer from two threads (e.g. a global or a field in an object reachable from two threads). It doesn't have a concept of deep immutability, so there's no good way of creating a data structure that you can statically guarantee is safe to share between threads. It doesn't have a concept of move semantics or linear types, so there's no good way of guaranteeing that mutable data is passed (not shared) between threads. It has a single global namespace for the entire program, so there is no way of building programs in it that have any notion of sandboxing other than as two separate processes that communicate via mechanisms that are opaque tot the compiler. It does not guarantee memory safety, which means that it can't benefit from a load of the optimisations available to higher-level languages, but also can't benefit from a load of the optimisations available to lower-level languages.
The problem with the Apple ecosystem is that Swift inherits all of these limitations and brings nothing new other than different syntax. It does not address any of the fundamental limitations of Objective-C and inherits a PDP-11-like abstract machine, in a world where modern computers look nothing like PDP-11s.
sudo mod me up
(Score: 2) by bussdriver on Friday March 13 2020, @06:46AM
Objective-C needed a team evolving it over time like C++ and others. COBAL doesn't look like it did MANY decades ago even it evolved a bit. Objective-C should be more like C++ with changes to fit today's needs. Even if some breakage happens. A read a history book on the development of C++ and didn't agree with many design choices that seemed to be where Objective-C went the other direction.
Swift I don't know other than I heard it was an evolution of Objective-C with a bunch of syntax games that were not likely needed. It seemed to me from a glance they were trying to get some kind of hybrid between compiled and scripted languages. A worthy goal to attempt as we do so much more in scripting languages today; it sure would be nice if scripting could compile into something much faster while still being easy to develop quickly. I won't look into Swift until it's more free from Apple's grip.
Objective-C, I dabbled in and loved it but the lack of backers outside of Apple discouraged me from investing more effort. Had I known 20 years ago about GNUstep I might have gone into it much more.