Intro to Microsoft COM for Smalltalkers

Just made this image, I thought it would be fun to share :3 (Yes there are a
few memory leaks there due to no SysFreeString to match SysAllocString, but
regardless...

http://i.imgur.com/Fz36SHU.png

COM to Microsoft Windows seems to be like Smalltalk to Smalltalk Runtime,
with Object Browser being the Windows Registry.



--
View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

To be fair, C++CLI is quite a pleasure to code, it's a very refreshing
technology that sits nicely on the barrier of runtime and compiletime,
similar to Objective C; eg still has access to unmanaged resources, while
still having managed resources in contrast to Java/C# which kinda go one
step towards runtime, and ISO C++ which tries to stay within compile time.

Windows Programming isn't quite that bad now with C++CLI, my image is
contrived to demonstrate one of my first successful attempts at getting COM
to actually do something other than give me compilation errors.



--
View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917767.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Well that is not fair because C++ CLI is basically C++ .NET which is another language altogether baring some resemblance to C++.

And you dont need C++ CLI to sit on barrier of runtime and compile , C++ can do this just fine.

I found this recently trying to experiment at whether its possible to do live coding with C++. I found it after following tutorials that is very possible doing that isfyou put only a super minimal code loop in the executable that loads DLLs and divert all other code to DLLs. This gives you ability to have instant compilation and change code while it is executed. For live data you can put all data to a place in memory and then pass the memory as pointer to the DLLs. This give you live inspection of data and live change of data. You can even protect yourself from crashes , something that Pharo cannot currently do, by wrapping the loading of the DLLs to an OS exception, the executable will never crash but it will show the crash errors. Of course you can hook the debugger for live debugging etc.

You can find my experiment here
https://github.com/kilon/LiveCPP

and find more info here
https://www.youtube.com/watch?v=WMSBRk5WG58

My complains however is over the design of WIndows APIs for C++ , they are beyond ugly, the naming convention alone has a notoriously bad reputation.

.NET is another thing altogether, its a beauty. Its actually an insult to put C# and Java on the same sentence, many coders think that C# is a rip off of Java but nothing could be further from the truth. The creator of .NET is not Microsoft , Microsoft has no clue what good design is, its a coder they hired that worked previously with Borland and created the gorgeous Delphi. Delphi is the only true pro quality Smalltalk out there, without being a Smalltalk. That may sound as a contradiction and it is. Delphi does not use the Smalltalk language , instead uses Object Pascal but pretty much else is a recipe take from the Smalltalk book, notable the API which Delphi calls VCL and the IDE. The API is of special interest here because it has been the first pro quality api to utilize full OO the proper way , with well designed objects and carefully mapped class inheritance. Java on the other hand like windows C++ APIs is a huge pile of mess. The same coder designed C# and .NET and used all the ideas he used with Delphi , winforms alone is a large rip off of Delphi's GUI api.

But even with this beauty Microsoft could help itself dropping the ball, so what it did was to completely ignore the cross platform ability of .NET , hence why Java kept the lead. The excuse was mainly the Windows Mobile that Microsoft dreamed of competing with iOS and Android but that dream eventually failed with the spectacular commercial failure of Microsoft smartphones. So Microsoft did the expected thing, accepted defeat and bought the company that already ported .NET to iOS and Android and countless other platforms and named it Mono. The company is called Xamarin.

Fortunately Microsoft seems to learn from its past mistakes and has recently redesigned .NET to better support cross platform and even open sourced it.

Personally I love .NET and I would not mind at all coding on C# and ironpython  (.NET variant of python). Mircrosoft definetly has lost interest in C++ anyway , it has seen the rapidly decline of the language of the language and the mass migration to Java. Java may be ugly but it cured of the pain of manual memory management and offered the first pure business orientated API with the best cross platform support. Java also destroyed the myth that a Garbage Collector cannot reach top performance and compete with C++ code. In sort Java is not as popular because of the design of its libraries but is certainly extremely popular for a lot other reasons.

The question is why you even bother with C++ CLI , C++ CLI was created mainly to bridge C++ with C# / .NET languages, is there a reason you prefer it over C# ?

On Sun, Oct 2, 2016 at 2:01 PM CodeDmitry <[hidden email]> wrote:

To be fair, C++CLI is quite a pleasure to code, it's a very refreshing
technology that sits nicely on the barrier of runtime and compiletime,
similar to Objective C; eg still has access to unmanaged resources, while
still having managed resources in contrast to Java/C# which kinda go one
step towards runtime, and ISO C++ which tries to stay within compile time.

Windows Programming isn't quite that bad now with C++CLI, my image is
contrived to demonstrate one of my first successful attempts at getting COM
to actually do something other than give me compilation errors.



--
View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917767.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

2016-10-02 10:57 GMT-03:00 Dimitris Chloupis <[hidden email]>:
> By the way I am all for COM for Pharo, the issue is that 2/3 of our
> community are MacOS and Linux users , I dont even remember the last time we
> had a Windows only topic in the mailing list. Modern languages generally
> avoid using OS specific libraries, the last exceptions be C# and Swift and
> C# definetly looks like it will be fully cross platform soon enough (it
> already is because of Mono).

I wouldn't state such affirmations without a proper surveying.

My latest survey related with RDBMS support [1] showed that the users
of Windows are on par with the users of MacOS.

I am a Windows user, who runs most of the Pharo images inside Linux
VMs not because I don't want to run them in Windows, but because the
current support of Windows is somewhat limited.

Having COM support for Pharo in a Windows environment would be a big
enabler to a lot of current users of Smalltalk that don't use Pharo.

Esteban A. Maringolo

[1] https://medium.com/@emaringolo/pharo-rdbms-support-survey-results-9c8f640878db#.ym049enul

@kilon.alios

[1]
I like C++/CLI more than C# because it is very refreshing to use a
language capable of using managed memory and unmanaged memory.

I am too used to being in languages where garbage collection is
forced on you and everything must be done via new or stack types
such as Java, most scripting languages;
Or using languages where static-types are forced on you and
heavily encouraged over dynamic types.

I feel very "free" when I write C++CLI, as it can do everything
C# can(although many things are admitably harder), but it can also
call C when it feels like it.

[2]
If you want to get more users, I hope you are checking the things
people are saying about Smalltalk.

In my class last week, the general concensus was that
"Smalltalk is dead, why are we studying this useless language".

Personally, I really enjoy the environment, but I feel that the
environment would do better from giving existing users a reason
to tell their friends about Pharo, and to like the language.

There are many things that relate to this

1. Reasons to be excited about Pharo/Smalltalk
    - It is a system where you can modify the system within the system.
    - It has a very simple syntax, which is capable of doing things as
powerful as JavaScript.
    - It is easy to get on Windows(3 minute download self contained)...
    - It has pretty powerful prototyping means, but it's not quite as
powerful as
      it could be. One way to improve this would be to add a morph editor
similar to
      VB6. Morphs are somewhat scary to new users right now, and I feel they
stand a bit
      further than where AWT/Swing is in terms of difficulty getting
started, even
      if it is not necessarily true.

2. Quality of Life
    - Blocks the GUI thread in strange scenarios: It's really aggrevating
when
          it does this; when you type in code, the GUI should not freeze!
    - Make it a bit easier to remove morphs(Pit of least astonishment, shift
alt click
      is not obvious, and morph that consists of many morphs is somewhat
hard to select
      the parent morph, so you have to delete the child morph then shift alt
click the
      same place to select the underlying morph(eg grids).
    - More themes!
    - I know you're going to hate me for this but... It's a bit annoying to
install
      Pharo on 64-bit Linux right now...
    - It is kind-of hard to understand what .image, .changes, and .sources
are and
      the material online isn't very exhaustive on their responsibilities.
To date I
      am not actually sure what purpose .sources serves.
    - It's too easy to put Pharo into inconsistant state where it harasses
you with
      popups. It should be easier to access the "undo whatever I just did
please", whether
      it is editing of code, or running a code, I am not sure how easy this
is but at the
      moment, it's not as up-front as it could be; It's scary when you do
something and
      your environment starts yelling at you. (Maybe we could use some
Toasts instead of
      Popups?).
    - Is there a Pharo alternative to JavaScript timeouts?

That is all I could think of for now, probably not going to help you much
but I wanted
to give my 1/1000 of a cent.



--
View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917788.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Contribution is something I've been thinking about for quite some time
because it's interesting how a lot of software is declared "open" but make
it not obvious what you can do to help, or at least participate, or just
take a glimpse at the code to see if something stands out.

I am a believer that there is a way to structure a project in a way to make
it very easy for people with decent experience in broad programming
paradigms to jump into looking over your code and propose revisions or
question design decisions.

That said, I've also been in groups where people only want to write things
once and forget it exists and can't handle any criticism and consider any
questions asked to them as a waste of time, who will only work on stuff
at last moment and won't let anybody help them.

The factors I've noticed are:

1. Ease of finding the repositories which you want people to contribute to,
and tell them apart from
repositories which you don't want people to contribute to, or are irrelevant
to the project(often a project
is broken down into multiple repositories, and the dependency chain isn't
clear).

2. Dependencies: If you ever took a look at a Minix Kernel, you will notice
a huge chain of headers
including headers including headers, scopes with over 7 variables in them,
and nonflat hierarchies which
look at multiple include directories, many of which are not even part of the
project, eg Minix will look at
the system's include directory to decide things rather than figure it out in
a standalone way. This means
that it is very hard to just take things out of context and understand them
without traversing huge
dependency chains, this really discourages contribution.

3. Strict coding guidelines: i've seen projects that force you to either use
tabs, or only use spaces, or such. These are very harmful to encouraging as
many people to participate as possible; we have tools
to restructure code you are looking at automatically, but these tools are
not very easy to access on
all platforms, and need to be configured to your tastes. These tools improve
productivity immensely but
people need to be told how to use them.

4. Ease of telling "where is the start" "where is the end". Many projects
are simply too hard to tell where the start/where the end is, and where the
plugins are, etc. Making it clear where the VM start point is, and
how the project is structured, how the dependency chain looks like really
helps familiarize yourself faster,
and lets people jump into contributing faster as they don't feel like they
need to learn EVERYTHING
before doing anything.

----

My argument is:
Let S be the set of all people who are aware of Pharo's existence who have
enough
programming experience to be relevant to possibly contributing.

Let C be the set of all the people in S who have an interest in contributing
to Pharo, or are willing to contribute to Pharo if you were to come up to
them and ask them to sit next to you and work on it with you. eg they have
the time/resources but don't feel like they go out of their way to get
started.

Let N be the set of all the people in C who are actually contributing or
will contribute to Pharo at some point.

There exists a way to structure the project under a philosophy which, the
closer you come to it,
the more set N decreases, that is, if the philosophy is executed perfectly,
there are no people who are
capable of contributing something relevant, who have not done so or will
never do so.

I am not quite sure what the exhaustive philosophy is, but I suspect the
factors up front play a part in it.





--
View this message in context: http://forum.world.st/Intro-to-Microsoft-COM-for-Smalltalkers-tp4917738p4917793.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.