Any suggestions on which languages could fit this criteria?
Any suggestions on which languages could fit this criteria?
[1] https://pragprog.com/titles/7lang/seven-more-languages-in-se...
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.
- 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.
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.
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.
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".
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
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
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.
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.
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.
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.
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.