5 ms·

I’m always amused that this is called a magazine. At least this particular issue. It’s nearly 500 pages long!! My favorite chapter in the tome is the one by Pe

I’m always amused that this is called a magazine. At least this particular issue. It’s nearly 500 pages long!! My favorite chapter in the tome is the one by Peter Deutsch on control structures. Starts on page 322. I did Smalltalk for 20 years. I don’t have right words to express how much I loved the Smalltalk block closure, the fact that it was a reified object type that you could extend and use polymorphically is one of the unsung geniuses in Smalltalk. Every time I use python lambdas or Swift’s closures or Kotlin’s closures (the three closure enabled languages I use most today), I just sigh and wish.

coldtea 7y ago
>I loved the Smalltalk block closure, the fact that it was a reified object type that you could extend and use polymorphically Some example of that?
- CodeArtisan 7y ago
  Memoization. You could add a method to the class implementing blocks. Block>>memoize "Return a memoized one-argument block" | cache | cache := Map new. ^[:arg | cache at: arg ifAbsentPut: [self value: arg]] aBlock := [:foo | foo + 1]. aBlockMemoized := aBlock memoize.
jolmg 7y ago
I believe Ruby's blocks are based on Smalltalk's blocks. Could you describe how Ruby's blocks might be lacking in comparison to Smalltalk's?
- scroot 7y ago
  In Smalltalk, blocks are actual objects in the system like everything else. You can send messages to them (I don't think Ruby allows this). In fact, that's the only way to get something out of a block -- send it the message #value (without args) or #value: (with args) to get some response back. As the poster above you mentioned, you can then create your own objects that are polymorphic to this pattern if you need to. In other words, make your own object respond to the #value/#value: messages and other objects in the system that are, say, expecting a block can use your custom object all the same. Objects that are polymorphic with blocks are often called "valuables" precisely because they respond to the #value messages.
  - jolmg 7y ago
    > In Smalltalk, blocks are actual objects in the system like everything else. You can send messages to them (I don't think Ruby allows this). Actually, blocks are Proc objects in Ruby: irb> def f(&b); b.call b.class; end; f {|x| "foo #{x}"} => "foo Proc" > In other words, make your own object respond to the #value/#value: messages and other objects in the system that are, say, expecting a block can use your custom object all the same. Are there not other messages that they might depend on that would also need to be implemented? I'm having a hard-time thinking of a case where polymorphic blocks might be useful. Then again, I think Rack middleware (used in Rails for error handling and other things) are somewhat like what you're basically saying, since to define a middleware you mostly just need to define a `call` function. Yet, I'm not sure I'd consider this a block. Maybe the idea would be having the option to use simple blocks as middleware, but having the option to do something more complicated if one wants it.
    - scroot 7y ago
      Aha interesting!
    - scroot 7y ago
      > Are there not other messages that they might depend on that would also need to be implemented? The answer to this is "maybe" but it doesn't really matter. You only need to implement the messages that will be sent by other objects and for "valuables" what we care about are the #value/#value: messages for the most part. We can think of this as some kind of delayed evaluation. Perhaps we define an object who, when sent the #value message, goes off and fetches information from the net or something. We wait until the #value message is sent before doing so, just like we wait to evaluate a block until #value is sent. An example of methods on Blocks that exist but probably don't need to be implemented for polymorphism are things like #fork and #forkAt which will run the block in it's own separate Process.
      - jolmg 7y ago
        > The answer to this is "maybe" but it doesn't really matter. You only need to implement the messages that will be sent by other objects and for "valuables" what we care about are the #value/#value: messages for the most part. If one is trying to pass a block-like object to a message that is expecting a block and which we cannot be easily sure is not dependent on other messages under obscure conditions, is it not easier to extend from / inherit whatever class the blocks in Smalltalk use (i.e. the equivalent of Proc in Ruby)? Or is it that documentation of such methods explicitly mention that they support not just Smalltalk blocks but also other "valuables"? > An example of methods on Blocks that exist but probably don't need to be implemented for polymorphism are things like #fork and #forkAt which will run the block in it's own separate Process. I mean, sure, you can intuitively guess that such messages might not be needed, but it might not always be such an easy thing to guess. Ruby Procs have the methods `arity` and `parameters` for example, which could be widely used to inspect the parameters accepted by a block to decide how to pass arguments in. I never used such methods, but it might be that methods from other libraries to which I pass these blocks could use them. I don't know. I guess it could be a language culture thing. Dependence on only `#value` / `#value:` could be common convention in Smalltalk if usage of valuables is a more common idiom.
protomyth 7y ago
I’m always amused that this is called a magazine. At least this particular issue. It’s nearly 500 pages long!! Those magazine tended to be big, but Byte was at the top of its class. The only thing bigger I can remember was Computer Shopper, and that was massive.
- seanmcdirmid 7y ago
  Byte had a bit more content, computer shopper was mostly ads.
  - analog31 7y ago
    Indeed, it was pretty typical to have a subscription to Byte, but buy an issue of Computer Shopper just when it was time to get a new computer. That, or see if someone else already had a recent issue.
    - heelix 7y ago
      It was the place to mail order components too! If you were building a system back in those days, that was one of the better tomes to dig through to find deals. That was really the only good place to find competitive offerings of a VESA local bus video card and find venders who you could trust. Good times.
  - protomyth 7y ago
    Computer Shopper actually had some pretty good columnists working for it. Also, in a lot of ways at that time in the industry, the ads were great content.
- maire 7y ago
  Byte magazine was like a paper github. People published everything including the source code for BITBLT. A scoundrel later patented BITBLT and sued Xerox! It wasn't difficult for Xerox defend against the fake patent since it was published in Byte. One issue had the entire source code for the Star Trek game written in Basic. This brings back memories.
ChuckMcM 7y ago
It is the effect of the Internet of course. Magazines could (and did) publish articles that other magazines had covered and they they themselves had previously covered, which boosted the number of "editorial" pages, which gave them more pages for advertising. Most editors were sensitive to the ratio of editorial (content) to ads. That ratio indicated a level of "seriousness" to the content, if it was all content ("a true journal had no advertising and is bought for its cutting edge knowledge") to mostly ads ("an advertising vehicle with some grabby headline to get it into your hands.") Price was proportional to, from very expensive (journal subscription) to free (weekly advertiser).

coldtea 7y ago

>I loved the Smalltalk block closure, the fact that it was a reified object type that you could extend and use polymorphically Some example of that?

CodeArtisan 7y ago
Memoization. You could add a method to the class implementing blocks. Block>>memoize "Return a memoized one-argument block" | cache | cache := Map new. ^[:arg | cache at: arg ifAbsentPut: [self value: arg]] aBlock := [:foo | foo + 1]. aBlockMemoized := aBlock memoize.

jolmg 7y ago

I believe Ruby's blocks are based on Smalltalk's blocks. Could you describe how Ruby's blocks might be lacking in comparison to Smalltalk's?

scroot 7y ago
In Smalltalk, blocks are actual objects in the system like everything else. You can send messages to them (I don't think Ruby allows this). In fact, that's the only way to get something out of a block -- send it the message #value (without args) or #value: (with args) to get some response back. As the poster above you mentioned, you can then create your own objects that are polymorphic to this pattern if you need to. In other words, make your own object respond to the #value/#value: messages and other objects in the system that are, say, expecting a block can use your custom object all the same. Objects that are polymorphic with blocks are often called "valuables" precisely because they respond to the #value messages.
- jolmg 7y ago
  > In Smalltalk, blocks are actual objects in the system like everything else. You can send messages to them (I don't think Ruby allows this). Actually, blocks are Proc objects in Ruby: irb> def f(&b); b.call b.class; end; f {|x| "foo #{x}"} => "foo Proc" > In other words, make your own object respond to the #value/#value: messages and other objects in the system that are, say, expecting a block can use your custom object all the same. Are there not other messages that they might depend on that would also need to be implemented? I'm having a hard-time thinking of a case where polymorphic blocks might be useful. Then again, I think Rack middleware (used in Rails for error handling and other things) are somewhat like what you're basically saying, since to define a middleware you mostly just need to define a `call` function. Yet, I'm not sure I'd consider this a block. Maybe the idea would be having the option to use simple blocks as middleware, but having the option to do something more complicated if one wants it.
  - scroot 7y ago
    Aha interesting!
  - scroot 7y ago
    > Are there not other messages that they might depend on that would also need to be implemented? The answer to this is "maybe" but it doesn't really matter. You only need to implement the messages that will be sent by other objects and for "valuables" what we care about are the #value/#value: messages for the most part. We can think of this as some kind of delayed evaluation. Perhaps we define an object who, when sent the #value message, goes off and fetches information from the net or something. We wait until the #value message is sent before doing so, just like we wait to evaluate a block until #value is sent. An example of methods on Blocks that exist but probably don't need to be implemented for polymorphism are things like #fork and #forkAt which will run the block in it's own separate Process.
    - jolmg 7y ago
      > The answer to this is "maybe" but it doesn't really matter. You only need to implement the messages that will be sent by other objects and for "valuables" what we care about are the #value/#value: messages for the most part. If one is trying to pass a block-like object to a message that is expecting a block and which we cannot be easily sure is not dependent on other messages under obscure conditions, is it not easier to extend from / inherit whatever class the blocks in Smalltalk use (i.e. the equivalent of Proc in Ruby)? Or is it that documentation of such methods explicitly mention that they support not just Smalltalk blocks but also other "valuables"? > An example of methods on Blocks that exist but probably don't need to be implemented for polymorphism are things like #fork and #forkAt which will run the block in it's own separate Process. I mean, sure, you can intuitively guess that such messages might not be needed, but it might not always be such an easy thing to guess. Ruby Procs have the methods `arity` and `parameters` for example, which could be widely used to inspect the parameters accepted by a block to decide how to pass arguments in. I never used such methods, but it might be that methods from other libraries to which I pass these blocks could use them. I don't know. I guess it could be a language culture thing. Dependence on only `#value` / `#value:` could be common convention in Smalltalk if usage of valuables is a more common idiom.

protomyth 7y ago

I’m always amused that this is called a magazine. At least this particular issue. It’s nearly 500 pages long!! Those magazine tended to be big, but Byte was at the top of its class. The only thing bigger I can remember was Computer Shopper, and that was massive.

seanmcdirmid 7y ago
Byte had a bit more content, computer shopper was mostly ads.
- analog31 7y ago
  Indeed, it was pretty typical to have a subscription to Byte, but buy an issue of Computer Shopper just when it was time to get a new computer. That, or see if someone else already had a recent issue.
  - heelix 7y ago
    It was the place to mail order components too! If you were building a system back in those days, that was one of the better tomes to dig through to find deals. That was really the only good place to find competitive offerings of a VESA local bus video card and find venders who you could trust. Good times.
- protomyth 7y ago
  Computer Shopper actually had some pretty good columnists working for it. Also, in a lot of ways at that time in the industry, the ads were great content.
maire 7y ago
Byte magazine was like a paper github. People published everything including the source code for BITBLT. A scoundrel later patented BITBLT and sued Xerox! It wasn't difficult for Xerox defend against the fake patent since it was published in Byte. One issue had the entire source code for the Star Trek game written in Basic. This brings back memories.

ChuckMcM 7y ago

It is the effect of the Internet of course. Magazines could (and did) publish articles that other magazines had covered and they they themselves had previously covered, which boosted the number of "editorial" pages, which gave them more pages for advertising. Most editors were sensitive to the ratio of editorial (content) to ads. That ratio indicated a level of "seriousness" to the content, if it was all content ("a true journal had no advertising and is bought for its cutting edge knowledge") to mostly ads ("an advertising vehicle with some grabby headline to get it into your hands.") Price was proportional to, from very expensive (journal subscription) to free (weekly advertiser).