What simple things annoy you about your favourite programming languages?

Every language has nuances. Sometimes they can be ignored, other times they get in the way, yet other times they lead to defects. Most disturbing are simple things that are missing, something that exists in another language, or something that seems like it'd be easy to implement. Perhaps it's just a minor syntax flaw, ambiguity, or library limitation.

What are the simple things in your favourite languages that give you grief on a regular basis?

Comments

[Doshirae]

The package manager in Elixir.
You have to fire up the full mix stuff to install any dependency, so that bother's me when I want to write a simple little script like I would in Ruby. Ruby has "gem install" + "require" and let's go, but Elixir hasn't :(

[Børge André Jensen]

Yeah, the Clojure error messages are indeed horrible. I've spent an insane amount of time trying to figure out what's wrong because of typos like passing a list instead of an anonymous function.

Still, it's the language I like the most :D

[Stefan Dorresteijn]

That it (Ruby on rails) is hardly viable for large projects that require real time communication anymore.

[Olivier “Ölbaum” Scherler]

PHP: was designed with the same level of consistency as The Lord of the Rings was
Translated into French: by at least four different people with different goals and who never talked to each other.

Ruby: gloats about Duck Typing as a revolutionary way of solving the problems of untyped languages, but you spend the first 2/3rds of every function validating your arguments just like in PHP or JS, only with different syntax.

Python: the amount of boilerplate needs once
your simple script starts to become long enough that it has to be split into modules.

JavaScript: The lack of any hint of a standard library (to format dates, for example), and the misplaced efforts to add more and more silly syntax before solving this problem.

To be continued…

[edA‑qa mort‑ora‑y]

I agree with both statements. Dynamic languages are really great ways to quickly get something working and be productive. However, the moment that start exceeding a few thousands lines they become increasingly difficult to refactor.

In Leaf I've made optional one of the fundamental type qualifiers.

[Kasey Speakman]

Using both Elm and F#. Here are a few things that irk me.

• Hazardous generics
  Elm : Result SomeErrorType SomeType
  F# : Result<SomeType, SomeErrorType> - The sharp angles cut me

• Elm union types do not allow an optional leading |, which makes the first one a pain to copy/paste, diff, etc. (Maybe implemented soon.)
  

    -- Elm
    type SomeUnion
        = FooCase -- merge conflict waiting to happen
        | BarCase

    // F#
    type SomeUnion =
        | FooCase
        | BarCase

• F# let syntax is nicer to use. Elm let statements require an in clause whereas it is optional/implicit in F#. Additionally, elm-format always expands let statements to multi-line. The visually-enormous resulting code leads you to want to avoid let in Elm.

    -- Elm
    let
        asdf =
            oneLiner x

        fdsa =
            anotherOneLiner y

    in
        f asdf fdsa

    // F# - easier to read IMO
    let asdf = oneLiner x
    let fdsa = anotherOneLiner y
    f asdf fdsa

• Elm generates curried constructors for all record and union types. Curried constructors are great because they support partial application. F# does not, and the normal record construction syntax is quite verbose. I often create my own curried constructor for partial application.

    -- Elm
    type alias SomeType =
        { someInt : Int
        , someString : String
        , someFloat : Float
        }

    -- automatic curried constructor
    let x = SomeType 1 "foo" 3.14 in ...

    let list = List.map ( SomeType 1 "foo" ) [ 3.14, 2.718 ] in ...

    // F#
    type SomeType =
        { SomeInt : int
          SomeString : string
          SomeFloat : double
        }

    // make my own curried constructor
    let mkSomeType a b c =
        { SomeInt = a; SomeString = b; SomeFloat = c }

    let x = mkSomeType 1 "foo" 3.14

    let list = List.map ( mkSomeType 1 "foo" ) [ 3.14; 2.718 ]

Here is what the last two lines would look like in C#.

    var x = new SomeType(1, "foo", 3.14);

    var arr =
        new double[] { 3.14, 2.718 }
            .Select(x => new SomeType(1, "foo", x))
            .ToArray();

[Gerald Nash ⚡️]

I despise the fact that null is an object in JavaScript.

[Valentin Baca]

For what language?

[Palle]

In Swift, it's often annoying that you cannot have a variable of a generic protocol type. You need to have a generic type implementing that protocol because you cannot specify associated types when declaring a variable.

For example, Swift has a Collection protocol, which has an associated generic type Element.

Instead of declaring a variable with let foo: Collection<Int> = ... you need to have a generic variable C: Collection where C.Element == Int, which can be pretty annoying because your enclosing structures also need to be generic.

Example

struct Foo<C: Collection> where C.Element == Int {
    var bar: C
}

It would be so much more pleasant to write

struct Foo {
    var bar: Collection<Int>
}

Yes I am aware of the AnyCollection<Element> type but that is just a workaround that is specific to the collection protocol and not a general solution and yes I am aware that the Swift compiler always wants to specialize generics at compile time but this is just annoying.

[Connectety]

I really love Scala, but

1. The compiling time can be so long (example: the classical "Hello World!", Scala: 4420ms (Without fsc) Java: 107ms (as a comparison)
2. Values can be returned without return statement
3. parameters always become immutable

(also if you're programming half of the project in Java, "++" can confuse you, because it does different things in Java and Scala)

[edA‑qa mort‑ora‑y]

What don't you like about #2, that values can be returned without a return statement? Are they named returns in the function signature?

[Connectety]

You somtime accidentally return values (method type = unit (so you don't have to return null and can't get a nullPointException)) and sometimes it can take a while to understand that something gets return (like when a function does return true if it did what it should and that gets returned by another function)