Hacker News new | comments | show | ask | jobs | submit login
Pharo 4.0 Released (pharo.org)
107 points by estebanlor 890 days ago | hide | past | web | 79 comments | favorite

Not having heard of Pharo before 10 minutes ago, I wish this website did a better job of explaining what it is.

"... an object-oriented programming language and a powerful environment... (think IDE and OS rolled into one)"

An IDE and OS rolled into one? What does that even mean? I had to go to Wikipedia to learn that this is basically a modern Smalltalk implementation. So why not just say that on the main page?

I once took a glance at IBM's Smalltalk about 20 years ago (in fact, these IDE screenshots remind me of the "VisualAge" IDE that eventually morphed from Smalltalk to Java and was then re-invented as Eclipse). However, I don't know enough about Smalltalk itself for this website to be informative. Does it compile to executables, or does it require an interpreter or VM at runtime? Can applications be built from command-line (or a build script on a CI server), or is it tightly coupled with the IDE? The Wikipedia article mentions some web frameworks, but the Pharo website shows screenshots of what appear to be desktop GUI applications (or maybe data visualizations running inside the IDE, a la R with RStudio?).

Maybe someone with some hands-on experience could provide a TL;DR, for those who aren't willing to read the full book just to get a high-level sense of this?

Because if you don't understand "an IDE , OS rolled into one" then you don't understand what Smalltalk is anyway. Its not easy to explain what Pharo is , the same way its not easy to explain what Emacs is , etc. There are may ideas and workflow integrated into it and its development workflow is radically different to normal programming languages. "Does it compile to executables"

No it does not , but there is no need. Pharo can be distributed with your application and it does need to installed its a standalone.

"or does it require an interpreter or VM at runtime?"

its interpreted to byte code and it has a JIT VM. It is always runtime ;) Meaning everything is live and running even your source code. Compilation happens under the hood without the user being aware of it.

"Can applications be built from command-line (or a build script on a CI server), or is it tightly coupled with the IDE?"

There is a command line interface , also any method can be exported to command line and Pharo can run without a GUI.

"The Wikipedia article mentions some web frameworks, but the Pharo website shows screenshots of what appear to be desktop GUI applications (or maybe data visualizations running inside the IDE, a la R with RStudio?)."

There is a web framework which quite popular and actively developed Seaside that allow you to use javascript , html and the usual suspect. Plenty of others frameworks exists as well but not so actively developed. Most success stories in the web site use those frameworks.

"Maybe someone with some hands-on experience could provide a TL;DR, for those who aren't willing to read the full book just to get a high-level sense of this?"

you can also drop in IRC for general directions, and ask questions to the mailing list, the community is very welcomed for newcomers. But give pharo a try and ask questions and you wont regret it Pharo is a great way and fun way to create software.

I have made also video tutorial for newcomers


I have also made this simple guide to explain what Pharo really is


> then you don't understand what Smalltalk is anyway Sorry, but I think that is just wrong. As far as I know, Pharo is one of the best and more approachable alternatives to enter the Smalltalk world. They should be doing a better job at welcoming people to "their world". If they want people to just come already knowing what they are going to get, I don't see how are they going to go mainstream, ever (assuming they would like to.)

My personal opinion on this and no way the opinion of core Pharo devs, I am just a newcomer to Pharo and a minor contributor.

Mainstream will kill Pharo in an instant. Pharo is too cool and too well designed for mainstream. Pharo also is going towards a complete opposite direction of sacrificing features over ease of usage.

So in the end Pharo is not designed for the mainstream developer its designed for the developer that looks for something radical diffirent.

But diffirence comes with a cost, it means that you get out your comfort zone, explaining basic concepts takes much more time and effort because of lack of familiarity etc etc.

So if you dont understand Pharo at first try, thats not a bug thats a feature. If you do understand Pharo at second try that's a bug.

Some people refer to pharo as "the red pill" of coding, taking the red pill has its advantages but also significant disadvantages. The choice in the end is yours.

Sure documentation and website can be improved but it wont solve the problem that Pharo is outside mainstream way of doing coding because this is what makes Pharo so fun to work with :)

> Pharo is too cool and too well designed for mainstream.

And people wonder why the Smalltalk community has such a bad reputation.

Does your definition of "bad reputation" also includes modern software basing itself on ideas and implementation that either originated from Smalltalk or greatly improved by it, like GUI MVC , mouse integration, VM , Test Driven Development , IDE and much more ?

If yes then I hope Pharo keeps bringing a lot more of this "bad reputation" I find it very useful and productive. Frankly I wish I was aware of this "bad reputation" 25 years ago, would have saved me a lot of trouble learning all these languages which just recycle the same old things slightly modified. Unfortunately I converted to Squeak and then Pharo , a couple years ago. But better late than never :)

By the way you do not need to be a "snob" Smalltalker to be upset about mainstream's software disregard of good designs. There are endless posts on C++ design, Java design, Javascript design , Eclipse design , Visual Studio design, the horror of MFC, the horrors of web development, the horrors of android development and so much more.

> Does your definition of "bad reputation" also includes modern software basing itself on ideas and implementation that either originated from Smalltalk or greatly improved by it, like GUI MVC , mouse integration, VM , Test Driven Development , IDE and much more ?

No, my definition of bad reputation is perfectly demonstrated by your tone and attitude throughout this thread. You don't even seem to be aware of it, which is mystifying.

Try to step back for a second, reread what you wrote and start wondering if you'd be even remotely interested in joining a community filled with people with a similar elitist and condescending attitude such as yours.

You like Smalltalk, I get it. Good for you. Now try to learn to promote what you like without making it sound like everyone who doesn't share your passion is an idiot.

You assume too much. I never called other people idiots. There is much more to coding than good design. Mainstream coding choose to focus on features, performance and background compatibility. Thats not stupid its practical.

Many of the good designs of Smalltalk have been integrated to modern coding as well. There are complex practical reasons why good design and ease of use has not been the focus for the majority of programming languages for very long time.

To classify myself as elitist you will have to find at least one time of me mentioning Pharo as best solution out there. Quite the contrary I already said that it comes with its own share of problems and issues.

I am not here to promote it, I am here to help people understand what it is and let them make their own mind if they are interested in giving it a try or not.

Ugh, I agree with zak_mc_kracken.

The Pharo community needs to knock it off, with that kind of arguments. (And I say that, being a part of that community).

Pharo is NOT too cool and too well designed for the mainstream. :( It /is/ cool, and has a lot of good work put into it. But it still needs a lot more work (especially in documentation and tutorials) before it's really useable by people without extensive Smalltalk experience. So, everybody shut up and roll up your sleeves and work. And be humble.

First that was my argument and my opinion as I stated several times already. Not an opinion of a whole community. Second I prefer to say things as they are instead of being humble.

I don't believe for example its good design to depend on C libraries so heavily especially for something as essential like GUI development . I know for at least one bug in GTK that took a year to get resolved on MacOS because most people were not interested in it. In Pharo bug fixing is a lot easier because the language is dynamic and live and it has plenty of powerful IDE tools to make your life easier find bugs and resolved them. Same process in C or C++ is a pain in the ass. Python community chose to heavily depend on third party C/C++ GUI APIs .

I completely agree about documentation and tutorials but that does not make Pharo any less cooler in my back or worse designed , its makes it partly undocumented. Which is one of downsides of using Pharo.

And this is not just about Pharo, take Common Lisp and compare it with Javascript, how one language has been designed and how another. Which one is most popular ? How many articles have been written about Javascript ugliness ? What about C++ and Java way of doing OOP ? Compare it with the way Smalltalk is doing OOP.

Good design have been proven again and again in the software world highly unpopular , because people prefer to buy features. You can be humble and you can be honest, but you cant be both. I chose to be honest.

> You can be humble and you can be honest, but you cant be both

I... I literally have no words.

This would be great if there weren't so many red pills to choose from.

Like calling it "the" red pill is overselling it I mean.

It's "a" red pill.

As far as me is concerned to call something a red pill , it will have to offer a very diffirent experience. Thats is definetly not the case when it comes to coding, where you have the same old same recipe with some new things here and there. This is why also it took me so long to get used doing things in Pharo compared to learning another programming language which would be far faster. Pharo requires a rethinking of the fundamentals of the coding workflow.

You could argue that some language like Lisp requires the same, but the problem is that Lisp is just a language, Pharo is a lot more than that.

So for me, Pharo is the only "red pill" I can think of. Not because its diffirent but because is so fundamentally diffirent. Everything else is just blue pills with some red spots here and there. Thus I cant call Pharo , "a" red pill.

But if you have something else that is as diffirent as Pharo is I am mostly welcome the info , love to try fresh approaches to coding :)

Another thing to note here is that I dont use the term "red pill" to identify it as something superior. Its not superior , far from it , it come with its own problems and weaknesses. Pharo is neither a paradise or a utopia.

Pharo is not for everyone but for specific people looking for a very diffirent way of coding. But even they may not like Pharo.

In the end Pharo is another way of doing coding, it wont make you sexy with the ladies or turn you into a super coder.

> You could argue that some language like Lisp requires the same, but the problem is that Lisp is just a language, Pharo is a lot more than that.

Actually Lisp is so much more.

Lisp is a whole family of programming languages and its implementations. From Lisps on tiny micro-controllers, PCs, servers, to supercomputers. From simple interpreters to highly optimizing whole-program compilers.

Pharo is just one particular implementation of the programming language Smalltalk.

"You could argue that some language like Lisp requires the same, but the problem is that Lisp is just a language, Pharo is a lot more than that." - You could possibly try Racket.

This "red pill" metaphor really can apply to anything. For example for a high-level programming language user, C could be a red-pill if learning it helps them visualize what's happening automagically thanks to the VM/interpreter of their usual language.

It's also too cool to have a hello world that you can give to someone come in under 20 MB.

Nonsense. Hello world code in Pharo / Smalltalk is still a line or two, like in other languages.

You're probably referring to the fact that there's an option to deploy the hello world PLUS the VM it runs on, in a single package. That's like saying "You can't give a Java hello world to someone under 50 MB". Yes, technically true, the couple of lines of Hello World source code don't work without a 50 MB JRE. But you're being disingenuous.

You can't give a Java hello world to someone under 50 MB.

> Because if you don't understand "an IDE , OS rolled into one" then you don't understand what Smalltalk is anyway.

For people that know Smalltalk, "a Smalltalk environment" contains more information than "an IDE, OS rolled into one" (which you also could possibly apply as a description to some javascript environments or a whole number of other things that could exist, it is not like Smalltalk is the only way to build such an environment)

How does source control work for Pharo? I know it was an issue with Smalltalk as your "source" was a modified binary image. Is this the same?

You can use Pharo with git and github outside the box if you are using MacOS or Linux, there are some issues I think with Windows. Pharo uses Filetree which export source to files and makes commits , pulls , pushs etc. Gitfiletree allows filetree to be managed by git from inside Pharo without the use of a terminal but you can still use the terminal if that is your thing. I explain filetree, git and github in this video


Incidentally, even back in the day with the original Smalltalk-80 the "source" was available in a plain text sources file and the programmer's changes and additions were available in a plain text changes file which were in-sync with the image file.

Of course, arbitrary code could be exported in text files from the "binary image" file (even if that required code to be de-compiled from bytecode to text).

The source still is available as source code, so tools can work with that. The standard in the Smalltalk world is Monticello, I hope they added good tooling around it (the implementation I've seen was painful if you had ever used mercurial, git or even SVN, but I don't know how things are with Pharo)

Source control works similarly as to how it does with other languages. (The modified binary image thing was never the only, or the main, option).

From the amazing "Design Principles Behind Smalltalk"[0], which is short, beautiful and everyone interested in programming and software should read at least once:

"Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one."

Syntactically, the SmallTalk language is relatively straightforward, but the power of SmallTalk is that the designers envisioned so much more from what a programming language should be. SmallTalk has a "World" which is an incredible concept (this is the OS/IDE combo). Of course, this means that you must abandon every tool you use to start working in the language. But in exchange you can click on any window and view the source code for it, see where it fits in the object hierarchy etc. Every part of your development world can be interacted with and modified. You can open the same world from a usb drive on Windows, Mac and Linux. Unlike Haskell, it's not the language itself that will expand your vision of programming, it's the approach to what it even means to have a programming language.


Part of the confusion stems from the term "Smalltalk" being overloaded. When most people hear the word, they think "Smalltalk-80" - the version released over 30 years ago. What they probably don't know is that Smalltalk-80 was just one in a series of Smalltalks marching their way closer and closer to the "Dynabook" dream - a live, dynamic, turtles-all-the-way-down environment to provide “support for the creative spirit in everyone”. So Pharo is a modern iteration of the Smalltalk series.

Although it uses Smalltalk-80 syntax (almost), syntax is the least important part of Smalltalk. The real juice is the idea of a computing environment small and beautiful enough for one person to understand entirely - and fun! Toward that end, we feel that Pharo is evolving far enough beyond St-80 that it's more useful to think about it on its own terms.

Unfortunately, ideas that are truly different than the status quo are impossible to describe in a sound bite. Like learning to play a musical instrument, there is no shortcut - extended play is the price one must pay to shift to a more powerful perspective. But I hope this gives you a taste. If you're interested, I go a bit more in depth [on my blog](http://seandenigris.com/blog/?p=1092)

"Does it compile to executables, or does it require an interpreter or VM at runtime?"

It looks like they are still using (since 2010) the COG VM, which is a fast jitting VM, but I think they have others in works to replace/improve it.

They hesitate to include "Spur", a new memory manager in the VM. Check Clement Bera's blog post for more: https://clementbera.wordpress.com/2014/02/06/7-points-summar...

This is the first step towards a 64bits VM (yay!)

COG JIT VM is still the main VM, though the old one is also supported for mobile platforms like Raspbery Pi. There is also work to move Pharo to 64 bit.

> So why not just say that on the main page?

Because most people would not be intrigued by a site that said:

  Basically a modern smalltalk implementation
Personally I think the site is really nice and explanatory. But I agree that a "Learn More" button at the way bottom which brings you to a tour-style page would be a useful addition to their homepage.

The changelog is here: https://github.com/pharo-project/pharo-changelogs/blob/maste...

Things that I find especially interesting, from new stuff:

> TxModel, a modern text model who works with Athens (Preview)

This is very, very nice. New text model was in the works for quite some time now and I'm glad it finally landed. Easy and powerful text editing is important, even in primarily GUI-driven environments. Pharo was a bit behind the times in this regard, which resulted in, for example, Shampoo (http://dmitrymatveev.co.uk/shampoo/).

> OSWindow, a new way to handle windows and input events (Preview)

This allows for creating OS level windows from inside Pharo. IIRC it's supported only on Windows right now, but it's a very nice feature and will make creating apps that "look natively" easier.

> Slots model instance variables as first class enities and enable meta-programming on this level.

This looks rather important and I remember reading about it some time ago. There's a paper about it: http://scg.unibe.ch/archive/papers/Verw11bFlexibleObjectLayo... - I'll need to read it again now that it's implemented.

Then there are updated things, all very nice too. Congratulations to the team and contributors!

OSWindow is working nice for the three major platforms, using a SDL2 backend.

>Slots model instance variables as first class enities and enable meta-programming on this level.

That sounds similar to Self, where everything was expressed with slots, including instance variables. I believe Self also had a way to mark slots as immutable, which would be an awesome feature to get in Pharo.

Awesome work!

I gave Pharo a test drive a few months ago and was pleasantly surprised when I had a little window with a table listing out all of the links and titles on the front page of HN in an afternoon.

I really enjoyed the experience of "filling in the blanks," style programming that it introduced to me. I just started by instantiating an object and calling the entry point method... and landed in the debugger. But I was able to fill in the missing methods and data-structures until it finally came out of the debugger and I had a working application.

Can't wait to check out the release notes. I highly recommend spending an afternoon with it just to see what can be done.

Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback.

It still has a strange non-native user interface. Why would I want another window system in a window in 2015?

So does iTunes on windows and Qt (since v. 4) on everything.

But I agree the single-window MDI is a major drawback. I keep checking out Pharo periodically and hoping a UI with multiple, native windows will be present or at least in the works, but sadly that is not yet the case.

There was actually a project many years ago for Squeak to give it native OS windows called Cheese, and the Squeak people, if you can believe this, actually told the author (Boris Shingarov) not to bother, and that if he wanted native windows, he should go use some other Smalltalk instead. They actually preferred their ugly, unprofessional, cartoonish UI that nearly everyone new to Squeak complained about.

I think Pharo is on the right track, but it's sad the developers have to spend so much time paying off the technical debt the Squeak project ran up.

With the new OSWindows you can create multiple native windows. But... this is cool to allow people to do their stuff, but it does not match very well with the development philosophy of Pharo, where we open many windows at the same time. Imagine 20+ browsers, inspectors, playgrounds opened, all mixed with your regular browsers, mail, any kind of applications and you will understand why we prefer to keep the MDI. Said that... we actually want to support SDI also for development (optional for users), but this is a lot of work and will take a lot of effort. But we'll arrive there, with time (and help).

If a window manager does not support dealing with multitudes of applications with multiple windows, then the window manager does something wrong.

> Imagine 20+ browsers, inspectors, playgrounds opened, all mixed with your regular browsers, mail, any kind of applications and you will understand why we prefer to keep the MDI.

I simply hide these other applications - actually I use auto-hiding after some time period. No need for an MDI.

Let's look. My Mac now has 11 apps open: mail, calendar, contacts, browser, previewer, notes, two Lisp systems, several terminals, a finder, twitter, ...

Both Lisp systems use native windows, menus, buttons, dialogs, text fields, ... each Lisp editor is a separate window, ...

Multiple (native) windows + tabbed browsing is IMO better than a single-window MDI. Remember Linux and other Unix desktops already support multiple virtual desktops to manage many windows; you shouldn't try to reinvent this in Pharo.

We should not forget Pharo IS a fork of Squeak, it goes to a very different direction but is based on the same code. GUI wise Pharo inherited its GUI API, Morphic from Squeak. My personal opinions is that native look interfaces are dead. Nowdays most apps use custom look especially web applications.

Native looks apps look boring. Users don't like boring applications. At least I dont :)

The GUI in Pharo is not ideal but we should not also forget that this is a small community that is able to come up with tons of new cool useful features in each release because of how R.A.D Pharo is.

I disagree, native looking applications, while "boring", at least feel natural. Every time I use an application with custom controls (which almost always look pillowy) I feel like it wasn't made by a professional, it tends to respond different and it just doesn't feel right. I have read again and again criticism against Java and how it "failed" in the desktop because every time you used a Java application, it looked like a Java application.

Right, a lot of Smalltalker would love native windows. It's a requirement for some companies as well.

Edit: not only for the look but also for the feel. I hate when my usual keyboard shortcuts do something different in Pharo than in my OS.

I am not going to debate your personal taste, its your right to want "native looking" interfaces.

There has been a project to bring native interfaces to pharo called Mars


but after the student left none took the project further. So yes its possible but for now there zero interest for it in pharo community.

I myself also would prefer native windows, and I time to time continue working on Mars... but is a side project nobody has actually expressed interest, so I usually spend my time in other, more required, stuff. But... Mars was loading in Pharo 4.0, and even if very incomplete, is usable for them who want to give it a try and finish it (also people showing interest could help me to get motivation :) )

SmallTalk was designed to BE the computer. Skinning for a native look the way Qt does may be the way to go. Targeting code for native applications should really be a separate thing and should involve additional toolkits.

The commercial Smalltalks do this but they are very pricey.

> SmallTalk was designed to BE the computer

Yes! This is why comparing Smalltalk to programming languages misses the whole point. I just wrote a blog post about this: "Programmers: You Probably Don’t Know What a Computer Is" http://seandenigris.com/blog/?p=1092

My main complaint is the MDI. I don't think non-native widgets are a problem as long as they're done well and behave close enough to native widgets as to not confuse people.

Qt is probably the best example of this, so much that people will actually cite it as an example of a native UI toolkit when in fact it isn't, it just skins its widgets to look like it.

I find the Pharo UI boring. Looks like ancient with its old windows and controls of some dead Microsoft era. emulated other interfaces of Pharo always have this slightly off feeling to it... Just from the look&feel - not even thinking about all this non-standard half-baked UI, which is a strange mix of Xerox/Smalltalk, Morphic, Windows, and other UIs...

You would want it because its implemented in Pharo and because Pharo allow you to easily hack the system that means you can make the interface look any way you want without having to mess with C libraries. Also being Pharo it is part of the live system and it also push pharo development towards visual coding. As someone else pointed out already Pharo is a virtual OS, so having its own GUI API part of its very powerful live enviroment is very crucial. You can use external GUI APIs but you lose the ability to live code them which is what is the main goal of Pharo anyway. Personally I love the look of the user interface and even though there is dated MacOS theme I prefer using this theme. But one can create any theme he wants if looks are that important to him.

It's beyond my understanding why non-native windows, buttons, menus, etc. are a requirement for 'live-coding' or 'visual coding'.

its not, but on the other hand, existing GUI APIs are not live coding friendly nor made in Pharo ;) Also the moment you want to change something or hack something , welcome to C++ hell. You sacrifice native look and powerful features, you get a live easy to hack system in return. But as I said Pharo DOES NOT forbid you from using Native libraries of any sort, including GUI. The fact that the vast majority of pharo developers choose not to use native gui apis, says a lot about how desirable GUI APIs are compared to "non native look" Pharo GUI API which is called Morphic :)

Compare with for example this Lisp application:


A new UI, but using tons of native elements...

Why talk about a music app that a small amount of people use while we can talk about the most popular pro music apps out there. The kind of apps that the whole music industry is based on. Cubase , Ableton Live, Logic and Reason.

Guess what .... they all have custom GUIs

http://rekkerd.org/img/201404/prop_reason71.jpg http://www.highprofileaudio.com/LogicPro_BIG1.jpg http://static.kvraudio.com/i/b/cubase5.jpg http://soundista.com/wp-content/uploads/2012/06/Ableton.png

When it comes to music and graphics, there is not even a contest. Custom GUI win hearts of the users. Same story with mobile apps and web apps.

As matter of fact even some of the apps that do use Native GUIs they reject the native look using their own custom look at least to an extend.

And the native look goes more and more towards popular custom guis we see in web apps, like flat design etc etc.

None of them uses its own Window system.

actually all of them do use their own Window system and far more than that.

Hmm, I just started Logic on my computer and it uses native windows and lots of native UI. There is a main window, preferences window, help window, keyboard window, colors window, metronom settings, ... there is a menu bar with ten menus - native. There are native open/save dialogs, ...

None of that is in Pharo. It uses a clunky font, clunky windows, clunky shadows on windows, clunky resizing of the main window, its own open/save dialogs, its own finder, ...

Looks dated to me...

I have not been using Logic that much, but I can assure you Ableto and Reason are custom drawn GUI all the way and so are the vast majority of VST instruments and effects.

Fonts that comes with Pharo by default is a bitmap font, you can replace it with any TrueType font in Pharo settings.

You can have setting windows, open/save dialogs, color windows and much more with Pharo's GUI. There is even a window manager that can help you manage multiple windows. Tab support , and much more.

If you hate Pharo GUI so much , dont use Pharo, nobody forces you to. None in the Pharo community has a problem improving the GUI (the GUI is actually improved in every release of Pharo) or even supporting native GUIs ( https://marsonpharo.wordpress.com/ ) but the community is very small and I think they are doing a great job for their size.

Personally I really like the GUI :)

> You can have setting windows, open/save dialogs, color windows and much more with Pharo's GUI.

That's not the point. It is just not used by the software itself.

> Personally I really like the GUI :)

I like the GUI of my Lisp Machine. But very very few people use it and it is behind the times in many ways.

> If you hate Pharo GUI so much

Pointing out that it is dated and clunky is not 'hating' it. If somebody asks me how a UI for development tool should look like, I would point out the importance of a native look and feel. Lighttable for example. A recent development. It's not really native. It uses complex web stuff on the desktop. Fail.

True, cross-platform development is tough. But it's somewhat possible. Example: https://www.jetbrains.com/idea/

I still use Emacs in 2015, and Emacs is, basically, a strange non-native window system in a window. Smalltalk/Pharo is the same kind of thing, except less terminal-oriented—no?

Yes, exactly :)

(If you think about it, Java apps like Eclipse and so on, are also a tiny bit strange and non-native. They've come a long way towards blending in with native apps, over the years. But they still feel a bit off, from a native icon and windowing perspective.)

I use Emacs with windows. Native windows.


Pharo, the 1500HP engine for livecoding.

Is anyone using a smalltalk for live coding? It seems like the toplap community [1] who claim to be the home of live coding, are mostly into LISPs.

[1] http://toplap.org

Basically all Smalltalker do live coding. It's not live coding in the sense of building a scene or composing music tough.

The parent probably means live coding his app. If you do Ruby, think about creating your whole program in IRB. You can dump the memory anytime and reload the dump to continue from where you left.

Coding in IRB means that you have access to all the introspection and dynamic analysis while you're coding.

The meaning of live coding is quite specific, I mean, there is toplap and even a whole conference on it coming up.

Gilad Bracha likes to push live programming in smalltalk via his newspeak work. No time travel though, which I don't think is supported by any smalltalk environment yet (you can change code via fix and continue, or objects via direct manipulation, but code changes do not update objects retroactively). So the Bret Victor style of live programming probably isn't supportable (without changes to be model/runtime).

>>but code changes do not update objects retroactively<<

Can you explain what you mean by that?

iirc You can step back through the execution stack in the debugger, change code or variable values; and when you resume the new code is used and the new values are used.

Great ! Congratulation to the whole Pharo community.

I installed this for Ubuntu 12.04. When I fired it up, it requested I choose and build a source file (different from Pharo 3). Then when it started, it said, "Pharo cannot locate the source file named /usr/lib/pharo-vm/PharoV40.sources.

Any ideas what to do?

TIA, Steve

Sorry about that. The Ubuntu PPA is not yet up-to-date. Please download http://files.pharo.org/sources/PharoV40.sources.zip and extract it in /usr/lib/pharo-vm/PharoV40.sources. You may have to throw your image away and start a new one.

I forwarded you question to the dev list

Did the compiler overhaul happen in this version?

it happened previous version (3.0), this version we started to actually use it :)

Very nice! I missed that. Thanks!

Anyone using this professionally?

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact