[VIDEO TUTORIAL] How to use external code editors to code in Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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

EstebanLM


> On 25 Jan 2019, at 20:52, Torsten Bergmann <[hidden email]> 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.
>                      
>


Reply | Threaded
Open this post in threaded view
|

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

EstebanLM
In reply to this post by eftomi


> On 25 Jan 2019, at 21:45, eftomi <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

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

kilon.alios
In reply to this post by EstebanLM
"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. 


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 <[hidden email]> wrote:


> On 25 Jan 2019, at 20:52, Torsten Bergmann <[hidden email]> 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.
>                       
>


Reply | Threaded
Open this post in threaded view
|

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

eftomi
In reply to this post by EstebanLM
> 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

Reply | Threaded
Open this post in threaded view
|

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

EstebanLM


> On 26 Jan 2019, at 15:13, eftomi <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

Re: [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

Reply | Threaded
Open this post in threaded view
|

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

hernanmd
In reply to this post by kilon.alios

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 (<[hidden email]>) 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 <[hidden email]> wrote:
El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe (<[hidden email]>) escribió:


> On 24 Jan 2019, at 17:04, K K Subbu <[hidden email]> 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
>


Reply | Threaded
Open this post in threaded view
|

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

Ben Coman
In reply to this post by eftomi


On Sun, 27 Jan 2019 at 02:01, eftomi <[hidden email]> 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...
<CTRL-O><B>  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 <CTRL-F> from here could be re-purposed for "Filter..."?
 
How many people currently use <CTRL-F> from the Packages pane? (I never have)

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

Also, <CTRL-TAB> currently opens an Inspector on the currently selected package or class.
Is that a common requirement?  <CTRL-TAB> 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 <CTRL-F>, <TAB> & <CTRL-TAB>
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 <CTRL-F>, <TAB> & <CTRL-TAB>
perhaps experiment with it and propose a PR.

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: [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
> <CTRL-F>, <TAB> & <CTRL-TAB>
> perhaps experiment with it and propose a PR.

This would be great.




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

123