Also, good luck doing major refactoring with a text editor. In 2020 we can do better than find and replace.
As I said, just try to think in Java (rather than Java-esque pseudocode.) Try to write a Java program in advance, in your head, that only needs typing-in (in a plain text editor!), such that it's valid the first time you type it in. Imagine how carefully and meticulously you'd have to think, to get that code right. That required meticulousness is another measure of Java's inherent friction.
> good luck doing major refactoring with a text editor
A language can also be high-friction or low-friction when it comes to how hard it is to refactor code in that language. Though this comes from more abstract architectural constraints the language imposes, rather than things like syntax or identifier naming conventions.
For example: Erlang code is low-friction for refactoring, because code that lives in a separate process needs to be spoken to through a messaging ABI; which necessitates that every such process have an API-client module to encapsulate that ABI; where that client API then offers a de-facto interface/contract for clients of that API to hold to; which frees anything underneath that API from stability requirements, as long as the API itself remains stable. The fact that this is done "in the small", per process, rather than in the large, per package/library, means that Erlang "refactoring" almost always just consists of changing the shape of a process state-function, and then adding some polyfill logic to its client API module-function to keep the process working.
That's not necessarily a bad thing. For one, writing real world code in your head would require a level of trivia memorization (e.g. the standard library function signatures) that most people have deemed a waste of time. Secondly, meticulousness is usually a positive trait in a programmer. If Java's going to be negatively evaluated for that, then it needs to be shown that the kinds of meticulousness it requires don't actually add value in cases where it's used (which may not be like your cases).
Elixir is slightly higher-friction; all that weird extra Erlang syntax that Elixir eschews (the comma and semicolon statement-binding operators specifically) has a purpose in making Erlang “mentally lintable”, so Elixir loses some of that.
It gains in other places, though; for example, Elixir’s hygenic macros impose much less of a mental load than Erlang’s parse-transforms do. (Just the fact that you have to explicitly require the definition-site module before using any macro from that module, is a big boon to predicting what’ll happen when you go to run the code.)
Spin a blank "hello world" project in Android Studio and you get no less than 79 files, and it won't work the next time you update Android Studio because of some Gradle errors.
I don't know what went wrong, but "hello world" should not be 79 files, it should be something that I can hand-code in something less than an IDE.
class MyApp extends AndroidApp {
void main() {
Document.write("hello world");
Document.write("<button id=\"foo\">blah</button>");
}
}
Ant? Maven?
Yeah I know it doesn't work like this now, but the designers of the entire Java/Android ecosystem should have designed it to be that simple.
The moment you get any of these build systems involved you instantly lose all hopes of DRY coding. Excerpts from an Ant build.xml file:
<target name="jar" depends="compile">
<mkdir dir="jar" />
<jar destfile="jar/HelloWorld.jar" basedir="classes">
<manifest>
<attribute name="Main-Class"
value="antExample.HelloWorld" />
</manifest>
</jar>
</target>
<target name="run" depends="jar">
<java jar="jar/HelloWorld.jar" fork="true" />
</target>
Scripting languages are programming languages, and a class with a method is only typical of a narrow class of languages (most of which that aren't Java are specifically designed to closely follow Java); leaving aside those programming languages typically called “scripting” languages, in C++ it is just a function, just like C; D is pretty similar (as are most procedural languages, including those like C++ that also support class-based OOP without being obsessive about it, and also most impure functional languages.)
In Haskell it's just: main = putStrLn "Hello, World!"
https://developer.gnome.org/gtk3/stable/gtk-getting-started....
Any higher level language and ecosystem than C should be less verbose and less involved than this. Otherwise, what's the point of being higher level?
That’s Android Studio’s default workflow designed around the expectation that it's going to be used for building Android apps in a particular style, and to optimize for what is usually appropriate for that, which is very much not “Hello, world!” optimized.
As much as Java is a needlessly verbose language, the problem you are looking at is an particular IDE / build system / project type combination issue, not a Java issue.
This is a problem with the Android platform itself.