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

Smalltalk: Welcome to the Balkans

threeriversinstitute.org

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Smalltalk: Welcome to the Balkans

#11

Post by spooneybarger »

rbanffy wrote: post #3
dmlorenzetti wrote: post #2

This surely will sound like a troll, but the main thing that struck me here was the statement: "Just getting the code out of VisualWorks was a pain." How can anybody use a development environment that doesn't expose the source code in plain-text files? Can somebody who likes VW expound on the advantages it provides?

Smalltalk has been using images since ever. The image contains your world - your code, development tools and all your complete environment, preserving its state between your sessions. When it's time to deliver the application to its users, you just take out whatever is not the application and its dependencies and give the image to your client. That said, I too find it a bit disturbing not to be able to import/export…

You can do both of those things. You can file out changes and you can use text files to load in and build an image, it just isnt very commonly done.

Re: Smalltalk: Welcome to the Balkans

#12

Post by spooneybarger »

cabalamat wrote: post #5
rbanffy wrote: post #3

Earlier quoted context omitted.

Smalltalk has been using images since ever. The image contains your world - your code, development tools and all your complete environment, preserving its state between your sessions. When it's time to deliver the application to its users, you just take out whatever is not the application and its dependencies and give the image to your client. That said, I too find it a bit disturbing not to be able to import/export…

> I too find it a bit disturbing not to be able to import/export changes to the base image as text-files and being unable to build a clean image from source-code only. I also find that disturbing. Another vthing i find disturbing, which may be a related problem is that although Smalltak lets you do all sorts of cool things like rotate its menus 30 degrees while the application is still running, often it just doesn't…

I find having a live interactive debugger on the actual data makes it far easier to 'get the state of the system' rather than some text files which have very little to do with the state of the system and usually just represent code whereas a 'system' is a combination of code and data.

Re: Smalltalk: Welcome to the Balkans

#13

Post by spooneybarger »

larsr wrote: post #8
rbanffy wrote: post #3

Earlier quoted context omitted.

Smalltalk has been using images since ever. The image contains your world - your code, development tools and all your complete environment, preserving its state between your sessions. When it's time to deliver the application to its users, you just take out whatever is not the application and its dependencies and give the image to your client. That said, I too find it a bit disturbing not to be able to import/export…

There are objects in the modern day Squeak image that were created when Smalltalk-80 was released. In fact, if you explore around Squeak's image, you can find all sorts of disconnected bits and pieces that nobody uses anymore, that are just along for the ride because they are in the image. Sort of Smalltalk pseudogenes. It's organic, very different, and to me as a biologist who likes to program, quite fascinating.

There are some good points about how many people use images in this avi bryant interview that is completely different from the 'steroetypical' idea that many people have of how 'everyone' uses images:

http://www.infoq.com/interviews/bryant-smalltalk-dabbledb

Re: Smalltalk: Welcome to the Balkans

#14

Post by spooneybarger »

bad_user wrote: post #4
dmlorenzetti wrote: post #2

This surely will sound like a troll, but the main thing that struck me here was the statement: "Just getting the code out of VisualWorks was a pain." How can anybody use a development environment that doesn't expose the source code in plain-text files? Can somebody who likes VW expound on the advantages it provides?

The advantage when working with Smalltalk is that your application is alive, all your objects are alive ... it's like working in "irb" or "ipython", but with a true IDE that can do all sorts of things. An exception got thrown? The code browser takes you to the method that did it. You fix the error, and repeat the action that triggered the exception, and since the application doesn't completely die, you only need to r…

You can file code in and out of every smalltalk I've ever used. Its just a pain compared to getting an image. Or on most smalltalks now, you can just load monticello packages in ( its a smalltalk code & object distributed versioning system ).

While file in and out is a pain for large amounts of code, monticello and metacello make bringing code in and out of an image quite easy.

Re: Smalltalk: Welcome to the Balkans

#15

Post by spooneybarger »

dmlorenzetti wrote: post #2

This surely will sound like a troll, but the main thing that struck me here was the statement: "Just getting the code out of VisualWorks was a pain." How can anybody use a development environment that doesn't expose the source code in plain-text files? Can somebody who likes VW expound on the advantages it provides?

Using a fully relective image based system like various Smalltalks provide can be very disconcerting at first when you are used to files.

I wasn't particularly comfortable when I started. It was new, foreign and none of my tools that I was used to worked. I couldnt find all instances of string 'XYZ' and replace it with 'ZYX' in the ways I was used to and it bothered me but if you give a system like smalltalk enough time, you will see the advantages.

I have a hard time now when I'm working in ruby, perl or any other language where I don't have a debugger that can halt at any point in running code so I can examine everything about it: all my data, code, everything. I can run snippets of code against that data to verify results and then update my code right then, hit proceed and my bug is fixed. I never liked debuggers before smalltalk and now I know why, most debuggers are just too limited. I remember the glorious C days of finding the suspected cause of a bug and then recompling to test to make sure it was it. I remember the web app development days of logging and print statements.

What I have now when I do web development in Seaside is the ability to drop a breakpoint into any location in my code, get the debugger and quickly see, test and fix any issues I'm having. I love it and don't want to go back.

There are, however, tons of things I want to change about Smalltalk and the various communities that surround it, but for me, the core experience is second to none that I have ever experienced.

Re: Smalltalk: Welcome to the Balkans

#16

Post by spooneybarger »

wingo wrote: post #6
bad_user wrote: post #4

Earlier quoted context omitted.

The advantage when working with Smalltalk is that your application is alive, all your objects are alive ... it's like working in "irb" or "ipython", but with a true IDE that can do all sorts of things. An exception got thrown? The code browser takes you to the method that did it. You fix the error, and repeat the action that triggered the exception, and since the application doesn't completely die, you only need to r…

I seem to recall hearing (from the GNU Smalltalk author) that the text representation of Smalltalk isn't even standard. See http://www.gnu.org/software/smalltalk/manual/html_node/Synta... , for example.

Why would it be suprising that there isn't a standard text file representation of something that is hardly ever represented that way?

Re: Smalltalk: Welcome to the Balkans

#17

Post by mahmud »

rbanffy wrote: post #9
larsr wrote: post #8

Earlier quoted context omitted.

There are objects in the modern day Squeak image that were created when Smalltalk-80 was released. In fact, if you explore around Squeak's image, you can find all sorts of disconnected bits and pieces that nobody uses anymore, that are just along for the ride because they are in the image. Sort of Smalltalk pseudogenes. It's organic, very different, and to me as a biologist who likes to program, quite fascinating.

I know I shouldn't, but this organic thing makes me worry that one day my working image could develop some kind of disease ;-)

Use a purifying/tree-shaking tool then. I am sure STs have them.

Re: Smalltalk: Welcome to the Balkans

#18

Post by gnaritas »

dmlorenzetti wrote: post #2

This surely will sound like a troll, but the main thing that struck me here was the statement: "Just getting the code out of VisualWorks was a pain." How can anybody use a development environment that doesn't expose the source code in plain-text files? Can somebody who likes VW expound on the advantages it provides?

> How can anybody use a development environment that doesn't expose the source code in plain-text files?

I could just as easily say how can anybody use a development environment that only exposes the source code in something as archaic as plain-text files?

Files may make working with known tools easier and may have all kinds of advantages in other areas such as deployment, but images are far superior for the actual experience of developing working code. Tinkering with live objects real time beats the hell out of a run/compile/debug cycle that throws everything away and starts from scratch every time.

Re: Smalltalk: Welcome to the Balkans

#19

Post by _delirium »

rbanffy wrote: post #3
dmlorenzetti wrote: post #2

This surely will sound like a troll, but the main thing that struck me here was the statement: "Just getting the code out of VisualWorks was a pain." How can anybody use a development environment that doesn't expose the source code in plain-text files? Can somebody who likes VW expound on the advantages it provides?

Smalltalk has been using images since ever. The image contains your world - your code, development tools and all your complete environment, preserving its state between your sessions. When it's time to deliver the application to its users, you just take out whatever is not the application and its dependencies and give the image to your client. That said, I too find it a bit disturbing not to be able to import/export…

> being unable to build a clean image from source-code only

It's a different language, but I found this paper on making SBCL (a lisp compiler) build from source interesting: http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf

The previous situation was that the CMUCL compiler, which SBCL forked from, was essentially defined by the image, which was incrementally changed into new versions--- and over decades this process had made the source code that was nominally "the CMUCL source" increasingly different from the in-memory image that was actually CMUCL.

I still find the image-based model vaguely fascinating in its blurring of the compile-time/runtime distinction, something that occasionally gets resurrected under various guises: http://en.wikipedia.org/wiki/Interactive_programming

Re: Smalltalk: Welcome to the Balkans

#20

Post by jhancock »

It didn't used to be this bad:

1 - I used to have a commercial app framework in smalltalk. You could take a fresh Digitalk smalltalk system (or even one with lots of mods as long as there were no namespace conflicts) and "file-in" my app framework code and all was well. The tools of that day allowed you to "file-out" the code to a plain text file(s) or save it in object repos with revision history.

2 - Porting between the two major vendors of the day, Digitalk and ParcPlace, was trivial if you were a solid smalltalk programer.

For the last 10 years, I've on and off tried to use smalltalk again, but the tool sets are horrid compared to what they used to be. A 1994 Digitalk smalltalk was a great toolset. Maybe in a few years, Pharo will be on par with what we had then.

Post reply on HN