Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pharo, the Modern Smalltalk

medium.com

Post reply on HN
Print view View original

141–150 of 178 posts

Re: Pharo, the Modern Smalltalk

#141

Post by igouy »

flavio81 wrote: post #137
gnaritas wrote: post #131

Earlier quoted context omitted.

No I'm not misunderstanding Smalltalk, that Smalltalk now has a git plugin to be able to expose itself in that manner is exactly the kind of jumping through hoops I was referring to, it's taken many years for that to become stable and most of us still don't use it, we use Monticello. And both of those are for sharing code, not for developing, we don't work on those st files, we export them. Don't tell me what I'm thi…

Smalltalk's image file(s) contain only the compiled code, not the original source code, which is on the changes and source files. You could decompile the image and get most of the source but not in its original, complete form. If your image crashes it gets reconstructed from those two files. It would be great if you Smalltalk fans would explain its source handling in these terms above, instead of promoting "image bas…

Correct - and the only time someone would directly interact with the .changes or .sources text files (as-text-files without using the IDE), is in the unlikely event that the image file had become corrupted in some way, and they were trying to recover work that had been done.

The .changes and .sources text files are maintained in-the-background by the IDE and kept in-sync with the image file.

Re: Pharo, the Modern Smalltalk

#142

Post by gnaritas »

flavio81 wrote: post #137
gnaritas wrote: post #131

Earlier quoted context omitted.

No I'm not misunderstanding Smalltalk, that Smalltalk now has a git plugin to be able to expose itself in that manner is exactly the kind of jumping through hoops I was referring to, it's taken many years for that to become stable and most of us still don't use it, we use Monticello. And both of those are for sharing code, not for developing, we don't work on those st files, we export them. Don't tell me what I'm thi…

Smalltalk's image file(s) contain only the compiled code, not the original source code, which is on the changes and source files. You could decompile the image and get most of the source but not in its original, complete form. If your image crashes it gets reconstructed from those two files. It would be great if you Smalltalk fans would explain its source handling in these terms above, instead of promoting "image bas…

Correct, and not remotely the point being made. Just stop, seriously, you don't know what you're talking about.

Re: Pharo, the Modern Smalltalk

#143

Post by scroot »

brudgers wrote: post #18
naasking wrote: post #16

Earlier quoted context omitted.

A Smalltalk environment is practically its own operating system, complete with its own isolated UI/window manager, shells and desktop environment.

GNU Smalltalk is file based and integrates with Emacas...oh, nevermind.

There's Shampoo [1] but I'll be damned if I've ever been able to get it to work.

[1] http://dmitrymatveev.co.uk/shampoo/

Re: Pharo, the Modern Smalltalk

#144

Post by scroot »

claystu wrote: post #104

How do you get started with GUI programming? I can't seem to find anything on this for Pharo6...and barely anything for earlier versions (which I'm assuming are now obsolete).

Spec [1] is one way. You can also find a list of books on the Pharo website [2].

[1] http://files.pharo.org/books/spec-tutorial/ [2] http://books.pharo.org

Re: Pharo, the Modern Smalltalk

#145

Post by int_19h »

cestith wrote: post #125
gnaritas wrote: post #119

Earlier quoted context omitted.

I just provided direct quotes from one of the creators of Java, sorry but you're simply wrong to argue you know better what inspired them than they did. Java is a decedent of Smalltalk via Objective C, that is simply a fact. It's well known and accepted they took syntax from C++ as deliberate attempt to entice C++ programmers into Java, that is not evidence they didn't base their inspiration on Smalltalk. And I quote…

Perhaps what inspired them and what their creation most resembles are not necessarily the same thing. It would do some good if both you and your parent poster could agree or disagree with that statement.

Yes, that's exactly what I had in mind. Regardless of what inspired the development of Java (and as this quote makes clear, both Smalltalk and Simula were on the list), the result clearly bears more semblance to Simula.

A relatively simple mental exercise to prove the point is to look at various Simula and Smalltalk constructs, and see how well they map to Java (1.0) constructs. For Simula, you'll find a nearly 1:1 correspondence on syntax alone, with nested functions being the primary pain point. With Smalltalk, you'd stumble as soon as you run into the first block.

Re: Pharo, the Modern Smalltalk

#146

Post by vanderZwan »

scroot wrote: post #140
vanderZwan wrote: post #123

I enjoyed playing around with Pharo a few years back, and often look at what else the people working on it have been thinking of lately. Having said that, the PharoJS website mentioned in the article could use some love, I just get an unstyled webpage[0]. Now, I love avoiding website bloat as much as the next guy, but from the point of view of a web developer who might be interested in exploring what Pharo and Smallt…

FYI for anyone reading / interested: Amber is apparently still under active development, but they moved from Github to a self hosted platform [1]. Last code update was 3 days ago. [1] https://lolg.it/amber/amber

Oh, that's good! But the website and documentation is pretty outdated then. I guess all current development goes into code?

Re: Pharo, the Modern Smalltalk

#147

Post by vanderZwan »

igouy wrote: post #128
vanderZwan wrote: post #124

Earlier quoted context omitted.

Well, Pharo seems to have quite a few contributors, so they probably figured something out. Let me have a look.. So, based on these slides about Pharo 6[0], it seems that they use multiple things. First, they have a tool called Epicea , which is a more modern way of tracking changes to an image[1]. Then, for git integration, they have a bunch of tools at pharo-vcs , specifically Iceberg [2]. [0] https://www.slideshar…

You seem to be answering the question - How do you distribute the software development? - and I read the question as - How do you distribute the finished app?

I honestly don't know how I misread GP so badly... too late to edit now.

Re: Pharo, the Modern Smalltalk

#148

Post by ScottBurson »

i_feel_great wrote: post #136
ScottBurson wrote: post #110

Smalltalk’s use of live coding is easy and elegant; not even Common Lisp, Forth, nor Java (hot swapping) can lay claim to that. Does anyone understand what this is talking about? I may not understand exactly what is meant by "live coding", but I think I do it in Common Lisp (via SLIME) all the time. How is it better in Smalltalk?

In Smalltalk, you can pause your application and inspect the objects alive in a stack at the time you paused it, go backwards and forwards in the stack, change them to see an alternative future, make changes and resume. It is the weirdest shit.

Common Lisp implementations admittedly vary in how well they support interacting with the stack in this way, but some of them do it just fine, as did the Lisp Machines. (The Lisp Machine developers were heavily influenced by Smalltalk, so I'm not saying Smalltalk doesn't deserve credit for the innovation; I'm just wondering what I'm missing, if anything, by using CL today.)

Re: Pharo, the Modern Smalltalk

#149

Post by flavio81 »

gnaritas wrote: post #142
flavio81 wrote: post #137

Earlier quoted context omitted.

Smalltalk's image file(s) contain only the compiled code, not the original source code, which is on the changes and source files. You could decompile the image and get most of the source but not in its original, complete form. If your image crashes it gets reconstructed from those two files. It would be great if you Smalltalk fans would explain its source handling in these terms above, instead of promoting "image bas…

Correct, and not remotely the point being made. Just stop, seriously, you don't know what you're talking about.

You only threw attacks and condescending comments instead of explaining Smalltalk's IDE way of keeping files, which I did. You are doing a disservice to the Smalltalk community with such an attitude.

Re: Pharo, the Modern Smalltalk

#150

Post by flavio81 »

throwaway7645 wrote: post #139
flavio81 wrote: post #121

Earlier quoted context omitted.

When you load Lisp files, they get compiled; this compilation is saved as binary files (often, "fast load files"), that do what it says on the tin: They allow you to, next time, load your program really quickly. Now, your program also has state. If you want, you can also save the state of the program (i.e. by using the "save-lisp-and-die" command). This can create large files, because this allows you not only to quic…

Thanks for clarifying my comment with actual experience. Much appreciated!

You're welcome! Forgot to mention, the other reason executable files (if produced) get big, is that compilation of a Lisp program not only produces the machine language form of your program, but it also includes a Lisp runtime.

The runtime makes possible having the condition-restart system, and the full power of macros (your program can compile lisp code at runtime if needed, thanks to the runtime.)

Post reply on HN