[HN Gopher] Janet for Mortals
___________________________________________________________________
Janet for Mortals
Author : ianthehenry
Score : 262 points
Date : 2023-03-31 12:55 UTC (10 hours ago)
(HTM) web link (janet.guide)
(TXT) w3m dump (janet.guide)
| billfruit wrote:
| How does this compare with Carp, which is often featured here.
| ianthehenry wrote:
| The only thing they have in common are parentheses. Carp is a
| statically typed language that compiles to native code without
| a GC. Janet is a dynamically-typed language that compiles to
| bytecode and runs in a virtual machine with a GC. Janet's
| closest relative is probably Lua, despite appearances.
| jamesgill wrote:
| I'm not in the audience for Janet, but I really appreciate
| efforts like this--to write about software in a creative and
| interesting way. I wish there were more.
| oleganza wrote:
| As a wise programmer once said: "Lisps are created by those who
| are lazy to write proper parsers"
|
| Homoiconicity does not mean your syntax should be backwards. Look
| at Io language: it is basically a Lisp, but it has parens in the
| familiar places.
|
| Same with Forth: it is a small and powerful language, but it's
| good for implementing low-level stuff. You will quickly run into
| desire to have normal(language(with, familiar, syntax)) for
| writing non-trivial programs.
| weatherlight wrote:
| syntax < semantics
| tmtvl wrote:
| Allow me to disagree, I personally am very fond of the
| regularity and structure of plain old S-expressions. They suit
| the way my brain works. If I weren't as fond of them as I am I
| would still be using Raku, which is the most pleasant non
| S-expression based language I've ever used.
| kazinator wrote:
| The programmer may have been wise, but their remark doesn't
| testify to that.
| [deleted]
| stefncb wrote:
| How would you write the let macro in Io syntax? I can't think
| of a good way.
|
| Lisp is just less familiar, not necessarily wrong.
| shaicoleman wrote:
| There are no code examples on the home page, so here's one:
| (defn bottles [n] (match n 0 "No more
| bottles" 1 "1 bottle" _ (string n "
| bottles"))) (loop [i :down [99 0]]
| (print (bottles i) " of beer on the wall\n"
| (bottles i) " of beer\nTake one down, pass it around\n"
| (bottles (- i 1)) " of beer on the wall\n\n"))
|
| https://rosettacode.org/wiki/99_bottles_of_beer#Janet
| [deleted]
| cmiles74 wrote:
| I had some time a while back to work on a project of my own, I
| coded up a bencode parser in Janet. It was a fun project, I
| liked Janet alot. :-)
|
| https://github.com/cmiles74/bencode/blob/master/src/bencode....
| mdgrech23 wrote:
| bottles 99 of beer on the wall? That's not the lyrics or am I
| just not understanding janet?
| bombastry wrote:
| The prefix notation may be throwing you off or perhaps you
| have mistaken the function `bottles` for the string
| "bottles".
|
| The code `(bottles i)` in the loop is calling the function
| `bottles` (defined at the top) with the argument `i`. The
| value of `(bottles 99)` is `(string 99 " bottles")` which
| evaluates to "99 bottles", as expected.
| colonCapitalDee wrote:
| You aren't understanding Janet. (bottles i) invokes the
| bottles function with parameter i, so the lyric is "99
| bottles of beer on the wall".
| Cyphase wrote:
| I was about to comment on the "Chapter Fibe" typo, but I decided
| to check the chapter contents first. So in case anyone else is
| thinking about doing the same thing, it's intentional.
| harryvederci wrote:
| The author is super helpful in the Janet community, I'm sure this
| is absolute gold. I encourage Ian to put a donate button on the
| website.
|
| What I like about Janet is that anything seems possible with it,
| and that code from others is very approachable and understandable
| to me. In no other language do I ever find myself hacking on
| someone else's library to add a feature that I need. In Janet, it
| always seems easy.
|
| Some stuff I created that I wouldn't quickly find myself doing in
| other languages:
|
| - a wrapper around my web app that runs it like a CGI script (for
| ultra-cheap deploying on shared web hosts)
|
| - a logging function (macro) that logs the input (both the
| unevaluated way it was called and what it evaluated to) + line
| number of the code that called it
|
| - a framework for creating web apps (not public yet, but used in
| production on my website)
|
| - (with Ian's help) a macro that I can use to create functions
| that require explicitly specified parameters
| sph wrote:
| Thanks, I was looking forward to this, after you sent me a draft
| months ago. I completely forgot about Janet as I've been very
| busy lately, but this is a good opportunity to get back into it.
|
| --
|
| See also, from the same author: https://bauble.studio/ --
| interactive 3d sandbox in Janet
|
| Previously discussed at:
| https://news.ycombinator.com/item?id=32738654
| kelipso wrote:
| Is cutesy language like this as offputting for anyone else? I
| couldn't get past the second paragraph due to the overly cutesy
| ridiculously simplified language. Who is the audience here?
| replwoacause wrote:
| Nope, I like the writing style. It's approachable and enjoyable
| to me.
| cfiggers wrote:
| I really like the writing style. I wouldn't describe it as
| "cutesy" at all, just informal.
| munificent wrote:
| No, I love it.
|
| I don't need sesquipedalian nomenclature in order to respect
| the content of a written work.
| vamega wrote:
| I'm reading your book, and have previously read Ian's
| adventures on Nix.
|
| I love the writing style in both of them! It may not be for
| everyone, but I can appreciate works that use language to
| make topics less intimidating.
|
| Thanks to both you and Ian for your writings.
| sgentle wrote:
| Fun Janet feature that I don't see in many languages: you can
| pause a fiber (coroutine), serialise it, deserialise it somewhere
| else and resume it again.
|
| A bunch of caveats to using it in practise, but it's still a
| little bit magical.
| thih9 wrote:
| > this book contains a repl, and you can summon it whenever you'd
| like by pressing the escape key on your keyboard.
|
| Is there an alternative shortcut for people without an esc key?
|
| I'm on iOS and my keyboard doesn't have one.
| ianthehenry wrote:
| You can click the REPL icon in the bottom left corner, but the
| experience is pretty bad on mobile.
| Graziano_M wrote:
| I'm a fan of janet. I did 2021 Advent of Code using it. I am not
| a fan of Lua, since it's ugly and too barebones (no string
| split?), but I understand its ubiquity due to its small size and
| ease of embedding in programs. I wish/hope for Janet to fill this
| niche.
| keb_ wrote:
| Surprised to hear someone call Lua ugly, as I find it pretty
| and simple. The barebones-ness is part of the appeal for me as
| well.
| catketch wrote:
| Take a look at fennel. Same author as Janet, but it transpiles
| to Lua. https://fennel-lang.org/
| Graziano_M wrote:
| Yeah I actually opt to use fennel over Lua at every chance,
| including my Neovim config.
| bongobingo1 wrote:
| Fennels cool. I use it a lot, but it inherits all the ugly
| bits of lua still.
| munificent wrote:
| The writing style of this is so good I accidentally got halfway
| through the first chapter despite not really needing a Lisp or
| scripting language in my life. I love it.
| throwaquestion5 wrote:
| The site has a Janet repl (downloads pressing Esc) with
| autocomplete. That's enough, now I have to give the book a spin.
|
| The fact the author points out, being able to distribute the
| program without requirements, is a big plus. Multiple times I
| have been doing some bash script that later I can't share with my
| non-techy friends until I translate it in some google sheets or
| something they can use. If Janet can let me do simple script
| stuff and let me share it just sending the binary as a file on
| some chat app, then I'm more than interested
| djha-skin wrote:
| My question for why Janet was answered:
|
| > My favorite feature of Janet, though, is something that sounds
| really dumb when I say it out loud: you can actually distribute
| Janet programs to other people. You can compile Janet programs
| into statically-linked native binaries and give them to people
| who have never even heard of Janet before. And they can run them
| without having to install any gems or set up any virtual
| environments or download any runtimes or anything else like that.
|
| The space is ripe for a lisp that is easily distributable. Yes,
| common lisp can be statically compiled, but their binaries (at
| least with sbcl) can get pretty big [1], even with compression.
| Making a lisp specifically good at using to make CLI or desktop
| tools with good c ffi support is compelling.
|
| 1: https://blog.djha.skin/blog/50mb-for-hello-world/
| medo-bear wrote:
| 50mb for a hello world in common lisp is a bit misleading. its
| 50mbs for a hello world + an entire interactive common lisp
| runtime you can use to further extend the application. if you
| write 2x hello world it aint gonna be 100mb lol
|
| on the other hand, i hear that commercial versions of common
| lisp can achieve better results. but seriously, is this such an
| issue for todays computers ? i have pdfs that are hundreds of
| mb
| zdragnar wrote:
| Why would I want a 50mb hello world?
| thechao wrote:
| Why do you want hello world, at all? Yes, the nearly-null
| program is 50MB; also, yes, a fairly nontrivial program is
| ... 60MB? The core for a computer algebra system is 100MB?
|
| You're paying a higher initial capital cost for lower per-
| unit costs.
| thomascgalvin wrote:
| Why would you want a hello world at all? That isn't a
| realistic distribution scenario.
| HelloNurse wrote:
| A simple "Hello World" is a realistic test scenario,
| representative of a large class of plain command line
| tools and approximately reduced to pure overhead.
|
| If you can distribute and run a trivial hello world
| program, you can expect to be able to distribute and run
| something like tail or uniq, and that it will be larger
| (more standard library portions linked) and slower (more
| actual work executed).
| [deleted]
| EggsAndOil wrote:
| On the contrary, 50 milli bits is quite small for Hello
| World.
| tpoacher wrote:
| > you can actually distribute Janet programs to other people.
| You can compile Janet programs into statically-linked native
| binaries and give them to people who have never even heard of
| Janet before
|
| In theory you "can" do that with python too.
|
| "Can" is a very different kettle of fish from "most people are
| inclined to".
| djha-skin wrote:
| Nah, you really can't.
|
| Before you start screaming "cxFreeze/pyOxidizer/pyInstaller",
| NO. I have gone this route. It is incredibly painful. Python
| was built with the thought in mind that it would be
| interpreted. It wasn't engineered well for compilation. A
| _significant_ amount of effort, often a significant
| percentage of the total effort, is spent shoehorning things
| into this as an escape hatch because requirements have
| changed. This is not the route to choose from the start. Same
| goes for Clojure and `native-image`. I 'm glad the native
| image project exists, and we all hail babashka as a success
| story, but it doesn't mean its author didn't have to spend a
| ton of time with native-image. If you go this route, prepare
| to spend half your time with the build tool itself, and be
| prepared for "oh the language _technically_ works with this,
| but not if I use library _x_ " type disappointments right and
| left.
|
| The best, most painless route is to go with a language which
| has thought about the end result of the build pipeline
| _beforehand_. Rust and Go are gold standard for this. If I
| want a Python that is statically compiled, I reach for Go.
|
| So to hear that the language made a bunch of tiny little
| design decisions up and down the line with the idea of making
| static executables _from the start_ is, from this DevOps
| engineer, incredibly compelling.
| cjohnson318 wrote:
| Go for the win. It's not too hard to pick up, it builds
| fast, it runs fast, and cross-compilation is easy.
| actuallyalys wrote:
| Native image has been getting better, with the Graal
| project recently making it much easier to get builds
| working on Windows. So it's getting to be quite painless,
| so that I think it's already worth it for people already
| familiar with Clojure.
|
| But if you're looking specifically to write small tools
| distributed as native binaries, Janet sounds like a much
| better choice.
| djha-skin wrote:
| I will be most interested when this gets easier, in
| particular if it works with sqlite and the unzip
| libraries. Those libraries are the major snags. I could
| _not_ get it running on windows (the repo in
| question[1]).
|
| 1: https://github.com/djhaskin987/zic
| _a_a_a_ wrote:
| My Python isn't very good so I'm not familiar with your
| cxFreeze/pyOxidizer/pyInstaller list, but couldn't you just
| develop your python using one of these tools from the
| start?
| progre wrote:
| Sure you can, but last I tried (admitedly a good long
| while ago) the exe included everything _except that
| fucking Visual Studio DLL_ that everything requires.
| cjohnson318 wrote:
| For a script with a few dependencies, pyInstaller isn't
| too bad. I love Python, but it's an interpreted language
| first and foremost. Distributing Python code is never
| easy, no matter what you throw at it. Things that are
| supposed to "just work" almost never work when you need
| them to on someone else's machine.
| crabbone wrote:
| Bare Python is mostly useless. People use Python because
| of the libraries. The kinds of projects that are
| developed in Python all, save the most trivial ones, rely
| on stuff that's not written in Python.
|
| For instance, if you do ML, then you use NumPy, Scikit-
| Learn etc. It's all C / C++ code, which you will have to
| link with somehow. And even if you figure out how to link
| with it, your program will still suck because of the
| unnecessary (as I call it) PyObject layer, i.e. the
| Python interpreter interface that is used for
| communicating between Python libraries. Eg. say you
| wanted to pass a pointer from one library to another. If
| you were writing in C -- no big deal, just have some
| externally visible function in one library and call it in
| another, and you are done. But if you want to connect two
| Python libraries, at best, you'll have to use a special
| struct PyCapsule, with two dozens or so of fields, which
| is allocated by Python's allocator and also needs to be
| deallocated... The overhead will be tremendous.
|
| Similarly, if you do Web development, you need some HTTP
| server that can run fast. I haven't touched this part of
| Python in a long time, but the last thing I came to use
| was Tornado, which was a C library with Python bindings.
|
| When it comes to infra, there are plenty of tools that
| are also written in C, various database drivers, Kafka
| client, encryption library... and so on.
|
| ---
|
| Bottom line, even if you defeat the system and manage to
| make it all compile together... it won't work well, not
| as well as it could have if only you could ditch Python
| entirely from this equation. And if you could, then...
| well... you'd be just writing in C...
| _a_a_a_ wrote:
| That's a very strange post that doesn't sound like it's
| coming from a professional programmer. "Do everything in
| C" really misses the value of using a glue language.
| Furthermore you overlook the cost of python as glue,
| which can be relatively quite low under the right
| circumstances. Everything is a trade-off.
| vindarel wrote:
| > common lisp can be statically compiled, but their binaries
| (at least with sbcl) can get pretty big [1], even with
| compression.
|
| My SBCL binaries are +-28MB, with the complete Lisp runtime and
| debugger (cool, I can eval and load configuration files or
| connect to a remote app) and dozens of dependencies, including
| a web server.
| djha-skin wrote:
| I could get it down to 10 with the `:compression` option
| on[1] for hello world. Perhaps this is the option you use?
| The compression didn't hurt the run time much as I recall.
| It's the reason why I'm still okay with common lisp for this
| use case.
|
| 1: http://www.sbcl.org/manual/#Function-sb_002dext-
| save_002dlis...
| vindarel wrote:
| absolutely, I use SBCL compression (following this recipe:
| https://lispcookbook.github.io/cl-
| cookbook/scripting.html#bu... that boils down to save-lisp-
| and-die ultimately). Start-up times are still below the
| 50ms for me.
| freilanzer wrote:
| Who cares about these sizes though? I know I don't and nobody I
| know would either. 100Mb are downloaded in roughly 6 seconds
| with my connection at home.
| tmtvl wrote:
| Exactly, and loading stuff into memory is free, everyone has
| an SSD, and RAM and L1 cache are exactly as fast as each
| other \s.
|
| But on a more serious note, I actually do care because I have
| around 4,500 packages installed on my system. If all of those
| were 100MB in size I'd have a problem.
| Malcx wrote:
| You forgot the /s right? Most of the world doesn't have that
| kind of connection.
| freilanzer wrote:
| I don't see how this is a huge problem. You don't need to
| download the executable once per minute.
| eru wrote:
| Yes, some of us have faster internet. (Assuming freilanzer
| talked about megabits, not megabytes.)
| sebstefan wrote:
| I used to do that in Lua
|
| https://github.com/LuaDist/srlua
|
| The Lua runtime is 340kB on Windows and there's plenty of
| projects including the one above (srlua is made by the Lua
| maintainers) to produce statically linked and dynamically
| linked binaries.
|
| But it's Lua, so while I loved the language, you have to put up
| with the tiny list of standard features which can make it a
| grind.
| brabel wrote:
| The project you linked to has been archived. Are you sure
| they are still maintaining it?
|
| As someone who's playing with Lua to run an incredibly
| lightweight HTTP server[1] which requires just a few MB on
| disk and 1MB of RAM (while supporting stuff like JSON, HTTPS,
| Sqlite DB, Email, MQTT and a lot more), I would be curious
| what you think are the problems with Lua.
|
| [1] http://barracudaserver.com/ba/doc/
| ianthehenry wrote:
| I think Janet is an excellent choice for making redistributable
| CLI apps. Chapter 12 covers a bit of this, including the
| implementation of an extremely simple fzf-powered todo list:
| https://janet.guide/scripting/
| eimrine wrote:
| But not if a support of Windows 7 in a CLI app is important.
| dylan604 wrote:
| in 2023, why would it be? we're talking creating something
| new in a newish language. we're not talking about
| supporting legacy code on a deprecated OS
| pnathan wrote:
| - a helm 3 distro is 45M
|
| - a terraform distro is 59M
|
| - a kubectl distro is 44M
|
| getting rust installed on a windows machine required not just a
| rust distro, but a visual c++ library set over 1G.
|
| at a certain employer, the size of the teams golang tool was
| well over 100MB.
|
| So - 50MB to start with a full Lisp image? yeah, sure, no
| worries.
| nerdponx wrote:
| Plenty of Scheme implementations produce portable-ish
| binaries too.
| pnathan wrote:
| I've never really schemed, only Lisp'd in a common sort of
| way.
|
| I've heard that some scheme things will compile out to C
| even.
| leoc wrote:
| I think it's fair to say that that sentence almost screams
| "this is my adoption strategy". And fair enough, of course.
| ianthehenry wrote:
| I am not the author of the Janet programming language, just a
| user who likes it enough to write a book about it. That is my
| real favorite feature, not a strategy of any kind :)
| psychphysic wrote:
| Maybe I'm being too simplistic but this should be a
| characteristic of the implementation and not the language?
|
| Then again I don't know much about the technical details here
| (when do you or don't you need your own runtime). It seems
| baffling to me with all the cruft and bloat in a modern windows
| install do you still have to install so many microsoft
| runtimes.
| crabbone wrote:
| I really struggle to think about a language that doesn't
| _usually_ need a runtime. _Some_ can produce binaries that
| don 't need a runtime, but usually you need to jump through
| hoops to make that happen.
|
| We just don't notice that typical C programs need libc and
| pthreads. Or that C++ programs on Windows require that cursed
| Microsoft Visual C++ Runime DLL which is always missing, but
| has few dozens of copies all over the system of the miserable
| Microsoft slave.
|
| Go doesn't produce fully statically linked binaries by
| default. I used to make "from scratch" Go containers and, in
| general case, you need libc in them, unless you are willing
| to go through pain of statically linking with it.
|
| Typical / practical Rust programs will also depend on libc
| and pthreads (but, sure, you can do w/o).
| weavie wrote:
| The difficulty with a lot of dynamic languages is that it is
| very difficult to determine at compile time what parts of the
| runtime are not going to be invoked so you largely end up
| having to include the entire platform in the executable.
| JohnMakin wrote:
| can't you compile C into statically linked binaries?
| iansinnott wrote:
| I wonder if Jank [1] could be such a Lisp? I haven't played
| around with it, but I really like the idea and would love to
| see it get more traction.
|
| [1]: https://jank-lang.org/
| miroljub wrote:
| Unless jank rebrands itself as NativeClojure retaining 100%
| Clojure compatibility with a few more native related goodies,
| I don't see it offering more than Janet, which is also
| inspired by Clojure.
|
| Given that they have similar goals, why not merge and join
| efforts? Would help in softening the rough edges and reducing
| the bus factor.
| cellularmitosis wrote:
| Looks like the key difference is that jank is based on
| persistent data structures, while Janet embraces
| mutability.
| smegsicle wrote:
| 'jank' is a good name then- janky immutable structures
| sounds flexible and fast, while janky mutable structures
| sounds like a big mucky headache
| andrewflnr wrote:
| Racket can supposedly compile standalone packages with the raco
| compile command (IIRC). Does anyone have experience with this?
| butt____hugger wrote:
| They aren't standalone executables, they need to be
| distributed along with the lib folder that includes the
| racket runtime.
| sebstefan wrote:
| Surely the lib can be included statically no like Lua does
| no?
| nsm wrote:
| Sorry, I meant to respond to this but went to the parent
| https://news.ycombinator.com/item?id=35392704
| dunham wrote:
| I haven't used it beyond just trying it out once or twice.
| But a "hello world" application in the Idris2 language
| compiles to a 17kb racket file (the default backend is chez,
| but it also does racket and javascript).
|
| If I run `raco exe` on this, I get a 57MB file. On mac, it's
| only linking system libraries. (For Idris2 programs, there is
| an Idris support library that is dynamically loaded.)
|
| I haven't tested transporting it to another system (my test
| was on an arm mac, so I don't have another system to test
| that on).
| nsm wrote:
| Doesn't raco make followed by raco exe produce fully
| standalone (except libc) executables? I believe some
| platforms need an additional raco distribute step.
| andrewflnr wrote:
| Oh, raco exe is probably what I was thinking of.
| zem wrote:
| chicken scheme can do this too, for what it's worth
| muyuu wrote:
| chicken scheme comes to mind
|
| anyone around knows how does it compare to Chicken?
| koito17 wrote:
| The binaries are big because it's shipping a preprended lisp
| kernel together with the _entire_ programming language in a
| heap image. It 's also largely dependent on the Common Lisp
| implementation. SBCL is very inline happy and consequently
| consumes more memory than other Lisp implementations. A fresh
| CCL image consumes at most 8 MB on my Mac.
|
| If you want small binaries, then you'd want tree-shaking, not
| an entirely new language. LispWorks is already capable of
| producing small, graphical hello world examples. Even then, a
| hello world is a rather silly benchmark for binary size,
| especially since it totally ignores the fixed cost of a
| language runtime and no serious person is distributing a hello
| world.
| Koshkin wrote:
| It's a LISP
| kunley wrote:
| It's alive^Wa lisp!!;)
| _benj wrote:
| I'm quite excited about this!
|
| Janet looks like a nice small, embeddable, fun language with a
| lively community!
|
| The documentation and site felt like a close-knit community of
| insiders, which I wanted to become one of them :) hopefully this
| book shows the path!
| [deleted]
| progre wrote:
| > 4. Pegular expressions
|
| Good one. PEGs feels like having a parsing superpower compared to
| regexes.
| giraffe_lady wrote:
| Oh cool I love janet, I've been using it everywhere I can
| recently. There definitely weren't many good resources on it last
| year, though it wasn't too hard to learn despite that.
|
| This language also completely converted me to PEGs for entire
| classes of problems, and I'm now often annoyed in other languages
| that don't have them. Libraries exist, but having it built in is
| so nice, and the s-exp syntax works much much better for them
| than almost anything else you could come up with.
|
| A moderate issue I had was finding functions for what I wanted,
| since the docs were set up more tutorial style, then there was
| just a huge list of every function. Spent a lot of time skimming
| through that guessing what I could be looking for.
|
| Another thing I ran into is the concurrency/fiber system still
| feels like a work in progress. There are several different ways
| to handle concurrency depending on how you want to combine the
| abstractions, and some parts of the (otherwise excellent)
| standard lib don't work well with it. It also combines nastily
| with a lot of C libraries, which is rough in a language that
| seems to expect you to use C bindings often. Understandable
| limitation and there's probably not a good clean solution.
|
| Anyway this book looks great, I really hope it brings more people
| into janet. It's an excellent language for a lot of applications
| where people reach for the imo extremely overrated lua.
| whydoineedthis wrote:
| I wish Ian Henry (the author) wrote all of my technical books. He
| is both whimsical, but also to the point.
|
| I don't think i'm the biggest fan of Janet, but I really
| appreciate his writing and may just read the whole book anyways.
| superb-owl wrote:
| Here I was hoping for an introduction to the work of Pierre
| Janet.
| BillinghamJ wrote:
| I thought it might be about this JANET:
| https://en.wikipedia.org/wiki/JANET
| mentos wrote:
| Is the 'for mortals' thing a Steve Jobs-ism?
| sph wrote:
| Given that it is a Lisp, it should be "for mortals seeking
| divine beauty and purity".
| ianthehenry wrote:
| The Janet language is named after a fictional immortal being
| from the television show The Good Place, who exists to help
| mortals in the afterlife -- that was the inspiration for the
| title.
| cnasc wrote:
| I think a reference to Q For Mortals https://code.kx.com/q4m3/
| eimrine wrote:
| Any sufficiently complicated C or Fortran program contains an ad
| hoc, informally-specified, bug-ridden, slow implementation of
| half of Common Lisp [1] . Maybe Janet is a human version of C,
| and that half of Lisp which is implemented here is the part of
| Lisp which is relatively easy to learn.
|
| [1] Greenspoon's tenth rule
| Uehreka wrote:
| So the word LISP does not appear in the entire introduction. If
| you're introducing a language thats a LISP, that's really the
| kind of thing you've got to state up front.
|
| You can define the term for those unfamiliar, and you don't have
| to dwell on it, but people who are turned off by LISPs will feel
| a little swindled if they get 3 book-pages in before finding out.
| And people who specifically like LISPs might pass this over
| without realizing what it is and miss out.
| wodenokoto wrote:
| Chapter 1 deals with your frustration:
|
| > And now you're just wondering when I'm going to use the
| L-word. You want me to use it so you can go write a long screed
| about how Janet isn't a real one. But I'm not going to give you
| the satisfaction. I'm not going to use that word until Chapter
| Fourteen.
| philsnow wrote:
| also
|
| > Note that Janet's `nil` is not the empty list. If you don't
| understand why I'm calling that out here, you can safely
| ignore this paragraph.
|
| beautiful, succinct, and not a jab at lisp-y languages
| weatherlight wrote:
| this guy is a hero, i love it.
| fallat wrote:
| I really argue the opposite: it's really something you dont. A
| ton of people see LISP and get scared away.
| tgv wrote:
| The first (defun will take care of it if you don't. If they
| stay, and can stomach ))))), I doubt they'd be scared off by
| mentioning LISP. Hell, you can even mention it after the
| first examples.
| giraffe_lady wrote:
| If you call it a lisp you summon the lisp lawyer demons who
| will litigate your namespace & symbol semantics and start a big
| beef among themselves about what a lisp is and what makes lisp
| lisp and how much this is lisp and whether lisp even exists
| it's just a whole huge headache.
|
| It uses parens and prefix notation. Not every language that
| uses parens and prefix notation is a lisp, I guess, maybe, I
| don't care. But not wanting to have that argument is an
| excellent reason to never make this assertion about a language
| imo.
| YuukiRey wrote:
| So someone might be 3 pages in and really like what they're
| seeing but upon hearing the word LISP they turn around and
| decide they suddenly dislike it?
|
| Considering that people can't even really decide on what
| constitutes LISP (Is Clojure a LISP?) I don't think there's any
| merit in this kind of resource to mention a term that's more
| likely to give people a false impression of what this really is
| or isn't.
| superdisk wrote:
| He pokes fun at this type of comment in chapter 1.
| cpufry wrote:
| this is neat and all, idk why i feel so exhausted every time i
| see a new language these days
| nerdponx wrote:
| If you're anything like me, it's because you're getting older
| and have increasingly limited free time and energy that you can
| no longer dedicate to learning new programming languages.
| weatherlight wrote:
| Because learning new things is hard and hard things tire us
| out. we should endeavor to learn new things everyday.
| smegsicle wrote:
| some people have reported aspirin providing relief from long
| covid
| replwoacause wrote:
| huh?
| afry1 wrote:
| It's the "sadness of mortal men" as Tolkien put it. So many
| awesome languages in this world, so little time to learn and
| use them.
| nerdponx wrote:
| One obvious point I'm missing here, and that I've been missing
| from Janet discussion in general: why Janet and not Scheme?
|
| Gauche for example implements the latest (and IMO greatest) R7RS,
| its standard library is huge and "batteries-included" including a
| wide array of RFCs to the point of rivaling Python, and has a
| package manager in the form of Akku. Chicken has a similar story.
| Racket is arguably more useful "out of the box", but its
| community seems so heavily focused on using it for PL research
| that it's harder to justify using it for day-to-day programming.
| And there's Clojure as well, which I know comparatively less
| about, but is well-loved by its users.
|
| Heck, even Common Lisp has a lot going for it, but the Standard
| and the conventional Lisp dev tools are kind of chaotic and
| idiosyncratic enough that it's understandable if people don't
| want to use it.
|
| To be clear, Janet seems like a great little language. But as
| someone with limited time and energy who is interested in using
| it, I want to know why I should spend the time learning it,
| compared to Scheme
| dri_ft wrote:
| Scheme feels really verbose to me. I get that it's 'minimal'
| and 'elegant' and everything, but then why are all the
| identifiers so long? I feel like I have to do a lot of typing
| to get anything done. Maybe it's better if you're using emacs
| and have good lispy autocomplete, I don't know. But broadly, it
| makes me feel like the people who developed scheme were working
| from a very specific definition of 'elegant', and it doesn't
| align with mine. Janet feels better for that.
| ianthehenry wrote:
| I don't think Janet and Scheme have very much in common. If
| you're looking for a huge, batteries-included language, you
| will not have a good time with Janet :)
|
| Janet is much closer to Lua, in scope and applications, than it
| is to any Scheme or Common Lisp or Clojure implementations.
| pull_my_finger wrote:
| Janet has a lot in common with Lua: tables, coroutines, easy
| embedding, lots of API similarities. Compared to a language
| like Lua, Janet is _bursting_ with "batteries". Almost to a
| Ruby level where whenever you think to do something, you
| check the docs and find yourself saying "of course there's a
| function for that". I have to disagree completely with your
| assessment.
| headhasthoughts wrote:
| r5rs is significantly smaller than Janet.
| Koshkin wrote:
| This was the last good Scheme.
| medo-bear wrote:
| it seems to me that gebril scheme fits janet's use cases
|
| https://cons.io/
| imwithstoopid wrote:
| Janet users are not encumbered with the historical cruft of
| scheme like hiding libraries behind unmenorable srfi numbers,
| or the ancient an un-portable oop implementations etc etc
| agumonkey wrote:
| This should be studied a bit. At what point a partial reboot
| benefits the community/language before.
| giraffe_lady wrote:
| Janet has close integration with C going both ways. It has
| built in C ffi and you can easily build and distribute a janet
| binary that uses C libraries.
|
| It's also easily embeddable in C programs the same way lua is,
| making it possible to use it as a config, extension, or
| scripting language in a larger program.
|
| Aside from that having used it a fair bit I think it's got a
| very "practical" orientation. It provides immutable structures,
| but doesn't enforce immutability semantics the way clojure
| does. It has a good concurrency system but is cleanly single-
| threaded and performant by default. And imo the standard lib is
| a really good balance, neither forcing you to build EVERYTHING
| yourself (lua) or having the whole last 50 years of CS research
| in it (racket).
| crabbone wrote:
| > is cleanly single-threaded
|
| And here I immediately lost my interest. Anything that cannot
| do real concurrency is a toy in my book. There's no excuse
| for a language developed for practical computers in 21'st
| century to not be able to utilize concurrency which is
| practically built into every existing computer.
| tmtvl wrote:
| Then it's a good thing those words were preceded by:
|
| > _It has a good concurrency system_
| giraffe_lady wrote:
| Maybe you should reread that sentence bc I don't think it
| says what you think it says.
| galaxyLogic wrote:
| This would seem like a good tool for creating small binaries
| which are meant to be combined by shell-pipelines later (?)
___________________________________________________________________
(page generated 2023-03-31 23:00 UTC)