Pharo-users

By thread

pharo-users@lists.pharo.org

October 2017

102 participants
822 messages

Re: [Pharo-users] Smalltalk Argument

by Andrew Glynn

I will, although in some ways the two may be more complementary than anything. Sent from Mail for Windows 10 From: Stephane Ducasse Sent: Saturday, October 28, 2017 5:06 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Hi andrew you should contact esteban because he is writing an objective-C bridge.Â Stef On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: One thing Iâm working on is a bridge between Pharo and F-Script.Â F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot.Â However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system.Â To do that you âinjectâ F-Script into the OS.Â The ability to so has a specific implication, though.Â MacOS and iOS are themselves written in and as a dialect of Smalltalk.Â (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run).Â Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk.Â No surprise that Appleâs does, as well. Â In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools.Â The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS.Â Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android.Â Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. Â As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it.Â My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. Â As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo.Â It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments.Â Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it.Â For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: Â Say âhello worldâ Â Since it generates virtually the same bytecode, it may be an easy way to do it. Â With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. Â Tc Andrew Â Â Â Sent from Mail for Windows 10 Â From: phil(a)highoctane.be Sent: Thursday, October 26, 2017 2:19 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â I like that piece a lot, seeing exactly the described situation in large enterprises. Â I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). Â The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. Â One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. Â Now we miss the boat on mobile and bigdata, but this is solvable.Â Â 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. Â 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. Â Phil Â Â Â Â Â Â Â Â On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: Thereâs other questions that are relevant to me: Â 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. Â 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. Â 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 Â Â Â

Oct. 28, 2017

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

by 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 <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *jtuchel(a)objektfabrik.de > *Sent: *Monday, October 23, 2017 3:32 AM > *To: *Any question about pharo is welcome <pharo-users(a)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 > > >> 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 > > > > > > >

Oct. 28, 2017

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

by Andrew Glynn

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

Oct. 28, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by henry

I used to use JINI, a fine system. I didnât know it had been rereleased as Apache River, Iâve been out of it awhile. This was the broker system that got me interested in Linda. Now I have an eventual Linda project called eLinda, which you can find in the Cryptography repository, no prerequisites needed. - HH On Sat, Oct 28, 2017 at 11:25, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Iâm not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each. > > One thing Iâm working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but Iâve added the Synapse micro service bus to control data flows and secure access to remote services. > > It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the carâs subsystems that are relevant to it. > > JINI is far more used than people realize, partly because it âjust worksâ and as a result doesnât get the public âsqueaky wheelâ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering itâs open source) shows the degree to which that effect is operative. > > Thereâs probably a couple dozen other general use cases where the integration will allow Pharo apps to âjust workâ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. Iâd have to mode-switch to think of them off the top of my head though ð. > > Andrew > > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 > > From: [henry](mailto:henry@callistohouse.club) > Sent: Saturday, October 28, 2017 10:02 AM > To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) > Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment > > Hi Andrew, > > Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities. > > What work are you undertaking? > > Regards, > > - HH > >> -------- Original Message -------- >> >> Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment >> >> Local Time: October 28, 2017 9:12 AM >> >> UTC Time: October 28, 2017 1:12 PM >> >> From: aglynn42(a)gmail.com >> >> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >> >> Writing that kind of code is another of the reasons I decided I donât want to work in anything else ð. Maybe more important than some of the others, both to myself and to other users. >> >> Iâve gained so much personally, mostly for nothing, even just considering the relatively few projects I have been able to work on in Pharo and previously in Squeak, VW and VA. Unfortunately in most I havenât been able to make the code public, since they were for entities like the government, DoD, etc. >> >> Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they werenât expensive. More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year). >> >> I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers. >> >> Iâm nearly there on a couple of projects â one Iâm testing and making final tweaks, another is about 2/3dâs of the way. >> >> The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since itâs intended to directly help work you are doing in Pharo, it may worthwhile. Iâm hoping to have it ready for public consumption by the middle of November. >> >> On a different but related topic, the article I wrote got a fair amount of interest considering I donât write nearly as well as Kenneth, for example. Including direct interest from some well known industry people, which canât hurt. In an indirect way it may even be helpful, but not in the real, direct way decent code is. >> >> Capabilities that wonât be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself. >> >> Cheers >> >> Andrew Glynn >> >> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >> >> From: [Stephane Ducasse](mailto:stepharo.self@gmail.com) >> >> Sent: Saturday, October 28, 2017 5:09 AM >> >> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >> >> Subject: Re: [Pharo-users] Smalltalk Argument >> >> Hi andrew >> >> please take a project that would help to bring more companies and that you want to push and push it with us :). >> >> Stef >> >> On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >>> Hi andrew >>> >>> you should contact esteban because he is writing an objective-C bridge. >>> >>> Stef >>> >>> On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>> >>>> One thing Iâm working on is a bridge between Pharo and F-Script. F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot. However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system. To do that you âinjectâ F-Script into the OS. The ability to so has a specific implication, though. MacOS and iOS are themselves written in and as a dialect of Smalltalk. (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk. No surprise that Appleâs does, as well. >>>> >>>> In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools. The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS. Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android. Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. >>>> >>>> As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it. My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. >>>> >>>> As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo. It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments. Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it. For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: >>>> >>>> Say âhello worldâ >>>> >>>> Since it generates virtually the same bytecode, it may be an easy way to do it. >>>> >>>> With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. >>>> >>>> Tc >>>> >>>> Andrew >>>> >>>> Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10 >>>> >>>> From: phil(a)highoctane.be >>>> >>>> Sent: Thursday, October 26, 2017 2:19 AM >>>> >>>> To: [Any question about pharo is welcome](mailto:pharo-users@lists.pharo.org) >>>> >>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>> >>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>> >>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>> >>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>> >>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>> >>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> Phil >>>> >>>> On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: >>>> >>>>> Thereâs other questions that are relevant to me: >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> 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](tel:%2B49%207141%2056%2010%2086%200) Fax: [+49 7141 56 10 86 1](tel:%2B49%207141%2056%2010%2086%201)

Oct. 28, 2017

Re: [Pharo-users] Linear solvers

by Ben Coman

thx for the tip. cheers -ben On Sat, Oct 28, 2017 at 11:47 PM, werner kassens <wkassens(a)libello.com> wrote: > On 10/28/2017 04:23 PM, Ben Coman wrote: > > btw, what does PolyMath/SciSmalltalk offer in the way of linear solvers? > Hi Ben, > so far no linear solvers in PolyMath. i made a small constraint solver > for PolyMath that is not restricted to linear problems, hence > necessarily slower than linear solvers & not fast enough for > UI-layout-problems. a general overview of what that package does is > here: > https://github.com/SergeStinckwich/SciSmalltalk/wiki/RealInterval-Example- > Algos > . the constraint solver is described somewhere in the middle of that page. > werner > >

Oct. 28, 2017

Re: [Pharo-users] Linear solvers

by werner kassens

On 10/28/2017 04:23 PM, Ben Coman wrote: > btw, what does PolyMath/SciSmalltalk offer in the way of linear solvers? Hi Ben, so far no linear solvers in PolyMath. i made a small constraint solver for PolyMath that is not restricted to linear problems, hence necessarily slower than linear solvers & not fast enough for UI-layout-problems. a general overview of what that package does is here: https://github.com/SergeStinckwich/SciSmalltalk/wiki/RealInterval-Example-A… . the constraint solver is described somewhere in the middle of that page. werner

Oct. 28, 2017

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

by Steffen MÃ¤rcker

Does that mean the sets/bdd would be constructed mainly at comile time? Anyway, Andrew, feel free to contact me, I might help you with this. Best, Steffen Am .10.2017, 16:05 Uhr, schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > I think that andrew would like to improve smacc when parsing inputs > containing utf-8 characters. > > > On Sat, Oct 28, 2017 at 1:46 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >> I see. What is the task in detail? Are some of the set fixed or known in >> advance? What's the argument against a bitset-based solution? >> >> Cheers, Steffen >> >> >> >> Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse >> <stepharo.self(a)gmail.com>: <---Schnitt---> >> >

Oct. 28, 2017

Re: [Pharo-users] [ANN] Grafoscopio is now also an indexedpublication

by Andrew Glynn

Btw, thank you personally. In another project Iâve started to use both Grafoscopio itself (from a developer perspective) but also programmatically to improve that project. Hopefully Iâll be able to release that project soon (i.e. in the next couple of weeks) and youâll be able to see how Grafoscopio improvise it, but also how it increases the capabilities of Grafoscopio. Andrew Glynn Sent from Mail for Windows 10 From: Offray Vladimir Luna CÃ¡rdenas Sent: Saturday, October 28, 2017 11:02 AM To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] [ANN] Grafoscopio is now also an indexedpublication Thanks Stephan, As told many times. This community has been really empowering to prototype the artifacts for my PhD (which is *not* in software [1]). Is good to count with such proactive and helpful community. [1] http://www.doctoradoendiseno.com/en This learning process is just starting. Cheers, Offray On 28/10/17 09:27, Stephane Ducasse wrote: > well done. > > > On Sat, Oct 28, 2017 at 12:58 AM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> 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. 28, 2017

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

by Andrew Glynn

Part of the reasoning is that by writing JVM bytecode, the differences between the various JVM languages become largely irrelevant, though in some ways it becomes slightly less convenient if calling, for example, Scala or Clojure code from Pharo. The other is inherent JVM limitations and discrepancies between Java as a semantic spec and various specific implementations as dynamic systems, particularly since the latter differ both by Java version and by which frameworks might be in use, and dynamically create further discrepancies contingently based not only on the above, but also specifics of the system and its current state. Cheers Andrew Sent from Mail for Windows 10 From: Stephane Ducasse Sent: Saturday, October 28, 2017 10:06 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk I think that andrew would like to improve smacc when parsing inputs containing utf-8 characters. On Sat, Oct 28, 2017 at 1:46 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > I see. What is the task in detail? Are some of the set fixed or known in > advance? What's the argument against a bitset-based solution? > > Cheers, Steffen > > > > Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse > <stepharo.self(a)gmail.com>: >> >> It was for test inclusion of UTF-8 characters so we do not want to >> rely on external libraries. >> >> On Fri, Oct 27, 2017 at 1:54 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> Dear Andrew, >>> >>> I didn't find time to answer earlier. Some time ago, I was looking for a >>> (MT)BDD package in ST as well. I didn't found one. So the only two >>> options >>> left are >>> >>> 1) implementing a new BDD lib in ST and >>> 2) doing FFI to some existing lib, e.g. CUDD, Sylvan, Jinc >>> >>> I'd prefer 2) since the existing libraries are feature-rich and highly >>> optimized - which took quite some time. As a bonus, a solution could >>> potentially switch between those backends. The biggest hurdle, in my >>> option, >>> is memory management, since most libs use some sort of reference >>> counting. >>> And you do not want to end up with nightmarish dozens of ref(bddNode) >>> deref(bddNode) in your application code (like the probabilistic model >>> checker PRISM does). This introduces hard to track bugs easily. However, >>> I >>> have an idea in mind how to tackle this but I didn't found the time to >>> put >>> it into code yet. >>> >>> May I ask, which sort of application do you have in mind? >>> >>> Best, Steffen >>> >>> >>> >>> >>> Am .10.2017, 07:54 Uhr, schrieb Prof. Andrew P. Black >>> <black(a)cs.pdx.edu>: >>> >>>> Thanks for the responses so far. I see that I need to clarify my >>>> enquiry. >>>> >>>> B-Trees and BDDs are not the same. BDDs are an efficient and compact >>>> representations for Boolean functions, sometimes used in SAT-solvers >>>> and >>>> electronics design. The key idea is that since the output must be 0 >>>> or 1, >>>> you can represent any Boolean function as a tree whose depth is the >>>> same as >>>> the number of bits in the input. >>>> >>>> To make the tree small and efficient, though, you need to eliminate any >>>> node whose two children are the same, and to share subtrees, so that >>>> you >>>> really get a DAG, not a tree. The full name for these efficient >>>> compressed >>>> trees is âReduced Order Binary Decision Diagramsâ, or ROBDDs. I was >>>> hoping >>>> that someone else had implemented the algorithms necessary to build >>>> this >>>> representation. >>>> >>>> Because sets can be considered to be Booleans functions (true => >>>> argument >>>> is in the set), you can use ROBDDs to efficiently represent large sets. >>>> >>>> To be clear, despite the word âdiagramâ in the name, one is not >>>> normally >>>> interested in drawing the BDD â except in the documentation for the >>>> package >>>> ;-). Normally, BDDs they are used to represent sets, or functions, >>>> where >>>> the drawing would be hopelessly large. >>>> >>>> The BuDDy package (http://buddy.sourceforge.net/manual/main.html) is an >>>> example of what Iâm looking for, but unfortunately itâs in C++. >>>> >>>> Andrew >>>> >>>> >>>>> On 25 Oct 2017, at 21:39 , Stephane Ducasse <stepharo.self(a)gmail.com> >>>>> wrote: >>>>> >>>>> Hi andrew >>>>> >>>>> I think that Avi did a package about BDD (but I thought it was special >>>>> binary trees) so this is probably the same. >>>>> Did you check on Squeaksource? >>>>> http://www.squeaksource.com/BTree.html >>>>> If this is what you are looking for I can help porting it to Pharo. >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Wed, Oct 25, 2017 at 9:02 PM, Prof. Andrew P. Black >>>>> <black(a)cs.pdx.edu> >>>>> wrote: >>>>>> >>>>>> >>>>>> Does anyone know of a BDD â thatâs Binary Decision Diagram â package >>>>>> written in Smalltalk? >>>>>> >>>>>> Andrew >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >

Oct. 28, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by Andrew Glynn

Iâm not working on that specifically, although what I am working on could definitely use that and vice versa, which would increase the capabilities of each. One thing Iâm working on is using Vert.x for service registration and discovery, mapped to Apache River (JINI) to propagate that over non-local network segments that require fully authenticated security (as a result, it also provides things such as Kerberos to Pharo apps). The mapping between the two is very straightforward, almost direct, but Iâve added the Synapse micro service bus to control data flows and secure access to remote services. It enables things like automatic configuration/integration of Pharo based mobile apps with newer cars that support that kind of autoconfiguration, since they all use JINI to do so. Thus a Pharo mobile or IoT app can automatically be configured to work with any of the carâs subsystems that are relevant to it. JINI is far more used than people realize, partly because it âjust worksâ and as a result doesnât get the public âsqueaky wheelâ effect. The fact that the authors of Vert.x reimplemented half of the features of JINI, in a less comprehensive and less reliable way, rather than just using it (especially considering itâs open source) shows the degree to which that effect is operative. Thereâs probably a couple dozen other general use cases where the integration will allow Pharo apps to âjust workâ in a JINI or Vert.x environment, as well as thousands of industry/company specific ones. Iâd have to mode-switch to think of them off the top of my head though ð. Andrew Sent from Mail for Windows 10 From: henry Sent: Saturday, October 28, 2017 10:02 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment Hi Andrew, Are you working to bring a Capabilities model to Pharo? This is precisely what I am working to bring with Hubbub, running on top of my ParrotTalk. I derived these from erights.org's ELib and have been working on them for many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to implementing marshalling of layer 6 objects using STON all to run on top of ParrotTalk. Once I get marshalling with scope substitutions, I will debug Hubbub to offer distributed Capabilities. What work are you undertaking? Regards, - HH -------- Original Message -------- Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment Local Time: October 28, 2017 9:12 AM UTC Time: October 28, 2017 1:12 PM From: aglynn42(a)gmail.com To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Writing that kind of code is another of the reasons I decided I donât want to work in anything else ð.Â Maybe more important than some of the others, both to myself and to other users. Â Iâve gained so much personally, mostly for nothing, even just considering the relatively fewÂ projects I have been able to work on in Pharo and previously in Squeak, VW and VA.Â Unfortunately in most I havenât been able to make the code public, since they were for entities like the government, DoD, etc. Â Â Not that VA attracts me quite so much to give back all that strongly, when a license is $8500+. Â Were it possible to give back to VA C++ or VA Java, it might be different, but neither were OSS although they werenât expensive. Â More relevantly, both are now abandonware (hence my comment about IBM, which is applicable to OS/2 as well, although that has quietly had a 5.0 version released in June of this year). Â I would, though, love a chance to give back to Pharo primarily, although I may port anything relevant to Squeak, and if I have sufficient time port it to VW, which although not OSS is at least affordable to most developers. Â Iâm nearly there on a couple of projects â one Iâm testing and making final tweaks, another is about 2/3dâs of the way.Â Â The first project you (and others on the list) may be more immediately interested in testing, since it requires little to no additional work to use it, and even if not perfect, since itâs intended to directly help work you are doing in Pharo, it may worthwhile.Â Iâm hoping to have it ready for public consumption by the middle of November.Â Â On a different but related topic, the article I wrote got a fair amount of interest considering I donât write nearly as well as Kenneth, for example.Â Including direct interest from some well known industry people, which canât hurt.Â In an indirect way it may even be helpful, but not in the real, direct way decent code is. Â Capabilities that wonât be available in anything else in an really usable way (because to be efficient they depend on capabilities not found in anything else), and in any case nowhere near as useful in anything else, will hopefully be more use than any article can be, never mind one I wrote, not just to me but also to other Pharo users and to Pharo itself. Â Cheers Andrew Glynn Â Â Sent from Mail for Windows 10 Â From: Stephane Ducasse Sent: Saturday, October 28, 2017 5:09 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â Hi andrew Â please take a project that would help to bring more companies and that you want to push and push it with us :). Â Â Stef Â Â On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: Hi andrew Â you should contact esteban because he is writing an objective-C bridge.Â Â Stef Â On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: One thing Iâm working on is a bridge between Pharo and F-Script.Â F-Script is, basically, a Smalltalk dialect, as is obvious from the screenshot.Â However for MacOS and iOS, it allows you to bypass the static Objective-C API interface and debug / modify or even write applications directly in the system.Â To do that you âinjectâ F-Script into the OS.Â The ability to so has a specific implication, though.Â MacOS and iOS are themselves written in and as a dialect of Smalltalk.Â (were it simply an overlay on Objective-C, it wouldnât be able to do things that are impossible in Objective-C, and it wouldnât need to be âinjectedâ in order to run).Â Every implementation of Objective-C , bar GNUâs useless imitation, compiles to Smalltalk.Â No surprise that Appleâs does, as well. Â In any event, it will allow Pharo code to be mapped to MacOS and iOS objects, injected into the system dynamically, and modified / debugged dynamically using the Pharo tools.Â The result, at least as far as iOS is concerned, may make Pharo actually the most powerful way to program it, well beyond XCode alone, along with doing the same for MacOS.Â Android is another issue, although the Raspbian port of Pharo should be relatively easy to port to it. For me, unless someone had a use case, I donât have one myself for Android.Â Iâve tried nearly every version, because Iâd love to support an OSS ecosystem, unfortunately using it compared to the iPhone is still like driving a Fiero based kit car compared to an actual Ferrari. Â As far as JNI, while I see your point, JNI is such a PITA that few Java developers know it.Â My usual workaround is to use Stamp and Synapse, which has the further advantage of allowing Java to âthrottleâ data that the JVM canât deal with at full speed. Â As far as dealing with other JVM languages, PetitParser or SmaCC can generate bytecode rather than Java or other JVM code, and that allows libs to be written that utilize Synapse to talk to Pharo.Â It isnât necessarily an ideal solution, but a possible one without having to support umpteen environments.Â Another potential way of accomplishing that is to use NetRexx, a declarative JVM language, which is both easy and terse, and like SQL, generates the actual bytecode rather than precompiling to it.Â For instance, imagine the code needed for a simple âhello worldâ in Java, then compare: Â Say âhello worldâ Â Since it generates virtually the same bytecode, it may be an easy way to do it. Â With the last statement, that expresses really well the exact reason I no longer want to work in most other environments ð. Â Tc Andrew Â Â Â Sent from Mail for Windows 10 Â From: phil(a)highoctane.be Sent: Thursday, October 26, 2017 2:19 AM To: Any question about pharo is welcome Subject: Re: [Pharo-users] Smalltalk Argument Â I like that piece a lot, seeing exactly the described situation in large enterprises. Â I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). Â The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. Â One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. Â Now we miss the boat on mobile and bigdata, but this is solvable.Â Â 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. Â 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. Â Phil Â Â Â Â Â Â Â Â On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: Thereâs other questions that are relevant to me: Â 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. Â 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. Â 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 Â Â Â Â Â Â

Oct. 28, 2017

← Newer
1
...
4
5
6
7
8
9
10
...
83
Older →

Jump to page: