Earlier quoted context omitted.
x86-64
market share is going to ARM
ARM is nice too, I concur
Janet: a lightweight, expressive and modern Lisp
241–250 of 280 posts
Re: Janet: a lightweight, expressive and modern Lisp
#242Earlier quoted context omitted.
I gotta agree with HelloNurse here. When that kind of money is on the line you set up a production version that ingests real data at real speed, and produces the same output / response but doesn't actually spend / affect any money. You watch it for at least a week and see what happens. I'm sorry to say it, but the loss of money here was not the JVMs fault. It was putting code with insufficient load testing in a produ…
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 annihilate a company of any size, not only cost you as much as a bunch of servers, lack of testing appears very reckless.
Re: Janet: a lightweight, expressive and modern Lisp
#243I don't use lisp languages, but one basic difference this has from other lisps is that functions accept multiple expressions, e.g.: (defn greet [firstname lastname] (def fullname (string firstname " " lastname)) (string "Hello, " fullname)) In other lisps, you'd have the last expression nested inside a `let` block: (defn greet [firstname lastname] (let [fullname (string firstname " " lastname)] (string "Hello, " full…
In common lisp `defun` does not require using `let`.
There are two things at play here (1) the implicit body and (2) being able to add new bindings in an existing scope with "def".
CL has an implicit body, but does not allow defining new bindings outside of some dedicated forms (let, etc.). I really prefer having to write "let" forms instead of having new variables added inside the body.
Re: Janet: a lightweight, expressive and modern Lisp
#244Janet is quite nice, and I was playing with it only the other day:
https://taoofmac.com/space/blog/2020/05/10/1300
However, nobody here seems to have mentioned Joker, which is a Go interpreter/linter for Clojure:
I'm rather torn between Janet and Joker, but am considering using Joker instead (even though it is single-threaded and lacks SQLite support) because it's closer to Clojure syntax.
Re: Janet: a lightweight, expressive and modern Lisp
#245Earlier quoted context omitted.
In the fine tradition of Jcala, Jotlin, Jroovy and Jlojure.
Little known fact: Rich Hickey initially planned to target .Net CLR and JVM, so he wanted something that has "C", "L", "R", and "J" in the name, that's how Clojure got its name.
Well, I guess had he put JVM first to reflect reality, the ‘Jocular’ language would evoke rather different feelings.
Re: Janet: a lightweight, expressive and modern Lisp
#246Okay, so when Clojure came along, it came with a strong underlying philosophy of what the language was supposed to be/do. Among them were design decisions such as, e.g.,: - VMs, not OSes, are the platforms of the future, so target the JVM - Object Orientation is overrated, but polymorphism is a good thing - Multi-core is here to stay, so use immutable data structures to greatly facilitate writing correct concurrent p…
It looks like you may have inadvertently used the "block quote" ML in your whitespace. It renders terribly on mobile.
Re: Janet: a lightweight, expressive and modern Lisp
#247This 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.
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" because it doesn't use cons cells is like saying a map implemented using a red-black tree isn't a "real" map because it doesn't use an array of nodes.
Re: Janet: a lightweight, expressive and modern Lisp
#248Earlier 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?
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 scriptin…
[deleted]
Re: Janet: a lightweight, expressive and modern Lisp
#249Earlier 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…
Clojure isn't a Lisp, and really screws up some of the concepts.
Re: Janet: a lightweight, expressive and modern Lisp
#250Earlier quoted context omitted.
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?
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, which are easier to pack densely into memory so usually have better cache performance on reads (clever lisp implementations can sometimes can make lists fit densely in memory, but usually they take about twice as much memory as a tuple).
splicing is the like the spread operator in JavaScript or the splat operator in Ruby. This turns out to be very useful in a language without cons for manipulating tuples in macros, even though it is not as efficient as a cons.