[dead]
Then either n is a constant and it's really O(1), or k isn't a constant and its naming was in violation of the International Conventions on Naming Things to Avoid Silly Arguments, section 3, paragraph IV.7 & ff.
Blorp Language
31–40 of 67 posts
Re: Blorp Language
#32Interesting. 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…
> i could definitely see this leading to some very funky looking chaining. At least for me, thing .doThis() .thenDoThat() .andFinallyThis() is much more readable than andFinallyThis( thenDoThat( doThis(thing) ) )
Well, nesting is not the only option.
``` thing.doThis() thing.thenDoThat() thing.andFinallyThis()
// or
doThis(thing) thenDoThat(thing) andFinallyThis(thing) ```
Re: Blorp Language
#33"Blorp" is the notional noise of kimchi or sauerkraut fermenting as the carbon dioxide escapes the airlock. Vigorous fermentation can be described as "the kimchi is really blorping along today". It's almost onomatopoetic, but not quite. 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: ht…
> "Blorp" is the notional noise of kimchi or sauerkraut fermenting as the carbon dioxide escapes the airlock. Vigorous fermentation can be described as "the kimchi is really blorping along today".
I find it difficult to believe that a noise assigned to the preparation of kimchi would be so flagrantly incompatible with the Korean language.
Re: Blorp Language
#34I applaud the effort, but every time there's a new hobbyist programming language on HN, almost always it's something I've already seen in countless other hobbyist languages, just a slight variation of it based on the author's personal tastes. It doesn't tell me why I should adopt it over language X. What I'd like to see is exploration of novel practical ideas that would make certain types of projects much faster to w…
I like these hobby languages just because they help expose and experiment with interesting higher level language constructs. Because of that, I don't really care if they try to sell me on the language or not.
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.
Re: Blorp Language
#35[flagged]
Re: Blorp Language
#36Earlier quoted context omitted.
Wikipedia says that "guard clause" was a term invented by Kent Beck, but that the actual practice was used since at least the early 60s
No, I meant the idea that guard clauses are antipatterns and your subroutine should have a single implicit return.
Sorry, I misread. Need more coffee
Re: Blorp Language
#37"Blorp" is the notional noise of kimchi or sauerkraut fermenting as the carbon dioxide escapes the airlock. Vigorous fermentation can be described as "the kimchi is really blorping along today". It's almost onomatopoetic, but not quite. 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: ht…
> "Blorp" is the notional noise of kimchi or sauerkraut fermenting as the carbon dioxide escapes the airlock. Vigorous fermentation can be described as "the kimchi is really blorping along today". 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 a basically monolingual white guy from the Midwest USA, transplanted to Vermont. I discovered kimchi in a restaurant and learned to make it from the internet[0].
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 :-)
Re: Blorp Language
#38It looks nice. The general syntax isn't explained AFAICT?
Looks somewhat Python-like but modernised (great!) - is it indentation sensitive?
Re: Blorp Language
#39I 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'.
I don't understand this concern. How exactly are you copy/pasting code such that significant indentation causes "real problems"?
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...
Re: Blorp Language
#40Earlier quoted context omitted.
> i could definitely see this leading to some very funky looking chaining. At least for me, thing .doThis() .thenDoThat() .andFinallyThis() is much more readable than andFinallyThis( thenDoThat( doThis(thing) ) )
Well, nesting is not the only option. ``` thing.doThis() thing.thenDoThat() thing.andFinallyThis() // or doThis(thing) thenDoThat(thing) andFinallyThis(thing) ```
That’s not equivalent.