Readable syntax with mandatory indentation is a very questionable idea. For me its easier to understand that something ends with a specific designation, not with a lack of it. Indentation should be solved by formatter and not the language.<p>And I don't quite understand the memory model, is it something similar to Rust?
Why is `pure` a keyword that needs to be added, with impure being the default? This discourages programmers from marking functions as pure. I like how Nim does it, with `func` declaring a function (pure) and `proc` declaring a procedure (impure).
I would also recommend this default.<p>We want languages that encourage good design.<p>If your goal is - like Crystal - to be as pain free of a migration from Python to Blorp, this shouldn't really impact it, since the compiler can and should be able to auto-fix this.
Interesting. there are some parts i like a lot here, but two things that I really dislike syntax wise. One is the lean towards a chainable syntax - this has proven to a big footgun for many devs in both java streams and typescript, making it very easy to go from O(n) to O(2n). The other part i really dislike is the first argument principle noted. If i myself define `string_and_reverse` and I can call it both through `string_and_reverse(42)` and `42.string_and_reverse()` i could definitely see this leading to some very funky looking chaining.<p>Perhaps it's just one point from me - not liking chaining :D
I know there are people that are used to the indention based scope but that has a real problem when it comes to copy/pasting code. I think a alternative that still looks pretty clean is to do like Ruby and Julia and have the function/class imply begin and have a literal 'end'.
Fun fact, in Python, the indentation is checked per block. So, in the outer block, indentation can be 2 spaces, while in the inner block, the indentation is 3 spaces. The only prerequisite is that the indentation in the block is the same.<p>This, to circumvent copy/paste issues.
If your editor messes up indentation when copy-pasting, you need a better editor.
I like it. Reminds me of ruby. maybe a more verbose/explicit go? cool stuff!
You might like this language I've been working on: <a href="https://GitHub.com/Cuzzo/clear" rel="nofollow">https://GitHub.com/Cuzzo/clear</a><p>It's not as true to Ruby as Crystal is, because I aim to make it far safer. It's closer to Elixir, if anything.<p>But I <i>love</i> Ruby to death, and it is definitely the desire to make it as close to Ruby spiritually as possible.
Feels like CoffeeScript for C, in the best way
Is it just me that doesnt like automatically returning the last statement in functions? It makes it hard to see where a function returns, and I dont see how you would do a guard clause at the start of a function without having the entire rest of the function in an else block
I remember really bumping up against this learning OCaml in college after having experienced oodles of imperative programming.<p>I understand the sort of philosophy and ergonomics of not having an early return, but it really does hurt certain kinds of code that otherwise would be more readable
I suspect the idea would be to use `match` instead of an imperative `if`. There's an example here:<p><a href="https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/sleep_fanout.brp#L8" rel="nofollow">https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/...</a><p>Then again, there's really not too many examples of early return guards, but I did manage to find one where the body is stuffed in an `else`:<p><a href="https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/binary_trees.brp#L16" rel="nofollow">https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/...</a><p>It does make me think that the usual types of guards might typically happen higher up (handled by the caller) or hidden with safe / monadic type operators that simply pass through rather than bailing out, so to speak.
I think it is much more obvious than being able to return from anywhere in a function. If the last expression is a match, I know every match body must return the same type. if the last is a (cond ...) I know ever cond branch must return a value. I vastly prefer that.
If it's inconsistently applied, yes.<p>In most functional languages however you can view the end of any statement/expression as a return/assign which makes it very easy and trivial to assign anything to variables, or split anything into function calls.
[dead]