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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Avi Bryant: MagLev recap

30 点作者 toffer将近 17 年前

2 条评论

fendale将近 17 年前
All this hype about MagLev, OODBs and Smalltalk that has come out of this Rails presentation has got me wondering about how some of this stuff works.<p>As I understand it, coding in Smalltalk involves developing code in an 'image' that is persisted to disk when you exit (sort of as if it dumps the entire memory contents to disk in a binary form that can be read back in). What sort of applications is Smalltalk suitable for? I know Seaside is a web framework, but a lot of the examples I can find show off more traditional GUI apps.<p>Does the image approach mean that Smalltalk is not really suitable for quick and dirty sys admin type scripts that you would use Perl or Ruby for?<p>I am fairly sure that HN doesn't use a traditional DB - and that if I recall PG said that Viaweb didn't either. With Viaweb, when a user logged into their admin console it loaded their environment into a process (and process memory) and kept it there (I think I read that somewhere).<p>Does that mean that each user had their own Lisp process fired up and kept around, and that data was just kept in process memory (and important stuff persisted to disk somehow)?<p>What I was thinking then is that if you had a web-app like Basecamp for instance (ie, an Account with no shared data between accounts), would it be technically feasible to have a different Smalltalk image for every single account that is loaded only when that account is being used, with basically all the account data inside the image? I am thinking memory could be a serious limiting factor here!<p>Sorry for the long rambling post - just trying to get my head around this stuff - hopefully someone on here knows something about it ...
评论 #206249 未加载
评论 #206317 未加载
评论 #206169 未加载
wallflower将近 17 年前
As an undercover Java guy at RailsConf and someone who worked with Gemstone/J, I am starting to think that Gemstone has finally found the passionate niche that it's always been looking to find. Rails and Ruby. The only thing Rails codes dislike more than Java is SQL
评论 #206671 未加载