Blorp Language
blorp-lang.org
blorp-lang.org
We want languages that encourage good design.
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.
https://github.com/roc-lang/roc/blob/b2503210da6b58a4ce1254d...
Marketing.
Instead of reading the code littered with "impure" keywords, you look at the beautiful code marked as "pure".
But there can be many (small) applications where pure doesn't even matter, so I don't really want to force someone to write "impure" for the main function, for example.
And I don't quite understand the memory model, is it something similar to Rust?
The move away from indentation in programing came as a rebellion against the too-constraining fixed column languages, in the interval between punched cards and python, with a brief resurgence in the early blink tag and font potpourri web era. These days, it's perfectly reasonable.
IME, it requires less work. You just grab the piece of code you want, whereas with braces, you need to count which closing brace is the correct one.
I can't believe that the claim "python-style syntax is perfectly reasonable" deserves to be down-voted into the basement.
We ferment wine or beer in a different vessel with different airlock, so it does not blorp. We don't have a word for that yet.
The crock we used that birthed this word is this one:
https://www.lehmans.com/product/striped-european-style-ferme...
I find it difficult to believe that a noise assigned to the preparation of kimchi would be so flagrantly incompatible with the Korean language.
I'm sure people who come by their kimchi-making through their family or culture natively probably have words that work better for them that I would stumble over and mangle is truly epic fashion :-)
This, to circumvent copy/paste issues.
I remember the creators of Go explained [1] that they chose explicit block delimiters because of problems they saw when embedding snippets of Python in other languages. But this seems like a very niche kind of problem.
[1]: https://go.dev/talks/2012/splash.article#:~:text=we%20have%2...
Perhaps it's just one point from me - not liking chaining :D
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
At least for me,
thing
.doThis()
.thenDoThat()
.andFinallyThis()
andFinallyThis(
thenDoThat(
doThis(thing)
)
)``` thing.doThis() thing.thenDoThat() thing.andFinallyThis()
// or
doThis(thing) thenDoThat(thing) andFinallyThis(thing) ```
Of course, blorp also allows local mutation in loops (even in pure functions, so long as the logic is contained to the function), so if there's a specific algorithm you'd rather express in a loop, you can.
For example, a typical web service I work on:
- uses JSON APIs
- it's fully stateless (uses external DBs/caches for persistence)
- has the concepts of value objects, entities, architectural layers (app, domain, infra), ports/adapters etc.
- only entities are proper rich objects, while most of the code is stateless services that operate on requests + entities + value objects
- stateless services are composed (via interfaces) into a dependency tree (stored in the dependency container)
module my_service
layer app {
service Adder { // stateless service
uses base int // a value-based dependency, injected in the container below
method add(x int) int {
return base + x
}
}
service Doubler {
uses a Adder // delegates to another service
method double(x int) int {
return a.add(x) + a.add(x)
}
}
}
container { // dependency container construction with injections
A = Adder { base: 10 }
D = Doubler { a: A }
}
// automatically generates a web server that exposes a JSON API with method "double" and accepts the "n" argument
endpoint double(n int) int {
return D.double(n)
}
What do you think? Does it make sense? It basically moves something usually implemented by a framework into the language, but that's the entire point: a language optimized for writing compact, architecturally safe stateless services in a few lines of code. For example, since we know a request's memory is bound to that request (no global state), we can have very optimized memory management without a full GC => improved latency. Or for example, we can have compile-time checks for things like dependency direction validation (i.e. the domain layer cannot reference the infrastructure layer) to keep the architecture clean, etc.
As for your concept, I think this is super interesting. A language catered towards higher level abstractions that we use for web services these days is very appealing. The service and container constructs are particularly enticing.
It seems like your goal is to make things more declarative / readable.
Creating a language is a pretty large undertaking, and unless you need to do it to achieve your goals, I wouldn't recommend it - unless you really just want to see what it's all about and make one.
Almost all "new" languages presented on HN are basically slightly different flavours of languages that have been around for a very long time. But without the libraries/documentation/tools etc. needed to make it useful.
This is in the very first example you see on the site. If it's a mistake, that's not encouraging. If this is actually how the language works, that's even less encouraging -- the syntax highlighter doesn't even get it right!
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.
But I love Ruby to death, and it is definitely the desire to make it as close to Ruby spiritually as possible.
Looks somewhat Python-like but modernised (great!) - is it indentation sensitive?
There's a lot of other differences -- it's a smaller language surface than Python overall.
I was trying to find if it is definitely a significant whitespace syntax, as it appears to be
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 wonder who came up with this idea first. I find obvious early returns incredibly ergonomic.
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.
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.