Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Janet Language

janet-lang.org

Post reply on HN
Print view View original

171–180 of 203 posts

Re: The Janet Language

#171

Post by xigoi »

injidup wrote: post #156
jb1991 wrote: post #100

Earlier quoted context omitted.

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…

You said "requires" hashing. Sets and Maps do not require hashing. Through it is correct to observe the unfortunate naming convention in the c++ std lib. 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 ma…

> But they are both map and set structures just each version has other guarantees that in some scenarios may be more or less useful.

And similarly, linked lists and arrays are just different "versions” of the same data structure: a list.

Re: The Janet Language

#172

Post by weavie »

ianthehenry wrote: post #9

Oh 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…

Is there somewhere I can keep up to date with books progress?

Re: The Janet Language

#173

Post by masklinn »

SyrupThinker wrote: post #154
masklinn wrote: post #103

Earlier quoted context omitted.

> 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…

Thanks for clarifying, I did not find anything decisive searching persistent in combination with Clojure, weird. > 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.

> As someone with a background in Swift, Rust and C#, all of which have the concept of a tuple

They all have tuples, but AFAIK in none of them is a tuple a sequence (well not sure about C# it might be there, but I'd be surprised). Usually a tuple is a form of lightweight, anonymous, structure, so it's addressed by field (even if the fields are positions), you usually can't iterate through tuples, or "index" them using runtime variables (except through reflection).

That it is so in Python is somewhat peculiar, but makes sense within the context of the language (unpacking works on iterables, and thus sequences).

Re: The Janet Language

#174

Post by jdrek1 »

camdez wrote: post #159
sergiotapia wrote: post #129

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

I certainly don't fault you for having that reaction, but I would encourage you to look deeper and not dismiss one of the most interesting families of programming languages on the basis that it looks weird. Far from atrophying your skills in other languages, many people say that learning Lisp makes them better programmers even when they're coding in other languages. Lisps don't arbitrarily look weird—there's a deep,…

That example is quite unfair. You could just write

  println(is_me ? "me" : "you")
which has exactly the same amount of symbols.

Re: The Janet Language

#175

Post by seanstrom »

tremon wrote: post #153
mypetocean wrote: post #142

Earlier quoted context omitted.

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]…

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. 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 e…

Not a lisp apologist haha, but I think Clojure tries to use fewer smooth parens “()” in general. Square parens “[]” and curly parens “{}” are used to help with things like variable declarations and stuff like data structures.

I recently started using Clojure and I’ve used languages like C#, JavaScript, and Python a lot. My two cents is that a Clojure-like language should try to embrace the aesthetics of a white-space language like Python, but use the parens as clues for scopes or blocks. So much could be done with formatting rules that just make parens easier to scan without some extra IDE highlighting or something.

The best part of parens is that you can try to pick a consistent format, but ya know that sometimes doesn’t happen because everybody likes to use parens differently lol.

Re: The Janet Language

#176

Post by epgui »

gus_massa wrote: post #81
klyrs wrote: post #23

Earlier quoted context omitted.

Pro-tip: move every open-paren to the right of its first enclosed token.

It also help to move each closing paren to it's own line, so instead of ))) it looks like ) ) ) It's almost the same number of parens, just a different formatting.

Please don’t do this… There’s plugins for working effectively with lisps. You probably just need the rainbow parens or better contextual highlighting.

Re: The Janet Language

#178

Post by otabdeveloper4 »

drdec wrote: post #117
otabdeveloper4 wrote: post #110

Earlier quoted context omitted.

If by "list" you mean "linked list", then those are never used in practice. There is no place for this data structure in a modern CS toolbox.

The people behind the Elixir programming language certainly disagree.

Maybe that's why Elixir never gained real traction.

Re: The Janet Language

#179

Post by otabdeveloper4 »

mtlmtlmtlmtl wrote: post #123
otabdeveloper4 wrote: post #110

Earlier quoted context omitted.

If by "list" you mean "linked list", then those are never used in practice. There is no place for this data structure in a modern CS toolbox.

That's a ridiculous statement. Linked lists have real performance benefits in some applications. A good "modern CS toolbox" includes the ability to make the right choice. Which, if you believe they are fundamentally useless, clearly you lack.

> Linked lists have real performance benefits in some applications.

Maybe in 0.01% of the cases. In reality they just ruin your cache and memory allocator performance for no real good reason.

Re: The Janet Language

#180

Post by mirekrusin »

xigoi wrote: post #171
injidup wrote: post #156

Earlier quoted context omitted.

You said "requires" hashing. Sets and Maps do not require hashing. Through it is correct to observe the unfortunate naming convention in the c++ std lib. 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 ma…

> But they are both map and set structures just each version has other guarantees that in some scenarios may be more or less useful. And similarly, linked lists and arrays are just different "versions” of the same data structure: a list.

Let's simplify it even more - everything is just ones and zeroes.
Post reply on HN