Earlier quoted context omitted.
You mean Python, not Clojure. A number of key underpinnings, such as (almost) exclusively immutable datastructures are missing from this language. It is more of a Python with a LISP syntax.
If anything it’s major inspirations seem to be Clojure and Lua. It has some of the affordances of the former in terms of semantics, but is stripped down and friendly like Lua. The use cases also seem to overlap with Lua, as a fast, embeddable scripting language that you can easily keep in your head (see docs). It seems to be simpler than Lua because it doesn’t complect arrays and dicts into tables, as arrays are a se…
The Janet Language
151–160 of 203 posts
Re: The Janet Language
#152Oh hey! Nice to see this on the front page here. I love Janet -- I've been using it for about year and a half, and it's now my go-to scripting language when I need something more powerful than bash, or when I want to hack on goofy little side project (some examples in my profile). Parsing expression grammars (think, like, declarative parser combinators?) are a really great feature for ad-hoc text parsing -- and nicer…
I went there, saw the Lisp syntax, and noped back out.
This is why I don't do any math I can't do on my fingers.
Parentheses are just too scary, and there's no way that parenthesis math junk actually has any useful ideas.
Re: The Janet Language
#153Earlier quoted context omitted.
Same reaction here... wow that is a rough looking language. Then again I always disliked those kinds of languages like Clojure. The syntax is just too much for me. I feel like if I used it, it would atrophy my skills in other more traditional languages.
The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. The opening paren is simply relocated to the other side of the function name or keyword. What we're experiencing is just a cognitive bias which causes us to prefer the more familiar over the less familiar ([the mere-exposure effect, also called the familiarity principle]…
This tired trope needs to die. Yes, there are more parentheses, because lisp also uses parentheses where other languages use [] or {} or ;.
The real thing is that people from C-like languages are used to seeing different block markers for different constructs. It takes effort to read Lisp coming from other languages, because those other languages have a richer symbol vocabulary. Learning to read code without those symbols is like reading English where all punctuation has been replaced with a single space. Sure you ll get there eventually but it s a very cheap straw man argument to pretend that the only complaint people have about Lisps is the positioning of the parentheses.
Re: The Janet Language
#154Earlier quoted context omitted.
> Closure is not a language so hopefully not? Very true, the typo is strong in this one. > rather than the persistent data structures you'd expect from a strong clj inspiration What do you mean by persistent here? I assume some kind of shared memory instead of copying? Or something with more practical implications like deep immutability? > looks a lot more like a description of Python datatypes I am surprised where t…
> What do you mean by persistent here? I mean the class of data structures called persistent: https://en.wikipedia.org/wiki/Persistent_data_structure > I assume some kind of shared memory instead of copying? Sure. > I am surprised where this sentiment comes from. Because of the initial comment? Because "tuple" for an immutable sequence is rather specific to Python. And data structures related to clojure (or functiona…
> Because "tuple" for an immutable sequence is rather specific to Python.
As someone with a background in Swift, Rust and C#, all of which have the concept of a tuple, I did not make that connection, but thanks again.
Re: The Janet Language
#155Earlier quoted context omitted.
Same reaction here... wow that is a rough looking language. Then again I always disliked those kinds of languages like Clojure. The syntax is just too much for me. I feel like if I used it, it would atrophy my skills in other more traditional languages.
The funny thing is that it's _not_ more parentheses, roughly, than one would expect to find in any Algol/C-inspired language, like C# or JavaScript. The opening paren is simply relocated to the other side of the function name or keyword. What we're experiencing is just a cognitive bias which causes us to prefer the more familiar over the less familiar ([the mere-exposure effect, also called the familiarity principle]…
Re: The Janet Language
#156Earlier quoted context omitted.
Sets and maps do not required hashing. Specifically std::map and std::set in the C++ standard library are based on ordered trees.
They’re often called “hash sets” or “hash maps” in other languages - they are called this for a reason, and certainly not because they could be implemented as a list. std::map is not a good example anyway, you want to consider std::unordered_map for a more appropriate comparison. C++ is weird that way. (What C++ calls a map is not what most languages call a map. std::map doesn’t even satisfy O(1). You’d be surprised…
std::set and std::map should be std::ordered_set and std::ordered_map sts::unordered_set and std::unordered_map should be std::hash_set and std::hash_map
If this were so then it might make the incorrect usage of these two options less prevalent. But they are both map and set structures just each version has other guarantees that in some scenarios may be more or less useful.
Re: The Janet Language
#157Earlier quoted context omitted.
One thing the Python version doesn't suffer from is lines that have to end in something like "))))". Syntax readability may be subjective, and I agree that the business logic in both examples are equally readable, but I think having to read and write a bunch of repeated punctuation at the end of a line, depending on how deeply the final statement is nested, is annoying. I don't know how Janet in particular handles er…
This is kind of unfair, unless you're in an indent based language you cannot get rid of this. The only other solution I've seen was in a pascal-like language, where you did end function NAME and that would close everything inside.
Re: The Janet Language
#158Earlier quoted context omitted.
One thing the Python version doesn't suffer from is lines that have to end in something like "))))". Syntax readability may be subjective, and I agree that the business logic in both examples are equally readable, but I think having to read and write a bunch of repeated punctuation at the end of a line, depending on how deeply the final statement is nested, is annoying. I don't know how Janet in particular handles er…
You don't HAVE to write lines that way, though it is the convention which as a mostly outsider I've never been a huge fan of. Think about languages like c# where you often have multiple closing curly braces but the convention is separate lines. You could write them like Lisp if you wanted but no one does.
Re: The Janet Language
#159Earlier quoted context omitted.
I went there, saw the Lisp syntax, and noped back out.
Same reaction here... wow that is a rough looking language. Then again I always disliked those kinds of languages like Clojure. The syntax is just too much for me. I feel like if I used it, it would atrophy my skills in other more traditional languages.
Lisps don't arbitrarily look weird—there's a deep, principled, elegant reason for it; Lisp code represents how the code will be evaluated in the most direct way, without relying on (some would say needlessly) complex parsing / precedence rules. There are no surprises and no arbitrary rules to learn. There are no useless semicolons to forget, and you'll never have to wonder if `+=` returns the RHS or the result of the operation (or does it even have a return value?).
You don't have this meaningless distinction where you can't directly reduce with `+` because—ugh—it's not a function, it's an operator. You just say `(reduce + [1 2 3])`.
You never have to do this ugly Ruby stuff...
words.map &:length
# or
words.map { |w| w.length }
...because methods are really just polymorphic functions, but language designers chose syntax that doesn't compose elegantly.You don't have this useless distinction between statements and expressions that limits how you can compose code. You never have to drop down to some ugly, limited tertiary expression form (`COND ? X : Y`) of `if` because—whoops—`if` is a "statement". You just write:
(println (if me? "me" "you"))
Because, duh, we wanted an `if`.What do we gain by adding all of this noise?:
if (is_me) {
println("me");
} else {
println("you");
}
Absolutely nothing. The parens on the conditional, the curly braces, the semicolons, the `else` keyword—they're essentially meaningless incantations to appease the compiler. And we've introduced an undesirable opportunity for the two branches to accidentally diverge over time.But most importantly, our code is written in the data structures of our language. Code as data means we can manipulate code as easily as we manipulate data, which means we can trivially (re-)write code with code (i.e. macros). And not shitty string generating macros, or macros that can only do a handful of sanctioned things—we can write our own control structures in couple lines of code. We can add new abstractions to the programming language from user space.
Wish the language had an `if-not` construct? You can add it with, like, 3 lines of code. Wish functions could have optional parameters? Add it. Wish it had a pattern matching functions like SML or Erlang? Cool. Java-style annotations? Logging that is fully removed when running in high performance mode? A different OO model? Multi-line string literals? String interpolation? A graph of dependent calculations that only get run when used? A more convenient way to load dependencies? It's all easily doable.
I've coded in Lisps (and a dozen other languages) for at least 20 years, and every time I have to use a non-Lisp syntax I just think "wow, these people really missed the boat". It's like having to write math in Roman numerals (would you rather calculate "D + L + IX" or "500 + 50 + 9"?); there's a better way, and that better way has elegant, recursive, underlying design principles that make the ergonomics way better.
But, yeah, it doesn't look like C code. And people seem to be really attached to their C syntax.
Re: The Janet Language
#160One thing that bothers me about languages that compose functions like this f(g(x)) is that when programming interactively f is typically an afterthought. So, you start out with g(x) and then need to go all the way back and add f . Similarly, when x turns out like it needs to be elaborated, and you either have to go all the way back, or edit the expression in place making it longer and inevitably facing problems with…
The 'terminal' restriction is long gone. Most Lisp read-eval-print-loops run inside an editor or another specialized tool. In Common Lisp: CL-USER 37 > (sin 3) 0.14112 CL-USER 38 > (cos *) 0.9900591 Above really is (cos (sin 3)). The variable * is bound to the last result.
When used interactively, Python also has _ to store the previous value (but Python only ever really returns single value, which is sometimes a tuple or a list that can be deconstructed into variables, iirc in CL if you don't request other return values, they are gone.)
More generally, you'd want more of xargs-like functionality (eg. split result into chunks and feed them to the next function in chunks, perhaps in parallel). Or maybe you'd want something like a tee, to split the results of the previous function into multiple streams and processed by different functions? Java-like languages don't immediately support something like that, but Shell-like do with redirection syntax, tee, xargs.