JavaScript vs Java

JavaScript looks for every possible way to treat the code you write as runnable and is very reluctant to point out likely errors. For example, you have call a function with too many arguments, the extra arguments are simply discarded.

If you forget a var or new, you can clobber the global scope. For tiny scripts (JavaScript's original use case) globals are great, but for larger applications globals are generally regarded as a Bad Thing. This is because changes to one small part of a program can randomly break things anywhere else. These kinds of bugs are notoriously hard to find.

Since JavaScript is a weakly typed language, you don't have to learn about data types if you start using JavaScript as your first language. Data types being one of the most important concepts in programming. This will also cause trouble in the long run when you will have to (inevitably) learn and work with a strongly or statically typed language because you will be forced to learn the type system from scratch.

'5' - 1 == 4, but '5' + 1 == 51. There are other examples that make even less sense.

JavaScript has a long litany of warts and gotchas. JavaScript will bite you if you're just a wee bit careless. You have to exercise a great deal of caution and awareness. You either have to know the entire 545-page ES6 spec to avoid them all, or use a linter to help restrict you from using the bad parts (and you still have to be familiar with the language), but beginners don't know these things. (Linters are also prone to time-wasting false positives.) This is a significant cognitive burden on even the experienced programmer (as if coding wasn’t hard enough already), but try learning to program in the first place on top of all of this and you'll understand that JavaScript is a terrible choice for the beginner.

It wouldn't consolidate a good mind structure for moving to other languages. Too open.

Beginner programmers often make the mistake of coding something, seeing it works in the browser they tested it in, and then scratching their heads when it doesn't work in another browser. Ideally you'd want a language that works consistently across all platforms in order to be able to focus more on the programming and less on the underlying environment. It just takes time away from learning and forces you to spend time figuring out why this worked in browser X but not browser Y.

Trying to keep up=javascript fatigue. You won't have time to learn anything else if this is your first language, and you will probably think all programmers are crazy. Plus web assembly may open the door for better alternatives.

this is bound to whatever object called the function. Unless you invoke it as a method. Unless you invoke it as a constructor. Unless it's an arrow function.

Much often needed functionality is not in the standard library. (Contrast with Python.) However, there are well established libraries such as Lodash, to fill the gap (however, due to the diverse/fractured ecosystem it may not be clear what library to use).

JavaScript can work synchronously but its current use is mainly around asynchronous instructions, and it's surely not a good way to start learning programming.

Therefore, attempts to call methods on them will fail. This is especially frustrating since these are often returned instead of throwing exceptions. So a failure may appear far away from the actual cause, which makes bugs very hard to find.

Many cases when you should get an Array, you just get an Array-like object instead and none of the Array methods work on it.

The language and the web platform move fast these days. this makes it difficult for students as there is a lot of fragmentation and outdated information.

This is very surprising for beginners. Especially since 00 through 07 seem to work just fine. And this isn't just for hardcoded numbers. The parseInt() function has the same problem, but only on some systems.

You really want to be using a good editor (light IDE) and a linter, type checker (e.g.:Flow), etc. until you grok the language. And choosing / setting-up that development environment is it's own learning curve. If taught in a classroom, using a subset of JS with solid tools, there is an argument that JS could be an ideal first language... however, that is a lot of ceremony to protect the new programmer from JS gotchas. But without the tools, JS can be a very painful painful first language (trying to figure out why your code isn't doing what you intended).

JS is one of the most dreaded languages as it was designed for the purpose of becoming just an scripting language for a browser. It was never intended to take over as the leading technology in web development, thus the language has been streched past its own capabilities. A beginer should learn something else first, something that is better conceived and refined.

JavaScript is rather inconsistent when dealing with different types. For example, when working with the + operator and two numbers, they will be added, two strings will be concatenated:

3+5; // 8;
"Hello "+"world"; // "Hello world"

When using + with a string and a non-string operand, the non-string operand is converted to a string and the result is concatenated:

"the answer is "+42; // "the answer is 42"
"this is "+true; // "this is true"

In any other case (except for Date) the operands are converted to numbers and the results are added:

1+true; // = 1+1 = 2; 
null+false; // = 0+0 = 0;

Angular, React, Ember, Meteor, Backbone, Knockout, Express, Mithril, Aurelia. The web frameworks pass in and out of fashion too quickly to keep up with. The endless civil wars are becoming tiresome.

But beginners won't know better. And even after you learn, you might have to deal with others' code that uses the bad stuff. JavaScript was originally developed in 10 days. It just wasn't designed that carefully.

• A Hello world needs package, class, static method and the actual printf.
• Reading a line from input requires instatiating 5 objects in the right order.
• Exceptions are everywhere, particularly since all values are nullable.
• Java has a getter/setter culture, but without native syntax support.
• portable Java code lacks anonymous functions, and continues to lack good support for partial application, compensating instead with verbose design patterns, kludges like anonymous inner classes, or just inline code.
• It is statically typed without type inference, with a culture that promotes long class names.
• Poor support for sum-types and pattern matching leads to overuse of inheritance for dynamic dispatch and chains of nested conditionals

Especially for beginners, this can make reading Java code feel overwhelming; most Java courses tell students to simply copy, paste, and ignore a significant percentage of the code until they've learned enough to understand what it means.

For experienced programmers, this makes Java feel tedious, especially without an IDE, and actively discourages some solutions and some forms of abstraction.

Some features in Java can be quite confusing for beginners.

Encapsulation is needlessly obfuscated with a confusing access control model. As an example, the "protected" keyword not only grants access to child classes, but to the entire package. Since small programs are written as one package, it becomes functionally equivalent to "public".

In OOP, everything is supposed to be an object, but, in Java, primitive types such as integers, booleans and characters are not, and must be handled as special cases.

Java continues to lack many high-level features, and, particularly prior to Java 7, compensated by adding confusing Java-only features, such as anonymous subclasses. Some example code is unreadable without knowing a special-case feature, libraries differ in style based on when they were released or what platform they target(e.g., Android vs. Desktop), and some solutions just aren't available on some platforms.

Overly focuses on class-based OOP to the detriment of programmer freedom or alternative paradigms that are better for various problems. Traps programmers into an always use class-based OOP mindset.

Type erasure means it doesn't even exist at runtime. The whole generics system is confusing for beginners.

Too far from the machine hardware.

I've been developing in Java for 20 years and I love this language, I've never used a better designed one over the last 30+ years. However, starting with version 6, the number of really useful features in each release has steadily decreased. There is now too much marketing in Java's evolution and too few concern about developers' needs (the functionalities of the applications we develop haven't changed and enterprise application architecture is much simpler than 20 years ago). I'm deeply sad to say that today, learning Python is a much wiser choice.

Java is a garbage collected language and it does not force programmers to think about memory allocation and management for their programs. This is fine most of the time. However, it may cause some difficulties in adjusting to a non-GC language (such as C for example), where memory management needs to be done manually. But if good coding practices and habits are followed, this shouldn't be much of a problem.

It's just barely good enough to make decent IDEs, but it's not at the level of Idris or even Haskell. For large enterprise projects, the IDE support is important, but the static typing in Java just gets in the way for the smaller projects beginners would start with.

Python is duck typed and this makes small programs easy to develop quickly, but the price is that you have to write unit tests to avoid breaking larger programs. In contrast, you can be reasonably certain that a program that actually compiles in Idris does what you want, because assertions are built into the powerful type system. Java can't make that claim and still requires unit tests. Java has the worst of both worlds because of its poor static type system.

The type system gets in your way more than it helps. Heavy IDE support is absolutely required for reasonable productivity. This means beginners have to learn not just the language, but eventually a complex, heavyweight IDE too.

Java evolves very slowly - lambda expressions weren't available until Java 8 (which is not available on Android), and despite getters/setters being a long-time convention, the language still doesn't have native accessor syntax (a la C#'s properties). It's unlikely newer, popular features like list comprehensions or disjoint union types will be available anytime soon. While not strictly required for novice programmers, these make problems more complicated and tedious than they need to be - for example, when a simple local function would do, (portable) Java demands anonymous inner classes, an interface and a class, or worse, no abstraction at all.

Since C# came later, it could avoid the blatant mistakes made in Java.

Java utilizes principles that primarily organize code into "classes" as the central concept, instead of more familiar organizational methods.

Checked exceptions add significantly to the cognitive load of the beginner. The more rules unrelated to the actual task that you pile onto the beginner, the slower he gets. Exponentially. And for what? Sure, they look good on paper, but checked exceptions are useless in the real world. They don't scale.

When you're calling APIs five levels deep and your method's throws clause balloons to 80 exceptions you might see, it gets kind of ridiculous. So you just say throws Exception, which defeats the whole feature, but is more pointless boilerplate in an already tediously verbose language.

Or worse, while developing you can't be bothered and just catch{} and silently swallow them all. Then you forget about it. Now you don't even have exceptions. The cure is worse than the disease!

So the wiser Java programmers will wrap all checked exceptions into a runtime exception, effectively making exceptions unchecked. That's at the cost of more boilerplate, but it's the lesser of evils. Unfortunately, Java doesn't even have macros to do this part for you. Maybe your IDE can write code templates for you, but that doesn't make it any easier to read.