HN user

sullyj3

1,004 karma
Posts1
Comments521
View on HN

Functions can be polymorphic in their effectfulness, so the coloring problem isn't. Functions only become incompatible where you've made them incompatible on purpose - the whole point of annotating functions' effectfulness is to statically know you're not accidentally invoking particular effects where you promised you wouldn't.

Learning a new language is basically trivial relative to the effort of bootstrapping everything yourself to compensate for a lacking ecosystem, or the effort of banging your head against the fundamental unsuitability of a tool for a job.

Anyone who's learned one or two languages should be able to pick up the basics of any of the standard ones pretty much instantaneously.

Whenever you're asking for an explanation this deep in the ontology stack, you need to think about what kind of explanation would be satisfying to you, and whether you can reasonably expect intuitive answers in domains that lie far outside of your everyday experience. Human brains aren't built to grasp this stuff intuitively.

At a certain point, the reason we like some particular wacky physical model is always going to be "it has the best combination of explanatory power and simplicity"

I feel like right-to-left requires you to think to the end of a line before you start typing anything at all

Maybe this will make people tend to shorter lines, counterbalancing the natural tendency towards incomprehensibility of array and stack languages

Why Fennel? 3 years ago

It's a runtime check. The following fennel:

    (fn add-1 [x] (+ x 1))

    (lambda add-2 [x] (+ x 2))
transpiles to the following lua:
    local function add_1(x)
      return (x + 1)
    end
    local function add_2(x)
      _G.assert((nil ~= x), "Missing argument x on /home/sullyj3/tmp/fn-vs-lambda/fnl/x.fnl:3")
      return (x + 2)
    end
    return add_2
Lean 4.0 3 years ago

For that you'd use Applicative

  (*) <$> [1..10] <*> [2,3,5]
  -- or
  liftA2 (*) [1..10] [2,3,5]
Admittedly also not accessible to non-haskellers. But on the other hand, if you're going to learn a language, you ought to learn its idioms at some point.

Possibly you were using "algebraic data types" as a general stand in for fancy type system stuff, but algebraic data types are actually one of the least fancy haskell features. They're much more straightforward than the name might lead you to believe. I think there's a broad consensus that new statically typed languages ought to have them, eg they've been adopted by rust and swift. I find languages that don't support them very irritating to use.

I empathise with this uncertainty. As I understand it, flakes aren't incompatible with the previous way of doing things. Rather they represent an additional feature which can be used on top of them.

For example if you have a shell.nix that you were running with `nix-shell` which defaults to using channels to obtain nixpkgs

    { pkgs ? import <nixpkgs> {} }:
      pkgs.mkShell {
      # ...
You can reuse it in your flake.nix
    devShells.${system}.default = import ./shell.nix { inherit pkgs; };
And it will use the locked nixpkgs input defined in your flake. You can run it with the new `nix develop` command, but `nix-shell` will continue to work, giving you the previous behaviour.

A 'flake' is more/less a set of inputs and a set of outputs. I'd say it's less complicated than a package.json file in an NPM project.

It's conceptually comparably complicated, but the actual practical experience of writing flakes is much more complicated. This is not the fault of flakes specifically, but rather due to the complexity of nixpkgs. Although on second thoughts the fact that there are a bunch of libraries like flake-utils and flake-parts out there does seem to point at a verbosity UX issue.

I see your point, but relative capability levels aren't the only relevant factor here, absolute capabilities matter as well.

It seems plausible to me that even if we are to the AI as cats are to us, we've reached an absolute threshold of generality that allows the AI to be confident in our ability to follow simple (to it) instructions, in a way that cats can't for us.

Yeah, this concerns me. If someone believes they can upper bound LLM capabilities, I think the onus is on them to explain where and why scaling laws break down. Regardless, it seems like we'll get to AGI relatively soon (say, within a century), whether that's using transformers and LLMs or not.

I find the implicit assumption a bit funny that the only reason OP might be asking this is for career reasons rather than say, curiosity, the joy of learning, love of knowledge for its own sake.

It's worth noting that `map` is variadic and acts as an nary `zipWith`. I didn't realize that for a while.

    >>> from operator import `add`
    >>> list(map(add, range(5), range(10, 15)))
    [10, 12, 14, 16, 18]
    >>> add3 = lambda x,y,z: x+y+z
    >>> list(map(add3, range(5), range(10, 15), range(100, 105)))
    [110, 113, 116, 119, 122]
Just don’t 4 years ago

I’ve lead teams

I’ve never heard someone criticize me

I wonder if there could perhaps be some causal link here.

People in positions of power often suffer from atrophy of their instinct for social acceptability, because people are less likely to call them out.

a neuron can fire at like 1Hz and modern CPUs operate in the GHz range.

This comparison doesn't make much sense - computers have a very small number of cores, let's say 10, and brains have 86 billion neurons. 86 billion things operating at 1Hz is also in the GHz range. This is leaving aside the issue that a CPU cycle and a neuron firing are doing completely different sorts of work - comparing them is kind of nonsensical in the first place.

A priori one would not expect humans to be near the physical limit of what's possible, purely based on the characteristics of the process that created us

Natural selection is

- random

- blind - gradient descent is prone to getting stuck in local minima, has no foresight, no ability to go back to the drawing board, no "understanding" of what it's doing.

- not even optimizing for intelligence, except instrumentally - to the extent that increasing intelligence interferes with survival, it has to be sacrificed

- subject to hard constraints like the limits on size imposed by childbirth