IronSmalltalk - Smalltalk on top the .Net DLR

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

Dear Todor,

IIRC there had been at least two approaches to this goal already (S# and #Smalltalk, Dave Simmons’ S# being probably the most advanced and most promising one. Does your approach build on top of those experiences or did you start from scratch? How does your approach differ from the former ones?

Cheers

Helge

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Hi Helge,

You are right. There are several implementations on the .Net. This is no more different than the several “native” Smalltalk dialects. They all aim to fulfill certain goal. I started from scratch and I don’t know about the technical approach of the other dialects, but the where IronSmalltalk differs from the other dialects is that the intention is to be first class citizen in the .Net world. It’s not only about running on the .Net and being able to consume .Net libraries and code, but also allow the remaining .Net languages to consume your objects. There is no idea of having a .Net implementation of Smalltalk if you are not going to interact with the rest of the .Net world (both ways).

I believe that the other .Net Smalltalks can easily consume .Net libraries, but I don’t think .Net code can easily consume objects written in Smalltalk. To achieve that you need to leverage the DLR, which to my knowledge none of the other Smalltalks does.

It is under MIT license.

The goal is to be 100% ANSI (ANSI INCITS 319-1998) compliant.

I would like to extend the language with mixins or even dynamic object behavior, where the object can elect what behavior it wants to expose dynamically. In classical Smalltalk, this is achievable with #doesNotUnderstand:, but I think that this can be implemented cleaner and more optimal / optimized. This is not difficult to implement technically, the difficult part is in exposing it cleanly to the developer (the end-user of IronSmalltalk).

Cheers,

Todor

Dear Todor,

IIRC there had been at least two approaches to this goal already (S# and #Smalltalk, Dave Simmons’ S# being probably the most advanced and most promising one. Does your approach build on top of those experiences or did you start from scratch? How does your approach differ from the former ones?

Cheers

Helge

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Dear Todor,

if I remember correctly at least S# had and implemented the same goals though it was in the pre-DLR era. If I furthermore remember correctly S# had been sponsored by Microsoft, so the implementation should be very advanced. It had also mixins. Maybe if you contact David Simmons he’ll share some of his experiences.

Cheers

Helge

P.S. VisualWorks and ObjectStudio come with the DotNet component for using .NET frameworks at the fine grained level. Providing functionality implemented in Smalltalk to .NET applications and vice versa is usually done via web services, Microsoft’s suggested default API for .NET

Hi Helge,

You are right. There are several implementations on the .Net. This is no more different than the several “native” Smalltalk dialects. They all aim to fulfill certain goal. I started from scratch and I don’t know about the technical approach of the other dialects, but the where IronSmalltalk differs from the other dialects is that the intention is to be first class citizen in the .Net world. It’s not only about running on the .Net and being able to consume .Net libraries and code, but also allow the remaining .Net languages to consume your objects. There is no idea of having a .Net implementation of Smalltalk if you are not going to interact with the rest of the .Net world (both ways).

I believe that the other .Net Smalltalks can easily consume .Net libraries, but I don’t think .Net code can easily consume objects written in Smalltalk. To achieve that you need to leverage the DLR, which to my knowledge none of the other Smalltalks does.

It is under MIT license.

The goal is to be 100% ANSI (ANSI INCITS 319-1998) compliant.

I would like to extend the language with mixins or even dynamic object behavior, where the object can elect what behavior it wants to expose dynamically. In classical Smalltalk, this is achievable with #doesNotUnderstand:, but I think that this can be implemented cleaner and more optimal / optimized. This is not difficult to implement technically, the difficult part is in exposing it cleanly to the developer (the end-user of IronSmalltalk).

Cheers,

Todor

Dear Todor,

IIRC there had been at least two approaches to this goal already (S# and #Smalltalk, Dave Simmons’ S# being probably the most advanced and most promising one. Does your approach build on top of those experiences or did you start from scratch? How does your approach differ from the former ones?

Cheers

Helge

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

S# was to my knowledge not sponsored by Microsoft, nor was it “very advanced” when running on the .NET VM/CLR. Dave had another runtime (AOS) that was *very advanced*. He hoped that the .net version eventually would pick up most of the same features, but that never happened. Microsoft later released the DLR (Dave had some influence on that) to enable dynamic languages to actually run on top of .NET (and not just be exotic research projects).

The default .API for .NET is *not* webservices. Anyone saying so is clearly trying to advocate a language missing real .NET bindings.

	Henrik Høyer
	Chief Software Architect
	[hidden email] • (+45) 4029 2092
	Tigervej 27 • 4600 Køge
	www.sPeople.dk • (+45) 7023 7775

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Nowak, Helge
Sent: 28. oktober 2011 11:08
To: [hidden email]
Subject: AW: IronSmalltalk - Smalltalk on top the .Net DLR

Dear Todor,

if I remember correctly at least S# had and implemented the same goals though it was in the pre-DLR era. If I furthermore remember correctly S# had been sponsored by Microsoft, so the implementation should be very advanced. It had also mixins. Maybe if you contact David Simmons he’ll share some of his experiences.

Cheers

Helge

P.S. VisualWorks and ObjectStudio come with the DotNet component for using .NET frameworks at the fine grained level. Providing functionality implemented in Smalltalk to .NET applications and vice versa is usually done via web services, Microsoft’s suggested default API for .NET

Hi Helge,

You are right. There are several implementations on the .Net. This is no more different than the several “native” Smalltalk dialects. They all aim to fulfill certain goal. I started from scratch and I don’t know about the technical approach of the other dialects, but the where IronSmalltalk differs from the other dialects is that the intention is to be first class citizen in the .Net world. It’s not only about running on the .Net and being able to consume .Net libraries and code, but also allow the remaining .Net languages to consume your objects. There is no idea of having a .Net implementation of Smalltalk if you are not going to interact with the rest of the .Net world (both ways).

I believe that the other .Net Smalltalks can easily consume .Net libraries, but I don’t think .Net code can easily consume objects written in Smalltalk. To achieve that you need to leverage the DLR, which to my knowledge none of the other Smalltalks does.

It is under MIT license.

The goal is to be 100% ANSI (ANSI INCITS 319-1998) compliant.

I would like to extend the language with mixins or even dynamic object behavior, where the object can elect what behavior it wants to expose dynamically. In classical Smalltalk, this is achievable with #doesNotUnderstand:, but I think that this can be implemented cleaner and more optimal / optimized. This is not difficult to implement technically, the difficult part is in exposing it cleanly to the developer (the end-user of IronSmalltalk).

Cheers,

Todor

Dear Todor,

IIRC there had been at least two approaches to this goal already (S# and #Smalltalk, Dave Simmons’ S# being probably the most advanced and most promising one. Does your approach build on top of those experiences or did you start from scratch? How does your approach differ from the former ones?

Cheers

Helge

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Well, I have been told by people from Microsoft over and over again that web services is the default for interacting with MS applications. Maybe they were advocating languages with missing .NET bindings??

S# was to my knowledge not sponsored by Microsoft, nor was it “very advanced” when running on the .NET VM/CLR. Dave had another runtime (AOS) that was *very advanced*. He hoped that the .net version eventually would pick up most of the same features, but that never happened. Microsoft later released the DLR (Dave had some influence on that) to enable dynamic languages to actually run on top of .NET (and not just be exotic research projects).

The default .API for .NET is *not* webservices. Anyone saying so is clearly trying to advocate a language missing real .NET bindings.

Dear Todor,

if I remember correctly at least S# had and implemented the same goals though it was in the pre-DLR era. If I furthermore remember correctly S# had been sponsored by Microsoft, so the implementation should be very advanced. It had also mixins. Maybe if you contact David Simmons he’ll share some of his experiences.

Cheers

Helge

P.S. VisualWorks and ObjectStudio come with the DotNet component for using .NET frameworks at the fine grained level. Providing functionality implemented in Smalltalk to .NET applications and vice versa is usually done via web services, Microsoft’s suggested default API for .NET

Hi Helge,

You are right. There are several implementations on the .Net. This is no more different than the several “native” Smalltalk dialects. They all aim to fulfill certain goal. I started from scratch and I don’t know about the technical approach of the other dialects, but the where IronSmalltalk differs from the other dialects is that the intention is to be first class citizen in the .Net world. It’s not only about running on the .Net and being able to consume .Net libraries and code, but also allow the remaining .Net languages to consume your objects. There is no idea of having a .Net implementation of Smalltalk if you are not going to interact with the rest of the .Net world (both ways).

I believe that the other .Net Smalltalks can easily consume .Net libraries, but I don’t think .Net code can easily consume objects written in Smalltalk. To achieve that you need to leverage the DLR, which to my knowledge none of the other Smalltalks does.

It is under MIT license.

The goal is to be 100% ANSI (ANSI INCITS 319-1998) compliant.

I would like to extend the language with mixins or even dynamic object behavior, where the object can elect what behavior it wants to expose dynamically. In classical Smalltalk, this is achievable with #doesNotUnderstand:, but I think that this can be implemented cleaner and more optimal / optimized. This is not difficult to implement technically, the difficult part is in exposing it cleanly to the developer (the end-user of IronSmalltalk).

Cheers,

Todor

Dear Todor,

IIRC there had been at least two approaches to this goal already (S# and #Smalltalk, Dave Simmons’ S# being probably the most advanced and most promising one. Does your approach build on top of those experiences or did you start from scratch? How does your approach differ from the former ones?

Cheers

Helge

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

API for MS applications != API for .NET

Well, I have been told by people from Microsoft over and over again that web services is the default for interacting with MS applications. Maybe they were advocating languages with missing .NET bindings??

S# was to my knowledge not sponsored by Microsoft, nor was it “very advanced” when running on the .NET VM/CLR. Dave had another runtime (AOS) that was *very advanced*. He hoped that the .net version eventually would pick up most of the same features, but that never happened. Microsoft later released the DLR (Dave had some influence on that) to enable dynamic languages to actually run on top of .NET (and not just be exotic research projects).

The default .API for .NET is *not* webservices. Anyone saying so is clearly trying to advocate a language missing real .NET bindings.

Dear Todor,

if I remember correctly at least S# had and implemented the same goals though it was in the pre-DLR era. If I furthermore remember correctly S# had been sponsored by Microsoft, so the implementation should be very advanced. It had also mixins. Maybe if you contact David Simmons he’ll share some of his experiences.

Cheers

Helge

P.S. VisualWorks and ObjectStudio come with the DotNet component for using .NET frameworks at the fine grained level. Providing functionality implemented in Smalltalk to .NET applications and vice versa is usually done via web services, Microsoft’s suggested default API for .NET

Hi Helge,

You are right. There are several implementations on the .Net. This is no more different than the several “native” Smalltalk dialects. They all aim to fulfill certain goal. I started from scratch and I don’t know about the technical approach of the other dialects, but the where IronSmalltalk differs from the other dialects is that the intention is to be first class citizen in the .Net world. It’s not only about running on the .Net and being able to consume .Net libraries and code, but also allow the remaining .Net languages to consume your objects. There is no idea of having a .Net implementation of Smalltalk if you are not going to interact with the rest of the .Net world (both ways).

I believe that the other .Net Smalltalks can easily consume .Net libraries, but I don’t think .Net code can easily consume objects written in Smalltalk. To achieve that you need to leverage the DLR, which to my knowledge none of the other Smalltalks does.

It is under MIT license.

The goal is to be 100% ANSI (ANSI INCITS 319-1998) compliant.

I would like to extend the language with mixins or even dynamic object behavior, where the object can elect what behavior it wants to expose dynamically. In classical Smalltalk, this is achievable with #doesNotUnderstand:, but I think that this can be implemented cleaner and more optimal / optimized. This is not difficult to implement technically, the difficult part is in exposing it cleanly to the developer (the end-user of IronSmalltalk).

Cheers,

Todor

Dear Todor,

IIRC there had been at least two approaches to this goal already (S# and #Smalltalk, Dave Simmons’ S# being probably the most advanced and most promising one. Does your approach build on top of those experiences or did you start from scratch? How does your approach differ from the former ones?

Cheers

Helge

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Web services is nice if you have decoupled system, may be running on several machines. Web services is not nice, and is in fact *HUGE* overhead if you need a component or certain logic in your application and need to call that often.

You can compare web services to the old static HTML days before the scripting languages. You could do a lot, but everything was HTTP requests and responses to the server. The reason people invented browser scripting languages is exactly the same to avoid the overhead with the HTTP request. Tell Google or Facebook to implement their websites without any scripting. The product will be terrible. What I want to bring with IronSmalltalk is the same that scripting languages brought to the browser; a rich and flexible development environment/language.

Well, I have been told by people from Microsoft over and over again that web services is the default for interacting with MS applications. Maybe they were advocating languages with missing .NET bindings??

S# was to my knowledge not sponsored by Microsoft, nor was it “very advanced” when running on the .NET VM/CLR. Dave had another runtime (AOS) that was *very advanced*. He hoped that the .net version eventually would pick up most of the same features, but that never happened. Microsoft later released the DLR (Dave had some influence on that) to enable dynamic languages to actually run on top of .NET (and not just be exotic research projects).

The default .API for .NET is *not* webservices. Anyone saying so is clearly trying to advocate a language missing real .NET bindings.

Dear Todor,

if I remember correctly at least S# had and implemented the same goals though it was in the pre-DLR era. If I furthermore remember correctly S# had been sponsored by Microsoft, so the implementation should be very advanced. It had also mixins. Maybe if you contact David Simmons he’ll share some of his experiences.

Cheers

Helge

P.S. VisualWorks and ObjectStudio come with the DotNet component for using .NET frameworks at the fine grained level. Providing functionality implemented in Smalltalk to .NET applications and vice versa is usually done via web services, Microsoft’s suggested default API for .NET

Hi Helge,

You are right. There are several implementations on the .Net. This is no more different than the several “native” Smalltalk dialects. They all aim to fulfill certain goal. I started from scratch and I don’t know about the technical approach of the other dialects, but the where IronSmalltalk differs from the other dialects is that the intention is to be first class citizen in the .Net world. It’s not only about running on the .Net and being able to consume .Net libraries and code, but also allow the remaining .Net languages to consume your objects. There is no idea of having a .Net implementation of Smalltalk if you are not going to interact with the rest of the .Net world (both ways).

I believe that the other .Net Smalltalks can easily consume .Net libraries, but I don’t think .Net code can easily consume objects written in Smalltalk. To achieve that you need to leverage the DLR, which to my knowledge none of the other Smalltalks does.

It is under MIT license.

The goal is to be 100% ANSI (ANSI INCITS 319-1998) compliant.

I would like to extend the language with mixins or even dynamic object behavior, where the object can elect what behavior it wants to expose dynamically. In classical Smalltalk, this is achievable with #doesNotUnderstand:, but I think that this can be implemented cleaner and more optimal / optimized. This is not difficult to implement technically, the difficult part is in exposing it cleanly to the developer (the end-user of IronSmalltalk).

Cheers,

Todor

Dear Todor,

IIRC there had been at least two approaches to this goal already (S# and #Smalltalk, Dave Simmons’ S# being probably the most advanced and most promising one. Does your approach build on top of those experiences or did you start from scratch? How does your approach differ from the former ones?

Cheers

Helge

Hey guys!

I’ve spent some of my spare time the last year or so to work on yet another Smalltalk dialect. It is (or the goal is) an ANSI compliant Smalltalk that runs as a first class citizen on top the .Net Dynamic Language Runtime (DLR) and that is capable to fully interact with the rest of the .Net world, including IronRuby and IronPython.

The .Net world is big with rich class library, third party code, libraries and modules. Many, often smaller businesses also have a “.Net only” policies, or just tell you that they don’t have the resources to maintain a platform which is not installed out-of-the-box (i.e. doesn’t come with Windows). My personal experience lies in business applications and I have quite solid knowledge in the workings of the .Net. Many other languages are already available on the .Net platform, so I decided that Smalltalk should be as well!

I will be attending the FAST (http://www.fast.org.ar/smalltalks2011) conference in Buenos Aires next week and I will present some of the work on IronSmalltalk. I will write more about the project and the details in a week or two. If you are interested to check it out, it’s hosted here http://ironsmalltalk.codeplex.com/ and is available under MIT license.

Venlig Hilsen / Best regards,

Todor Todorov

Partner

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***