Planet Smalltalk

Position Summary

Based in SageTea’s Ottawa office and reporting to the Chief Technical Officer with guidance from the senior software developers, the Junior Software Developer will become part of a team creating a tool that redefines how software is created.

Responsibilities

• Develop and augment software features
• Create object-oriented software features as defined by the Chief Technical Officer and senior software developers
• Document all work and design notes
• Demonstrate new features internally
• Test all features to verify they comply with the design
• Follow standard coding conventions
• Read and understand functional and technical documents
• Report on current progress and meet deadlines
• Identify technical deficiencies in design
• Multitask to handle several priorities

Skills and Qualifications

• Bachelor’s degree
• Minimum 2 years related experience
• Strong object-oriented development background
• Knowledge of VisualWorks Smalltalk is an asset
• Excellent communication skills in English (both written and verbal)

Nice looking Smalltalk/Gemstone job in banking in Zuerich. 

Zuerich is a nice city and there are loads of banks.

The latest release of Essence# introduces the ability to invoke .Net methods that have “out” or “ref” parameters. This post will explain what those are, why supporting them is a technical challenge, and how to pass such parameters to .Net methods that use them.

Conceptually, there are only two ways to pass parameters to functions: By value or by reference. Although there are (usually rather old or even ancient) programming languages that pass all parameters “by reference,” most programming languages pass parameters “by value” in the default case. And some languages, such as Essence#, pass all parameters “by value.”

The following example will be used to illustrate the difference in the semantics:

var x = 3;
var y = f(x);

If the variable x is passed to the function f as a “by value” parameter, then it will be impossible for the function f to change the value of the variable x. However, if the variable x is passed to the function f as a “by reference” parameter, then the function f will be able to change the value of the variable x (although it may nevertheless refrain from doing so.)

Although there is more than one way to implement the two different ways of passing parameters, conceptually the difference is that, when arguments are passed “by value,” only the value of the argument is passed in to the function being called, whereas when arguments are passed “by reference,” the address of the argument (typically, the address of a variable) is passed in to the function being called. In the latter case, the called function may use that address to assign a new value to the variable–although it need not do so.

In fact, many languages implement “pass by value” semantics by physically passing in the address of the arguments that are passed “by value,” but nevertheless disallowing assignment to function parameters. As Peter Deutsch famously said, “you can cheat as long as you don’t get caught.” However, neither the CLR nor the DLR’s LINQ expression compiler cheat in that way: Unless a parameter is declared to require “pass by reference” semantics, arguments are passed by copying their values into the activation frame of the function being invoked.

So the problem for languages implemented on the CLR, such as Essence#, that have no syntax for specifying that parameters will be passed “by reference,” is that there’s no straightforward way to invoke the methods of CLR types that have any “pass by reference” parameters, where the intended usage is that the called method will, as part of its normal operation, assign a new value to an argument that is passed by reference.

And there’s an additional complication: Some methods that use “pass by reference” parameters will neither need nor use the initial value of the parameter, because they only set its value, and never “read” it. Conversely, others will use the initial value to compute and set a new value for the argument. And yet others may do one or the other with the same parameter, depending on the state of the receiver and the value of other parameters.

The C# language attempts to reduce the ambiguity regarding the usage model of “by reference” parameters by requiring that the method definer use different syntax to declare parameters, depending on whether the method will or will not use the initial value of a “by reference” parameter to compute and then set the argument’s new value. In the C# syntax, a parameter that is passed by reference must have one of two keywords as a prefix: out or ref.

The C# out keyword causes the compiler to require that the method that declares the parameter must first assign a value to the parameter before the parameter can be used–and before the method can return. That makes it impossible to use or access the initial value of the parameter. In contrast, the C# ref keyword causes the compiler to require that whoever invokes the method must first assign a value to the parameter.

But C# is not the only language used on the CLR, and the CLR itself does not enforce any constraints on the usage of “by reference” parameters. A .Net language’s compiler may do so, but such is not required by the CLR. That means there may exist .Net types that have methods that use “pass by reference” parameters that do not abide by the rules of C#.

The reflection metadata provided by the CLR does reveal, for each method parameter, whether it is a “pass by value” or a “pass by reference” parameter.  It may also reveal whether the intended usage of a “pass by reference” parameter is as a C#-style out parameter. But compilers are not required to provide that particular piece of metadata. The parameter may be used as an out parameter even if the reflection metadata makes no such claim. The only information provided by the reflection metadata that must be accurate is whether or not the parameter requires that its corresponding argument be passed “by value” or “by reference.”

So for now, Essence# deals with .Net method parameters that require that arguments must be passed by reference in one of two ways:

If the actual argument at runtime is anything other than a block or delegate, the dynamic binding subsystem will create and initialize a new variable that will be passed as the argument. Unless the reflection metadata claims that the parameter is an “out” parameter, the variable will be initialized to have the same value as the argument specified by the invoking code. The method will then be invoked with that new variable as the argument corresponding to the “by reference” parameter. When the method completes, the value of the created variable that was passed in as the actual argument will be assigned to the expression that represents the originally-specified argument. That assignment may cause an exception, and it may fail to update the original variable. I’m researching improvements, perhaps using the DLR’s Meta Object Protocol.

However, if the actual argument at runtime is a block or delegate, then the dynamic binding subsystem will create and initialize a new variable that will be passed as the argument (just as it does for the other case.) The method will then be invoked with that new variable as the argument corresponding to the “by reference” parameter (still essentially the same procedure as in the other case.) But when the method completes, the procedure is different: The one-argument block or delegate that was the originally-specified argument will be invoked, with the newly-created variable as its argument. That permits the caller to access the value of the “out” parameter, because its value will be the value of the block (or delegate) argument. Note, however, that the block or delegate must have an arity of one, and if it’s a delegate, its parameter type must be assignable from the parameter type of the invoked method’s parameter.

Example Usage

Let’s assume that we want to invoke the method Get as defined in the C# class named ValueModel shown below:

class ValueModel {
        private static readonly Object notAValue = new Object();

        protected Object value = notAValue;

        public bool HasValue {
                get {return value != notAValue;}
        }

        public void Set(Object newValue) {
                value = newValue;
        }

        public bool Get(out Object value) {
                if (HasValue) {
                        value = this.value;
                        return true;
                }
                return false;
        }
}

If we have an instance of the above ValueModel class in a variable named model (in an Essence# block or method,) we can invoke the Get method as follows:

[:model |
        | value |
        (model get: [:v | value := v])
                ifTrue: [value doSomethingUseful]
]

Or more simply, we could just do:

[:model | model get: [:value | value doSomethingUseful]]

Important: If the .Net method being invoked returns a boolean value, then the block will only be invoked if the .Net method returns true. But if the .Net method has a return type of void, or has a return type other than Boolean, then the block will always be invoked.

We are to happy to announce SciSmalltalk v0.12

SciSmalltalk is a new Smalltalk project, similar to existing scientific libraries like NumPy, SciPy for Python or SciRuby for Ruby.

SciSmalltalk already provides the following basic functionalities:

• complex and quaternions extensions,
• random number generators,
• fuzzy algorithms,
• LAPACK linear algebra package,
• Didier Besset's numerical methods,
• Ordinary Differential Equation (ODE) Solver).

Everything is available herehere>https://ci.inria.fr/pharo-contribution/job/SciSmalltalk/*

This version should work on Pharo 2.0/3.0/4.0 and also Squeak 4.5 (to be confirmed).

We are a small community, we are looking for more volunteers to contribute code and documentation. Please join us at : https://groups.google.com/forum/#!forum/scismalltalk

Essence# was released to the public almost 2 months ago. Since that time, the following features and capabilities have been added: Exceptions, Collections, Traits, Announcements and .Net Events, passing blocks as parameters to .Net methods where the corresponding parameter is a .Net delegate, and defining Essence# classes that represent .Net generic type definitions.

And now the ‘Acts’ release of Essence# introduces support for Threads, (asynchronous) Tasks, Semaphores, Monitors and Mutexes, the ability to call .Net methods that use “out” or “ref” parameters, the ability to convert Essence# arrays into .Net arrays (with any .Net type as the element type,) the ability to create such arrays, and the ability to construct closed generic types from open generic type definitions, and create instances of those types. And it fixes various bugs.

The Acts release can be downloaded from the Essence# site on CodePlex (which gets you the installer.) Alternatively, the code for the run time system (written in C#) can be obtained from theEssence# CodePlex site using Git, and the code for the Essence# Standard Library can be obtained from GitHub. And the example scripts can also be downloaded from the Scripts repository on GitHub.

The Essence# Development Plan

Before getting into the details of the new features and capabilities introduced in this release, I should explain the overall development plan:

The highest priority goes to making the compiler and the run time system work correctly. The next priority is adding whatever features to the compiler and/or the run-time system may be required to a) have a fully-functional programming language that conforms to the ANSI Smalltalk standard to the extent that that’s possible on .Net, and b) to enable the maximal degree of interoperability with .Net that is possible without compromising support for the language’s conformance to the ANSI Smalltalk standard. Next to lowest priority is adding whatever classes or methods to the Essence# Standard Library may be required in order to conform to the ANSI Smalltalk standard. And everything and anything else has the lowest priority.

Essence# will stay in alpha until both the language and the standard class library provide full ANSI Smalltalk compatibility, to the extent that that’s possible on .Net.  It will remain in beta until Essence# code a) can be compiled to .DLLs and .EXEs, and b) can be debugged using the Visual Studio debugger. The second requirement depends on the first–debugging with Visual Studio is simply not possible using the type of  (CLR) methods that the Essence# compiler currently generates (which .Net calls “dynamic methods.”)

Typically, when support for new feature domains is added to Essence# (e.g, exceptions, collections, events, threads, files/streams, etc.,) the first step will be releasing Essence# classes that simply wrap the native .Net classes for that feature domain. In some cases, nothing more will be needed. But in most cases, in order to provide ANSI Smalltalk conformance,  it will be necessary (in later releases) to add more classes and methods to the Essence# Standard Library that provide an ANSI Smalltalk facade over the native .Net classes.

Completing the task of adding Essence# classes that wrap (directly represent) the native .Net classes that are needed to complete the planned feature set of the Esssence# Standard Library has priority over implementing Essence# classes that adapt those classes so that they provide an API that conforms to the ANSI Smalltalk standard. That’s why this release does only the former, and not the latter (with some minor exceptions.) It’s also why the same will be true for the next major feature domain: Streams and files.

Using the Essence# Concurrency Classes

This release implements Essence# classes that represent (“wrap”) many of the core .Net classes for multitasking and concurrency that are defined in the .Net System.Threading namespace, such as Thread, Monitor, WaitHandle, EventWaitHandle, SemaphoreSlim, Mutex, SpinLock, SpinWait, ReaderWriterLockSlim and ThreadPool.  It also implements Essence# classes that represent (“wrap”) many of the classes defined in the .Net System.Threading.Tasks namespace, such as Task, TaskScheduler and Parallel.

The new classes reside in the Essence# Standard Library in the namespaces CLR.System.Threading and CLR.System.Threading.Tasks. In a few cases, the Essence# class name is not the same as the .Net class name. Examples: CLR.System.Threading.Semaphore -> System.Threading.SemaphoreSlim, CLR.System.Threading.ReaderWriterLock -> System.Threading.ReaderWriterLockSlim.

Note that these new classes are not defined–and therefore not visible–in the default system namespace (“Smalltalk.”)

Also note that, in some cases, the new classes represent (“wrap”) .Net generic type definitions (“open generic types,”) which means one cannot create instances of such types. To create instances, it is first necessary to construct a “closed generic type” by supplying a generic type argument that corresponds to each of the generic type parameters of the generic type definition. This version of the Essence# Standard Library also includes Essence# classes that do just that for the .Net classes Task`1 (“Task<>” using C# syntax), TaskCompletionSource`1 (“TaskCompletionSource<>” using C# syntax) and ThreadLocal`1 (“ThreadLocal<>” using C# syntax.) Those classes wrap generic types that are constructed by supplying System.Object as the generic type argument to the base generic type definition. They reside in the namespace Smalltalk.Multitasking, and are named Smalltalk.Multitasking.Task (which represents the .Net type Task<System.Object>), Smalltalk.Multitasking.TaskCompletionSource (which represents the .Net type TaskCompletionSource<System.Object>) and Smalltalk.Multitasking.ThreadLocal (which represents the .Net type ThreadLocal<System.Object>).

You should also know that an Essence# class that represents any closed generic type inherits from the Essence# class that represents the corresponding open generic type definition. So the class Smalltalk.Set–which represents the .Net type System.Collections.Generic.HashSet<Object>)–inherits from the Essence# class that represents the .Net type System.Collections.Generic.HashSet<>, and Smalltalk.Multitasking.Task inherits from the Essence# class that represents the .Net type System.Threading.Tasks.Task<> (using C# syntax for the type names.)

If you browse the Essence# code that implements the new classes, what you won’t see is an Essence# method that corresponds to every method and property of the corresponding .Net type. They are there nonetheless, and you can call them in spite of the fact that you don’t see the method definitions in the Essence# code. And that’s true of any and all Essence# classes that represent (“wrap”) a .Net type. If the .Net type represented by an Essence# class has a property or method named “Start,” you can invoke the method or get the value of the property by sending the message #start (or #Start, if you prefer) to an instance of the .Net type, even though there is no such method defined in the Essence# code.

Generally, a method will only be defined in Essence# code when the corresponding .Net method requires 2 or more parameters, or when the type has constructors that require any arguments. Normally, methods in Essence# code only need to be explicitly defined to access a .Net property, or to invoke a .Net method with less than 2 parameters, when it is desired to use a different name for the Essence# message than the one defined by .Net (perhaps because the message selector traditionally used in Smalltalk for the operation with the same semantics is different.)

However, if the class is a native Essence# class which does not “wrap” a .Net type, then almost all methods not inlined by the compiler (or not added dynamically by sending a message such as #addMethod: to the class) must be explicitly defined, with a very small number of exceptions (currently, those would be #doesNotUnderstand:, #ensure:, #ifCurtailed: and #on:do:). The compiler inlines many of the same messages as would be the case in other Smalltalk implementations.

You can print out a list of all the methods defined by an Essence# class (including those that come from traits, or are inherited from its superclasses) by using the ES command line program to run code on the command line (e.g, using the Windows CommandPrompt) such as the following, which will print out the names of all the methods of class Array:

Array allSelectorsDo: [:selector | System.Console writeLine: selector]

Example Of Thread Usage

The methods #newProcess, #newProcessAt:, #fork and #forkAt: have been added to class Block as an initial stab at giving blocks standard behavior with respect to threads (“processes.”) Here’s an example of using blocks to start threads, and of using CLR.System.Threading.Semaphore to schedule threads:

| semaphore|
	
semaphore := CLR.System.Threading.Semaphore new.

[semaphore wait. 
System.Console writeLine: 'Thread one reporting'] fork.

[System.Console writeLine: 'Thread two reporting'. 
semaphore signal] fork.

The #fork message creates a Thread from the block that is its receiver, and starts it running. The first thread immediately begins waiting on the semaphore.  The second thread writes out a message to the console, and then signals the semaphore, which causes the first thread to stop waiting on the semaphore and write out its own message to the console.

And that’s it for now. I’ll publish more posts over the next week that describe and explain the other new features and capabilities, such as calling .Net methods that require “out” or “ref” parameters.

Smalltalk position in Tours France with a contract company, Neo-Soft.

For this Smalltalk position they look for someone on Unix to make changes in Smalltalk and Java. In addition you need to understand COBOL and MVS.

More information in French here.

• Atlanta, GA – Smalltalk Developer through Evolutyz
  • Required Skills:
    • 5+ years of Smalltalk Development experience
    • IBM Visual Age version 5.0+
    • Version Control using VisualAge – ENVY
    • SQL Server 2008
    • SDLC LifeCycle
    • Familiar with consuming Webservices from Smalltalk
  • Additional listings: VDart, VDart

• Fremont, CA – Software Engineer 1 at Lam Research
  • Required Skills:
    • MS/BS in EE/CS or related fields
    • Working knowledge of object-oriented design methods and languages
    • Working knowledge of multi-threaded software
    • Basic knowledge of real-time operating system, hardware and software interface, real-time control, motion control
    • Basic knowledge of at least 1 communication protocol
  • Wanted Skills:
    • Smalltalk
    • Working knowledge of Visual Studio
    • Working knowledge of relational database (SQL server preferred)

• Fremont, CA – Software Engineer 2 at Lam Research
  • Required Skills:
    • Must be proficient in C, C++, and Java
    • Must have used any of the following tools in academic projects tools: ClearQuest, ClearCase, SVN, CVS, GIT, Eclipse
    • Unix
    • Must be familiar with Multi Threading, Inter Process Communications, Memory Management
    • Code analysis using profilers and debuggers etc
  • Wanted Skills:
    • QNX or VxWorks
    • ControlWorks and/or Smalltalk

This blog’s RSS Feed

Dear all,

we are to happy to announce SciSmalltalk v0.12

SciSmalltalk is a new Smalltalk project, similar to existing
scientific libraries like NumPy, SciPy for Python or SciRuby for Ruby.
SciSmalltalk already provide the following basic functionalities:

- complex and quaternions extensions,
- random number generators,
- fuzzy algorithms,
- LAPACK linear algebra package,
- Didier Besset's numerical methods,
- Ordinary Differential Equation (ODE) Solver).

Everything is available here: https://github.com/SergeStinckwich/SciSmalltalk
All the code is available under the MIT licence.

We have more than 424 green unit tests and we run a CI job here:
https://ci.inria.fr/pharo-contribution/job/SciSmalltalk/

This version should work on Pharo 2.0/3.0/4.0 and also Squeak 4.5 (to
be confirmed).

We are a small community, we are looking for more volunteers to
contribute code and documentation. Please join us at :
https://groups.google.com/forum/#!forum/scismalltalk

Regards,

Another great list of changes and improvements in Pharo.

40104
13605 Slider can use setValueSelector instead of accessor everywhere
https://pharo.fogbugz.com/f/cases/13605

13603 remove extensions classOrMetaClass and messageName form Context
https://pharo.fogbugz.com/f/cases/13603

40103
13598 MorphicModel ivar open: not used
https://pharo.fogbugz.com/f/cases/13598

13602 SmalltalkImage >> #openLog dependent on Tools
https://pharo.fogbugz.com/f/cases/13602

13601 Add in group DNU
https://pharo.fogbugz.com/f/cases/13601

13600 DiffereratorSettings –> move to TextDiffBuilder
https://pharo.fogbugz.com/f/cases/13600

40102
13594 Reduce references to CodeHolder
https://pharo.fogbugz.com/f/cases/13594

13597 Implement #readsSlot and #writesSlot on CompiledMethod (and tests)
https://pharo.fogbugz.com/f/cases/13597

13595 PluggableSystemWindow is dead code
https://pharo.fogbugz.com/f/cases/13595

13596 remove package TT.cs
https://pharo.fogbugz.com/f/cases/13596

40101
13592 Small RB Tests cleanup
https://pharo.fogbugz.com/f/cases/13592

13589 deprecated TimeStamp
https://pharo.fogbugz.com/f/cases/13589

13590 TimeStamp has still instances
https://pharo.fogbugz.com/f/cases/13590

13591 unload tests Metacello-TestsTutorial
https://pharo.fogbugz.com/f/cases/13591

40099
13576 Small code critique cleanup Graphics-Primitives
https://pharo.fogbugz.com/f/cases/13576

13587 add tests to make sure globals and class vars use the right bindings
https://pharo.fogbugz.com/f/cases/13587

13580 move UnixEnvironment and Win32Environment to NativeBoost
https://pharo.fogbugz.com/f/cases/13580

40098

13574 ModelOrNil has only one sender so we should rewrite it and remove it.
https://pharo.fogbugz.com/f/cases/13574

13578 safer RPackageOrganizer>>systemMethodRemovedActionFrom:
https://pharo.fogbugz.com/f/cases/13578

13585 use term Class Variable, not Shared Variablem in ClassModification
https://pharo.fogbugz.com/f/cases/13585

40097
13584 Forward code generation for Globals and Class Vars to meta object
https://pharo.fogbugz.com/f/cases/13584

13586 Class Variables should be ClassVariables, not Globals
https://pharo.fogbugz.com/f/cases/13586

40096
13581 move ThreadSafeTranscriptPluggableTextMorph to own package named Tool-Transcript
https://pharo.fogbugz.com/f/cases/13581

13583 #senders and #implementors on Symbol
https://pharo.fogbugz.com/f/cases/13583

13579 MCPatchOperation >> #patchWrapper should be moved to package Polymorph-Tools-Diff
https://pharo.fogbugz.com/f/cases/13579

13582 Deprecated #classSymbol
https://pharo.fogbugz.com/f/cases/13582

40095
13552 First Class Variables: improve reflective API, ClassBuilder use objects, not string for Globals
https://pharo.fogbugz.com/f/cases/13552

40094
13275 RBSmalllintChecker checks classes not defined in environment
https://pharo.fogbugz.com/f/cases/13275

13577 UIManager should not use WorldState for defer:
https://pharo.fogbugz.com/f/cases/13577

13575 TreeModel in checklist mode gives unchecked items hardcoded color
https://pharo.fogbugz.com/f/cases/13575

13571 Something is completely broken regarding Slice submission
https://pharo.fogbugz.com/f/cases/13571

40093
13558 PluggableTextFieldMorph should be packaged in PluggableTextMorph
https://pharo.fogbugz.com/f/cases/13558

12879 Rename and Recategorize RPackage>>#correspondingMcPackage
https://pharo.fogbugz.com/f/cases/12879

13572 little clean of SimpleSwitchMorph and comment
https://pharo.fogbugz.com/f/cases/13572

40092
13515 GrafPort and EllipseMidpointTracer should not be in Morphic package
https://pharo.fogbugz.com/f/cases/13515

13563 Fix sender of deprecated RPackageOrganizer>>#renamePackage:in: method
https://pharo.fogbugz.com/f/cases/13563

40091
6765 Refactoring Extract into Temporary should modify all duplicates
https://pharo.fogbugz.com/f/cases/6765

13565 extensions of Polymorph on Polymorph class should be folded in these classes
https://pharo.fogbugz.com/f/cases/13565

5618 Refactoring: Cannot permutate arguments
https://pharo.fogbugz.com/f/cases/5618

13540 Debugger: method refactoring option
https://pharo.fogbugz.com/f/cases/13540

40090
13569 Small Code critique cleanup of MonticelloGUI
https://pharo.fogbugz.com/f/cases/13569

13567 Small code critique clean Polymorph
https://pharo.fogbugz.com/f/cases/13567

12205 Cleanup gofer>>#directory:
https://pharo.fogbugz.com/f/cases/12205

13125 The Find&Replace dialog does not honor the Appearance font size setting
https://pharo.fogbugz.com/f/cases/13125

40089
11287 Form class>>fromUserWithExtent: freezes because Rectangle class>>originFromUser:grid: is broken.
https://pharo.fogbugz.com/f/cases/11287

13550 Should remove the 30 inbox from pharo 40alpha
https://pharo.fogbugz.com/f/cases/13550

40088
13564 Fix all users of TimeStamp: remove Tests, change two remaining clients
https://pharo.fogbugz.com/f/cases/13564

13562 remove UUIDGeneration seed generation from sound input
https://pharo.fogbugz.com/f/cases/13562

13561 remove some unload class methods
https://pharo.fogbugz.com/f/cases/13561

40087
13560 remove DSA seed generation from sound input
https://pharo.fogbugz.com/f/cases/13560

13555 IconicListItem should be packaged in Widgets-Basic
https://pharo.fogbugz.com/f/cases/13555

13556 ImagePreviewMorph could be packaged close to AlphaImageMorph
https://pharo.fogbugz.com/f/cases/13556

13559 ControlButtonMorph and PluggableButtonMorph could be moved to Widgets-Base
https://pharo.fogbugz.com/f/cases/13559

13557 Github zip download does not check for the existence of file with the same name
https://pharo.fogbugz.com/f/cases/13557

40086
13551 Not all SmartSugs works in Debugger
https://pharo.fogbugz.com/f/cases/13551

40085
12790 AthensSurfaceExamples class side examples do not work due to subclassResponsibility
https://pharo.fogbugz.com/f/cases/12790

13538 RowScrollerMorph us unused and undocumented
https://pharo.fogbugz.com/f/cases/13538

So Wired thinks Apple’s Playgrounds development paradigm is revolutionary?

Not so much: Smalltalk programmers have been coding with analogous capabilities since before Steve Jobs ever saw his now famous demo at Xerox PARC.

The Smalltalk development environment now has close to 40 years of maturity and experience behind it. And its cool features from 1979 still haven’t all been added to the IDEs of other languages, to say nothing of the ones added since then.

Ref: http://www.wired.com/2014/07/apple-swift/

Today is my last day at RMoD.

The last two years have been an incredibly rich experience, and I’m profoundly sad to leave my colleagues. I have in the past two years met and worked with a lot of very smart people and many of them became very close friends. I’m still saying goodbye to people, so I’ll make this post short. :)

The first thing that comes to my mind when I think about the last two years is that I’m very proud of having been part of RMoD. It hasn’t always been easy, but it has been all in all a very joyful experience.

I will of course stay around, and come back to visit the team around February next year.

In two weeks I’ll be packing my stuff to go to Stockholm, where I will be working in another development team. It’s a totally new adventure that will begin, so stay tuned!

Comments

Static typing inhibits interoperability. It does so between class libraries and their clients, and also between programming languages.

The reason is simply because static typing violates encapsulation in general, and improperly propagates constraints that aren’t justifiable as architectural, design or implementation requirements in particular. It does so either by binding too early, or by binding (requiring) more than it should.

The reason that static typing violates encapsulation is because it fails to permit the object itself from being the sole arbiter of its own behavior, and the sole arbiter of the semantics of any operations that may be applied to it. It does that by forcing the programmer to break the veil of encapsulation of the object by directly referencing its class or type as the static type constraint of variables that will be permitted to contain objects of that type, instead of respecting the privacy of that information, which should remain hidden behind the wall of encapsulation that objects are supposed to provide. And then that information is used by the compiler to force the behavior of objects based on the static type constraint of the variables that reference them, as well as the semantics of the operations applied to them, thus violating encapsulation even more profoundly.

As usually implemented by widely-used programming languages, and therefore as typically used by program developers, static typing confuses the distinction between a class and the type that the class implements. And even in an ideal implementation in some language that almost no one will ever actually use in anger, it violates encapsulation by confusing the variables or parameters that reference a value with the class of the referenced value, the type of the referenced value, or (usually) both.

A class is not a type. It’s an implementation of a type.  Therefore, any system built on that false assumption is intrinsically broken at a very deep level. If you write code based on the idea that classes are types, you need to transform your thinking.

And a variable is not the value it references. Therefore, any system built on that false assumption is intrinsically broken at a very deep level.  The semantics of a variable is the architectural role(s) it plays in the algorithm that uses it. It is not the class of the value of the variable that the variable may be referencing at any particular time, nor the type that that class may be implementing at that particular time (the type that a class implements is not necessarily a static property of the class.)

As a concrete example, consider the usage of an array object in a statically-typed language which must hold objects of different types (or different classes, it makes no difference in this case,) and therefore must use Object as the static type constraint for the array’s element type (assuming there is no less-general common superclass.) Putting elements into such an array is easy, and raises no issues.  However, although it is equally easy to fetch elements from such an array, using the retrieved values for other than the most trivial purposes typically requires the programmer to over-constrain the retrieved value: The programmer is forced to constrain such values to being instances of some predefined type (which often also means constraining them to be instances of some predefined class,) before such values can be used in application-specific or domain-specific ways. The programmer must impose such constraints by casting the value to a specific type or class–which will fail if the programmer misjudges the type of the object, even though there would have been no failure had the programmer been allowed to use the value in the operations that were needed without having to cast the value to some specific type (because those operations would be valid for all the elements of the array, regardless of their type or class.)

Typically, one only needs to send one or two messages to values retrieved from a variable or from a collection. One usually does not need to send every message (or apply every operation) defined by a particular type or class. Therefore, requiring that a value must be an instance of a particular type or class is almost always requiring more than is necessary–and usually, far more. Imposing such unnecessary constraints inhibits interoperability because it reduces the generality of the code, reduces the generality of the entities the code defines, and reduces the generality of the the entities that the code can make use of.

And the violation of encapsulation bubbles up to higher-level entities: Classes, modules, packages, assemblies, class libraries and entire frameworks–which is how it inhibits interoperability, not only between class libraries or application frameworks and their clients, but even between different programming languages.

Static typing dramatically increases the coupling between components, because it not only exposes the specific entities that define and/or implement all the behavior of a value, it also requires that clients use precisely and only those specific defining or implementing entities, and typically prohibits the use of functionally/semantically equivalent alternatives that would have worked as desired. This is true even when interfaces are pervasively used as static type constraints (which is rarely the case in practice, and so should in all fairness be dismissed as a moot point,) and because clients must in any case use only the specific interfaces used and/or defined by the component providing the service they’d like to use.

Pervasively using interfaces as static type constraints, although it definitely helps, nevertheless remains a problem a) because interfaces typically require behavior that just is not needed every time one of their instances is used (which is almost always the case,) b) because interfaces defined by third parties–and the classes and methods that use them–generally cannot be changed in any way by their clients, and c) because it is possible (and even likely) that the various providers of “reusable” (ahem) components will separately define what are conceptually “the same” interfaces for the same purposes, which nevertheless won’t be type-compatible even if they have exactly the same names and require precisely all the same operations (messages, operators, etc.)

Why? Because “reusable” components from independent sources that use what are conceptually “the same” interfaces nevertheless cannot easily interoperate with each other, since two (or more!) interfaces that aren’t defined in the same namespace will be classified by the static type system as different, incompatible types, no matter how identical they are otherwise. That means that, for example, the function provided by class library A from source Alpha that transforms a video stream by applying a user-supplied function to the color of each pixel cannot be used with the function that performs the desired color transformation provided by class library B from source Beta, because the two class libraries each use their own “Color” interface, which is not type compatible in spite of having the exact same name and defining the exact same set of required operations with the exact same semantics.

And that’s a short–and incomplete–example of why and how static typing substantially reduces a programmer’s degree of freedom in combining and reusing code components from different, independent sources, relative to what it could be if programming languages used the open-world assumption instead of the closed-world assumption regarding which operations are valid. Operations should be assumed valid until that assumption is proven false, for reasons that are analogous to those that justify the assumption that a person accused of a crime is innocent until proven guilty, or those that motivate the assumption that the null hypothesis is true until proven false by actual experimental observation.

Most of human progress over the past few centuries is directly attributable to discarding the prior obsession with being able to present absolute proofs, and replacing that paradigm with what we now know and love as the scientific method, which is based on falsifiability instead of being based on provability. Our modern technology only exists because we gave up the idea that our models of the world must be provably correct, and instead started using the paradigm of falsifiability, as embodied by the scientific method.

The programming world is in severe need of a Copernican Revolution so that we can discard the ever-more complicated epicycles and contortions that the static typists go through to try to match the generality, reusability and productivity of dynamic programming languages.

Note: You can vote on this essay on Reddit

Hola a todos, hace mucho que no escribo algo para el blog. Durante el último tiempo tuve que dedicarme a cerrar ciertos pendientes que tenia en otros proyectos, disminuyendo el tiempo que le pude dedicar a la robótica.

Durante los próximos meses comenzaremos a trabajar en SLAM (Simultaneous Localization And Mapping), que describe la capacidad de un dispositivo móvil de reconocer su entorno, crear un mapa, ubicarse a si mismo y poder navegar utilizando dicho mapa.

Recientemente me postulé para una beca doctoral y en algún punto de los próximos meses me enteraré si califique para la misma. El proyecto de tesis que presenté es sobre el uso de sensores infrarrojas de profundidad en SLAM .

Ejemplo de Mapa

Para esto planeamos utilizar un Kinect de microsoft, y honestamente creemos que podemos ahorrarnos muchos problemas inherentes al campo de aplicación gracias a la información provista por este sensor.

Lograr que un robot pueda ver y comprender el mundo como para ubicarse es sumamente difícil, y será un largo camino antes de que podamos tener algo funcional pero voy a tratar de mantenerlos al tanto a medida que existan avances al respecto.

- Modularisation is under way

• - Tools 
• - Morphic
• - Polymorph 

package structure is slowly getting cleaner

- Infrastructure

• - Android (Missing management events and graphics)
• - Raspberry (FFI works, vm works, OS process)

- Spur
should be finished this week

• - found a bug in Spur related to weak structure (already fixed by Eliot)
• - release each image we produce to Spur format
• - nativeBoost is not working
• - large integer plugin is not working

- Host window integration

• - OSWindow common interface
• - Multiple back-ends (VM, SDL2, plugin)
• - Ready to be integrated.
• - Need some class comments!

- New bytecode set

• - integrated this morning
• - needs a new vm for the bytecodeset

- Spur 64 bits

• - starting to work on it in September

- Removing old compiler

• - reloadable
• - needed for VM
• - Spur

- System Localization

• - usman should open a bug issue

- Leading Char Removal

• - probably we will not do it.

- Guille Core

• - bootstrap
• - next friday…
• - Unloading Reloading tools 
• - JB will help

- Athens

• - roadmap
• - missing txText

- TxText

• - Widget is there and working
• - Morph is working
• - Spec integration
• - Not all tool use Spec
• - Clean version
• - Igor MUST release a version and not try to make the complete system working with it.

- Remove the old browser

• - kill the filePackage browser
• - We should get Nautilus or OndoBrowser browsing Ring

- Spec

• - Should do a pass
• - Check the design (in particular link between adapter and morph)
• - Examples-driven are needed

- GitSupport

• - filetree integration is working but not good enough
• - small progress.
• - Martin should check with Max the status of libgit2
• - Need to build on top of that.

- Morph and theme

• - we will see if we have the time
• - brainstorming on a solution

- Make sure that we do not overuse Ring

- Font with FreeType

- Glamour

• - esteban roadmap
• - first bootstrap
• - second only a stripped down version
• - development outside the image

- Ombu/Epicea

• - call for more users

- ZnUrl should be used in place of URI URL

- Keychain Removal

- Morph class side announcer

• - we should look at the announcer plague

- Intersect:

• - should be finished

- Image-level resources

• - brainstorming prototyping

- Opal

• there is progress!
• - slots <-> OPAL 
• - subclassing and adding instance compiled 
• - specific slots are on the way

- ClassBuilder

• - should be revisited.

I’ve committed my integration of ROE with NBSQLite3 to SmalltalkHub.

Tested on Pharo 3 on OSX Mountain Lion and Linux Mint 17 based on Ubuntu 14.04. All 23 tests of RATestSQLiteSemantics pass.

The Pharo consortium issued its first annual meeting report 2014-06-report. The report is public and contains all the information exchanged during the meeting. Figures are interesting to look at .

Kilon announced Ephetos: a bridge to Blender. Here is its announce.

Its far from production ready but I am too excited to keep to myself. I present to you Ephestos.