I think you answered your own question. A small core is small since it is limited to what is required to make it run. This eases development and lets you focus on what's important and interesting.
On Jun 4, 2011 6:06 PM, "Scott McLoughlin" <scottmc...@gmail.com> wrote: > > Kind Folks, > > I just feel obligated to say that I had absolutely no intention > of introducing the far too well-worn debate between untyped, > latently typed and manifestly typed languages. > > My intention was to far more specifically ask: why "small > core, user comprehensible and modifiable, and boot-strapable" > systems seem to be the province of either latently typed (Smalltak, > Lisp, Scheme, Icon (?), etc.) or untyped (Forth, B (?)) languages > rather than... > > ...manifestly typed languages (wide variety - C++, D, Oberon, > Haskell, Standard ML and oodles more). > > This is a very highly contextual question, I believe apropos of > this mailing list. > > Mucho thanks again, in advance. > > - S. > > > On 6/4/2011 11:27 AM, Michael Forster wrote: >> >> On Sat, Jun 4, 2011 at 10:08 AM, Alan Kay<alan.n...@yahoo.com> wrote: >> [...] >>> >>> This left the other question and possible motivation for static type >>> checking, which was: could the tradeoffs it imposed still wind up helping >>> the programmers more than bogging them down? >>> >>> The extreme case of this -- where the variables are actually constrained to >>> the specific values they are supposed to contain -- would be very useful if >>> it could be made to generally work -- it amounts to declarative programming. >> >> A specific case only, but a useful one: SQL. (Even if it is an >> "ad-hoc, informally-specified, bug-ridden, slow implementation of >> half" of the relational model.) >> >> >>> Another extreme case would concern procedures/methods (we've called it >>> "semantic typing"). For example, we want to find an operator that will do >>> something specific -- like the sine function -- and we type our local name >>> for this so that the only value it can have is a procedure that will compute >>> sine. We could think of this as a kind of unit test for resources, or we >>> could think of this as search criteria. Ted Kaehler implemented the Squeak >>> method finder to do some of this. You give it examples of relations and it >>> finds the methods. So 3 . 4 . 7 will yield both "+" and "xor". 30 . 0.5 will >>> find "degreeSine", etc. >> >> [...] >>> >>> It's always seemed to me that what we really need to be working on is >>> something more like "real specifications that execute to produce prototypes >>> (and can be debugged) much more than weak schemes that are complex enough to >>> introduce severe cognitive load, but aren't comprehensive enough to come >>> close to paying their way. >> >> >> A small step along the path? Haskell's type system and the Hoogle >> Haskell API search engine: >> >> http://haskell.org/hoogle/ >> >> >> Regards, >> >> Mike >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
