Whatever a programming language is, it has to be something you can hold onto in your head, because the human mind is where "programming" takes place. And there really aren't many forms that such a thing can take.
The step-sibling of programming languages, the mathematical proof, can really take any form we like; we're not limited to maths that can run on a computer, as long as we can "run" them in our minds. But we've still ended up with only two basic formalisms that almost(?) all mathematics is expressed in terms of: geometry (visual mathematics), and algebra (symbolic mathematics, including formal logic.) Because those are the formalisms that we have mental hardware to comprehend.
Anything that isn't in one of those shapes (say, an exhaustive computer-assisted proof-by-parts) might still be productive to prove; but we humans won't like it, and will always seek to replace it with something that we can get a mental "handle" on.
We'd certainly never take the formalisms that do work for us, throw them out, and replace them with non-human-mind-comprehensible formalisms instead. Why would we bother? What would we gain?
> Being able to push secondary parts of a program to be foldable, or visible on mouseover but not by default, makes it easier to communicate understanding to other humans. And actually that's a more faithful recreation on how you'd communicate in writing - on a blackboard you might use small text, or footnotes, or a verbal explanation.
Oh, I don't disagree. But all those things are useful for plain text, too. As you say, humans already think and manipulate text that way. And "advanced" text editors already provide facilities to manipulate text that way, without any understanding of programming-language syntax.
You can get very fancy about how you manipulate symbols... as long as "just manipulating symbols" is truly all you're doing. As pure symbol manipulation is something you can always also do in your head. Go much beyond that, though, and you stray from the land of "things humans can keep track of in their brains."
Can you think in terms of what a JetBrains codebase will look like after you refactor it, without actually doing the refactoring and seeing the result? How about with two or three such applications in play? It gets pretty hard, no? Because those aren't just pure symbol-manip. They're not just moving letters around on the mental blackboard that represents the current module. The non-local effects aren't strictly intuitive. Each layer of that that you have to hold solely in your head, bogs you thinking down. In a high-friction language, you just don't bother to try to work too far ahead with such changes; you just "take things one step at a time", applying each change and then re-learning the codebase in light of it; sometimes applying a change and then backing out once you realize you're got your sequencing wrong.
Sometimes working "with blinders on" like this is necessary (e.g. fixing up a big ugly three-way git merge); but why subject yourself to it if you don't have to? Wouldn't you rather be able to understand what you're doing, and where you're going?
> A mathematical paper is almost never "plain text" in the sense of being a linear sequence of ascii characters and nothing more.
I mean, they're usually written in LaTeX ;) But to be clear and precise, I was trying to invoke the concept of a https://en.wikipedia.org/wiki/Formal_language. Programming languages and (symbolic) mathematics are both formal languages. You manipulate them algebraically, by moving the symbols around, applying transformations that turn one valid statement into another valid statement.
Yes, there are isomorphisms, e.g. visual "programming languages" like Scratch. They're certainly neat, but as far as I've been able to ascertain, people can't really think in them the way they can think in symbols.
Ask a composer: what do you think about when you compose music? Do you think of the sound; or do you picture the score? Where music's concerned, I would guess pretty much everyone is thinking about the sound, because that's a lot more intuitive. Someone could probably write a song entirely by manipulating a score in their mind—and make it sound good!—but it'd be hell to do, in comparison.
I don't think the IDE should do "everything" for you, and you should understand how its building/compiling the software. But with statically typed languages and library definition hints. I think I would be wasting time searching docs if I didn't have the hints and type info. I can't remember everything I work with, it's impossible.
Just two among many reasons to use IDEs.
I don't know what kind of refactoring you are doing but for me yes I absolutely know what it will look like after the refactoring. In fact, that is usually why I'm doing it: refactoring to remove complication.
For example, the typical "extract method" refactoring lets me grab a piece of code that is almost duplicated elsewhere and turn it into a method with conditional logic to handle both conditions. That's a great simplification and make it much easier to hold in my head.
>Can you think in terms of what a JetBrains codebase will look like after you refactor it, without actually doing the refactoring and seeing the result? How about with two or three such applications in play?
Not sure what you mean here, IDE built-in refactorings are tools that I use because I know exactly what I want to do and what the codebase should look like after I do it, but the work to get there is tedious and repetitive. I have never had trouble imagining how they work or what the result will be. Compilers do optimizations that alter the structure of programs reliably; an IDE with a language model as rich as the IntelliJ suite's is little different from a compiler specialized to a few high-level optimizations.
>Programming languages and (symbolic) mathematics are both formal languages. You manipulate them algebraically, by moving the symbols around, applying transformations that turn one valid statement into another valid statement.
We seem to think about programming languages very similarly. Always nice to find a fellow traveler ;)
I'm not really a fan of Java though I will confess to liking C# a lot. My heart is with OCaml and Idris though. So why do I program in C#? Why do I choose such a "high-friction" language, as you put it? C# is most definitely not designed from the ground up for maximum developer ergonomics.
It's because of the ecosystem, and specifically tooling like the JetBrains IDEs. I'm more productive in a language like C# because of the depth of high-quality libraries available to me and the quality of the tooling I use. Yes, some of the worth of an IDE is in papering over ergonomic problems in languages. However, IDEs are certainly not required to write code in these verbose languages. I use them because they are powerful tools that are well adapted to the conceptual model of the languages they support, and they enhance my ability to use patterns and write code "fluidly" as you put it.
Even in more ergonomic and expressive languages this has value, probably even more than it has in C# or Java. These languages are easier to write without an IDE, but we don't know what we're missing because the high-quality tooling just doesn't exist. Idris' Atom support is a pointer in the direction I'm thinking of: https://atom.io/packages/language-idris
Just think about what an IntelliJ-level IDE could do for a language with a type system as rich as Idris'. You might be able to infer entire applications based off a handful of expressive type signatures. We have yet to see what writing in one of these languages is like with a suitably powerful design environment, and I fully believe that it will make writing them with a text editor look pedestrian just like IntelliJ did to Java.
You're welcome to use it as cleaner Java and it will work well for this.
You're equally welcome to make use of more advanced features.
You're also welcome to go nuts and use all the features but it's not recommended.
> We'd certainly never take the formalisms that do work for us, throw them out, and replace them with non-human-mind-comprehensible formalisms instead. Why would we bother? What would we gain?
The dominance of those formalisms is at least as much about the physical hardware as the mental hardware. In my head, a mathematical proof is usually something like a tree structure or even a wiki: I have an overview that A implies B and B and C together imply D, and then if I "zoom in" then there's all sorts of structure to the steps to get from A to B. Of course if I were to write this proof on paper or blackboard then I'd have to flatten it (though not completely; I'd certainly break it up into lemma x and sub-lemma y), but saying that a paper is the human-mind-comprehensible formalism is putting the cart before the horse. The kind of richer structures that we can use with computers - Jupyter-style notebooks, or wiki-like linked crossreferences - makes it easier for humans to comprehend, not harder.
> Can you think in terms of what a JetBrains codebase will look like after you refactor it, without actually doing the refactoring and seeing the result? How about with two or three such applications in play? It gets pretty hard, no? Because those aren't just pure symbol-manip. They're not just moving letters around on the mental blackboard that represents the current module. The non-local effects aren't strictly intuitive. Each layer of that that you have to hold solely in your head, bogs you thinking down. In a high-friction language, you just don't bother to try to work too far ahead with such changes; you just "take things one step at a time", applying each change and then re-learning the codebase in light of it; sometimes applying a change and then backing out once you realize you're got your sequencing wrong.
Completely disagree. The result of the refactoring is always the obvious thing that you'd expect, and having the IDE take care of the details of which characters change in which files makes it much easier to focus on the actual change you're making rather than get bogged down in the details. I can't imagine understanding programming as manipulating a flat sequence of symbols; it would be like trying to work in Brainfuck.
> Ask a composer: what do you think about when you compose music? Do you think of the sound; or do you picture the score? Where music's concerned, I would guess pretty much everyone is thinking about the sound, because that's a lot more intuitive. Someone could probably write a song entirely by manipulating a score in their mind—and make it sound good!—but it'd be hell to do, in comparison.
Again I think you're getting this completely backwards. I have the structure of the program in my head, and it's something much richer than a sequence of symbols; it's a graph of directed connections, and much more besides. An IDE that can do things like showing references on hover gives me a much closer representation of the program than a linear sequence of symbols, brings me much closer to being able to manipulate the program itself; manipulating the sequence of symbols sounds exactly like manipulating the score instead of manipulating the sound.
I remember people making similar arguments when cars started to have power steering.
> Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye.
I disagree; programming languages are primarily tools for programming on computers, and expecting them to be skeuomorphic to a particular approach may hold us back, just like expecting a CAD program to work the same as a physical drafting table or expecting a rendering engine to use a TV-like fixed framerate.
Being able to push secondary parts of a program to be foldable, or visible on mouseover but not by default, makes it easier to communicate understanding to other humans. And actually that's a more faithful recreation on how you'd communicate in writing - on a blackboard you might use small text, or footnotes, or a verbal explanation. A mathematical paper is almost never "plain text" in the sense of being a linear sequence of ascii characters and nothing more. A language whose design embraces IDEs can be a better tool than one that flattens everything into the binary of written in the code or completely invisible.