[Pharo-project] Popularity of Smalltalk in Software Industry

Jimmie Houchin jlhouchin at gmail.com
Fri May 6 01:03:41 CEST 2011

On 5/5/2011 4:25 PM, Igor Stasenko wrote:
> On 5 May 2011 21:39, Jimmie Houchin<jlhouchin at gmail.com>  wrote:
>> On 5/5/2011 12:21 PM, Igor Stasenko wrote:
>>> On 5 May 2011 18:57, Jimmie Houchin<jlhouchin at gmail.com>    wrote:
>> [Big Snip]
>>> Well said.
>>> Except that i'm not sharing your view that its hard to interface with
>>> foreign libraries.
>>> Its not hard at all. Of course to connect two different worlds, you
>>> need to have knowledge
>>> in both of them. But this requirement not a bit different when you
>>> take any other pair of languages and try to
>>> connect them.
>> Thanks,
>> I have no knowledge of either the knowledge or the challenges involved in
>> using external libraries in Pharo or Squeak. I have no knowledge of
>> FFI/Alien or using C/C++/C# or compilers.
>> However, this is my experience in Python.
>> Navigate to the directory containing the script makepy.py or if it is a part
>> of your Python's sys.path, execute the script. It generates a Python module
>> which is on
>> It pops up a dialogue which prompts you to select the library you wish to
>> interface.
>> Then to use in a script simply
>> import Dispatch
>> self.mylib = Dispatch("MyLibrary")
>> This will expose all the functionality of the library.
>> All provided by the python win32 extensions. It was very successful for my
>> needs. I do not know what limitations it may or may not have.
>> Very easy for non-expert programmers. I would love this level of ability to
>> interface outside libraries in Squeak. But I have no idea the effort
>> required to automate the generation of a class or classes which interface
>> the external library.
>> In my particular instance this is obviously for a Windows library. I don't
>> know if Python has anything comparable for Linux or OSX.
>> In this particular instance, Python was enabling for me, for which I am
>> grateful. Otherwise I might be stuck writing my app in VisualBasic. But
>> despite my gratefulness, I spend as little time in Python as possible.
>> Despite Python not requiring a compiler, I really hate going to an editor
>> and writing code. Then to an interpreter to run code. Hit my stacktrace. Go
>> back to the editor. Reload the module in the interpreter and run again, and
>> if that doesn't succeed due to the reload not really reloading the new code,
>> open in a new interpreter. Ugh!!!  Where's my Smalltalk. Give my live object
>> system. :)
> Haha.. i have strong suspicion that here you are talking about quite
> specific set of libraries,
> which using OLE/COM interfaces. Indeed, one could implement an
> automatic "import/connect" tool
> for it, because a library itself contain enough information reflecting
> it interface(s).
> You can check Dolphin smalltalk which works only on windows and has
> integrated solution for that for years:
> In same way like you described, you just pick the library, click "ok"
> and its done&  ready for use.
> But that would be too easy if you could do same with any other library
> in your system.
> So, if you feel adventurous, try to check what Python can do with
> libraries like Kernel32.dll
> or User32.dll. I am sure it can do as little as Smalltalk in this
> regard, but you are free to check it yourself :)

As I said, I am totally unaware of the limitations of the system, but 
that it did what I need, and would have liked to do that from 
Pharo/Squeak. I know Dolphin has/had certain capabilities. But I don't 
prefer to use non-open source software if at all possible for 
development. I also am very preferential towards cross-platform 
software. Dolphin fails on all accounts. I would choose my Python/Pharo 
blend over Dolphin any day. I know it introduces some pain, but I am 
willing to accept the pain. I like tools that allow me to use them where 
ever I am and whatever I am doing.

However, that said, when I look at the facilities Python offers for such 
capabilities it on appearances looks quite impressive.


ctypes is a foreign function library for Python. It provides C 
compatible data types, and allows calling functions in DLLs or shared 
libraries. It can be used to wrap these libraries in pure Python. Loading dynamic link libraries

ctypes exports the /cdll/, and on Windows /windll/ and /oledll/ objects, 
for loading dynamic link libraries.

You load libraries by accessing them as attributes of these objects. 
/cdll/ loads libraries which export functions using the standard cdecl 
calling convention, while /windll/ libraries call functions using the 
stdcall calling convention. /oledll/ also uses the stdcall calling 
convention, and assumes the functions return a Windows HRESULT error 
code. The error code is used to automatically raise a WindowsError 
exception when the function call fails.

Here are some examples for Windows. Note that msvcrt is the MS standard 
C library containing most standard C functions, and uses the cdecl 
calling convention:

>>>  from  ctypes  import  *
>>>  print  windll.kernel32  # doctest: +WINDOWS
<WinDLL 'kernel32', handle ... at ...>
>>>  print  cdll.msvcrt  # doctest: +WINDOWS
<CDLL 'msvcrt', handle ... at ...>
>>>  libc  =  cdll.msvcrt  # doctest: +WINDOWS


It has examples for windows and linux.

I didn't read it all as I am unqualified to assess its capabilities or 
limitations, nor do I presently need it as the win32 extensions do 
easily and well what I presently need to do.

Hopefully it can inform us as to what is expected and doable in 
alternative languages which are dynamic like Smalltalk.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110505/3f7cd8f9/attachment.htm>

More information about the Pharo-project mailing list