Java vs C

• 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.

Undefined behavior in a program can cause unexpected results, making it hard to debug. With UB, program behavior may vary wildly depending on optimization settings. There are many cases that invoke UB, such as signed overflow, invalid dereferences, large integer shifts, uninitialized variables, etc. These serve to frustrate novice programmers when they could be learning other concepts.

Learning programming is already hard enough when you don't have to worry about memory leaks.

The C standard library is not type safe, and the language itself does not promote type safety built into the language, which leads to error-proneness of the language. If anything, it would be recommended that those interested in C to instead put their time in D, which actually includes a complete copy of the C standard library rewritten to be fully type safe.

While other programmers will learn algorithms and structures and will do magic tricks and awesome applications, you will learn trash info that you should know maybe after 5-7 years experience in software development, not earlier. It's like going the first time as a seven year old kid to first school class, and your teacher tells you to learn you about Discrete Math, without basic math and how to do 2x2.

If you wish to be a really good programmer, C for sure will be in your portfolio, but not as a first language, and this programming language is used only for very hard and very limited tools which require a lot of professional skills from the programmer.

Header files are a poor man's implementation of modules. Modern programming languages make use of modules which eliminate the need for C includes and header files and the many issues caused by them, such as the complete lack of dependency checking. Header files often contain even more include statements that point to other header files which also point to even more which drastically increases compile time. Modules only have to be compiled once, and when importing those modules into your software project, you only have to pull in the module that you are using, which is often times already precompiled. This way, the compiler knows exactly what it needs before beginning to compile your project and can automatically compile the few dependencies it needs in advance rather than recursively compiling every header file it runs across as in C.

While the language compliments knowledge of computer components very well, and gives a deeper understanding, it is also quite difficult to learn, and to use correctly, especially without aforementioned knowledge.

Depending on the purpose this can be either a pro or a con. If the task is to learn how to program, low-level of C will impend learning important concepts. Furthermore, C is rather limited in ways of building abstractions.

"Low-levelness" of C can be a pro feature in learning system programming.

There are languages like Rust, Object Pascal, D, Golang, Vlang, Odin, Zig, Jai, etc... that can be used instead. The other languages are easier to understand, use, and/or about as fast.

In the same manner that C recursively compiles header files ad infinitum without any sort of dependency checking, C source code is also compiled in the same manner. If you attempt to call a function before it is declared, the compiler will fail because the function was not compiled before it was caled.

C does not support the string type, nor does it support UTF-8 strings that modern languages are employing today. Instead of strings, C makes use of the *char type which is a pointer to a character array.

When an array is passed to a function, it is converted to a pointer, even though the prototype confusingly says it's an array. When this conversion happens, all array type information gets lost. C arrays also cannot not be resized, which means that even simple aggregates like a stack are complicated to implement. C arrays also cannot be bounds checked, because they don't know what the array bounds are.

Subtle errors can render the entire program "undefined" by the complicated C standard. The standard imposes no requirements in such cases. Thus C compiler is free to ignore the existence of such cases and Bad Things are prone to happen instead. Even experts can't reliably avoid undefined cases in C, so how can beginners be expected to do so? C allows for non-type safe operations such as logic errors, wild pointers, buffer overflow, etc. UB and type safety issues create a large number of bugs and security vulnerabilities.

Older languages, like C, are no longer in their hay day. Even if you do learn it as your first language, you are only setting yourself up to need to learn another language in the long run. If you want a skill that you can not only learn from, but also potentially build a career on, C should not be your first choice.

The C programming language is not portable to other operating systems, and even different compilers, because the C language does not provide any reference cross platform libraries or compilers. Different platforms and compilers provide their own implementation of the C standard library which may not be compatible with the implementation in another compiler or platform. Without cross platform libraries and tools, one cannot state that C is portable. This is in stark contrast to modern programming languages that provide their own cross platform libraries and compilers, such as D, Go and Rust.

Modern programming languages are capable of compiling split source code files by concatenating them together efficiently at compile time before compiling them. However, C requires the developer to resort to messing with header files and makefiles to get similar functionality.

C structs lack a lot of modern capabilities that are vital in programming languages of today, such as assigning member functions to structs to give them object-oriented capabilities, constructs, deconstructors and RAII. Great care must be used when using structs in C to prevent memory leaks and ridiculously slow structs.

All the modern languages have resulted in ditching the ancient deprecated model of #include statements and have instead adopted the superior model of modules. When compiling software written in C, the programmer is forced to also compile X headers which contain Y headers which contain Z headers and so forth -- drastically increasing the number of lines that need to be compiled. In order to compile something as simple as "Hello, World", for example, 18K lines of code needs to be compiled. This can be very taxing on RAM and CPU resources, causing compile times to quickly absorb a large portion of the programming process.

C lacks a large majority of programming concepts that modern languages make use of today. The existing functionality of C makes use of outdated and deprecated methodologies which can be of great annoyance to the modern day programmer.