←back to thread

498 points azhenley | 1 comments | | HN request time: 0s | source
Show context
munchler ◴[] No.45767832[source]
> Making almost every variable const at initialization is good practice. I wish it was the default, and mutable was a keyword.

It's funny how functional programming is slowly becoming the best practice for modern code (pure functions, no side-effects), yet functional programming languages are still considered fringe tech for some reason.

If you want a language where const is the default and mutable is a keyword, try F# for starters. I switched and never looked back.

replies(19): >>45767880 #>>45767882 #>>45767891 #>>45767892 #>>45767898 #>>45767926 #>>45767975 #>>45767989 #>>45768118 #>>45768188 #>>45768230 #>>45769840 #>>45769875 #>>45770104 #>>45770306 #>>45771134 #>>45771926 #>>45772136 #>>45775848 #
tasn ◴[] No.45767898[source]
Functional programming languages (almost always?) come with the baggage of foreign looking syntax. Additionally, imperative is easier in some situations, so having that escape hatch is great.

I think that's why we're seeing a lot of what you're describing. E.g. with Rust you end up writing mostly functional code with a bit of imperative mixed in.

Additional, most software is not pure (human input, disk, network, etc), so a pure first approach ends up being weird for many people.

At least based on my experience.

replies(7): >>45767931 #>>45768098 #>>45768136 #>>45769309 #>>45770165 #>>45771129 #>>45772143 #
rapind ◴[] No.45768098[source]
> come with the baggage of foreign looking syntax

Maybe they're right about the syntax too though? :)

replies(1): >>45768148 #
kragen ◴[] No.45768148[source]
Which one, Erlang, Lisp, or ML?
replies(3): >>45768958 #>>45770119 #>>45771398 #
tmtvl ◴[] No.45770119[source]
Lisp syntax is objectively superior because you can write a predicate like thus:

  (< lower-bound x-coordinate upper-bound)
Instead of having to do the awful ampersand dance.
replies(1): >>45773270 #
1. kragen ◴[] No.45773270[source]
In Python or Icon (or Unicon) that's

    lower_bound < x_coordinate < upper_bound
except that usually you want

    lower_bound <= x_coordinate < upper_bound
which is also legal.

In Python this is a magical special case, but in Icon/Unicon it falls out somewhat naturally from the language semantics; comparisons don't return Boolean values, but rather fail (returning no value) or succeed (returning a usually unused value which is chosen to be, IIRC, the right-hand operand).

And in SQL you have

    `x-coordinate` between `lower-bound` - 1 and `upper-bound` + 1
which is obviously the best possible syntax.