Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Wednesday March 11 2020, @10:00PM   Printer-friendly
from the what-do-YOU-think dept.

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?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by bussdriver on Friday March 13 2020, @06:28AM (1 child)

    by bussdriver (6876) on Friday March 13 2020, @06:28AM (#970574)

    Objective-C is open source but it's rarely used and that is the problem. It is nearly as old as C++ but it made many better design decisions than C++. I have done both and clearly Objective-C is better than C++. Now days you can mix the two languages and use the best of both worlds which is cool stuff.

    I wish Objective-C took off instead of C++ but ultimately it's the people controlling the language that decide it's long term success. Adding flexible OOP to C without obsessing over speed was the way to go but over application of OOP to everything was the fad so crazy measures to keep speed seemed more important than it was. You could get that extra speed when you needed by just using C.

    Apple seems to be the primary driver and they are migrating away. It's a shame because if a C guru and OOP guru came up with a solution it would be a lot like Objective-C and not C++. Not that some C++ concepts weren't great help to compiler it had many great ideas.

    CoffeeScript was clever; relates to Objective-C. I'd think it should be doing better since it's use case is a popular one today and it's mature and well designed for the niche some people want to go into with other fad tools right now.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by JoeMerchant on Friday March 13 2020, @01:03PM

    by JoeMerchant (3937) on Friday March 13 2020, @01:03PM (#970672)

    I'm not knocking the academic/technical/aesthetic merits of Objective-C, just its real world applicability. Betamax was clearly better than VHS, BluRay is better than DVD, but what's it worth if the content in the format is lacking, or difficult to access? Like in spoken languages, Esperanto may have all kinds of academic/technical/aesthetic merits over whatever other languages you care to compare it with, but how useful is it anywhere other than at a special gathering of Esperanto speakers, and how useful are such gatherings? Lack of APIs, lack of code base, lack of "speakers" or available developer experience, even lack of stack overflow and similar problem solving resources on Google are much more important than any particular merits/demerits of a language. If you have a "need for speed" there are almost always ways to get that in any language - though for scripting languages like Python the way to get that speed is to leave the language altogether and build your speed critical modules in something else, like C/C++, so I have a hard time getting on board with the "Python is great" crowd when such a critical part of the language is learning how to stitch together disparate libraries (often built in languages you don't understand) with the inevitable bag of snakes that is configuration management of the complete product.

    In 1996 we converted an application that we had been developing (more like organically growing) since 1990 in C. The core of the application was a set of data processing blocks (filters, feature extractors, etc.) that layered on top of one another, generally about 6 layers deep from the source data to what was presented to the user as graphs. The C++ translation did indeed fully embrace object oriented design, and the running speed hit was about 50% vs. the C implementation. However, this was ~1996 - it took about a year to port 90% of the old app from C to C++, and during that year new PCs gained as least 2x speed per dollar performance, so the "new stuff" really didn't run slower than the "old stuff" in absolute terms. The thing of value that did accelerate greatly was speed of development. With the object oriented design, a new idea could be translated into running code about 4x faster than the C version, on average. This may have been more attributable to the fact that the C++ app was "architected" with 6 years of experience whereas the C app grew organically, like a coral reef, as each new idea layered on top of the existing code which started growing from a tiny seed that had no idea what it would become. The real motivation for using C++ wasn't the app's core "value add" unique IP, the real motivation was that the Windowing UI API was all written in C++. To do that exercise all over again (and waste yet another man year on re-development) we _might_ have gained back the 50% speed lost during the migration to C++ by keeping our compute core in straight C, or... it's possible that it was just the early C++ compilers that didn't optimize as well as the more mature C compilers. Back when we started the C++ compilers were straight up too buggy to use, which is what drove us to implement in C in the first place.

    --
    Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end