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

Janet: a lightweight, expressive and modern Lisp

janet-lang.org

Post reply on HN
Print view View original

231–240 of 280 posts

Re: Janet: a lightweight, expressive and modern Lisp

#231

Post by HelloNurse »

zentiggr wrote: post #209
anonymoushn wrote: post #84

Earlier quoted context omitted.

Right, we improved the performance by moving the work out of the JVM. It's my fault that if you trade US equities based on old information you lose money? Edit: Actually, I'm still not sure how to correctly measure GC pauses, other than from inside the application.

I'm not sure I've ever heard of the JVM being used in trading level software before. I've gotten a broad but vague impression that custom applications are the norm. No criticism, as I've only read others' accounts, but that sounds out of character.

Java or Clojure applications are "custom" too: custom code running in some kind of application server is more or less the same as custom code relying on libraries and frameworks in C or C++ or other leaner languages.

What's "out of character" (nice euphemism!) is adopting state of the art automatic garbage collection technology, writing in a language that makes actual garbage collection practically unavoidable, and then expecting that garbage collection doesn't happen or happens accordingly to arbitrary expectations. The JVM is clearly inappropriate technology if latency is important: it can perform well in common cases and with a reasonable level of tuning effort, but other options simply do not have the threat of GC pauses.

Re: Janet: a lightweight, expressive and modern Lisp

#232

Post by andrewflnr »

jonathanstrange wrote: post #121
lispm wrote: post #39

Earlier quoted context omitted.

Is it really Lisp without 'lists'? https://janet-lang.org/api/index.html that does not mention list in meaningful ways. It seems to prefer to work with other data structures (like arrays) - which is okay, but then I won't call it a List Processor dialect.

I don't understand why somebody downvoted you, I've seen a number of languages that look like Lisp, but are based on vectors or arrays, and that changes the language drastically. So I'm wondering, too. I was trying to find out whether Janet programs are lists or something else like arrays, but didn't find it in the docs.

What are the most prominent examples? I tend to think that vectors are a better basis for a practical language.

Re: Janet: a lightweight, expressive and modern Lisp

#233

Post by Scarbutt »

pron wrote: post #60
varjag wrote: post #58

Earlier quoted context omitted.

It is state of the art in the same sense that America is the uncontested leader in WWE.

Is it? I've looked hard and couldn't find any runtime that isn't more than five years behind OpenJDK(+Graal) in those areas, but maybe I missed something. I'm not saying it's perfect, but there's nothing out there that's better in those areas.

You don't need Graal when you have Golang around the corner.

Re: Janet: a lightweight, expressive and modern Lisp

#234

Post by dkersten »

pjmlp wrote: post #70
dkersten wrote: post #52

Earlier quoted context omitted.

Clojure was never against any of the ideas in OO, just that they should be accessible individually if or when they make sense. Traditional OO is very “all in”, while Clojure is very a-la-carte use the bits that make sense for the problem you are trying to solve. Clojure also encourages a data-over-objects and a functional-first approach, but when you need the OO features, they’re there and you should use them.

Even Smalltalk supports the other way around, although very few are aware of it, because they never bother to learn it. You can do LINQ style coding in Smalltalk-80, and modern Smalltalks like Pharo do support traits as well. So the point being that all major languages embrace both paradigms. "Traditional OOP" basically boils down to Java until version 8 or C# until version 3, and very little else, but unfortunately…

Well, yes, I should have said “popular OO” instead of traditional. I did mean the Java’s and C#’s, Ruby’s and Python’s of the world, not the Smalltalks.

> So the point being that all major languages embrace both paradigms.

Sure, nowadays, most languages are very much multi-paradigm, but typically there is a dominant paradigm and the others are somewhat second-class. For example, in recent years, Java has gained a lot of functional programming feature too, but its not in the same ballpark as Haskell.

Re: Janet: a lightweight, expressive and modern Lisp

#235

Post by pron »

Scarbutt wrote: post #233
pron wrote: post #60

Earlier quoted context omitted.

Is it? I've looked hard and couldn't find any runtime that isn't more than five years behind OpenJDK(+Graal) in those areas, but maybe I missed something. I'm not saying it's perfect, but there's nothing out there that's better in those areas.

You don't need Graal when you have Golang around the corner.

We're not talking about the same thing. The innovative parts of Graal are not the AOT compiler.

Re: Janet: a lightweight, expressive and modern Lisp

#237

Post by microcolonel »

doteka wrote: post #207
microcolonel wrote: post #193

Earlier quoted context omitted.

No, these are not making your point for you. You bring up :import and :use, but in truth, a beginner or intermediate Clojure user is not going to use either of them at all; and when they choose to, it'll be because they have some deeper knowledge which will make the documentation appropriate to them. :import is primarily for people who understand Java and the JVM. If you know what you're importing, you will understan…

And people wondered why Clojure is dying... Somehow a language designed from scratch with all the purported wisdom of Lisp ended up with a nastier import solution than JavaScript, which had none out of the box for its first two decades of life, and then had to reconcile as many as 5 different module systems.

Am I missing something here? The experience is basically the same as the best available in JavaScript/TypeScript, how is it "nastier" or even "nasty" at all?

Also Clojure is doing just fine, not sure what you mean by "dying". The core and the tooling continue to improve, there are lots of libraries, more people writing than ever. I just don't see this death you're describing.

The comments here just strike me as ignorant and incoherent as a whole. Why do people who clearly have no experience actually trying to do something in Clojure have so much to say about it?

Clojure may support things that look daunting to you, but if you actually had any goal other than critiquing the variety of things you actually have no use for, you would not have the difficulties you describe.

Maybe I'm spoiled, I remember JDK setup being a pain on Windows a decade ago when I used it last, if that's the problem then I get it. My spoiled experience on a system with a functioning package manager is basically install-and-go, and zero configuration required to get CIDER going after that.

I just don't get what's so bad about it, it's basically the same experience as Rust with Cargo; is that another "nasty" experience? What language with package manager has a better experience?

Re: Janet: a lightweight, expressive and modern Lisp

#238

Post by nonbirithm »

MaysonL wrote: post #226
armitron wrote: post #221

Earlier quoted context omitted.

I never thought I'd see a Lisp without lists. Oh wait, I didn't because this isn't a Lisp. I know naming is hard, but this is getting out of hand. Don't say you're a Lisp when you're clearly not. Say Lisp-inspired. Don't use the term 'modern Lisp', 9/10 it's signaling the wrong thing.

From the examples: # A simple fizz buzz example (loop [i :range [1 101] :let [fizz (zero? (% i 3)) buzz (zero? (% i 5))]] (print (cond (and fizz buzz) "fizzbuzz" fizz "fizz" buzz "buzz" i))) Is this not lisp?

I'm not clear on the exact reasons, but I think some people see it as "Python with S-expressions" rather than "Lisp". I think it's because Janet does not use lists implemented with cons cells and historically that's just what Lisp always used. (Janet uses arrays instead.) But by that logic Clojure isn't a Lisp, if has no cons cells...

Another criteria used is homoiconicity.

I think the argument is about if a language satisfies the historical definition of "Lisp" rathen than being a Lisp-inspired language with parens.

Re: Janet: a lightweight, expressive and modern Lisp

#239

Post by zdragnar »

MaysonL wrote: post #226
armitron wrote: post #221

Earlier quoted context omitted.

I never thought I'd see a Lisp without lists. Oh wait, I didn't because this isn't a Lisp. I know naming is hard, but this is getting out of hand. Don't say you're a Lisp when you're clearly not. Say Lisp-inspired. Don't use the term 'modern Lisp', 9/10 it's signaling the wrong thing.

From the examples: # A simple fizz buzz example (loop [i :range [1 101] :let [fizz (zero? (% i 3)) buzz (zero? (% i 5))]] (print (cond (and fizz buzz) "fizzbuzz" fizz "fizz" buzz "buzz" i))) Is this not lisp?

Lisp comes from LISt Processing, and prefix notation with enclosing parentheses alone doesn't mean processing lists.

With that said, the underlying datastructures don't actually deter from the fact that you can quote and unquote what appear to be lists, and it walks and quacks more or less like a lisp (like clojure, as a sibling pointed out), so I don't actually mind.

In fact, Janet just might be my favorite scripting language, even if I haven't had occasion to use it for anything impressive yet.

Re: Janet: a lightweight, expressive and modern Lisp

#240

Post by hexmiles »

bakpakin wrote: post #124
jonathanstrange wrote: post #121

Earlier quoted context omitted.

I don't understand why somebody downvoted you, I've seen a number of languages that look like Lisp, but are based on vectors or arrays, and that changes the language drastically. So I'm wondering, too. I was trying to find out whether Janet programs are lists or something else like arrays, but didn't find it in the docs.

This does change the language drastically - source code is represented as tuples usually, although all of the core data structures have literal forms. This means writing macros is still easy, although certain idioms like consing are usually replaced by splicing, which is like unquote-splicing in Common Lisp but more general.

as someone who dosen't know the theory what is the difference between list and array? consing and splicing?

is there a pratical difference in the way you write programs or is more of theory/implemetation detail?

Post reply on HN