Slots

Camille and Marcus, thank you for your response. I thought something was missing, so the testing of Slots will be shelved for now; however, while it is in the planning stage, I would like to add some thoughts on targets and deliverable products (applications).

I agree that most devices like the iPad and iPhone would not be suitable for development, they should be targets for application development and I would expand that list to include all devices, even micro-controllers. Look at the development process for the iPad and iPhone, the programming is done on a Mac using Xcode and testing is done first on the simulator running on the Mac and latter on the actual device. I find the Xcode environment inferior to Smalltalk's and by no stretch of the imagination is Objective-C a good substitute for Smalltalk. I think that development of application programs could be done far better with Smalltalk, provided that some tools were added to Smalltalk. Why not have the view, if it can be programmed in C then it can be programmed in Smalltalk.

I think that the application process should be viewed as a series of steps culminating in the production of a product for sale or distribution: develop and test the program logic, test using constraints imposed by the target device, performance testing, test on the target device, and package for sale or distribution. A good examples of the second step where the constraints of the target is imposed are the word size and floating-point precision differences found in the target. If the development of the application is on a 64-bit computer then integer and floating-point calculated must be simulated for targets with smaller word size and for 32-bit floating-point or no floating-point processor.

Implicit in those steps is the notion a gradual typing, the first uses the Smalltalk model to generically test the logic of the program, while the final step would require a fully compiled executable for some of the targets. I would argue that one reason that Smalltalk was not a commercial success was that you could not provide a fully compiled executable to the customer. The tools that the Smalltalk environment provides makes it a very productive application development environment, but of what use are they to the end user of the application, say a clerk or a business executive: why should any of the development tools be in the final product?

It is clear that Slots will be used in the enforcement of typing at the instance variable level, but what about temporary variables? Can a compiler (machine not bytecode) be developed if temporary variables are not typed? Then there is the question of how to handle the elements of heterogeneous collections.

I have more thoughts, but the above are related to Slots. Any comments?

On 09 Jun 2014, at 13:55, Bob Williams <[hidden email]> wrote:

Camille and Marcus, thank you for your response. I thought something was missing, so the testing of Slots will be shelved for now; however, while it is in the planning stage, I would like to add some thoughts on targets and deliverable products (applications).

I agree that most devices like the iPad and iPhone would not be suitable for development, they should be targets for application development and I would expand that list to include all devices, even micro-controllers. Look at the development process for the iPad and iPhone, the programming is done on a Mac using Xcode and testing is done first on the simulator running on the Mac and latter on the actual device. I find the Xcode environment inferior to Smalltalk's and by no stretch of the imagination is Objective-C a good substitute for Smalltalk. I think that development of application programs could be done far better with Smalltalk, provided that some tools were added to Smalltalk. Why not have the view, if it can be programmed in C then it can be programmed in Smalltalk.

I think that the application process should be viewed as a series of steps culminating in the production of a product for sale or distribution: develop and test the program logic, test using constraints imposed by the target device, performance testing, test on the target device, and package for sale or distribution. A good examples of the second step where the constraints of the target is imposed are the word size and floating-point precision differences found in the target. If the development of the application is on a 64-bit computer then integer and floating-point calculated must be simulated for targets with smaller word size and for 32-bit floating-point or no floating-point processor.

Implicit in those steps is the notion a gradual typing, the first uses the Smalltalk model to generically test the logic of the program, while the final step would require a fully compiled executable for some of the targets. I would argue that one reason that Smalltalk was not a commercial success was that you could not provide a fully compiled executable to the customer. The tools that the Smalltalk environment provides makes it a very productive application development environment, but of what use are they to the end user of the application, say a clerk or a business executive: why should any of the development tools be in the final product?

It is clear that Slots will be used in the enforcement of typing at the instance variable level, but what about temporary variables? Can a compiler (machine not bytecode) be developed if temporary variables are not typed? Then there is the question of how to handle the elements of heterogeneous collections.

I have more thoughts, but the above are related to Slots. Any comments?

I don’t think that the main power of Slots if typing… its more slots with behavioural changes or meta data.

Slots can be used for providing typed slots, but these would just do a runtime check, slowing down everything.

It’s much more interesting for things like ProperySlots, BooleanSlots (which would be very memory efficient, typing

would be just a side effect).

For typing, the actually annotations (of ivars, temps, and casting of expressions, return types…) is not that problem…designing

a good type system is the real thing, e.g.:

http://rmod.inria.fr/web/publications/bib?query=Alle13a&display=abstract