8 ms·

Java doesn't have a lot of friction. In fact, IntelliJ is probably the closest you'll get today to the "golden age" of programming with something like Turbo Pas

by winrid 6y ago

Java doesn't have a lot of friction. In fact, IntelliJ is probably the closest you'll get today to the "golden age" of programming with something like Turbo Pascal. Also, good luck doing major refactoring with a text editor. In 2020 we can do better than find and replace.

dheera 6y ago
The way people use Java is a problem. 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.
- sethammons 6y ago
  Heh. Some years ago, I thought I’d step away from highly available distributed systems and build an android app. Got to the point in the tutorial where we needed to define a string for “hello, world” and the tutorial said, “ok, navigate to such and such directory and add this xml file and ...”. Closed the tutorial assuming Java is not for me.
  - iamcreasy 6y ago
    The tutorial also said that you are placing this string in an xml file for easy localization in the future. I am not defending their setup, but it sends a wrong message when you skip parts of the sentence.
    - DreadY2K 6y ago
      But is it ideal for a "Hello, world" program to follow all best-practices? In my opinion, a "Hello, world" program should do the bare minimum to print "Hello, world" to the screen, and no more, so that it represents the language at its most basic.
      - dheera 6y ago
        Yeah I mean it should be as basic as class MyApp extends AndroidApp { void main() { Document.write("hello world"); Document.write("<button id=\"foo\">blah</button>"); } } javac it, adb sideload the .class file (or .jar file), and you should be done for the day. Unfortunately the bare minimum is way way way more complicated than this. Weird XML files, infestations of manifests (generate them automatically from 'ls' and 'grep' damnit), Gradle files (worst abomination of a build system ever), API levels (how about you just infer it from the functions I use? I shouldn't need to tell you), signing (ok fine but this should only be needed when uploading to an app store), zipaligning (wtf, this should be automatic, don't make me do that nonsense).
        Almad 6y ago
        > Gradle files (worst abomination of a build system ever) Ant? Maven?
        dheera 6y ago
        Ugh. Why can't we just make javac [STAR].java work? Tarball the resulting .class files, make sure to have one called Main.class that is the entrypoint, GPG sign the tarball and you should be ready to distribute. 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> I see "HelloWorld" repeated 3 times. MASSIVE fail. I'd rather no build system than deal with this level of repetitiveness. It's bad enough that Java requires the file name == class name which is already a case of repetition (that design decision is fine with me but then files should start with "class {" and not "class Foo {")
        6y ago
  - sk5t 6y ago
    This sad outcome is 100% not Java's fault.
  - winrid 6y ago
    That's because they want you to get used to properly localizing your app. Work in any localized system and you'll define the text in JSON or XML files.
- tomc1985 6y ago
  Yeah but "Hello World" in actual java is a main class and a quick write to stdout, like most any other normal (programming, not scripting) language
  - dragonwriter 6y ago
    > Yeah but "Hello World" in actual java is a main class and a quick write to stdout, like most any other normal (programming, not scripting) language. 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!"
    - tomc1985 6y ago
      My point was that Java's hello world is comparable to most other language, and that hello world in Android is a poor example
      - deleted 6y ago
        [deleted]
      - dheera 6y ago
        Well here's GTK hello world in freaking C. One file that you can gcc and run "./a.out". Not 79 files with a build system that breaks every time you hit "upgrade", and which requires me to install gigabytes worth of SDK API bloat and agree to 10 different license agreements. Want a free build system that works for this for every version of Linux in the past decade and probably the coming decade? All you need is ONE "Makefile" and you're done. https://developer.gnome.org/gtk3/stable/gtk-getting-started.html 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?
- dragonwriter 6y ago
  > Spin a blank "hello world" project in Android Studio 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.
- brabel 6y ago
  The language is not the problem: A Kotlin Android project will have the same number of files. This is a problem with the Android platform itself.
  - deleted 6y ago
    [deleted]
derefr 6y ago
You're conflating the language and the prosthetic used to code in it. Java is a high-friction language. Write it in a text editor, and measure how long it takes to write some working nontrivial Java. What you're measuring there is the inherent friction of Java, as a language. The IDE adds negative friction — lubrication — to the process. But that's a separate thing from the language itself. 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.
- ardy42 6y ago
  > 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. 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).

by winrid 6y ago

dheera 6y ago

The way people use Java is a problem. 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.

sethammons 6y ago
Heh. Some years ago, I thought I’d step away from highly available distributed systems and build an android app. Got to the point in the tutorial where we needed to define a string for “hello, world” and the tutorial said, “ok, navigate to such and such directory and add this xml file and ...”. Closed the tutorial assuming Java is not for me.
- iamcreasy 6y ago
  The tutorial also said that you are placing this string in an xml file for easy localization in the future. I am not defending their setup, but it sends a wrong message when you skip parts of the sentence.
  - DreadY2K 6y ago
    But is it ideal for a "Hello, world" program to follow all best-practices? In my opinion, a "Hello, world" program should do the bare minimum to print "Hello, world" to the screen, and no more, so that it represents the language at its most basic.
    - dheera 6y ago
      Yeah I mean it should be as basic as class MyApp extends AndroidApp { void main() { Document.write("hello world"); Document.write("<button id=\"foo\">blah</button>"); } } javac it, adb sideload the .class file (or .jar file), and you should be done for the day. Unfortunately the bare minimum is way way way more complicated than this. Weird XML files, infestations of manifests (generate them automatically from 'ls' and 'grep' damnit), Gradle files (worst abomination of a build system ever), API levels (how about you just infer it from the functions I use? I shouldn't need to tell you), signing (ok fine but this should only be needed when uploading to an app store), zipaligning (wtf, this should be automatic, don't make me do that nonsense).
      - Almad 6y ago
        > Gradle files (worst abomination of a build system ever) Ant? Maven?
        dheera 6y ago
        Ugh. Why can't we just make javac [STAR].java work? Tarball the resulting .class files, make sure to have one called Main.class that is the entrypoint, GPG sign the tarball and you should be ready to distribute. 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> I see "HelloWorld" repeated 3 times. MASSIVE fail. I'd rather no build system than deal with this level of repetitiveness. It's bad enough that Java requires the file name == class name which is already a case of repetition (that design decision is fine with me but then files should start with "class {" and not "class Foo {")
        6y ago
- sk5t 6y ago
  This sad outcome is 100% not Java's fault.
- winrid 6y ago
  That's because they want you to get used to properly localizing your app. Work in any localized system and you'll define the text in JSON or XML files.
tomc1985 6y ago
Yeah but "Hello World" in actual java is a main class and a quick write to stdout, like most any other normal (programming, not scripting) language
- dragonwriter 6y ago
  > Yeah but "Hello World" in actual java is a main class and a quick write to stdout, like most any other normal (programming, not scripting) language. 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!"
  - tomc1985 6y ago
    My point was that Java's hello world is comparable to most other language, and that hello world in Android is a poor example
    - deleted 6y ago
      [deleted]
    - dheera 6y ago
      Well here's GTK hello world in freaking C. One file that you can gcc and run "./a.out". Not 79 files with a build system that breaks every time you hit "upgrade", and which requires me to install gigabytes worth of SDK API bloat and agree to 10 different license agreements. Want a free build system that works for this for every version of Linux in the past decade and probably the coming decade? All you need is ONE "Makefile" and you're done. https://developer.gnome.org/gtk3/stable/gtk-getting-started.html 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?
dragonwriter 6y ago
> Spin a blank "hello world" project in Android Studio 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.
brabel 6y ago
The language is not the problem: A Kotlin Android project will have the same number of files. This is a problem with the Android platform itself.
- deleted 6y ago
  [deleted]

derefr 6y ago

You're conflating the language and the prosthetic used to code in it. Java is a high-friction language. Write it in a text editor, and measure how long it takes to write some working nontrivial Java. What you're measuring there is the inherent friction of Java, as a language. The IDE adds negative friction — lubrication — to the process. But that's a separate thing from the language itself. 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.

ardy42 6y ago
> 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. 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).