hatmatrix

It's an apt analogy. It's like the realtor is under pressure to sell the house so does a quick and dirty DIY plumbing. Then when the house is sold you hire a real plumber to fix it right, hopefully before the gushing disaster.

Here, founders demo something that attracts the investors' or customers' attention - then they can clean it up later.

Can this connect to WSL like VSCode?

Well I think the original author was a fan of Lisp and implemented the first Julia parser in femtolisp, IIRC. (And femtolisp was a lightweight Lisp of his own.)

Lispers might not like that it's not a Lisp, but I remember Luke Tierney also making a statement to the effect that the statisticians have spoken and they don't prefer the Lisp syntax.

So Julia is a happy middle ground - MATLAB-like syntax with metaprogramming facilities (i.e., macros, access to ASTs). Its canonical implementation is JIT, but the community is working on allowing creation of medium-sized binaries (there has been much effort to reduce this footprint).

Both.

There are some optimizations that can be made a compile-time that can speed up the computations. It also makes it portable provided that the executables are provided for each desired platform.

> And while base Python I find to be extremely elegant, typical data science and scientific computing workflows are a headache.

That's my impression as well. Going back to the topic of the original post, pandas only partially implements the idioms of the tidyverse so you have to mix in a lot of different forms of syntax (with lambdas to boot) go get things done. Julia is much nicer, but I find myself using PythonCall more often than I'd like.

Scipy was originally supposed to provide the scientific computing stack, but then many offshoots in the direction of pandas / ibis / JAX, etc. happened. I guess that's what you get with a community-based language. MATLAB has its warts but MathWorks does manage to present a coherent stack on that end.

Actually I like that you can use it as a dictionary of tuples (i.e., rows).

Hey this looks pretty tidy.

There is so much hype and luck to widespread adoption, you never know with these things.

> At the time it was more or less taken for granted that AI work was done in Lisp. C++ barely existed. Perl was brand new. Java was years away. Spacecraft were mostly programmed in assembler, or, if you were really being radical, Ada.

Given the choices, Lisp made a lot of sense when they started. After 2001-2004, there were other options - not to say they were necessarily better, but a mainstream language that enables a large number of people working together (interchangeably) has its value. Lisp is indeed "one-of-a-kind, highly dynamic applications that must be developed on extremely tight budgets and schedules" - but has a reputation for fostering lone geniuses and bad for large teams working together and maintaining legacy codebases.

(I write this as a big fan of Lisp.)

I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings.

There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost. Yes, there is Ctrl+[ for single commands, but this is still an additional step compared to the key chord model of Emacs for instance.

Indeed there is administrative bloat everywhere, and I can sympathize with your hope that tearing down the current system will leave room for building anew.

However, it's hubris to assume that everything is bloat. There is the adage of Chesterton's fence, which reads: "...reforms should not be made until the reasoning behind the existing state of affairs is understood." Many things that appear to be bloat that serves a useful function, and tearing them blindly is going to do irreparable damage.

[1] https://en.wiktionary.org/wiki/Chesterton%27s_fence

Such a functionality would be useful for developing some scripts and then converting to a Quarto document [1].

[1] https://quarto.org/

Is it? I use org-babel regularly but wasn't aware of it - what's the function called? As great as org-mode / org-babel is, the user base is too small to not be overlooked.

Peter Norvig himself has come around to embracing Python as an alternative to Lisp:

https://norvig.com/python-lisp.html

https://news.ycombinator.com/item?id=1803815

and there is indeed a Python implementation for the PAIP programs.

https://github.com/dhconnelly/paip-python

GC conferring additional composability is an interesting take - I hadn't thought of that (though I don't spend much time in this domain).

Good point. When Clojure first came out it was questioned whether it's a lisp at all, but now I commonly hear many say it is the best Lisp.

Ah I didn't see that.

That explanation sounds very plausible.

I believe it's open source but requires a commercial license; free for academics.

I understand native multithreading would be one of the key advantages of Guile Emacs.

As a fan of Julia, surprised to see how julialang/julia has so few links. It's a niche language; how isolated it is on this map is maybe not so unrepresentative of the user or developer experience.

I can't imagine the use cases for parsing org-syntax in Julia - is it for textual analysis?

Monte Carlo is one way to implement multiple imputation.

Igor Pro is nice but the underlying language which grew out of a set of macros is pretty rough to work with (by default works via side effects and mutation of global state, though there are ways to contain them). However, I know people who have built some nice GUIs on top of it. While it does have HDF5 I/O integration, there's no memory mapping and it will choke on larger data sets from what I recall.

I've heard promising things about Makie [1] in Julia; there is also capability to build a dashboard called Genie [2] (and a commercial dashboard builder [3]) though not sure if Makie and Genie play nicely together at the moment.

[1] https://docs.makie.org/ [2] https://genieframework.com/ [3] https://info.juliahub.com/blog/create-low-code-apps-on-julia...

Or PlantUML - or is that not in the running anymore?

Ah I had not realized I was corresponding with the author of that talk - I'd followed it back when it was happening as I'm particularly interested in adapting AD.

Where do you feel Julia is at this point in time (compared to say, JAX or PyTorch) from a practitioner's standpoint?

It seems like an experimental research language.

Julia also competes in this domain from a more practical standpoint and has less limitations than JAX as I understand it, but is less mature and still working on getting wider traction.

Surprising because you get different answers each time you ask ChatGPT.

There are some very useful rules of thumb here about when to use forward vs. reverse differentiation, etc. Very practical tutorial.

I switched to Windows/WSL2 a few years back so don't have a fight in this game (though if it's Electron, why only macOS?) - but having to switch between IDE and Jupyter for code formatting seems like unnecessary overhead.

But TBH Quarto is much better in this regard; you can use a VScode together with another IDE if you wish to format/edit/run chunks of code in the same file.

I've heard it summed up this way: "They lied to us 30 years ago. How can we trust they're not lying this time?"

Recycling technology has not advanced enough that what is promised is credible. If they were honest about the difficulties in recycling, it may be that we still might have carried forward with the plastic revolution - but we probably would have been less cowboy-ish in adopting it for everything.

It's widely thought but not conclusively found that there are certain constituents that are more toxic than others. As you say, the problem lies in the ability to measure these constituents more widely.

However, there is a hypothesis [1] that maybe there is something about the collective mass as negative association with health effects have been found all over the world where the composition changes drastically. A more recent hypothesis [e.g., 2] is that many health problems from particles stem from persistent reactive oxygen species that cause oxidative stress, and these reactive species form from many different mechanisms so likely scales with the collective mass, which has been serving as a surrogate metric.

[1] https://doi.org/10.1016/S0048-9697(99)00513-6

[2] https://doi.org/10.1038/srep32916