7 ms·
Why Pharo Might be the Future of Software Development (2017)
- ofrzeta 8y agoMaybe it's my age but I am getting increasingly tired of the same articles about Smalltalk/Squeak/Pharo being on the edge of a breakthrough. Surely Smalltalk is nice and also has its place in the history of programming languages. Today, however, there's such a vast number of interesting programming languages that are used "in production" that I doubt Smalltalk will suddenly get more traction. What makes articles like this one really annoying are the same old claims that seem to be a bit delusional if not outright wrong, such as: "the Pharo IDE is much simpler and cleaner than Visual Studio and Eclipse. Even children can use it without difficulty!" The accompanying screenshot surely doesn't support that claim.
- Scarbutt 8y agoMaybe it's my age but I am getting increasingly tired of the same articles about Smalltalk/Squeak/Pharo They want to sell you courses.
- em-bee 8y agoi kind of agree. i use pharo, and i love working with it. it is actively developed and its interface is improving with every release. what i like about it though, is not the IDE but the image based development: that i can debug and fix an application while it is running. that, for certain classes of errors, i can pause an application (or it will pause by itself), and simply resume after fixing the error. maybe 10 years ago, and certainly 20 or 30 years ago, smalltalk's IDE was ahead of its time. today, many alternatives exist. but image based development is limited to very few platforms. only smalltalk, lisp and a few others offer that. i also like that smalltalks syntax is incredibly minimalistic. the downside is that smalltalk effectively requires you to forget all the tools you worked with before. but this is again, where pharo development makes its mark. it is now well integrated with git for example. we all know that git has its issues and a learning curve, and many GUIs are trying to make git more accessible. pharo managed to integrate git in a way that it works well with the traditional smalltalk development style while at the same time allowing it to take advantage of the strengths that git has to offer. greetings, eMBee.
- elboru 8y ago"Simpler and cleaner" Proceeds to show a window inside a window with 7 panels filled with lists and text everywhere. I was not sure if they were joking or if they were serious.
- hibbelig 8y agoMaybe it's because nothing related to files is showing up. For example, Java has packages, classes, protocols (interfaces), methods, and documentation. All of these are visualized in a Java IDE. But Java _also_ has folders and files, so these need to be visualized, as well. At least in Java there's a pretty clear mapping from packages and classes to folders and files. In PHP, the mapping is not so clear. Edit: I'm not saying I agree with the author, I'm just pointing out one aspect.
- coldtea 8y agoIt's not about the number of windows but about the very simple model of what they show.
- moesart 8y ago"Even children can use it without difficulty!" IMO A child would only find it easy to use if they were already a seasoned coder. The IDE looks overly complicated.
- gaius 8y agoEven children can use it Im my generation children used assembly language without any problems, and those who didn't have assemblers just worked out the hex codes on paper and POKEd them in and CALLed them.
- adamnemecek 8y agoMight but won’t.
- projectileboy 8y agoYou have to admit that this headline coupled with the (2017) is pretty funny.
- moesart 8y agoI hadn't noticed that. Thanks. That's made my day.
- gaius 8y agoI remember in the 90s Smalltalk was going to be the next big thing, IBM were all set to throw their weight behind it with VisualAge as the next big enterprise development tool... Then Java happened and IBM ditched Smalltalk and leaped on that bandwagon instead and the rest is history https://en.wikipedia.org/wiki/IBM_VisualAge https://en.wikipedia.org/wiki/IBM_VisualAge
- zapzupnz 8y agoAnything by Richard Kenneth Eng isn't worth the read. Props to the guy for promoting what he loves, but he never gives any good reasons or data to back up the non-existent reasons. His personal points of view are all you get, heavily disguised as assertions about Smalltalk and the environment being categorically better or easier than things with which nobody seems to be exhibiting any real problems. Because the assertions aren't backed up with evidence, it's hard to take seriously. Not to mention every single post on every single website just repeats the same things ad infinitum; it's basically spam at this point. This is mirrored by some of the more rabid fans. Whenever Smalltalk is brought up on HN, there's invariably someone or other to come and espouse that live coding is better than compile-debug-rinse-repeat. Why? Because it is. In what way is it better? It just is. I mean, why wouldn't I want to switch to developing apps in an unfamiliar way with little in the way of easy-to-understand documentation, contained within an alien user interface to my beloved macOS, limited to an unnecessarily difficult-to-use IDE, using a language that I can only use in the IDE, that can't integrate with damn near any other popular or modern tools and workflows, whose ability to target mobile (or hell, native platform-specific experiences) is either in its infancy (in 2018!) or completely non-existent, and whose proponents can't give a clear answer to what the big deal is? Yeah, no. A million posts saying the same things won't make a damned bit of difference.
- radiowave 8y agoI agree. Now, I'm a bit of a Smalltalk die-hard, and I do think live coding is better (in some vague, hand-wavey sense that I won't attempt to expand upon here), but I agree that a million posts saying as much won't change anything. Programming language adoption is as much about the transmission of culture as anything else, it's hard to do that with Smalltalk at a distance. One way in which many people here will regularly encounter "live" coding (i.e. with very short cycle times) is at the bash prompt - grep, awk, et al - (and my opinion of bash... is another thing I won't expand upon), but the ridiculous archaic "let's pretend it's a teletype" metaphor has an interesting thing going for it - as you work you leave behind a transcript of what you did, and what the result was. You can copy and paste that into an email, send it to someone and ask for help - maybe a mailing list, maybe a newsgroup. You can write it up as a blog post and say, "hey everyone - look at the clever way I did this". You can illustrate your tools and your working practices easily, and transmit your programming culture far and wide.
- nunb 8y agoKenneth Eng writes only about smalltalk... Despite promising directions like Amber ST, somehow smalltalk has failed to reach critical mass, and that's a shame. My feeling is that something about their approach promotes learning by showing rather than reading and that has limited the uptake. Most successful proponents move on... Avi Bryant and Ramon Leon and perhaps Mark Watson. I've had email exchanges with almost all these folks and overall the feeling is that it was a great environment whose time has passed. I think the Forth guy Don Hopkins is also a fan as is perhaps Joe Armstrong of Erlang fame. And of course HN loves Alan Kay.
- mark_l_watson 8y agoSince you mentioned me, here is my take: I would spend more time using Pharo but it often takes to much time getting things running. It happens too often that I will see a project mentioned in Pharo News, want to try it, and then have to spend too much time getting it running. There are advantages and disadvantages to image development and I usually don’t even take advantage of image based development in SBCL Common Lisp anymore: I usually have a load file to fetch data I will need and load in my code and required libraries. In the same way, I no longer keep multiple Pharo images around. That said, it is a large world and you don’t need too many companies and individuals using a software technology to keep the ecosystem supported and moving forward. I was also a big fan of my Xerox 1108 Lisp Machine, but that was mostly viable because Xerox had one large customer, the CIA. The CIA had a custom work environment for analysts that took advantage of the platform. In a similar way, I can see Pharo as potentially being an integration tool for knowledge workers with interfaces to external tools like MatplotLib and TensorFlow. A highly customized Pharo environment could be effective for organizations that could support a small team maintaining a custom analysis setup.
- kough 8y agoIf your language is tightly coupled to a specific IDE, that's cool and I might play around with it, but good luck getting me to use it in production.
- epse 8y agoYet C# and friends managed that just fine for many years..
- pritambaral 8y agoC# being the recommended way to build Windows apps played some part in that.
- zapzupnz 8y agoNot only that, one didn't need to use VS to code in C#. There was always csc.
- anotheryou 8y agoThe article is a bit light on what's special about it. I'm still a fan of the bold moves eve¹ did. ¹ http://witheve.com/ http://witheve.com/