Popularity of Smalltalk in Software Industry
Locked
12345
... 7
12345
... 7
Re: Popularity of Smalltalk in Software Industry
 
|
On May 5, 2011, at 11:32, Toon Verwaest wrote: > This is totally unrelated to having an image; it's just a great debugger implementation. 2 completely different things. No reason why this wouldn't work for C; except for the fact that they didn't do it yet (those lazy bastards). ... and that it's an order of magnitude more difficult! Yes, there are certainly other aspects of being image-based that are way cool, but iterative code development and debugging is a big part of it. (I am teaching a Java course right now with BlueJ, which is a cool environment (at least if you're not used to an image-based system like Smalltalk). It provides a little UML diagram of your classes, and you can create an object by clicking on the appropriate class, and inspect, and call methods. Objects that you create appear on a "workbench". So I had build up a little example with a few objects, found a bug, and edited the class, hit "compile" and *poof* empty workbench. Yes, in Java they probably could have emulated the image, but it's a lot of work!) ../Dave |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by cedreek
On 2011-05-05, at 17:39, Cédrick Béler wrote: > > Le 5 mai 2011 à 17:32, Toon Verwaest a écrit : > >> On 05/05/2011 05:26 PM, Cédrick Béler wrote: >>> >>>> Lastly, most Smalltalk systems are image based... >>> >>> ...which makes you feel the system is "alive", hence one **huge benefit** of Smalltalk: its debugger which enables on the fly debbuging... and also test driven development (real one [1]) where you can run incomplete code and code what's missing iteratively when you need it (Smalltalk is a live system, not only a language as somebody said lately). >>> >>> Cédrick >>> >>> [1] see in particular this webcast: http://www.pharocasts.com/2010/01/starting-with-sunit-and-debugger.html >> Seriously ... these points in favor of the image are so m00t. Lets see how it would work without an image: >> >> I write a C application which I link to GCC. Now I run GDB on my application, and while running I have the whole GCC compiler collection at my disposal while running. While debugging (at some breakpoint) I just let the GCC library compile some C code for me; I turn on the executable flag and whooptidoo, I have a Smalltalk like debugger for C. >> >> This is totally unrelated to having an image; it's just a great debugger implementation. 2 completely different things. No reason why this wouldn't work for C; except for the fact that they didn't do it yet (those lazy bastards). > > ok, true :) > > but, it's not only the debugger... getting senders, implementers, class that use it, methods that contains this word, ... > of course, this is doable with files (see eclipse *sigh*), but I prefer the snappy feeling of an image for that... the snappiness could be easily achieved with a fulltext search index (just look how fast spotlight works on a couple of millions of files on my machine...) The main issue of the image, is that it locks you out, making it close to impossible to use other tools than smalltalk. Though the nice thing about the image is that you can start up your IDE in less than a second, and again, this is not necessarily linked to Smalltalk and could be achieved for C programs as well. |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Dave Mason-3
On 05/05/2011 05:46 PM, Dave Mason wrote:
> On May 5, 2011, at 11:32, Toon Verwaest wrote: > >> This is totally unrelated to having an image; it's just a great debugger implementation. 2 completely different things. No reason why this wouldn't work for C; except for the fact that they didn't do it yet (those lazy bastards). > ... and that it's an order of magnitude more difficult! > > Yes, there are certainly other aspects of being image-based that are way cool, but iterative code development and debugging is a big part of it. > > (I am teaching a Java course right now with BlueJ, which is a cool environment (at least if you're not used to an image-based system like Smalltalk). It provides a little UML diagram of your classes, and you can create an object by clicking on the appropriate class, and inspect, and call methods. Objects that you create appear on a "workbench". So I had build up a little example with a few objects, found a bug, and edited the class, hit "compile" and *poof* empty workbench. Yes, in Java they probably could have emulated the image, but it's a lot of work!) > > ../Dave was already integrated within GDB? Suppose GDB looked like a Smalltalk debugger? Is there anything technical that stands in your way? C is annoying for many other reasons, but not for that one. |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Toon Verwaest-2
On 5/5/2011 10:32 AM, Toon Verwaest wrote:
> On 05/05/2011 05:26 PM, Cédrick Béler wrote: >>> Lastly, most Smalltalk systems are image based... >> >> ...which makes you feel the system is "alive", hence one **huge >> benefit** of Smalltalk: its debugger which enables on the fly >> debbuging... and also test driven development (real one [1]) where >> you can run incomplete code and code what's missing iteratively when >> you need it (Smalltalk is a live system, not only a language as >> somebody said lately). >> >> Cédrick >> >> [1] see in particular this webcast: >> http://www.pharocasts.com/2010/01/starting-with-sunit-and-debugger.html > Seriously ... these points in favor of the image are so m00t. Lets see > how it would work without an image: > > I write a C application which I link to GCC. Now I run GDB on my > application, and while running I have the whole GCC compiler > collection at my disposal while running. While debugging (at some > breakpoint) I just let the GCC library compile some C code for me; I > turn on the executable flag and whooptidoo, I have a Smalltalk like > debugger for C. > > This is totally unrelated to having an image; it's just a great > debugger implementation. 2 completely different things. No reason why > this wouldn't work for C; except for the fact that they didn't do it > yet (those lazy bastards). Disclaimer, I am not a professional programmer and I have not programmed in C or any other static compiled language at all. So I may not have any idea what I am talking about. :) What I don't see in your example, but what I experience in my programming is often in the *use* of my application during development. Part of my application is written in Python (so I can interface I library I can't from Pharo) and part in Pharo. (*use*, ie: the application is compiled and ready for a *user* and I am the user and encounter the bug. My Python app connects to a server on the net and downloads data and inserts it into a PostgreSQL database. It also provides live data to my Pharo app via an http interface. While experimenting with NumPy and running some statistical analysis on a GB or two of data. The analysis took 10-12 hours to run. I start it up and walk away. I get back to it only to find that at the end of all the analysis it exited with a stacktrace. Ugh! I concatenated a string using a ',' instead of a '+'. Switching between Pharo and Python bit me. :) This was at the very end of all the analysis and the generation of a report. The last line of the code had the bug. I lost the 12hours of analysis. This bug passed the syntax checker and the Python compiler when I imported the module. It wasn't until it was live and running and encountered in execution that it was discovered. In Pharo, the same situation, I fix it in the debugger and my report is generated and I continue. All my data is still resident in the image and I can explore and continue. In Python (and I presume most any other dead language) all is lost and I have to rerun. Now as I said I am not a professional. Certain processes would have helped in this situation, but not necessarily all. And I have limited experience with the best other systems or languages have to offer. But how many programming languages/environments handle that well? I am still so very tired of every time an application on my computer says, "You just updated. Do you want to restart?" Why do most every single web application outside of the Smalltalk world require shutdowns and restarts for bug fixes and upgrades? Why does NetBeans consume 200mb, take 3-5minutes to startup, and do a much, much poorer job with syntax, autocomplete, etc. on a single 500 line Python file? I don't think the world out there is anywhere near what Smalltalk has. Nor do they have the vision for it. They are happy with files, and restarts and all their processes to reduce their pain due to not having a live environment. I am a single guy with a vision, an idea, that I want to implement for my business. I have seen nothing that gives me the productivity that Smalltalk does. Not Java, Python, Clojure, Scala, Lua, etc. I have never seen any other language accomplish so much with so few. I look at other languages and apps built with them and look at the armies they have to do so. Then I look at Seaside, etc. with just a small group of guys with an idea of something better. While I desperately want Squeak/Pharo to be able to interface outside systems better. I have seen nothing that is better or comes close. And as I said, I have a business requirement to interface a proprietary library written in C, which why I am connected with Python (and Windows) against my will. So I do understand. I understand, as does everybody else here, that Pharo/Smalltalk is not perfect and has huge areas where we have not done things well or right. But I don't think this is one of them. I think this is one where the rest of the world is behind us. Squeak/Pharo/Smalltalk is empowering. JMHO, take with a grain of salt. :) Jimmie |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Toon Verwaest-2
On 5 May 2011 17:32, Toon Verwaest <[hidden email]> wrote:
> On 05/05/2011 05:26 PM, Cédrick Béler wrote: >> >>> Lastly, most Smalltalk systems are image based... >> >> ...which makes you feel the system is "alive", hence one **huge benefit** >> of Smalltalk: its debugger which enables on the fly debbuging... and also >> test driven development (real one [1]) where you can run incomplete code and >> code what's missing iteratively when you need it (Smalltalk is a live >> system, not only a language as somebody said lately). >> >> Cédrick >> >> [1] see in particular this webcast: >> http://www.pharocasts.com/2010/01/starting-with-sunit-and-debugger.html > > Seriously ... these points in favor of the image are so m00t. Lets see how > it would work without an image: > > I write a C application which I link to GCC. Now I run GDB on my > application, and while running I have the whole GCC compiler collection at > my disposal while running. While debugging (at some breakpoint) I just let > the GCC library compile some C code for me; I turn on the executable flag > and whooptidoo, I have a Smalltalk like debugger for C. > > This is totally unrelated to having an image; it's just a great debugger > implementation. 2 completely different things. No reason why this wouldn't > work for C; except for the fact that they didn't do it yet (those lazy > bastards). > > In image-based setup you tend to do things in a way, that things should be always available at any moment (wanna create an instance of me? - feel free to do it). In C and other languages which having compile & run cycle it is totally different. Things are available for you not instantly, but only after you restart everything from scratch, reinitialize everything and then repeat exactly same steps to meet the same point as before. This is often tedious, time consuming and frustrating. And this difference in approaches leads to fatal flaws in design, like on Windows OS, which requires you to reboot machine every time you install new driver(s). -- Best regards, Igor Stasenko AKA sig. |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Jimmie Houchin-5
On 5 May 2011 18:57, Jimmie Houchin <[hidden email]> wrote:
> On 5/5/2011 10:32 AM, Toon Verwaest wrote: >> >> On 05/05/2011 05:26 PM, Cédrick Béler wrote: >>>> >>>> Lastly, most Smalltalk systems are image based... >>> >>> ...which makes you feel the system is "alive", hence one **huge benefit** >>> of Smalltalk: its debugger which enables on the fly debbuging... and also >>> test driven development (real one [1]) where you can run incomplete code and >>> code what's missing iteratively when you need it (Smalltalk is a live >>> system, not only a language as somebody said lately). >>> >>> Cédrick >>> >>> [1] see in particular this webcast: >>> http://www.pharocasts.com/2010/01/starting-with-sunit-and-debugger.html >> >> Seriously ... these points in favor of the image are so m00t. Lets see how >> it would work without an image: >> >> I write a C application which I link to GCC. Now I run GDB on my >> application, and while running I have the whole GCC compiler collection at >> my disposal while running. While debugging (at some breakpoint) I just let >> the GCC library compile some C code for me; I turn on the executable flag >> and whooptidoo, I have a Smalltalk like debugger for C. >> >> This is totally unrelated to having an image; it's just a great debugger >> implementation. 2 completely different things. No reason why this wouldn't >> work for C; except for the fact that they didn't do it yet (those lazy >> bastards). > > Disclaimer, I am not a professional programmer and I have not programmed in > C or any other static compiled language at all. So I may not have any idea > what I am talking about. :) > > What I don't see in your example, but what I experience in my programming is > often in the *use* of my application during development. Part of my > application is written in Python (so I can interface I library I can't from > Pharo) and part in Pharo. (*use*, ie: the application is compiled and > ready for a *user* and I am the user and encounter the bug. > > My Python app connects to a server on the net and downloads data and inserts > it into a PostgreSQL database. It also provides live data to my Pharo app > via an http interface. > > While experimenting with NumPy and running some statistical analysis on a GB > or two of data. The analysis took 10-12 hours to run. I start it up and walk > away. I get back to it only to find that at the end of all the analysis it > exited with a stacktrace. Ugh! I concatenated a string using a ',' instead > of a '+'. Switching between Pharo and Python bit me. :) This was at the > very end of all the analysis and the generation of a report. The last line > of the code had the bug. I lost the 12hours of analysis. This bug passed the > syntax checker and the Python compiler when I imported the module. It wasn't > until it was live and running and encountered in execution that it was > discovered. > > In Pharo, the same situation, I fix it in the debugger and my report is > generated and I continue. All my data is still resident in the image and I > can explore and continue. In Python (and I presume most any other dead > language) all is lost and I have to rerun. > > Now as I said I am not a professional. Certain processes would have helped > in this situation, but not necessarily all. And I have limited experience > with the best other systems or languages have to offer. > > But how many programming languages/environments handle that well? > > I am still so very tired of every time an application on my computer says, > "You just updated. Do you want to restart?" > > Why do most every single web application outside of the Smalltalk world > require shutdowns and restarts for bug fixes and upgrades? > > Why does NetBeans consume 200mb, take 3-5minutes to startup, and do a much, > much poorer job with syntax, autocomplete, etc. on a single 500 line Python > file? > > I don't think the world out there is anywhere near what Smalltalk has. Nor > do they have the vision for it. They are happy with files, and restarts and > all their processes to reduce their pain due to not having a live > environment. > > I am a single guy with a vision, an idea, that I want to implement for my > business. I have seen nothing that gives me the productivity that Smalltalk > does. Not Java, Python, Clojure, Scala, Lua, etc. > > I have never seen any other language accomplish so much with so few. I look > at other languages and apps built with them and look at the armies they have > to do so. Then I look at Seaside, etc. with just a small group of guys with > an idea of something better. > > While I desperately want Squeak/Pharo to be able to interface outside > systems better. I have seen nothing that is better or comes close. And as I > said, I have a business requirement to interface a proprietary library > written in C, which why I am connected with Python (and Windows) against my > will. So I do understand. > > I understand, as does everybody else here, that Pharo/Smalltalk is not > perfect and has huge areas where we have not done things well or right. But > I don't think this is one of them. I think this is one where the rest of the > world is behind us. > > Squeak/Pharo/Smalltalk is empowering. > 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. > JMHO, take with a grain of salt. :) > > Jimmie > > -- Best regards, Igor Stasenko AKA sig. |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Igor Stasenko
> Yes, but it affects the way how you design your applications and frameworks. > In image-based setup you tend to do things in a way, that things > should be always available > at any moment (wanna create an instance of me? - feel free to do it). > > In C and other languages which having compile& run cycle it is > totally different. > Things are available for you not instantly, but only after you restart > everything from scratch, > reinitialize everything and then repeat exactly same steps to meet the > same point as before. > This is often tedious, time consuming and frustrating. > > And this difference in approaches leads to fatal flaws in design, like > on Windows OS, which requires you to reboot machine every time you > install new driver(s) system, it just makes you think differently. However, suppose that C would have a REPL which gives you an inspector... then you'd already be more inclined to build systems like Smalltalk has. I don't say Smalltalk and its philosophy isn't great, I'm just saying that the image isn't a requirement. I'm sure that if someone would build a more flexible version of C that people would get used to it and want nothing else... even expect it. But whatever :) |
|
|
In reply to this post by Noury Bouraqadi-2
Good evening Roy.
One thing that always amazes me a lot is that so many experienced solution providers (ie. people who develop solutions either to be sold as OTSCS or embedded as a more or less autonomous part of a bigger system) mind about if something is "mainstream" or something else. For several reasons extensively discussed in this forum, smalltalk didn't "hit the market" like java did. It has nothing to do regarding to smalltalk qualities or lack of them. It has to do with good marketing vs. bad marketing, shorter learning curve for things like java and the fact that java was more apt to be used in personal computers of the 1990ies. Besides that, large part of smalltalk community at that time had the "king inside their bellies" and that just made the technology less attractive to outsiders (look: 1990ies language wars). Smalltalk is a really nice technology supporting fast development of complex (and performative) solutions and demanding much smaller teams to do so. It has evident advantages in the fields of code testing, profiling, maintenance and reuse. Most common families of smalltalk like pharo/squeak/Cincom VW/ are cross platform (Windows, Linux, OS X, iOS). Important families of smalltalk are open source (pharo, squeak, gnu smalltalk and dedicated derivatives like OpenCobalt). Smalltak is far from dead. If you investigate you'll see that pharo (for instance) is supported by important universities (listed among 100 best universities in world). In recent years we have witnessed amazing things in smalltalk world. For reasons that can be summarized as immature product adoption in the 1990ies and ugly commercial practices by suppliers, smalltalk is not as popular as java or python. IMHO time will correct this situation. Now, if you want to deploy solutions you have no reason to fear smalltalk except by the fact that it's highly addictive: you start producing and do it fast and clean and just don't want to stop... but, like any d-dealer would say: "don't trust me, you just have to try it... just once... and look: first time is for free !!!" Ok, enough kidding: if you want to deploy solutions you'll see that for the same investment (time & material resources) you do more with smalltalk. You'll loose much less time debugging things, documenting things, figuring out what other people did before... you'll spend much less money in debuggers, profilers, testers, etc... You'll see that reusing and integrating things is just pleasant. And you'll be amazed by performance. That are my 2¢ CdAB |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Igor Stasenko
On 5/5/2011 12:21 PM, Igor Stasenko wrote:
> On 5 May 2011 18:57, Jimmie Houchin<[hidden email]> 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. :) Jimmie |
Re: Popularity of Smalltalk in Software Industry
|
|
Thanks Jimmie
Thanks to kick our asses like that! I would love to have that too in Pharo. Stef > 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. :) > > Jimmie > > |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Jimmie Houchin-5
On 5 May 2011 21:39, Jimmie Houchin <[hidden email]> wrote:
> On 5/5/2011 12:21 PM, Igor Stasenko wrote: >> >> On 5 May 2011 18:57, Jimmie Houchin<[hidden email]> 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 :) > Jimmie > -- Best regards, Igor Stasenko AKA sig. |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Mariano Martinez Peck
On 05/05/11 22:11, Mariano Martinez Peck wrote:
> http://stephane.ducasse.free.fr/FreeBooks.html And of those many good books I'd put in a particular word for "Smalltalk By Example" by Alex Sharp. I found it particularly straightforward and helpful when I was starting out. http://stephane.ducasse.free.fr/FreeBooks/ByExample/ Steve |
|
|
In reply to this post by Toon Verwaest-2
2011/5/5 Toon Verwaest <[hidden email]>:
> > > For me, Java and .NET have never really been worth knowing. > +1 I can't really imagine anything worse than the artifacts of .net "technology". |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Igor Stasenko
On 5/5/2011 4:25 PM, Igor Stasenko wrote:
On 5 May 2011 21:39, Jimmie Houchin [hidden email] wrote:On 5/5/2011 12:21 PM, Igor Stasenko wrote:On 5 May 2011 18:57, Jimmie Houchin[hidden email] 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. 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. http://docs.python.org/library/ctypes.html """ 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. 15.18.1.1. Loading dynamic link librariesctypes 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. Jimmie |
|
|
In reply to this post by cedreek
2011/5/5 Cédrick Béler <[hidden email]>:
> > Lastly, most Smalltalk systems are image based... > > ...which makes you feel the system is "alive", hence one **huge benefit** of > Smalltalk: its debugger which enables on the fly debbuging... and also test > driven development (real one [1]) where you can run incomplete code and code > what's missing iteratively when you need it (Smalltalk is a live system, not > only a language as somebody said lately). Super Full Agree! > Cédrick > [1] see in particular this > webcast: http://www.pharocasts.com/2010/01/starting-with-sunit-and-debugger.html -- |
|
|
In reply to this post by Igor Stasenko
>
> 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. > True, I was just ready to write the same thing about Dolphin and works very well, transforming OLE objects in Smalltalk objects with their respective methods. But allways you need to know what to do with such objects and methods. And is very dependent of the operating system and the underlying technology. I think that the cooperation with the outside world is needed, but I will not miss the advantages of work in Smalltalk, lot of times is more cheap to develop the needed stuff in Smalltalk than a complex artifact to interact with another technology. Cheers. Germán. |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Jimmie Houchin-5
On 6 May 2011 01:03, Jimmie Houchin <[hidden email]> wrote:
> On 5/5/2011 4:25 PM, Igor Stasenko wrote: > > On 5 May 2011 21:39, Jimmie Houchin <[hidden email]> wrote: > > On 5/5/2011 12:21 PM, Igor Stasenko wrote: > > On 5 May 2011 18:57, Jimmie Houchin<[hidden email]> 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. > So, read about it. It doesn't bites. :) > 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. > > http://docs.python.org/library/ctypes.html > > """ > 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. > > 15.18.1.1. 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 >>> > So? Why do you think that you cannot do the same in Pharo? Have you digested what is available before doing it in Python? > """ > > It has examples for windows and linux. > I feel that you are seriously under-informed. Just try googling for: Squeak + FFI Alien NativeBoost and just check what you can do using it: http://www.squeaksource.com/NBOpenGL/ also check mail archives. Forgive me, but i really can't understand , why you can't just look for what you need by yourself? Are google.com banned by your ISP? For me this subject is interested in aspect, why this information (while being available openly) didn't catch your attention , so you using python instead. (Okay, you might miss some functionality like being able to automatically generate bindings to COM interfaces). But again, i am sure that if you surf the net or ask right questions on mailing list, you will probably discover that there is already work being done in that direction. And at last, if you feel that there is missing some key functionality which you want, and you expect that it is also could be useful to community, you can always implement it and share with people (instead of using Python ;). So, next who will come after you won't find himself in a desert with couple of oasises few hundred miles away. > 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. > > Jimmie > -- Best regards, Igor Stasenko AKA sig. |
Re: Popularity of Smalltalk in Software Industry
|
|
On Fri, May 6, 2011 at 3:19 AM, Igor Stasenko <[hidden email]> wrote:
Indeed, one thing FFI / Alien / NB don't have is a documentation as nice as http://docs.python.org/library/ctypes.html in http://book.pharo-project.org/
FFI / Alien / NB may be powerful, it seems I've never managed to do what I want, even with all mailing lists support (search mails on yaz / z3950 or id3taglib). In Python it works on OSX out of the box (I've just tried :)
But when I was working with Python and Ruby several years ago things was easy (for my needs), I think because of documentation. Laurent And at last, if you feel that there is missing some key functionality |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Igor Stasenko
On 5/5/2011 8:19 PM, Igor Stasenko wrote:
> On 6 May 2011 01:03, Jimmie Houchin<[hidden email]> wrote: >> On 5/5/2011 4:25 PM, Igor Stasenko wrote: >> >> On 5 May 2011 21:39, Jimmie Houchin<[hidden email]> wrote: >> >> On 5/5/2011 12:21 PM, Igor Stasenko wrote: >> >> On 5 May 2011 18:57, Jimmie Houchin<[hidden email]> 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. > So, read about it. It doesn't bites. :) spare time. I have a full-time+ job and a very large family who want some of my time. >> 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. >> >> http://docs.python.org/library/ctypes.html >> >> """ >> 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. >> >> 15.18.1.1. 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 > So? Why do you think that you cannot do the same in Pharo? > Have you digested what is available before doing it in Python? I never said it couldn't be done in Pharo or Squeak. What I said is that I lack the skills to do so in Pharo. It isn't a two lines of code an your off and running. Which is what Python provided me. Ok, in total, my Python code is more like 500 lines. It interfaces the COM DLL and serves the data to my Pharo app which provides all of my business logic. The Python app is simply an interface and gateway. No business logic. >> """ >> It has examples for windows and linux. > I feel that you are seriously under-informed. > Just try googling for: > > Squeak + FFI > Alien > > NativeBoost > > and just check what you can do using it: > > http://www.squeaksource.com/NBOpenGL/ > > also check mail archives. > > Forgive me, but i really can't understand , why you can't just look > for what you need by yourself? > Are google.com banned by your ISP? > > For me this subject is interested in aspect, why this information > (while being available openly) didn't catch your > attention , so you using python instead. > (Okay, you might miss some functionality like being able to > automatically generate bindings to COM interfaces). > But again, i am sure that if you surf the net or ask right questions > on mailing list, you will probably discover that > there is already work being done in that direction. > And at last, if you feel that there is missing some key functionality > which you want, and you expect that it is also > could be useful to community, you can always implement it and share > with people (instead of using Python ;). > So, next who will come after you won't find himself in a desert with > couple of oasises few hundred miles away. off-list conversations with people who have used Alien/FFI about what I need. It is presently beyond my current skill and knowledge and time to acquire said knowledge. I am not saying it isn't doable. I am saying at the moment it isn't anything I have the time to pursue. I already have in place a working solution. It isn't as nice as I would like, or an all Pharo solution. But it is working. The current working solution is simply version 1.0 of my application. When it is up and running and I have further time I will explore other options. Ok, as far mentioning this before here I go. :) My messages squeak-dev 11/17/2009 1:23 PM Re: My own Squeak direction Presently I am writing an app that I would love to do in Squeak but cannot. Why Squeak? Simply because I love working within a live environment. I love the tools available for writing the code. I love being able to fix a problem live and continue on. Not starting all over. But I am constrained. I am provided two options for my application. 1. Interface with a Windows COM library. 2. Interface with Java libraries. ____________ squeak-dev 6/20/2010 11:52 PM Re: Interesting survey about smalltalk I would love to be using Squeak for my financial application. Numerical performance isn't currently what is stopping me. My problem is that I require interfacing with a Windows COM dll and in a future version with a Java library. Hopefully at some point I will be able to port to Squeak. I would much prefer it to using Python, which is what I am currently using. ____________ pharo-devel 9/29/2010 8:54 AM Re: Calling Python from Pharo I have been much in the same situation. I am developing a financial technical analysis application in Pharo. Part of my requirements are the use of a Windows COM dll. I do not have the ability to use that dll from within Pharo. (My skills are too limited) I have written the front end/back end of my application in Python interfacing the dll and the financial server. I am writing the middle part of the application in Pharo using Seaside. My Python app will call my Seaside app with the necessary data and my Seaside app will provide the Python app the necessary actions. This also enables me to provide a web interface to my application. ___________ 12/31/2010 4:24 PM And for complete disclosure. My plans for my app version 2.0 which eliminate interfacing any external library but rather accessing a different protocol via http. Proper Smalltalk lots of classes I am porting the FIX protocol to Squeak/Pharo. http://www.fixprotocol.org/ ... I haven't been silent (dating back to Nov. 2009), and I have done some due diligence. My decisions weren't made out of ignorance of what options are available, but rather my ignorance and ability to use some of the options. I am interested in writing my application. Not down and dirty interfacing of external libraries. That isn't where my knowledge or skill lies. It isn't where I want to spend my time. Which is why I commented about the Python library which allowed me to interface a COM DLL in two lines. The ctypes library I referred to above, I chose not to use because it wasn't as easy as the already working solution I had. The Python library generated As I stated, I am not a professional programmer. I have no computer science background. I have no C/C++/C# skills. The more time I spend doing low level stuff or learning how to do so, the less time I have to spend on what my app is intended to do, the business logic. My goal is more along the lines of getting my business up and running and hiring knowledgeable people like you to do the things that enable people like me. I find Smalltalk enabling for the guy with an idea. Its the most enabling and empowering tool I've found for my ideas. I would like to see it improve in its enabling ability. I get excited about executing my ideas. If I had no options but to learn Alien/FFI or ctypes, or C/C++/C#/F3, in order to build my application. I would. But it would delay me considerably. I have more ideas, than time. I would like to see Pharo's story for interfacing external libraries to be better than Pythons. It would be very enabling for those of us with less skills, and less time for those who have the skills. Thanks. Jimmie |
Re: Popularity of Smalltalk in Software Industry
|
|
In reply to this post by Igor Stasenko
Igor
We should face it: the FFI and Alien... are not that simple. Laurent spent time to try to cnnect to libs and it did not work. So we should really improve that aspect. Igor not everbody is able to code in assembler for nativeboost. So NB is probably a good insfrastructure but not ready for consumption for everybody. The interaction with C should be improved :) Stef > So, read about it. It doesn't bites. :) > >> 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. >> >> http://docs.python.org/library/ctypes.html >> >> """ >> 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. >> >> 15.18.1.1. 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 >>>> >> > > So? Why do you think that you cannot do the same in Pharo? > Have you digested what is available before doing it in Python? > > >> """ >> >> It has examples for windows and linux. >> > > I feel that you are seriously under-informed. > Just try googling for: > > Squeak + FFI > Alien > > NativeBoost > > and just check what you can do using it: > > http://www.squeaksource.com/NBOpenGL/ > > also check mail archives. > > Forgive me, but i really can't understand , why you can't just look > for what you need by yourself? > Are google.com banned by your ISP? > > For me this subject is interested in aspect, why this information > (while being available openly) didn't catch your > attention , so you using python instead. > (Okay, you might miss some functionality like being able to > automatically generate bindings to COM interfaces). > But again, i am sure that if you surf the net or ask right questions > on mailing list, you will probably discover that > there is already work being done in that direction. > And at last, if you feel that there is missing some key functionality > which you want, and you expect that it is also > could be useful to community, you can always implement it and share > with people (instead of using Python ;). > So, next who will come after you won't find himself in a desert with > couple of oasises few hundred miles away. > >> 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. >> >> Jimmie >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |