Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell which are covered in "Seven Languages in Seven Weeks" are quite nice for start.

Can also recommend the followup "Seven More Languages in Seven Weeks" [1] which covers: Lua, Factor, Elixir, Elm, Julia, MiniKanren, and Idris

[1] https://pragprog.com/titles/7lang/seven-more-languages-in-se...

> "Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell"

Do they offer any meaningful differences to an otherwise "mainstream" language - anything beyond syntax, tooling ecosystem and the usual functional vs. procedural vs. OOP paradigms?

Anything I can't just whip up in modern C#, C++, Java or Python if I wanted to constrain myself to a specific subset of features or a specific paradigm?

I get the "it's fun to try something new every once in a while" part but people tend to forget that the distinctions between programming languages have blurred significantly over the last 10+ years.

In the case of Erlang the answer to your question about meaningful differences is: oh yes! I could list more, but there are two:

- support for concurrency. After tasting it you never will want to go back to techniques normally used in the languages you listed

- data immutability, which makes reading code so much easier.

Yes, there are plenty of meaningful differences. It's true most mainstream languages in industry are essentially syntax swaps of each other, but Prolog and Haskell are not that at all.

Imagine if you could run a Python function backwards and feed something into the return value and have Python tell you the parameters to match. That's the uncomon, twisty difference of Prolog relations. In Python a test whether this combination of length and area makes a valid square:

    def test_square(side_length, area):
        return (side_length ** 2) == area

which says imperatively "square the side length and compare it to the area, return the result" becomes a Prolog relation:

    :-use_module(library(clpfd)).

    square_side_area(X, A) :-
        X #> 0,
        X*X #= A.

which says declaratively "square_side_area holds for X and A if X is positive and X squared equals A". This can be used in the same way as the Python code to ask "does length 5 and area 25 make a valid square, yes/no?" but it can also be queried to find: "given length X 5, can this relation hold?" and it answers yes, if A=25. Or "given area 25, can this hold?" and it answers "yes, when X is 5". Or "are there any solutions?":

    ?- square_side_area(5,25).
    true.

    ?- square_side_area(5,AREA).
    AREA = 25.

    ?- square_side_area(SIDE,25).
    SIDE = 5.

    ?- square_side_area(SIDE, AREA).
    SIDE in 1..sup,
    SIDE^2#=AREA,
    AREA in 1..sup.

Then, unlike the Python, you can combine this with extra conditions outside e.g. "(that), and AREA is between 1 and 25" and have it show all the possible answers in that range:

    ?- square_side_area(SIDE, AREA), AREA in 1..25, label([SIDE,AREA]).
    SIDE = AREA, AREA = 1 ;

    SIDE = 2,
    AREA = 4 ;

    SIDE = 3,
    AREA = 9 ;

    SIDE = 4,
    AREA = 16 ;

    SIDE = 5,
    AREA = 25.

If you can spare 30 minutes for a video, this Sudoku Solver in Prolog[1] shows quite well this style of thinking and its consequences. As you watch it, wonder what you might write in C# to solve sudoku (and how much code), and notice here what there is in the way of variables, loops, recursion, indexing, control flow, etc. This kind of thing "I give the constraints to a combinatorial problem, through constraint propagation find some valid solutions" is one of Prolog's strengths.

It isn't /only/ a built in brute-force search, or a "do everything with recursion" computer science lesson timewaster.

[1] https://www.youtube.com/watch?v=5KUdEZTu06o

Haskell's laziness gets you all sorts of control flow that is awkward in or missing from most languages. So I think it's worth checking out.

Well, Prolog for one seems very different. In functional/procedural/OOP you have to write a program describing every step of the way. In Prolog you just have to describe the destination.

The APL/J/BQN family of array languages, or Prolog & other Horn clause languages. Both will change your idea of what’s expressible in a programming language.

I'm not a programmer/developer by trade but I do like writing scripts to make my job easier.

I'm looking into APL and Lisp type languages basically to expand my mind as up to now I've really only being using "traditional" type languages.

It's like starting from scratch again.

That's true for everybody, I think.

I find "thinking in lisp, then writing the program out in X" where X is whatever 'mundane' language seems most suitable to the task is often a very effective technique.

Array languages I've tried to learn repeatedly over the years and always ended up bouncing off, so have no opinion there except "personal aha moment not yet reached".

Besides Lisp, languages like Haskell and F# would probably fit. As would Forth and modern stack languages like Factor.

I'd add Smalltalk to the other odd list suggestions given.

Check ACPUL 1.0 pure programming language for mobiles. ACPUL have 99.5% common features.

No keywords, only 2 statements (if/while), no strings in code but bulitin i18n. Here is EBNF grammar https://github.com/d08ble/acpu/blob/master/acpul-EBNF-cocor/...

Here is demo project https://github.com/web3cryptowallet/Web3CryptoWallet

But powerful like LISP and I am building mobile OS, IDE and nocode environment with ACPUL https://twitter.com/acpustudio

Metamine - it seems to have been pulled from the internet by its creator, after having given some really cool demos.

What's weird: it allows a mix of declarative and imperative syntax in a style that seems like normal procedural programming. You have a "magical equals" that is actually reactive programming... if any of the terms change, ever, the result gets updated.

Here's a previous thread about it

https://news.ycombinator.com/item?id=27555940

Zig is one that’s been on my list for Paul's stated reason.

Is Zig weird though? I find it eminently pragmatic and a lot of the interest in it comes from people migrating from popular languages like C and C++ (not that C++ isn't itself pretty weird).

Zig uses explicit allocations everywhere (if you want to allocate something you need a reference to an allocator) which is pretty unique even for low-level languages (e.g. C, Rust)

From what I’ve seen, Zig has no built-in polymorphism features (no vtables/interfaces/traits), which is _pretty_ weird for a modern language in a good way.

That is just because it is new. If it survives it will end up with everything.

It has compile time programming designed to subsume those features. So eg a generic struct becomes instead a compile time function that takes a type and returns a struct

That is a wholly other set of language features, for a different purpose, and is thus no substitute.

Practical languages accumulate features to better address a multitude of common real-world problems. Toy languages don't. Sometimes a toy language is adopted and grown to practicality. People always complain about that.

“Adding everything” is definitely not a part of Zig’s philosophy.

https://github.com/ziglang/zig/issues/130#issuecomment-70601...

> However, at this point the plan is to not add an additional dynamic dispatch language feature.

Key phrase: "at this point".

Isn't that forecasting a trend with too few data points? The field is still young and changing.

Oh, I don’t think it is a trend. I rather see it as a curious phenomenon that makes one reflect on the trade offs we usually make when using polymorphism, and whether it’s worth all the time, not only in terms of performance, but also in terms of program architecture.

Interesting. What are the program architecture tradeoffs you are suggesting?

To be honest, I have zero experience programming with Zig. But I imagine programming with Zig would lead to more literal style and fewer, simpler abstractions (no IoC, no frameworks). That might be beneficial for certain kinds of focused-scope projects.

I see. They say you can solve every problem with an other indirection, and ad hoc polymorphism is an instance of that. But there are other ways to enable composition that are seldom reached for when your language makes that easy

Every problem, except those caused by too many indirections.

Each solution uses only a few language features. Different problems call for different subsets. Not using a feature on your favorite sort of problem says nothing about its value. "Ways to enable composition" poorly supported are reached for less. Poorly supporting one of them that has proven frequently useful does not improve a language.

> too few data points?

There have been rather a lot of languages. The field is approaching 70 years old, and still changing, but clear evolutionary processes are seen repeated in hundreds of languages living and dead. The ones that don't grow are the most reliably dead.

Zig is certainly not weird in the way that something like prolog or scheme are.

Assembly language for ARM or RISC-V. It will provide a better appreciation for what's going on under the hood.

You'll also see which high level languages fit (or don't fit) this underlying fundamental model which may help cut through the marketing fluff from their various proponents and provide an unpleasant appreciation of the performance costs of popular programming paradigms.

TLA+, AWK, jq are also interesting choices.

Any highly experimental language that is used only by a small group of programming language experts would fit the bill!

Sure! Just curious about what specific languages would fit this description.

For 'pg it's just an excuse to talk about Lisp.

The max I’ve seen in both categories is Brainfuck: https://en.wikipedia.org/wiki/Brainfuck