Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We're Building Observable

observablehq.com

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Why We're Building Observable

#81

Post by justanothersys »

tlarkworthy wrote: post #25

I am a huge fan of Observable and I think it has massive potential beyond visualizations. To me it's the holy grail of a development environment, there is no separation between development and output. There is no toolchain separating source and binary, infact, the binary is partially recomputed on changes. On top, it is forkable for others to build upon. It support comments, its reactive. When I explain it to people…

I also found Observable and spent a week or so rebuilding https://nopaint.art in it! I really liked how you could export a Notebook and it would pull in all the dependencies to make a SPA. I think it would be such a beautiful way to develop my software with other people. (Edit: I only built a prototype that has not been released, but I still believe it would be viable over the current game engine I'm using, especially for collaboration.)

Re: Why We're Building Observable

#82

Post by j-pb »

kowlo wrote: post #67
j-pb wrote: post #59

Earlier quoted context omitted.

"You can't self-host with Observable." You can self host observble, but you can't self host observablehq. Literate programming just means the combination of code and documentation/visualisation. Observablehq provides a nice inline code editor, but that's incidental to what observable is. Git can also be used with a GUI but that GUI is not essential to what git is. Simularly observable notebooks can just as well be cr…

I can see the ambiguity in what you've quoted, but it's clarified in the sentence that immediately follows it. It was referring to the "literate programming environment".

The definition of literate programming environment doesn't include the requirement of a GUI.

Knuths original literate programming environment consisted of a command line tool to split files that mixed pascal and tex into the pascal and tex source, to be compiled separately.

Which means that according to your definition, the original literate programming system, isn't literate programming.

Re: Why We're Building Observable

#83

Post by kowlo »

j-pb wrote: post #82
kowlo wrote: post #67

Earlier quoted context omitted.

I can see the ambiguity in what you've quoted, but it's clarified in the sentence that immediately follows it. It was referring to the "literate programming environment".

The definition of literate programming environment doesn't include the requirement of a GUI. Knuths original literate programming environment consisted of a command line tool to split files that mixed pascal and tex into the pascal and tex source, to be compiled separately. Which means that according to your definition, the original literate programming system, isn't literate programming.

I think you've steered this discussion away from the factual point that I made.

All the best.

Re: Why We're Building Observable

#84

Post by j-pb »

kowlo wrote: post #83
j-pb wrote: post #82

Earlier quoted context omitted.

The definition of literate programming environment doesn't include the requirement of a GUI. Knuths original literate programming environment consisted of a command line tool to split files that mixed pascal and tex into the pascal and tex source, to be compiled separately. Which means that according to your definition, the original literate programming system, isn't literate programming.

I think you've steered this discussion away from the factual point that I made. All the best.

I think you're fundamentally misunderstanding the architecture, capabilities and relationships between observable and observablehq. Not having a button next to each cell to edit it in place, is not going to impact your productivity in any way, when you can just edit the cell in the window to the left. Wether it's below or left isn't a meaningful difference, and shouldn't have an impact on wether or not it's a suitable replacement or superior/inferior to other notebooks.

Hope you'll look at it again in the future. In a sense it's your loss, so good luck and take care.

Re: Why We're Building Observable

#85

Post by what_is_this_98 »

j-pb wrote: post #84
kowlo wrote: post #83

Earlier quoted context omitted.

I think you've steered this discussion away from the factual point that I made. All the best.

I think you're fundamentally misunderstanding the architecture, capabilities and relationships between observable and observablehq. Not having a button next to each cell to edit it in place, is not going to impact your productivity in any way, when you can just edit the cell in the window to the left. Wether it's below or left isn't a meaningful difference, and shouldn't have an impact on wether or not it's a suitabl…

it doesn't look like they've misunderstood anything, are you a shill or simply not reading anything? it's cringeworthy

Re: Why We're Building Observable

#86

Post by lmeyerov »

tracyhenry wrote: post #80
lmeyerov wrote: post #79

Earlier quoted context omitted.

This feels close to a lot of our thinking and why some of those pieces were originally written :) We (the Graphistry team) wrote the original Arrow JS implementation to help us bridge GPU visual analytics components in the browser with real-time GPU clusters in the data center, and our backend is DSLs like dataframes to make it easier to do that. An interesting thing to me here is the layering of DSLs. E.g., SQL enab…

Thanks for the thoughts. Graphistry looks really slick and interesting. On thing I'm curious about: how do you compare Graphistry with OmniSci and similar GPU-based solutions? You seem to focus on a niche - graph visualizations. That's one differentiator I can tell. Do other solutions support graphs too? If so, how do you compare Graphistry with them? Btw, if you referred to the 1M-row example I posted - we actually…

Fundamentally, omnisci locks you into:

- omnisci SQL. in contrast, rapids.ai opens layers below (cudf arrow, dask, ...) that enable cooperating solns on top (blazingsql, cugraph, custreams, prefect, ...) that are faster + easier for their domains, w fallback to general dataframes/sql.

-- omnisci is governance by a VC co, while rapids.ai is by nvidia (who wants to sell hw, not sw) and more OSS partners

Omnisci did good engineering, so it does have strengths. ex: its geospatial visual analytics means it's a good esri alternative consideration, as it is more polished than manually stitching together cuspatial + blazingsql + leaflet etc. Likewise, commercially polished for hostile enterprise environments (procurement, ...).

re:scale, see rapids tpcx-bb numbers ('big data'), I think on 10TB datasets. it shows scale + cost effectiveness wins vs others. less obvious, out-of-core so can do TBs even on one GPU, and full tpcx-bb needed the above versatility where sql is a kludge.

re:graph vs table, if you do just points and no edges, the node table is just a regular table you can do regular tabular data analysis + viz in. ex: load in samples scored by some ml model (x/y plot w lots of data columns for each point), then connect nearest neighbors to make it into an interactive graph. we are doing more and more here in practice, it's fun :)

Post reply on HN