[VIDEO TUTORIAL] How to use external code editors to code in Pharo
Locked
123
123
Re: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
 
|
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 <[hidden email]> wrote:
|
Re: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
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 (<[hidden email]>) escribió:
|
|
|
In reply to this post by Sven Van Caekenberghe-2
El jue., 24 ene. 2019 a las 13:18, Sven Van Caekenberghe (<[hidden email]>) escribió:
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 |
|
|
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> wrote: > > > > > On 24 Jan 2019, at 12:10, Dimitris Chloupis <[hidden email]> 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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
In reply to this post by K K Subbu
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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
In reply to this post by hernanmd
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:
|
|
|
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 <https://code.visualstudio.com/docs/editor/whyvscode> "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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
In reply to this post by kilon.alios
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 (<[hidden email]>) escribió:
|
Re: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
In reply to this post by eftomi
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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
> On 25 Jan 2019, at 11:34, Tim Mackinnon <[hidden email]> 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. |
|
|
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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
In reply to this post by Sven Van Caekenberghe-2
El vie., 25 ene. 2019 a las 8:01, Sven Van Caekenberghe
(<[hidden email]>) escribió: > > On 25 Jan 2019, at 11:34, Tim Mackinnon <[hidden email]> 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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
El vie., 25 ene. 2019 a las 10:36, Esteban Maringolo
(<[hidden email]>) escribió: > > El vie., 25 ene. 2019 a las 8:01, Sven Van Caekenberghe > (<[hidden email]>) escribió: > > > On 25 Jan 2019, at 11:34, Tim Mackinnon <[hidden email]> 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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
In reply to this post by Esteban A. Maringolo
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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
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 [hidden email]:
|
Re: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
In reply to this post by Tim Mackinnon
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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
|
|
Well written, well said, Torsten, exactly my point.
> 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". > 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. > > |
|
|
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: [VIDEO TUTORIAL] How to use external code editors to code in Pharo
Administrator
|
In reply to this post by isr
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. > > 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 < > sven@ > > wrote: >> >> >> >> > On 24 Jan 2019, at 12:10, Dimitris Chloupis < > kilon.alios@ > > 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 >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
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 entirely new level of liveliness that > I find simply fascinating Agreed. -- Regards, Imran Sher Rafique On Fri, 25 Jan 2019 at 13:08, Richard Sargent <[hidden email]> wrote: > > 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. > > > > 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 < > > > sven@ > > > > wrote: > >> > >> > >> > >> > On 24 Jan 2019, at 12:10, Dimitris Chloupis < > > > kilon.alios@ > > > > 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 > >> > >> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |