On 09 Jun 2014, at 13:55, Bob Williams <rwilliam...@cox.net> 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
Marcus
