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

251–260 of 280 posts

Re: Janet: a lightweight, expressive and modern Lisp

#251

Post by kazinator »

solaxun wrote: post #247
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.

I'm so tired of this whole "xyz lang isn't a REAL lisp". First off, what's your definition of "real lisp", second off, who cares? What point are you trying to make? Is the language somehow less useful because it doesn't meet your arbitrary definition of what it means to be a "real" lisp? I imagine you sitting at home in a smoking jacket with some smug smirk typing this out. Saying that a language isn't a "real lisp"…

The definition of what is Lisp does not have the moving goalposts you imply.

> Is the language somehow less useful

It may in fact be the most generally useful programming system in the world.

But does it have to be misleadingly named?

Would you make a four-wheeled bicycle and call it a "skateboard"?

> saying a map implemented using a red-black tree isn't a "real" map

Rather, it's like writing a map using an array of nodes, and then calling it "red black tree" and using identifiers like rbtree_t and rbtree_node_t all over the code, complete with a rbtree_lower_bound function that calls bsearch, followed by a linear scan to find the lowest duplicate key. Why? Because all the popular maps use red-black trees and the designer doesn't understand what that actually is, believing it to be a synonym for any ordered map.

Lisp is not abstract, like "map"; it started as the name of a concrete computer program with a reference manual describing specific features. It spawned descendant systems and imitations. Those which are too far from the original concept aren't Lisp, simple as that.

"Lisp" is an implementation word, not an abstraction word.

Lisp is a specific implementation of symbolic and list processing with specific shapes of data structures, names of functions and their semantics, treatment of Boolean conditions, syntax, and everything else.

Another implementation of symbolic processing, no matter how well or how badly it works, is something else.

People who make Algol-like languages understand this.

Wirth made some very similar languages yet prudently gave them different names. The result is that anyone who says that Oberon is Pacal or that Pascal is Modula 2 is promptly and correctly regarded as an idiot.

Re: Janet: a lightweight, expressive and modern Lisp

#252

Post by jbritton »

oknoorap wrote: post #104

Any tutorial about Janet?

The Janet documentation is sufficient to get going. It reads pretty much like a tutorial. At least if you have any lisp/scheme experience. https://janet-lang.org/docs/index.html

I downloaded a couple weeks ago. I really wanted to build an executable, but I couldn’t. It seemed all the docs on this aspect were out of date or my build was broken in this respect.

Re: Janet: a lightweight, expressive and modern Lisp

#254

Post by owl57 »

jimbokun wrote: post #152
thih9 wrote: post #69

Earlier quoted context omitted.

This process might seem easy for you, but maybe not for people installing Clojure for the first time. In an extreme case, someone who doesn't know Java ecosystem might want to stop to research: what is JVM, why is it necessary, which version would be the best, what's the difference between Oracle's Java and OpenJDK, etc...

If you don't know what Java is, you are not in the Clojure target market.

There is a subtle difference between knowing what river is and knowing how to get to the other bank.

Re: Janet: a lightweight, expressive and modern Lisp

#255

Post by anonymoushn »

HelloNurse wrote: post #242
anonymoushn wrote: post #96

Earlier quoted context omitted.

A complete-fidelity production-like environment would be a couple orders of magnitude more expensive than the 1-day loss, so I disagree.

You don't need another complete set of servers: the new production servers, before beginning actual service, are available for brutal stress tests and all sorts of other experiments while the old servers running the old software are still in use and undisturbed. If the system is completely new and there is no old software on old servers, it's even easier. Considering that software mishaps in securities trading can an…

> You don't need another complete set of servers: the new production servers, before beginning actual service, are available for brutal stress tests and all sorts of other experiments while the old servers running the old software are still in use and undisturbed. If the system is completely new and there is no old software on old servers, it's even easier.

We did not generally physically swap out servers each time we changed a line of code. Rather, we had two identical sets of servers, one for production and one for test. For test, we had some additional machines to run matching engines. If we wanted to make the test environment more closely match an actual venue, we would need many more machines that run matching engines. That still might not be sufficient to produce identical output timings in prod and test, though, because venues generally do not publish the sequence of all incoming ticks they receive during a day, the source code of their matching engine, what hardware they are using, their kernel version, and so on.

> Considering that software mishaps in securities trading can annihilate a company of any size, not only cost you as much as a bunch of servers, lack of testing appears very reckless.

It's strange that you replied to me suggesting we had no production-like test environment ~10 hours after I replied to you saying that this code did fine in our production-like test environment.

Re: Janet: a lightweight, expressive and modern Lisp

#256

Post by hexmiles »

bakpakin wrote: post #250
hexmiles wrote: post #240

Earlier quoted context omitted.

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?

A list refers to a singly-linked list, while tuples are implemented as immutable arrays. The former is flexible in that multiple lists can hare structure, and prepending to a list is an O(1) operation that does not change the original list (consing). This property allows all sorts of interesting data structures which at their core are simply lists of atoms and other lists. Janet on the other hand just uses tuples, wh…

thank you!

Re: Janet: a lightweight, expressive and modern Lisp

#258

Post by oalae5niMiel7qu »

armitron wrote: post #221
ristos wrote: post #99

This looks so awesome! It's got the best parts of a lot of languages. This is what sticks out to me: - Really simple lisp like scheme, but reminds me of lua (and not bloated like CL) - Has resumable fibers, no callcc like scheme - Not missing the lack of lists tbh - A module system that doesn't feel awkward like CL - A built-in package manager (unlike CL) - Good lua and C support - Threads have a shared-nothing appro…

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.

> Don't use the term 'modern Lisp', 9/10 it's signaling the wrong thing.

I think it's signalling exactly the right thing. We know exactly what to expect when someone claims they've made a "modern Lisp". That phrase has come to mean "something with parentheses that demonstrates that its author doesn't understand Lisp at all."

Re: Janet: a lightweight, expressive and modern Lisp

#259

Post by oalae5niMiel7qu »

nonbirithm wrote: post #238
MaysonL wrote: post #226

Earlier quoted context omitted.

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…

A good reason to regard this as "Python with parentheses" is because not only does it use arrays instead of cons cells, but there's no non-mutating `append` function. Instead, Janet has an `array/concat` function that behaves like a Python array's `.append` method, and that's it.

And no, Clojure isn't a Lisp. Perhaps it would be appropriate to say that Janet is "a Clojure".

Re: Janet: a lightweight, expressive and modern Lisp

#260

Post by oalae5niMiel7qu »

microcolonel wrote: post #144
roenxi wrote: post #134

Earlier quoted context omitted.

Clojure is an inspirational language that has some insightful opinions about how things should be done. A month spent learning Clojure is a great investment. A lifetime programming in Clojure would be a joy. But as I recall the original Rich Hickey talks on "Why Clojure?" he was explicit that dependency/project management were very hard problems that Clojure didn't really attempt to solve. I'm not aware of any Clojur…

> he was explicit that dependency/project management where very hard problems that Clojure didn't really attempt to solve. For what it's worth, having used Clojure for work for a couple years now, and ditching leiningen for deps.edn (built in package and dependency management that hooks into maven), I've not had an issue with it. You just add the dependencies to your deps.edn, and run your program. If your namespace…

>For what it's worth, having used Clojure for work for a couple years now, and ditching leiningen for deps.edn (built in package and dependency management that hooks into maven), I've not had an issue with it.

>...

>To be clear, projects like this can be run with the base Clojure distribution, no additional tools required.

Didn't you just say that dependency management hooks into Maven? So doesn't that imply you need to get Maven set up before you can run a Clojure project?

Post reply on HN