|
|
|
|
|
|
by davidkell
2054 days ago
|
|
|
The two places I’ve seen this working best today: - Open source data science/scientific computing ecosystems. Notably python, where all the libraries interop seamlessly via numpy/pandas/arrow and Jupyter is the visual coding platform. But also R/tidyverse and Julia. - Modern “no-code” tools, where the visual coding is Notion/Coda/Bubble, interfaces via Zapier/Integromat/Autocode and data models in Airtable/Sheets. (Many of these tools use the word “block” as part of the UX) And ofc, we take it for granted but the concept of a “file” is the ultimate building block for applications. In my experience, commercial disincentives aside, the main trade off for this power/flexibility is the complexity. It is intimidating for new users, and hard to design well for because of the combinatorial explosion of interactions. Users need to be strongly motivated to get over this complexity hump - whereas most users, most of the time want a single happy path. Personally I don’t see this as a negative thing - you are essentially coding best practices into the tool. As an aside, the instant feedback coding in python looks fantastic! Could be a fantastic extension eg for Jupyterlab or VSCode. |
|
|
Yes. I love me some abstraction and building blocks. We constantly think about them because it helps the product be flexible by design in situations we haven't thought about.
Similar abstractions and building blocks or "units of computational thought", although not "perfect": Docker containers, Jupyter notebooks.
>In my experience, commercial disincentives aside, the main trade off for this power/flexibility is the complexity. It is intimidating for new users, and hard to design well for because of the combinatorial explosion of interactions. Users need to be strongly motivated to get over this complexity hump - whereas most users, most of the time want a single happy path. Personally I don’t see this as a negative thing - you are essentially coding best practices into the tool.
I agree. Complexity is not going anywhere, it just is a matter to decide who inherits it and at what level. For example, we're making our machine learning platform[0] after years of custom ML products to help us. We have different profiles: some of them can move between training a neural network, building custom connectors for esoteric data sources, setting up infrastructure, and running cable. Others live and breathe in a notebook who have trouble setting up the proper environment.
What we do is that we build a product that handles most things for the latter profile, but gives the possibility for advanced users to tweak things. One of the reasons we haven't adopted other products is that because they were way too restrictive. Point and click, no API, use custom non time proven abstraction, etc. It's also because in our years of actually shipping machine learning products for paying enterprise customers, the problems we faced in machine learning projects were not for lack of snappy CSS or animations. In other words, the products we had seen were solving non problems for us. We keep an eye out for products made by people who actually shipped ML products, though.
That's one of the reasons we built functionality on top of JupyterLab, like near real-time collaboration, scheduling long-running notebooks, and automatic tracking, instead of wanting to re-create the wheel with "Our Way (TM)".
- [0]: https://iko.ai