Hi Stef, > What I can tell you is that we are growing :). > When a company with more than 30 millions lines of code wants to migrate > to Pharo. > It means something :) and we are helping them and they actively support > the consortium > with immediate impact. Pablo is working full time to improve pharo and we > feel it.
That */is/* an impressive show of confidence in Pharo and its community! The risk + expense of that is just mind-boggling... I think it also shows that "Pharo is a big-league language". > Yes there is a strong support from the community and from the consortium. > This is why we create the consortium (since 2012). It is here to support > companies and pharo development and pharo and its community are growing > steadily. This will certainly help at larger scales of Pharo use, at the point where a mission realizes they have a dependency on Pharo, similar to how they depend on other vendors for "product support" when there are issues that might impact delivery schedules, etc. I'm thinking of starting out small: introduce Pharo as a means of producing support tools, performing analysis & presentation, and so forth -- places where there is not much concern what languages are used to build a needed app, or where the output is the focus rather than the means. By demonstrating speed, ease of use, easy maintenance, features, etc. this can lead to requests for more Pharo work. Then it grows from there. (Pharo improves, too, as this is occurring.) > Esteban went to give special lectures or coaching to companies in the > past. > Since a year the consortium is supporting Schmidt Pro and Lifeware based > on contract > and so far this is working well. We will continue. Schmidt Pro looks like a U.S. firm. There are multiple Lifewares, but I think you may be referring to the INRIA associate? > Also what is important is that Mooc is a key assets: why because it > represents > 15 years of teaching experience. There are OOP teachers that are learning > things on OOP > when watching the mooc. So the mooc is not only about pharo. This is understandable; many universities use Smalltalk to teach the principles of OOP. Seems logical that this would lead to using ST afterwards to follow through. (But I know this doesn't often happen.) I've gotten through all but the last two weeks of the MOOC so far, and it is quite good. I will be suggesting it to people here. > Now a smart guy can learn Pharo in two days (Henrique Rocha did it and we > hired him :), > and after 2 weeks to play with the ide you can start to get fluent. Pharo has a different sort of learning curve: The language is simple, and only requires different thinking to grasp some of the concepts. Most of the learning involves how to make use of the IDE and what are the base classes needed to make useful things. My frustrations have all involved things like "How do I build a deployable application, start to finish?" Most of the teaching materials seem focused on how to write Pharo code, but that's really the easy part (if you've programmed with anything else before). I will need to make tools in Pharo, but then I have to give something to another engineer to run on his own. There are levels, of course: Run from the CLI, run from a native (Spec) GUI, run from a web browser (by building a web app in Pharo) -- in increasing order of complexity and experience/skills needed. I /want/ to be able to do all of these, of course. The challenge of enrolling other developers into the Pharo ecosystem (with all its advantages, many hidden at first) will revolve around how quickly they can make something, even if CLI-based. They will want to see early results, then they get hooked and want to invest to learn how to do more. Still, the early results will involve "How do I make a simple application with this, like the way I can script something?" I would really love to see a booklet that covers this subject (and I'm sure others would, too). > BTW the Mooc value is around 150 Keuros and it is free because we did it > and it was sponsored > by our institute and some other universities. Good training materials are very, very important. (And should be free, as the MOOC is.) One of the things I've mentioned to others about the MOOC is that it shows you how easy it is to build a professional-looking web application using Pharo and its web libraries. (Of course all trainings teach you the syntax and semantics of any language; the MOOC is also showing you /how to build things/, and how many of us have built web apps before? I never did.) > Yes this is why we can help to show how we do things. > We will tell you also where we are not so good and where we want to go. I see this as a "mutually beneficial" possibility. I'm not looking to see "What can Pharo do for me to make my job easier?" I'm interested in "How can I help JPL benefit from what Pharo offers, while at the same time contributing back to Pharo & its community to make a better ecosystem?" Because when powerful, productive tools such as Pharo improve, everyone benefits, directly and indirectly. JPL is an FFRDC (Federally-Funded Research & Development Center), and our mission includes advancing technology and assisting industry in ways that they cannot do themselves, or cannot afford to do. We don't just "send spacecraft to the planets". Many don't realize this. I prefer this "business model", so I've worked here my entire career. > Right now we are starting a real effort for the following years on the > virtual machine. > One day we will revise the Pharo vision document (should be on internet > somewhere) > but it shows that we have a vision/roadmap and that we built it. The virtual machine intrigues me, so starting my contributions on the UFFI docs (and maybe code, too) is a good place for me. > You see you can play it the way you want. > The first ticket for a company is 1000 euros and else you can play as > an official academic member of the consortium. We would be academic, I'm sure. But that's on the horizon, at this point. > Now what is more important is that we listen to our users. So the > consortium roadmap is > validated by the consortium > members and we are helping as much as we can. Our goal is to make people > succeed with their > Pharo projects. We want to create a vertuous ecosystem. Excellent -- You don't just "write Pharo and throw it over the wall". Here's what I would like to see happen: I start a "interest group" here, find like-minded engineers & developers who want to learn "this new thing" (which isn't new, of course), and encourage the use of Pharo. Almost everything we do here is custom-built one way or another, so there are tools, scripts, web apps, etc. that we built as a matter of course. Many languages are used for this; Pharo can easily be one of them. There will be both a "newness" hurdle, but also a "strangeness" hurdle to deal with. The strengths and "cool tools" of Pharo (along with the ease of making GUIs and web apps, and cool graphics from Roassal, etc.) will pull strongly to overcome these hurdles and motivate interest -- IF this is presented, marketed, supported properly AND if some early successes come out of it. "Nothing sells like success." We have some very creative, very smart people here, who love "cool technology" and "toys to play with", but they are also very busy people... and there's always that need to be successful, so invest wisely. There is a joke that goes like this: "JPL has only two products: Photographs and press releases." Another one is "JPL's successes end up on the front page of all the world's newspapers. JPL's failures end up on the front page of all the world's newspapers." It it works, super. Good for you. If does something I can't do (and need to), you've got my attention. If it's fast & easy to learn, I'll try it out. If it's complicated, you're losing me. If it doesn't work.. See ya later! And this has to be addressed at the level of developers and then at the level of managers... Building on that is where the issues of reliability, the Pharo Association & its support, community, and so forth come into play. As an analogy, we have processes we must go through with vendor or custom hardware to establish electrical safety, fail-safe, and so forth before such hardware can be connected to spacecraft to do its job. Software has similar risk-mitigating requirements, and if Pharo were to play a prominent role, that kind of trustworthiness must be established as well. Financial organizations are concerned with "We don't want a flaw to cause us to lose our money"; we're concerned with "We don't want a flaw to cause us to lose a mission". That sort of thing... So the kinds of support you're mentioning are good to hear. > A super concrete example, feenk reported that the windows update 1903/4 > changed something > and that their guys working on windows could not access git via libgit > anymore. > Pablo and Guille put this on their highest priority just after ESUG and it > was solved within > a couple of days. I did follow that thread. (I've been reading almost all the Dev & Users mailing list postings for this past year.) > Feenk got problems with a binding or headless VM and pablo pair programmed > with one of > their engineering during ESUG. That's also strong evidence of significant support. We're used to having "field engineers" show up on-site to help work out some of our tougher problems with vendor's products. Thanks again for your responses. (And for the support from other community members I've talked to.) I see nothing so far that doesn't continue to encourage me. I've looked at the community, the tools, the documents, the code, the MOOC and other trainings & examples, and played with it myself -- all good (even if some areas are still evolving). What's turning over in my mind is how to best present this, how to market it and get developers here "hooked" enough to spend time getting over that initial hill of understanding. At first, Pharo is just /weird/, if intriguing. There is *definitely* an ROI for those who will make the effort, carve out the time, and try it. -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
