On Feb 13, 3:36 pm, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> You don't seem to have learned the lesson of the philosophy. The > "solution" isn't to compactify and remove white space until it fits on > a screen. That is like fulfilling a 5 page essay requirement by > tweaking the font size. It fulfills the text of the requirement while > violating the spirit.
Using wider margins also works, and seems to be harder for most teachers to detect. ;-)
> Of course, I tend to use 100 row screens now, so what constitutes one > screen is up for debate.
Indeed; I use 24 lines, minus two or three eaten up by emacs for the minibuffer and buffer titles (and often half of that when I have the compile log open).
I have functions that are 500 lines and more. It's not ideal, but sometimes there's just so much state information to keep track of that splitting it up will only make things harder to find.
*Indentation* is much more troublesome, OTOH - especially if it has to be tracked between screens. My threshold is around 5-6 levels; after that I start considering moving things around. But as long as the code is commented, consistently formatted and kept as "flat" as possible, I don't think the *length* of functions matters much.
On 2008-02-13, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> His hatred of static types seems entirely misplaced. I think he hates > the excessive boiler plating most static type implementations impose. > Having had the opportunity to use Haskell recently, it really shows > why static types don't require any extra typing. Calling static types > "meta-data" is like calling unit tests "meta-data".
As far as I've been able to tell, Yegge's issues with static typing are a bit more subtle and have to do with static type systems' difficulties in doing reflection. This makes it difficult to do all sorts of metaprogramming tricks and hacks you can find in Lisp and Smalltalk for example.
On 2008-02-23 09:20:31, Risto Saarelma <rsaar...@gmail.com> wrote:
> On 2008-02-13, Jeff Lait wrote: > > His hatred of static types seems entirely misplaced. I think he hates > > the excessive boiler plating most static type implementations impose. > > Having had the opportunity to use Haskell recently, it really shows > > why static types don't require any extra typing. Calling static types > > "meta-data" is like calling unit tests "meta-data".
> As far as I've been able to tell, Yegge's issues with static typing are > a bit more subtle and have to do with static type systems' difficulties > in doing reflection. This makes it difficult to do all sorts of > metaprogramming tricks and hacks you can find in Lisp and Smalltalk for > example.
Interesting read (and one which has much useful thought regardless of my personal bias).
I would suggest that hot-swapping (self-modifying) code is even more limited by not having a realtime source compiler/interpreter, in conjunction with incremental linking. That is, the key element of hot-swapping code is having an eval technique (using JavaScript/Perl notation). The equivalent flexibility for a static-typed language would be to invoke a compiler and then link in the just-compiled function in real-time, but a first step would be dynamic loading of modules/plugins.
I think we have this already for byte-code compiled languages (e.g., Perl), but machine-compiled languages aren't quite there yet.
>The equivalent flexibility for a static-typed language would be to >invoke a compiler and then link in the just-compiled function in >real-time, but a first step would be dynamic loading of >modules/plugins.
It's called dlopen(), and it's specified in POSIX 1003.1-2003. -- \_\/_/ some girls wander by mistake into the mess that scalpels make \ / are you the teachers of my heart? we teach old hearts to break \/ --- Leonard Cohen, "Teachers"
Risto Saarelma wrote: > On 2008-02-13, Jeff Lait <torespondisfut...@hotmail.com> wrote: >> His hatred of static types seems entirely misplaced. I think he hates >> the excessive boiler plating most static type implementations impose. >> Having had the opportunity to use Haskell recently, it really shows >> why static types don't require any extra typing. Calling static types >> "meta-data" is like calling unit tests "meta-data".
> As far as I've been able to tell, Yegge's issues with static typing are > a bit more subtle and have to do with static type systems' difficulties > in doing reflection. This makes it difficult to do all sorts of > metaprogramming tricks and hacks you can find in Lisp and Smalltalk for > example.
I wonder if he thinks it counts when you can: save a module's precise state, completely unload it, and reload the new version, which accepts the old state and continues. There is a library to do that in Haskell (I forget what it is called). It is an easier technique than in other languages as Haskell's use of mutable state is constrained. With little change, the state-saving for reloading a module can be made to serialise the entire application state to disk.
Also, "traditional" Forth starts off with a dictionary that contains the built-in words and the compiler, and applications are compiled and linked directly on top of it; they extend the existing dictionary by adding words to it. This is all done by interpreting arbitrary Forth code, so there is no "boundary" between built-in words, the compiler, and applications words, and no need for relocatable object code. Rather like his beloved LISP.
> I wonder if he thinks it counts when you can: save a module's precise > state, completely unload it, and reload the new version, which accepts > the old state and continues. There is a library to do that in Haskell > (I forget what it is called).
Oops! As (the infamous) Philippa says in the first comment, it is called hs-plugins:
> On 2008-02-13, Jeff Lait <torespondisfut...@hotmail.com> wrote:
> > His hatred of static types seems entirely misplaced. I think he hates > > the excessive boiler plating most static type implementations impose. > > Having had the opportunity to use Haskell recently, it really shows > > why static types don't require any extra typing. Calling static types > > "meta-data" is like calling unit tests "meta-data".
> As far as I've been able to tell, Yegge's issues with static typing are > a bit more subtle and have to do with static type systems' difficulties > in doing reflection. This makes it difficult to do all sorts of > metaprogramming tricks and hacks you can find in Lisp and Smalltalk for > example.
First, I think that static typing has little to do with being able to make a system that doesn't need to reboot or can be hotswapped. We already mentioned Edit and Continue in MSVC++, which clearly demonstrates it is not impossible to build such a system.
His rant, while interesting, doesn't in the quick skim I gave it address the true downfall of systems that never reboot. If you go too long without rebooting, the system won't be rebootable. This is why console games are limited as a FEATURE, not a mistake. The entire design philosophy of console games and hardware is the blank-slate starting conditions. This makes it practical to guarantee that the system *will* work *every* time you run it. Very important when your code is burned on a ROM.
It used to be very fashionable to have year long uptimes. It seems the consensus now is to instead intentionally reboot systems to make sure they are not accumulating magic cruft that prevents them from being rebooted. I've had my experience of linux boxes that decided not to power on again because one too many patch was run on the live system.
The other big problem is that we don't need many systems. I don't want Nethack to have a full shell - that is what my actual command line shell is! Likewise, it would be a misfeature to have C++ itself be it's own OS (like smalltalk or LISP) - I already have a perfectly good OS, thank you very much.
I recently embarked in some Haskell work and will note that I've used solely the command line compiler. First, the interpreter is too slow to test against, second, programming in the interpreter means losing vi, working in a line by line mode as if I were editing the source in edlin. So while Haskell may (or may not) be "shell complete", I really couldn't care less personally. -- Jeff Lait (POWDER: http://www.zincland.com/powder)
> On Feb 23, 3:20 am, Risto Saarelma wrote: > > On 2008-02-13, Jeff Lait wrote:
> > > His hatred of static types seems entirely misplaced. I think he hates > > > the excessive boiler plating most static type implementations impose. > > > Having had the opportunity to use Haskell recently, it really shows > > > why static types don't require any extra typing. Calling static types > > > "meta-data" is like calling unit tests "meta-data".
> > As far as I've been able to tell, Yegge's issues with static typing are > > a bit more subtle and have to do with static type systems' difficulties > > in doing reflection. This makes it difficult to do all sorts of > > metaprogramming tricks and hacks you can find in Lisp and Smalltalk for > > example.
> First, I think that static typing has little to do with being able to > make a system that doesn't need to reboot or can be hotswapped. We > already mentioned Edit and Continue in MSVC++, which clearly > demonstrates it is not impossible to build such a system.
Edit and Continue in MSVC++ isn't relevant to the transhumanist religious slant Steve took on hot-swapping. What he wants is for the program itself to be able to generate a function, "compile it", and hotswap it in. This is almost *essential* to actually realize a Vingean Singularity.
MSVC++ Edit and Continue is entirely programmer-controlled. But static typing has little theoretical significance with program-controlled hotswapping of code; it has *much* practical significance since so far only the byte-code compiled languages have the eval capability that allows it. DLLs/plugins are a second-rate hack.
> His rant, while interesting, doesn't in the quick skim I gave it > address the true downfall of systems that never reboot. If you go too > long without rebooting, the system won't be rebootable. ...
Also note that rebooting allows practical immortality for materialist AIs: dump state on old machine, restart with that state on new machine. The awareness-process discontinuity could well be no worse than sleep or anesthesia is for us.
The objections he posits *assume* that a computer AI would be dualist metaphysics, which is not at all clear. Not only do we know whether *we* use dualist metaphysics (and if so, that may merely be a limited definition of "matter and energy"), even if that were granted that would not prove that a materialist AI was unconstructable.
