6 ms·

Being shackled to existing file-based tools holds you back from improving the software development process. In the past several decades, we've seen incremental

by horrido 10y ago

Being shackled to existing file-based tools holds you back from improving the software development process. In the past several decades, we've seen incremental improvements but nothing really earth-shattering. Do you really believe we'll still be using file-based tools for software development 50 or 100 years from now? Smalltalk is the future of software development created 45 years in the past. See https://medium.com/smalltalk-talk/smalltalk-and-the-future-of-the-software-industry-3f69cac13e5a https://medium.com/smalltalk-talk/smalltalk-and-the-future-o....

setr 10y ago
>Smalltalk is the future of software development created 45 years in the past. So doesn't that imply that Smalltalk was wrong to think we wouldn't be using file-based tools in 50 years..?
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.

by horrido 10y ago

setr 10y ago

>Smalltalk is the future of software development created 45 years in the past. So doesn't that imply that Smalltalk was wrong to think we wouldn't be using file-based tools in 50 years..?

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.