Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[eftomi]

Good observations! Shortcuts in general are shown under System > Keymap
browser. You can move from pane to pane with left and right arrows, this can
be set under Pharo Settings (ctrl-o-s). From methods pane you can even go to
the code editing pane (for the selected method) by pressing right arrow.

However, once you are there, you cannot move back, even if you assign a
different key combination to move between panes. Or is there a magic key
which can escape..?

Ctrl-f is now tied to 'Choose a class' action, it would be convenient if one
could jump to filter packages/classes directly from packages or classes
pane.

And a way to open subpackages ...

How to reach classes / instances etc radio buttons in the middle of Calypso
window is also unknown to me, although some of these modes are accessible
with certain key combinations - but not from the code editing pane.

If you navigate from the code editing pane to other tabs (ctrl-1 for the
first tab, ctrl-2 for the second etc), it's impossible to get the editing
pane properly selected again without the mouse.

> Pharo has been working to consolidate these - still ongoing.
> If someone can provide a lead in to the related definitions for Calypso's
> ,  & 
> perhaps experiment with it and propose a PR.

This would be great.




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Ben Coman]

On Sun, 27 Jan 2019 at 02:01, eftomi  wrote:

> > you can use it with the keyboard.
> > Using it, you do not require the mouse.
> > And, in addition, you do not need to remember complicated shortcuts:
> > Calypso and the tools of Pharo will > never be covered with shortcuts…
> > there are too many options.
> > So yes, it is not a replacement of the keyboard: is a way to USE the
> > keyboard in Calypso.
>

My little test...
  brings up the browser
Arrow keys scroll the Packages pane.
What I can't seem to do via keyboard is get to the "Filter..." input box
That could be useful.  Perhaps  from here could be re-purposed for
"Filter..."?

How many people currently use  from the Packages pane? (I never
have)

The next thing to determine is how to move to the Class pane.
 could be a good candidate?

Also,  currently opens an Inspector on the currently selected
package or class.
Is that a common requirement?   might be better used to cycle
between
the tabs in the bottom pane, which would align with common usage in web
browsers?

The above functional reassignments of ,  & 
could provide a reasonably good start to keyboard-only browser use.
Where can the current definitions of these for Calypso be found?


> Kkhmmm. I'll try to survive. I'm talking about moving left, right, up,
> down,
> choose/enter, escape - that kind of things, basic things. As I see from
> posts on various places (e. g. on stack overflow) this is an ongoing debate
> for years, about shortcuts defined in several places, text editor hijacking
> the keyboard, etc.


Pharo has been working to consolidate these - still ongoing.
If someone can provide a lead in to the related definitions for Calypso's
,  & 
perhaps experiment with it and propose a PR.

cheers -ben

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Hernán Morales Durand]

Kid you got my whole point wrong, I never said a word about IDE.

Cheers,

Hernán


El vie., 25 ene. 2019 a las 4:12, Dimitris Chloupis ()
escribió:

> I think you got this the wrong way
>
> Sure emacs and vim are very popular when compared to Pharo.
> When compared to IDEs oh boy , that's another story.
> There is a reason why their hardcore user are so desperate to call them
> IDEs and is not because they like IDEs, they dont.
> They hate IDEs.
>
> Text based coding, has lost  no my bad , let me correct this, text
> coding never stood chance. Smalltalk was like a nuclear bomb that when it
> landed it left nothing in its path,
> There is no doubt that nowdays IDEs dominating to a vast degree. Obviously
> big guns on top are Visual Studio (not Code) and Xcode by far for obvious
> reasons.
>
> Even in the case of my favorite IDE , Delphii its really amazing that even
> though its company has long disappeared, the all mighty Borland which one
> was the equivalent of Sun/Oracle.
> With only diffirent that obviously they were innovator. Even though
> outside Delphi absolutely none talks about Delphi.
> Delphi is surprisingly strong. Actually Delphis popularity is an
> undeniable proof how massively successful Smalltalk has been in its
> visual paradigm. Its company went to bankruptcy and the language was
> bought by a pretty much , even today, unknown company. The impact was that
> it went from 4th most popular to 12th most popular.
> Delphi even today is a formidable force for the Windows platform battling
> Go and freaking Swift who has the support of the most powerful company on
> the planet, Apple.There is no doubt in my mind
> that if Delphi was not such a massively loved IDE , being closed source
> which is a taboo for todays coding standards especially for a programming
> language, it would have been long dead.
>
> And lets not begin with scripting language which are basically dead.
> Python for example may be the 3rd most popular programming language but
> scripting wise has pretty much died.
> When it comes to the customisation of super advanced programs , the users
> has spoken loud and clear. They want visual coding and NOT text coding.
> 3 extremely complex fields , 3d graphics , Music and game development are
> dominated by Visual Coding languages. In Blender we offer both Python and
> Visual coding,
> guess what the users pick.
>
> Essentially one type of Visual Coding , node based visual coding.
>
> Also the time where visual coding was just for the users and not for the
> pros is long gone too after the massive success of Unreal's Blueprints.
> Which basically can do everything C++ can.
> Unreal's Blueprints is not even the first example of a visual language
> that will give a text language a run for its money. Softimage (3d app) ICE
> has been doing high performance coding decades ago.
> In music software we even have the insanity of visual language going down
> to low level, an I am not talking C++ or C , I mean real low level, old
> school Assembly code. Again decades ago.
>
> The users have spoken loud and clear and they have clearly stated they
> have no interest into investing the vast amount of wasted time that text
> coding requires.
>
> Even to learn how to code is dominated by Scratch. Just think about it, a
> language for kids dominates programming education.
> If you told that to a coder or even a user 20 years ago, he would have
> called you crazy and for a good reason.
>
> Text coding is only getting less and less popular by the year. I have no
> doubt at some point will completely disappear as did Assembly.
>
> So the biggest mistake of Smalltalk was not that it supported visual coding
>
> it was that it did not go visual coding all the way.
>
> It will have saved us the trouble of not being able to convince people to
> learn coding.
> Because people do not want to learn coding,
> And frankly I do not blame them.
>
> Visual coding is the only future of coding and Emac and Vim are relics of
> a past that has long gone.
> A despair attempt at nostalgia.
> On Fri, Jan 25, 2019 at 1:09 AM Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
>> El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe ()
>> escribió:
>>
>>>
>>>
>>> > On 24 Jan 2019, at 17:04, K K Subbu  wrote:
>>> >
>>> > On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
>>> >> Everybody is of course totally free to do whatever they want, but
>>> >> really, why the hell would you want to do that ?
>>> > Because text has many uses other than just feeding into a compiler for
>>> translation to machine code? People who come from Unix/Linux world are used
>>> to using a rich collection of tools that deal with text in various ways.
>>>
>>> I am myself a server/linux guy, an emacs user, I know what is all
>>> possible and what the unix philosophy is.
>>>
>>> I also know how to integrate Pharo into that world, and this is super
>>> important.
>>>
>>> >> You lose so much by doing that, I do not even know where 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[eftomi]

> you can use it with the keyboard. 
> Using it, you do not require the mouse. 
> And, in addition, you do not need to remember complicated shortcuts:
> Calypso and the tools of Pharo will > never be covered with shortcuts…
> there are too many options. 
> So yes, it is not a replacement of the keyboard: is a way to USE the
> keyboard in Calypso. 

Kkhmmm. I'll try to survive. I'm talking about moving left, right, up, down,
choose/enter, escape - that kind of things, basic things. As I see from
posts on various places (e. g. on stack overflow) this is an ongoing debate
for years, about shortcuts defined in several places, text editor hijacking
the keyboard, etc. 




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Esteban Lorenzano]

> On 26 Jan 2019, at 15:13, eftomi  wrote:
> 
>> cmd+h, then search for what you want (jump panels, execute commands,
> everything you can do in calypso you can find it there). 
> 
> Thanks. But Spotter can hardly be a replacement for the keyboard. Spotter is
> a marvel by itself, however please try to survive developing in Pharo for a
> minute without a mouse - or just jumping to different panes in Calypso,
> debugger and inspector. 

you can use it with the keyboard. 
Using it, you do not require the mouse. 
And, in addition, you do not need to remember complicated shortcuts: Calypso 
and the tools of Pharo will never be covered with shortcuts… there are too many 
options.
So yes, it is not a replacement of the keyboard: is a way to USE the keyboard 
in Calypso.

Now, maybe you tried to say using the keyboard to move between the different 
tools of Pharo.
There, yes you will need the mouse.


> 
> For instace, I checked all the shortcuts under ctrl-o-s. The shortcut
> ClySwitchFocusToPreviousBrowserPaneCommand>>fullBrowserShortcutActivation

Not all the shortcuts are perfect, but if you do ctrl+h and type “package” (the 
beginning of it, in fact), you will be able to jump to the package pane. 
Same for all the others, including the editors.
 
> should take you to the previous panel. It works for the top four panels, but
> not for the coding panel - or am I too clumsy? Furthermore, if you edit the
> code in Calypso, there are hidden shortcuts ctrl-1, ctrl-2, ctrl-3 etc.
> which take you to different tabs of the coding (bottom) panel. While editing
> the code, press ctrl-1 (this takes you to the Comment tab) and then go back
> to your code by using the keyboard. You can type in the code editor, however
> the panel is not selected (the blue frame is missing in the dark theme), and
> there is no cursor, so you are typing in the dark. And so forth.

As I said, not all the commands are correct (for example ctrl+2 is a special 
selection, it will not jump to the second pane).
But with ctrl+h spotter will let you find and jump to the tab you want.

> The problem is not people trying to edit the code in emacs, the problem is
> how to give them the experience which was already invented and works well.

With the exception of emacs, all other IDEs I know fail in letting you use the 
keyboard for everything. 
We are doing steps on the right direction, but I agree we are not perfect. 

Still. I recommend you to play with ctrl+h and the options there.

> There's no danger that Pharo will not be Pharo anymore, if we do that.
> Visual programming is not the mouse to click on the editor panels. And, in
> my opinion, a lot has already been done in this direction. I really don't
> understand all the fuss in this thread. 

The fuss in this thread is that you may criticise Pharo (and we know Pharo has 
many many problems). But wanting to code outside the environment is losing what 
makes Pharo an attractive option.
Without the environment, Pharo is just another dynamic language.
Wanting to avoid the environment just to use the tool you are used to is the 
bad approach. 
To program a C# application people uses visual studio. You can use notepad++ 
too, but nobody would think on doing it.

You know? It is possible to avoid completely the environment. Without much 
effort you can:

1. You edit the Tonel files with the editor you want.
2. You “compile your program”, which would be to file in the files.
3. You “run your program”, which would be to run the image.

This can be even improved! You can do a plugin on eclipse or IntelliJ that will 
match syntax color and maybe give you some autocompletion. 

Then you will be in the world you want, using your preferred IDE with you 
preferred shortcuts. 

But why then would you use Pharo?
There are TONS of languages there that work like that. 
Pharo is another beast… and its relevance is the IDE.

Esteban

> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[eftomi]

> cmd+h, then search for what you want (jump panels, execute commands,
everything you can do in calypso you can find it there). 

Thanks. But Spotter can hardly be a replacement for the keyboard. Spotter is
a marvel by itself, however please try to survive developing in Pharo for a
minute without a mouse - or just jumping to different panes in Calypso,
debugger and inspector. 

For instace, I checked all the shortcuts under ctrl-o-s. The shortcut
ClySwitchFocusToPreviousBrowserPaneCommand>>fullBrowserShortcutActivation
should take you to the previous panel. It works for the top four panels, but
not for the coding panel - or am I too clumsy? Furthermore, if you edit the
code in Calypso, there are hidden shortcuts ctrl-1, ctrl-2, ctrl-3 etc.
which take you to different tabs of the coding (bottom) panel. While editing
the code, press ctrl-1 (this takes you to the Comment tab) and then go back
to your code by using the keyboard. You can type in the code editor, however
the panel is not selected (the blue frame is missing in the dark theme), and
there is no cursor, so you are typing in the dark. And so forth.

The problem is not people trying to edit the code in emacs, the problem is
how to give them the experience which was already invented and works well.
There's no danger that Pharo will not be Pharo anymore, if we do that.
Visual programming is not the mouse to click on the editor panels. And, in
my opinion, a lot has already been done in this direction. I really don't
understand all the fuss in this thread. 





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"Abusing an external text editor is a slap in the face of anyone building
good tooling support into Smalltalk over many years.
I know Dimitris tried to help people (as often) - but I guess this video
really gives a false impression and guides people the wrong way."

Abusing ? Wait what on earth you talking about ?
How is using an external editor , abusing ?
Who is all mighty authority that says all these things ?
Is there a coder out there that can predict the needs and preferences of
every single coder ?
Last time I checked we edit text inside pharo , not bytecode.
Since when Smalltlak was not about source code, since when Smalltalk is not
about text ?
Oh sorry I forgot Pharo is not Smalltalk.

Yeah I guess I have never been religiously enslaved to any ideology or
belief and is true I do guide people the wrong way instead of taking
something at face value, because some authority says so, to use their
critical thinking and learn from their mistakes.

Yeah I guess my slap in the face of people build good tooling , is a stream
of videos that took me hours and hours to produce, that take newcomers by
hand and teach them step by step how to make tools in Pharo. Or
contributing to documentation because apparently building a good tooling
will magically transmit the knowledge to user heads.

My video is a problem and is not a problem that our documentation is still
lagging behind even when the most basic book is concerned Pharo By Example ?
My video is a problem and is not a problem that the vast majority of the
code inside Pharo does not even have class comments ?
My video is a problem and is not a problem that the image has been ridden
with feature creep and accumulating complexity that serves no purpose ?
My video is a problem and is not a problem that every time we talk about
new technologies everything , we have to be informed again and again
absolutely everything is inferior to Smalltalk ?
My video is a problem and is not a problem that every time one dares to
criticize Pharo or Smalltalk apparently we do not understand Smalltalk
while they understand other technologies ?

But worry not, the chances of me posting another video which were already
extremely low have certainly reached absolute zero.

I was planning to integrated an IPFS like system using bittorent protocol
inside Pharo so I can interconnect images of our entire community into one
universal virtual p2p image as a proof of concept for a commercial project
I am developing for Blender. Main use there will be to unify asset
management and code distribution in an image like fashion like happens in
Pharo.

https://ipfs.io/

But I guess this is also inferior to Smalltalk standards and a slap in the
face of anyone making good tooling in Pharo.

My hand got tired of slapping, I think I will take a break.


On Sat, Jan 26, 2019 at 10:10 AM Esteban Lorenzano 
wrote:

>
>
> > On 25 Jan 2019, at 20:52, Torsten Bergmann  wrote:
> >
> > Hi,
> >
> > Maybe Pharo's switch to Tonel remind people now on Java or C# class
> files and thats why they ask for the "traditional editing”.
>
> Nah, people talk about this time to time.
> Tonel format is just a readable format that yes, cool be used to edit in
> text files (but that was doable with chunk format too).
>
> For all the rest, +1 :)
>
> > But remember that Kent Beck once said: "I mean, source code in files;
> how quaint, how seventies!". Tonel is a readable storage format,
> > you could have the source code even in a database (with an ENVY and
> STORE like approach)
> >
> > And ouch  that video really hurts and I think it will be more
> disturbing than helpful especially to many newbees
> > now trying to use their favourite text editor for Pharo coding instead
> of really learning about a very flexible IDE and workflow with
> > browsing, interactively inspecting and refactorings.
> >
> > Abusing an external text editor is a slap in the face of anyone building
> good tooling support into Smalltalk over many years.
> > I know Dimitris tried to help people (as often) - but I guess this video
> really gives a false impression and guides people the wrong way.
> >
> > Sorry - but I'm reminded on pictures like this:
> >
> >
> https://i1.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagementcompanyblog.com/wp-content/uploads/2012/05/magnet-image-sws-one-no-border.gif
> >
> > Dont get me wrong: VisualStudio/VisualStudio Code, Eclipse, IntelliJ and
> others are nice, I use them too for other languages or tasks. Nicely done -
> but still
> > too static. Often I wished only half of the money invested into such
> IDE's could have been spend on better Smalltalk tooling.
> >
> > Remember: once VisualAge for Java got a price as the first usuable Java
> IDE (when people used Notepad to write *.java files) - but underneath it was
> > fully coded in Smalltalk and the Java debugger was the Smalltalk
> debugger running the java subset of bytecodes. At that time VisualAge for
> Smalltalk
> > was the base for the full 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Esteban Lorenzano]

> On 25 Jan 2019, at 21:45, eftomi  wrote:
> 
> Well, who am I to judge, but developers nowadays use tools which engage
> "muscle memory" to jump from one functionality of the editor to the other
> and developer brains are used to work on the problem at hand. All this to
> the extent that the mouse cannot be grasped with muscle memory alone and
> then the brain is interrupted. Roughly speaking. 

cmd+h, then search for what you want (jump panels, execute commands, everything 
you can do in calypso you can find it there).

> 
> I have a very practical question - is it possible to open Calypso, browse
> for a package that I forgot the name but will recall it when I see it,
> choose one of its classes, jump to its class methods, and start to edit one
> of them - all with the keyboard, without the mouse? I searched for all
> possible keystrokes but didn't find all the necessary keys to do all that.
> 
> I believe going into a more attractive direction for today's developers
> would not need too many resources, only a well thought set of shortcut
> commands and a couple of tiny details would do. If time permits me to
> contribute on that, I will.
> 
> 
> 
> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Esteban Lorenzano]

> On 25 Jan 2019, at 20:52, Torsten Bergmann  wrote:
> 
> Hi,
> 
> Maybe Pharo's switch to Tonel remind people now on Java or C# class files and 
> thats why they ask for the "traditional editing”.

Nah, people talk about this time to time. 
Tonel format is just a readable format that yes, cool be used to edit in text 
files (but that was doable with chunk format too).
 
For all the rest, +1 :)

> But remember that Kent Beck once said: "I mean, source code in files; how 
> quaint, how seventies!". Tonel is a readable storage format,
> you could have the source code even in a database (with an ENVY and STORE 
> like approach) 
> 
> And ouch  that video really hurts and I think it will be more disturbing 
> than helpful especially to many newbees
> now trying to use their favourite text editor for Pharo coding instead of 
> really learning about a very flexible IDE and workflow with
> browsing, interactively inspecting and refactorings.
> 
> Abusing an external text editor is a slap in the face of anyone building good 
> tooling support into Smalltalk over many years. 
> I know Dimitris tried to help people (as often) - but I guess this video 
> really gives a false impression and guides people the wrong way.
>  
> Sorry - but I'm reminded on pictures like this:
>  
>   
> https://i1.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagementcompanyblog.com/wp-content/uploads/2012/05/magnet-image-sws-one-no-border.gif
> 
> Dont get me wrong: VisualStudio/VisualStudio Code, Eclipse, IntelliJ and 
> others are nice, I use them too for other languages or tasks. Nicely done - 
> but still
> too static. Often I wished only half of the money invested into such IDE's 
> could have been spend on better Smalltalk tooling.
>  
> Remember: once VisualAge for Java got a price as the first usuable Java IDE 
> (when people used Notepad to write *.java files) - but underneath it was
> fully coded in Smalltalk and the Java debugger was the Smalltalk debugger 
> running the java subset of bytecodes. At that time VisualAge for Smalltalk
> was the base for the full VisualAge series (VisualAge for Java, Visual Age 
> for C++ and others).
> 
> But Smalltalk at that time unfortunately was expensive, licensing a problem 
> and big vendors had to prove one can do deliver similar things with Java too 
> - leading 
> to Eclipse and others. But the best part on Eclipse was not Java - it was the 
> pluggability concept. The extension point mechanisms of the platform provide
> a clear separation leading to a nice ecosystem of available plugins - but 
> still it is hard to write and debug a custom extension. 
> 
> A Smalltalk environment is still more dynamic, more lively where you can 
> browse, inspect and adjust nearly anything. And yes - you can even shoot 
> yourself in the foot.
> And yes we know Pharo does not provide fancy widgets yet or latest text 
> editing features - but this is a tribute to community resources. 
> 
> From my experience: if one free's his mind and gives up traditional 
> programming habits learned in mainstream languages he will enjoy the Pharo 
> journey 
> much more.
> 
> Bye
> T.
>   
> 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Imran Rafique]

Imran said:
> No matter how you setup your smalltalk, at some point, you have to
> talk to your system. Tell it to subclass Object because I want to add
> a new class. Or add a new method to an existing class. Or just execute
> this code right now, as is (Workspace/Playground). Etc, etc.

Richard said:
> The "system" isn't an object. It is a collaborative network of objects. You
> don't tell the /system/ to subclass Object, you tell /Object/ to define the
> subclass.

Huh? Thats not what I said (I realise this is getting close to
pedantic bikeshedding at this stage, but anyway ...):

1. System = the entire programming runtime

2. Tell it = send some text to that system, to consider it for execution

3. The "system" receives the text (somehow), parses it, and realises
its a message send to Object.

4. It sends the message to Object, and Object figures out what to do
(create a new class)

I wasn't trying to imply anything different. The important thing I was
getting at was "tell it".

Thats where the whole breakdown comes in this internal vs external
editing debate. And thats why I highlighted it.

That "tell it" part is just the transmission, by any means possible,
of dumb text to ... the system.

Too often that gets intertwined with "live objects all the way", when
in reality, I don't think it has anything to do with that aspect.

At this point, you're just flinging ascii/unicode bytes around. Its
only once the "system" gets those bytes, and parses it as "oh, you
want to send this message, with these arguments, to that object? Ok,
gotcha!"

The advantage of initially creating that "dumb text" from tools
running inside the image is that there should be a near-zero usabilty
delay in delivering this "dumb text" to the system. No saving to disk.
No loading from disk. Etc.

But as long as you realise that, at this stage, you **are** just
dealing with dumb text, then its equally plausible to create methods
of creating and delivering that dumb text, from outside the image, to
the system (inside the image).

Without having to save to disk. Reload from disk. Etc. In other words
- meet the same usability requirements.

That "dumb text" only has anything to do with objects, liveness etc
**once** the system gets it and parses it. Everything I was talking
about is **before** that stage.

Ok, so all of the above is pedantantry-gone-wild. But I think the
following gets to the crux of it.

Imran said:
> So, in a real sense, does it matter where you enter that dumb, simple,
> plain text?

Richard said:
> Yes, it does matter. When every keystroke changes the meaning of that "dumb,
> simple, plain text", yes, it matters.
>
> There are Smalltalk text editors that insert annotations into the text being
> presented to communicate information to you,

You're bringing up advanced code completion as a difference. Well, err, no.

You just need a constantly available backchannel of communication with
the system. To send a potentially incomplete chunk of text and ask it
"hey, what do you think he meant to say here?". Take that, and present
it to the user.

Upon every keystroke (if you like, that would drive me batty but to
each his own).

Lisp runtimes do this kind of thing all the time. Smalltalk can do
this too. Why can't it?

Recall the example I gave originally. It wasn't a braindead: Write in
this editor. Save it. Go to the image. Load it. Rinse. Repeat.

It was more: Write in this editor. Save it. It gets sent automatically
to the system. System does something.

Thats not confined to a single pseudo-file (with fuse or other
pseudo-filelike systems, the file metaphor is just an abstraction over
disk-less, instant communication between different processes).

You can have multiple pseudo-files giving and sending msgs about
various aspects.

Including "hey, based on what you're typing, I think this is the full
name". Or more complex reporting (variables, that method you just
referenced has the following arguments, etc)

None of this, absolutely NONE of this, requires having the text editor
be INSIDE the system to start with.

Of course, it **does** require an editor with more smarts than notepad. But:

- acme (my preference, so easy to integrate with out-of-process tools)
- emacs (but it likes pulling as much as possible inside its own process)
- even neovim, with is asynchronous communication facilities (but
still somewhat clunky, compared to the other two)

They're all capable.

Whats needed is the tooling to facilitate the ongoing communications
to and from the smalltalk system.

Like Craig Latta's webdav interface, as one example.

Why bother? Well, it depends on how you look at it, I suppose.

Is it easier to provide the background interface, and let others
connect it to a multitude of programmable editors who are capable on
ongoing asynchronous comms while editing?

All I'm saying is that its a valid approach, which doesn't (IMO, of
course) contravenes the "live environment" paradigm.

> The people at feenk.com have shown an 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Richard Sargent]

isr wrote
> I'm a long-time lurker on this list, and still more of an
> intermediate-squeaker (is that a word?) rather than pharo (although I
> have used this off and on since pharo-5), so I feel like a bit of an
> imposter jumping into this thread (long-time lisper).

Like you, I am primarily a lurker in the Pharo lists. Some of your comments
below I agree with and some I don't. I hope can explain clearly enough why I
don't. I've been fortunate enough to work in Smalltalk exclusively since
late 1991. Each year that goes by sees me gain a new and deeper
understanding. Things I thought I new well turn out to have much more to
them than I previously thought, even after multiple "rinse and repeat"
cycles.


> That said, and without wishing to ruffle any feathers nor cause any
> rancour (if I do, I apologise), may I humbly disagree with some of the
> opinions mentioned by some certainly more accomplished Smalltalkers
> than me.
> 
> Sven said:
>> Everybody is of course totally free to do whatever they want, but really,
>> why the hell would you want to do that ?
>> You lose so much by doing that, I do not even know where to start.
>> A big part of what makes Pharo (or any Smalltalk) special is the IDE
>> written in itself.
> 
> Esteban said:
>> Honestly, Pharo without the environment (and the “live objects” approach)
>> is just another dynamic language without much interest.
> 
> There's a distinction between "how you enter source code" and "the
> full live object environment" paradigm.
> 
> No matter how you setup your smalltalk, at some point, you have to
> talk to your system. Tell it to subclass Object because I want to add
> a new class. Or add a new method to an existing class. Or just execute
> this code right now, as is (Workspace/Playground). Etc, etc.

The "system" isn't an object. It is a collaborative network of objects. You
don't tell the /system/ to subclass Object, you tell /Object/ to define the
subclass.

To help provide a more complete context, let's go back to the beginning to
what Goldberg and Robson said in their preface to /Smalltalk-80 The Language
and Its Implementation/.
"Smalltalk is designed so that every component in the system that is
accessible to the user can be presented in a meaningful way for observation
and manipulation."

As developers, we are users and subject to the same goals and ambitions.
Observation for us is navigating the code to understand while manipulation
for us is producing new code (or changed code). But, keep in mind that the
word manipulation means a lot more than just writing.



> There are numerous text editor widgets sprinkled throughout
> squeak/cuis/pharo's set of "tools" which enable you to do exactly that
> - talk to the system.
> 
> These various editor widgets distinguish themselves slightly by
> binding Self to something convenient (in the browser, for example),
> but other than that - they're just text widgets.
> 
> The magic only happens once you take the text, and tell the system to
> **do something with it**. Save, Do-it, print-it, etc.
> 
> Up to that point, its just text. Dumb, simple, plain text.

That's only true because you have chosen it to be. And that is the crux of
this whole discussion. Dead bits are useless. Smalltalk is about live
objects. (As I said, it took me a long time to really, deeply understand
that. And I still see someone come along and prove me wrong. Wrong in the
sense that I didn't understand it nearly as well as I thought. Someone shows
the world an idea and my understanding takes an octave jump.)



> So, in a real sense, does it matter where you enter that dumb, simple,
> plain text?

Yes, it does matter. When every keystroke changes the meaning of that "dumb,
simple, plain text", yes, it matters.

There are Smalltalk text editors that insert annotations into the text being
presented to communicate information to you, from as simple as indicating a
declared variable is unused or an expression references an undefined
variable, to more complex concepts.

There are Smalltalk editors that know what potential receivers implement
selectors and variables (including globally accessible objects) matching
what you have typed so far and can offer you suggestions, including spelling
corrections, as you type.



> As long as there is an immediate, simple, failsafe way to sending that
> text to the system to "do something with me", then you still have the
> same live environment. Surely?

How can it be? Live, yes, for some definition of live. But, lively? Not so.

(The people at feenk.com have shown an entirely new level of liveliness that
I find simply fascinating. Each new thing rings with an echo of "What will
they think of next?" coupled with "I can't wait to see what they think of
next!".)



> At that point, it doesn't matter (from the point of view of having a
> "live system") whether the dumb, simple, plain text was initially
> entered, from keyboard to screen, via the smalltalk process or another
> external process.
> 
> 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[eftomi]

Well, who am I to judge, but developers nowadays use tools which engage
"muscle memory" to jump from one functionality of the editor to the other
and developer brains are used to work on the problem at hand. All this to
the extent that the mouse cannot be grasped with muscle memory alone and
then the brain is interrupted. Roughly speaking. 

I have a very practical question - is it possible to open Calypso, browse
for a package that I forgot the name but will recall it when I see it,
choose one of its classes, jump to its class methods, and start to edit one
of them - all with the keyboard, without the mouse? I searched for all
possible keystrokes but didn't find all the necessary keys to do all that.

I believe going into a more attractive direction for today's developers
would not need too many resources, only a well thought set of shortcut
commands and a couple of tiny details would do. If time permits me to
contribute on that, I will.







--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Sven Van Caekenberghe]

Well written, well said, Torsten, exactly my point.

> On 25 Jan 2019, at 20:52, Torsten Bergmann  wrote:
> 
> Hi,
> 
> Maybe Pharo's switch to Tonel remind people now on Java or C# class files and 
> thats why they ask for the "traditional editing".
> But remember that Kent Beck once said: "I mean, source code in files; how 
> quaint, how seventies!". Tonel is a readable storage format,
> you could have the source code even in a database (with an ENVY and STORE 
> like approach) 
> 
> And ouch  that video really hurts and I think it will be more disturbing 
> than helpful especially to many newbees
> now trying to use their favourite text editor for Pharo coding instead of 
> really learning about a very flexible IDE and workflow with
> browsing, interactively inspecting and refactorings.
> 
> Abusing an external text editor is a slap in the face of anyone building good 
> tooling support into Smalltalk over many years. 
> I know Dimitris tried to help people (as often) - but I guess this video 
> really gives a false impression and guides people the wrong way.
>  
> Sorry - but I'm reminded on pictures like this:
>  
>   
> https://i1.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagementcompanyblog.com/wp-content/uploads/2012/05/magnet-image-sws-one-no-border.gif
> 
> Dont get me wrong: VisualStudio/VisualStudio Code, Eclipse, IntelliJ and 
> others are nice, I use them too for other languages or tasks. Nicely done - 
> but still
> too static. Often I wished only half of the money invested into such IDE's 
> could have been spend on better Smalltalk tooling.
>  
> Remember: once VisualAge for Java got a price as the first usuable Java IDE 
> (when people used Notepad to write *.java files) - but underneath it was
> fully coded in Smalltalk and the Java debugger was the Smalltalk debugger 
> running the java subset of bytecodes. At that time VisualAge for Smalltalk
> was the base for the full VisualAge series (VisualAge for Java, Visual Age 
> for C++ and others).
> 
> But Smalltalk at that time unfortunately was expensive, licensing a problem 
> and big vendors had to prove one can do deliver similar things with Java too 
> - leading 
> to Eclipse and others. But the best part on Eclipse was not Java - it was the 
> pluggability concept. The extension point mechanisms of the platform provide
> a clear separation leading to a nice ecosystem of available plugins - but 
> still it is hard to write and debug a custom extension. 
> 
> A Smalltalk environment is still more dynamic, more lively where you can 
> browse, inspect and adjust nearly anything. And yes - you can even shoot 
> yourself in the foot.
> And yes we know Pharo does not provide fancy widgets yet or latest text 
> editing features - but this is a tribute to community resources. 
> 
> From my experience: if one free's his mind and gives up traditional 
> programming habits learned in mainstream languages he will enjoy the Pharo 
> journey 
> much more.
> 
> Bye
> T.
>   
> 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Torsten Bergmann]

Hi,

Maybe Pharo's switch to Tonel remind people now on Java or C# class files and 
thats why they ask for the "traditional editing".
But remember that Kent Beck once said: "I mean, source code in files; how 
quaint, how seventies!". Tonel is a readable storage format,
you could have the source code even in a database (with an ENVY and STORE like 
approach) 

And ouch  that video really hurts and I think it will be more disturbing 
than helpful especially to many newbees
now trying to use their favourite text editor for Pharo coding instead of 
really learning about a very flexible IDE and workflow with
browsing, interactively inspecting and refactorings.

Abusing an external text editor is a slap in the face of anyone building good 
tooling support into Smalltalk over many years. 
I know Dimitris tried to help people (as often) - but I guess this video really 
gives a false impression and guides people the wrong way.
 
Sorry - but I'm reminded on pictures like this:
 
  
https://i1.wp.com/ecbiz168.inmotionhosting.com/~perfor21/performancemanagementcompanyblog.com/wp-content/uploads/2012/05/magnet-image-sws-one-no-border.gif

Dont get me wrong: VisualStudio/VisualStudio Code, Eclipse, IntelliJ and others 
are nice, I use them too for other languages or tasks. Nicely done - but still
too static. Often I wished only half of the money invested into such IDE's 
could have been spend on better Smalltalk tooling.
 
Remember: once VisualAge for Java got a price as the first usuable Java IDE 
(when people used Notepad to write *.java files) - but underneath it was
fully coded in Smalltalk and the Java debugger was the Smalltalk debugger 
running the java subset of bytecodes. At that time VisualAge for Smalltalk
was the base for the full VisualAge series (VisualAge for Java, Visual Age for 
C++ and others).

But Smalltalk at that time unfortunately was expensive, licensing a problem and 
big vendors had to prove one can do deliver similar things with Java too - 
leading 
to Eclipse and others. But the best part on Eclipse was not Java - it was the 
pluggability concept. The extension point mechanisms of the platform provide
a clear separation leading to a nice ecosystem of available plugins - but still 
it is hard to write and debug a custom extension. 

A Smalltalk environment is still more dynamic, more lively where you can 
browse, inspect and adjust nearly anything. And yes - you can even shoot 
yourself in the foot.
And yes we know Pharo does not provide fancy widgets yet or latest text editing 
features - but this is a tribute to community resources. 

>From my experience: if one free's his mind and gives up traditional 
>programming habits learned in mainstream languages he will enjoy the Pharo 
>journey 
much more.

Bye
T.
                      

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Denis Kudriashov]

Hi.

Now settings browser includes all Commander based shortcuts which is all
calypso and Iceberg shortcuts in current image.

In addition there is a special spotter menu in Calypso to find any
available command (not only shortcut based).

пт, 25 янв. 2019 г., 15:45 Tim Mackinnon tim@testit.works:

>
>
> On 25 Jan 2019, at 13:36, Esteban Maringolo  wrote:
>
> I think this feature is so convenient that it should not only be
> visible, but have a menu item of its own.
>
>
> It did originally have a menu entry - however when PR’d I agreed with
> Denis to take it out as it kind of cluttered the context menu.
>
> The old Nautilus had a keystrokes menu that listed them all for you - but
> I think we have lost that in Calypso? There are some that appear in the
> settings, but I’m not sure its all of them.
>
> Tim
>

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Tim Mackinnon]

> On 25 Jan 2019, at 13:36, Esteban Maringolo  wrote:
> 
> I think this feature is so convenient that it should not only be
> visible, but have a menu item of its own.

It did originally have a menu entry - however when PR’d I agreed with Denis to 
take it out as it kind of cluttered the context menu. 

The old Nautilus had a keystrokes menu that listed them all for you - but I 
think we have lost that in Calypso? There are some that appear in the settings, 
but I’m not sure its all of them.

Tim

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Esteban Maringolo]

El vie., 25 ene. 2019 a las 10:36, Esteban Maringolo
() escribió:
>
> El vie., 25 ene. 2019 a las 8:01, Sven Van Caekenberghe
> () escribió:
> > > On 25 Jan 2019, at 11:34, Tim Mackinnon  wrote:
>
> > > Similarly, you might not also realise that can also use META-2 to 
> > > intelligently select wider portions of code
> > WOW, wow, very nice !

> But what key is "Meta-2" in Windows?

Answering myself it is not "meta two" (as I read it), but is "Meta+2",
which in Windows it is [Ctrl]+[2]

Regards!

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Esteban Maringolo]

El vie., 25 ene. 2019 a las 8:01, Sven Van Caekenberghe
() escribió:
> > On 25 Jan 2019, at 11:34, Tim Mackinnon  wrote:

> > Similarly, you might not also realise that can also use META-2 to 
> > intelligently select wider portions of code - which is great for 
> > refactoring or correcting a mistake (e.g. put your cursor inside a comment 
> > and press META-2). Repeatedly doing this will expand the selection (great 
> > inside a block of code). Again - this is the power of an intelligent 
> > environment. It also doesn’t take a lot of code and it was something I 
> > taught myself because our environment is so discoverable.
>
> WOW, wow, very nice !

This is so convenient! In particular when dealing with nested blocks
for rendering Seaside tags. :)
But what key is "Meta-2" in Windows?

I think this feature is so convenient that it should not only be
visible, but have a menu item of its own.

> There are so many hidden gems inside Pharo that it is impossible to keep 
> track. People should not only add such features, but also continuously 
> advocate/advertise them, it really takes a long time before everybody knows 
> about new stuff.

We need a cheatsheet of some sort :)

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[eftomi]

That's what I'm talking about! I doesn't have to be heavy resources, just a
directed evolution 

What's the proverb? - The laziness is the greatest inventor 

Can you suggest any starting points to discover these background concepts
for a novice like me?




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Sven Van Caekenberghe]

> On 25 Jan 2019, at 11:34, Tim Mackinnon  wrote:
> 
> As an aside - we can all make the editing tools better (e.g. borrow things 
> from VIM or Emacs) - I know I added a small feature in P7 (that possibly not 
> many realise) where you can now click anywhere on message (and not have to 
> highlight all of it) and browse senders/implementers (e.g. meta-M). This is 
> made possible because our tools are not simply text (like VIM/Emacs) - you 
> have the full AST at hand and can reason on the code and your cursor 
> locations.
> 
> Similarly, you might not also realise that can also use META-2 to 
> intelligently select wider portions of code - which is great for refactoring 
> or correcting a mistake (e.g. put your cursor inside a comment and press 
> META-2). Repeatedly doing this will expand the selection (great inside a 
> block of code). Again - this is the power of an intelligent environment. It 
> also doesn’t take a lot of code and it was something I taught myself because 
> our environment is so discoverable.

WOW, wow, very nice !

Thank you.

There are so many hidden gems inside Pharo that it is impossible to keep track. 
People should not only add such features, but also continuously 
advocate/advertise them, it really takes a long time before everybody knows 
about new stuff.

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Tim Mackinnon]

> On 25 Jan 2019, at 09:24, eftomi  wrote:
> 
> When there is a question about editing the code, we can look for the
> philosophies of other editors/IDEs. For instance,  authors of VSCode are
> saying  >   "First and
> foremost, it is an editor that gets out of your way. The delightfully
> frictionless edit-build-debug cycle means less time fiddling with your
> environment, and more time executing on your ideas."  
> 
> How far away from this idea is Pharo, if we compare both worlds? Pharo is an
> OS, IDE, editor and a language - but can we make it to get out of our way in
> the sense of developers' effort expectancy?

We can of course argue about all of this for a long time - I think Sven nailed 
it though -  people can do what they want (its OSS and its ours). You don’t 
have to use the editor in Pharo and you can edit Tonel in a text editor and 
commit it via git (I have to confess, when messing around with a pet project 
hooked up to a GitLab CI system, this was convenient when using an iPhone on 
the train for quick tweaks to try out an idea without a laptop. I don’t think I 
would want to program this way all the time though).

HOWEVER - I don’t think we have the resources necessary to do a great job of a 
traditional environment and an awesome job on a future looking environment (the 
latter being where we have the hearts and minds, and also really differentiate 
ourselves). Of course - if there are folks that are passionate enough to go 
away and do this really well - then I don’t think anyone would stop them.  

BUT I wouldn’t want to see some of our best resources spend time on this. I 
would like to improve the tools we’ve got (I’m loving the inspiration for the 
Feenk guys).

I would prefer the we make our integrated editor better, as well as keep 
pressing on Calypso (its better but still needs more work), and keep improving 
git integration as well as the compiler and some of the reification of things 
that we keep doing.

As an aside - we can all make the editing tools better (e.g. borrow things from 
VIM or Emacs) - I know I added a small feature in P7 (that possibly not many 
realise) where you can now click anywhere on message (and not have to highlight 
all of it) and browse senders/implementers (e.g. meta-M). This is made possible 
because our tools are not simply text (like VIM/Emacs) - you have the full AST 
at hand and can reason on the code and your cursor locations.

Similarly, you might not also realise that can also use META-2 to intelligently 
select wider portions of code - which is great for refactoring or correcting a 
mistake (e.g. put your cursor inside a comment and press META-2). Repeatedly 
doing this will expand the selection (great inside a block of code). Again - 
this is the power of an intelligent environment. It also doesn’t take a lot of 
code and it was something I taught myself because our environment is so 
discoverable.

I do think we can extend Calypso to show code in a less confined way - I too am 
not so keen on seeing only one method or flipping between class/instance - but 
again our tools are malleable and great at exploring these ideas (and I believe 
the Calypso model actually supports this experimentation - but I will find out, 
as that is the itch I want to scratch next).

Tim

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Jose San Leandro]

There's one thing in our brains called "amigdala". It's the reason we can
be efficient.
Using the mouse bypasses the amigdala completely. Everything is conscious.
Well, unless if you're Rapha playing Quake Champions.

I'm not sure if your argument about Visual Coding implies using the mouse.
I think maybe what you refer as Visual Coding is an imperfect
implementation of Bret Victor's DynamicLand.
I think he might be right.

Anyway, while coding we do two tasks: thinking, and making changes in the
image so that it behaves the way we want. While thinking, and designing,
the amigdala is not used. I still think using the mouse to explore is
distracting.
That's why I use Tiled desktop managers: they save me from the distraction.
I have absolutely no interest in organizing the windows on the desktop. The
windows are the mean, not the end.

Regarding the argument that Visual Coding is winning, that doesn't mean
it's good news. Have you read "Bad ass users"? I fully support that
approach. Visual coding seems to be great softening the learning curve. But
I doubt it makes people better as coders.
In my case, I feel I'm improving whenever I understand what it's happening.
Many times you get results that seem to contradict your expectations.
Whenever that happens, I debug until I find out what's actually happening.
If I use Visual Coding, at some point the information must be unhidden.

I don't have anything against Visual Coding. But I've benefited a lot from
learning touch typing, learning Dvorak, using a letter-less keyboard, and
learning the basics of Emacs. A lot. If the promise of Visual Coding is
"you don't need any of that", I think it's a false promise. You can move
nodes to save space for some time, until you learn a keybinding (or wish it
existed) and do it automatically.
That's what I want to have in Pharo.

"Bad ass users" is the antidote against the UX oversimplification we live
by, that confines as first-time users.

El vie., 25 ene. 2019 a las 8:12, Dimitris Chloupis ()
escribió:

> I think you got this the wrong way
>
> Sure emacs and vim are very popular when compared to Pharo.
> When compared to IDEs oh boy , that's another story.
> There is a reason why their hardcore user are so desperate to call them
> IDEs and is not because they like IDEs, they dont.
> They hate IDEs.
>
> Text based coding, has lost  no my bad , let me correct this, text
> coding never stood chance. Smalltalk was like a nuclear bomb that when it
> landed it left nothing in its path,
> There is no doubt that nowdays IDEs dominating to a vast degree. Obviously
> big guns on top are Visual Studio (not Code) and Xcode by far for obvious
> reasons.
>
> Even in the case of my favorite IDE , Delphii its really amazing that even
> though its company has long disappeared, the all mighty Borland which one
> was the equivalent of Sun/Oracle.
> With only diffirent that obviously they were innovator. Even though
> outside Delphi absolutely none talks about Delphi.
> Delphi is surprisingly strong. Actually Delphis popularity is an
> undeniable proof how massively successful Smalltalk has been in its
> visual paradigm. Its company went to bankruptcy and the language was
> bought by a pretty much , even today, unknown company. The impact was that
> it went from 4th most popular to 12th most popular.
> Delphi even today is a formidable force for the Windows platform battling
> Go and freaking Swift who has the support of the most powerful company on
> the planet, Apple.There is no doubt in my mind
> that if Delphi was not such a massively loved IDE , being closed source
> which is a taboo for todays coding standards especially for a programming
> language, it would have been long dead.
>
> And lets not begin with scripting language which are basically dead.
> Python for example may be the 3rd most popular programming language but
> scripting wise has pretty much died.
> When it comes to the customisation of super advanced programs , the users
> has spoken loud and clear. They want visual coding and NOT text coding.
> 3 extremely complex fields , 3d graphics , Music and game development are
> dominated by Visual Coding languages. In Blender we offer both Python and
> Visual coding,
> guess what the users pick.
>
> Essentially one type of Visual Coding , node based visual coding.
>
> Also the time where visual coding was just for the users and not for the
> pros is long gone too after the massive success of Unreal's Blueprints.
> Which basically can do everything C++ can.
> Unreal's Blueprints is not even the first example of a visual language
> that will give a text language a run for its money. Softimage (3d app) ICE
> has been doing high performance coding decades ago.
> In music software we even have the insanity of visual language going down
> to low level, an I am not talking C++ or C , I mean real low level, old
> school Assembly code. Again decades ago.
>
> The users have spoken loud and clear and they have clearly stated they
> have 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[eftomi]

Dear all,

I'm a Pharo novice, in the middle of a self paced Pharo MOOC, with years of
experence going from Turbo C on DOS over Visual Studio and Eclipse to Visual
Studio Code in last years. Besides, I'm a professor and a researcher of IT
adoption, so here's my two cents contributing to this very interesting
debate. 

Developers are users, and (potential) users decide upon four things:
- expected performance of a tool (what a tool can do and what it represents)
- user effort expectancy while learning (i.e. learning curve) and using the
tool 
- social influence (i.e. what other developers are doing, saying and
collaborating with)
- facilitating conditions (support, i.e. strong & helping community,
tutorials, user manuals)

We can discuss and rant about which language or a tool is better of worse in
a caffee (like complaining about the weather or our bosses), however for a
progress and good decisions it is necessary that we forget about our
personal feelings and preferences.

There is no doubt, Pharo delivers many new, stunningly innovative and
revolutionary approaches, and all the efforts of its developers are
worthwhile and greatly appreciated. 

When there is a question about editing the code, we can look for the
philosophies of other editors/IDEs. For instance,  authors of VSCode are
saying    "First and
foremost, it is an editor that gets out of your way. The delightfully
frictionless edit-build-debug cycle means less time fiddling with your
environment, and more time executing on your ideas."  

How far away from this idea is Pharo, if we compare both worlds? Pharo is an
OS, IDE, editor and a language - but can we make it to get out of our way in
the sense of developers' effort expectancy?

Maybe we don't need anything special to go into this direction. Just a
couple more of keystrokes to directly support edit-build-debug and TDD
development cycles and some work on the "console like feeling" when
interacting in Pharo. The dark theme is great, btw :-)

I think that a wish to directly edit the .st files comes from the fact that
other editors and IDEs are "linear" by design - we edit flat files with
them, and these files (modules) are longer than a typical method in Pharo. A
developer focuses on the method/function at hand, however she just has to
scroll up and down to reach other methods/functions within a module, while
in Pharo you typically grab your mouse and browse with the class browser.
Can a couple of keystrokes be a solution?

So, my proposal is that we forget about our personal feelings and
preferences, and think outside the box - which is a Pharo domain, after all!
 





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

I think you got this the wrong way

Sure emacs and vim are very popular when compared to Pharo.
When compared to IDEs oh boy , that's another story.
There is a reason why their hardcore user are so desperate to call them
IDEs and is not because they like IDEs, they dont.
They hate IDEs.

Text based coding, has lost  no my bad , let me correct this, text
coding never stood chance. Smalltalk was like a nuclear bomb that when it
landed it left nothing in its path,
There is no doubt that nowdays IDEs dominating to a vast degree. Obviously
big guns on top are Visual Studio (not Code) and Xcode by far for obvious
reasons.

Even in the case of my favorite IDE , Delphii its really amazing that even
though its company has long disappeared, the all mighty Borland which one
was the equivalent of Sun/Oracle.
With only diffirent that obviously they were innovator. Even though outside
Delphi absolutely none talks about Delphi.
Delphi is surprisingly strong. Actually Delphis popularity is an undeniable
proof how massively successful Smalltalk has been in its
visual paradigm. Its company went to bankruptcy and the language was bought
by a pretty much , even today, unknown company. The impact was that it went
from 4th most popular to 12th most popular.
Delphi even today is a formidable force for the Windows platform battling
Go and freaking Swift who has the support of the most powerful company on
the planet, Apple.There is no doubt in my mind
that if Delphi was not such a massively loved IDE , being closed source
which is a taboo for todays coding standards especially for a programming
language, it would have been long dead.

And lets not begin with scripting language which are basically dead. Python
for example may be the 3rd most popular programming language but scripting
wise has pretty much died.
When it comes to the customisation of super advanced programs , the users
has spoken loud and clear. They want visual coding and NOT text coding.
3 extremely complex fields , 3d graphics , Music and game development are
dominated by Visual Coding languages. In Blender we offer both Python and
Visual coding,
guess what the users pick.

Essentially one type of Visual Coding , node based visual coding.

Also the time where visual coding was just for the users and not for the
pros is long gone too after the massive success of Unreal's Blueprints.
Which basically can do everything C++ can.
Unreal's Blueprints is not even the first example of a visual language that
will give a text language a run for its money. Softimage (3d app) ICE has
been doing high performance coding decades ago.
In music software we even have the insanity of visual language going down
to low level, an I am not talking C++ or C , I mean real low level, old
school Assembly code. Again decades ago.

The users have spoken loud and clear and they have clearly stated they have
no interest into investing the vast amount of wasted time that text coding
requires.

Even to learn how to code is dominated by Scratch. Just think about it, a
language for kids dominates programming education.
If you told that to a coder or even a user 20 years ago, he would have
called you crazy and for a good reason.

Text coding is only getting less and less popular by the year. I have no
doubt at some point will completely disappear as did Assembly.

So the biggest mistake of Smalltalk was not that it supported visual coding

it was that it did not go visual coding all the way.

It will have saved us the trouble of not being able to convince people to
learn coding.
Because people do not want to learn coding,
And frankly I do not blame them.

Visual coding is the only future of coding and Emac and Vim are relics of a
past that has long gone.
A despair attempt at nostalgia.
On Fri, Jan 25, 2019 at 1:09 AM Hernán Morales Durand <
hernan.mora...@gmail.com> wrote:

> El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe ()
> escribió:
>
>>
>>
>> > On 24 Jan 2019, at 17:04, K K Subbu  wrote:
>> >
>> > On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
>> >> Everybody is of course totally free to do whatever they want, but
>> >> really, why the hell would you want to do that ?
>> > Because text has many uses other than just feeding into a compiler for
>> translation to machine code? People who come from Unix/Linux world are used
>> to using a rich collection of tools that deal with text in various ways.
>>
>> I am myself a server/linux guy, an emacs user, I know what is all
>> possible and what the unix philosophy is.
>>
>> I also know how to integrate Pharo into that world, and this is super
>> important.
>>
>> >> You lose so much by doing that, I do not even know where to start.
>> >
>> > Live coding (i.e. coding in the presence of instances) is undoubtedly
>> more powerful than edit-compile-run cycle. Text is used to direct IDE to
>> edit live objects. But text has many more uses than just issuing commands.
>> If beginners start using vim just to edit code due to established 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Pierce Ng]

On Thu, Jan 24, 2019 at 08:29:46PM +0530, K K Subbu wrote:
> Nice clip - short and sweet. You may want to point people to about chunk
> file format in the description to alert people who may break chunk syntax by
> accident and get confused when fileIn breaks (been there, done that :-().

Maybe Esteban has already solved the chunk file problem by inventing the
Tonel format. People can concat all their Tonel class files into one
gigantic text file and knock themselves out with emacs/vim. 

Say a client-server setup: Headless Pharo runs a Shampoo server. Emacs
runs the Shampoo client and talks to the Pharo instance to manipulate
whatever Pharo stuff on the Emacs side as text. 

I'm not seriously suggesting the above by the way. That'll be like
making Emacs into an ad-hoc bug-ridden slow implementation of the
Smalltalk IDE, to borrow a phrase from a famous person.

Pierce

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Imran Rafique]

I'm a long-time lurker on this list, and still more of an
intermediate-squeaker (is that a word?) rather than pharo (although I
have used this off and on since pharo-5), so I feel like a bit of an
imposter jumping into this thread (long-time lisper).

That said, and without wishing to ruffle any feathers nor cause any
rancour (if I do, I apologise), may I humbly disagree with some of the
opinions mentioned by some certainly more accomplished Smalltalkers
than me.

Sven said:
> Everybody is of course totally free to do whatever they want, but really, why 
> the hell would you want to do that ?
> You lose so much by doing that, I do not even know where to start.
> A big part of what makes Pharo (or any Smalltalk) special is the IDE written 
> in itself.

Esteban said:
> Honestly, Pharo without the environment (and the “live objects” approach) is 
> just another dynamic language without much interest.

There's a distinction between "how you enter source code" and "the
full live object environment" paradigm.

No matter how you setup your smalltalk, at some point, you have to
talk to your system. Tell it to subclass Object because I want to add
a new class. Or add a new method to an existing class. Or just execute
this code right now, as is (Workspace/Playground). Etc, etc.

There are numerous text editor widgets sprinkled throughout
squeak/cuis/pharo's set of "tools" which enable you to do exactly that
- talk to the system.

These various editor widgets distinguish themselves slightly by
binding Self to something convenient (in the browser, for example),
but other than that - they're just text widgets.

The magic only happens once you take the text, and tell the system to
**do something with it**. Save, Do-it, print-it, etc.

Up to that point, its just text. Dumb, simple, plain text.

So, in a real sense, does it matter where you enter that dumb, simple,
plain text?

As long as there is an immediate, simple, failsafe way to sending that
text to the system to "do something with me", then you still have the
same live environment. Surely?

At that point, it doesn't matter (from the point of view of having a
"live system") whether the dumb, simple, plain text was initially
entered, from keyboard to screen, via the smalltalk process or another
external process.

One can certainly argue that simple fileouts, editing, and filingin is
too clunky a process. But, for example, having a fuse filesystem
exporting the live contents of the class hierarchy:

- every time you read "/Class-as-Dir/Method-as-file", the current
source is queried from the live smalltalk system

- every time you write to that file the smalltalk system is updated

Surely this would keep much of the same "liveness-in-spirit"? With the
added advantages of:

- spreading a little of the cpu burden around the various cores
(although this isn't really a cpu-intensive task anyway, but this
might apply more if we had out-of-image graphical inspectors which
also communicated via fuse)

- taking advantage of the **vastly** more advanced text editing
widgets available outside of pharo

Certainly, this is what Craig Latta webdav system is trying to get at.
I think its an interesting area to explore, and does not in any way
distract from "liveness" or "smalltalk'iness".

Ok, rant over :)


--
Regards,
   Imran Sher Rafique

On Thu, 24 Jan 2019 at 05:54, Sven Van Caekenberghe  wrote:
>
>
>
> > On 24 Jan 2019, at 12:10, Dimitris Chloupis  wrote:
> >
> > Often we have users of emacs and vim that request a way to use their 
> > favorite shortcuts or features. Some even ask "Would not be nice if I could 
> > use my favorite code editor with Pharo ?"
> >
> > Actually not only you can do it, its also very easy. So the following video 
> > tutorial explains in the first 3 minutes how to do this and then spends 
> > another 10 min talking about how this could be automated to be completely 
> > automatic and instantaneous.
> >
> > https://youtu.be/3YfRhDafIxs
>
> Everybody is of course totally free to do whatever they want, but really, why 
> the hell would you want to do that ?
>
> You lose so much by doing that, I do not even know where to start.
>
> A big part of what makes Pharo (or any Smalltalk) special is the IDE written 
> in itself.
>
> Editing a .st file has always been possible, it is masochism.
>
> There is for example https://github.com/dmatveev/shampoo-emacs which already 
> makes a bit more sense (but even then).
>
> Really, why do you think all these big IDE environments exist in the first 
> place ?
>
> Sven
>
>

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Hernán Morales Durand]

El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe ()
escribió:

>
>
> > On 24 Jan 2019, at 17:04, K K Subbu  wrote:
> >
> > On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
> >> Everybody is of course totally free to do whatever they want, but
> >> really, why the hell would you want to do that ?
> > Because text has many uses other than just feeding into a compiler for
> translation to machine code? People who come from Unix/Linux world are used
> to using a rich collection of tools that deal with text in various ways.
>
> I am myself a server/linux guy, an emacs user, I know what is all possible
> and what the unix philosophy is.
>
> I also know how to integrate Pharo into that world, and this is super
> important.
>
> >> You lose so much by doing that, I do not even know where to start.
> >
> > Live coding (i.e. coding in the presence of instances) is undoubtedly
> more powerful than edit-compile-run cycle. Text is used to direct IDE to
> edit live objects. But text has many more uses than just issuing commands.
> If beginners start using vim just to edit code due to established habits,
> they will soon realize the ease of live coding and remain in IDE. This is a
> self-correcting error.
>
> Well, I don't think so.
>
> The users that you are going to attract in this way (the ones that don't
> want to leave their own IDE/editor), will look at textual Pharo and find it
> very strange and ill suited to textual editing (and they are absolutely
> right), they will not discover the power, will not learn (from this
> experience alone) what object design/programming/power is, and will ask for
> more (e.g. give me C style compiler errors, better/easier structure of the
> file, fixed the !! escape issue, etc, ...).
>
>
We should admit for once text-based programming already won for this age.
Want a nice proof? Check Mr. Robot series. That's how a new generation of
devs is getting it. It doesn't matter if we have 30 years of experience
supporting exploratory UI is the best way, not even if we are fully
convinced of it. Probably it's time to invert the burden of proof, and let
people decide how they want to get into Pharo. If they want an
Objective-Smalltalk mode, let people live and die with it.

And I love the Class Browser, but we cannot assume every coder has
developed an exploratory mindset. Just ready to jump into a world of new
tools. "Forcing" on developing it through tools isn't actually nice
attitude neither. And there are really good devs out there, it may just
happen that they don't want a shock therapy as someone told above. Or they
don't have the time+energy for now. Let people themselves discover the
right tools for them, or stay where they want to.

So IMHO until someone really sits down and figure out a cool Pharo REPL, we
will get the same print me "Hello World" trolls in forums.

Cheers,

Hernán


> >> Editing a .st file has always been possible, it is masochism.Vim is
> much more than just a typewriter. It can leverage a whole set of
> > text-based tools. One could use it to auto generate methods, clean them
> up and then file into Pharo.
> >
> > Regards .. Subbu
> >
>
>
>

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Jose San Leandro]

Thank you very much.

Just to be clear, even if I'd love to be able to do such things, working in
Pharo is far from being a pain. Those things are just "nice to have".
Even if I don't find easy ways to do what I'd like to, I can always do it
myself, my way. Furthermore, it'd be good for me to do so.
That's why I think Pharo (and Smalltalk) is what Paul Graham describes as
the Bulb paradox.

El jue., 24 ene. 2019 a las 19:54, Dimitris Chloupis ()
escribió:

> yeah the System Browser has some shortcuts that you can find if you click
> that down arrow in top right corner of the window
>
> About getting Window info, that is tricky, all is available through
> Morphic but Morphic is kinda messy. So if you are willing to do the hard
> work its definetly doable , you can create your own shortcuts etc.
>
> Finding the leftmost probably you will ask the World morph about all
> windows , ask each window whether its opened and if yes where is located
> (morph >>position)
> I think the focus is in SystemWindow >> isActive , look also at
> basicActivate for a better idea what activation means
>
> For groups there is isEmbeded , also Morph >> embededMorphs
>
> No idea about the Playground, it keeps timestamped session of whatever you
> do so there is definetly something
>
> Yeah Pharo is not Emacs that's for sure. Mainly because we attract people
> who are mouse driven, people who are keyboard driven tend to avoid IDEs.
> Its doable , its just not available out of the box.
>
> I can feel your pain though, this has been an issue for me with Pharo, the
> power is there, but its not easy to access. However to be fair Emacs has
> been around a lot longer and has far larger community of contributors so
> its no wonder it can do these things with ease. Emacs also has amazing
> documentation. But sadly is no IDE and its shortcuts is pure insanity, but
> then I am a mouse person myself. Ironically I was raised on CLIs and I
> always hated them with passion :D
>
> On Thu, Jan 24, 2019 at 8:32 PM Jose San Leandro 
> wrote:
>
>> I don't want to hijack this thread, but it would be useful for me to have
>> a cheatsheet to allow me to do the usual operations I do with the mouse,
>> programatically. I've had some difficulties with simple things in the past.
>> For example, to delete all Transcript or Playground windows, I use calls
>> such as
>>
>> (World submorphs select: [ :w | ((w model printString beginsWith: 'a
>>> GTPlayground') or: [ w model printString beginsWith: 'Transcript' ]) not ])
>>> do: [ :w | w delete ].
>>>
>>
>> I'm missing ways to query World submorphs to know exactly my target
>> instance. For example:
>> - Which is the leftmost window?
>> - Which window has the focus?
>> - Which windows have "grouping" enabled?
>> - Which Playground instance I used more recently?
>>
>> And operations such as:
>> - Maximize morph.
>> - Activate "class side" in Nautilus.
>> - Select "accessing" protocol.
>> - Select package X.
>> - Select "Hierarchy".
>> - Choose the next child when "hierarchy" is active.
>>
>>> - Resize the method panel.
>>>
>>
>> Also, basic things like:
>> - Move to the next word.
>> - Highlight previous word.
>> - Highlight current line.
>>
>> That would be very helpful for me. I'm not saying it's difficult to do,
>> I'm just saying for me it'd be helpful.
>> That's basically why I love Emacs, because I can do with the keyboard
>> anything that can be done with the mouse, and more.
>>
>> Thanks!
>>
>> El jue., 24 ene. 2019 a las 19:05, Dimitris Chloupis (<
>> kilon.al...@gmail.com>) escribió:
>>
>>> Playground is a REPL inside Pharo so I am not sure I understand what you
>>> are asking. Everything in Pharo is just Classes and methods so you can do
>>> whatever you want. If you are a bit more descriptive maybe I can help you
>>> more. There is no such thing as a bad idea, just an idea that has not
>>> mature enough :D
>>>
>>> On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro <
>>> jose.sanlean...@osoco.es> wrote:
>>>
 I was aware of that. I was imaging a way to use the tools available in
 Pharo, but within a REPL session.
 Probably a bad idea anyway. I just think the mouse is useful when
 exploring, but it's ridiculously inefficient once you know exactly what you
 want to do.
 In my 4k monitor I often feel like if I was saying "no, I want to
 resize the window, not moving it, not changing the focus, thanks". I have
 to waste time being accurate enough with the mouse, because it's the
 expected way to communicate with live objects. Mouse, then keyboard. Not
 good.

 El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (<
 kilon.al...@gmail.com>) escribió:

> "I am sure there will always be skeptics. But my own experience was
> different. For me, the most weird thing about Squeak (and now Pharo)
> IDE
> is its insistence in showing only one method at a time. A method is
> too
> small a chunk of code. It is easy to miss the forest for 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

yeah the System Browser has some shortcuts that you can find if you click
that down arrow in top right corner of the window

About getting Window info, that is tricky, all is available through Morphic
but Morphic is kinda messy. So if you are willing to do the hard work its
definetly doable , you can create your own shortcuts etc.

Finding the leftmost probably you will ask the World morph about all
windows , ask each window whether its opened and if yes where is located
(morph >>position)
I think the focus is in SystemWindow >> isActive , look also at
basicActivate for a better idea what activation means

For groups there is isEmbeded , also Morph >> embededMorphs

No idea about the Playground, it keeps timestamped session of whatever you
do so there is definetly something

Yeah Pharo is not Emacs that's for sure. Mainly because we attract people
who are mouse driven, people who are keyboard driven tend to avoid IDEs.
Its doable , its just not available out of the box.

I can feel your pain though, this has been an issue for me with Pharo, the
power is there, but its not easy to access. However to be fair Emacs has
been around a lot longer and has far larger community of contributors so
its no wonder it can do these things with ease. Emacs also has amazing
documentation. But sadly is no IDE and its shortcuts is pure insanity, but
then I am a mouse person myself. Ironically I was raised on CLIs and I
always hated them with passion :D

On Thu, Jan 24, 2019 at 8:32 PM Jose San Leandro 
wrote:

> I don't want to hijack this thread, but it would be useful for me to have
> a cheatsheet to allow me to do the usual operations I do with the mouse,
> programatically. I've had some difficulties with simple things in the past.
> For example, to delete all Transcript or Playground windows, I use calls
> such as
>
> (World submorphs select: [ :w | ((w model printString beginsWith: 'a
>> GTPlayground') or: [ w model printString beginsWith: 'Transcript' ]) not ])
>> do: [ :w | w delete ].
>>
>
> I'm missing ways to query World submorphs to know exactly my target
> instance. For example:
> - Which is the leftmost window?
> - Which window has the focus?
> - Which windows have "grouping" enabled?
> - Which Playground instance I used more recently?
>
> And operations such as:
> - Maximize morph.
> - Activate "class side" in Nautilus.
> - Select "accessing" protocol.
> - Select package X.
> - Select "Hierarchy".
> - Choose the next child when "hierarchy" is active.
>
>> - Resize the method panel.
>>
>
> Also, basic things like:
> - Move to the next word.
> - Highlight previous word.
> - Highlight current line.
>
> That would be very helpful for me. I'm not saying it's difficult to do,
> I'm just saying for me it'd be helpful.
> That's basically why I love Emacs, because I can do with the keyboard
> anything that can be done with the mouse, and more.
>
> Thanks!
>
> El jue., 24 ene. 2019 a las 19:05, Dimitris Chloupis (<
> kilon.al...@gmail.com>) escribió:
>
>> Playground is a REPL inside Pharo so I am not sure I understand what you
>> are asking. Everything in Pharo is just Classes and methods so you can do
>> whatever you want. If you are a bit more descriptive maybe I can help you
>> more. There is no such thing as a bad idea, just an idea that has not
>> mature enough :D
>>
>> On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro <
>> jose.sanlean...@osoco.es> wrote:
>>
>>> I was aware of that. I was imaging a way to use the tools available in
>>> Pharo, but within a REPL session.
>>> Probably a bad idea anyway. I just think the mouse is useful when
>>> exploring, but it's ridiculously inefficient once you know exactly what you
>>> want to do.
>>> In my 4k monitor I often feel like if I was saying "no, I want to resize
>>> the window, not moving it, not changing the focus, thanks". I have to waste
>>> time being accurate enough with the mouse, because it's the expected way to
>>> communicate with live objects. Mouse, then keyboard. Not good.
>>>
>>> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (<
>>> kilon.al...@gmail.com>) escribió:
>>>
 "I am sure there will always be skeptics. But my own experience was
 different. For me, the most weird thing about Squeak (and now Pharo)
 IDE
 is its insistence in showing only one method at a time. A method is too
 small a chunk of code. It is easy to miss the forest for the trees. In
 Dimitris video, you see lots more code in one glance in vim session. So
 there are pragmatic reasons why some coders fallback to using fileOuts
 for browsing classes."

 I could not agree more , I find the column GUI weird and a waste of
 space. This is why I have ended up relying a lot on GTSpotter (finder)
 which help me browse classes a lot faster than the class browser. Kinda
 ironic.

 I am using Pharo since 2011. I am still dont like Class Browser :D

 "In summary, if someone misses Emacs or Vim when working with Pharo, it
 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Jose San Leandro]

I don't want to hijack this thread, but it would be useful for me to have a
cheatsheet to allow me to do the usual operations I do with the mouse,
programatically. I've had some difficulties with simple things in the past.
For example, to delete all Transcript or Playground windows, I use calls
such as

(World submorphs select: [ :w | ((w model printString beginsWith: 'a
> GTPlayground') or: [ w model printString beginsWith: 'Transcript' ]) not ])
> do: [ :w | w delete ].
>

I'm missing ways to query World submorphs to know exactly my target
instance. For example:
- Which is the leftmost window?
- Which window has the focus?
- Which windows have "grouping" enabled?
- Which Playground instance I used more recently?

And operations such as:
- Maximize morph.
- Activate "class side" in Nautilus.
- Select "accessing" protocol.
- Select package X.
- Select "Hierarchy".
- Choose the next child when "hierarchy" is active.

> - Resize the method panel.
>

Also, basic things like:
- Move to the next word.
- Highlight previous word.
- Highlight current line.

That would be very helpful for me. I'm not saying it's difficult to do, I'm
just saying for me it'd be helpful.
That's basically why I love Emacs, because I can do with the keyboard
anything that can be done with the mouse, and more.

Thanks!

El jue., 24 ene. 2019 a las 19:05, Dimitris Chloupis ()
escribió:

> Playground is a REPL inside Pharo so I am not sure I understand what you
> are asking. Everything in Pharo is just Classes and methods so you can do
> whatever you want. If you are a bit more descriptive maybe I can help you
> more. There is no such thing as a bad idea, just an idea that has not
> mature enough :D
>
> On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro 
> wrote:
>
>> I was aware of that. I was imaging a way to use the tools available in
>> Pharo, but within a REPL session.
>> Probably a bad idea anyway. I just think the mouse is useful when
>> exploring, but it's ridiculously inefficient once you know exactly what you
>> want to do.
>> In my 4k monitor I often feel like if I was saying "no, I want to resize
>> the window, not moving it, not changing the focus, thanks". I have to waste
>> time being accurate enough with the mouse, because it's the expected way to
>> communicate with live objects. Mouse, then keyboard. Not good.
>>
>> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (<
>> kilon.al...@gmail.com>) escribió:
>>
>>> "I am sure there will always be skeptics. But my own experience was
>>> different. For me, the most weird thing about Squeak (and now Pharo) IDE
>>> is its insistence in showing only one method at a time. A method is too
>>> small a chunk of code. It is easy to miss the forest for the trees. In
>>> Dimitris video, you see lots more code in one glance in vim session. So
>>> there are pragmatic reasons why some coders fallback to using fileOuts
>>> for browsing classes."
>>>
>>> I could not agree more , I find the column GUI weird and a waste of
>>> space. This is why I have ended up relying a lot on GTSpotter (finder)
>>> which help me browse classes a lot faster than the class browser. Kinda
>>> ironic.
>>>
>>> I am using Pharo since 2011. I am still dont like Class Browser :D
>>>
>>> "In summary, if someone misses Emacs or Vim when working with Pharo, it
>>> could be due to:
>>> - being stuck in the file-based way to think of coding.
>>> "
>>> Its a common misconception that Pharo does not heavily rely on text
>>> files, it actually does. Not only the source file makes it possible to view
>>> the code even the oldest method of version control tha Pharo being a fork,
>>> inherited from Squeak, the known mcz files they may look small binary files
>>> like the Pharo image but they are merely zip files with source code text
>>> files with the st extension.
>>>
>>> The image is merely the bytecode, the VMs machine code sort of, the
>>> actually source works the same way as other languages. Like other languages
>>> you dont need the source code to execute , only the bytecode. What makes
>>> the image special is that its one file and its a memory dump which makes it
>>> easy to store both live code and live state. Which is very helpful,
>>> technically its mandatory for true live coding, but still Pharo has to rely
>>> on source code files to make our lives easy. From there on is just a
>>> question whether you break the source code files in several small ones, or
>>> keep one large.
>>>
>>> "Besides that, is there an easy way to run an image in text-only mode,
>>> with a REPL or a playground or something like that?"
>>>
>>> Yeap its possible and has been around for a very long time. Pharo also
>>> makes it dead easy to expose any method as command line argument, so its
>>> possible to code completely from the command line although definitely not
>>> recommended.
>>>
>>> Deep Into Pharo book explains how.
>>>
>>> On Thu, Jan 24, 2019 at 7:17 PM K K Subbu  wrote:
>>>
 On 24/01/19 9:47 PM, Sven Van Caekenberghe 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

Playground is a REPL inside Pharo so I am not sure I understand what you
are asking. Everything in Pharo is just Classes and methods so you can do
whatever you want. If you are a bit more descriptive maybe I can help you
more. There is no such thing as a bad idea, just an idea that has not
mature enough :D

On Thu, Jan 24, 2019 at 7:53 PM Jose San Leandro 
wrote:

> I was aware of that. I was imaging a way to use the tools available in
> Pharo, but within a REPL session.
> Probably a bad idea anyway. I just think the mouse is useful when
> exploring, but it's ridiculously inefficient once you know exactly what you
> want to do.
> In my 4k monitor I often feel like if I was saying "no, I want to resize
> the window, not moving it, not changing the focus, thanks". I have to waste
> time being accurate enough with the mouse, because it's the expected way to
> communicate with live objects. Mouse, then keyboard. Not good.
>
> El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis (<
> kilon.al...@gmail.com>) escribió:
>
>> "I am sure there will always be skeptics. But my own experience was
>> different. For me, the most weird thing about Squeak (and now Pharo) IDE
>> is its insistence in showing only one method at a time. A method is too
>> small a chunk of code. It is easy to miss the forest for the trees. In
>> Dimitris video, you see lots more code in one glance in vim session. So
>> there are pragmatic reasons why some coders fallback to using fileOuts
>> for browsing classes."
>>
>> I could not agree more , I find the column GUI weird and a waste of
>> space. This is why I have ended up relying a lot on GTSpotter (finder)
>> which help me browse classes a lot faster than the class browser. Kinda
>> ironic.
>>
>> I am using Pharo since 2011. I am still dont like Class Browser :D
>>
>> "In summary, if someone misses Emacs or Vim when working with Pharo, it
>> could be due to:
>> - being stuck in the file-based way to think of coding.
>> "
>> Its a common misconception that Pharo does not heavily rely on text
>> files, it actually does. Not only the source file makes it possible to view
>> the code even the oldest method of version control tha Pharo being a fork,
>> inherited from Squeak, the known mcz files they may look small binary files
>> like the Pharo image but they are merely zip files with source code text
>> files with the st extension.
>>
>> The image is merely the bytecode, the VMs machine code sort of, the
>> actually source works the same way as other languages. Like other languages
>> you dont need the source code to execute , only the bytecode. What makes
>> the image special is that its one file and its a memory dump which makes it
>> easy to store both live code and live state. Which is very helpful,
>> technically its mandatory for true live coding, but still Pharo has to rely
>> on source code files to make our lives easy. From there on is just a
>> question whether you break the source code files in several small ones, or
>> keep one large.
>>
>> "Besides that, is there an easy way to run an image in text-only mode,
>> with a REPL or a playground or something like that?"
>>
>> Yeap its possible and has been around for a very long time. Pharo also
>> makes it dead easy to expose any method as command line argument, so its
>> possible to code completely from the command line although definitely not
>> recommended.
>>
>> Deep Into Pharo book explains how.
>>
>> On Thu, Jan 24, 2019 at 7:17 PM K K Subbu  wrote:
>>
>>> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote:
>>> >
>>> >
>>> >> On 24 Jan 2019, at 17:04, K K Subbu  wrote:
>>> >>
>>> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
>>> >>> Everybody is of course totally free to do whatever they want,
>>> >>> but really, why the hell would you want to do that ?
>>> >> Because text has many uses other than just feeding into a compiler
>>> >> for translation to machine code? People who come from Unix/Linux
>>> >> world are used to using a rich collection of tools that deal with
>>> >> text in various ways.
>>> >
>>> > I am myself a server/linux guy, an emacs user, I know what is all
>>> > possible and what the unix philosophy is.
>>>
>>>
>>> No offense intended. Just wanted to point out that text can have
>>> different purposes. Historically, Smalltalk presented itself as a
>>> OS+IDE. Today, that is no longer true. Pharo is just a multi-platform
>>> IDE.
>>>
>>> > I also know how to integrate Pharo into that world, and this is super
>>> > important.
>>> Thanks. This is what I intended to bring out.
>>>
>>> >>> You lose so much by doing that, I do not even know where to
>>> >>> start.
>>> >>
>>> >> Live coding (i.e. coding in the presence of instances) is
>>> >> undoubtedly more powerful than edit-compile-run cycle. Text is used
>>> >> to direct IDE to edit live objects. But text has many more uses
>>> >> than just issuing commands.  If beginners start using vim just to
>>> >> edit code due to established habits, they will soon realize 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Jose San Leandro]

I was aware of that. I was imaging a way to use the tools available in
Pharo, but within a REPL session.
Probably a bad idea anyway. I just think the mouse is useful when
exploring, but it's ridiculously inefficient once you know exactly what you
want to do.
In my 4k monitor I often feel like if I was saying "no, I want to resize
the window, not moving it, not changing the focus, thanks". I have to waste
time being accurate enough with the mouse, because it's the expected way to
communicate with live objects. Mouse, then keyboard. Not good.

El jue., 24 ene. 2019 a las 18:36, Dimitris Chloupis ()
escribió:

> "I am sure there will always be skeptics. But my own experience was
> different. For me, the most weird thing about Squeak (and now Pharo) IDE
> is its insistence in showing only one method at a time. A method is too
> small a chunk of code. It is easy to miss the forest for the trees. In
> Dimitris video, you see lots more code in one glance in vim session. So
> there are pragmatic reasons why some coders fallback to using fileOuts
> for browsing classes."
>
> I could not agree more , I find the column GUI weird and a waste of space.
> This is why I have ended up relying a lot on GTSpotter (finder) which help
> me browse classes a lot faster than the class browser. Kinda ironic.
>
> I am using Pharo since 2011. I am still dont like Class Browser :D
>
> "In summary, if someone misses Emacs or Vim when working with Pharo, it
> could be due to:
> - being stuck in the file-based way to think of coding.
> "
> Its a common misconception that Pharo does not heavily rely on text files,
> it actually does. Not only the source file makes it possible to view the
> code even the oldest method of version control tha Pharo being a fork,
> inherited from Squeak, the known mcz files they may look small binary files
> like the Pharo image but they are merely zip files with source code text
> files with the st extension.
>
> The image is merely the bytecode, the VMs machine code sort of, the
> actually source works the same way as other languages. Like other languages
> you dont need the source code to execute , only the bytecode. What makes
> the image special is that its one file and its a memory dump which makes it
> easy to store both live code and live state. Which is very helpful,
> technically its mandatory for true live coding, but still Pharo has to rely
> on source code files to make our lives easy. From there on is just a
> question whether you break the source code files in several small ones, or
> keep one large.
>
> "Besides that, is there an easy way to run an image in text-only mode,
> with a REPL or a playground or something like that?"
>
> Yeap its possible and has been around for a very long time. Pharo also
> makes it dead easy to expose any method as command line argument, so its
> possible to code completely from the command line although definitely not
> recommended.
>
> Deep Into Pharo book explains how.
>
> On Thu, Jan 24, 2019 at 7:17 PM K K Subbu  wrote:
>
>> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote:
>> >
>> >
>> >> On 24 Jan 2019, at 17:04, K K Subbu  wrote:
>> >>
>> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
>> >>> Everybody is of course totally free to do whatever they want,
>> >>> but really, why the hell would you want to do that ?
>> >> Because text has many uses other than just feeding into a compiler
>> >> for translation to machine code? People who come from Unix/Linux
>> >> world are used to using a rich collection of tools that deal with
>> >> text in various ways.
>> >
>> > I am myself a server/linux guy, an emacs user, I know what is all
>> > possible and what the unix philosophy is.
>>
>>
>> No offense intended. Just wanted to point out that text can have
>> different purposes. Historically, Smalltalk presented itself as a
>> OS+IDE. Today, that is no longer true. Pharo is just a multi-platform IDE.
>>
>> > I also know how to integrate Pharo into that world, and this is super
>> > important.
>> Thanks. This is what I intended to bring out.
>>
>> >>> You lose so much by doing that, I do not even know where to
>> >>> start.
>> >>
>> >> Live coding (i.e. coding in the presence of instances) is
>> >> undoubtedly more powerful than edit-compile-run cycle. Text is used
>> >> to direct IDE to edit live objects. But text has many more uses
>> >> than just issuing commands.  If beginners start using vim just to
>> >> edit code due to established habits, they will soon realize the
>> >> ease of live coding and remain in IDE. This is a self-correcting
>> >> error.
>> >
>> > Well, I don't think so.
>> > The users that you are going to attract in this way (the ones that
>> > don't want to leave their own IDE/editor), will look at textual Pharo
>> > and find it very strange and ill suited to textual editing (and they
>> > are absolutely right), they will not discover the power, will not
>> > learn (from this experience alone) what object
>> > design/programming/power is, 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"I am sure there will always be skeptics. But my own experience was
different. For me, the most weird thing about Squeak (and now Pharo) IDE
is its insistence in showing only one method at a time. A method is too
small a chunk of code. It is easy to miss the forest for the trees. In
Dimitris video, you see lots more code in one glance in vim session. So
there are pragmatic reasons why some coders fallback to using fileOuts
for browsing classes."

I could not agree more , I find the column GUI weird and a waste of space.
This is why I have ended up relying a lot on GTSpotter (finder) which help
me browse classes a lot faster than the class browser. Kinda ironic.

I am using Pharo since 2011. I am still dont like Class Browser :D

"In summary, if someone misses Emacs or Vim when working with Pharo, it
could be due to:
- being stuck in the file-based way to think of coding.
"
Its a common misconception that Pharo does not heavily rely on text files,
it actually does. Not only the source file makes it possible to view the
code even the oldest method of version control tha Pharo being a fork,
inherited from Squeak, the known mcz files they may look small binary files
like the Pharo image but they are merely zip files with source code text
files with the st extension.

The image is merely the bytecode, the VMs machine code sort of, the
actually source works the same way as other languages. Like other languages
you dont need the source code to execute , only the bytecode. What makes
the image special is that its one file and its a memory dump which makes it
easy to store both live code and live state. Which is very helpful,
technically its mandatory for true live coding, but still Pharo has to rely
on source code files to make our lives easy. From there on is just a
question whether you break the source code files in several small ones, or
keep one large.

"Besides that, is there an easy way to run an image in text-only mode, with
a REPL or a playground or something like that?"

Yeap its possible and has been around for a very long time. Pharo also
makes it dead easy to expose any method as command line argument, so its
possible to code completely from the command line although definitely not
recommended.

Deep Into Pharo book explains how.

On Thu, Jan 24, 2019 at 7:17 PM K K Subbu  wrote:

> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote:
> >
> >
> >> On 24 Jan 2019, at 17:04, K K Subbu  wrote:
> >>
> >> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
> >>> Everybody is of course totally free to do whatever they want,
> >>> but really, why the hell would you want to do that ?
> >> Because text has many uses other than just feeding into a compiler
> >> for translation to machine code? People who come from Unix/Linux
> >> world are used to using a rich collection of tools that deal with
> >> text in various ways.
> >
> > I am myself a server/linux guy, an emacs user, I know what is all
> > possible and what the unix philosophy is.
>
>
> No offense intended. Just wanted to point out that text can have
> different purposes. Historically, Smalltalk presented itself as a
> OS+IDE. Today, that is no longer true. Pharo is just a multi-platform IDE.
>
> > I also know how to integrate Pharo into that world, and this is super
> > important.
> Thanks. This is what I intended to bring out.
>
> >>> You lose so much by doing that, I do not even know where to
> >>> start.
> >>
> >> Live coding (i.e. coding in the presence of instances) is
> >> undoubtedly more powerful than edit-compile-run cycle. Text is used
> >> to direct IDE to edit live objects. But text has many more uses
> >> than just issuing commands.  If beginners start using vim just to
> >> edit code due to established habits, they will soon realize the
> >> ease of live coding and remain in IDE. This is a self-correcting
> >> error.
> >
> > Well, I don't think so.
> > The users that you are going to attract in this way (the ones that
> > don't want to leave their own IDE/editor), will look at textual Pharo
> > and find it very strange and ill suited to textual editing (and they
> > are absolutely right), they will not discover the power, will not
> > learn (from this experience alone) what object
> > design/programming/power is, and will ask for more (e.g. give me ,
> > style compiler errors, better/easier structure of the file, fixed the
> > !! escape issue, etc, ...).
>
> I am sure there will always be skeptics. But my own experience was
> different. For me, the most weird thing about Squeak (and now Pharo) IDE
> is its insistence in showing only one method at a time. A method is too
> small a chunk of code. It is easy to miss the forest for the trees. In
> Dimitris video, you see lots more code in one glance in vim session. So
> there are pragmatic reasons why some coders fallback to using fileOuts
> for browsing classes.
>
> Regards .. Subbu
>
>

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Jose San Leandro]

I am one of those that Dimitris Chloupis calls "shortcut guys". Actually, I
think using the mouse is a performance killer.
I agree with the argument that editing files instead of manipulating the
image wouldn't make sense, if I could edit code as fast as I do in Emacs or
Vim. In those editors, you have macros. They are explicitly designed to be
usable without the mouse. At some point, you manipulate text without
thinking. That's nowhere near what you can accomplish with Nautilus (or
Calypso, I suspect).

Having said that, I don't use Emacs or Vim to edit .st files, but in
specific cases when I know what I'm doing and it's not dealing with live
objects, but with bootstrapping images.

In the past, I felt I was missing Emacs because I wasn't yet fully immersed
in a live environment. I was uncomfortable editing code in Pharo, but it
was tolerable. Of course, it would have been much more tolerable if I
didn't know Emacs, so I wasn't aware of what I was missing.

I expect to be able to customize the keybindings (which would be a huge
boost for me) in Nautilus or Calypso, and once that happens my life in
Pharo would be much much happier.

In summary, if someone misses Emacs or Vim when working with Pharo, it
could be due to:
- being stuck in the file-based way to think of coding.
- or, missing the productivity aids that are not present on Pharo.

Besides that, is there an easy way to run an image in text-only mode, with
a REPL or a playground or something like that?

El jue., 24 ene. 2019 a las 17:59, Dimitris Chloupis ()
escribió:

> "Honestly, Pharo without the environment (and the “live objects” approach)
> is just another dynamic language without much interest.
> Thinking the IDE is just autocompletion is a poor idea of what a live
> environment can do for you."
>
> And I repeat once more, I NEVER said use external editor instead of Pharo,
> I said use external editor with Pharo. No idea how to make this any more
> clear. With my approach you sacrifice nothing from Pharo.
>
> "These are all valid points (and I started by saying that everybody is
> free to do whatever they want), but wouldn't you agree that the best
> experience is"
>
> Nothing absolutely nothing in my book comes remotely close to how polished
> Delphi and amazingly powerful IDE with great GUI design,
> No I dont agree emacs is an IDE at all, even setting up its tools is a
> huge pain. I tried to set it up for Python coding and it tooks me ages to
> reach absolutely zero. Vim is nowhere near to being an IDE. Lispworks I
> have no idea never used it , same story with mathematica. I have used
> PyCharm which is I think is the equivelant of IntelliJ, well designed IDE
> but too weak for my taste. XCode only supports ObjC and Swift and as an IDE
> , even though an Apple product it lets a lot to be desired in GUI design
> and also not impressive.
>
> So for me its first Delphi or its open source variant Free Pascal/Lazarus
> and then is Pharo. Suprisingly Visual Studio is a nice IDE (just nice) but
> not VSCode which I currently use which is 100% code editor.
>
> To be sincere I have given up on the idea of IDEs mainly because even with
> Pharo it was a huge pain to customise them, usual coding problem of lack of
> documentation, no code comments etc. Nowdays I design my own dev tools from
> scratch, they are not pretty but get the job done partially and at least I
> know the code well enough to easily improve it.
>
> My livecoding lib has become quite usable lately and now I am slowly
> venturing into the territory of memory managment and data visualisation.
>
> The IDE for me is a very personal experience, of course that does not mean
> that Pharo and Delphi are not still my idols. Love them both. They are
> amazing restaurants, with the best chefs in the world but in the end
> nothing is like home made food.
>
> I dont agree that Smalltalk without an IDE is a Smalltalk, thus I do not
> consider GNU Smalltalk a Smalltalk at all.
>
> "Giving people a subpar entry into our world will probably not convince
> them that there is something cool to be seen there."
>
> I think my video tutorials have given more than enough good reason to use
> Pharo and even more to love Pharo. I find it hard to believe that one video
> tutorial going to change that. I never hidden my love for Pharo. Also for
> me live coding has become mandatory anyway which why I went to such great
> extends to implement it in Python and C. Mind you nowhere near the Pharo's
> elegance but it works.
>
> "Nice clip - short and sweet. You may want to point people to about chunk
> file format in the description to alert people who may break chunk
> syntax by accident and get confused when fileIn breaks (been there, done
> that :-(). Also a caveat not to edit *.changes or *.sources though they
> look very similar to *.st files."
>
> I have explicitly said to edit only st files, no idea how to make myself
> any more clear. Although sometime making mistakes is a great excuse to
> learn 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[K K Subbu]

On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote:




On 24 Jan 2019, at 17:04, K K Subbu  wrote:

On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:

Everybody is of course totally free to do whatever they want,
but really, why the hell would you want to do that ?

Because text has many uses other than just feeding into a compiler
for translation to machine code? People who come from Unix/Linux
world are used to using a rich collection of tools that deal with
text in various ways.


I am myself a server/linux guy, an emacs user, I know what is all
possible and what the unix philosophy is.



No offense intended. Just wanted to point out that text can have 
different purposes. Historically, Smalltalk presented itself as a 
OS+IDE. Today, that is no longer true. Pharo is just a multi-platform IDE.



I also know how to integrate Pharo into that world, and this is super
important.

Thanks. This is what I intended to bring out.


You lose so much by doing that, I do not even know where to
start.


Live coding (i.e. coding in the presence of instances) is
undoubtedly more powerful than edit-compile-run cycle. Text is used
to direct IDE to edit live objects. But text has many more uses
than just issuing commands.  If beginners start using vim just to
edit code due to established habits, they will soon realize the
ease of live coding and remain in IDE. This is a self-correcting
error.


Well, I don't think so.
The users that you are going to attract in this way (the ones that
don't want to leave their own IDE/editor), will look at textual Pharo
and find it very strange and ill suited to textual editing (and they
are absolutely right), they will not discover the power, will not
learn (from this experience alone) what object
design/programming/power is, and will ask for more (e.g. give me ,
style compiler errors, better/easier structure of the file, fixed the
!! escape issue, etc, ...).


I am sure there will always be skeptics. But my own experience was 
different. For me, the most weird thing about Squeak (and now Pharo) IDE 
is its insistence in showing only one method at a time. A method is too 
small a chunk of code. It is easy to miss the forest for the trees. In 
Dimitris video, you see lots more code in one glance in vim session. So 
there are pragmatic reasons why some coders fallback to using fileOuts 
for browsing classes.


Regards .. Subbu

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"Honestly, Pharo without the environment (and the “live objects” approach)
is just another dynamic language without much interest.
Thinking the IDE is just autocompletion is a poor idea of what a live
environment can do for you."

And I repeat once more, I NEVER said use external editor instead of Pharo,
I said use external editor with Pharo. No idea how to make this any more
clear. With my approach you sacrifice nothing from Pharo.

"These are all valid points (and I started by saying that everybody is free
to do whatever they want), but wouldn't you agree that the best experience
is"

Nothing absolutely nothing in my book comes remotely close to how polished
Delphi and amazingly powerful IDE with great GUI design,
No I dont agree emacs is an IDE at all, even setting up its tools is a huge
pain. I tried to set it up for Python coding and it tooks me ages to reach
absolutely zero. Vim is nowhere near to being an IDE. Lispworks I have no
idea never used it , same story with mathematica. I have used PyCharm which
is I think is the equivelant of IntelliJ, well designed IDE but too weak
for my taste. XCode only supports ObjC and Swift and as an IDE , even
though an Apple product it lets a lot to be desired in GUI design and also
not impressive.

So for me its first Delphi or its open source variant Free Pascal/Lazarus
and then is Pharo. Suprisingly Visual Studio is a nice IDE (just nice) but
not VSCode which I currently use which is 100% code editor.

To be sincere I have given up on the idea of IDEs mainly because even with
Pharo it was a huge pain to customise them, usual coding problem of lack of
documentation, no code comments etc. Nowdays I design my own dev tools from
scratch, they are not pretty but get the job done partially and at least I
know the code well enough to easily improve it.

My livecoding lib has become quite usable lately and now I am slowly
venturing into the territory of memory managment and data visualisation.

The IDE for me is a very personal experience, of course that does not mean
that Pharo and Delphi are not still my idols. Love them both. They are
amazing restaurants, with the best chefs in the world but in the end
nothing is like home made food.

I dont agree that Smalltalk without an IDE is a Smalltalk, thus I do not
consider GNU Smalltalk a Smalltalk at all.

"Giving people a subpar entry into our world will probably not convince
them that there is something cool to be seen there."

I think my video tutorials have given more than enough good reason to use
Pharo and even more to love Pharo. I find it hard to believe that one video
tutorial going to change that. I never hidden my love for Pharo. Also for
me live coding has become mandatory anyway which why I went to such great
extends to implement it in Python and C. Mind you nowhere near the Pharo's
elegance but it works.

"Nice clip - short and sweet. You may want to point people to about chunk
file format in the description to alert people who may break chunk
syntax by accident and get confused when fileIn breaks (been there, done
that :-(). Also a caveat not to edit *.changes or *.sources though they
look very similar to *.st files."

I have explicitly said to edit only st files, no idea how to make myself
any more clear. Although sometime making mistakes is a great excuse to
learn something. Because I never intended this to be a replacement for
Pharo , I thought unnecessary to focus on the syntax of the st file format.

I think I should add a warning to the video "WARNING THIS IS NO
REPLACEMENT FOR PHARO BUT AN EXTENSION".

"The users that you are going to attract in this way (the ones that don't
want to leave their own IDE/editor), will look at textual Pharo and find it
very strange and ill suited to textual editing (and they are absolutely
right), they will not discover the power, will not learn (from this
experience alone) what object design/programming/power is, and will ask for
more (e.g. give me C style compiler errors, better/easier structure of the
file, fixed the !! escape issue, etc, ...)."

I think you are a bit too optimistic. People if they dont like something
they just give up and move on. When was the last time you saw a post here
by a person saying "I like to use Pharo but I will not because it does not
have X". Rarely if not never, because these type of people you describe are
gone in 50 seconds.

To be sincere if my video makes them leave, awesome, we dont need people
who dont use Pharo complaining about Pharo. And plus I would love someone
to even mention C, I have like an army of complains about this language and
I have to use it everyday. Well at least is not as bad as C++. Thank God
!

By they way we had this discussion before in the community. When I first
mentioned Git and Github (2011) back when using Git with Pharo and
especially an external website to upload code was unthinkable , if not
heretic,  I can remember how many told me that this would be an excuse for
people not to learn Pharo. 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Sven Van Caekenberghe]

> On 24 Jan 2019, at 17:04, K K Subbu  wrote:
> 
> On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:
>> Everybody is of course totally free to do whatever they want, but
>> really, why the hell would you want to do that ?
> Because text has many uses other than just feeding into a compiler for 
> translation to machine code? People who come from Unix/Linux world are used 
> to using a rich collection of tools that deal with text in various ways.

I am myself a server/linux guy, an emacs user, I know what is all possible and 
what the unix philosophy is.

I also know how to integrate Pharo into that world, and this is super important.

>> You lose so much by doing that, I do not even know where to start.
> 
> Live coding (i.e. coding in the presence of instances) is undoubtedly more 
> powerful than edit-compile-run cycle. Text is used to direct IDE to edit live 
> objects. But text has many more uses than just issuing commands.  If 
> beginners start using vim just to edit code due to established habits, they 
> will soon realize the ease of live coding and remain in IDE. This is a 
> self-correcting error.

Well, I don't think so.

The users that you are going to attract in this way (the ones that don't want 
to leave their own IDE/editor), will look at textual Pharo and find it very 
strange and ill suited to textual editing (and they are absolutely right), they 
will not discover the power, will not learn (from this experience alone) what 
object design/programming/power is, and will ask for more (e.g. give me C style 
compiler errors, better/easier structure of the file, fixed the !! escape 
issue, etc, ...).

>> Editing a .st file has always been possible, it is masochism.Vim is much 
>> more than just a typewriter. It can leverage a whole set of 
> text-based tools. One could use it to auto generate methods, clean them up 
> and then file into Pharo.
> 
> Regards .. Subbu
> 

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[K K Subbu]

On 24/01/19 7:23 PM, Sven Van Caekenberghe wrote:

Everybody is of course totally free to do whatever they want, but
really, why the hell would you want to do that ?
Because text has many uses other than just feeding into a compiler for 
translation to machine code? People who come from Unix/Linux world are 
used to using a rich collection of tools that deal with text in various 
ways.



You lose so much by doing that, I do not even know where to start.


Live coding (i.e. coding in the presence of instances) is undoubtedly 
more powerful than edit-compile-run cycle. Text is used to direct IDE to 
edit live objects. But text has many more uses than just issuing 
commands.  If beginners start using vim just to edit code due to 
established habits, they will soon realize the ease of live coding and 
remain in IDE. This is a self-correcting error.


Editing a .st file has always been possible, it is masochism.Vim is much more than just a typewriter. It can leverage a whole set of 
text-based tools. One could use it to auto generate methods, clean them 
up and then file into Pharo.


Regards .. Subbu

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[K K Subbu]

On 24/01/19 4:40 PM, Dimitris Chloupis wrote:
Actually not only you can do it, its also very easy. So the following 
video tutorial explains in the first 3 minutes how to do this and then 
spends another 10 min talking about how this could be automated to be 
completely automatic and instantaneous.


https://youtu.be/3YfRhDafIxs


Nice clip - short and sweet. You may want to point people to about chunk 
file format in the description to alert people who may break chunk 
syntax by accident and get confused when fileIn breaks (been there, done 
that :-(). Also a caveat not to edit *.changes or *.sources though they 
look very similar to *.st files.


BTW, if the command is all in one line, you don't need to select it 
before doIt. It is implied. Even if it is spread over a couple of lines, 
just press SHIFT-HOME after finishing typing the text and use the arrow 
keys to select multiple lines and then doIt. Very nifty!


Regards .. Subbu

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Esteban Lorenzano]

Honestly, Pharo without the environment (and the “live objects” approach) is 
just another dynamic language without much interest. 
Thinking the IDE is just autocompletion is a poor idea of what a live 
environment can do for you.

Esteban

> On 24 Jan 2019, at 15:37, Dimitris Chloupis  wrote:
> 
> "Thank you! I'm one of those"
> "wow.. thank you :D"
> 
> "Everybody is of course totally free to do whatever they want, but really, 
> why the hell would you want to do that ?"
> 
> I can think a few million reasons. Vim and Emacs for example with tons of 
> internal and external tools , handling code, documentation, unit testing, 
> integration with other languages. The list is very long.
> 
> I think for me that I am not a shortcuts person which is usually the reason 
> why people want to do this, I really like the idea of Workspaces/Projects in 
> Visual Code. They are great for managing big project especially if you mix 
> several languages together. Another good reason is dealing with markdown 
> which is a popular way of documentation and quite convenient. Git support is 
> extremely well done Visual Code for example tells me each line what commit is 
> related to and direct acccess with good visualisation of remote git 
> repositories. 
> 
> "A big part of what makes Pharo (or any Smalltalk) special is the IDE written 
> in itself."
> 
> There is no doubt that IDE wise Pharo is best to handle refactoring pharo 
> code, debug etc. But my approach does not lock you down on a single editor. 
> As I demonstrated in the video you can move easily between Pharo and VS code 
> and thats the whole point, you can take advantage of the best of both worlds. 
> 
> "There is for example https://github.com/dmatveev/shampoo-emacs 
>  which already makes a bit more 
> sense (but even then)."
> 
> I am fully aware of emacs shampoo I used to recommend it but not any more for 
> the simple fact it has not been updated for 6 years. Shampoo also is not just 
> about code editing its also a port of the smalltalk IDE to emacs. 
> 
> I am talking strictly code editing here and various other tools that can be 
> found in those editors that simply do not exist in Pharo, I am not talking 
> about IDEs. Why not have your cake and eat it too if you can ?
> 
> The whole point of my video was how to use external editor with Pharo and not 
> to replace Pharo completely which I think what you talking about here. Coding 
> editing in Pharo has still a long way to go, we do not even have an easy way 
> to setup keyboard shortcuts which is essential not for me but at least for 
> others. 
> 
> We all want to live completely inside the image but in reality those features 
> take time to implement and is a lot of work for our small community. 
> 
> By the way neither Emacs, Vim or Visual Studio Code are IDEs.Just powerful 
> editors with some IDE features and usually most of the features come in form 
> of extensions that you have install and configure properly. 
> 
> In any case I will repeat once again the point of the video is how to taker 
> advantage of nice features in code editors without having to abandon Pharo. 
> If this convince people to stick with Pharo I think its a win win situation. 
> Wouldnt you agree ?

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Sven Van Caekenberghe]

> On 24 Jan 2019, at 15:37, Dimitris Chloupis  wrote:
> 
> "Thank you! I'm one of those"
> "wow.. thank you :D"
> 
> "Everybody is of course totally free to do whatever they want, but really, 
> why the hell would you want to do that ?"
> 
> I can think a few million reasons. Vim and Emacs for example with tons of 
> internal and external tools , handling code, documentation, unit testing, 
> integration with other languages. The list is very long.
> 
> I think for me that I am not a shortcuts person which is usually the reason 
> why people want to do this, I really like the idea of Workspaces/Projects in 
> Visual Code. They are great for managing big project especially if you mix 
> several languages together. Another good reason is dealing with markdown 
> which is a popular way of documentation and quite convenient. Git support is 
> extremely well done Visual Code for example tells me each line what commit is 
> related to and direct acccess with good visualisation of remote git 
> repositories. 
> 
> "A big part of what makes Pharo (or any Smalltalk) special is the IDE written 
> in itself."
> 
> There is no doubt that IDE wise Pharo is best to handle refactoring pharo 
> code, debug etc. But my approach does not lock you down on a single editor. 
> As I demonstrated in the video you can move easily between Pharo and VS code 
> and thats the whole point, you can take advantage of the best of both worlds. 
> 
> "There is for example https://github.com/dmatveev/shampoo-emacs which already 
> makes a bit more sense (but even then)."
> 
> I am fully aware of emacs shampoo I used to recommend it but not any more for 
> the simple fact it has not been updated for 6 years. Shampoo also is not just 
> about code editing its also a port of the smalltalk IDE to emacs. 
> 
> I am talking strictly code editing here and various other tools that can be 
> found in those editors that simply do not exist in Pharo, I am not talking 
> about IDEs. Why not have your cake and eat it too if you can ?
> 
> The whole point of my video was how to use external editor with Pharo and not 
> to replace Pharo completely which I think what you talking about here. Coding 
> editing in Pharo has still a long way to go, we do not even have an easy way 
> to setup keyboard shortcuts which is essential not for me but at least for 
> others. 
> 
> We all want to live completely inside the image but in reality those features 
> take time to implement and is a lot of work for our small community. 
> 
> By the way neither Emacs, Vim or Visual Studio Code are IDEs.Just powerful 
> editors with some IDE features and usually most of the features come in form 
> of extensions that you have install and configure properly. 
> 
> In any case I will repeat once again the point of the video is how to taker 
> advantage of nice features in code editors without having to abandon Pharo. 
> If this convince people to stick with Pharo I think its a win win situation. 
> Wouldnt you agree ?

These are all valid points (and I started by saying that everybody is free to 
do whatever they want), but wouldn't you agree that the best experience is

- Java in IntelliJ's IDEA
- Objective-C / Swift in XCode
- The Mathematica language inside Mathematica
- Common Lisp in Emacs or LispWorks
- etc ..

Even though in each case you can edit code in any editor, you will miss out of 
so much by doing so.

Many languages are 'strange' and have their own style of working - as a 
newcomer you have to learn that and immerse yourself into that new world, in 
order to really appreciate/get it.

'Textual Smalltalks' have been done before (GNU Smalltalk for example), [as 
have many forms of Typed Smalltalk], IMHO they do not give you the real deal.

The allure of Pharo/Smalltalk should be 'learn something new that will blow 
your mind and change forever how you think'.

Giving people a subpar entry into our world will probably not convince them 
that there is something cool to be seen there.

Sven

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Dimitris Chloupis]

"Thank you! I'm one of those"
"wow.. thank you :D"

"Everybody is of course totally free to do whatever they want, but really,
why the hell would you want to do that ?"

I can think a few million reasons. Vim and Emacs for example with tons of
internal and external tools , handling code, documentation, unit testing,
integration with other languages. The list is very long.

I think for me that I am not a shortcuts person which is usually the reason
why people want to do this, I really like the idea of Workspaces/Projects
in Visual Code. They are great for managing big project especially if you
mix several languages together. Another good reason is dealing with
markdown which is a popular way of documentation and quite convenient. Git
support is extremely well done Visual Code for example tells me each line
what commit is related to and direct acccess with good visualisation of
remote git repositories.

"A big part of what makes Pharo (or any Smalltalk) special is the IDE
written in itself."

There is no doubt that IDE wise Pharo is best to handle refactoring pharo
code, debug etc. But my approach does not lock you down on a single editor.
As I demonstrated in the video you can move easily between Pharo and VS
code and thats the whole point, you can take advantage of the best of both
worlds.

"There is for example https://github.com/dmatveev/shampoo-emacs which
already makes a bit more sense (but even then)."

I am fully aware of emacs shampoo I used to recommend it but not any more
for the simple fact it has not been updated for 6 years. Shampoo also is
not just about code editing its also a port of the smalltalk IDE to emacs.

I am talking strictly code editing here and various other tools that can be
found in those editors that simply do not exist in Pharo, I am not talking
about IDEs. Why not have your cake and eat it too if you can ?

The whole point of my video was how to use external editor with Pharo and
not to replace Pharo completely which I think what you talking about here.
Coding editing in Pharo has still a long way to go, we do not even have an
easy way to setup keyboard shortcuts which is essential not for me but at
least for others.

We all want to live completely inside the image but in reality those
features take time to implement and is a lot of work for our small
community.

By the way neither Emacs, Vim or Visual Studio Code are IDEs.Just powerful
editors with some IDE features and usually most of the features come in
form of extensions that you have install and configure properly.

In any case I will repeat once again the point of the video is how to taker
advantage of nice features in code editors without having to abandon Pharo.
If this convince people to stick with Pharo I think its a win win
situation. Wouldnt you agree ?

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Sven Van Caekenberghe]

> On 24 Jan 2019, at 15:12, Craig  wrote:
> 
> 
> 
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
> Sven Van Caekenberghe
> Sent: Thursday, 24 January 2019 15:53
> To: Any question about pharo is welcome
> Subject: Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors
> to code in Pharo
> 
> 
> 
>> Everybody is of course totally free to do whatever they want, but really,
> why the hell would you want to do that ?
>> 
>> You lose so much by doing that, I do not even know where to start.
>> 
>> A big part of what makes Pharo (or any Smalltalk) special is the IDE
> written in itself.
>> 
>> Editing a .st file has always been possible, it is masochism.
>> 
>> There is for example https://github.com/dmatveev/shampoo-emacs which
> already makes a bit more sense (but even then).
>> 
>> Really, why do you think all these big IDE environments exist in the first
> place ?
>> 
>> Sven
> 
> Having the entire class in one text file so that you can see all of the
> functionality without a ridiculous amount of  clicking around is a huge
> bonus.

In practice, it turns out that most well written object code is distributed 
over several classes anyway, browsers were invented to help there - they are 
the solution, not the problem.

> Especially for those of us that come from a C#/Java environment.  Also,
> VS-Code provides a nice self-learning code completion mechanism,
> so you don't lose auto-completion.
> 
> Win-win.
> 
> Craig

I don't know where you are coming from and how much exposure you already got to 
Pharo or Smalltalk (if you are new, welcome!), but it is only after learning to 
work in the IDE and then doing it a bit for real (that will be strange at 
first, there is a non trivial learning curve), that you will appreciate the 
differences.

Working with Smalltalk code in a foreign editor/IDE is simply a terrible 
experience. (Although it sometimes might be useful in extreme/fallback 
situations).

Sven

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Eric Gade]

Sven asks an important question: why would anyone want to use an external
text editor given the power already present in the system? For most of us
on the list this question is rhetorical. But let's take a stab at
addressing it with the seriousness that, I think, it actually deserves —
particularly in light of the feedback we saw in various forums after the v7
announcement.

First, outside users are coming from the (as we'd say, outmoded) paradigm.
Multiple generations have now been inculcated with the idea that editing
text is the primary kinesthetic part of programming. We need to think about
ways that newcomers can "ease in" to something like Pharo, rather than
shock therapy. They can pick up the advantages over time.

Second, programmers are attached to their text editor of choice. It seems
silly when said aloud, but it's the truth. When doing non-ST work, I like
Emacs. Some people like vim. Others like any number of available text
editors. They can move around quickly in them when it comes to editing
text. Editing text, as much as we like to brush it aside, is something that
still happens in Pharo. Again, we should ease people in as best as possible.

Third, the text in most external editors looks nicer than it does in Pharo.
This is not a small matter. If you have to stare at code all day, it really
helps to have smoothly displayed typefaces and some choice (and easy
configuration) about how things are displayed. Sure, it's possible to
change the typeface in the current version of Pharo, but as many many
people pointed out on HN, it does not look crisp. Programmers today are
used to good looking text. Hopefully Bloc etc will be able to address this,
but it goes again towards that presentation/visual aspect of the system
that turns a lot of newcomers off. They think it looks cartoonish. Several
responders online even indicated that the community does not take graphics
/ visual design seriously at all (which we know isn't true, but that's the
impression people have).

Fourth, there don't seem to be any *reasonable* or *easy* methods for
editing remotely. With vim and emacs, editing code on a remote machine is
so easy it's barely considered a feature. In editors like VS Code this is
an easy enough feature to add. For Pharo it's hard to tell what's out there
— how would a newcomer even know where to look to find out how to do this?
Again, forum posters complained about out of date blog posts being the only
accessible place to get information. I know about projects like Telepharo —
but how does it work? Who is using it regularly? How would we explain it to
someone who just completed the MOOC or PBE? And yes, I know about shampoo
and it seems great, but I've never been able to get it to work properly
with Pharo.

I say all of this as someone who is using Pharo as much as I can in my
daily work and who absolutely appreciates the system and philosophy behind
it. Where it's reasonable, we should take the criticisms like these
seriously. What we think matters might not matter to newcomers and vice
versa.

On Thu, Jan 24, 2019 at 9:13 AM Craig  wrote:

>
>
> -Original Message-
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf
> Of
> Sven Van Caekenberghe
> Sent: Thursday, 24 January 2019 15:53
> To: Any question about pharo is welcome
> Subject: Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code
> editors
> to code in Pharo
>
>
>
> >Everybody is of course totally free to do whatever they want, but really,
> why the hell would you want to do that ?
> >
> >You lose so much by doing that, I do not even know where to start.
> >
> >A big part of what makes Pharo (or any Smalltalk) special is the IDE
> written in itself.
> >
> >Editing a .st file has always been possible, it is masochism.
> >
> >There is for example https://github.com/dmatveev/shampoo-emacs which
> already makes a bit more sense (but even then).
> >
> >Really, why do you think all these big IDE environments exist in the first
> place ?
> >
> >Sven
>
> Having the entire class in one text file so that you can see all of the
> functionality without a ridiculous amount of  clicking around is a huge
> bonus.
> Especially for those of us that come from a C#/Java environment.  Also,
> VS-Code provides a nice self-learning code completion mechanism,
> so you don't lose auto-completion.
>
> Win-win.
>
> Craig
>
>
>
>

-- 
Eric

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Craig]

-Original Message-
From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of
Sven Van Caekenberghe
Sent: Thursday, 24 January 2019 15:53
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors
to code in Pharo



>Everybody is of course totally free to do whatever they want, but really,
why the hell would you want to do that ?
>
>You lose so much by doing that, I do not even know where to start.
>
>A big part of what makes Pharo (or any Smalltalk) special is the IDE
written in itself.
>
>Editing a .st file has always been possible, it is masochism.
>
>There is for example https://github.com/dmatveev/shampoo-emacs which
already makes a bit more sense (but even then).
>
>Really, why do you think all these big IDE environments exist in the first
place ?
>
>Sven

Having the entire class in one text file so that you can see all of the
functionality without a ridiculous amount of  clicking around is a huge
bonus.
Especially for those of us that come from a C#/Java environment.  Also,
VS-Code provides a nice self-learning code completion mechanism,
so you don't lose auto-completion.

Win-win.

Craig

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Sven Van Caekenberghe]

> On 24 Jan 2019, at 12:10, Dimitris Chloupis  wrote:
> 
> Often we have users of emacs and vim that request a way to use their favorite 
> shortcuts or features. Some even ask "Would not be nice if I could use my 
> favorite code editor with Pharo ?"
> 
> Actually not only you can do it, its also very easy. So the following video 
> tutorial explains in the first 3 minutes how to do this and then spends 
> another 10 min talking about how this could be automated to be completely 
> automatic and instantaneous.
> 
> https://youtu.be/3YfRhDafIxs 

Everybody is of course totally free to do whatever they want, but really, why 
the hell would you want to do that ?

You lose so much by doing that, I do not even know where to start.

A big part of what makes Pharo (or any Smalltalk) special is the IDE written in 
itself.

Editing a .st file has always been possible, it is masochism.

There is for example https://github.com/dmatveev/shampoo-emacs which already 
makes a bit more sense (but even then).

Really, why do you think all these big IDE environments exist in the first 
place ?

Sven

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[peter yoo]

wow.. thank you :D

Re: [Pharo-users] [VIDEO TUTORIAL] How to use external code editors to code in Pharo

[Jose San Leandro]

Thank you! I'm one of those.

El jue., 24 ene. 2019 a las 12:11, Dimitris Chloupis ()
escribió:

> Often we have users of emacs and vim that request a way to use their
> favorite shortcuts or features. Some even ask "Would not be nice if I could
> use my favorite code editor with Pharo ?"
>
> Actually not only you can do it, its also very easy. So the following
> video tutorial explains in the first 3 minutes how to do this and then
> spends another 10 min talking about how this could be automated to be
> completely automatic and instantaneous.
>
> https://youtu.be/3YfRhDafIxs
>