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 <kksubbu...@gmail.com> wrote: > >> On 24/01/19 9:47 PM, Sven Van Caekenberghe wrote: >> > >> > >> >> On 24 Jan 2019, at 17:04, K K Subbu <kksubbu...@gmail.com> 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 >> >>
