UTF-8 for Cuis, Pharo and Squeak

Unicode UTF-8 for Smalltalks 

The aim - Sortable, equivalency-testable Unicode strings for Smalltalks. 

Phase 1,

Sortable, equivalency-testable UTF-8 strings which 

encode ONLY ASCII and ISO 8859-1 ("ISO Latin-1")

Step 1 - Thinking

0) a) ASCII and ISO-8859-1 consist of characters encoded in 1 byte.
    b) UTF-8 can encode all of those characters in 1 byte, but can prefer some of them to be encoded as sequences of multiple bytes.  And can encode additional characters as sequences of multiple bytes.

1) Smalltalk has long had multiple String classes.

2) Any UTF16 Unicode codepoint which has a codepoint of 00nn hex
    is encoded as a UTF-8 codepoint of nn hex.

3) All valid ISO-8859-1 characters have a character code between 20 hex and 7E hex, or between A0 hex and FF hex.
https://en.wikipedia.org/wiki/ISO/IEC_8859-1

4) All valid ASCII characters have a character code between 00 hex and 7E hex.
https://en.wikipedia.org/wiki/ASCII

5) a) All character codes which are defined within ISO-8859-1 and also defined within ASCII.  (i.e. character codes 20 hex to 7E hex) are defined identically in both.

b) All printable ASCII characters are defined identically in both ASCII and ISO-8859-1

6) All character codes defined in ASCII  (00 hex to 7F hex) are defined identically in Unicode UTF-8.

7) All character codes defined in ISO-8859-1 (20 hex - 7E hex ; A0 hex - FF hex ) are defined identically in UTF-8.

8) => some Unicode codepoints map to both ASCII and ISO-8859-1.
         all ASCII maps 1:1 to Unicode UTF-8
         all ISO-8859-1 maps 1:1 to Unicode UTF-8

9) All ByteStrings elements which are either a valid ISO-8859-1 character  or a valid ASCII character are *also* a valid UTF-8 character.

10) ISO-8859-1 characters representing a character with a diacritic, or a two-character ligature, have no ASCII equivalent.  In Unicode UTF-8, those character codes which are representing compound glyphs, are called "compatibility codepoints".

11) The preferred Unicode representation of the characters which have compatibility codepoints is as a  a short set of codepoints representing the characters which are combined together to form the glyph of the convenience codepoint, as a sequence of bytes representing the component characters.

12) Some concrete examples:

A - aka Upper Case A
In ASCII, in ISO 8859-1
ASCII A - 41 hex
ISO-8859-1 A - 41 hex
UTF-8 A - 41 hex

BEL (a bell sound, often invoked by a Ctrl-g keyboard chord)
In ASCII, not in ISO 8859-1
ASCII : BEL  - 07 hex
ISO-8859-1 : 07 hex is not a valid character code
UTF-8 : BEL - 07 hex

£ (GBP currency symbol)
In ISO-8859-1, not in ASCII
ASCII : A3 hex is not a valid ASCII code
UTF-8: £ - A3 hex
ISO-8859-1: £ - A3 hex

Upper Case C cedilla
In ISO-8859-1, not in ASCII, in UTF-8 as a compatibility codepoint *and* a composed set of codepoints
ASCII : C7 hex is not a valid ASCII character code
ISO-8859-1 : Upper Case C cedilla - C7 hex
UTF-8 : Upper Case C cedilla (compatibility codepoint) - C7 hex  
Unicode preferred Upper Case C cedilla  (composed set of codepoints)
   Upper case C 0043 hex (Upper case C)
       followed by
   cedilla 00B8 hex (cedilla)

13) For any valid ASCII string *and* for any valid ISO-8859-1 string, aByteString is completely adequate for editing and display.

14) When sorting any valid ASCII string *or* any valid ISO-8859-1 string, upper and lower case versions of the same character will be treated differently.

15) When sorting any valid ISO-8859-1 string containing letter+diacritic combination glyphs or ligature combination glyphs, the glyphs in combination will treated differently to a "plain" glyph of the character
i.e. "C" and "C cedilla" will be treated very differently.  "ß" and "fs" will be treated very differently.

16) Different nations have different rules about where diacritic-ed characted and ligature pairs should be placed when in alphabetical order.

17) Some nations even have multiple standards - e.g.  surnames beginning either "M superscript-c" or "M superscript-a superscript-c" are treated as beginning equivalently in UK phone directories, but not in other situations.


Some practical upshots
==================

1) Cuis and its ISO-8859-1 encoding is *exactly* the same as UTF-8,  for any single character it considers valid, or any ByteString it has made up of characters it considers valid.

2) Any ByteString is valid UTF-8 in any of Squeak, Pharo, Cuis or any other Smalltalk with a single byte ByteString following ASCII or ISO-8859-1.

3) Any Smalltalk (or derivative language) using ByteString can immediately consider it's ByteString as valid UTF-8, as long as it also considers the ByteSring as valid ASCII and/or ISO-8859-1.

4) All of those can be successfully exported to any system using UTF-8 (e.g. HTML).

5) To successfully *accept* all UTF-8 we much be able to do either:
a) accept UTF-8 strings with composed characters 
b) convert UTF-8 strings with composed characters into UTF-8 strings that use *only* compatibility codepoints.


Having written all this, I have realised a picture is worth a thousand words, and I've now drawn this as a Venn diagram.
This note
It can be found at both:
http://smalltalk.uk.to/unicode-utf8.html

and at my Smalltalk in Small Steps blog at:


I therefore as a first step, propose these classes

a Utf8CompatibilityString class.

   asByteString  - ensure only compatibility codepoints are used.  Ensure it doews not encode characters above 00FF hex.

   asIso8859String - ensures only compatibility codepoints are used, and that the characters are each valid ISO 8859-1

   asAsciiString - ensures only characters 00hex - 7F hex are used.

   asUtf8ComposedIso8859String - ensures all compatibility codepoints are expanded into small OrderedCollections of codepoints

a Utf8ComposedIso8859String class - will provide sortable and comparable UTF8 strings of all ASCII and ISO 8859-1 strings.

Then a Utf8SortableCollection class - a collection of Utf8ComposedIso8859Strings words and phrases.

Custom sortBlocks will define the applicable sort order.  

We can create a Dictionary of named, prefabricated sortBlocks.

This will work for all UTF8 composed strings of ISO-8859-1 and ASCII strings.

If anyone has better names for the classes, please let me know.

If anyone else wants to help 

    - build these, 

    - create SUnit tests for these

    - write documentation for these

Please let me know.  euan mee at a well known email system run by Google.com - gmail

Downloads of Squeak

Downloads of Squeak, by version number, from source.squeak.org

Composing with roles

A role does several things (a bit of hand-waving here):

• It might provide behaviour (methods)
• It might require behaviour (acting sort of like an interface)
• Any conflicts (duplicate methods) must be resolved at compile-time

Understanding of roles and their use in specialisation by composition, can be aided enormously by Sandi Metz's talk, "Nothing is Something" (link).

Why have keyword names for multiparameter message sends?

In Objective C, Swift and Rust, the parameter names in a function call are called keyword names. They trace their roots back to the Smalltalk language, where they are keyword names in message sends.

Classes and objects are often re-used from somewhere else, or form part of very large complex systems. They will often not have active maintenance attention for long periods at a time.

Improving the clarity and legibility of the code is very important in these situations, as code often ends up as the only documentation, especially when developers are under deadline pressure, or simply dislike writing comments.  (q.v. Comments are always wrong (link) 

A descriptive keyword name allows maintainers to quickly see what the purpose of each argument in a function call, and which order they appear in, by simply glancing at the function call itself, rather than having to delve deep into the function code itself. It makes explicit the implied meaning of the parameters.

The latest language to adopt keyword names for parameters in function calls is Rust (link) - described as "a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety."  High uptime systems require greater code quality. Keyword names allow development and maintenance teams much more opportunity to avoid and to catch errors from sending the wrong parameter, or calling parameters out of order.

Keyword names can be wordy or terse, but Smalltalkers prefer wordy and descriptive to terse and meaningless. They can afford to be, because their IDE will do the bulk of such typing for them.

Why learn Smalltalk?

This is the answer I gave over on Stack Overflow, to 

Would you start learning Smalltalk? (link) 

1) Yes! 

It's always good to learn a language. 

If you are going to learn a language, make it a powerful, influential language that can be learnt easily and quickly.

Smalltalk remains a pre-eminent language and environment for learning OO concepts.

It is all objects, all the way down. This makes for a really consistent approach to working.

Integers are instances of Class Integer. Strings are a collection of character objects. Classes are singleton instance objects for the class they define.

Control structures work by sending get messages to instances of Class Boolean.

Even anonymous methods (blocks of code, aka blocks) are objects.

Everything is done by sending a message to an object. The syntax can be fitted on a postcard.

The clarity of the concepts and their implementation in Smalltalk mean that you can develop ways of thought which transfer directly into Java, Ruby and C#. I expect it's true for Python, too.

It's so good for making the concepts clear that a major UK University used Smalltalk to train 5,000 people a year in object-oriented computing.

Squeak 5, has just been released. It has gained major performance increases from its new Cog/Spur VM, which features with progressive garbage-collection.

Pharo 4 has a lovely clean-looking desktop theme. The next version, Pharo 5, will be released soon. It will move to using the Cog/Spur VM, it will have about 5,000 classes in the release, and additional packages of classes are readily available from the net via the Configuration Browser tool.

Squeak 5 is performant even on first-gen Raspberry Pis, and is almost 50% faster on the new $5 Raspberry Pi zero. $99 buys you a Raspberry Pi 2, screen and case - running a mature, fully feature-complete IDE.

Leading edge research is being done on co-ordinated, distributed OO systems in Smalltalk (e.g. Naiad and Spoon).

Some of the world's largest corporate databases are run on Smalltalk - including tracking of 60% of the world's shipping containers, and trading systems in the world's largest bank.

You can use Smalltalk as a sort of super-powered CoffeeScript, writing in Amber Smalltalk and transpiling to JavaScript, running in the browser.

Squeak, Pharo, and Amber are all Free, Open-source, open-licenced languages and environments.

Squeak and Pharo provide write-once, run anywhere facilities for MacOS, Windows and Linux. (Possibly RiscOS, too).

Dolphin Smalltalk is targetted firmly at native Windows look-and-feel, and lets you compile closed .exes of your finished work for distribution to end users. Further development of Dolphin by the vendor has stopped, but it is completely functional, and, like all Smalltalks, designed to be massively extensible. (Did I mention that Pharo now has 5,000 classes, compared to Squeak's 3,000? Pharo is a fork of Squeak 3.9)

**There is a How-to guide for installing and starting Squeak, Amber, Pharo, Cuis and Dolphin at: **http://beginningtosmalltalk.blogspot.co.uk/2015/11/how-to-get-smalltalk-up-and-running.html

The Seaside web framework runs on Squeak and on Pharo. It's a wonderful mature tool, as is the more traditional AidaWeb framework.

VisualAge, VisualWorks and Gemstone all provide enterprise-grade robust systems. Gemstone provides an infinitely scalable object database with transactions and persistence.

Do you already know Smalltalk? (same link) 

2) Yes - I do already use it.

I learnt it via the Open University, and was immediately productive in Ruby (a copy of the Pickaxe book and the library reference by my side). It helped me enormously with Java, and with Xerox Moo-code.

I have just returned to it to write apps to control manage and distribute responsive, massively multi-platform mobile apps.

I expect that soon I'll be re-writing my JavaScript mobile apps using Amber, too.

Squeak 5 and Pharo 4 side-by-side on Raspberry Pi (videos)

The videos are all of a Raspberry Pi Model B - i.e. it is the 1st Generation, single core 700MHz device.

For comparison, The newly launched Pi Zero is a single-core 1GHz device, so is substantially faster.

The Raspberry Pi 2 is a 900MHz quad-core device.

The Orange Pi (a Chinese Pi-alike) has options up to 1.6GHz.

Intel Atom CPUs start from ~$120 - that is for the CPU (or the System on Chip?) alone.

Be warned - the videos have been compressed as much as possible and are downloaded, not streamed.

http://smalltalk.uk.to/SmalltalkOnPi.html

Smalltalk.uk.to is now live

A site to show that SMALLTALK is for the UK TOo!  (As a mnemonic, that's very contrived.  I agree)

Currently, it has a proposed interim logo for Cuis, and a video showing Pharo4 and Squeak 5 running side by side on a Raspberry Model B (the original 700MHz model)

How to debunk Myths

1) Do more than simply explain the facts. 

Fight sticky myths with even stickier facts - this is the golden rule of debunking in Made To Stick (by Chip and Dan Heath).

Make your answers sticky - short, simple and concrete.  Messages that grab attention and stick in the brain.

And here's their mnemonic for stickiness:

SUCCES 

• Simple: If you can't explain it to a 6 year old, you don't understand it as well as you think.
• Unexpected: use any counter-intuitive factoids to take people by surprise.
• Credible: have sound sources you can point to
• Concrete: make the abstract real using clear analogies and metaphors.
• Emotional: we are emotional beings - embrace it even when talking about technology.  Expressing our passion has a power all of it's own. Personal stories communicate things at a more fundamental level than dispassionate abstractions do.
• Stories: Shape the facts into a narrative.  That creates a place for the facts to be stored in your audience's brains.

2) Focus attention on the truths, not the myths

The more often a statement is made, the more familiar it becomes to people, the more likely they are to think that it is true.

(Advertising works this way - once a message gets repeated more than 10-15 times, our critical faculties stop assessing the message before deciding whether to put it into our brain's long-term storage or not.  After enough repetitions, it just gets placed straight into storage).

This can cause a “familiarity backfire effect” - reinforcing the myth in people’s minds.

To avoid the familiarity backfire effect:

1) Put the emphasis on the facts.  Not on the myth.

2) Lead with the facts you wish to communicate, rather than the myth.  

3) Finish with the facts you want to communicate.  The correct facts should always be the first and last things you state.

Avoid putting the myth in the headline - that breaks the first two rules.

4) Show a warning flag before mentioning the myth, so people's mind's are on guard so they’re less likely to be influenced by the myth. It can be as simple as "A common misconception is ..."

5) Explain what trick or fallacy the myth uses to distort the facts.  People then have the opportunity and means to reconcile the facts with the myth. 

Here is a handy framework for identifying fallacies:

Tricks of (il)logic:

• Red Herrings - is it an irrelevant line of argument?
• Misrepresentations - Is the statement made actually true? Is it exaggerating for effect?
• Jumps to conclusions - from here to there in one mighty, illogical bound
• False dichotomoties - they say it's either or.  Maybe it's both and?

Expectations that cannot be met

Cherry Picking of facts

Overstating 

• the authority of sources
• the size of counter-examples

So - always lead with a SUCCES-ful fact.  Repeat the fact at the end, to recap. 

Give a clear warning, before repeating any myth.

Explain the trick behind the myth.

Repeat the SUCCES-ful fact at the end, to recap.

FACT - WARNING - MYTH - FALLACY - FACT  

aka

FWMFF - it's probably a  real word in Welsh :-)  Pronounced Fooomff.  In a lilting accent.

3)  Make your message easy to process. 

• easy to read
• easy to understand 
• short and to the point

Info that is easy to process is more likely to be accepted as true.

For example, simply getting a better colour contrast in a printed font so that is easier to read, increases people’s acceptance of a statement as true

4) Stick to a few key counter-arguments.

3 arguments are more successful than 12.

The more arguments you use, the more you risk re-inforcing the myth.  The refutations are too many to remember, so all that is remembered is the myth.  And we already know that the more often someone is exposed to the myth, the more likely they are to accept it as true. 

5)  Stick to the facts

Don't be dramatic.

Do not make derogatory comments - these will alienate people.

6) Keep the audience as unbiased as possible.

If they are given a choice, people selectively seek out information that bolsters their existing view.  This is Confirmation Bias.

Remove the choice, and present someone with arguments that run against their worldview? People spend significantly more time and thought actively arguing against opposing arguments.  This is Disconfirmation Bias

Together, it means that argument and debate is most often going to bolster pre-existing attitudes.  Raising supporting facts most often results in strengthening people’s pre-existing beliefs in the myths we want to bust.

7) Target the undecideds. 

The stronger the previously-held belief, the more entrenched it becomes in debate.

Keep away from the hot-button topics.

8) Couple any message that threatens a world-view with self-affirmation

People become more balanced in considering pros and cons when you do this.

Self-affirmation is getting people to reflect on their own good feelings about themselves.  (For example, by writing a few sentences about a time when they felt good about themselves because they acted on a value that was important to them. 

This has the strongest effect on people when you are trying to change a worldview which is most central to their own sense of self-worth. 

 9) Frame the debate in a way that threatens the audience's worldview less.

This can be as simple as using a different label for your proposal.

10) Any time you kill a myth, replace it with a new storyline.

This is based on what I expect I'd find in 

The Debunking Handbook

http://www.skepticalscience.com/docs/Debunking_Handbook.pdf

I'm off to read it now.

My vision for the Smalltalks

Here is my vision.

1) Commercial uptake, with an ongoing upwards growth trend
2) Thriving community of developers, with an ongoing upwards trend.
3) A platform with sufficient stability for commercial use, to provide 1)
4) A platform with sufficient stability for adequate documentation, that leads to sufficient levels of interest to provide 1) and 2) 

Here is the vision of the leader of the Pharo project (who is also the head of the European Smalltalk User Group)
the ultimate live environment
a great reflective system
a system well integrated with C
a system well integrated with OSes

a wonderful IDE

In my world view, it is possible for my both visions to be congruent.  It is not a given that they are - unless careful attention is paid to both.

So let's see what's what.  

Say we had:
the ultimate live environment - that <100 people use
a great reflective system - that <100 people use
a system well integrated with C - that <100 people use
a system well integrated with OSes - that <100 people use
a wonderful IDE - that less than 100 people use.

Would that be a fulfillment of anyone's vision?

The number of users (commercial organisations and individual hobby/student/academic developers) matters - because without a sufficiently large group, the velocity towards realisation of a vision does not keep up with events.

Because of the network effect, the two visions need to be complementary to succeed. In a world full of the network effect, two small items are *disproportionately* less useful than a single item twice the size.  And currently developer mindshare for FOSS Smalltalk is split more-or-less in two.   We need to unite as often and as much as possible - at least until our community is large enough to have the luxury of becoming different communities.

In the current dialectic, size of community and commonalities between closely-related communities are irrelevant.

However, at best, Pharo is currently a distro of Smalltalk.

It's a fat distro - a very fat distro, definitely the fattest one I use by more than a factor of 2.  But it's simply the Kubuntu to Cuis's PuppyLinux.
It uses the same syntax as the other Smalltalks.
It uses the same VM as the other Smalltalks.
It uses the same core classes as other Smalltalks.
Many of its additional classes are ports from other Smalltalks.

What's the old saying?  If it looks like a duck, and it quacks like a duck - it's a duck.

The key substantial difference it has over other Smalltalks is the additional Classes.  Currently mainly from PhD theses being added into the class libraries.  Plus an ongoing effort to port initiatives from other Smalltalks into the Pharo Class hierarchy.

Demanding that it be always and only be considered its own unique thing completely separately from other things just splits the community in two.

Most of the wins claimed for Pharo in the first several years of its life were from elsewhere - Squeak and VisualWorks. So many of the successes listed for Pharo have simply been simply ports of pre-existing software, rather than anything new and unique. 

Many of Pharo's substantial and numerous additional classes it has over when it started are either
- minority academic facilities
- insufficiently documented to be used by people other than the package developers
- have a stability half-life of about 18 months.

This last point matters.

For example.  DBXTalk.  Go to Stack Overflow and search for Pharo and SQL.

You get told about DBXTalk and pointed to the package's homepage.  Which until yesterday was a dead link. (I've just fixed it) Until I fixed it, this gives the impression that the package is dead.  And that if you want to do something as basic as link Pharo to MySQL you're going to have to roll-your-own solution.  (Which is not true!).

Even going to the new link is confusing, if you are arrive expecting to to use dbxtalk.  You then get pointed to two different packages, Garage and .. can't remember.  Neither of them have a self-descriptive name.  Self-descriptive names like like DBXTalk are meaningful and are memorable beacause of their  meaningfulness. DBXTalk is fairly obviously a DB Xover for Smalltalk)

If we want Pharo to succeed as a commercial-grade platform,
1) we need to grow the userbase
============================
And by 'userbase' I mean commercially-successful organisations which find Smalltalk compelling enough to use that they keep it in their tools portfolio.

(Please bear in mind that Ericsson created erlang and had a product portfolio which was internally reliant on erlang.  And the were still going to drop erlang from its toolset at one point - because they feared the community was too small for it to survive in the long run.  Just because a product has some powerful advantages does not mean that it is a compelling choice for an organisation in the long run).

Even better, it should be compelling enough to be adopted *into* their tools portfolio.

And if we can't be adopted into existing organisations' toolkits, we need to be capable of generating new commercially-strong organisations that have successfully used Pharo in their toolkit from day 1.  And continued to use Pharo once they have grown larger.

2) we need to grow the developer-base
===================================

The key problems:
==============
Growing the user-base in the absence of a thriving developer base is hard.

Growing the developer-base in the absence of a thriving user-base is hard.

This is a Chicken-and-egg problem.   There's a long  (but lively!) explanation of just how hard it is and why, see http://www.joelonsoftware.com/articles/fog0000000054.html

 - we need to have a breadcrumb trail from
   "don't know about it" to
   "potentially interested in it" to
   "actively interested in it" to
   "able to try it" to
   "finding something compellingly useful about it" to
   "having a sufficiently documented, sufficiently stable, set of facilities that people develop with" to
   "having a sufficiently stable set of facilities that things created using them keep working and working and working"

This is true both for developers, and for commercial users.

The answer "I have done this, and so have 3 dozen other people" is not an indication of success in this matter.

One single university in the UK produced 5,000 people trained to use Smalltalk each and every year, year after year.

Without commercial visibility of Smalltalk's use, they each stopped being able to use Smalltalk within a year.  (Mind you, they found picking up Java and JavaScript and Ruby and OO Python much easier, so they still gained personally, despite being lost to the Samlltalk community/ies.)

We have already lost the battle against Lua. Against Python. Against Ruby.  We were never in the running against JavaScript.
 (although there is a mathematically non-zero chance that Amber might beat out jQuery, Angular etc as the way to approach JavaScript.  In the same way that Scotland has a mathematically non-zero chance of winning the next FIFA World Cup)

In a world of network effects, splitting the community makes us weaker, not stronger.

In a world where Pharo syntax is Smalltalk syntax, in a world where the Pharo VM is the Smalltalk VM, in a world where Pharo's base 500 classes are everyone else's 500 base Smalltalk classes, Pharo is Smalltalk.  And great speakers do get invited to speak about a Smalltalk distro.  (I'm presuming because they are a great speaker, and because they have something interesting to say about Pharo's numerous and large extensions to the core distro.  They are not being invited because they are working in a new language.  And alas, it's certainly not because they are working on something that is growing a userbase and growing a developerbase).

Let's grow our community.  Let's embrace the network effect.  Let's do this as a Smalltalk community - all the various strands and sub-groups - and do this in concert, together.

Java to become legacy-ware?

Someone announced on a mailing list for one of the Smalltalks that:

InfoWorld received an Tuesday (24th November 2015), supposedly from a former high-ranking Java official, which claimed to feature details from inside Oracle.

It said the company was becoming a cloud company, competing with Salesforce, and “Java has no interest to them anymore.” The subject line cited “Java – planned obsolescence.”

Oracle is not interested in empowering its competitors and doesn’t want to share innovation, the email further alleges. The company is slimming down Java EE (Enterprise Edition), but it also doesn’t want anyone else to work on Java or Java EE and is sidelining the JCP (Java Community Process).

“They have a winner-take-all mentality and they are not interested in collaborating,” said the email. “Proprietary product work will be done on WebLogic, and there’ll be a proprietary microservices platform.” WebLogic is the Java application server Oracle acquired when it bought BEA Systems in 2008.

https://dzone.com/articles/even-if-oracle-is-losing-interest-in-java-should-y?edition=115055&utm_source=Spotlight&utm_medium=email&utm_campaign=java%202015-11-24

But, there is still no official indication from Oracle. For instance, no press-releases. 
( https://www.oracle.com/search/press )

=======================================

If Oracle did make this statement, then it's true - this is not a magic bullet to that will suddenly make the Smalltalk community massive.  BUT...

Java got about 40% of its initial momentum from IBM dumping VisualAge Smalltalk and putting all their resources into Java.

Oracle are targetting this move at IBM more than anyone else.

IBM will start to think about how to migrate from Java - as Oracle are telling them they will have to.  (It's OUR bat and its OUR ball, and no-one else can play with it.  Not even the Java Community).  And IBM's coders do not pay for Java, Eclipse users do not pay for Java. I expect the licence-fee income for JREs in the corporate multi-tier app world is small.

Oracle are announcing one of two things.  Either 

1. Java is for sale to device providers - makers of phones or of devices for the impending Internet of Things
   
   (Google would be an obvious buyer for Java, given how fundamental Java is to Android.  And the Internet of Things is precisely what Java was originally designed for. )
   
   or
    
2. no-one making an internet of things offering should consider Java.

Google would be an obvious buyer for Java, given how fundamental Java is to Android.  And the Internet of Things is precisely what Java was originally designed for. 

Yes, things live on and on in a kind of zombie state.  So yes, things live on as long as their ecosystem does.  And they gently wither as their ecosystem withers, and it's a long slow drawn out spiral.  Which is why we still have Cobol.

People and organisations tend to move from one technology to another in an incremental fashion.  Swapping a little bit here, and a little bit there.

The new target platforms are ones which
1) look like they have longevity, and
2) have a migration pathway that provides incremental steps.

Offering a compelling  advantage is good - but only if the steps 1) and 2) are catered to.

Smalltalk still has a loyal following in the large-scale corporate software market. The world's largest bank started work on new trading systems in Smalltalk earlier this month.

IBM VisualAge Smalltalk is still robust, commercially available software, (albeit now sold by Instantiations rather than IBM).  CinCom VisualWorks and Gemstone/S also continue to represent Smalltalk out to the big world of corporate development.

So that's a start.

Say only 5% of the Java world moves away from Java each year, as a result of this announcement.

We *should* wish to take advantage of this announcement.

After all, think about the difference that having even 0.01% of the world's Java coders moving to Smalltalk would make.    How could we help that happen?

Think what it would be like to have thought-leaders like Kent Beck and Ward Cunningham back in the Smalltalk fold.  How could we help that happen?

Think what it would be like to get back all the universities who used to teach OO concepts using Smalltalk, but which moved into teaching them via Java. Currently, we know almost all the universities using Smalltalk as a teaching language by name.  Does anyone know even how many universities teach OO via Java?    What would it be like if 5% of those universities moved to Smalltalk each year.   How could we help that happen?

Next - do we have any big brained thinkers who can see specific ways we can improve interoperation between Java facilities and libraries and the Smalltalks?  For the next 12 months, we should work on Java integration, rather than C/C++ integration.  We should identify the three best things for us to do in this regard,  and make them polished and compelling.    Who is in a position to help that happen?

The final way we can take advantage help the maximum number of people find their way to us is to present a united community front to the outside world.  In the same way I am both a European and a Scot, we need to be Smalltalkers *and* members of our individual Smalltalk-platform communities.

How can we help make that happen?

This is not a silver bullet. It's going to cause a long-term trend in events, not a sudden abrupt change.   But it will have a real, if gradual effect.  (Assuming, of course, that the rumour is well-founded).

Equally, it is not something we should ignore.  It is something we should make use of.  We need to put effort into raising our profile over the next 6 months, ready for the moment that Oracle makes this official.

Timing Issues in Squeak and Pharo and Cuis Smalltalks

I was profiling yesterday, and discovered these issues:

Issue:
=====
Time and DateAndTime both show human-readable time information to
micro-second precision.  Time also holds information to nano-second
precision.

Both objects are only providing information to the nearest millisecond.

The digits beyond milliseconds are always (on my PC) filled in as '902'.

In the nanoseconds instvar of the Time objects, the nanoseconds are
always filled in as '000'.


Root cause:
=========
When Times (and DateAndTimes) are created, they use the
Time>>primUTCMicrosecondsClock method to generate the time

primUTCMicrosecondsClock
"Answer the number of micro-seconds ellapsed since Squeak epoch.
That is since 00:00 on the morning of January 1, 1901 UTC.
At least a 60-bit unsigned integer is used internally which is enough
for dates up to year 38435.
Essential. See Object documentation whatIsAPrimitive. "

<primitive: 240>
self primitiveFailed

Potential for solution:
================
[The following is taken from Stack Overflow,
http://stackoverflow.com/questions/2607263/how-precise-is-the-internal-clock-of-a-modern-pc]
Modern PCs have a hardware  High Precision Event Timer (HPET) which
specifies a clock speed of 10MHz
http://www.intel.com/hardwaredesign/hpetspec_1.pdf
Even newer PC architectures take this and put it on the Northbridge
controller and the HPET can run at 100MHz or even greater. At 10Mhz we
should be able to get a resolution of 100 nano-seconds and at 100MHZ
we should be able to get 10 nano-second resolution.

The following operating systems are known not to be able to use HPET:
Windows XP, Windows Server 2003, and earlier Windows versions, older
Linux versions
The following operating systems are known to be able to use HPET:
Windows Vista, Windows 2008, Windows 7, x86 based versions of Mac OS
X, Linux operating systems using the 2.6 kernel and FreeBSD.

Switch fullscreen mode on and off

Display fullscreen: true

Display fullscreen: false

Ending a statement

I am frequently surprised (and caught out) by failing to end a statement.

Why is this?  I don't forget in other languages.  My very first professional debug turned out to be a failure to set the ending properly in three lines of code - out of a 10,000 SLoC app.

Always remember to finish the sentence with a .

Keyboard shortcut for Spotter in Pharo

Shift+Enter

Enumerating using keysAndValuesDo:

**Part 1 - Displaying to the screen**
The most straight forward way to print to the screen in a GUI-based Smalltalk is to use the message:
`Transcript show: 'some text'`
(The Transcript is a system object that displays into a scrollable window).

To make sure there is a newline before each line of display text, we send the message `cr` to the Transcript

    Transcript cr.
    Transcript show: 'some text'.

A shorthand method, that saves us re-typing `Transcript` over and over, is to send Transcript a series of messages one after another.  This is called a *message cascade*.  Each time we end a message in `;` it means *send to the same receiver as the last message was sent to*.

We can then shorten this again, as Smalltalk pays no attention to newlines in expressions.

The final display message cascade becomes:
`    Transcript cr; show: 'some text'.`

**Part 2: Enumerating aSortedCollection using keysAndValuesDo:**
This keyword message is SequencableCollectionand its method header is:
`keysAndValuesDo: aBlock
"Enumerate the receiver with all the keys (aka indices) and values."`

(It works the same way in Dolphin, and in Squeak and its derivatives, Pharo and Cuis).

The keyword message `keysAndValuesDo:` takes a block argument.  
A block is an anonymous object, with one method.  Its method is defined between a matched pair of square brackets - a `[` ... `]` pair.

In this case, we need a local variable in the block for the key of each element of the collection, and another local variable for the value of each element.

We can call them anything we like, and in this case, it is the order that they appear in that is important.  `keysAndValuesDo:` will put the element's key into the first local variable in the block, and will put the element's value into the second local variable in the block.

Local variables in a block are declared at the start of the block, and each variable name is identified by prefixing it with `:`. The local variable declarations are ended with a `|`.

The block then looks like
`[:local1 :local2 |
 "do something for each element, with the key in local1 and the value in local2"
 ]`

I prefer meaningful local variable names, so I'll use `eachKey` and `eachValue`.

**Part 3: Putting it all together**  
To enumerate through mySortedCollection

    "Declare the mySortedCollection variable"
    |mySortedCollection|
   
    "Initialise the collection"
    mySortedCollection := SortedCollection new.
   
    "add in some data to the collection"
    mySortedCollection add: ('First') ;
                       add: ('Second') ;
                       add: ('Third').
   
    "Enumerate through the collection, displaying to the Transcript window"
    mySortedCollection keysAndValuesDo:
       [:eachKey :eachValue |
        Transcript cr; show: eachKey; show: ' '; show: eachValue
    ] .

Paste the code into a Workspace (known as a Playground in Pharo, from version 4.0 onwards).  Select the text.  Once selected, right-click (on a two or three button mouse) and select "Do it" from the menu. Or use Ctrl-d as a keyboard shortcut.  (The exact chording key may vary on your platform)

**Final notes**
In a SortedCollection or an OrderedCollection, the key is the index.  The value is what is stored at element[index].

In a Dictionary, the key of the element is the key, and the value of the element is the value.

SortedCollections are sorted in order of the element values, according to the definition of the collections *sort block*.  In the absence of a custom sort block, they will be added in ascending order.  `'First'`, `'Second'` and `'Third'` are, coincidentally, in alphabetical order.  It happens to work out nicely in this example.

Beginning to Smalltalk has begun!

I've started a new blog - "Beginning to Smalltalk".

This is where I'll be putting my more polished posts, and I'll hopefully manage to put them in a sensible order.

I'm confident  Beginning to Smalltalk will become a useful step-by-step tutorial guide.

I'll continue to log my notes to myself, and my 'aha' moments, here.