[1]blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ [2]https://stackoverflow.com/q/2708033/2577465
a. Object oriented code done right is the best way to handle production code.
b. Java has introduced streams, lambdas etc.. has any other language shown this type of adaptation to times ?
c. Python, Ruby etc.. don't have equivalent performance
d. c++ obviously beats it on performance but I know the pain of porting c++ code
e. Most of the boilerplate code is either auto-generated or you can use Lombok type framework to generate them for you
f. Java made a really good comeback with Android
So the new kids in the block might not like Java because it isn't cool but Java has stood the test of time.
C#
"Adaption to times"? Lambdas are older than Java itself. It was outdated in v1.
I think OPs point was that the language has evolved more dramatically than other popularly adopted languages.
Of course it’s not popular for hobby projects, startups, academia or data science, but those fields are frankly dwarfed by enterprise on the job market.
C# has a stronger hold in the private sector, but scince most of the public software is produced by the private sector even there JAVA runs strong.
For people out there that look at all those getters and setters with contempt: you don't need them for your JSON objects. Just use public. The frameworks will still serialize and deserialize without issue. Use JSON annotations to define what a valid message is. Yes, you'll need a mapping layer between your JSON/inbound messages and your domain, but you need that anyway, otherwise your API is brittle.
JPA + Spring can lead to fast DB code and development time that rivals NoSQL with Postgres. You can have it autogenerate the DB during dev time with each boot, then create Liquibase migration documents for true devops stability.
After working with Go for a month, I really think Java just does things right. Servlet API is simple. Spring makes it easier. Transactional management + AOP is wonderful. So many cross-cutting concerns allow you to properly encapsulate and apply the logic in a few AOP. You just can't do that with GO without a lot of compiler work.
Autoconfiguration in particular seems nice at first but can cause all sorts of weird issues. I once had a situation where we added RabbitMQ, and some other JAR started trying to bind to a queue that didn't exist, but the framework was swallowing that exception and it took hours of screwing around in the debugger to figure out what was going on. That sort of thing simply doesn't happen with Go in my experience. Or probably Dropwizard, honestly.
As someone who has done a lot of Scala and Kotlin, I appreciate Java because I can anticipate the bytecode that will be generated. This is important to me on low-level JVM projects (profilers, fuzzers, etc).
Well, Lisp added CLOS, which was a huge adaptation to the rise of OOP. It also originated lambdas. I don't know if streams originated in Lisp, or if they were an adaptation from another language.
> Most of the boilerplate code is either auto-generated or you can use Lombok type framework to generate them for you
That's why I prefer a homoïconic language: I can write & generate the boilerplate in the language itself.
> Java made a really good comeback with Android
I don't know if that's true so much as there really aren't good options to Java on Android. I'd give my eye teeth for a good Go GUI SDK for Android, for example.
All the things you mention about Java were done in C# and much more elegantly.
Where Java shines is not the language but the runtime behind it.
> Object oriented code done right
Pick one.
But in all seriousness, Java is definitely underrated amongst many who are working with the trendier technologies. It's not perfect, but it gets the job done, and it's a solid platform with phenomenal tooling.
I don't think "Python, Ruby etc. don't have equivalent performance" is actually very important though. In practice, the availability of developers in a particular market, legacy code, and static typing & refactoring tools probably have much more to do with Java's success than performance.
* Instant recompilation
* One string type
* One error handling system
* Capitalized identifier = class name = file name = imported name
* English names for everything and no operator overloading
All these are ignored by e.g. Haskell or Rust.
You mean like, AbstractSingletonProxyFactoryBean? Sure, it's English, but when you end up with a project with that many layers of needless abstraction, it's not going to be easily and quickly comprehensible by anyone who isn't already familiar with it.
I think factories and beans are a sign that object construction in Java is a mess. In the applications I work with, most calls to "new" are dealing with data structures (lists, maps, protocol buffers), and behavior-heavy business objects are a mostly static call graph. Not sure if there's a name for this pattern though.
Foo foo = new Foo();
The Golang FAQ calls that stuttering; good term, I thought.
See section:
What are the guiding principles in the design?
"Stuttering (foo.Foo* myFoo = new(foo.Foo)) is reduced by simple type derivation using the := declare-and-initialize construct."
Foo::Bar *Foo::foobar = new Foo::Bar(Foo::Bar::FOOBARENUMVALUE);
* It is functional and succinct by default, but allows you to go mutable and fast when needed (see the alioth benchmarks).
* Open source culture
* The tooling (thanks to kcieslak and others) is fantastic
* Web story is covered well by suave/giraffe on the backend, with fable-elmish as a personal favorite if I need complex front-end functionality (most stuff I have is just regular pages though).
* Mobile story through Xamarin(Forms is not my favorite, but Native works fine) or Fable
* To mention javascript again, I think Fable has a ton of well thought out features compared to other transpiled languages
* Testing via expecto (and just github.com/haf in general)
* A whole wealth of libraries through .net integration
* I can compile a binary to execute on linux for easy deployments, or target osx to create convenience command line applications for my coworkers
There are some negatives (some C# interop gets inelegant, some tooling is left to the community as a responsibility, other minor things), but overall it has all of the important things.
I'm someone who thinks there is room for lots of good languages, and each has its role, so I don't think languages should be pitted against one another necessarily.
However, with Nim you have something very similar to Python in its expressivity, but with performance comparable to things like Rust and C++. The metaprogramming is very well done as far as I've seen, and it seems very well thought out. It also has solid, useful compilation targets.
It just seems like the whole package for a lot of use cases and I'm not sure why it's not getting a lot more attention.
I still wish the coffeescript model had worked out where we could view or think about languages differently and compile them to a common one. But unfortunately it doesn’t work without a great deal of effort.
Could you expand on that? I always thought the core nim language was fine. But, I've also come to the conclusion that the few libraries I've used that were written in nim are of poor quality. Is that a function of the language? The community? Or both? I have no idea.
Taste is subjective ...
De gustibus non est disputandum:
https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandu...
... so it is almost as though by default, you have to explain/justify your opinion on this :)
Nim is underrated indeed.
It really is a great successor to C++, with lots of new ideas taken from other languages too, and some very insightful language designers. I wish people would give it more of a chance and not stop at "it has a GC" and decide that this makes the whole language worthless.
It's been around for a while but hasn't gotten popular yet. I don't know if the weird license for the reference compiler is what slowed down adoption. At least for me, that's why I was hesitant to commit to D. After the license change, I've had so much fun with it.
Seriously! I've never seen anyone complain that e.g. Go has a garbage collector, and Go's is not even optional. The only thing Go has over D is a large corporate sponsor.
- predictable release process
- predictable language development
- predictable changes between versions
- clear direction
- no competing and non-interoperable standard libraries
- a backwards incompatible version 2 does not come out 6 months after version 1.0 deprecating it.
Oh. Wait. That wasn't just an "only" thing.
Special runner-up: MOOcode, the native language of LambdaMOO. Still one of the most coherent and pleasant object-oriented languages I've used. It's especially notable for its "code runs as author not invoker" protection model and call-stack introspection. People could learn a lot from that.
My first thought was Nim, and o2348diuu already explained why. Second thought was Lua, but a couple of people beat me to that. Haskell and Elixir are definitely not underrated. They're underused, certainly, but that's not the same thing and IMO Haskell is often overrated.
SQL seems to power nearly everything at some level, has much code written in other languages for the sole purpose of interfacing with it (for better or worse), has inspired other concepts and technologies (even as they are defined against it as what they are not), etc.
I don't think anybody mentioned C yet either, another foundational case…
Nobody needs to mention C because it is definitely not underrated - it's earned its reputation and is respected/feared by developers everywhere!
Compared to SQL, Datalog makes recursive queries very natural[1], making it good for manipulating graph-like structures. For example, here's reachability in a graph:
reaches(X,Y) :- edge(X,Y).
reaches(X,Z) :- edge(X,Y), reaches(Y,Z).
Variants of Datalog pop up in unexpected places. Datalog dialects are often used for implementing code analysers (e.g. Semmle). Datomic's product is a variety of Datalog with S-expression syntax. UC Berkeley has a Datalog-based research language called bloom (http://bloom-lang.net/faq/) aimed at implemented distributed systems. Datalog was also an influence on the recently-shuttered Eve (http://witheve.com/) project.
In its original form Datalog lacks aggregations, which is probably a big part of why it didn't catch on - aggregations are important! Still, some Datalog implementations add support for aggregations. Unlike SQL, Datalog never really became a standard; more an academic ideal than a practical tool. I think this is a shame.
While Datalog doesn't have a canonical practical implementation, in terms of impact on how people think about data query languages, I think it's an academic gem.
[1] SQL has recursive queries ("Recursive CTEs"), but they're neither widely used nor particularly well-supported in most SQL implementations - they're basically tacked on. This is partly because they're hard to optimize due to a lack of restrictions; with Recursive CTEs, SQL is Turing-complete. Datalog deliberately isn't, and there's a large literature on optimizing evaluation of recursive Datalog.
Many, many production applications have been written using these languages/environments, but the language has fallen out of favor since the early 2000s.
- Code is easy to read and understand, and you can get a new developer up to speed quickly
- Can be used as a high-level language, a low-level language (you can even include in-line assembler), or both
- Blazing fast compilation
- Statically-typed, and includes classes, records (structs), reference-counted interfaces and strings
- Lots of implementations and platforms
If you're looking to do web development (browser) with Object Pascal, then here's a shameless plug for our product, Elevate Web Builder:
It was a great language, the first real one I learned.
This separation between data and code also enabled trivial scaling for huge system, as well as the opposite - hundreds of apps, each belonging to a different customer could share the same system - decades before docker or k8 was born.
This language was written when Objects were the only thing people talked about. In a counter-cultural move, the language's author wrote the entire standard library as only functions. The language could be easily learned - just look at the list of functions for the one that does what you want.
It's cross platform - the user interfaces you build work on all platforms with a single codebase.
Its combination of scaling, quick development iterations, and ease of use powered the rise of fourth largest tech company in the world today. In fact, just a single app written in this language has more than a billion people using it every day.
Darkly, however, the name of this language may not be spoken here. Even by praising it obliquely, I risk censure, and my perceived value of my work being cut by eighty percent in penalty.
I will not name it.
Functional. Cross-platform (it has it's own vm, of course), instant deployment and hot rollback (via a/b images), etc.
Your puzzle-as-description was very cleverly written and an enjoyable exercise! Bravo!
(Though I have used this language's hot reloading features to win a faux stock market trading war, by being able to swap in newly written market making strategies on the fly)
Here’s a hint - its been around since before flip phones, and has been a top ten language on stack overflow since the site was started.
JavaScript SQL Java C# Python PHP C++ C TypeScript Ruby
The data reload in place has thrown me. I am not sure any of the above do this. Maybe I am wrong though.
My guess would be PHP although there's a reasonable argument that most of the Fortune 500 runs on VB.
Unless the definition of instantly has changed since I kicked the compile off.
The instant reload and not losing your place is because changes to the server do not affect what's in the browser.
Customers sharing a system works because you can just have directories of PHP files.
PHP was developed without any kind of object system.
PHP is completely cross-platform because the UI is in the browser.
PHP powered Facebook.
PHP has a very poor reputation here.
PHP is in the top 10 tags on StackOverflow.
In my crotchety, old man opinion, people have been trying very hard to make PHP like a blub, overly verbose language, and trying to hide the things that made it great.
Nitpick:
That's a HTTP 'REST' feature, surely?
The feature then is that PHP doesn't chuck out your sessions because the code has changed. But then other platforms can do this.
-> separation between data and code
-> trivial scaling for huge system
-> hundreds of apps, each belonging to a different customer could share the same system
-> decades before docker
-> standard library as only functions.
-> It's cross platform - the user interfaces you build work on all platforms with a single codebase.
-> this language has more than a billion people using it every day.
-> the name of this language may not be spoken here
can only be PHP
I know sometimes it gets some hype but Haskell and its ilk is just so above the quality of any other language it's mind bending. Whenever a hard language design problem comes up in any new language, Haskell has solved it more than 2 decades ago.
The ecosystem (Hackage etc) is pretty bad though.
The language might be elegant at the core, but it's too far removed from reality (efficiency on real computers is super hard to control from Haskell) and it's far too focused on types (which, while they catch some errors, slow development down, and encourage unnecessary complexity ("easier" and "more type-safe")). After all, it's an academic language.
Current debuggers are built around very imperative notion of program state. I have breakpoints, I can look at variables (state in a given time)..
What would debugging look like if we looked at it from the functional perspective?
For example, execution "filters" instead of breakpoints. What happens if this function receives value that satisfies certain condition? Instead of variable watches, give out a breakdown of the data passed in and out from the function. Etc.
It's understandable to show skepticism about "the new shiny thing" (although Haskell is > 30 years old) because most new shiny things turn out to be not that great after all. I've been struggling to communicate the "no, but really" distinction without much success to other people and it's frustrating.
(...for purely egoistical reasons though, I don't really care what people are using as long as I get to use a sane language in my day job, which is currently not the case.)
If you think this is smugness, look into it. The features that come up with GHC extensions have no equivalent in other languages, because the commonly used stuff in Haskell so far ahead.
I think this has more to do with lack of polished UI editors (build tools) than with the language.
One could easily say that Qt was pleasurable because it was a well designed object-oriented and inheritance based toolkit. I have my reasons to believe this is objectively better within the context of UI design, and that pure functional programming in GUI design will never break out of it's magnificently tiny niche, but I'm not gonna go into that here. I'd rather just point out that some shared theoretical idea behind both Qt and Haskell UI design doesn't in any way imply that Qt's success could be Haskell's as well. Only Haskell programmers, working in Haskell code, could prove that idea. And if it really is that great, then surely they could do it.
* Essentially a Lisp. Data and program can be freely interchanged and is frequently done in completely normal code.
* The most impressive "standard" "library" in existence: everything from symbolic calculus, machine learning, UI building, graphics, signal processing, data import and export, foreign function interfaces and it just goes on and on.
* Incredible attention to consistency and interoperability. Everything behaves in predictable and orthogonal fashions. Right from the low-level pattern matching up to interacting with the build in database.
* The best documentation of any programming language. Nothing compares even slightly in breath, friendliness, consistency.
It's far from the most sane language I've ever used, and as much as I love it, I'll admit there are parts of the syntax that straight up hurt my soul. Yet, despite all the drawbacks, if I need to write something fast, PHP and a micro-framework (I like Slim) is always my first choice.
PHP let's you be what you want to be. If you are an architect with years of experience building a suite of microservices where you would want to use lot of bells and whistles, testing, dependency management, etc. do it. If you are a novice programmer looking to create your wedding website and have a simple contact form, do that as well!
Best part, each request is a clean start and independent.
Another one is Nim, with great potential, but still some rough edges here and there.
Last but not least: Red. If this language gains momentum, it will change the game forever. The current implementation take the concept of cross-compilation to a new level (although the current lack of View on Linux is somehow disappointing.)
Perl is happily unoptimized for anything, and is usable for nearly everything. It's easy to write and easy to make it hard to read.
You can write Lisp in Perl, and some people insist on it.
The CPAN repository has a module for nearly everything, and an amazingly high percentage are well documented.
There are some weirdos who love Perl.
No other language has done more to carry the Lisp legacy forward than Perl.
And you shouldn't use unintelligible, clever tricks in C, at all. They are very easy to avoid (although I agree that even K&R had some of those in it).
Related:
http://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Favo...
He was stuck in the structural programming world and never ever got out of it. Besides, there's no single ultimate Wirth programming language. All of them are re-hashes of each other with random additions thrown in (Modula, Pascal, Oberon, Active Oberon, Modula 2, you name it).
They are small fast programming languages. And that's about it.
Or more charitably viewed, successive refinements consisting of collections of proven ideas, with the ideas that didn't pan out in earlier iterations left out, yielding a body of languages that have had wide influence.
But I’ve also wondered why D is not more widely used as it is a much nicer version of C++ and integrates fairly well with it.
Also a bit odd that OCaml and SML isn’t more widely used
Generally speaking applicatio startup time in Julia is poor (maybe because of the number of symbols in Base?), I only recommend using it for its original purpose - mathematical computation - which, by the way, it's insanely good at and an absolute joy to code in.
Edit: Specifically, Perl 5 + CPAN is what makes it so much better than many people think. The language itself is insanely flexible, which lends itself to extensions that greatly increase its expressiveness. IMO, if you start with Moose (from the CPAN) as part of your "core library" Perl 5 becomes a very powerful tool for writing very nice code, at any scale.
Its the most powerful language that has been in existence and yet most modern programmers haven't heard about it or used it.
Almost everything to do with the ecosystem is magic, and its not even a programming language by many a measure, its a thinking paradigm so powerful that it could make many things that look impossible a walk in the park. I've only been learning it for more than a month now, and this is what I've seen.
1. Unmatchable features when it comes to modifying structured data of any kind. Many eons ago our foregeeks seemed to have imagined everything in computer science as either a list or combination of lists on somekind. Tree, Queues, Heaps, Stacks, Vectors, Graphs, Sequences, Sets... You name it, these are all lists or a combination of lists. The programs too are lists(abstract syntax trees). Most modern day data structures you will will deal with XML, JSON, Tables, Matrices are lists or a combination of lists. And lisp is list processing. Once you get a hold of lisp and its paradigm of thought, even difficult algorithms and data structures feel like a walk in the park. I used to struggle with white board coding and algorithm stuff, these day most of it comes to me naturally or little work, when I think of it in terms of lisp paradigm.
2. Recursion: For some reason, its very easy to think recursively in lisp. And that makes very easy to represent hard solutions.
3. Functional programming: Full functional programming features, no holds barred.
4. REPL: If you haven't used the Lisp REPL, you haven't seen a real REPL yet. I was completely blown away by the REPL. Combination of Emacs + SLIME is just too good. And you can hot swap code by attaching to a live process. Which is totally insane.
4. Continuations: Makes it very easy to express a variety backtracking problems.
5. Macros: Ability to extend and add any language feature and paradigm you want, at compile time at 0 costs. And anything you add becomes a part of the language.
6. Libraries: Most lisps these days have libraries for most of the needs.
7. Books: Lisp easily has the most eccentric, fun and enlightening books in all of CS history.
When you code in lisp it feels you are dropping tiny little recursive functions all over the place which grow like a small organism to a very intelligent being.
This is closest I have to come to programming Nirvana so far. The last time before this was when I used Perl.
homoiconicity
It still makes me wonder though - here we are, the concept is 50 years old, and we're still bolting lexers together.
sub infix:<d> ( $count, $faces ) {
(1..$faces).roll($count)
}
# from this point on the language has changed to have a
# new infix operator
say 5 d 20;
# (13 5 3 3 14)
POSIX shells are homoiconic; you can type set to see all the functions, which are printed in reformatted source code, that you can copy and paste.
That could work in any interpreted language. Classic line number BASIC is homoiconic. You can LIST the lines of code.
A Lisp is useful even if it isn't homoiconic (functions cannot be edited). ANSI Lisp has some loosely defined support for homoiconicity via the ed function. This isn't used much; actual Lisp environments have other means to recall and edit a function definition, such as an IDE with buffers or REPL with history.
The term homoiconic doesn't really "nail it" when it comes to Lisp.
A further development of F-Script should have been the successor to Objective-C instead of Swift. It was fun and its APL influences really complemented the Objectice-C / Smalltalk collections. It also respected Objective-C conventions.
I find it interesting none of them are really used a ton in industry, but I've written my own Civ V and Civ VI mods (and helped other people with theirs). Lua is pretty much a pleasure to work with everytime.
Lisp is one of those odd balls, that is both prelevant, but also rarely seen in industry. My primary interaction has been with Scheme, Racket, and elisp. Wiring modes for Emacs is always fun (in elisp) and amazingly short, consise, and powerful.
Ruby is a dream, mostly I use it for Rails, but the whole ecosystem is well thought out and worth the time (what little you need) to put in. I've setup websites at scale in Ruby on Rails, with components written in Ruby inline C to make it much faster, an NLP library and much more (https://projectpiglet.com/). Better yet, I've seen non-programmers pick it up in a few weeks. Honestly, when I hear someone is developing an app in Springboot (Java) or some other webframework, I'll often show them they can complete their whole app in a couple days with Rails.
It's a different style of programming, the mental state of the program when using prolog is to declare the rules that must hold true for the program to execute. You think less about state and more about logic.
In my opinion, here's what's amazing about this. There are programs that you might have a hard time solving via other means that you can easily solve with Prolog if you know the rule.
If you know the rules all you need to do is state the rules, and Prolog will find the solution for you. Besides being great for quick prototyping and application of rules. You can build complete systems with it. SwiProlog has HTTP, SSL, ODBC and even GUI support.
Logic programming just sounded like it would make sense for describing the behavior of a home automation system, and I think it works well.
Clay is a language that is no longer being developed, but it was a well designed substitute for C. It was built with templates in mind from the ground up and has modules, move semantics and no garbage collection.
Also Intel's ISPC. If you want real speed, ISPC makes it much more practical to take advantage of SIMD, though it seems not many people know about it.
You can write your requirements in this language, then send to a programmer to convert them to code.
It's a batteries-included Scheme/Lisp dialect with the best documentation I've ever seen, a state-of-the-art macro system, and a very friendly community. It has performance better than your typical dynamic language (Python, Ruby) though not as good as the highly optimized ones (Javascript V8, LuaJIT).
Often people don’t learn anything about a language’s internals, or a computer’s internals, when they learn a “nice” language with garbage collection and dynamic typing and massages. IMO for long-term software engineering that stuff is important to know.
Many see C as this old, outdated, uncool language, and never even realise that so many other languages are written in it.
But really, when it comes to perf and correctness, it’s still king:
- Often you can try to optimize a simple python program to make it run faster... or you can rewrite it in C and get a 1000x boost for free
- It has compilers that have proofs of correctness
- There are many tools that can prove a C program’s correctness
- It’s still the best way (IMO) to learn how the computer works while learning the language
- It doesn’t have OOP (which makes me sad), but you can get there by writing C++ as “C with classes”
- It probably has the most job security guarantees of any language: it will be a looooong time before C goes away
- It’s so standard and supported, programs from 40 years ago still run today; I don’t know if you can say that about any other language (except like, COBOL)
Instead I use simple data table driven control flow, global state, etc.
I love the large feature sets with some other languages for certain projects, but the small size of C makes it easy to wrap one's head around the basics. The extended learning comes from problem solving due to specific limitations.
My biggest beef is probably a little to do with number sizes (64b ++), but I just haven't learned the best method for dealing with them.
I'd dabbled in it before, but this book really does open it up wide.
And the potential for working with embedded devices in a more profound way, it can't really be beat, no?
if 1 <= x < 99 rather than if 1 <= x && x < 99 and a host of much more natural expressions
You can take my perception with a giant grain of salt though: I mostly write Scala these days, which has to be Go's polar opposite of popular languages in terms of design philosophy.
Has many superb (proprietary) compilers and handles math like it is nobody business without having to drop into manual vectorization tricks like C and C++.
Given good variable naming convention it is quite readable too. It is still being developed and enhanced as a language.
The next generation with their pandas is spoiled.
Though reading through issues and threads about it, and maybe high performance programmers using it have more than a few things to say about the state of the GC. I'm not sure if that's changed or not. I've only dabbled yet.
I'd like to see a community grow around it. It, or something like it, seems to me like the path a modern, low-level language should be going. It's not there yet, but in terms of the feature-set, optional safety, syntax, typing, etc, it's an attractive space.
Same for Java, the language itself is pretty boring, but the runtime (JVM) is great.
C# is the opposite, the language is great but the tooling and runtime are not there yet.
Sad that it has been abandoned by Red Hat.
... then Java happened.
Given (historical) alternatives of flash and java:
Want some simple scripting on a web page? JavaScript, hands down
Want a full page takeover as an app? Java didn't make much sense here- the startup time was awful, and you might as well have literally just made a java desktop app. Flash too had limitations- you could (and I have) throw something together pretty quickly with flex, but the loss of the mobile market was unfortunate.
With that said, you are afforded many paradigms, from fully OO to fully functional (from GWT, to Angular, to React, to Purescript), with everything from static, compile time safety (typescript and flow) to runtime clojure-spec ish typing supporting ADTs (tcomb, io-ts, folktale, fantasyland).
There's canvas and webgl, but with the DOM having accessibility primitives built-in, you really don't need or want to go there unless you absolutely have to.
For every fault of the language, a third party came to the rescue- from module systems (require/amd => browserify/cjs => system/webpack/tsc/ => native modules) to macros (sweet.js) to DSLs (peg.js) to whatever you can think of, all on NPM (for better or worse).
There's a lot to hate about JS. There's a lot to love, if you give it a chance without carrying emotional baggage.
A lot of these things have absolutely ruined the modern web- I hate the popups on every news website wanting to send me push notifications, and every other blog pretending to be a SPA.
A lot of these things have made business advancements possible- I once took a downloadable part configurator app from a company, which could only be installed on windows, and converted it into a web site. Average quote turnaround went from 2-3 weeks to a salesperson could walk into a customer's office, walk them through the website on an iPad, and have a quote in 15 minutes.
JavaScript, and the web platform in general, have been maligned, misunderstood, inappropriately used, but it has also been a fundamental changing point in our usage of computers, in many cases for the better.