FilterHN

Blorp Language

34 points

by croottree

5 hours ago

| past

| 6 comments

| blorp-lang.org

| HN

▲

xigoi

2 minutes ago

[-]

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).

▲

bobajeff

23 minutes ago

[-]

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'.

▲

xigoi

30 seconds ago

[-]

If your editor messes up indentation when copy-pasting, you need a better editor.

▲

lekevicius

9 minutes ago

[-]

Feels like CoffeeScript for C, in the best way

▲

cupofjoakim

1 hour ago

[-]

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.

Perhaps it's just one point from me - not liking chaining :D

▲

KolmogorovComp

1 hour ago

[-]

> making it very easy to go from O(n) to O(2n)

Strictly speaking I assume everyone knows O(n) = O(2n) =O(kn) for k in R.

But I see your point. I assume any decent compiler would merge the loops though

▲

cupofjoakim

22 minutes ago

[-]

Fair! That'd depend on the operations right? For example, AFAIK typescript can't do much about multiple chained `map` calls, and i've seen quite a few `.filter(...).map(...).filter(Boolean).map(...)` :/

▲

c0balt

2 minutes ago

[-]

To be fair this likely should be handled by the interpreter/compiler for the compiled JS. V8 probably can merge this into one loop or another similar based on runtime types

▲

ramon156

16 minutes ago

[-]

I like it. Reminds me of ruby. maybe a more verbose/explicit go? cool stuff!

▲

voidUpdate

2 hours ago

[-]

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

▲

rtpg

2 hours ago

[-]

I remember really bumping up against this learning OCaml in college after having experienced oodles of imperative programming.

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

▲

zdragnar

1 hour ago

[-]

I suspect the idea would be to use `match` instead of an imperative `if`. There's an example here:

https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/...

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`:

https://github.com/kablorp/blorp/blob/main/benchmarks/blorp/...

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.

▲

bjoli

1 hour ago

[-]

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.

▲

troupo

1 hour ago

[-]

If it's inconsistently applied, yes.

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.