Tom

Null is terrible.

A lot of languages have it available as a valid return value for most things, implicitly. This also means you have to do extra checking or something like this will blow up with an exception:

// java example
// can throw exception
String address = person.getAddress().toUpperCase();

// safe
String address = "";
if (person.getAddress() != null) {
    person.getAddress().toUpperCase();
}

There are a ton of solutions out there. Many languages have added null-coalescing and null-conditional operators – which are a shorthand for things like the above solutions. Some languages have removed the implicit nulls (like Kotlin), requiring them to be explicitly marked in their type. Some languages have a wrapper around nullable values, an Option type. Some languages remove null entirely from the language (I believe Rust falls into this, using an option type in place of).

Not having null isn’t particularly common yet, and isn’t something languages can just change due to breaking backwards compatibility. However, languages have been adding features over time to make nulls less painful, and most have some subset of the above as options to help.

I do think Option types are fantastic solutions, making you deal with the issue that a none/empty type can exist in a particular place. Java has had them for basically 10 years now (since Java 8).

// optional example

Class Person {
    private String address;
    
    //prefer this if a null could ever be returned
    public Optional<String> getAddress() {
        return Optional.ofNullable(address);
    }
    
    // not this
    public String getAddress() {
        return address;
    }

When consuming, it makes you have to handle the null case, which you can do a variety of ways.

// set a default
String address = person.getAddress().orElse("default value");

// explicitly throw an exception instead of an implicit NullPointerException as before
String address = person.getAddress().orElseThrow(SomeException::new);

// use in a closure only if it exists
person.getAddress().ifPresent(addr -> logger.debug("Address {}", addr));

// first example, map to modify, and returning default if no value
String address = person.getAddress().map(String::toUpperCase).orElse("");

Bill is a liability.

I’m reluctant to call much “bloat”, because even if I don’t use something doesn’t mean it isn’t useful, to other people or future me.

I used to code in vim (plus all sorts of plugins), starting in college where IDEs weren’t particularly encouraged or necessary for small projects. I continued to use this setup professionally because it worked well enough and every IDE I tried for the main language I was using wasn’t great.

However, I eventually found IDEs that worked for the language(s) I needed and I don’t have any interest in going back to a minimalistic (vim or otherwise) setup again. It’s not that the IDE does things that can’t be done with vim generally, but having a tool that understands the code, environment, and provides useful tooling is invaluable to me. I find being able to do things with some automation (like renaming or refactoring) is so much safer, faster, and enjoyable than doing it by hand.

Features I look for/use most often:

• Go to (both definition and usages)
• Refactor tooling (renaming, inlining, extracting, etc).
• Good warnings, along with suggested solutions. Being able to apply solution is a plus.
• Framework integrations
• User-friendly debugger. Ability to pause, drill in, and interact with data is immensely helpful with the type of applications I work on.
• Configurable breakpoints.
• Build tool integrations. Doing it on the console is… fine… but being able to set up what I need easily in the IDE is preferable.

Features I don’t use or care so much about? Is there much left?

• My IDE can hook up to a database. I’ve tried it a few times, but it never seemed particularly useful for the apps I work on.
• git integration. I have a separate set of tools I normally work with. The ones in my IDE are fine, but I usually use others.
• Profiler. I use it on occasion, but only a few times a year probably.

I do code in non-IDE environments from time to time, but this is almost always because of a lack of tooling than anything else. (Like PICO-8 development)