4 ms·
Thank you for this. What do you make of BQN? https://aplwiki.com/wiki/BQN https://aplwiki.com/wiki/BQN I get enamored with apl/k/j every time I see it and wa
by recuter 5y ago
Thank you for this.
What do you make of BQN?
https://aplwiki.com/wiki/BQN https://aplwiki.com/wiki/BQN
I get enamored with apl/k/j every time I see it and was looking for excuses to use it despite everything.
I understand that due to the much smaller community the tooling and ecosystem is much weaker but there must be a reason why some people keep reaching for it, especially the guys in finance. I don't get the Cobol vibes from it like it is some sort of legacy burden. While the use case is narrow there must be an edge.
This is HN after all. You wouldn't tell people not to mess with lisp and just reach for python now would you? *puppy eyes stare*
- all2 5y agoWhen I want to just "Get stuff done" TM, I reach for Python. Except that I've stopped doing that because setting up package versioning and venvs is a nightmare that gets more frustrating every time I try to do it. Now I'm looking for a "better" TM way to get my scripting needs met. I'm looking at Nim, specifically. I may also try to lean on a Scheme or a Lisp. My problem with the latter is lack of decent docs for getting stuff done. Maybe I'm missing something, but being productive in those languages for me is like a high jump when I can't even step up on a curb.
- rscho 5y agoRacket has been rated as 'an acceptable python' by a famous programmer. Well deserved, I think.
- klibertp 5y agoNot without quite a few libraries. You need at least rackjure[1] (for threading macros if nothing else) and data/collections[2] (for unified sequence/collection handling and convenient helpers). You might want data/functional[3] for the `do` notation (to replace all the for/... forms; only if you know what you're doing). You will probably need a few srfis - 26 for cut, for example - depending on your preferred coding style and domain. You won't need external libraries for streams, generators, objects and classes, contracts, graphics and plotting, documentation generation, concurrency, limited parallelism (futures) and multiprocessing (places) - as these are all built-in. Racket is a great language. I learned it around 2008 and get back to it regularly. However, due to its focus on pedagogy, the defaults tend to be verbose for practical work. The incredible power of `syntax-parse` makes it trivial to build DSLs, but that backfires, because everyone and their cat make DSLs instead of settling on a single set of helper libraries. Packages that require a lot of effort to make, like a numpy/pandas/data-frame implementation, tend to lag behind their counterparts in other languages due to the relatively small community. Without easy access to larger ecosystem that Clojure enjoys it's pretty much impossible for the situation to drastically improve on that front. Contracts and Typed Racket are still, to my knowledge, the most advanced in their respective fields. I love Racket. It's my first Lisp, and it'll have a place in my heart until the day it stops beating. However, for practical, day to day coding, that doesn't fit precisely into Racket strengths, it's not as good as any of the top 10 on TIOBE. [1] https://docs.racket-lang.org/rackjure/index.html https://docs.racket-lang.org/rackjure/index.html [2] https://docs.racket-lang.org/collections/collections-api.html?q=data%2Fcollection#%28part._.Generic_.Collections_and_.Sequences%29 https://docs.racket-lang.org/collections/collections-api.htm... [3] https://docs.racket-lang.org/functional/interfaces.html https://docs.racket-lang.org/functional/interfaces.html
- beagle3 5y agoNimpy makes it possible to move from Python to Nim gradually. It’s magical, and while it doesn’t solve python’s own venv problems, it would only need the DLL from Python - whether it was 2.5 or 3.4 or 3.8, it would just work - they probably removed the python2 support by now, but it was just magic.
- jrapdx3 5y agoSome Scheme/Lisp implementations are capable enough to accomplish daily work. Common Lisp is one option, and I've used Chicken Scheme effectively for some projects. You're right though, there's a significant learning curve with any language in a different paradigm. Forth-like languages are an example, and yeah, J/K and cousins are hard to grasp. I've dabbled in these but never quite got there. IMO Lisp-like languages aren't quite as "foreign" since the syntax is a variation on 'function parameters body' used in "normal" (Algol-like) languages. I guess it comes down to what we get used to, and really for many purposes choice of language isn't all that critical, assuming of course it supports the task at hand.
- girvo 5y agoNim is excellent, I use it daily, but you'll have to define what you mean by "scripting" language :) It is very much in the school of "build a binary, run that binary", which is ideal for my usages. There is of course, support for running scripts (".nims", Nimble tasks, and so on), and one can just tell the compiler to run your binary no worries from nimcache anyway, but I still use other actual scripting languages for some tasks. Mainly bash, to be perfectly honest. That said, my view is biased, as most of what I do with it is for the "make a binary, then run the binary somewhere" school of usage patterns! Its quite possible it is a good fit for what you're after. And I adore it as a language.
- klibertp 5y agoI've been doing some research in this area: for day-to-day, quick and dirty, scripting purposes, if not Python, then what? I want something expressive: Python can be a bit verbose by default and isn't very good at oneliners. I want something that starts up fast, but can run a bit slower. It would be great if it had a REPL, but if compilation and/or startup are fast enough its lack would also be acceptable. The amount of available libraries is not that important, but at least https client, json and csv parsers, are a must. I considered: V, Nim, Clojure, Scala 2, Scala 3, GNU Smalltalk, Rust, Zig, Clojure, Racket, Emacs Lisp, Raku, Ruby, OCaml, and LiveScript. I don't have the time right now for a full write-up, but in terms of expressiveness and for scripting on the command line, LiveScript[1] won; in terms of general scripting (10-20 loc) Emacs Lisp won (I use Emacs, and the IDE-level support for Elisp there is outstanding). Raku and Ruby were runner ups in both categories. The expressiveness of Elisp - with some extensions I made to the interpreter and a bunch of libraries I already have installed (dash, s, f, ht) - was the biggest surprise. It was on par with LiveScript, which has a lot of specialized syntax. The problem with LiveScript is that it's not very actively maintained, but it's still one of the most expressive languages I know of, and running on Node makes it quite fast and gives it access to all of NPM. I didn't consider Haskell, because I don't know it well enough. The rest of the languages were either significantly more verbose, had unacceptable startup time, required a lot of extensions and libraries to get the expressiveness level I wanted, or had a bit too few libraries available. [1] https://livescript.net/ https://livescript.net/ + https://preludels.com/ https://preludels.com/
- melezhik 5y agoyou may consider Raku AND sparrow - http://sparrowhub.io http://sparrowhub.io , you'll get all the benefits of Raku on high level scenarios, and you can write _underlying plugins_ on many languages (Bash/Perl/Ruby/Python/Powershell), so that will give you a certain level of freedom while transitioning from one language to another.
- nathan_compton 5y agoJ feels a lot like Smalltalk and Lisp to me. If you got on board early, you could do all sorts of stuff other languages struggled to make easy and performant. Hence the set of dedicated users. And there are some genuinely interesting conceptual things going on in array languages which have real appeal. But in the end I think J reflects a previous era and hasn't caught up to really useful ideas in more contemporary languages, probably because its user base is too conservative. I wouldn't recommend people use XLisp or run Genera in a VM to solve real problems. Recommending J feels like that to me.
- recuter 5y agoI see your point. You dream crushing bastard. :) For no reason whatsoever here is a link to a guy building a Korean style wooden house by hand without using nails: https://www.youtube.com/watch?v=hvsvMzgiq6s https://www.youtube.com/watch?v=hvsvMzgiq6s What are "real problems" anyway? Sigh. You're right, I know you're right. Somehow this field is losing appeal over time. I'm going for a walk.
- mlochbaum 5y ago> Somehow this field is losing appeal over time. Not true, at all! Since 2010 or so, the APL family has only improved its reputation and grown in popularity. I listed some developments of the past two years at https://news.ycombinator.com/item?id=28930064 https://news.ycombinator.com/item?id=28930064. Now, it's not much relative to the huge growth of array frameworks like TensorFlow with more mainstream language design, but it is definitely not losing appeal.
- recuter 5y agoOh no, Marshall, I was being far more despondent and was referring to programming as a whole. Thank you very much for your efforts on BQN. Speaking of TensorFlow, I was looking at tinygrad the other day: https://github.com/geohot/tinygrad/blob/master/tinygrad/tensor.py https://github.com/geohot/tinygrad/blob/master/tinygrad/tens... Very tempted to port it to BQN. I could be wrong but I bet it would shine for that. You could print the whole thing on a t-shirt.
- jonahx 5y ago>I get enamored with apl/k/j every time I see it and was looking for excuses to use it despite everything. You should do it. Nothing in my programming career has changed the way I thought so much as learning J to the point of real fluency. Though you could swap out APL, k, or BQN for the same effect.