Re: [Pharo-users] Pumping FFI documentation [WAS] FFI beginner question

Hi 

Hi Stef,

Okay, that's in line with what I expected.  No worries!

The devops part of me still wants to know how the process works, though.  I
like the format it produces, and I could see adopting it for a documentation
tool outside of Pharo (assuming everything is open source).

-Ted



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

> On 25 Sep 2019, at 16:51, Brainstorms <[hidden email]> wrote:
>
> Hi Stef,
>
> Okay, that's in line with what I expected.  No worries!
>
> The devops part of me still wants to know how the process works, though.  I
> like the format it produces, and I could see adopting it for a documentation
> tool outside of Pharo (assuming everything is open source).

Yes it is fully open-source.
It has a way to plug different “book” templates.
I know some companies that used it to generate documentation.
Now with guillermo we spent some days there and there to improve (all my slides, books, ….)
are based on pillar.

Stef
>
> -Ted
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

It has probably some rough edges so to not hesitate to come back to us.
I’m currently migrating all the books, booklets, to the latest tagged version.

I can offer my writing/editing/proofreading skills for this work, too.

As Guillermo pointed out, the documentation is "super important".  And I can
be immediately productive there, as my English skills are way ahead of my
Pharo coding skills.

I'm also approaching this as a relative newbie, and as someone with
aspirations to start teaching Pharo (informally, at least at first) where I
work...

-t




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

> On 25 Sep 2019, at 17:56, Brainstorms <[hidden email]> wrote:
>
> I can offer my writing/editing/proofreading skills for this work, too.
>
> As Guillermo pointed out, the documentation is "super important".  And I can
> be immediately productive there, as my English skills are way ahead of my
> Pharo coding skills.

Read what you want.
I would like to produce a booklet out of the excellent libraries sven is developing over the years
so that we can update the documentation that he wrote in Entreprise Pharo.

> I'm also approaching this as a relative newbie, and as someone with
> aspirations to start teaching Pharo (informally, at least at first) where I
> work…

The mooc contains a lot of material that is under CC so feel free to use, ask for feedback
we can also help with a remote lecture if you see fit.
>
> -t
>
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

I'll likely start working with Guillermo on the UFFI booklet.  I also see the
'by example' booklets as being /very/ important, as they give critical first
impressions to those new to the whole concept of Smalltalk.  I want to
enroll others in Pharo, and that means I need good docs/web pages to direct
people to.

There are documents needed for reference; to answer questions & guide style,
usage, conventions, understanding.  But there are also documents needed to
enroll newcomers, get attention, provide that "hook"...  Both are important.
You're aware of Pharo's "marketing needs" as well as anyone, I'm sure.

So thanks for the generous offer.  I'm thinking about starting here with an
interest group, along with some tools and demonstration projects (based
closely on the work we do) to get attention & interest.  That should evolve
into training needs, and that's where I think the MOOC and remote lectures
would come into play.

We are (also) a national R&D institute where software, automation, etc.
figures prominently.  It's long past time that we have an awareness of Pharo
and tap into its advantages to improve the quality, reliability, &
productivity of our missions.  This has been on my mind for some months now.

-t



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Ok!
Let us know how we can help.

There is also the Pharo consortium: it is free for “academix” but is a nice way to
show that we are working in a sound robust eco-“system”.

There is enough space for everyone willing to contribute.
And I do not know if you saw some of our talks but Pharo is yours means that
this is not a product and that people can get an impact.

Stef

Thank you, I will; community support will be important -- developers (and
their managers!) are very conscious of the "critical mass" issue.  They all
want to know that if they make an investment in learning and using a new
language, tools, development paradigm, etc. that there's a company/support
structure/resources behind it that will exist for a long time to come.  No
one wants to "get stuck" with an orphan product or technology -- even if it
is attractive at first.  (The culture here can be a bit risk-averse in
places.)

We also welcome open-source projects, and use them freely.  Adopting Pharo
would not be substantially different than our current widespread use of
Linux, C/C++, Python, Lua, Tcl, SVN, Git, etc.  There's definitely a place
for it here.  But very few know about it!

I've attended a Tech Talk (and plan to join tomorrow's talk).  And I'm aware
of the consortium; I joined the Pharo Association myself as an individual.
There's no reason why we wouldn't/couldn't do so as an academic
organization, at some point (assuming my plans succeed).  

We have an unusual situation: JPL may be part of NASA (they own the
buildings, the equipment, the property, fund the projects, etc.), but we are
not civil servants -- we don't work for the federal government as do other
NASA center staff.  We're actually staff members of Caltech, under
privileged long-term contract.  So I can either be "a government employee"
(via contract) or "an academic staff member", depending (usually on what
kind of discount some business may be offering. ;^)

So it may be easier as Caltech to have an academic association.  Something
also for the future...

-t





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Hi ted

> Thank you, I will; community support will be important -- developers (and
> their managers!) are very conscious of the "critical mass" issue.

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.

>  They all want to know that if they make an investment in learning and using a new
> language, tools, development paradigm, etc. that there's a company/support
> structure/resources behind it that will exist for a long time to come.  No
> one wants to "get stuck" with an orphan product or technology -- even if it
> is attractive at first.  (The culture here can be a bit risk-averse in
> places.)

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.
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.

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.
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.
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.

> We also welcome open-source projects, and use them freely.  Adopting Pharo
> would not be substantially different than our current widespread use of
> Linux, C/C++, Python, Lua, Tcl, SVN, Git, etc.  There's definitely a place
> for it here.  But very few know about it!

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.
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.


:)
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.

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.
 
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.

Feenk got problems with a binding or headless VM and pablo pair programmed with one of their engineering
during ESUG.

> So it may be easier as Caltech to have an academic association.  Something
> also for the future…

Academic membership is simple and free. You have the same document than the industrial member.
And I think that Caltech fit there.
Now we also have some academics that pay to support Pharo. But this is the way people want to play it.

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

>
> Schmidt Pro looks like a U.S. firm.  

no this is a german one.

> There are multiple Lifewares, but I
> think you may be referring to the INRIA associate?

Lifeware.ch


Yes we should improve on this.

> 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.  

Thanks. We will have to do something there.

>
> 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.  

I should add a CLI to one of my project and I will use it to write a small tutorial.


Let us know :)

:)

Pick up something that help you and build it.
Be your first success story like that you will have something to show
and we can help too :)

>
> -t
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

I have found a project that I think is a good fit in size & complexity, one
that can operate at that "CLI level" (i.e., doesn't need a GUI or a web
front end).

We ("we" being my group and a number of projects around the Laboratory we've
been associated with) are migrating code from a Subversion server to a
central "Enterprise" GitHub (not publicly accessible).  I'm the admin for
this particular SVN server, so I'm doing the migrations.  Having assumed
most all of the group's devops functions over the years, I frequently have
to write code to automate tasks like these.  That puts me in an good
position to write these tools in Pharo instead of Bash or Lua or Python,
etc. as I normally have been doing.

Some of the SVN repos convert nicely, using available migration tools (such
as 'svn2git' or 'git svn').  However, many developers are insufficiently
trained on VCS, and over the years many of the SVN repos have been choked
with inappropriate files and have had their history threads tangled up -- so
they will not covert.  I've studied the internal structure of SVN repo dump
files, and I have algorithms (and some code in Bash & Python) that allow me
to edit these files to make them convertible.  Still, it's a lot of
hand-work; a more comprehensive solution is needed.

I'm going to make a tool, in Pharo, for general editing of SVN dump files:
to remove junk that doesn't belong, extract single projects from mixed-use
repos, simplify history for tangled moves, etc.  The output will be clean
dump files containing the extracted project-specific commits that will then
roll into GitHub without issues and show up with branches, tags, etc. as
expected.

While researching how to do this, I've converted 3 of >80 repositories
(which resulted in 15 project repos grouped in 3 GitHub Organizations).  My
methods work; I just need to fully automate the process so that I can
complete the remainder.

Ironically, I'm not actually being funded to do this as one of my "normal"
job tasks -- certainly not the automation part.  As a result, this has
become a "nights and weekends" effort.  But that means I will own the code
-- so I plan to put it on the *public* GitHub, with an MIT/Apache
open-source license.  Of course, everyone else who's been frustrated trying
to convert complicated SVN repos into GitHub will have my Pharo tool to use.
(That could result in a lot of exposure to Pharo..??)  And it allows the
Pharo community to potentially help, since they'll have access to the source
code as well.

This kind of project does not require a GUI (it will be run by Linux admin
types) and it does not benefit from a web interface.  It's mostly file I/O,
with some parameters that need to be negotiated with the user once the SVN
dump file has been scanned.  Challenging, but not too challenging.

From there I can advertise its use around the Lab.  We're not the only group
that's been using SVN.  Some other sysadmins are likely to want
modifications...  A start?

-t



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Pay attention because Pharo could be better for supplanting bash.




To help you, you can extend the inspector to provide specific view on data.

>
> From there I can advertise its use around the Lab.  We're not the only group
> that's been using SVN.  Some other sysadmins are likely to want
> modifications...  A start?

To me Pharo is not really at the level I would like to. But this is my view.
Now we have nice binding to invoke shell and other like subOSProcess.
We should also progress on that front.

To me Pharo is super good at manipulating complex data and object
and building nice abstraction.

So I hope that you will not be disappointed.
>
> -t
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

> Pay attention because Pharo could be better for supplanting bash.

That was one of the first things I was evaluating Pharo on, to see its
potential for replacing Bash (and therefore Lua, which I was also
considering for this, initially; I'm one of those holdouts who hasn't
learned Python -- I want "the real OOP" instead).  But I have many years of
programming Bash; I automate things.  I really want Pharo to become my
"handy tool" for this.  And more.

Now, there's this wrinkle: Pharo doesn't run in the same realm (e.g., Linux
Userland) as the OS and associated tools I need to work with; it runs in its
own container, akin to running in Docker or LXC.  We call them "image
files", but they're really like Docker or LXC containers -- only Pharo
containers are plugged into a VM instead of a Linux kernel (so it's much
better!).  Also, the realm of Pharo is "Objectland", not an isolated
filesystem such as LXC provides.  But the principles are the same, and.. do
I really want to learn Docker?

The consequence of this is, "How do you cross the container boundary, as
needed, to interact with 'the real world'?" And do so with ease?  This is
distinctly different from, say, file I/O, where you're almost doing the
opposite in Pharo: Bringing (a representation of) the file system into the
image in order to interact with it.  I can't bring 'grep' into Pharo; I need
to reach outside and launch 'grep', and interact with it, all from code
executing in my image.

Pharo shares this issue with Docker, but goes one further: Marshalling
in/out of objects, because that's all there is "on the inside".  These are
interesting CS/IT issues, for sure...  We depend on skillful IDE developers
in the Pharo community to make it all work smoothly, almost invisibly.

> To me Pharo is not really at the level I would like to.

I have already gotten the feel for this.  I started with an impression of
"Pharo is Smalltalk that's modernized and mature, finally!" (having shifted
from Squeak), to a more subtle feeling of "Wow, it's evolving (quickly!),
there are many areas being improved, and still some things that are "in the
rough".  

And that's okay; Rome wasn't built in a day and this is a major project.
We're "rebuilding a 1970's sedan into a 21st Century electric autonomous
car" sort of thing, and doing it while it's being driven.  And successfully,
too.  So I will still recommend that engineers and developers spend time
evaluating it.  What language/IDE stands still anyway?  They all evolve.

> But this is my view.
> Now we have nice binding to invoke shell and other like subOSProcess.
> We should also progress on that front.

I was frustrated a bit at first, but then I found Christopher Fuhrman's page
on using 'LibC':
https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html
which shows how to "get a shell" on the host to run commands & access the
environment variables (including returning stdout, stderr, and the $? result
-- excellent).

That seems to cover most needs, but I'm not sure if this is the "standard
way to do it".  It does seem pretty powerful, though.

Then I found the "clap" project, https://github.com/cdlm/clap-st
and then "Scale", https://github.com/guillep/Scale

So I conclude that the ability is there, with more potential to be realized
as things evolve.

> To me Pharo is super good at manipulating complex data and object
> and building nice abstraction.

I get that!  Bash is terrible at this, but it's super good at blending
scripts with the OS evironment to make Userland tools work so seemlessly as
part of your custom code they seem to be elements of the language.  Now flip
that around: How does Pharo fare at OS/environment interaction?  We can't
operate in a vacuum (unless we build, what? Single-player games?)

> So I hope that you will not be disappointed.

So far, I'm not; I'm inspired, if anything.  Here's the list of what I
consider to be the ideal capabilities of any language/programming
environment, in increasing challenges.  (And keep in mind that I don't come
from a corporate IT background, shuttling & transforming data from cloud to
cloud; I build code to automate machines, devices, instruments, operating
systems, applications, processes, tools.. and every now & then processing
the data. :^)

1.) I want to have full host file system capabilities.  Not just read/write
files, but manipulating the file system.  Pharo seems to have this covered.

2.) I want to have good TCP/UDP capabilities.  I want to act as a server to
provide TCP sockets to connect to, act as a client and connect to servers
using TCP, and be able to read and write UDP packets easily.  Again, Pharo
seems to provide this nicely.

3.) I want to be able to interact with the OS, the host environment, and
tools and applications in the host.  This includes being able to launch,
monitor, and control processes -- and pass I/O in & out dynamically.  In
Bash, if I need complex pattern matching, I just "ask grep"; if I need
programmatic editing of a file, I just "tell sed to do it".  There's no
hoops to jump through, and nothing to set up.  Just "use the tool" and keep
coding...  I see ability here with Pharo.

4.) I want to be able to connect to compiled libraries of code and call them
easily -- so that I can interact with devices as well as export behavior to
pre-existing code.  This is the Pharo uFFI.  And I'll mention USB/serial use
here; device control is Pharo IOT I'm told.  I have yet to look at Pharo
IOT, but I will be doing so soon, just as I will be immersed with the uFFI
as I help with the docs and later the code.  So I know Pharo can do this,
too, yet it seems an area that's evolving.

5.) I want to be able to write applications that I can interact with from my
host's command line.  I want to write REPL apps, Linux filters, and the
like.  For example, I ought to be able to recreate 'grep' in Pharo (if I
wanted to go to the trouble. Not really, but I should be able to do it).
Most of my Bash and Lua scripts work at this level.  With Pharo..?  I'm not
sure how well this can work.

6.) I want to create apps that have a nice, professional-looking
mouse-driven GUI interface -- without the tedious nature of, say, Tk to
build them.  I know now that SpecUI answers that, to some degree of ease;
but I'm not sure yet how well, as I need to run a tutorial & play with it.
Pharo Launcher proves that these apps can be built.  So I wonder, "How hard
would it be to recreate Pharo Launcher?"  Because of course, I want to
deliver apps to my colleagues that work like running Pharo Launcher.  So
here it's a matter of "It can do it well, but how hard is it?"

7.) I want to create web apps, where my Pharo code, running in its
container, is reached by a web browser or another app's code, over sockets
(like accessing Docker microservices), whether it runs on the same host or a
remote host.  This is the ultimate -- it makes deployment, maintenance,
access, and so forth much easier, enables scaling, redundancy,
platform-independence, etc.  My customers want this, but I can't give it to
them currently.  I know that Pharo can do this, and do it well.  I like that
the cognitive burden of learning web programming is significantly reduced
with Pharo.  (Here's a suggestion for Pharo: Make Pharo easily capable of
plug-and-play in a Docker cluster.  I want to make/deploy microservices
built with Pharo, not Docker.  The IT world seems to be swinging towards
this, and if Pharo pursues this, perhaps it would be that breakout feature
it needs.)

8.) Finally, I want to be able to create the client-side
view/behavior/experience that my user sees and interacts with in a
browser-as-my-GUI.  I think this is Amber or PharoJS, and I know that this
the summit of the mountain and most likely a separate skill area.  I have
never wanted to learn JavaScript, CSS, etc. but one can never get far from
that, so I would leave this to the specialists.  But being able to give them
a Pharo environment to build these would be nice.  I have no idea how ideal
Amber/PharoJS is for making web pages...

Where I am now, I have at least one language/IDE that gives me all but the
last two capabilities on this list (and doesn't do #5 very well).  But my
primary IDE is closed-source and *expensive*.  (I can pay several thousand
more to a third-party vendor for an add-on that gives web control, but no
one here wants to pay for that, even though many ask for the capability.)  I
want an open-source, platform-independent IDE instead.

I started to think that Lua (with MANY add-on libraries) would cover enough
of these "desirements", but I've always wanted to work in that pure OOP
environment of Smalltalk.  So I'm encouraged at all I've seen, because Pharo
touches on all these capabilities.  Not all perfectly, of course, but many
very well.  

I don't think I'll be disappointed.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html