- 23comments
- 21comments
- 119comments
- 18comments
- 56comments
- 260comments
- —discuss
- 38comments
- 611comments
- 149comments
- 3comments
- 19comments
- 243comments
- 25comments
- 93comments
- 173comments
- 77comments
- 8comments
- 237comments
- 49comments
- 136comments
- —discuss
- 163comments
- 17comments
- 27comments
- 69comments
- 29comments
- 47comments
- —discuss
- 43comments
For anyone interested, there is a MOOC for Pharo going on here right now : https://www.fun-mooc.fr/courses/inria/41010/session01/ . The video are in French with English subtitle, but all the contents are in dual language French/English.
thank you for the link
Why is there no mention of Smalltalk on the page?
So is it Smalltalk? I kept reading and thinking, "This smells like Smalltalk." That's certainly not a bad thing!
yes it's smalltalk, i believe it was a fork of squeak??
Maybe to them it is. Smalltalk has been around forever. We've all heard about it, but very few of us have done anything with it so maybe to too many it has been relegated to the "that's cool, but I'll probably never use it" bin.
You know that interesting. I never really noticed that before because I already knew it was for Smalltalk programming.
You have to go to the "About" page to see that is has to do with Smalltalk.
I sent them an email about that. It may be intentional but I would think you would want that somewhere more prominent.
The main reason is because, while Pharo is obviously heavily inspired by (and, in fact, a fork of) Smalltalk, it's not trying to stay Smalltalk-80 compatible. Think of Racket: Racket started life as DrScheme, but as the goals of Racket gradually drifted away from being "just" a Scheme dialect, they decided to just call the entire language Racket to avoid confusion.
Pharo's doing the same thing. For the moment, the changes are relatively minor--new GUI hierarchy, support for method lambdas, some cleanup of the class hierarchy, support for traits alongside classes, and so on--but the team wants the flexibility to break compatibility more thoroughly as time goes on.
In other words, it's not about Pharo not wanting to give credit where it's due, but rather about not setting false expectations.
It's great to see Pharo improving, it has tremendous potential.
I think the groundbreaking changes in terms of immediate appeal will come in Pharo 6 (new widgets Brick/Bloc, faster graphics with SDL, better font rendering and so on) which will surely attract lots of newcomers to the environment.
To any Pharo devs that may be reading this, there is this snippet in http://www.pharo.org :
$ curl get.pharo.org | bash
In an age where nation states are fighting for control and MITM attacks are more prevalent than one would think, it does you no favors to promote snippets like the one I pasted. Please consider what the implications are and come up with a better way. I also noticed that you offer no signatures for the Pharo archives or downloads over HTTPS even. You do not need the bad publicity that will come with a security disaster stemming from these issues.
I hope you are right. I plan on doing the next MOOC that comes out to familiarize myself with Smalltalk and Pharo. Never stop learning.
There is a MOOC going on on Pharo programming right now at FUN (France Université Numerique) https://www.fun-mooc.fr/courses/inria/41010/session01/about
It is awesome!
They also could secure their downloads with TLS and signing.
That would just give a false sense of security.
In the end, you DO download a binary. Whether you download it with a script or not doesn't matter.
And at least the script, you can examine before running.
Damn, I feel like I see the curl-into-shell discussion every day online. Something has to give.
We would all be satisfied if they took the five minutes to set up a LetsEncrypt certificate.
There's no excuse not to.
Even better: have the developers agree on a set of GPG signatures to sign their builds with. A bit more complicated...
Did you read the LE client source code? Did you verify or set up so that files and directories are with least privilege? All that in five minutes?
Or are you suggesting that the Pharo webmaster git clones certbot onto their web server system and just runs the commands according to the LE getting started guide? That's not a qualitative step-up from "curl ... | bash".
I use acme-tiny. It's a nice short Python script that mostly shells out to OpenSSL. I went through the source code rather carefully, tested it, and then mucked around with file/directory permissions when using it for real. Took me like 12 minutes at least.
I'm kidding about the 12 minutes part, obviously. :-D
Do you have a source on "In an age where nation states are fighting for control and MITM attacks are more prevalent than one would think" ?
I am curious what those numbers actually look like. I've always wondered about what kind of scale they operate on.
PRISM is one single huge MITM.
An example (QUANTUM) that became public with Snowden revelations, that is also very old by now (so who knows what their current capabilities are) gives NSA the ability to on-demand MITM ANYONE they wish with a minimum of effort.
This is just a single actor.
What are the best practice alternatives?
I'm curious, what do people use Smalltalk/Pharo for?
I've seen a handful of demos and been blown away (especially the debugging tools), but am I wrong in assuming it's mostly for educational purposes? Is there a "real world smalltalk" that I'm missing?
It's useful in education, but it also was competitive in what became the Java market. Weirdly, the world bought into a relatively static language when it had the option to go for the extremely dynamic and flexible SmallTalk instead. I have always thought it an extreme shame that the man-centuries (man-millennia?) sunk into improving the JVM weren't instead spent improving an open-source SmallTalk instead.
Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control?
For a long time, Smalltalk and its brethren were terrible at sharing code; you had a bunch of stuff in an environment, and importing and exporting stuff was a nightmare. Has this changed?
Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run".
I'd be happy to be wrong about any of this. Smalltalk is my favorite language (that I'll never ship a product in) . . . but when you look at a couple of my recent projects, which are PHP + JavaScript + WebGL that interpret and let you look at a bunch of back-end statistics, I'd sure like to be using something better.
Regarding your last comment: surely there's a good compiles-to-JS option available these days? There's even a Smalltalk for client-side programming:
http://amber-lang.net/index.html
... not sure how that would work with WebGL though.
Amber's quite heavyweight and requires server-side support to do anything useful.
But Smalltalk's so simple that writing your own transpiler isn't that hard --- I have an entirely browser-side prototype in about 2kloc:
https://github.com/davidgiven/stellation/tree/stellation5/cl...
Performance is adequate, but not great. Method lookup is the dominating factor, because you need different code paths based on the type of the receiver (number, string, object...)
Of course, writing the libraries is the bulk of the work.
Possibly. But you may be looking at history through modern lenses. Java was released in mid 90s, and the open source VC tools of the day were RCS and CVS. SVN came in 2000. The explosive growth of DVCS came after that.
A Smalltalk image is similar to a bunch of Java packages bundled into a jar/war/ear/*ar file. You can run any number of OS processes, each a Smalltalk VM running an image, on a single computer. You can scale out by running Smalltalk VMs across multiple computers. Just as with Java and JVMs.
It's at least debatable whether or not an "extremely dynamic" environment is a pro or con when it comes to saving man hours
Well, one of the cornerstone technologies of the JVM, HotSpot, was actually developed for a Smalltalk implementation, Strongtalk, and later adapted for Java.
... and then some of that same team went on to do the compiler used by node, and Chrome (V8).
Modern JavaScript has many Smalltalk features.. [starts putting on flame retardant suit].
The best parts of JavaScript are where the Lisp and Smalltalk heritage is apparent.
The worst parts are where a PHB told Brandon Eich "we're going to call it Javascript, make it more like Java", and where the PHB told him "I don't care if it's done, we need to ship it".
Given the object model, I would add another Smalltalk descendent into the mix: Self http://www.selflanguage.org
Self was definitely an influence. It's where the prototype inheritance came from. Not sure that's a good thing. Smalltalk was more traditional in its inheritance model even if it was all duck typing.
For UI, prototype inheritance was nicer on the Newton (NewtonScript) than on the several of the class-based stuff I played with[1]. Morphic include in Pharo / Squeak is based on Self's UI. I actually like a prototype (other than performance issues) more than class-based. It has a much nicer, lighter feel for me. I just don't think Javascript is the best at it. I loved programming NewtonScript other than its clunky syntax in places. NeXTSTEP got around a lot of crappy class-based behavior by having live objects.
1) I swear I still have nightmares that include OnOk
You might be interested in some of their success stories:
http://pharo.org/success
Smalltalk was started to be adopted at the enterprise level when Sun unleashed Java into the world.
I used Smalltalk/V at the university around 1995, and since my focus was programming languages, started devouring all the Xerox PARC books right away.
IBM used to sell VisualAge for Smalltalk, which was reborn as Eclipse. To this day, Eclipse still has a Smalltalk like class navigation when you switch to "Java Browser" perspective.
The first commercial collections for Java in the late 90's, tended to either be influenced by STL's design or Smalltalk's.
The majority of Smalltalk vendors ended up switching to Java.
It didn't help that Sun brought in the startup that was trying to improve Smalltalk performance, to create Hotspot instead.
I use it to script Blender
https://www.youtube.com/watch?v=XPGDQc5LUvE
I take advantage of Pharo Live coding to Live Code 3d graphics in Blender
piping to bash as an install method?
didn't we decide this was a really really bad idea?
It could definitely be dangerous, but nothing is stopping you from inspecting the script before you run it.
Not saying you are wrong (you are not, you technically can download the script in one step, read it and then feed the local copy to bash) but someone posted a proof of concept a couple months ago that used user agent sniffing to potentially fool people into reading one thing and running another if they used the browser to read the source but curl to pipe the script into bash.
I wasn't aware of that, thanks.
gotta love a project that takes its documentation seriously http://files.pharo.org/books/
Does anyone know if the compiler refactoring happened in this release?
there is a new compiler this release and a new vm. Over 200 new features over 2000 fixed bugs and a ton of new documentation (my department). Busy Busy :)
awesome! I always wanted to dig into squeak/pharo compiler implementation. The old code was a mess. Thanks, happy digging-into-code-time ahead.
Smalltalk has been incredibly frustrating in that is one of the most fun languages ever, but makes it incredibly hard to actually produce a standalone program.
Programming in Smalltalk environments compared to regular ones is like gardening, maybe, growing stuff organically as opposed to working in a factory. But I somehow never managed to rip an appplication out of its environment.
That was my frustration. I made a game in SmallTalk at one point but there was no way to distribute it to people without giving them my whole image. I just wanted a simple .exe to hand out.
I'm surprised that decades after the first Smalltalks came out, the Smalltalk people still have not understood how big a deal that is.
http://forum.world.st/Create-a-exe-application-in-Pharo-2-0-...
PS: You should be a bit more flexible. If you insist on programming, say, in Haskell the same way you program in C, all you'll do is hurt yourself. Same goes when you try to use an image-based environment like a standard IDE or toolchain.
Just look at how Pharo itself is distributed: it's a zip file you can uncompress and run right on your desktop. On Windows, it just works out of the box without even running an installer.
You say this as if it's a good thing, it's not. It's a bad thing on Windows. It means the software will not be able to use a lot of facilities on the Windows platform. It's also a hassle for users who need to pick up a target directory, remember it's there, create a shortcut manually, etc...
There are reasons why modern operating systems use installers
As for the article, it is incredibly dated and wrong on many fronts about how people ship software on Windows.
I'll just address one point:
Installing and updating executables on Windows is a solved problem. Solved. It's so easy to deploy patches and even have software self update that nobody thinks about it any more. The fact that Pharo is reinventing its own process under the cover of doing it better (which they don't, it's worse by all standards) is precisely the problem that I was referring to: Pharo (and Smalltalk people in general) still don't understand how to deploy software on modern computers.
Just like unix!