TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The program is the database is the interface

137 点作者 jgrodziski超过 2 年前

12 条评论

TuringTest超过 2 年前
Since its inception, computers were based on the model of a machine traversed by data that are processed like sausages in a mincer, as data was fed directly on hardware which had code assembled as physical wires.<p>However, the software part of the machines is made of the same material as the data, so they are much closer to what current programming languages seem to imply.<p>It is natural that they tend to converge, especially in Lisp-like languages, into a type of program where the structure has code and data intermingled, which organically co-evolve in the directions in which problem solving takes it.<p>Instead of a machine with a processing pipeline, a closer metaphor might be the phloem of plants, the living cells that transport food, and which form part of the plant&#x27;s structure and grow along with it.<p>(BTW I&#x27;ve coined a name for that kind of self-rendered cells, processed in place as collections of data sharing the same structure; I call them <i>&#x27;wits&#x27;</i> - as in, <i>the minimum unit of meaning</i>; in parallel to bits as the minimum unit of information. And if you look closely, you&#x27;ll begin to see that a lot of modern programming systems have them everywhere. So you may want to use this term &#x27;a <i>wit</i>&#x27; to describe the concept explained in the article.)
评论 #34771716 未加载
评论 #34771225 未加载
评论 #34774058 未加载
评论 #34776814 未加载
Twisell超过 2 年前
Whenever I stumble on an article like that*, I can&#x27;t stop wondering why do so many developers think that SQL is hard&#x2F;clunky in comparaison?<p>*(any article where author seemingly rebuild a database engine from scratch with maybe 0,1% to 1% of features count present in any RDBMS including sqlite)
评论 #34771007 未加载
评论 #34772630 未加载
评论 #34772404 未加载
评论 #34773352 未加载
评论 #34774559 未加载
评论 #34773112 未加载
Kinrany超过 2 年前
Next step: UI components a-la <a href="http:&#x2F;&#x2F;witheve.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;witheve.com&#x2F;</a>
评论 #34774486 未加载
评论 #34770844 未加载
habibur超过 2 年前
Another alternate is to use Excel.<p>The downsides being [compared to this one] :<p>- Excel is more bulky. Takes time to start.<p>- You are forced to use Excel&#x27;s editor, and not any editor of your choice.
评论 #34771363 未加载
vlz超过 2 年前
This is like Jupyter notebooks for clojure with UI elements. Certainly helpful for small applications.<p>Jupyter seems to have community support for other languages though[1] including clojure, so it would be nice to see how that compares.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;jupyter&#x2F;jupyter&#x2F;wiki&#x2F;Jupyter-kernels">https:&#x2F;&#x2F;github.com&#x2F;jupyter&#x2F;jupyter&#x2F;wiki&#x2F;Jupyter-kernels</a>
评论 #34771844 未加载
marttt超过 2 年前
I&#x27;ve had a similar experience using the sam [1] text editor in command line mode, basically like a REPL. Filtering and modifying data using sam&#x27;s &quot;structural regular expressions&quot;. Rob Pike, the author of sam, specifically points out in the linked paper that the command language is great for manipulating multi-line &quot;records&quot;.<p>Add the ability to { nest { expressions } } + very flexible file system IO (e.g. pipe selection to an external command and return the result), and you have a really nice recursive querying language. I specifically like it because of how easy it is to refine the query&#x2F;regex substitution when it didn&#x27;t yield the expected result.<p>1: <a href="http:&#x2F;&#x2F;doc.cat-v.org&#x2F;plan_9&#x2F;4th_edition&#x2F;papers&#x2F;sam&#x2F;" rel="nofollow">http:&#x2F;&#x2F;doc.cat-v.org&#x2F;plan_9&#x2F;4th_edition&#x2F;papers&#x2F;sam&#x2F;</a> (In particular, scroll to the &quot;Structural Regular Expressions&quot; section.)
samsquire超过 2 年前
This is interesting.<p>I do wonder what the ergonomics of querying data is for people who are unfamiliar with your APIs, they may prefer to query the data with SQL or a cursor based API.<p>The volcano model for querying in SQL databases is useful but I&#x27;ve never implemented that. (Kind of hard to query about though on Google)<p><a href="https:&#x2F;&#x2F;www.computer.org&#x2F;csdl&#x2F;journal&#x2F;tk&#x2F;1994&#x2F;01&#x2F;k0120&#x2F;13rRUwI5TRe" rel="nofollow">https:&#x2F;&#x2F;www.computer.org&#x2F;csdl&#x2F;journal&#x2F;tk&#x2F;1994&#x2F;01&#x2F;k0120&#x2F;13rRU...</a>
alxmng超过 2 年前
So, a spreadsheet?
评论 #34799291 未加载
blatant303超过 2 年前
<a href="https:&#x2F;&#x2F;www.hyperfiddle.net" rel="nofollow">https:&#x2F;&#x2F;www.hyperfiddle.net</a>
pvillano超过 2 年前
you might be interested in <a href="https:&#x2F;&#x2F;youtu.be&#x2F;HB5TrK7A4pI" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;HB5TrK7A4pI</a><p>&quot;We Really Don&#x27;t Know How to Compute!&quot;- Gerald Sussman (2011) [1:04:18]
jokethrowaway超过 2 年前
you could also just have a string tag field, avoiding some inference which need to be often overwritten<p>I use your typical boring spreadsheet and it&#x27;s mostly just numbers and strings with a few sums for totals
jacoblambda超过 2 年前
Is there a reason to homeroll your accounting like this vs using one of the plain text accounting tools and their scripting interfaces?
评论 #34772774 未加载
评论 #34771071 未加载
评论 #34770767 未加载