Hacker News new | past | comments | ask | show | jobs | submit | mcaruso's comments login

> Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc.

You might want to take a look at what browsers have been working on lately, because a lot of what you're asking is either already here or actively developed. Some of it driven by the Open UI working group (https://open-ui.org).

- Modal: see the <dialog> element, with its focus trapping out of the box, stylability through the top layer, entry and exit animations through @starting-style and the ability to transition discrete properties like `display`, etc.

- Rich dropdown: browsers now support popovers, which allow you (without any JS) trigger a popover that overlays the screen in the top layer, and with automatic focus management. See also the work being done on stylable <select> elements, there's a great episode of Off The Main Thread that goes deep into all the work being done to make this happen [1].

- Carousel: see the recent work on stylable <details> elements [2], and in general the carousel project at Open UI. After <select>, the carousel is one of the main focus areas.

[1] https://offthemainthread.tech/episode/stylable-select-elemen...

[2] https://chromestatus.com/feature/5112013093339136

[3] https://open-ui.org/components/carousel.research


Of course HN works fine, if it didn't work fine it'd be fixed by now. "Working fine" is an extremely low bar for any site. As a developer you will still want to avoid quirks mode because it just makes your life harder for no reason.


From the article:

> But we've had a pretty good definition of abstraction since 1977, originally in the context of program analysis, and — I claim — it actually translates quite well into a precise definition of “abstraction” in engineering.

So I don't think the author is saying that all these other people are "wrong", but rather that this one particular definition seems to capture the underlying essence of what we intuitively think of when we say "abstraction", and the rest of the "hodgepodge of different concepts" break down if you analyze them a bit deeper (as the author did in the "Not Abstraction" section).


Yes and I don't agree that this is particularly fruitful. I might have completely misunderstood it but here we go:

The common theme in the Not Abstraction section is: These things are used to build abstractions and are not necessarily abstractions themselves. This is not only nitpicking but it's also false. Programming language features like functions and interfaces are already abstractions, even in the narrow sense that the article describes. They are an idealized mapping to something concrete (register machines, vms etc.) and provide precision, soundness and are based on specification.

Again, I very much like the core idea presented here, but I think it is completely unnecessary to make the claims about what is and isn't "true" abstraction.

Take this quote:

"Abstractions are separate from the code, and even from the abstract domain. It does not make sense to say that the bookTable function or anything else in this file “is” the abstraction, (..)"

The function _is_ not the abstraction because abstractions are entirely conceptual? Is it a way to communicate an abstraction then? What about the actual machine code the compiler produces from that function, is there some abstraction?

None of this helps me. The interesting part is that code is used to model information, it's not the world itself or even tries to be.

Then this:

"Feel free to call numbers an abstraction of the hardware, but be prepared to switch to this precise terminology when there's tension on the horizon."

Simple abstractions that are not discussed are names and signs. These are abstractions in the very real sense and they are very simple on their own. But they are entirely contextual and are allowed to mean different things. For example the term "abstraction".


I think you've misunderstood it.

Let's design a system that allows us to run virtual computers on a single hardware platform. In some part of this system we need to map real hardware addresses to virtual ones in order to isolate the different virtual computers.

Now you might need a way to take a real, logical address to a memory location on this machine and get a virtual address. You might have to run this system on many different hardware platforms and you only know the platforms you will run on today (or the next few months). Almost without thinking about it you might choose to use a virtual method on a class to define a function signature for this operation. That way folks implementing this system for different hardware platforms can create a sub-class and fill in a concrete definition of the virtual method. Now users of the system can translate an address and don't have to think about the underlying hardware platform they're running on! Abstraction!

Only it's not an abstraction.

If you attempt to formalize what it means to map a hardware address to the virtual address you will find it quite difficult because your interface provides no information about hardware addresses. In other words the virtual method does not put in all of the details of the concrete implementation and so we cannot maintain an invariant in our specifications that would ensure that we only translate valid addresses, or that translation is deterministic -- properties that would be important for users of the abstraction to truly be able to ignore the underlying complex domain. If we could write such a specification for this virtual method though, it would be very complicated, and that is a good sign this is not a good abstraction.

Abstractions are often separate from the code because they're much more general than a single program. If we came up with a better abstraction in a formal logic like separation logic or using Hoare logic -- we might be able to prove that the properties we care about hold and therefore any program that implements this specification will have the same properties. And there might be several such programs!

So what industry programmers are often saying when they are talking about "abstraction" is "indirection and vagueness." What this article is trying to show is that we can give precise definitions to our abstractions so that we can build new _semantic_ layers that have precise meaning: when I translate a hardware address I get a valid, deterministic virtual address and nothing else.


These are very useful properties to have. And I rather use an abstraction where these properties hold, rather than one that just takes care of some plumbing. There is a qualitative difference here.


Node supports ES Modules (the import statements you mention) natively now: https://nodejs.org/api/esm.html


=> also comes straight from math learned in school. There it's written → (for function signatures), and (the more rare) ↦ for function definitions.


0.x releases are also major versions according to semver, just pre-stable. So many people were referring to React 0.x releases as "React x" that they just bumped it straight to version x.


Lambdas are constrained by their type. If you see a lambda being passed to, let's say `map`, then (assuming you know the type of `map`) you know the type of the passed lambda.

Of course this assumes the lambda is pure, but in the kind of code we're talking about (pseudofunctional code with lots of higher-order functions) they should be pure for the most part.


> (all _effect_ively research languages)

:)


eh, iirc fused-effects is used in production, along with haskell (obviously)


Was just pointing out a nice (probably unintentional) pun


The title probably changed. The URL slug still has "comes-to-an-end".


Let's take a look at how we might write a function like `map` the (pure) functional way in a language like JS:

    const head = ([x, ...xs]) => x;
    const tail = ([x, ...xs]) => xs;
    
    const map = (list, fn) => {
      if (list.length === 0) {
        return [];
      } else {
        return [fn(head(list)), ...map(tail(list), fn)];
      }
    };
    
    map([1, 2, 3], x => x + 1); // [2, 3, 4]
We're not keeping track of any state here. Using recursion you don't need to keep track of the current element in the list for example (when you run this on a physical machine it will of course, but not at the conceptual level).


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: