November 2017 - Pharo-users

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Engineers donât innovate often in core technologies, because theyâre careful. Of course that also means they generally make terrible marketers ð. They also donât generally compete, which is part of the problem in this industry. The semiconductor industry, for instance, provides money to an independent institute, ISMI, that advances the core technologies they all use. We do love shiny new toys though, thatâs half the reason we became engineers. You donât âneedâ an image by any means, but the fact that my live coding environments in Eclipse have been running, hiding behind modal dialogs, for 332, 468, and 992 hours respectively, due to constantly comparison between in-memory data and on-disk data combined with a crappy eventing model, implies that itâs at the very least much easier. Granted theyâre building parts of a huge program, an ERP, and using JPA with it. Still, I have 3 Eclipse environments on 3 Sun servers with 64 threads each that have been untouchable for many days. Smalltalk is âaâ way, a way that doesnât have the massive discrepancies between its syntactical appearance and dynamic implementation that C++ and Java suffer from, discrepancies that dynamically propagate depending on different libraries, frameworks, internal system states and external environments. Python is another way, it has plenty of strengths. Its weakness is that it doesnât scale in terms of either data size or complexity. Odoo is a great case, most usable ERP out there for the end user, but if you try to run more than a few of the 40 odd modules it craps out. Largely thatâs lack of time or investment, if you havenât the latter, you need the former. IMO Python is closer to Smalltalk than GNU Smalltalk. But why compete? Where Python has strengths I use it, where there are reliable, stable technologies in Java I use them (Synapse and JINI are two main ones). If I have to do work in a browser I have to write JS, I just donât try to do things itâs not reliably capable of. If Iâm using ACT-R for modeling, I use LISP, for Wordnet I use Prolog. Writing any language in another, especially a language like C, is not going to work well in the long term, because while writing the language, one canât be in that languageâs proper mindset. As a result Ruby looks like Smalltalk but works like Java, except a Java without the massive investment that make actual Java somewhat reliable. Funny you mentioned Alan Kay, given I had a disagreement with him last night. His argument was that we need to think beyond Smalltalk, beyond anything out there at the moment. My argument was that we havenât yet caught up to Smalltalk, never mind LISP, and that despite nearly everything we use having originated in those, most donât even recognize it. Weâre nowhere near ready for a new paradigm when we havenât digested the old one yet. It was a polite disagreement. Nevertheless, AFAIK only God is God, and I donât speak with him personally all that regularly ð. Pharo is far from the Smallltalk I began with in â88. Morphic is well beyond MVC and the improvements to it, combined with the things built on it, are keys to why I use Pharo. The JIT compiler is a another big improvement, which originated with Strongtalk - the PoC for the Java JIT compiler written by Sun. But when my first language, Forth, is still better than 90% of the ânewâ languages out there, using those new languages as core technologies is problematic. New is better only if its actually better. Andrew Sent from Mail for Windows 10 From: Dimitris Chloupis Sent: Monday, November 6, 2017 5:29 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument all people like popular choices, including engineers. Engineers may be more careful but they are not known exactly for their talent to innovate.Â We are pact animals, we are social animals.Â This is far from a coding problem, its pretty much coded right inside our DNA, not just for us but also for any other animal. And we have our trends too, our resistance to git is an excellent example. A general fixation of avoiding files and especially text files. The unreasonable argument that you need an image to preserve a live coding enviroment. The idea that just because you have access to the complete source code , life becomes easier for some weird way as if people are likely to mess with the internals of a system. That for some weird reason you cannot have access to source code in other languages or that is hard to do so. The notion that live coding is only possible or only easy in Smalltalk. That reimplementing everything in Smalltalk is a great idea. That minimal syntax equals softer learning curve. That Smalltalk is the only sensible way of doing OOP.Â Finally but not least, "Alan Kay is god".Â Â People love to stick to their beliefs (me included) and not feel comfortable questioning them. It's no surpise it tooks us hundrends of thousands of years to get to this point. JS is chosen as a language for the same reason its so hated, its third party libraries. As coders we have to rely a lot more to libraries than we have to rely on languages. Sure a language can solve many potential problem but a powerful library support can practically give you code on a plate. Hence also why JS is practically non existant outside web dev and that is pretty rare for a language.Â So sure popularity plays a major role but in the end the preference for JS is not insanity, its the right choice for what it focuses on. A difficult/ not that well designed languageÂ + big library support will always be easier to use than a super ease elegant language without such big library support. The time when we were relying on our code and our own libraries has passed long time ago.Â Â Â On Mon, Nov 6, 2017 at 10:37 AM Andrew Glynn <aglynn42(a)gmail.com> wrote: Btw, I think we gained pace when JS took over the front end, but lost visibility.Â Nothing is slower than coding a client/server app with the front end in JS. The âriseâ of JS is a side effect of the fact that the web was designed, built and continues to be built by âcodersâ who donât know enough to be called amateurs. Â What puts 'codersâ off though is related to way JS is and (mostly doesnât) work.Â You canât just sit down and âhack onâ Smalltalk until it âsorta kindaâ does what you want.Â You canât grab code from some random website and âfiddle with itâ until it âsorta kindaâ works. âCodersâ canât make it âsorta kindaâ work, and they donât know how to write code that works. Â One of the better JS programmers Iâve worked with said at one point âEngineers canât write JavaScript because it doesnât fit their mentality.Â I used to be a retoucher, Iâd spend hours and hours getting one pixel right.Â Thereâs no good reason that one pixel had to be that way, but the image didnât âgoâ otherwise. JavaScript is like that, you spend hours and hours messing with it, getting it to work, and at the end you donât know why it works, nor why it didnât.Â Thatâs not an engineerâs mindset.â Â Do aviation engineers choose tools based on âpopularityâ? At the same time, would you want your next flight to be on an aircraft running on JavaScript?Â I wouldnât eat from a microwave running JavaScript.Â Â Iâd rather be an engineer than a popularity contestant or a fashion victim. Â In any case, more often than not itâs management that chooses technologies, generally based on who they have lunch with more than anything else.Â Â Andrew Â Sent from Mail for Windows 10 Â From: Dimitris Chloupis Sent: Monday, November 6, 2017 2:35 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â Another way of promoting Pharo is copying its advantages to other languages. The ideal way is for people to get straight to Pharo and fall in love with it. But sometimes this may be possible for several reasons. The most usual being that people simple are not in the mood of learning a new language unless they have to. As the saying goes "People love progress , its just that they equally hate change" Â Introducing similar features to another language, like I did with introducing live coding enviroment to Python with direct reference back to Pharo is a very good way to promote the language. Just because you cannot code in Pharo at your work does not mean you cannot code the Pharo way. Just put a huge tag in your documentation, comments and anywhere you mention your code "inspired by Pharo ( https://pharo.org)" and you will get their attention whether they like the idea of learning a new language or not.Â Â Its like watching an ad, using sex, humour and even unrelated stuff to grab your attention to a product. The idea here is to get the attention, once you do that, the rest follows.Â Â A huge problem with Smalltalk in general is that even though every language, enviroment, tool, IDE has been copying it , it is rarely mentioned. If it did , I have no doubt it would have been masively more popular than it is right now.Â Â On Mon, Nov 6, 2017 at 9:22 AM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: Phil, Am 26.10.17 um 08:17 schrieb phil(a)highoctane.be: > > > Now we miss the boat on mobile and bigdata, but this is solvable. You know, "It's solvable, and it's even easy in Smalltalk" has been what we've been shouting down at those worms in the C++/Java swamp for decades. We just never really proved it. We also missed the boat on web. Seaside was the last real innovation in that field, almost 15 years ago. When Javascript took over the frontend, we lost pace. > > If we had an open Java bridge (and some people in the community have > it for Pharo but do not open source it - so this is eminently doable) > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big > executable we would have a way to embed Pharo in a lot of places (e.g. > in the Hadoop ecosystem where fast starting VMs and small footprint > would make the cluster capacity x2 or x3 vs uberjars all over the > place) Â this would be a real disruption. To it sounds like a big ball of mud to me, but that is opinion ;-) > > Think about being able to call Pharo from JNA > https://github.com/java-native-access/jna the same way we use C with UFFI. > > Smalltalk argument for me is that it makes development bearable (even > fun and enjoyable would I say) vs the other stacks. That matters. > Yep. As long as there is no mobile, web or big data involved ;-) To me that is not enough for convincing project managers these days, because web, mobile and big data as well ass AI (oh, is that probably no. 4 on our list of missed boats?) are the topics of what we consider future-proof projects... I am not only dissing the Pharo community here, this is a problem for all Smalltalk vendors in my opinion. Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim TuchelÂ Â Â Â Â mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 LudwigsburgÂ Â Â Â Â Â Â Â Â http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1 Â

Nov. 6, 2017

Re: [Pharo-users] Smalltalk Argument

by Hans N Beck

Hi Dimitris, you have pointed out some good thoughts. However, for me any technical thing can have two aspects: - solve a problem, provide a product which has value (for get things done) - take the concepts (of applied technics and computer science forward) For me, both things are important. Experience from doing gives new impulses for better concepts, better concepts may help to solve unsolvable problems. I like your example of libraries. Yes, I think too reinventing everything is not necessary. But I believe libraries as âliveâ objects providing protocol and capabilities would be an important improvement. For me, Morphic in itâs essence could be great for the AR world to come. So in principle I agree with you, but I hope that we not stop to search also for better concepts in a world, where privacy and self will is called in the age of big data and AI. Just my personal view ð Cheers Hans > Am 06.11.2017 um 11:28 schrieb Dimitris Chloupis <kilon.alios(a)gmail.com>: > > all people like popular choices, including engineers. > > Engineers may be more careful but they are not known exactly for their talent to innovate. > > We are pact animals, we are social animals. > > This is far from a coding problem, its pretty much coded right inside our DNA, not just for us but also for any other animal. > > And we have our trends too, our resistance to git is an excellent example. A general fixation of avoiding files and especially text files. The unreasonable argument that you need an image to preserve a live coding enviroment. The idea that just because you have access to the complete source code , life becomes easier for some weird way as if people are likely to mess with the internals of a system. That for some weird reason you cannot have access to source code in other languages or that is hard to do so. The notion that live coding is only possible or only easy in Smalltalk. That reimplementing everything in Smalltalk is a great idea. That minimal syntax equals softer learning curve. That Smalltalk is the only sensible way of doing OOP. > > Finally but not least, "Alan Kay is god". > > People love to stick to their beliefs (me included) and not feel comfortable questioning them. It's no surpise it tooks us hundrends of thousands of years to get to this point. > > JS is chosen as a language for the same reason its so hated, its third party libraries. As coders we have to rely a lot more to libraries than we have to rely on languages. Sure a language can solve many potential problem but a powerful library support can practically give you code on a plate. Hence also why JS is practically non existant outside web dev and that is pretty rare for a language. > > So sure popularity plays a major role but in the end the preference for JS is not insanity, its the right choice for what it focuses on. A difficult/ not that well designed language + big library support will always be easier to use than a super ease elegant language without such big library support. The time when we were relying on our code and our own libraries has passed long time ago. > > > >> On Mon, Nov 6, 2017 at 10:37 AM Andrew Glynn <aglynn42(a)gmail.com> wrote: >> Btw, I think we gained pace when JS took over the front end, but lost visibility. Nothing is slower than coding a client/server app with the front end in JS. The âriseâ of JS is a side effect of the fact that the web was designed, built and continues to be built by âcodersâ who donât know enough to be called amateurs. >> >> >> >> What puts 'codersâ off though is related to way JS is and (mostly doesnât) work. You canât just sit down and âhack onâ Smalltalk until it âsorta kindaâ does what you want. You canât grab code from some random website and âfiddle with itâ until it âsorta kindaâ works. âCodersâ canât make it âsorta kindaâ work, and they donât know how to write code that works. >> >> >> >> One of the better JS programmers Iâve worked with said at one point âEngineers canât write JavaScript because it doesnât fit their mentality. I used to be a retoucher, Iâd spend hours and hours getting one pixel right. Thereâs no good reason that one pixel had to be that way, but the image didnât âgoâ otherwise. JavaScript is like that, you spend hours and hours messing with it, getting it to work, and at the end you donât know why it works, nor why it didnât. Thatâs not an engineerâs mindset.â >> >> >> >> Do aviation engineers choose tools based on âpopularityâ? At the same time, would you want your next flight to be on an aircraft running on JavaScript? I wouldnât eat from a microwave running JavaScript. >> >> >> >> Iâd rather be an engineer than a popularity contestant or a fashion victim. >> >> >> >> In any case, more often than not itâs management that chooses technologies, generally based on who they have lunch with more than anything else. >> >> >> >> Andrew >> >> >> >> Sent from Mail for Windows 10 >> >> >> >> From: Dimitris Chloupis >> Sent: Monday, November 6, 2017 2:35 AM >> >> >> To: Any question about pharo is welcome >> Subject: Re: [Pharo-users] Smalltalk Argument >> >> >> >> Another way of promoting Pharo is copying its advantages to other languages. The ideal way is for people to get straight to Pharo and fall in love with it. But sometimes this may be possible for several reasons. The most usual being that people simple are not in the mood of learning a new language unless they have to. As the saying goes "People love progress , its just that they equally hate change" >> >> >> >> Introducing similar features to another language, like I did with introducing live coding enviroment to Python with direct reference back to Pharo is a very good way to promote the language. Just because you cannot code in Pharo at your work does not mean you cannot code the Pharo way. Just put a huge tag in your documentation, comments and anywhere you mention your code "inspired by Pharo ( https://pharo.org)" and you will get their attention whether they like the idea of learning a new language or not. >> >> >> >> Its like watching an ad, using sex, humour and even unrelated stuff to grab your attention to a product. The idea here is to get the attention, once you do that, the rest follows. >> >> >> >> A huge problem with Smalltalk in general is that even though every language, enviroment, tool, IDE has been copying it , it is rarely mentioned. If it did , I have no doubt it would have been masively more popular than it is right now. >> >> >> >> On Mon, Nov 6, 2017 at 9:22 AM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >> >> >> Phil, >> >> Am 26.10.17 um 08:17 schrieb phil(a)highoctane.be: >> > >> > >> > Now we miss the boat on mobile and bigdata, but this is solvable. >> >> You know, "It's solvable, and it's even easy in Smalltalk" has been what >> we've been shouting down at those worms in the C++/Java swamp for >> decades. We just never really proved it. We also missed the boat on web. >> Seaside was the last real innovation in that field, almost 15 years ago. >> When Javascript took over the frontend, we lost pace. >> >> > >> > If we had an open Java bridge (and some people in the community have >> > it for Pharo but do not open source it - so this is eminently doable) >> > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big >> > executable we would have a way to embed Pharo in a lot of places (e.g. >> > in the Hadoop ecosystem where fast starting VMs and small footprint >> > would make the cluster capacity x2 or x3 vs uberjars all over the >> > place) this would be a real disruption. >> >> To it sounds like a big ball of mud to me, but that is opinion ;-) >> >> > >> > Think about being able to call Pharo from JNA >> > https://github.com/java-native-access/jna the same way we use C with UFFI. >> > >> > Smalltalk argument for me is that it makes development bearable (even >> > fun and enjoyable would I say) vs the other stacks. That matters. >> > >> Yep. As long as there is no mobile, web or big data involved ;-) To me >> that is not enough for convincing project managers these days, because >> web, mobile and big data as well ass AI (oh, is that probably no. 4 on >> our list of missed boats?) are the topics of what we consider >> future-proof projects... I am not only dissing the Pharo community here, >> this is a problem for all Smalltalk vendors in my opinion. >> >> >> Joachim >> >> >> >> -- >> ----------------------------------------------------------------------- >> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 >> >> >>

Nov. 6, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

all people like popular choices, including engineers. Engineers may be more careful but they are not known exactly for their talent to innovate. We are pact animals, we are social animals. This is far from a coding problem, its pretty much coded right inside our DNA, not just for us but also for any other animal. And we have our trends too, our resistance to git is an excellent example. A general fixation of avoiding files and especially text files. The unreasonable argument that you need an image to preserve a live coding enviroment. The idea that just because you have access to the complete source code , life becomes easier for some weird way as if people are likely to mess with the internals of a system. That for some weird reason you cannot have access to source code in other languages or that is hard to do so. The notion that live coding is only possible or only easy in Smalltalk. That reimplementing everything in Smalltalk is a great idea. That minimal syntax equals softer learning curve. That Smalltalk is the only sensible way of doing OOP. Finally but not least, "Alan Kay is god". People love to stick to their beliefs (me included) and not feel comfortable questioning them. It's no surpise it tooks us hundrends of thousands of years to get to this point. JS is chosen as a language for the same reason its so hated, its third party libraries. As coders we have to rely a lot more to libraries than we have to rely on languages. Sure a language can solve many potential problem but a powerful library support can practically give you code on a plate. Hence also why JS is practically non existant outside web dev and that is pretty rare for a language. So sure popularity plays a major role but in the end the preference for JS is not insanity, its the right choice for what it focuses on. A difficult/ not that well designed language + big library support will always be easier to use than a super ease elegant language without such big library support. The time when we were relying on our code and our own libraries has passed long time ago. On Mon, Nov 6, 2017 at 10:37 AM Andrew Glynn <aglynn42(a)gmail.com> wrote: > Btw, I think we gained *pace* when JS took over the front end, but lost > visibility. Nothing is slower than coding a client/server app with the > front end in JS. The âriseâ of JS is a side effect of the fact that the web > was designed, built and continues to be built by âcodersâ who donât know > enough to be called amateurs. > > > > What puts 'codersâ off though is related to way JS is and (mostly doesnât) > work. You canât just sit down and âhack onâ Smalltalk until it âsorta > kindaâ does what you want. You canât grab code from some random website > and âfiddle with itâ until it âsorta kindaâ works. âCodersâ *canât* make > it âsorta kindaâ work, and they donât know how to *write* code that works. > > > > One of the better JS programmers Iâve worked with said at one point > âEngineers canât write JavaScript because it doesnât fit their mentality. > I used to be a retoucher, Iâd spend hours and hours getting one pixel > right. Thereâs no good reason that one pixel had to be that way, but the > image didnât âgoâ otherwise. JavaScript is like that, you spend hours and > hours messing with it, getting it to work, and at the end you donât know > why it works, nor why it didnât. Thatâs not an engineerâs mindset.â > > > > Do aviation engineers choose tools based on âpopularityâ? At the same > time, would you want your next flight to be on an aircraft running on > JavaScript? I wouldnât eat from a microwave running JavaScript. > > > > Iâd rather be an engineer than a popularity contestant or a fashion victim. > > > > In any case, more often than not itâs management that chooses > technologies, generally based on who they have lunch with more than > anything else. > > > > Andrew > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *Dimitris Chloupis <kilon.alios(a)gmail.com> > *Sent: *Monday, November 6, 2017 2:35 AM > > > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > Another way of promoting Pharo is copying its advantages to other > languages. The ideal way is for people to get straight to Pharo and fall in > love with it. But sometimes this may be possible for several reasons. The > most usual being that people simple are not in the mood of learning a new > language unless they have to. As the saying goes "People love progress , > its just that they equally hate change" > > > > Introducing similar features to another language, like I did with > introducing live coding enviroment to Python with direct reference back to > Pharo is a very good way to promote the language. Just because you cannot > code in Pharo at your work does not mean you cannot code the Pharo way. > Just put a huge tag in your documentation, comments and anywhere you > mention your code "inspired by Pharo ( https://pharo.org)" and you will > get their attention whether they like the idea of learning a new language > or not. > > > > Its like watching an ad, using sex, humour and even unrelated stuff to > grab your attention to a product. The idea here is to get the attention, > once you do that, the rest follows. > > > > A huge problem with Smalltalk in general is that even though every > language, enviroment, tool, IDE has been copying it , it is rarely > mentioned. If it did , I have no doubt it would have been masively more > popular than it is right now. > > > > On Mon, Nov 6, 2017 at 9:22 AM jtuchel(a)objektfabrik.de < > jtuchel(a)objektfabrik.de> wrote: > > > Phil, > > Am 26.10.17 um 08:17 schrieb phil(a)highoctane.be: > > > > > > Now we miss the boat on mobile and bigdata, but this is solvable. > > You know, "It's solvable, and it's even easy in Smalltalk" has been what > we've been shouting down at those worms in the C++/Java swamp for > decades. We just never really proved it. We also missed the boat on web. > Seaside was the last real innovation in that field, almost 15 years ago. > When Javascript took over the frontend, we lost pace. > > > > > If we had an open Java bridge (and some people in the community have > > it for Pharo but do not open source it - so this is eminently doable) > > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big > > executable we would have a way to embed Pharo in a lot of places (e.g. > > in the Hadoop ecosystem where fast starting VMs and small footprint > > would make the cluster capacity x2 or x3 vs uberjars all over the > > place) this would be a real disruption. > > To it sounds like a big ball of mud to me, but that is opinion ;-) > > > > > Think about being able to call Pharo from JNA > > https://github.com/java-native-access/jna the same way we use C with > UFFI. > > > > Smalltalk argument for me is that it makes development bearable (even > > fun and enjoyable would I say) vs the other stacks. That matters. > > > Yep. As long as there is no mobile, web or big data involved ;-) To me > that is not enough for convincing project managers these days, because > web, mobile and big data as well ass AI (oh, is that probably no. 4 on > our list of missed boats?) are the topics of what we consider > future-proof projects... I am not only dissing the Pharo community here, > this is a problem for all Smalltalk vendors in my opinion. > > > Joachim > > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Nov. 6, 2017

Re: [Pharo-users] perspective request for those earning a living fromSmalltalk

by Davorin Rusevljan

On Sat, Oct 28, 2017 at 7:59 PM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Your history is accurate, but thereâs a few things Iâd like to add, due > to having been employed by IBM at exactly that period working specifically > on VisualAge, not only for Smalltalk, but for Java, C++ and Cobol as well. > (my NDAâs finally having expired also helps ð). Itâs not a correction > or contradiction, but a complement to your description, providing a > relevant but different perspective. > > Andrew, please find a way to write an article or blog post on this subject. It is priceless. davorin

Nov. 6, 2017

Re: [Pharo-users] perspective request for those earning a livingfromSmalltalk

by Marten Feldtmann

Am 06.11.2017 um 09:36 schrieb Andrew Glynn: > They did just release 5.0 in June, lol. > VisualAge Smalltalk 6.01 for OS/2 is still running without any problems ... Marten -- Marten Feldtmann

Nov. 6, 2017

Re: [Pharo-users] perspective request for those earning a livingfromSmalltalk

by Andrew Glynn

They did just release 5.0 in June, lol. Sent from Mail for Windows 10 From: jtuchel(a)objektfabrik.de Sent: Monday, November 6, 2017 2:46 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] perspective request for those earning a livingfromSmalltalk A tiny example why OS/2 was great: You could have two printer instances on your desktop for colour printers: one for a b/w printing and one for Colour printing. You could even have another one for printing from tray 1,2, or duplex. You still can't do that in Windows these days (about 20 years later) and even on a Mac it is complicated and hard to handle. Great does not necessarily mean great money. So things get abandoned no matter how great they are ;-) Joachim Am 28.10.17 um 20:11 schrieb Richard Sargent: Thank you , Andrew, for that back-story! I really liked OS/2 and was extremely reluctant to give it up; it had a really good design. On Sat, Oct 28, 2017 at 10:59 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: Your history is accurate, but thereâs a few things IâdÂ like to add, due to having been employed by IBM at exactly that period working specifically on VisualAge, not only for Smalltalk, but for Java, C++ and Cobol as well.Â (my NDAâs finally having expired also helps ð).Â Itâs not a correction or contradiction, but a complement to your description, providing a relevant but different perspective. Â IBM did tell some Â of their customers to move to Java, but that was partly based on the existence of VisualAge for Java, which in some ways went beyond VA Smalltalk, in others not as far, but did make migration to Java easier, and in some cases possible at all.Â Its replacement, Eclipse, simply doesnât.Â And it could do so, because as with all VisualAge products, it was written in Smalltalk.Â One of the things that annoys me about the whole thing the most is that the biggest complaint, which was a partial but significant reason it wasnât more popular, was from developers who âcouldnât see their filesâ, i.e. couldnât edit them in vi(le) and build on the command line.Â I heard that complaint on a project using both the Java and C++ versions so many times I finally responded ânobody gives a shit about your f*cking filesâ, in the middle of the office at Pratt & Whitney Aerospace, lol. Â Since VA for Java (and VA C++) are now abandonware, itâs an example of what I meant by owning a market, failing to promote it, and thereby destroying it, and also the reason I referred to IBM specifically as being âvery good at it' Â Â I was involved in writing a major application in both Java and C++ using CORBA in 2000-2002, and on that we also used both VA C++ and VA Java.Â Otherwise, quite honestly, we may not have finished it despite having some brilliant people on the team, since doing CORBA manually, especially with object trees that use C++ multiple inheritance, can be near impossible to get working reliably.Â Â Unfortunately, due to being abandoned, the core of the app is no longer even buildable with current tools.Â If you look at the binary jars in the latest release (2016) the dates on them are still mid-2002.Â The most surprising thing to me is that they still run at all, particularly with Java 8 on current platforms (mainly Solaris 11 and Windows 10), considering they were written and built on Java 1.3.1, and although they targeted Windows and Solaris/AIX, were in fact written on OS/2 v. 4, because Solaris didnât run at the time on any laptop, and Windows 2000 loaded on a high spec laptop for the time but couldnât really be judged to be running, i.e. it loaded and proceeded to thrash to the degree that nothing further got accomplished. Â VA Smalltalk as itâs publicly available (at the not insignificant cost of ~$8500+ per license), is written on a base IBM Smalltalk thatâs ~26 years old.Â Instantiations has improved some things, but the core is vastly out of date.Â Meanwhile, IBM themselves have a fully current version (the last version I saw, when visiting a former colleague at the lab, was released early last year, but is only available internally.Â This wasnât one of the four I referred to in my other post, but nearly qualifies as âpublicly unavailableâ, since the available version is not nearly the same.Â Â VA is also very out of date in comparison with VW, Pharo, F-Script and Squeak, not only in comparison with the internal version.Â In particular the UI doesnât fully incorporate the improvements made (largely via the Announcer) in Morphic and the other current Smalltalk GUIâs.Â Like Swing and SWT, part of those improvements are there, but that in many ways only makes things worse.Â That WindowBuilder (available free for Java in Eclipse, but not for free in VA Smalltalk) is in fact a simple port of the original Smalltalk version is demonstration enough that the UI is not significantly different than the UI in Eclipse itself, or in Swing, since Swing is also supported by WindowBuilder. Â As an example of the remaining problems, I recently reverse engineered a complex legacy database via the Eclipse Dali JPA tools in order to make it available to BIRT / Talend for reporting.Â On an i7 with the DB on an SSD, it took over 950 CPU hours to complete.Â As of today, it has been in process of exiting for another 140 CPU hours, trying to catch up with the events triggered by Dali. Â Perhaps that helps understand why Iâm not thrilled with even some of the better libraries in many other environments. Â Outside Smalltalk and languages with IDEâs written in it.Â Â OS/2 is a great example of owning a market, then destroying it by not promoting it.Â OS/2 never owned the mainstream market of course, but what it did largely own was the smaller but sometimes crucial market for PC based systems that could run complex software reliably. Despite having âkilledâ OS/2 13 years ago, version 5.0 came out in June, released by a âcompanyâ of former IBM people financed by IBM, whose company name means ânew boxâ.Â Â The reason IBM canât completely kill it is that companies who canât move software off it, because every attempt to do so (to either Windows Server or different forms of *nix) has failed, in some cases over a dozen times, include such small entities as Boeing, MIT, NASA, the US government, including all four branches of the military, all of the worldâs airlines, GE, Rolls Royce, Pratt & Whitney, GM, Siemens, AT&T, and Citibank, just to name a few I know of (and none are exactly publicizing the fact).Â Despite the existence, today, of both Linux and Solaris on x86, and the improvements between Windows NT in the 1990âs and Windows Server today, institutions with fairly capable developers, such as MIT and Bell Labs, just to name two, canât port software they simultaneously canât be without, to any of those platforms.Â There is a specific technology in OS/2 not available elsewhere that is the main culprit, the Distributed System Object Model.Â Somewhat ironically though, one of the main uses of SOM/DSOM is to provide the type of live object manipulation and debugging to the core environment (and in a distributed manner) common in dialects of Smalltalk but virtually unknown otherwise. Â The person I learned Java RMI, JINI and J2EE architecture from was, by happenstance, the same person who architected OS/2.Â A somewhat humorous story is that IBM dropped out of a project begun with Sun in the late 1990âs to write a pure JavaOS.Â IBMâs reason for dropping out was embarrassment at the fact that pure Java apps ran faster on OS/2 than on the pure JavaOS.Â Sun couldnât at the time afford to complete it on their own so it disappeared, as unreleased products do, without even the marginal trace of existing on abandonware sites.Â That person was also, unsurprisingly, one of the key developers of IBM Smalltalk. Â Iâm not claiming that IBM or anyone else does such things in a completely aware way.Â Rather, the fact that efficient environments are difficult to build without significant time and resources (both are necessary because no matter how many resources are available, rushing the development will result in mistakes that have to be fixed later, giving the environment an unstable base to build on), combined with the advantage industry inefficiencies provide to the companies with those resources, makes the situation relatively easy to reinforce without really needing to admit what youâre doing, particularly to yourself. Â Andrew Â Â Sent from Mail for Windows 10 Â From: jtuchel(a)objektfabrik.de Sent: Monday, October 23, 2017 3:32 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] perspective request for those earning a living fromSmalltalk Â Petr, Â I've been working as a Consultant for many big corporations (mainly in VA Smalltalk) since 1996. The situation you describe is very well known to me. But in my opinion there is no technical reason for this. It's a managerial problem. Ever since IBM went out to their customers and told them to move to Java for the better ini the mid-90ies, managers wanted the Smalltalk projects to go away as fast as possible. Nobody asked why IBM was still happily using VisualAge Smalltalk internally at that time frame.... Â So the Smalltalk projects were declared legacy by Management. Replacement projects were started with big efforts and optimism. Some went well, some somewhat came to fly in a bit more than double the time and much more times the costthan planned, some failed miserably. One thing was in common to the replacement projects all over the place: they took much longer, turned out to be much mor complicated and took a lot more manpower than anybody had ever imagined. Â So two important things happened: Â 1) People were told the old Smalltalk stuff would be gone soon, so if you wanted to be a valued and appreciated staff member, you better stay away from these projects 2) The people who knew the business and technical side of the existing projects were moved to the new projects. Some liked it (because of 1) some were frustrated (because they knew / feared the new project was going to be a death march) Â Â Over the first 2 years or so, nobody realized how bad the situation really was. It was easy to postpone user requirements to the new project, accumulate more and more manpower in the new project and still keep up green flags everywhere. Â ...until yellow was the new green and users/stakeholders wanted the new features NOW - and not one day when the replacement project would become real. Â So the remaining manpower in the old project (not the ones with lots of experience and knowledge) had to extend the old system, integrate it with the new system (thereby implementing all the stuff that IBM once told their management would never be possible in Smalltalk) and keep it up and ranning year after year. Nobody ever said Thank You or would appreciate the work they did. Because that was old stuff anyways and was already irrelevant. Â Â Some of these old systems still exist today, serving users every single day, while some of the new systems never appeared. No manpower was ever added to these projects, and never would anybody ever say: okay, guys, you won. They still work on legacy code and try to do their best to fulfill user requirements. While on other projects that never see the light of day, people get appreciation, are allowed to work with new technologies and do cool stuff. Nobody ever asked the Smalltalkers whether they could do that as well, because "if you want to do web, you need to do Java". IBM said so, you know (and many other consultants as well). Â So this is why new people try to stay away from these old projects. This is why the remaining staff is frustrated and this is why nobody allows them to do the cool things that Smalltalk can do as well as the others. They are just required to fix bugs, add new features in the old GUIs and else keep silent. Some of them were trying to fight this and tried to prove Smalltalk's strengths, but back then nobody would listen. One day they gave up. Â Â Management still frustrates people every. single. day. Â Â Just my opinion Â Â Joachim Â Â Â Â Am 22.10.17 um 18:56 schrieb Petr Fischer: > Here. (But from one point of view, it's a litte misery, 10-20 year old code sometimes, a mess, old VAST, absolutely no interest from young colleagues with no experience to willingly learn something about Smalltalk etc etc.). >Â > If I bring up enough arguments, we will use Gemstone+Pharo tools in the future, which is a dream for me... but, we will see... >Â > pf >Â >> At https://news.ycombinator.com/item?id=15523807 >> the question is asked... "Does anyone on here program in Smalltalk >> professionally? Not to get off topic, but I'm curious and would like to >> know how it stacks up compared to what they did previously? " >>Â >> If you've earning a living from programming Smalltalk, please drop a >> comment there. >>Â >> cheers -ben >Â Â -- ----------------------------------------------------------------------- Objektfabrik Joachim TuchelÂ Â Â Â Â Â Â Â Â mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 LudwigsburgÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1 Â Â Â -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Nov. 6, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Btw, I think we gained pace when JS took over the front end, but lost visibility. Nothing is slower than coding a client/server app with the front end in JS. The âriseâ of JS is a side effect of the fact that the web was designed, built and continues to be built by âcodersâ who donât know enough to be called amateurs. What puts 'codersâ off though is related to way JS is and (mostly doesnât) work. You canât just sit down and âhack onâ Smalltalk until it âsorta kindaâ does what you want. You canât grab code from some random website and âfiddle with itâ until it âsorta kindaâ works. âCodersâ canât make it âsorta kindaâ work, and they donât know how to write code that works. One of the better JS programmers Iâve worked with said at one point âEngineers canât write JavaScript because it doesnât fit their mentality. I used to be a retoucher, Iâd spend hours and hours getting one pixel right. Thereâs no good reason that one pixel had to be that way, but the image didnât âgoâ otherwise. JavaScript is like that, you spend hours and hours messing with it, getting it to work, and at the end you donât know why it works, nor why it didnât. Thatâs not an engineerâs mindset.â Do aviation engineers choose tools based on âpopularityâ? At the same time, would you want your next flight to be on an aircraft running on JavaScript? I wouldnât eat from a microwave running JavaScript. Iâd rather be an engineer than a popularity contestant or a fashion victim. In any case, more often than not itâs management that chooses technologies, generally based on who they have lunch with more than anything else. Andrew Sent from Mail for Windows 10 From: Dimitris Chloupis Sent: Monday, November 6, 2017 2:35 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Another way of promoting Pharo is copying its advantages to other languages. The ideal way is for people to get straight to Pharo and fall in love with it. But sometimes this may be possible for several reasons. The most usual being that people simple are not in the mood of learning a new language unless they have to. As the saying goes "People love progress , its just that they equally hate change" Introducing similar features to another language, like I did with introducing live coding enviroment to Python with direct reference back to Pharo is a very good way to promote the language. Just because you cannot code in Pharo at your work does not mean you cannot code the Pharo way. Just put a huge tag in your documentation, comments and anywhere you mention your code "inspired by Pharo ( https://pharo.org)" and you will get their attention whether they like the idea of learning a new language or not.Â Its like watching an ad, using sex, humour and even unrelated stuff to grab your attention to a product. The idea here is to get the attention, once you do that, the rest follows.Â A huge problem with Smalltalk in general is that even though every language, enviroment, tool, IDE has been copying it , it is rarely mentioned. If it did , I have no doubt it would have been masively more popular than it is right now.Â On Mon, Nov 6, 2017 at 9:22 AM jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: Phil, Am 26.10.17 um 08:17 schrieb phil(a)highoctane.be: > > > Now we miss the boat on mobile and bigdata, but this is solvable. You know, "It's solvable, and it's even easy in Smalltalk" has been what we've been shouting down at those worms in the C++/Java swamp for decades. We just never really proved it. We also missed the boat on web. Seaside was the last real innovation in that field, almost 15 years ago. When Javascript took over the frontend, we lost pace. > > If we had an open Java bridge (and some people in the community have > it for Pharo but do not open source it - so this is eminently doable) > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big > executable we would have a way to embed Pharo in a lot of places (e.g. > in the Hadoop ecosystem where fast starting VMs and small footprint > would make the cluster capacity x2 or x3 vs uberjars all over the > place) Â this would be a real disruption. To it sounds like a big ball of mud to me, but that is opinion ;-) > > Think about being able to call Pharo from JNA > https://github.com/java-native-access/jna the same way we use C with UFFI. > > Smalltalk argument for me is that it makes development bearable (even > fun and enjoyable would I say) vs the other stacks. That matters. > Yep. As long as there is no mobile, web or big data involved ;-) To me that is not enough for convincing project managers these days, because web, mobile and big data as well ass AI (oh, is that probably no. 4 on our list of missed boats?) are the topics of what we consider future-proof projects... I am not only dissing the Pharo community here, this is a problem for all Smalltalk vendors in my opinion. Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim TuchelÂ Â Â Â Â mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 LudwigsburgÂ Â Â Â Â Â Â Â Â http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Nov. 6, 2017

Re: [Pharo-users] perspective request for those earning a living fromSmalltalk

by jtuchel＠objektfabrik.de

A tiny example why OS/2 was great: You could have two printer instances on your desktop for colour printers: one for a b/w printing and one for Colour printing. You could even have another one for printing from tray 1,2, or duplex. You still can't do that in Windows these days (about 20 years later) and even on a Mac it is complicated and hard to handle. Great does not necessarily mean great money. So things get abandoned no matter how great they are ;-) Joachim Am 28.10.17 um 20:11 schrieb Richard Sargent: > Thank you , Andrew, for that back-story! > I really liked OS/2 and was extremely reluctant to give it up; it had > a really good design. > > On Sat, Oct 28, 2017 at 10:59 AM, Andrew Glynn <aglynn42(a)gmail.com > <mailto:aglynn42@gmail.com>> wrote: > > Your history is accurate, but thereâs a few things IâdÂ like to > add, due to having been employed by IBM at exactly that period > working specifically on VisualAge, not only for Smalltalk, but for > Java, C++ and Cobol as well.Â (my NDAâs finally having expired > also helps ð).Â Itâs not a correction or contradiction, but a > complement to your description, providing a relevant but different > perspective. > > IBM /did/ tell some//Â of their customers to move to Java, but that > was partly based on the existence of VisualAge for Java, which in > some ways went beyond VA Smalltalk, in others not as far, but did > make migration to Java easier, and in some cases possible at all.Â > Its replacement, Eclipse, simply doesnât.Â And it could do so, > because as with all VisualAge products, it was written in > Smalltalk. One of the things that annoys me about the whole thing > the most is that the biggest complaint, which was a partial but > significant reason it wasnât more popular, was from developers who > âcouldnât see their filesâ, i.e. couldnât edit them in vi(le) and > build on the command line.Â I heard that complaint on a project > using both the Java and C++ versions so many times I finally > responded ânobody gives a shit about your f*cking filesâ, in the > middle of the office at Pratt & Whitney Aerospace, lol. > > Since VA for Java (and VA C++) are now abandonware, itâs an > example of what I meant by owning a market, failing to promote it, > and thereby destroying it, and also the reason I referred to IBM > specifically as being âvery good at it' > > I was involved in writing a major application in both Java and C++ > using CORBA in 2000-2002, and on that we also used both VA C++ and > VA Java.Â Otherwise, quite honestly, we may not have finished it > despite having some brilliant people on the team, since doing > CORBA manually, especially with object trees that use C++ multiple > inheritance, can be near impossible to get working reliably. > > Unfortunately, due to being abandoned, the core of the app is no > longer even buildable with current tools.Â If you look at the > binary jars in the latest release (2016) the dates on them are > still mid-2002.Â The most surprising thing to me is that they > still run at all, particularly with Java 8 on current platforms > (mainly Solaris 11 and Windows 10), considering they were written > and built on Java 1.3.1, and although they targeted Windows and > Solaris/AIX, were in fact written on OS/2 v. 4, because Solaris > didnât run at the time on any laptop, and Windows 2000 /loaded/ on > a high spec laptop for the time but couldnât really be judged to > be /running/, i.e. it loaded and proceeded to thrash to the degree > that nothing further got accomplished. > > VA Smalltalk as itâs publicly available (at the not insignificant > cost of ~$8500+ per license), is written on a base IBM Smalltalk > thatâs ~26 years old.Â Instantiations has improved some things, > but the core is vastly out of date. Meanwhile, IBM themselves have > a fully current version (the last version I saw, when visiting a > former colleague at the lab, was released early last year, but is > only available internally.Â This wasnât one of the four I referred > to in my other post, but nearly qualifies as âpublicly > unavailableâ, since the available version is not nearly the same. > > VA is also very out of date in comparison with VW, Pharo, F-Script > and Squeak, not only in comparison with the internal version.Â In > particular the UI doesnât fully incorporate the improvements made > (largely via the Announcer) in Morphic and the other current > Smalltalk GUIâs.Â Like Swing and SWT, part of those improvements > are there, but that in many ways only makes things worse.Â That > WindowBuilder (available free for Java in Eclipse, but not for > free in VA Smalltalk) is in fact a simple port of the original > Smalltalk version is demonstration enough that the UI is not > significantly different than the UI in Eclipse itself, or in > Swing, since Swing is also supported by WindowBuilder. > > As an example of the remaining problems, I recently reverse > engineered a complex legacy database via the Eclipse Dali JPA > tools in order to make it available to BIRT / Talend for > reporting.Â On an i7 with the DB on an SSD, it took over 950 CPU > hours to complete.Â As of today, it has been in process of exiting > for another 140 CPU hours, trying to catch up with the events > triggered by Dali. > > Perhaps that helps understand why Iâm not thrilled with even some > of the better libraries in many other environments. > > Outside Smalltalk and languages with IDEâs written in it.Â Â OS/2 > is a great example of owning a market, then destroying it by not > promoting it.Â OS/2 never owned the mainstream market of course, > but what it did largely own was the smaller but sometimes crucial > market for PC based systems that could run complex software > reliably. Despite having âkilledâ OS/2 13 years ago, version 5.0 > came out in June, released by a âcompanyâ of former IBM people > financed by IBM, whose company name means ânew boxâ. > > The reason IBM canât completely kill it is that companies who > canât move software off it, because every attempt to do so (to > either Windows Server or different forms of *nix) has failed, in > some cases over a dozen times, include such small entities as > Boeing, MIT, NASA, the US government, including all four branches > of the military, all of the worldâs airlines, GE, Rolls Royce, > Pratt & Whitney, GM, Siemens, AT&T, and Citibank, just to name a > few I know of (and none are exactly publicizing the fact). Despite > the existence, today, of both Linux and Solaris on x86, and the > improvements between Windows NT in the 1990âs and Windows Server > today, institutions with fairly capable developers, such as MIT > and Bell Labs, just to name two, canât port software they > simultaneously canât be without, to any of those platforms.Â There > /is/ a specific technology in OS/2 not available elsewhere that is > the main culprit, the Distributed System Object Model. Somewhat > ironically though, one of the main uses of SOM/DSOM is to provide > the type of live object manipulation and debugging to the core > environment (and in a distributed manner) common in dialects of > Smalltalk but virtually unknown otherwise. > > The person I learned Java RMI, JINI and J2EE architecture from > was, by happenstance, the same person who architected OS/2.Â A > somewhat humorous story is that IBM dropped out of a project begun > with Sun in the late 1990âs to write a pure JavaOS.Â IBMâs reason > for dropping out was embarrassment at the fact that pure Java apps > ran faster on OS/2 than on the pure JavaOS.Â Sun couldnât at the > time afford to complete it on their own so it disappeared, as > unreleased products do, without even the marginal trace of > existing on abandonware sites.Â That person was also, > unsurprisingly, one of the key developers of IBM Smalltalk. > > Iâm not claiming that IBM or anyone else does such things in a > completely aware way. Rather, the fact that efficient environments > are difficult to build without significant time and resources > (both are necessary because no matter how many resources are > available, rushing the development will result in mistakes that > have to be fixed later, giving the environment an unstable base to > build on), combined with the advantage industry inefficiencies > provide to the companies /with/ those resources, makes the > situation relatively easy to reinforce /without /really needing to > admit what youâre doing, particularly to yourself. > > Andrew > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> > for Windows 10 > > *From: *jtuchel(a)objektfabrik.de <mailto:jtuchel@objektfabrik.de> > *Sent: *Monday, October 23, 2017 3:32 AM > *To: *Any question about pharo is welcome > <mailto:pharo-users@lists.pharo.org> > *Subject: *Re: [Pharo-users] perspective request for those earning > a living fromSmalltalk > > Petr, > > I've been working as a Consultant for many big corporations > (mainly in > > VA Smalltalk) since 1996. The situation you describe is very well > known > > to me. But in my opinion there is no technical reason for this. > It's a > > managerial problem. Ever since IBM went out to their customers and > told > > them to move to Java for the better ini the mid-90ies, managers > wanted > > the Smalltalk projects to go away as fast as possible. Nobody > asked why > > IBM was still happily using VisualAge Smalltalk internally at that > time > > frame.... > > So the Smalltalk projects were declared legacy by Management. > > Replacement projects were started with big efforts and optimism. Some > > went well, some somewhat came to fly in a bit more than double the > time > > and much more times the costthan planned, some failed miserably. One > > thing was in common to the replacement projects all over the > place: they > > took much longer, turned out to be much mor complicated and took a > lot > > more manpower than anybody had ever imagined. > > So two important things happened: > > 1) People were told the old Smalltalk stuff would be gone soon, so if > > you wanted to be a valued and appreciated staff member, you better > stay > > away from these projects > > 2) The people who knew the business and technical side of the > existing > > projects were moved to the new projects. Some liked it (because of 1) > > some were frustrated (because they knew / feared the new project was > > going to be a death march) > > Over the first 2 years or so, nobody realized how bad the situation > > really was. It was easy to postpone user requirements to the new > > project, accumulate more and more manpower in the new project and > still > > keep up green flags everywhere. > > ...until yellow was the new green and users/stakeholders wanted > the new > > features NOW - and not one day when the replacement project would > become > > real. > > So the remaining manpower in the old project (not the ones with > lots of > > experience and knowledge) had to extend the old system, integrate it > > with the new system (thereby implementing all the stuff that IBM once > > told their management would never be possible in Smalltalk) and > keep it > > up and ranning year after year. Nobody ever said Thank You or would > > appreciate the work they did. Because that was old stuff anyways > and was > > already irrelevant. > > Some of these old systems still exist today, serving users every > single > > day, while some of the new systems never appeared. No manpower was > ever > > added to these projects, and never would anybody ever say: okay, > guys, > > you won. They still work on legacy code and try to do their best to > > fulfill user requirements. While on other projects that never see the > > light of day, people get appreciation, are allowed to work with new > > technologies and do cool stuff. Nobody ever asked the Smalltalkers > > whether they could do that as well, because "if you want to do > web, you > > need to do Java". IBM said so, you know (and many other > consultants as > > well). > > So this is why new people try to stay away from these old > projects. This > > is why the remaining staff is frustrated and this is why nobody > allows > > them to do the cool things that Smalltalk can do as well as the > others. > > They are just required to fix bugs, add new features in the old > GUIs and > > else keep silent. Some of them were trying to fight this and tried to > > prove Smalltalk's strengths, but back then nobody would listen. > One day > > they gave up. > > Management still frustrates people every. single. day. > > Just my opinion > > Joachim > > Am 22.10.17 um 18:56 schrieb Petr Fischer: > > > Here. (But from one point of view, it's a litte misery, 10-20 > year old code sometimes, a mess, old VAST, absolutely no interest > from young colleagues with no experience to willingly learn > something about Smalltalk etc etc.). > > > > > > If I bring up enough arguments, we will use Gemstone+Pharo tools > in the future, which is a dream for me... but, we will see... > > > > > > pf > > > > > >> At https://news.ycombinator.com/item?id=15523807 > <https://news.ycombinator.com/item?id=15523807> > > >> the question is asked... "Does anyone on here program in Smalltalk > > >> professionally? Not to get off topic, but I'm curious and would > like to > > >> know how it stacks up compared to what they did previously? " > > >> > > >> If you've earning a living from programming Smalltalk, please > drop a > > >> comment there. > > >> > > >> cheers -ben > > > > > -- > > ----------------------------------------------------------------------- > > Objektfabrik Joachim TuchelÂ Â Â Â Â Â Â Â Â > mailto:jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> > > Fliederweg 1 http://www.objektfabrik.de > > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > <http://joachimtuchel.wordpress.com> > > Telefon: +49 7141 56 10 86 0 Â Fax: +49 7141 56 10 86 1 > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Nov. 6, 2017

Re: [Pharo-users] Smalltalk Argument

by Dimitris Chloupis

Another way of promoting Pharo is copying its advantages to other languages. The ideal way is for people to get straight to Pharo and fall in love with it. But sometimes this may be possible for several reasons. The most usual being that people simple are not in the mood of learning a new language unless they have to. As the saying goes "People love progress , its just that they equally hate change" Introducing similar features to another language, like I did with introducing live coding enviroment to Python with direct reference back to Pharo is a very good way to promote the language. Just because you cannot code in Pharo at your work does not mean you cannot code the Pharo way. Just put a huge tag in your documentation, comments and anywhere you mention your code "inspired by Pharo ( https://pharo.org)" and you will get their attention whether they like the idea of learning a new language or not. Its like watching an ad, using sex, humour and even unrelated stuff to grab your attention to a product. The idea here is to get the attention, once you do that, the rest follows. A huge problem with Smalltalk in general is that even though every language, enviroment, tool, IDE has been copying it , it is rarely mentioned. If it did , I have no doubt it would have been masively more popular than it is right now. On Mon, Nov 6, 2017 at 9:22 AM jtuchel(a)objektfabrik.de < jtuchel(a)objektfabrik.de> wrote: > > Phil, > > Am 26.10.17 um 08:17 schrieb phil(a)highoctane.be: > > > > > > Now we miss the boat on mobile and bigdata, but this is solvable. > > You know, "It's solvable, and it's even easy in Smalltalk" has been what > we've been shouting down at those worms in the C++/Java swamp for > decades. We just never really proved it. We also missed the boat on web. > Seaside was the last real innovation in that field, almost 15 years ago. > When Javascript took over the frontend, we lost pace. > > > > > If we had an open Java bridge (and some people in the community have > > it for Pharo but do not open source it - so this is eminently doable) > > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big > > executable we would have a way to embed Pharo in a lot of places (e.g. > > in the Hadoop ecosystem where fast starting VMs and small footprint > > would make the cluster capacity x2 or x3 vs uberjars all over the > > place) this would be a real disruption. > > To it sounds like a big ball of mud to me, but that is opinion ;-) > > > > > Think about being able to call Pharo from JNA > > https://github.com/java-native-access/jna the same way we use C with > UFFI. > > > > Smalltalk argument for me is that it makes development bearable (even > > fun and enjoyable would I say) vs the other stacks. That matters. > > > Yep. As long as there is no mobile, web or big data involved ;-) To me > that is not enough for convincing project managers these days, because > web, mobile and big data as well ass AI (oh, is that probably no. 4 on > our list of missed boats?) are the topics of what we consider > future-proof projects... I am not only dissing the Pharo community here, > this is a problem for all Smalltalk vendors in my opinion. > > > Joachim > > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > >

Nov. 6, 2017

Re: [Pharo-users] Smalltalk Argument

by jtuchel＠objektfabrik.de

Phil, Am 26.10.17 um 08:17 schrieb phil(a)highoctane.be: > > > Now we miss the boat on mobile and bigdata, but this is solvable. You know, "It's solvable, and it's even easy in Smalltalk" has been what we've been shouting down at those worms in the C++/Java swamp for decades. We just never really proved it. We also missed the boat on web. Seaside was the last real innovation in that field, almost 15 years ago. When Javascript took over the frontend, we lost pace. > > If we had an open Java bridge (and some people in the community have > it for Pharo but do not open source it - so this is eminently doable) > + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big > executable we would have a way to embed Pharo in a lot of places (e.g. > in the Hadoop ecosystem where fast starting VMs and small footprint > would make the cluster capacity x2 or x3 vs uberjars all over the > place) Â this would be a real disruption. To it sounds like a big ball of mud to me, but that is opinion ;-) > > Think about being able to call Pharo from JNA > https://github.com/java-native-access/jna the same way we use C with UFFI. > > Smalltalk argument for me is that it makes development bearable (even > fun and enjoyable would I say) vs the other stacks. That matters. > Yep. As long as there is no mobile, web or big data involved ;-) To me that is not enough for convincing project managers these days, because web, mobile and big data as well ass AI (oh, is that probably no. 4 on our list of missed boats?) are the topics of what we consider future-proof projects... I am not only dissing the Pharo community here, this is a problem for all Smalltalk vendors in my opinion. Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1Â Â Â Â Â Â Â Â Â Â Â Â Â http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0Â Â Â Â Â Fax: +49 7141 56 10 86 1

Nov. 6, 2017