81–90 of 203 posts
line noise much? man, that example is not pretty
Pro-tip: move every open-paren to the right of its first enclosed token.
)))
it looks like
)
)
)
One 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…
> So, you start out with g(x) and then need to go all the way back and add f. That's one thing I will say after coming from Perl/PHP to Java, is that despite its verbosity and the uselessness of having to write .stream(), I much prefer Java's stream.map(...).filter(...) syntax over the more functional-style filter(map(list, ..), ..) syntax. The Java syntax reads left-to-right, which is the order you want when you're…
Of course, Ruby is a bit of a mixed bag, but for the applications where it fits, it can be very nice.
I think the language is unreadable. For me, the purpose of a programming language is to let a human talk to a machine. Show me (for instance) control flow for the example function on the home page. It just isn't making things easier
(f x) -- too many parentheses
f(x) -- PERFECT
Earlier quoted context omitted.
I'm pretty sure GP meant Closure, considering the language has matching immutable data structures for mutable ones [^1] and even its own (limited) version of EDN called JDN. It’s definitely also inspired by it. [^1]: https://janet-lang.org/docs/data_structures/index.html
> I'm pretty sure GP meant Closure Closure is not a language so hopefully not? > the language has matching immutable data structures for mutable ones [^1] Looking at the lingo being used, the extremely limited breadth of ABI, and the complexity they assert around "immutable" data structures, they're clearly imperative data structures you can't mutate rather than the persistent data structures you'd expect from a stro…
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 this sentiment comes from. Because of the initial comment? Basically any language nowadays has maps, sequences and byte strings. If I had to draw a similarity to Python it would be something along the lines of first-class generators.
I think the language is unreadable. For me, the purpose of a programming language is to let a human talk to a machine. Show me (for instance) control flow for the example function on the home page. It just isn't making things easier
For anyone who’s spent even a casual amount of time with S-Expressions, the example code is extremely readable. But if ALGOL-like code is your main source of experience, then Janet will look like executable line noise.
I think the language is unreadable. For me, the purpose of a programming language is to let a human talk to a machine. Show me (for instance) control flow for the example function on the home page. It just isn't making things easier
(defn sum3
"Solve the 3SUM problem in O(n^2) time."
[s]
(def tab @{})
(def solutions @{})
(def len (length s))
(for k 0 len
(put tab (s k) k))
(for i 0 len
(for j 0 len
(def k (get tab (- 0 (s i) (s j))))
(when (and k (not= k i) (not= k j) (not= i j))
(put solutions {i true j true k true} true))))
solutions)
def sum3(s) :
"""Solve the 3SUM problem in O(n^2) time."""
tab = {}
solutions = {}
l = len(s)
for k in range(0,l) :
tab[ s[k] ] = k
for i in range(0,l) :
for j in range(0,l) :
k = tab.get( -s[i]-s[j] )
if k and k != i and k != j and i != j :
solutions[ {i:True, j:True, k:True} ] = True
return solutions
In the example janet returns
(map keys (keys solutions))
But syntactically janet is not much worse(?).
The lisp style syntax is jarring
Honestly, to me it is unreadable. Defining function inside a function inside yet another function where you use a for loop kind of function. It requires a much different line of thinking to be applicable in the real world, which goes against historic human nature of following specific instructions, one instruction at a time.
If you're really interested, just try to get through that syntax once and you'll find that it's not that alien.
I think the language is unreadable. For me, the purpose of a programming language is to let a human talk to a machine. Show me (for instance) control flow for the example function on the home page. It just isn't making things easier
I guess: f x -- obscure and mathematical (f x) -- too many parentheses f(x) -- PERFECT
>> f(x) -- PERFECT
They have the same number of parentheses.
f(x) is probably something you have seen for the majority of your life as this is how math is taught.
This is really cool, surprised it has so few stars and I've never seen it talked about here. I like the LISPs but I've always thought not having a CPython type thing was a bit of a deal breaker for making it a go-to "primary" language that I would use everyday. I'm definitely going to try with Janet though.
> surprised it has so few stars and I've never seen it talked about here Why? It's a niche language in a dated syntax, with use cases already covered by other languages. You will downvote because you don't like that, but it doesn't make it less true.
Earlier quoted context omitted.
What data structure isn't just a list with extra steps?
…anything that requires hashing as a fundamental part of the guarantee. Which happens to be quite a lot of the structures most of us use every day. Sets, maps, etc.