- Pharo-users - lists.pharo.org

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by horrido

This is exactly why I also push Smalltalk's simplicity. In the 1970s, Per Brinch Hansen posited that a small, simple language would lead to fewer programmer errors. The result of his work was the Edison programming language. It was published in his book, "Programming a Personal Computer," which is one of my favourite programming books. Of course, Per Brinch Hansen wasn't alone in this belief. It was also shared by Niklaus Wirth who created Pascal and Oberon. So it's not just Smalltalk's live programming environment that we should herald. The size and simplicity of the language is a big deal. Richard Sargent wrote > On Fri, Jan 10, 2020 at 1:52 PM horrido < > horrido.hobbies@ > > wrote: > >> Offray Vladimir Luna CÃ¡rdenas-2 wrote >> > But I have not >> > being able to convince any of my coder friends to switch to Pharo >> > instead of C++, Java or Javacript, which by the way, is the language >> > they already know and use to put bread on the table on a daily basis. >> > >> > So I think that we deal with a paradox: while Smalltalk advocacy is >> > better suited for a Blue Ocean Strategy[2], exploring and implementing >> > new/emerging scenarios and markets, money is already mostly invested in >> > Red Oceans of constituted technologies and practices ecosystems. >> > Bridging both is pretty difficult. >> >> Yes, that is the principal obstacle and challenge. When I'm pushing >> Smalltalk, I mention the language's simplicity and conciseness, I >> mention the purity of the object-oriented model, I mention the >> built-in IDE, and so on. But the key advantage that I emphasize >> is *programmer productivity*. >> >> I realize it's hard to argue with the availability of jobs for Java, >> Python, >> JavaScript, etc. It's hard to argue with their rich ecosystems. It's >> hard to argue with the status quo of established code bases and >> IT infrastructures. But we have to make them believe that >> Smalltalk can cut their development time in half, if not better. >> >> What is it worth to a company to cut their development time in half? >> It means much lower development cost. It means much shorter >> "time to market." >> > > It also means much lower error rates. Capers Jones also review errors / > lines of code and Smalltalk was substantially better than the C derivative > languages. I don't recall the ration, but I think the Namcook report does > include it. > > Fewer errors means a higher ratio of time spent delivering functionality > and a better customer experience. (We can't do anything about bad design > and UX practices, of course and unfortunately. Although, I suspect without > evidence that Smalltalkers may do a better job of both.) > > >> Is this not worth investing time and energy in Smalltalk? Even if the >> job opportunities aren't there. Even if it means overhauling your >> IT infrastructure. >> >> The investment can lead to more users and more jobs. If they don't >> believe it, then we have failed. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Richard Sargent

On Fri, Jan 10, 2020 at 1:52 PM horrido <horrido.hobbies(a)gmail.com> wrote: > Offray Vladimir Luna CÃ¡rdenas-2 wrote > > But I have not > > being able to convince any of my coder friends to switch to Pharo > > instead of C++, Java or Javacript, which by the way, is the language > > they already know and use to put bread on the table on a daily basis. > > > > So I think that we deal with a paradox: while Smalltalk advocacy is > > better suited for a Blue Ocean Strategy[2], exploring and implementing > > new/emerging scenarios and markets, money is already mostly invested in > > Red Oceans of constituted technologies and practices ecosystems. > > Bridging both is pretty difficult. > > Yes, that is the principal obstacle and challenge. When I'm pushing > Smalltalk, I mention the language's simplicity and conciseness, I > mention the purity of the object-oriented model, I mention the > built-in IDE, and so on. But the key advantage that I emphasize > is *programmer productivity*. > > I realize it's hard to argue with the availability of jobs for Java, > Python, > JavaScript, etc. It's hard to argue with their rich ecosystems. It's > hard to argue with the status quo of established code bases and > IT infrastructures. But we have to make them believe that > Smalltalk can cut their development time in half, if not better. > > What is it worth to a company to cut their development time in half? > It means much lower development cost. It means much shorter > "time to market." > It also means much lower error rates. Capers Jones also review errors / lines of code and Smalltalk was substantially better than the C derivative languages. I don't recall the ration, but I think the Namcook report does include it. Fewer errors means a higher ratio of time spent delivering functionality and a better customer experience. (We can't do anything about bad design and UX practices, of course and unfortunately. Although, I suspect without evidence that Smalltalkers may do a better job of both.) > Is this not worth investing time and energy in Smalltalk? Even if the > job opportunities aren't there. Even if it means overhauling your > IT infrastructure. > > The investment can lead to more users and more jobs. If they don't > believe it, then we have failed. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by horrido

Offray Vladimir Luna CÃ¡rdenas-2 wrote > But I have not > being able to convince any of my coder friends to switch to Pharo > instead of C++, Java or Javacript, which by the way, is the language > they already know and use to put bread on the table on a daily basis. > > So I think that we deal with a paradox: while Smalltalk advocacy is > better suited for a Blue Ocean Strategy[2], exploring and implementing > new/emerging scenarios and markets, money is already mostly invested in > Red Oceans of constituted technologies and practices ecosystems. > Bridging both is pretty difficult. Yes, that is the principal obstacle and challenge. When I'm pushing Smalltalk, I mention the language's simplicity and conciseness, I mention the purity of the object-oriented model, I mention the built-in IDE, and so on. But the key advantage that I emphasize is *programmer productivity*. I realize it's hard to argue with the availability of jobs for Java, Python, JavaScript, etc. It's hard to argue with their rich ecosystems. It's hard to argue with the status quo of established code bases and IT infrastructures. But we have to make them believe that Smalltalk can cut their development time in half, if not better. What is it worth to a company to cut their development time in half? It means much lower development cost. It means much shorter "time to market." Is this not worth investing time and energy in Smalltalk? Even if the job opportunities aren't there. Even if it means overhauling your IT infrastructure. The investment can lead to more users and more jobs. If they don't believe it, then we have failed. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Offray Vladimir Luna CÃ¡rdenas

Hi, (I don't know if there is a netiquete rule of _this list_ about top-posting inter-posting or bottom-posting, so I will start here). Is good to see a thread like those with different points, so thanks to all participants. I agree with several of them. I think that Smalltalk advocacy is important, but it happens in different ways, some write prose for that, some code, some both. In my case, Smalltalk has the strongest point by blurring the frontier between separate concerns: language, IDE, tools, writing/execution time and is an experience that may other computing environments, frameworks and languages are trying to bring (see Svelte, DarkLang, Elm, Clojure and so on). I still think that the way Smalltalk blurs concerns and the live coding experience it creates by doing so, is unbeatable. But the way Smalltalk expose its advantages works in particular domains (research, prototyping) and not so well in others (mobile) where others are delivering more and faster apps for the developer and user. In my case, Smalltalk environments, particularly Pharo, work well because I used it for my PhD research prototyping and is well suited for my exploration of new domains (for example I'm now exploring the Scuttlebutt protocol and social network [1] in Pharo). But I have not being able to convince any of my coder friends to switch to Pharo instead of C++, Java or Javacript, which by the way, is the language they already know and use to put bread on the table on a daily basis. I have been more successful convincing philosophers, librarians, journalists in using Pharo and they enjoy it, but I have not any Pharo related local job proposal and I doubt I will have it. [1] https://scuttlebutt.nz/ So I think that we deal with a paradox: while Smalltalk advocacy is better suited for a Blue Ocean Strategy[2], exploring and implementing new/emerging scenarios and markets, money is already mostly invested in Red Oceans of constituted technologies and practices ecosystems. Bridging both is pretty difficult. I will share some Blue Ocean experiments, but still they are, as usual, weekend and holidays projects without any promise or resources for a sustained rhythm or deliverables. [2] https://en.wikipedia.org/wiki/Blue_Ocean_Strategy Also, there is an important consequence of Richard's (and others) outreach strategies and is the "inner-reach" echoes of them, so we have this kind of talks that are worthy and not so frequent about the inter subjectivities in our community and the ways we think and experience about Smalltalk in the present and in the future. Thank you all, Offray On 10/01/20 10:53 a.Â m., Marten Feldtmann wrote: > Am 10.01.20 um 15:42 schrieb horrido: > >>> So let's stop trying to convince people with things that mattered some >>> 20 years ago. Even the function point thingie we keep carrying in front >>> of our bellies (Capers-Jones was it?) is a lie when you want to build an >>> application for today's markets. >> I disagree that it's a lie. The study is based on thousands of projects and >> millions of lines of code over a period of several decades, including recent > Well, naming it a "lie" is perhaps too strong - but Joachim (did you > have a bad Smalltalk day ?????) statement is from my point of view > correct - this talking about function point and productivity is an > academic point. > > If I am a Java developer and my productivity is around 10% compared to > Smalltalk developer it is still useful to use Java - because for my > problem there might exists already dozen of libraries and solutions. > > Using Smalltalk today is matter of personal taste and love - like many > other developers in other languages. > > Joachim mentioned the critical points and for me perhaps the following > statements are true: > > * Smalltalk development over the last decade ran in circles > > and due to that > > * Smalltalk is not solving the biggest problems any more > > So many time has been wasted to make a Smalltalk dialect running in a > browser. > > I would use (my loved) Smalltalk today only, if > > * I have an application, which was written in Smalltalk (and I have one) > > * Smalltalk is superior to other solutions in a specific topic (and with > Gemstone I have one topic) > > When I would start from scratch ... build a headless Smalltalk, put lots > of good communication libraries into it, spread it over Windows, Mac and > Linux, make it open source and put some XML and JSON and solve printing, > multithreading/multiprocessing (framework) runtime AND (!) debugging, > scripting, interconnections with other languages. Try adding a modelling > and source code generator. Build the whole stuff with concurrency in > mind - offer specific data structure to help you here. Look for suitable > persistency options. > > Go back to the time, where Smalltalk source code was hold in a > repository to manually work with it and and not getting software via > Github with some broken relationships between packages and nobody knows why. > > Use the browser (with Javascript) as the main UI and build a superior > interface in Javascript to the backend Smalltalk. Use the Electron > framework and build some specific support for Smalltalk into that. > > But even with that in mind you will not catch the Javascript developers > (because they are on that way already and they do not need Smalltalk), > but you may survive as a Smalltalk developer. > > Spread the word around, that multi-language development is a MUST and > one should support it. > > So, to summarize - this is my personal view of Smalltalk today - since > 1986, where I first met Georg Heeg on a Atari fair in DÃ¼sseldorf seeing > the first Smalltalk system in my life. > > Marten > > > >

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by horrido

itlists(a)schrievkrom.de wrote > Am 10.01.20 um 15:42 schrieb horrido: > >> >>> So let's stop trying to convince people with things that mattered some >>> 20 years ago. Even the function point thingie we keep carrying in front >>> of our bellies (Capers-Jones was it?) is a lie when you want to build an >>> application for today's markets. >> >> I disagree that it's a lie. The study is based on thousands of projects >> and >> millions of lines of code over a period of several decades, including >> recent > > Well, naming it a "lie" is perhaps too strong - but Joachim (did you > have a bad Smalltalk day ?????) statement is from my point of view > correct - this talking about function point and productivity is an > academic point. Not so academic. After all, the study was based on a huge number of software projects for dozens of programming languages over many years. It doesn't get any more practical than that. The analysis was simplified by adopting the "function points" model which provides a level playing field for all the languages. It's about the amount of time needed to do a certain amount of work, whether that work is specific to a few domains or to many. Some people may take issue with the analysis, but it's there for your consideration at any rate. Since there is no other study of its kind in the world, I choose to use it in my advocacy. Readers can make their own judgement. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Marten Feldtmann

Am 10.01.20 um 15:42 schrieb horrido: > >> So let's stop trying to convince people with things that mattered some >> 20 years ago. Even the function point thingie we keep carrying in front >> of our bellies (Capers-Jones was it?) is a lie when you want to build an >> application for today's markets. > > I disagree that it's a lie. The study is based on thousands of projects and > millions of lines of code over a period of several decades, including recent Well, naming it a "lie" is perhaps too strong - but Joachim (did you have a bad Smalltalk day ?????) statement is from my point of view correct - this talking about function point and productivity is an academic point. If I am a Java developer and my productivity is around 10% compared to Smalltalk developer it is still useful to use Java - because for my problem there might exists already dozen of libraries and solutions. Using Smalltalk today is matter of personal taste and love - like many other developers in other languages. Joachim mentioned the critical points and for me perhaps the following statements are true: * Smalltalk development over the last decade ran in circles and due to that * Smalltalk is not solving the biggest problems any more So many time has been wasted to make a Smalltalk dialect running in a browser. I would use (my loved) Smalltalk today only, if * I have an application, which was written in Smalltalk (and I have one) * Smalltalk is superior to other solutions in a specific topic (and with Gemstone I have one topic) When I would start from scratch ... build a headless Smalltalk, put lots of good communication libraries into it, spread it over Windows, Mac and Linux, make it open source and put some XML and JSON and solve printing, multithreading/multiprocessing (framework) runtime AND (!) debugging, scripting, interconnections with other languages. Try adding a modelling and source code generator. Build the whole stuff with concurrency in mind - offer specific data structure to help you here. Look for suitable persistency options. Go back to the time, where Smalltalk source code was hold in a repository to manually work with it and and not getting software via Github with some broken relationships between packages and nobody knows why. Use the browser (with Javascript) as the main UI and build a superior interface in Javascript to the backend Smalltalk. Use the Electron framework and build some specific support for Smalltalk into that. But even with that in mind you will not catch the Javascript developers (because they are on that way already and they do not need Smalltalk), but you may survive as a Smalltalk developer. Spread the word around, that multi-language development is a MUST and one should support it. So, to summarize - this is my personal view of Smalltalk today - since 1986, where I first met Georg Heeg on a Atari fair in DÃ¼sseldorf seeing the first Smalltalk system in my life. Marten -- Marten Feldtmann

Jan. 10, 2020

TechTalks: Dates + Call

by Marcus Denker

Hi, Here are dates for the Pharo TechTalks first half of 2020: January 23: https://association.pharo.org/event-3697009 Thursday 20 https://association.pharo.org/event-3697011 March 19 https://association.pharo.org/event-3697012 April 23 https://association.pharo.org/event-3697013 May 28 https://association.pharo.org/event-3697016 June 18 https://association.pharo.org/event-3697017 We need topics! If you want to take over one of these talks to show your project (or something that you find interesting) â> send me a mail. The date/time can be changed as needed, too. Archive of past techtalks: https://pharo.org/TechTalk

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by David T. Lewis

On Fri, Jan 10, 2020 at 10:52:51AM +0100, jtuchel(a)objektfabrik.de wrote: > > I wanted to stay out of this thread, because it leads nowhere. But now > that I've typed all this, I will push the send button and regret it in a > few minutes... Joachim, Thanks for pushing the send button. Dave

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by horrido

jtuchel wrote > Am 10.01.20 um 10:16 schrieb Marten Feldtmann: >> That happened once in the history of Smalltalk and the big player was >> IBM ... > > Well, twice actually ;-) > Many people might not know that HP once was a Smalltalk vendor with > their distributed Smalltalk (which was actually a white-label copy of > VisualWorks iirc/iiuc)... > > Big corporations do not warrant the success of a technology. We'd still > be using OS/2, BS2000, whatever...Â today if that was the case. True, but major tech adoption *can* greatly increase public mindshare. C#, TypeScript, Golang, Kotlin, Swift, and Rust are good examples. > So let's stop trying to convince people with things that mattered some > 20 years ago. Even the function point thingie we keep carrying in front > of our bellies (Capers-Jones was it?) is a lie when you want to build an > application for today's markets. I disagree that it's a lie. The study is based on thousands of projects and millions of lines of code over a period of several decades, including recent years with languages like C#, Ceylon, Dart, Elixir, F#, Golang, Haskell, Haxe, Julia, and LiveScript. Some of these are cutting-edge languages used for modern applications. > Smalltalk is great. If you don't need a mobile app to accompany your > product. It's great if your GUI doesn't have to be sexy as hell or you > are happy reinventing wheels. It is great if you only ship to PCs or on > the web and don't need a lot of interaction in the browser. Anything > else is hard in Smalltalk. If it's not, it is undocumented. Well, perhaps not for ALL mobile apps, but Cordova is certainly used for cross-platform mobile development. I've used it with Amber and PharoJS and the documentation is pretty good. People also use React Native, so there's no real reason to avoid JS. > I am not sure if energy spent on these "syntax fits on a postcard and, > btw,Â we have the balloon" articles could be better spent doing > something about the problems I mention here. I was in the same boat in > the late 90ies and early 2000's with my blog and articles and stuff. All > I found out was that nobody actually cares about these old hat stories. > Heck, a lot of people these days don't even care about maintainability. > You don't like it any more? No prob, we can redo it in this great new > (JS) framework anyways. It's not an either-or situation. We can market Smalltalk *and* address the technical weaknesses of Smalltalk. For example, I'm doing the former and you guys are doing the latter. What's the problem? It would be nice if more Smalltalkers got involved with Smalltalk marketing. I can't do this forever. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Jan. 10, 2020

Re: [Pharo-users] Why Smalltalk is so easy to evangelize

by Esteban Maringolo

On Fri, Jan 10, 2020 at 6:53 AM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: > I wanted to stay out of this thread, because it leads nowhere. But now > that I've typed all this, I will push the send button and regret it in a > few minutes... Don't regret it, I like how you wrote and I agree with most of what you said, maybe because we deal with similar kind of software solutions. It's only when you use something to solve a real problem, usually with economic constraints, that you find its strengths and limitations. And Smalltalk has both. Regards, Esteban A. Maringolo

Jan. 10, 2020