4 ms·

Well, don't speak about abstract 'shackles', show me the improved process! I am especially interested in version control and collaboration. IMHO, existing file-

by theamk 10y ago

Well, don't speak about abstract 'shackles', show me the improved process! I am especially interested in version control and collaboration. IMHO, existing file-based tools have had quite a few advances on this front: * Tests are now common and considered a good thing. A new contributor can write code without worrying about breaking rarely-used functionality. * Many languages have package managers. Using latest third-party library is now simple * We have great deployment mechanisms -- one-command deployments are common, containers and version pinning help reproducibility. * Some languages come with support for interactive REPL -- you can evaluate arbitrary commands inside running processes. * Many languages support static checking -- a lot of errors could be caught even if the code is never exercised * Many languages need no compilation at all -- just edit the file and run it What can smalltalk offer? Obviously it has great REPL. Anything else? What is the cool new 'software development process' feature that you are referring to? For example, I have found exactly one sentence about version control and sharing in the article you have linked: "We may even see Pharo 7, which promises a Git-integration tool called Iceberg for source code version control." . Is this what you wanted to show me? Because my takeaway is that the only way to work on Smalltalk software as a team is to use file-based tools (git). I see no improvements in software development process here. The other commenter mentioned Monticello and Smalltalk Hub. Ok, this looks like a decent version control system. It is interesting how without files, you have to add a prefix to a name of every class and tag each function which you want checked in. Still, I could not find which features it has that git does not.

db48x 10y ago
Most of those "advances" have nothing to do with files or images at all. For testing it doesn't matter where the tests come from. Certainly some test environments look for tests in files with predetermined names, or in particular directories, but that's an implementation detail. Look at Rust for a modern compiled file-based language that completely avoids that; instead you tag individual functions with metadata to indicate that they are tests. At build time you can create both a normal binary and a test binary; the first is the program you wrote, the second runs the tests that you wrote. REPLs and a mixed compiler/interpreter were both invented by Lisp, which is largely image-based. They go hand-in-hand; code you enter at the REPL might start out interpreted, but you can always call the compiler (at run time) to speed up functions you care about (or let the system do it automatically). The static vs dynamic language divide has nothing to do with how the code is stored, but historically languages with REPLs have indeed been dynamic languages. I don't know about Smalltalk specifically, but Common Lisp has a great package system, and with Quicklisp it's a fully modern one with automatic package installation, dependency management, version pinning, and everything. Of course, Common Lisp these days is a hybrid system. Your code is stored in files, and when you load them into memory to create an image. If you care about startup time you can dump that image out so that it loads all at once. Quicklisp just has to download a tarball of files and stick them in your load path for you; I don't know precisely this is done in Smalltalk. Both Lisp and Smalltalk have a facility for writing code out to a file to be printed, sent across the network, etc. This is how collaboration is done. You write the code in your environment, test it, etc. Then you write it out to a file and send it to whoever. (Or your version control system puts it in a file for you when you commit, etc.)
- theamk 10y ago
  Well, I was responding to specific parent's statement: "Being shackled to existing file-based tools holds you back from improving the software development process." This seems to imply to me that non-file-based tools have some other improvements to software development process. I think both you and I agree that software development process improves mostly independently from file-based/image distinction. There are no visible ways when files are "holding back" the software development.
  - bencoman71 10y ago
    Everyone sees the world through their own eyes, filtered by what their past and what know. A peculiar perspective of Smalltalk programmers is to consider that "code in files is dead code". External tools are needed to query it, modify it, compile it. In Pharo you can evaluate... Integer methods first inspect and in different tabs you can see this method's source code, the AST, the compiled bytecode. Or in a similar way we can look at how PLUS is implemented by evaluating (Integer>>#+) inspect Or look at all the methods that use PLUS #+ senders inspect Within Smalltalk, classes and methods are themselves objects. You can operate on them like any other object. They are ALIVE!!! AHAhahaHaaaaa :)
nathanjames 10y ago
The improved process is not in how it can emulate the way you've done things for decades with file-based tools. It's in the conceptual nature of programming, as well-explained by Bret Victor: https://youtu.be/8pTEmbeENF4 https://youtu.be/8pTEmbeENF4 - Software development using files and folders is absolutely antediluvian. Smalltalk does everything in a universe of objects; source code is organized spatially rather than in long reams residing in text files. - Live coding and debugging done right is an enormous and unparalleled productivity booster. - Persisting execution state is extremely convenient for maintaining continuity, and hence the high velocity of development. Governments and enterprises have long used Smalltalk to write massive applications in large team environments using Smalltalk's own tooling for collaboration and version control. There's no question that historically Smalltalk has not played well with the outside (file-based) world, and this has been a major point of contention. If you insist on using Git and similar tools with Smalltalk, then yes, this is problematic. The point is, if you view software development from only one perspective, you deny any possibility of improving the process in other ways that can lead to dramatically improved productivity, accelerated development, and lowered cognitive stress.
- theamk 10y ago
  Sorry, I am at work right now and don't have time to watch videos. Can you tell me more about "Smalltalk's own tooling for collaboration and version control"? Are you referring to Monticello? I am not insisting on git, but Monticello seems pretty limited in term of collaboration. I see commit, diff, checkout, and remote pull/push. Specifically, let's imagine this scenario: we have team of tens of programmers working on a project. A new team member joins and accidentally breaks the code in non-obvious way. He pushes the code to main repository. Next time, everyone else checks out the latest version of the code and starts having weird problems. If you had 20 people on team, and they each wasted 2 hours because the code was broken, well, you just wasted a week of programmer time. How do you prevent it? In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this.
  - 10y ago
bencoman71 10y ago
> * Tests are now common and considered a good thing. A new contributor can write code without worrying about breaking rarely-used functionality. btw, xUnit testing originated with Smalltalk. https://en.wikipedia.org/wiki/SUnit https://en.wikipedia.org/wiki/SUnit > * Many languages have package managers. Using latest third-party library is now simple Metacello is Pharo's tool for defining dependencies between libraries [1][2]. [1] http://sleepycoders.blogspot.com.au/2013/10/dead-simple-intro-to-metacello.html http://sleepycoders.blogspot.com.au/2013/10/dead-simple-intr... [2] http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/late... > * We have great deployment mechanisms -- one-command deployments are common, containers and version pinning help reproducibility. Pharo Catalog provides a GUI one click installer of Metacello configurations https://pbs.twimg.com/media/CHajfSAWUAEpCBM.png https://pbs.twimg.com/media/CHajfSAWUAEpCBM.png You can also load Metacello configurations from the command line per last snippet of [1] Metacello provides version pinning. You might consider every Smalltalk Image to be a container. Its like a uni sports tour. What happens in the Image, stays in the Image ;) > * Some languages come with support for interactive REPL -- you can evaluate arbitrary commands inside running processes. As you say, Smalltalk has a super REPL. How easy is it for other REPLs to modify and query the code of the system? For example in Pharo if I define a class and methods like this... Object subclass: #MyClass instanceVariableNames: 'count' classVariableNames: '' package: 'Demo'. MyClass compile: 'setCount: anInteger count := anInteger'. MyClass compile: 'getPlusFive ^count + 5'. I can do this... obj := MyClass new. obj setCount: 3. obj getPlusFive inspect. ==> 8 MyClass methods asString ==> '{MyClass>>#getPlusFive. MyClass>>#setCount:}' > What can smalltalk offer? Obviously it has great REPL. Anything else? > What is the cool new 'software development process' feature that you are referring to? For me, the greatest thing about Smalltalk is the very tight code/compile/debug loop. Indeed, its common to "code from within the debugger" where you compile your first method calling methods that don't exist yet, and when execution hits them, the system asks you to define that method and then continues execution. This is great for protoyping and (purely subjective) I feel program architecture ends up being closer to how a "user" of the library would like it layered. A video by someone outside the Pharo community (Avdi has published several books on Ruby) shows a bit of this [3] https://www.youtube.com/watch?v=HOuZyOKa91o&t https://www.youtube.com/watch?v=HOuZyOKa91o&t Now this is not "cool and new" for Smalltalk. It has had this since 1980. But its a "blub" [4] feature that not many people get exposed to. The saying goes "the only languages worth learning are those that change how you think about programming". And for me, this is what changed how I thought about programming. [4] http://paulgraham.com/avg.html http://paulgraham.com/avg.html > For example, I have found exactly one sentence about version control and sharing in the article you have linked: "We may even see Pharo 7, which promises a Git-integration tool called Iceberg for source code version control." . Is this what you wanted to show me? Because my takeaway is that the only way to work on Smalltalk software as a team is to use file-based tools (git). I see no improvements in software development process here. Git interaction is not what Pharo is selling a better development process. But its an important thing for the Pharo community to make it easier to participate in polygot projects. Historically one of the common criticisms that Smalltalk was insular and didn't play well with others. Monticello had three-way merge for a long time so we were able to live a long time without external version control. Monticello works well for small teams, but doesn't scale well to Internet size teams. We've now recognized those other advances and fixing those reasons "not to use Pharo." The advantage of Pharo is not so much inter-developer processes. Its simliar to other languages, especially now we are integrating. Pharo's benefit is improving the "flow" of moving thoughts into code. The very tight code/compile/debug loop and minimal syntax reduces the friction of coding. I heard of a few projects where clients initially resistant to the use of "new" technology like Pharo, but accepted using Pharo to prototype with - but in the end were very happy to leave it all in Pharo. > The other commenter mentioned Monticello and Smalltalk Hub. Ok, this looks like a decent version control system. > It is interesting how without files, you have to add a prefix to a name of every class and tag each function which you want checked in. Still, I could not find which features it has that git does not. This prefixing of class names has nothing to do with sans-files. It is just that Pharo does not have namespaces. This does leave the potential for name classes, but in practice the prefixing works well. btw, as another minor demonstration of Pharo REPL, you can change every reference to the class in one line like this... MyClass rename: 'OtherClass'. obj := OtherClass new. obj setCount: 5. obj getPlusFive inspect. ==> 10

by theamk 10y ago

db48x 10y ago

Most of those "advances" have nothing to do with files or images at all. For testing it doesn't matter where the tests come from. Certainly some test environments look for tests in files with predetermined names, or in particular directories, but that's an implementation detail. Look at Rust for a modern compiled file-based language that completely avoids that; instead you tag individual functions with metadata to indicate that they are tests. At build time you can create both a normal binary and a test binary; the first is the program you wrote, the second runs the tests that you wrote. REPLs and a mixed compiler/interpreter were both invented by Lisp, which is largely image-based. They go hand-in-hand; code you enter at the REPL might start out interpreted, but you can always call the compiler (at run time) to speed up functions you care about (or let the system do it automatically). The static vs dynamic language divide has nothing to do with how the code is stored, but historically languages with REPLs have indeed been dynamic languages. I don't know about Smalltalk specifically, but Common Lisp has a great package system, and with Quicklisp it's a fully modern one with automatic package installation, dependency management, version pinning, and everything. Of course, Common Lisp these days is a hybrid system. Your code is stored in files, and when you load them into memory to create an image. If you care about startup time you can dump that image out so that it loads all at once. Quicklisp just has to download a tarball of files and stick them in your load path for you; I don't know precisely this is done in Smalltalk. Both Lisp and Smalltalk have a facility for writing code out to a file to be printed, sent across the network, etc. This is how collaboration is done. You write the code in your environment, test it, etc. Then you write it out to a file and send it to whoever. (Or your version control system puts it in a file for you when you commit, etc.)

theamk 10y ago
Well, I was responding to specific parent's statement: "Being shackled to existing file-based tools holds you back from improving the software development process." This seems to imply to me that non-file-based tools have some other improvements to software development process. I think both you and I agree that software development process improves mostly independently from file-based/image distinction. There are no visible ways when files are "holding back" the software development.
- bencoman71 10y ago
  Everyone sees the world through their own eyes, filtered by what their past and what know. A peculiar perspective of Smalltalk programmers is to consider that "code in files is dead code". External tools are needed to query it, modify it, compile it. In Pharo you can evaluate... Integer methods first inspect and in different tabs you can see this method's source code, the AST, the compiled bytecode. Or in a similar way we can look at how PLUS is implemented by evaluating (Integer>>#+) inspect Or look at all the methods that use PLUS #+ senders inspect Within Smalltalk, classes and methods are themselves objects. You can operate on them like any other object. They are ALIVE!!! AHAhahaHaaaaa :)

nathanjames 10y ago

The improved process is not in how it can emulate the way you've done things for decades with file-based tools. It's in the conceptual nature of programming, as well-explained by Bret Victor: https://youtu.be/8pTEmbeENF4 https://youtu.be/8pTEmbeENF4 - Software development using files and folders is absolutely antediluvian. Smalltalk does everything in a universe of objects; source code is organized spatially rather than in long reams residing in text files. - Live coding and debugging done right is an enormous and unparalleled productivity booster. - Persisting execution state is extremely convenient for maintaining continuity, and hence the high velocity of development. Governments and enterprises have long used Smalltalk to write massive applications in large team environments using Smalltalk's own tooling for collaboration and version control. There's no question that historically Smalltalk has not played well with the outside (file-based) world, and this has been a major point of contention. If you insist on using Git and similar tools with Smalltalk, then yes, this is problematic. The point is, if you view software development from only one perspective, you deny any possibility of improving the process in other ways that can lead to dramatically improved productivity, accelerated development, and lowered cognitive stress.

theamk 10y ago
Sorry, I am at work right now and don't have time to watch videos. Can you tell me more about "Smalltalk's own tooling for collaboration and version control"? Are you referring to Monticello? I am not insisting on git, but Monticello seems pretty limited in term of collaboration. I see commit, diff, checkout, and remote pull/push. Specifically, let's imagine this scenario: we have team of tens of programmers working on a project. A new team member joins and accidentally breaks the code in non-obvious way. He pushes the code to main repository. Next time, everyone else checks out the latest version of the code and starts having weird problems. If you had 20 people on team, and they each wasted 2 hours because the code was broken, well, you just wasted a week of programmer time. How do you prevent it? In file-based word, the answer is tests and CI. What is the smalltalk way? And please do not say "It's in the conceptual nature of programming" -- if the scenario makes no sense in the smalltalk world (maybe you are not supposed to have 20 people working on the same project?) please say this.
- 10y ago

bencoman71 10y ago

> * Tests are now common and considered a good thing. A new contributor can write code without worrying about breaking rarely-used functionality. btw, xUnit testing originated with Smalltalk. https://en.wikipedia.org/wiki/SUnit https://en.wikipedia.org/wiki/SUnit > * Many languages have package managers. Using latest third-party library is now simple Metacello is Pharo's tool for defining dependencies between libraries [1][2]. [1] http://sleepycoders.blogspot.com.au/2013/10/dead-simple-intro-to-metacello.html http://sleepycoders.blogspot.com.au/2013/10/dead-simple-intr... [2] http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/late... > * We have great deployment mechanisms -- one-command deployments are common, containers and version pinning help reproducibility. Pharo Catalog provides a GUI one click installer of Metacello configurations https://pbs.twimg.com/media/CHajfSAWUAEpCBM.png https://pbs.twimg.com/media/CHajfSAWUAEpCBM.png You can also load Metacello configurations from the command line per last snippet of [1] Metacello provides version pinning. You might consider every Smalltalk Image to be a container. Its like a uni sports tour. What happens in the Image, stays in the Image ;) > * Some languages come with support for interactive REPL -- you can evaluate arbitrary commands inside running processes. As you say, Smalltalk has a super REPL. How easy is it for other REPLs to modify and query the code of the system? For example in Pharo if I define a class and methods like this... Object subclass: #MyClass instanceVariableNames: 'count' classVariableNames: '' package: 'Demo'. MyClass compile: 'setCount: anInteger count := anInteger'. MyClass compile: 'getPlusFive ^count + 5'. I can do this... obj := MyClass new. obj setCount: 3. obj getPlusFive inspect. ==> 8 MyClass methods asString ==> '{MyClass>>#getPlusFive. MyClass>>#setCount:}' > What can smalltalk offer? Obviously it has great REPL. Anything else? > What is the cool new 'software development process' feature that you are referring to? For me, the greatest thing about Smalltalk is the very tight code/compile/debug loop. Indeed, its common to "code from within the debugger" where you compile your first method calling methods that don't exist yet, and when execution hits them, the system asks you to define that method and then continues execution. This is great for protoyping and (purely subjective) I feel program architecture ends up being closer to how a "user" of the library would like it layered. A video by someone outside the Pharo community (Avdi has published several books on Ruby) shows a bit of this [3] https://www.youtube.com/watch?v=HOuZyOKa91o&t https://www.youtube.com/watch?v=HOuZyOKa91o&t Now this is not "cool and new" for Smalltalk. It has had this since 1980. But its a "blub" [4] feature that not many people get exposed to. The saying goes "the only languages worth learning are those that change how you think about programming". And for me, this is what changed how I thought about programming. [4] http://paulgraham.com/avg.html http://paulgraham.com/avg.html > For example, I have found exactly one sentence about version control and sharing in the article you have linked: "We may even see Pharo 7, which promises a Git-integration tool called Iceberg for source code version control." . Is this what you wanted to show me? Because my takeaway is that the only way to work on Smalltalk software as a team is to use file-based tools (git). I see no improvements in software development process here. Git interaction is not what Pharo is selling a better development process. But its an important thing for the Pharo community to make it easier to participate in polygot projects. Historically one of the common criticisms that Smalltalk was insular and didn't play well with others. Monticello had three-way merge for a long time so we were able to live a long time without external version control. Monticello works well for small teams, but doesn't scale well to Internet size teams. We've now recognized those other advances and fixing those reasons "not to use Pharo." The advantage of Pharo is not so much inter-developer processes. Its simliar to other languages, especially now we are integrating. Pharo's benefit is improving the "flow" of moving thoughts into code. The very tight code/compile/debug loop and minimal syntax reduces the friction of coding. I heard of a few projects where clients initially resistant to the use of "new" technology like Pharo, but accepted using Pharo to prototype with - but in the end were very happy to leave it all in Pharo. > The other commenter mentioned Monticello and Smalltalk Hub. Ok, this looks like a decent version control system. > It is interesting how without files, you have to add a prefix to a name of every class and tag each function which you want checked in. Still, I could not find which features it has that git does not. This prefixing of class names has nothing to do with sans-files. It is just that Pharo does not have namespaces. This does leave the potential for name classes, but in practice the prefixing works well. btw, as another minor demonstration of Pharo REPL, you can change every reference to the class in one line like this... MyClass rename: 'OtherClass'. obj := OtherClass new. obj setCount: 5. obj getPlusFive inspect. ==> 10