public class HelloWorld {
public static void main(String[] args) {
// Prints "Hello, World" in the terminal window.
System.out.println("Hello, World");
}
}
This is the full code. This is what I care about on success path: System.out.println("Hello, World");
// Success
Or maybe even just: println("Hello, World");
Or maybe, because I forgot what is what in Java: java.lang.System - The System class contains several useful
class fields and methods. It cannot be instantiated.
|
| System.out : java.io.PrintStream - The "standard" output stream.
| |
| | PrintStream::println(String) -> void - Prints a String and then terminate the line.
v v v
System.out.println("Hello, World");
This is what I care when I'm looking at the module view: HelloWorld (public, class)
main(String[] args) -> void (public, static, entry point)
-- Prints "Hello, World" in the terminal window.
This is what I care when I'm looking at error propagation view: HelloWorld::main() - entry point
Program end, return code 0 [default]
Or maybe, given sufficient metadata in the standard library: HelloWorld::main() - entry point
System.out.println("Hello, World")
-> failed if System.out.checkError() == true
Program end, return code 0 [default]
Or I want a dependency view: HelloWorld
java.lang.System
[java.io.PrintStream]
Etc.Now imagine being able to open the Hello World code, and instantly switch between those views and many others with a single shortcut. Not tooltips above the code, but views that replace code. That is what I'm talking about.
Oh, and views are editable where it makes sense. Even read-only views would improve the development experience a lot, but the magic is in mutable views, so that you don't ever have to touch the full, original form of the source.
EDIT: look at the first vs. third code-block in this comment. People built whole programming languages on the premise that Hello World should look like the third block instead of the first one. That's an extreme case of making a style choice ahead of time, and also a source of endless, pointless debates.
That is, if typing in one of the restricted views, is it possible to create a bug because of something that's currently hidden from you? I feel as soon as that happens to someone, they are going to switch to the "show everything" view and never switch back.
> look at the first vs. third code-block in this comment. People built whole programming languages on the premise that Hello World should look like the third block instead of the first one.
Well that was silly of them. Microsoft managed to retrofit it: https://learn.microsoft.com/en-us/dotnet/csharp/tutorials/to...
Isn't this always the case?
I don't think there is a "full view" like you describe. Even if you're writing raw assembly, you're still working on top of the abstractions provided by the instruction set. There is no such thing as a full view where you can see every detail of everything that is going to happen.
I think the solution to this problem is tests and doing your due diligence in understanding what you're doing.
Having more control over what abstractions you're seeing should help with the understanding part, which should in turn reduce bugs resulting from lack of understanding.
Edit: related thought: it's about improving the tooling. Which I suppose is another thing for someone to learn and possibly misuse. But I don't think it's correct to say that firefighters shouldn't carry axes because they could accidentally kill someone with them.
Part 2: https://m.youtube.com/watch?v=ZZDwB4-DPXE
You can project your programs into different views and add lots of metadata about the program and use that data in various contexts. Also extends to source control and other use cases. It looked really neat.
I'm not sure what happened to it.
One could start from a real case in a real company, document it thorougly, including different stakeholders. Then rewrite the code to fit this organisation at this point in time.
Then, make a two or three fictional changes to the organisation and circumstances, snapshot these (or follow an organisation longitudinally for long enough that this occurs naturally) and for each snapshot, rewrite and redocument the code to fit those circumstance.
From that, one could "dumb down" the whole thing until it stops making sense and see how simple one could make it.
Probably there are people smart and seasoned enough to write an entirely fictional account of all of this, and still have it make sense - that's not me though.