October 2017 - Pharo-users - lists.pharo.org

[ANN] Grafoscopio is now also an indexed publication

by Offray Vladimir Luna CÃ¡rdenas

Hi, I would like to share with you the recent acceptation of Grafoscopio in the Journal of Open Source Software (JOSS), which makes it also an indexed publication. More details at: http://joss.theoj.org/papers/10.21105/joss.00251 I would like to thank Serge StinchwichÂ (from this community) and Arfon Smith (from JOSS) for reviewing the software and helping me with the publication process. Cheers, Offray === About JOSS (http://joss.theoj.org/about) "The Journal of Open Source Software (JOSS) is a *developer friendly* journal for research software packages. [...] The Journal of Open Source Software (JOSS) is an academic journal (ISSN 2475-9066) with a formal peer review process that is designed to /improve the quality of the software submitted/. Upon acceptance into JOSS, a CrossRef DOI is minted and we list your paper on the JOSS website." ===

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

Elastic search JSON integration would be another good one. I heard there was a Kafka integration, is that true? Where could I find that, I used to use Kafka. Kafka is a great event channel for input to BigData. Using Kafka, it is well in crafting a Lamda Architecture. Imagine Pharo where Storm resides. - HH On Fri, Oct 27, 2017 at 16:51, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. > > - HH > > On Fri, Oct 27, 2017 at 16:41, henry <[henry(a)callistohouse.club](""mailto:henry@callistohouse.club"")> wrote: > >> How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. >> >> Can Pharo be called as a shared library from Java JNA? >> >> - HH >> >> On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <[aglynn42(a)gmail.com](""mailto:aglynn42@gmail.com"")> wrote: >> >>> Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be. Does that cause issues? Of course. But Iâd rather deal with those than do things I donât enjoy. However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. >>> >>> Cheers >>> >>> Andrew >>> >>> Sent from [Mail](""https://go.microsoft.com/fwlink/?LinkId=550986"") for Windows 10 >>> >>> From: [jtuchel(a)objektfabrik.de](""mailto:jtuchel@objektfabrik.de"") >>> Sent: Thursday, October 26, 2017 8:14 AM >>> To: [pharo-users(a)lists.pharo.org](""mailto:pharo-users@lists.pharo.org"") >>> Subject: Re: [Pharo-users] Smalltalk Argument >>> >>> Andrew, >>> >>> Am 26.10.17 um 00:46 schrieb Andrew Glynn: >>> >>>> Thereâs other questions that are relevant to me: >>> >>> I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. >>> >>>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >>> >>> Some people canât. I canât. I am making my living with a web based application. And I like it. >>> >>>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say.> >>> >>> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. >>> >>> Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. >>> >>> I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. >>> >>> So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? >>> >>> Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) >>> >>> Joachim >>> >>>> >>>> >>>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>>> >>>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>>> >>>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>>> >>>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>>> >>>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>>> >>>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>>> >>>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>>> >>>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>>> >>>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>>> >>>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>>> >>>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>>> >>>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>>> >>>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>>> >>>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>>> >>>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>>> >>>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>>> >>>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>>> >>>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>>> >>>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>>> >>>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>>> >>>> From: Pharo-users [<pharo-users-bounces(a)lists.pharo.org>](""mailto:pharo-users-bounces@lists.pharo.org"") on behalf of David Mason [<dmason(a)ryerson.ca>](""mailto:dmason@ryerson.ca"") >>>> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](""mailto:pharo-users@lists.pharo.org"") >>>> Date: Tuesday, October 24, 2017 at 11:52 AM >>>> To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](""mailto:pharo-users@lists.pharo.org"") >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> >>>> PharoJS is working to give you that mobile app/browser app experience. As with others, weâre not there yet, but getting there. See [http://pharojs.org](""http://pharojs.org"") >>>> >>>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so itâs presumably a high percentage of a smallish number of people. >>>> >>>> On 20 October 2017 at 03:23, [jtuchel(a)objektfabrik.de](""mailto:jtuchel@objektfabrik.de"") <[jtuchel(a)objektfabrik.de](""mailto:jtuchel@objektfabrik.de"")> wrote: >>>> >>>>> First of all: Iâd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we donât want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer youâve heard the sentence "weâve taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>>> >>>>> A shortage of developers doesnât exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldnât care. Itâs that simple. As a consultant, Iâve heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. Itâs just a lie: the shortage of Smalltalk developers is not a problem. >>>>> >>>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>>> Can we build cool looking web apps in extremely short time? No. >>>>> Can we build mobile Apps with little effort? No. >>>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>>> >>>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment Iâve used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>>> >>>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>>> >>>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what weâve done so far wouldâve taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>>> >>>>> Smalltalk is cool, and the day somebody shows me something like Googleâs flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, Iâd say these arguments about productivity are just us trying to make ourselves believe weâre still the top of the food chain. Weâve done that for almost thirty years now and still arenât ready to stop it. But weâve been lying to ourselves and still do so. >>>>> >>>>> I donât think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you canât win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>>> >>>>> Okay, shoot ;-) >>>>> >>>>> Joachim >>>>> >>>>> â >>>>> ââââââââââââââââââââââââ >>>>> Objektfabrik Joachim Tuchel mailto:[jtuchel@objektfabrik.de](""mailto:jtuchel@objektfabrik.de"") >>>>> Fliederweg 1 [http://www.objektfabrik.de](""http://www.objektfabrik.de"") >>>>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com](""http://joachimtuchel.wordpress.com"") >>>>> Telefon: [+49 7141 56 10 86 0](""tel:%2B49%207141%2056%2010%2086%200"") Fax: [+49 7141 56 10 86 1](""tel:%2B49%207141%2056%2010%2086%201"") >>> >>> â >>> >>> ââââââââââââââââââââââââ >>> >>> Objektfabrik Joachim Tuchel >>> [mailto:jtuchel@objektfabrik.de](""mailto:jtuchel@objektfabrik.de"") >>> >>> Fliederweg 1 >>> [http://www.objektfabrik.de](""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

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment. - HH On Fri, Oct 27, 2017 at 16:41, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. > > Can Pharo be called as a shared library from Java JNA? > > - HH > > On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <[aglynn42(a)gmail.com]("mailto:aglynn42@gmail.com")> wrote: > >> Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be. Does that cause issues? Of course. But Iâd rather deal with those than do things I donât enjoy. However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. >> >> Cheers >> >> Andrew >> >> Sent from [Mail]("https://go.microsoft.com/fwlink/?LinkId=550986") for Windows 10 >> >> From: [jtuchel(a)objektfabrik.de]("mailto:jtuchel@objektfabrik.de") >> Sent: Thursday, October 26, 2017 8:14 AM >> To: [pharo-users(a)lists.pharo.org]("mailto:pharo-users@lists.pharo.org") >> Subject: Re: [Pharo-users] Smalltalk Argument >> >> Andrew, >> >> Am 26.10.17 um 00:46 schrieb Andrew Glynn: >> >>> Thereâs other questions that are relevant to me: >> >> I am glad you opened your words with this sentence. Other peoplesâ mileages may vary a lot. >> >>> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. >> >> Some people canât. I canât. I am making my living with a web based application. And I like it. >> >>> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say.> >> >> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. >> >> Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. >> >> I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. >> >> So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a managerâs point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? >> >> Your answer delivers a lot of food for thought, but I donât buy all of it. And I donât expect you to buy all of mine ;-) >> >> Joachim >> >>> >>> >>> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >>> >>> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >>> >>> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >>> >>> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >>> >>> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >>> >>> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >>> >>> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >>> >>> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >>> >>> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >>> >>> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >>> >>> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >>> >>> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >>> >>> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >>> >>> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >>> >>> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >>> >>> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >>> >>> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >>> >>> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >>> >>> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >>> >>> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >>> >>> From: Pharo-users [<pharo-users-bounces(a)lists.pharo.org>]("mailto:pharo-users-bounces@lists.pharo.org") on behalf of David Mason [<dmason(a)ryerson.ca>]("mailto:dmason@ryerson.ca") >>> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>]("mailto:pharo-users@lists.pharo.org") >>> Date: Tuesday, October 24, 2017 at 11:52 AM >>> To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>]("mailto:pharo-users@lists.pharo.org") >>> Subject: Re: [Pharo-users] Smalltalk Argument >>> >>> PharoJS is working to give you that mobile app/browser app experience. As with others, weâre not there yet, but getting there. See [http://pharojs.org]("http://pharojs.org") >>> >>> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so itâs presumably a high percentage of a smallish number of people. >>> >>> On 20 October 2017 at 03:23, [jtuchel(a)objektfabrik.de]("mailto:jtuchel@objektfabrik.de") <[jtuchel(a)objektfabrik.de]("mailto:jtuchel@objektfabrik.de")> wrote: >>> >>>> First of all: Iâd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we donât want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer youâve heard the sentence "weâve taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>>> >>>> A shortage of developers doesnât exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldnât care. Itâs that simple. As a consultant, Iâve heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. Itâs just a lie: the shortage of Smalltalk developers is not a problem. >>>> >>>> And, to be honest: what is it we actually are better in by using Smalltalk? >>>> Can we build cool looking web apps in extremely short time? No. >>>> Can we build mobile Apps with little effort? No. >>>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>>> >>>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment Iâve used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>>> >>>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>>> >>>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what weâve done so far wouldâve taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>>> >>>> Smalltalk is cool, and the day somebody shows me something like Googleâs flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, Iâd say these arguments about productivity are just us trying to make ourselves believe weâre still the top of the food chain. Weâve done that for almost thirty years now and still arenât ready to stop it. But weâve been lying to ourselves and still do so. >>>> >>>> I donât think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you canât win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>>> >>>> Okay, shoot ;-) >>>> >>>> Joachim >>>> >>>> â >>>> ââââââââââââââââââââââââ >>>> Objektfabrik Joachim Tuchel mailto:[jtuchel@objektfabrik.de]("mailto:jtuchel@objektfabrik.de") >>>> Fliederweg 1 [http://www.objektfabrik.de]("http://www.objektfabrik.de") >>>> D-71640 Ludwigsburg [http://joachimtuchel.wordpress.com]("http://joachimtuchel.wordpress.com") >>>> Telefon: [+49 7141 56 10 86 0]("tel:%2B49%207141%2056%2010%2086%200") Fax: [+49 7141 56 10 86 1]("tel:%2B49%207141%2056%2010%2086%201") >> >> â >> >> ââââââââââââââââââââââââ >> >> Objektfabrik Joachim Tuchel >> [mailto:jtuchel@objektfabrik.de]("mailto:jtuchel@objektfabrik.de") >> >> Fliederweg 1 >> [http://www.objektfabrik.de]("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

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

How is there no steering committee to accumulate wrapping 3rd party libraries in Alien to gain benefits of code in other languages? Do not assume that code is not extremely well written in that particular language for that particular task and that particular deployment mechanism. Can Pharo be called as a shared library from Java JNA? - HH On Fri, Oct 27, 2017 at 15:47, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be. Does that cause issues? Of course. But Iâd rather deal with those than do things I donât enjoy. However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. > > Cheers > > Andrew > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: jtuchel(a)objektfabrik.de > Sent: Thursday, October 26, 2017 8:14 AM > To: pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-users] Smalltalk Argument > > Andrew, > > Am 26.10.17 um 00:46 schrieb Andrew Glynn: > >> Thereâs other questions that are relevant to me: > > I am glad you opened your words with this sentence. Other peoples' mileages may vary a lot. > >> Do I give a f*** about cool looking web apps? No, I donât use web apps if in any way I can avoid it. > > Some people can't. I can't. I am making my living with a web based application. And I like it. > >> Do I give a f*** about mobile apps? No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say.> > > So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. > > Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. > > I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. > > So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a manager's point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? > > Your answer delivers a lot of food for thought, but I don't buy all of it. And I don't expect you to buy all of mine ;-) > > Joachim > >> >> >> Do I give a f*** about the number of libraries in other languages? No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time). >> >> Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version? Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. >> >> Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid. Iâve written better shitty mobile apps than the average shitty mobile apps. However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth. >> >> A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job. That sounds like another âthere arenât enough Smalltalk developers", but it wasnât, because the job wasnât writing Smalltalk. It was writing Java. >> >> The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because "people who grew up with Java donât know how to write code". I donât agree with that, Iâve known a (very few) good Java developers. I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head. >> >> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ. An application is by definition a state-machine, which implies plenty about JS developers on the whole. >> >> If youâre a good developer you can write good code in (nearly) anything. My question then is why would you want to write in crap? The better question is why arenât there more good developers in any language? >> >> Every project I have been able to do in Smalltalk, though, has had one thing in common, the "shit has to work". Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when "shit has to work". They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers. >> >> Why do they not do it? One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often. Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât. >> >> Why donât their competitors do it? Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Put more generally, average stupidity that isnât corrected by the market. Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work. >> >> Enterprises can, and do use Smalltalk when it matters. When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. >> >> Cost is relevant, but not in the simple way people look at things. A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc. Cost becomes largely irrelevant when âshit has to workâ. >> >> Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role. Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. >> >> The productivity argument is realistically only relevant in the context of an already higher hourly cost. Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. >> >> All these ways of looking at it are contingent perspectives though. Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity. All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc. None of them is in itself anything but a result of the others. >> >> If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent. We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at. But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry. >> >> To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference. That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software. In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. >> >> Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is. What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary. Engineers are defined by their ability to make things work. >> >> Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. >> >> Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. >> >> From: Pharo-users [<pharo-users-bounces(a)lists.pharo.org>](mailto:pharo-users-bounces@lists.pharo.org) on behalf of David Mason [<dmason(a)ryerson.ca>](mailto:dmason@ryerson.ca) >> Reply-To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](mailto:pharo-users@lists.pharo.org) >> Date: Tuesday, October 24, 2017 at 11:52 AM >> To: Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](mailto:pharo-users@lists.pharo.org) >> Subject: Re: [Pharo-users] Smalltalk Argument >> >> PharoJS is working to give you that mobile app/browser app experience. As with others, we're not there yet, but getting there. See http://pharojs.org >> >> The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so it's presumably a high percentage of a smallish number of people. >> >> On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: >> >>> First of all: I'd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we don't want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer you've heard the sentence "we've taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. >>> >>> A shortage of developers doesn't exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldn't care. It's that simple. As a consultant, I've heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. It's just a lie: the shortage of Smalltalk developers is not a problem. >>> >>> And, to be honest: what is it we actually are better in by using Smalltalk? >>> Can we build cool looking web apps in extremely short time? No. >>> Can we build mobile Apps with little effort? No. >>> Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? >>> Are we lying when we say we are so extremely over-productive as compared to other languages? >>> >>> I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment I've used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. >>> >>> Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. >>> >>> I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what we've done so far would've taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. >>> >>> Smalltalk is cool, and the day somebody shows me something like Google's flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, I'd say these arguments about productivity are just us trying to make ourselves believe we're still the top of the food chain. We've done that for almost thirty years now and still aren't ready to stop it. But we've been lying to ourselves and still do so. >>> >>> I don't think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you can't win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. >>> >>> Okay, shoot ;-) >>> >>> 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](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201) > > -- > > ----------------------------------------------------------------------- > > 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

Oct. 27, 2017

Re: [Pharo-users] Teapot and Websockets

by Hans

Attila Magyar wrote > Teapot already supports conditional routes, maybe using them instead of > adding the WS: message would be better. > > I'm thinking domething like: > > Teapot on > GET: '/chat' -> whatever; when: [:req | req isWebSocket]; > start. > > or just > > Teapot on > GET: '/chat' -> whatever; when: #isWebSocket > start. > > I'll play with this idea sometime. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html I've played a little bit with this: GET: '/chat' -> [:req | Teapot forward: aReq toWebSocket: '/chat' ]; when: ... The class method of Teapot does the "ZnWebSocketDelegate map: ... to... " thing. It could handle the instances of the delegate per url. Don't know it this matches the Teapot philosophy, it was just another variant to play with. Cheers Hans -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 27, 2017

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

Iâm not claiming I donât or havenât been affected, only that I no long allow myself to be. Does that cause issues? Of course. But Iâd rather deal with those than do things I donât enjoy. However I only got to that point after 26 years in the industry, so I donât expect that everyone will feel that way. Cheers Andrew Sent from Mail for Windows 10 From: jtuchel(a)objektfabrik.de Sent: Thursday, October 26, 2017 8:14 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] Smalltalk Argument Andrew, Am 26.10.17 um 00:46 schrieb Andrew Glynn: Thereâs other questions that are relevant to me: I am glad you opened your words with this sentence. Other peoples' mileages may vary a lot. > Do I give a f*** about cool looking web apps?Â No, I donât use web apps if in any way I can avoid it. Some people can't. I can't. I am making my living with a web based application. And I like it. Â > Do I give a f*** about mobile apps?Â No, the screenâs too small to read anything longer than a twit, or anyone with anything worthwhile to say.> So you are in the lucky position that neither mobile nor web nor integration matters to you or you have enough resources to do all that stuff yourself. I am envyous. I need to build web pages and people ask me whether we can ship an iPhone App. I do customer-facing stuff and sex sells much more than we like to think. Your comments on the crappiness of libs in other languages is a great fit for Smalltalk. Not invented here, therefor rubbish. We came a long way with this way of thinking. But these rubbish makers dance circles around us while we try to do our first hello world for an iPad. They laugh at us when we try to reinvent MVC on top of Seaside (although MVC is closesly related to Smalltalk). Because they are back home and watch Netflix while we debug our homegrown base libraries that are, of course, much better than theirs because they are written in Smalltalk. I am not arguing that maintaining Smalltalk code is far superior to most technolgies out there. But depending on the needs of our projects we have to learn and use those crappy technologies to accomplish what they offer. Because, sometimes (especially if you have to pay bills), an existing library with flaws is better than none. So if I have to use Javascript or C# or Dart or Swift to do the frontend part of my system, is there still much benefit in using these together with Smalltalk? Or is there - at least from a manager's point of view - not a reasonable amount of sense in choosing the frontend technology also for the logic and compensate the loss in productivity with a gain in avoided complexity? Your answer delivers a lot of food for thought, but I don't buy all of it. And I don't expect you to buy all of mine ;-) Joachim Â Â Do I give a f*** about the number of libraries in other languages?Â No, because most of them are crap in every language Iâve had to work in, and the base languages are crap so they have to keep changing radically, and libraries and frameworks therefore also have to and never get any better. The few that are worthwhile I can almost always use from Smalltalk without a problem (read, Blender, ACT-R and Synapse, since every other library/framework Iâve used outside Smalltalk has been a waste of time).Â Â Do I give a f*** about implementing a complex piece of machine learning software in 22 hours, compared to 3 months for the Java version?Â Well, actually yes, I do, because that was 3 months of my life down the toilet for something that is too slow to be useful in Java. Â Any argument depends on your priorities. Iâve written tons of web apps, because I needed to get paid.Â Iâve written better shitty mobile apps than the average shitty mobile apps.Â However, Iâm not going to do any of that any longer in crap that never improves, because after 26 years the irritability it produces is more than itâs worth.Â Â A few weeks ago, a recruiter that specializes in Smalltalk called me about a job, although they were well aware I live 1500 miles away from the city I lived in when I had worked through them, to see if Iâd be willing to move back there for a job.Â That sounds like another âthere arenât enough Smalltalk developersâ, but it wasnât, because the job wasnât writing Smalltalk.Â It was writing Java. Â The person hiring, though, wouldnât look at anyone who didnât write Smalltalk, because âpeople who grew up with Java donât know how to write codeâ.Â I donât agree with that, Iâve known a (very few) good Java developers.Â I would say, though, that Iâve known far more incompetent ones than good ones, and I canât think of any incompetent Smalltalk developers off the top of my head.Â Â Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP, or even C, complain about how hard maintaining state is or coming up with various hacks to avoid it, which seems to be the main point of every JavaScript based âtechnologyâ.Â An application is by definition a state-machine, which implies plenty about JS developers on the whole. Â If youâre a good developer you can write good code in (nearly) anything. Â My question then is why would you want to write in crap? Â The better question is why arenât there more good developers in any language? Â Every project I have been able to do in Smalltalk, though, has had one thing in common, the âshit has to workâ.Â Companies do use it, in fact I could name 4 large enterprises Iâve worked for whoâve written their own dialects, and they all use it only when âshit has to workâ.Â They know itâs more productive, they also know using it for more things would increase the availability of Smalltalk developers.Â Â Why do they not do it?Â One reason, though it takes a while to recognize it, because management doesnât admit even to themselves why they do it, or not very often.Â Being inefficient, as long as it doesnât âreallyâ matter, is an advantage to large enterprises because they have resources smaller competitors donât.Â Â Why donât their competitors do it?Â Because they canât see past an hourly rate, whatâs fashionable, or just new, or because their customers canât. Â Put more generally, average stupidity that isnât corrected by the market.Â Fashion affects smaller companies more than larger ones, because they canât afford a few customers walking away because they wanted an app in Electron, even if they canât give any relevant reason for wanting it, and even the samples on the Electron site donât work.Â Â Enterprises can, and do use Smalltalk when it matters.Â When it doesnât, itâs to their advantage to promote things that are inefficient, buggy and unreliable. Â Cost is relevant, but not in the simple way people look at things.Â A crucial but rarely mentioned perspective on its relevance is that while Java based software runs TV set top boxes, Smalltalk based software runs things like medical equipment, automated defense systems, tanks, etc.Â Cost becomes largely irrelevant when âshit has to workâ.Â Â Productivity is primarily relevant to less talented developers, in an inversely sense, since unproductive environments and attitudes have a leveling tendency in general, and more specifically make accomplishing what the less talented are capable of in any environment sufficiently laborious for them to have a role.Â Capability in Smalltalk, as implied by the person hiring for the Java role I mentioned, is a fairly decent means of judging whether someone is a so-so developer or a good one. Â The productivity argument is realistically only relevant in the context of an already higher hourly cost.Â Given that it is relevant at that point, companies that know Smalltalk is more productive would use it outside things that have to be 100%, if their own productivity were relevant to the same degree that competitorsâ productivity is inversely relevant. Â All these ways of looking at it are contingent perspectives though.Â Yes, if the number of libraries is relevant to you, Smalltalk is less attractive, but thatâs only a contingent phenomenon based on the relative popularity of Java and JavaScript, as a result it canât be used as explanatory for that popularity.Â All the ways of looking at it that are fully determinate are determinate via contingencies of that kind, which for the most part are precisely the other perspectives, including productivity, cost, availability of developers, etc.Â None of them is in itself anything but a result of the others.Â Â If availability of developers is contingent on popularity (and further, popularity contingent on industry attitudes), to use an example already mentioned in Joachimâs post, then his simultaneous posit of library availability is if anything more contingent on the same popularity, so positing it as a cause and not a result, or merely a correlate, of popularity is incoherent.Â We can go one step further, and demonstrate that even when large enterprises make something that works reliably available, they fail to promote and support it, which destroys the market for reliable tooling by simultaneously owning it while not promoting it, something IBM is particularly good at.Â But IBM canât (and if they canât, neither can any other company) operate that way without the tacit agreement of the industry.Â Â To understand it in a more general way, software development has to be looked at in the context where it occurs, and how itâs determined to a large degree by that context, with a specific difference.Â That difference is itself implicit in the context, i.e. capitalism, but only purely effective in software development. Itâs a result of virtualization as an implicit goal of capitalism, and the disruptions implicit in the virtual but so far only realized completely in software.Â In terms of that understanding, the analysis of virtualization and disruption as inherent to capitalism is better accomplished in Kapital than in any more recent work. Â Or you can simply decide, as Iâve done recently, that working in ways and with tools that prevent doing good work in a reasonable timeframe isnât worthwhile to you, no matter how popular those ways and tools might be, or what the posited reasons are, since at the end popularity is only insofar as it already is.Â What those tools and methods are depends to a degree on your priorities, but if developers are engineers those priorities canât be completely arbitrary.Â Engineers are defined by their ability to make things work. Â Software as virtual is inherently disruptive, and the software industry disrupts itself too often and too easily to build on anything. A further disruption caused by developers, as engineers, refusing to work with crap that doesnât, i.e. insisting on being engineers, while in itself merely an aggravation of the disruptive tendencies, might have an inverse result. Â Using a stable core of technologies as the basis for a more volatile set of products, in the way nearly every other industry does, is the best means we know of to build things both flexibly and reasonably efficiently. Â The computer hardware industry is the extreme example of this, while the software industry is the extreme contradiction. Â From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of David Mason <dmason(a)ryerson.ca> Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Date: Tuesday, October 24, 2017 at 11:52 AM To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Smalltalk Argument Â PharoJS is working to give you that mobile app/browser app experience.Â As with others, we're not there yet, but getting there.Â See http://pharojs.org Â The 67% loved means that 67% of people using Smalltalk (or perhaps have ever used it) want to continue - so it's presumably a high percentage of a smallish number of people. Â On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de <jtuchel(a)objektfabrik.de> wrote: First of all: I'd say the question itself is not a question but an excuse. I am not arguing there are enough Smalltalkers or cheap ones. But I think the question is just a way of saying "we don't want to do it for reasons that we ourselves cannot really express". If you are a good developer, learning Smalltalk is easy. If you are a good developer you've heard the sentence "we've taken the goos parts from x,y,z and Smalltalk" at least twice a year. So you most likely would like to learn it anyways. A shortage of developers doesn't exist. What exists is an unwillingness of companies to get people trained in a technology. If Smalltalk was cool and great in their opinion, they wouldn't care. It's that simple. As a consultant, I've heard that argument so often. Not ferom Startups, but from insurance companies, Banks or Car manufacturers who spend millions on useless, endless meetings and stuff instead of just hiring somebody to teach a couple of developers Smalltalk. It's just a lie: the shortage of Smalltalk developers is not a problem. And, to be honest: what is it we actually are better in by using Smalltalk? Can we build cool looking web apps in extremely short time? No. Can we build mobile Apps with little effort? No. Does our Smalltalk ship lots of great libraries for all kinds of things that are not availabel in similar quality in any other language? Are we lying when we say we are so extremely over-productive as compared to other languages? I know, all that live debugging stuff and such is great and it is much faster to find & fix a bug in Smalltalk than in any other environment I've used so far. But that is really only true for business code. When I need to connect to things or want to build a modern GUI or a web application with a great look&feel, I am nowhere near productive, because I simply have to build my own stuff or learn how to use other external resources. If I want to build something for a mobile device, I will only hear that somebody somewhere has done it before. No docs, no proof, no ready-made tool for me. Shortage of developers is not really the problem. If Smalltalk was as cool as we like to make ourselves believe, this problem would be non-existent. If somebody took out their iPad and told an audience: "We did this in Smalltalk in 40% of the time it would have taken in Swift", and if that something was a must-have for people, things would be much easier. But nobody has. I am absolutely over-exaggerating, because I make my living with an SaaS product written in Smalltalk (not Pharo). I have lots of fun with Smalltalk and - as you - am convince that many parts of what we've done so far would've taken much longer or even be impossible in other languages. But the advantage was eaten by our extremely steep learning curve for web technologies and for building something that works almost as well as tools like Angular or jQuery Mobile. Smalltalk is cool, and the day somebody shows me something like Google's flutter in Smalltalk, I am ready to bet a lot on a bright future for Smalltalk. But until then, I'd say these arguments about productivity are just us trying to make ourselves believe we're still the top of the food chain. We've done that for almost thirty years now and still aren't ready to stop it. But we've been lying to ourselves and still do so. I don't think there is a point in discussing about the usefulness of a language using an argument like the number or ready-made developers. That is just an argument they know you can't win. The real question is and should be: what is the benefit of using Smalltalk. Our productivity argument is a lie as soon as we have to build something that uses or runs on technology that has been invented after 1990. Okay, shoot ;-) 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 Â -- ----------------------------------------------------------------------- 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

Oct. 27, 2017

Re: [Pharo-users] [GT] moldable tools for non-developers

by Offray Vladimir Luna CÃ¡rdenas

Hi Sebastian, On 27/10/17 13:15, Sebastian Heidbrink via Pharo-users wrote: > that is kind of what I am looking for. Would you mind if I contacted > you directly? > I am in the process of formulizing a master thesis and would love to > bring Pharo into the mix. > No problem. Contact me. This weekend is a little bit busy with some deadlines I need to reach, but next week is fine. > Is you phd thesis public? It is at [1], with a public repository of the research artifacts since 2011 (before open research was in fashion :-P), but it is in Spanish. Sorry. I didn't have the time to clarify my mind about this research and also improve my English. But I would be glad to discuss it in English with you or anyone interested. You're very welcomed. [1] http://mutabit.com/repos.fossil/doctorado-offray/ Cheers, Offray

Oct. 27, 2017

Re: [Pharo-users] [GT] moldable tools for non-developers

by Sebastian Heidbrink

Hi Offray! that is kind of what I am looking for. Would you mind if I contacted you directly? I am in the process of formulizing a master thesis and would love to bring Pharo into the mix. Is you phd thesis public? I tried to explore software ecosystems in the context of methiation theory by Peter-Paul Verbeek, but I was not able to design an applied mater thesis based on such philosopical theory. This is why the modeling of ecosystems services is a new broad scope that I will have to narrow down during the next quater. Sebastian Am 27.10.2017 um 11:01 schrieb Offray Vladimir Luna CÃ¡rdenas: > Hi, > > > On 27/10/17 10:48, Sebastian Heidbrink via Pharo-users wrote: >> While the ambitions behind GT seem to be developer centric, I wonder >> if there is also research or development done to support non-developer >> pharo users. > Yes. We're trying to bridge the gap between developers and > non-developers (like myself) using moldable environments like Pharo. Our > use case is data activism, visualization and storytelling. So our > intended users are people coming from any of such fields that don't > develop app, but try to tell factual stories supported by data and/or > visualizations. For that I have developed the Grafoscopio[1] tool and > the Data Week workshop+hackathon [2], were we approach the gap between > devs and other users from the point of critical data & software literacy > (pretty far away from the "Hello World" introduction to programming[3]). > > [1] http://mutabit.com/grafoscopio/index.en.html > [2] http://mutabit.com/dataweek/ > [3] http://mutabit.com/offray/blog/en/entry/dumb-hello-world > > Pharo, agile visualization and moldable tools have allowed me to explore > my PhD question about "How we can change the digital tools that change > us?" from this critical approach to data/tech, tools and literacy > for/from activism. > > Cheers, > > Offray > > >

Oct. 27, 2017

Re: [Pharo-users] UFFI and Fortran

by Dimitris Chloupis

Maybe you talk about TalkFFI which aumatically wrapped C libraries for Pharo and i think Squeak as well but used Nativeboos, i think http://forum.world.st/TalkFFI-automatic-FFI-generation-for-Pharo-td4662239.… On the subject of Fortran yes you can use UFFI if Fortran code is compiled as a DLL (or equivelant non Windoom OSes) https://software.intel.com/en-us/node/535305 Dynamic Library format are not exclusive to C for generation , many languages can generate them so even though UFFI is used predominatly for C any language that can generate a DLL without any name mangling should be accessible via UFFI. if DLL generation is not possible, then you can drop down to my solution of Shared Memory Mapped Files. Which means you make an executable in Frotran (or any other language) that contains the code you want to access and creates a shared memory region and you can access that region from Pharo via UFFI. This is how I built my CPPBridge project. Which one can use as a template for generating similar bridge for Fortran or any other language where the generation of DLLs is not practical or possible. The shared memory region can be used also as a means of communication additional to sharing live state, memory mapped files automatically save the live state so next time you open the file it behaves as you would expect a Pharo image to behave by restoring the live state. A means to extend Pharo image to include memory not managed by the VM. Because memory mapped files is mechanism of the OS Kernel and is also the mechanism used for the loading of dynamic libraries like DLLs there is also no loss of performance and is the fastest way of communication between languages, libraries and applications. So yes using Fortran code is possible via UFFI in more than one way. But in the end it should be noted here that because IPC mechanisms (common way of using libraries from other languages) are based on core OS functionality like , memory managment, sockets , pipes, etc its not hard to use libraries from any language from inside any language. So Pharo can use Fortran libraries and Fortran can use Pharo libraries, its also possible to retain live coding even when executing code written in another language through various means. Recently I was succesful in making Python into a basic live coding enviroment , meaning code that when changed in the source file it updates also existing live intances as you expect in Pharo. Python also supports memory mapped files so its possible to create a joined live coding enviroment and live image that containes both Pharo and Python bytecode. Of course without touching VM source code. Even though live state is not tricky to retain for compiled languages, live code can be a bit trickier to do but still not impossible or that hard as most would assume. Sky is the limit. Bottom line is that if you have a favorite library in any language you can use it from inside Pharo with at worst a few hundrend lines of setup code you can create as a library and of coure reuse next time you want to use again a library from another language without having to write a line of additional code. The technology is available is just a matter of learning how to use it. Especially if its a very large libraries it will be thousands times easier than trying to replicate the functionality in Pharo. On Fri, Oct 27, 2017 at 6:26 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > it seems to hint how to do it from Pharo UFFI. > > Slightly OT: I remember years ago, someone (Dave Mason?) demoed a library > which automatically created FFI wrappers for C libs. I never heard anything > about it after that, which is sad, because I was amazed and wanted to use > it! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 27, 2017

Re: [Pharo-users] [GT] moldable tools for non-developers

by Offray Vladimir Luna CÃ¡rdenas

Hi, On 27/10/17 10:48, Sebastian Heidbrink via Pharo-users wrote: > While the ambitions behind GT seem to be developer centric, I wonder > if there is also research or development done to support non-developer > pharo users. Yes. We're trying to bridge the gap between developers and non-developers (like myself) using moldable environments like Pharo. Our use case is data activism, visualization and storytelling. So our intended users are people coming from any of such fields that don't develop app, but try to tell factual stories supported by data and/or visualizations. For that I have developed the Grafoscopio[1] tool and the Data Week workshop+hackathon [2], were we approach the gap between devs and other users from the point of critical data & software literacy (pretty far away from the "Hello World" introduction to programming[3]). [1] http://mutabit.com/grafoscopio/index.en.html [2] http://mutabit.com/dataweek/ [3] http://mutabit.com/offray/blog/en/entry/dumb-hello-world Pharo, agile visualization and moldable tools have allowed me to explore my PhD question about "How we can change the digital tools that change us?" from this critical approach to data/tech, tools and literacy for/from activism. Cheers, Offray

Oct. 27, 2017