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

61–70 of 203 posts

Re: The Janet Language

#61

Post by crabbone »

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 terminal length and terminal input being determined by when you press "Enter".

I like Lisp languages, and would take Scheme over Python for my job in a heartbeat, if I was allowed to. But, I think, that if we want interactive Shell-like programming, we really need to address the issues above in the language. Shell pipes are a good start, but they are quite restricted in what they can do and require xargs "extension". Some languages also have the "where" form, where arguments to a function can be elaborated after the function call.

If I was ever to design a language for interactive programming, I'd certainly try to have these two features in it.

Re: The Janet Language

#62

Post by jgrodziski »

There is also the jank language [0] that plays in similar fields.

> jank is a general-purpose programming language which embraces the interactive, value-oriented nature of Clojure as well as the desire for native compilation and minimal runtimes. jank is strongly compatible with Clojure.

[0]: https://jank-lang.org/

Re: The Janet Language

#63

Post by iLoveOncall »

jimbo9991 wrote: post #13

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.

Re: The Janet Language

#64

Post by [deleted] »

epgui wrote: post #16
spikyllama wrote: post #11

line noise much? man, that example is not pretty

If you're not used to working with lisps, your reaction is basically just unfamiliarity, and not actual discernment. Lisps are inarguably and objectively syntactically simpler than non-s-expression languages.

[deleted]

Re: The Janet Language

#65

Post by adrianmsmith »

crabbone wrote: post #61

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 thinking about code, and also as you say writing it. I think if I were creating a programming language I too would try to make stuff read left-to-right as much as possible.

Re: The Janet Language

#66

Post by twism »

crabbone wrote: post #61

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…

Maybe what you are looking for is threading https://stuartsierra.com/2018/07/06/threading-with-style

Re: The Janet Language

#68

Post by lispm »

crabbone wrote: post #61

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…

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.

Re: The Janet Language

#69

Post by ocimbote »

adrianmsmith wrote: post #65
crabbone wrote: post #61

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…

Aligning reading order with flow of actions is so important!

That's why I use and msybe tend to abuse the `->` and `->>` macros in Clojure and the pipe operator `|>` in Elixir.

Hopefully soon in JS as well, if I've read correctly.

Re: The Janet Language

#70

Post by mst »

adrianmsmith wrote: post #65
crabbone wrote: post #61

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…

It's notable that raku (previously known as perl6) lets you write things in either direction, if I remember correctly something like

  @source >>> map { ... } >>> grep { ... } >>> my @sink;
though note I'm typing from memory on my second coffee so I may have got that slightly wrong.

Plus of course there's many languages with a |> operator so you can do

  g(x) |> f
I also (the example is specialised for I/O but the implementation technique could trivially be borrowed for something that wasn't) implemented something sort of in this direction for perl once: http://p3rl.org/IO::Pipeline

I'm not convinced that left-to-right is -always- the best option and prefer having the choice of both, but I wouldn't be at all surprised if a survey of developers found that if they could only pick one they'd pick left-to-right, and while I'd find it hard to choose for myself alone I'd probably pick left-to-right on the basis that it'd likely make it easier to onboard people to any given codebase.

Post reply on HN