7 ms·

I went through the MOOC material and tried it out for a few small things. It inherited a lot of the unique Smalltalk features which make it sort of alienating t

I went through the MOOC material and tried it out for a few small things. It inherited a lot of the unique Smalltalk features which make it sort of alienating to a modern programmer. For instance, all your code resides in an image file, and if you want a copy of your code the environment does some extra epicycles to copy it outside. The choice to make everything a message, including basic flow control takes some getting used to. As you just sort of hack your image to do what you want, it just sort of turns into a ball of mud. The paradigm they're going for is TDD for everything. Personally, I feel this is a big step backwards from most mainstream scripting languages adding on type annotations. It's not easy to use a simple text editor. You pretty much have to use their integrated environment. Then, there were a few problems that were specific to Pharo. Pharo went through a couple different package systems and the different package systems don't necessarily have the same packages. Pharo has had major breaking changes in their GUI toolkit, so if you found a package that did exactly what you wanted and were able to install it, it just wouldn't work.

fmakunbound 5y ago
> a copy of your code the environment does some extra epicycles to copy it outside Iceberg https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg is the Git/etc. integration built into Pharo and works extremely well. You don't need to "file out" code if that's what you meant.
- scotty79 5y ago
  Do you have any examples of Pharo github repositories created with Iceberg? What do they even contain? Does Pharo even have a notion of source file?
  - kencausey 5y ago
    The github link in the comment above is one such example.
    - scotty79 5y ago
      On the screens in Getting started tutorial I found this: https://github.com/pharo-spec/Spec https://github.com/pharo-spec/Spec
  - igouy 5y ago
    > Does Pharo even have a notion of source file? Same as other Smalltalk implementations — VM + .image file & .sources file & .changes file. .image is a snapshot/cache .changes is recovery log text of what has been done with the .image file .sources is source code text for the .image smapshot
    - galaxyLogic 5y ago
      But, you wouldn't want to store the .sources or even .changes into git would you? The git-way is to have many small(ish) files so that you can merge them easily to another development branch. Having just 2 files in git doesn't seem to make sense. I don't know how Pharo does it but I could see that every class had its own source-file, committed to git ?
      - igouy 5y ago
        Sorry I don't have experience using Pharo with Git, so the best I can do is offer a book that Goole would have found -- https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-ManageCode.pdf https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-Ma...
      - urthor 5y ago
        Don't think of it as trading source files. Think of it as version controlling a package of class definitions. The whole idea with Smalltalk and Pharo is that you don't have files. You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub. The answer is that each class definition should be seen as an atomic unit with its own version control history. Smalltalk/Pharo intrinsically doesn't focus on dealing with the Unix filesystem, because the Unix filesystem is what C deals with. And yes, the answer is Iceberg exports the package of class definitions as a text file.
        imtringued 5y ago
        >You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub. What prevents the pharo guys from simply providing their own merge tool and letting git call it? The only remaining issue then is showing a file system tree and diffs out of the image e.g. a simple export that doesn't necessarily even have to be importable.
andjd 5y ago
This is kinda the point of smalltalk. It's a radically different programming model _and_ paradigm than most C-derived languages. If you're looking for a language that feels comfortable to developers with a background in [insert widely-deployed language here], there are better options for you. Smalltalk has been around for over 40 years, which makes it a contemporary to C. Just like FORTRAN or COBOL, there's a corpus of deployed code, and institutions that are invested in a maintained runtime, but that dosen't mean that you would necessarily want to use it for a new project today. A lot of the great things about smalltalk, such as block syntax for anonymous functions, have been copied into many modern programming languages, and we probably wouldn't have them without smalltalk taking it's unconventional approach. > The paradigm they're going for is TDD for everything. Personally, I feel this is a big step backwards from most mainstream scripting languages adding on type annotations. So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all. Put another way, it's a concession of these languages to try and be everything for everyone. But statically typed complied languages do not provide an inherently better programming paradigm than dynamic programming. Smalltalk commits further and deeper to a live, dynamic programming experience. It's different, and I don't feel like saying that it fails to conform to expectations brought in from other, very different programming paradigms is a meaningful criticism of the language.
- theamk 5y ago
  > So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages ... Nope, this is not true. I am personally pushing to add types to our Python codebase, and I have no love for "Java, C-Sharp and other enterprisy languages". It's just that as the codebase grows, and especially as number of contributors grows, people start to make more mistakes. A rarely used code path, like an error handler, might fail in production because of wrong type or missing argument. We can require unit tests with 100% coverage, but this is very hard -- and typing linter finds you many more bugs per effort spent. That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. But as you move to production, don't understimate typecheckers -- they can help a lot.
gjvc 5y ago
> The paradigm they're going for is TDD for everything. Smalltalk facilitated Kent Beck's invention of TDD.
zelphirkalt 5y ago
For version control they have Iceberg, which should allow you to use git for your projects. It doesn't have to be all in an image.
igouy 5y ago
> As you just sort of hack your image to do what you want, it just sort of turns into a ball of mud. No, it doesn't just turn into a ball of mud all-by-itself. As you said, we can export our app code and bake a new working image (vendor image + our app code — kind-of like a container, kind-of like a reproducible development process.)
mark_l_watson 5y ago
As a very long time occasional Smalltalk user (on my 1108 Lisp Machine, Commercial on early Mac, later Squeak, then Pharo), I agree with you, except that Pharo has nice git integration that I can recommend spending the time to set up. Also, I used to create Squeak headless standalone applications - plenty of tutorial material for this. Lisp used to get a similar bad rap, but SBCL has good app packaging available and the commercial LispWorks makes it easy to build small standalone apps.
musicale 5y ago
> It inherited a lot of the unique Smalltalk features Because it is a version of Smalltalk.

fmakunbound 5y ago

> a copy of your code the environment does some extra epicycles to copy it outside Iceberg https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg is the Git/etc. integration built into Pharo and works extremely well. You don't need to "file out" code if that's what you meant.

scotty79 5y ago
Do you have any examples of Pharo github repositories created with Iceberg? What do they even contain? Does Pharo even have a notion of source file?
- kencausey 5y ago
  The github link in the comment above is one such example.
  - scotty79 5y ago
    On the screens in Getting started tutorial I found this: https://github.com/pharo-spec/Spec https://github.com/pharo-spec/Spec
- igouy 5y ago
  > Does Pharo even have a notion of source file? Same as other Smalltalk implementations — VM + .image file & .sources file & .changes file. .image is a snapshot/cache .changes is recovery log text of what has been done with the .image file .sources is source code text for the .image smapshot
  - galaxyLogic 5y ago
    But, you wouldn't want to store the .sources or even .changes into git would you? The git-way is to have many small(ish) files so that you can merge them easily to another development branch. Having just 2 files in git doesn't seem to make sense. I don't know how Pharo does it but I could see that every class had its own source-file, committed to git ?
    - igouy 5y ago
      Sorry I don't have experience using Pharo with Git, so the best I can do is offer a book that Goole would have found -- https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-ManageCode.pdf https://books.pharo.org/booklet-ManageCode/pdf/2020-05-12-Ma...
    - urthor 5y ago
      Don't think of it as trading source files. Think of it as version controlling a package of class definitions. The whole idea with Smalltalk and Pharo is that you don't have files. You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub. The answer is that each class definition should be seen as an atomic unit with its own version control history. Smalltalk/Pharo intrinsically doesn't focus on dealing with the Unix filesystem, because the Unix filesystem is what C deals with. And yes, the answer is Iceberg exports the package of class definitions as a text file.
      - imtringued 5y ago
        >You have class definitions, and these are only version controlled in text files as a concession to the extreme populatity of GitHub. What prevents the pharo guys from simply providing their own merge tool and letting git call it? The only remaining issue then is showing a file system tree and diffs out of the image e.g. a simple export that doesn't necessarily even have to be importable.

andjd 5y ago

This is kinda the point of smalltalk. It's a radically different programming model _and_ paradigm than most C-derived languages. If you're looking for a language that feels comfortable to developers with a background in [insert widely-deployed language here], there are better options for you. Smalltalk has been around for over 40 years, which makes it a contemporary to C. Just like FORTRAN or COBOL, there's a corpus of deployed code, and institutions that are invested in a maintained runtime, but that dosen't mean that you would necessarily want to use it for a new project today. A lot of the great things about smalltalk, such as block syntax for anonymous functions, have been copied into many modern programming languages, and we probably wouldn't have them without smalltalk taking it's unconventional approach. > The paradigm they're going for is TDD for everything. Personally, I feel this is a big step backwards from most mainstream scripting languages adding on type annotations. So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages who would probably rather not work in a dynamic language at all. Put another way, it's a concession of these languages to try and be everything for everyone. But statically typed complied languages do not provide an inherently better programming paradigm than dynamic programming. Smalltalk commits further and deeper to a live, dynamic programming experience. It's different, and I don't feel like saying that it fails to conform to expectations brought in from other, very different programming paradigms is a meaningful criticism of the language.

theamk 5y ago
> So, the push to add types to JS, Python, Ruby and other dynamic languages is largely from developers accustomed to Java, C-Sharp, and other enterprisy languages ... Nope, this is not true. I am personally pushing to add types to our Python codebase, and I have no love for "Java, C-Sharp and other enterprisy languages". It's just that as the codebase grows, and especially as number of contributors grows, people start to make more mistakes. A rarely used code path, like an error handler, might fail in production because of wrong type or missing argument. We can require unit tests with 100% coverage, but this is very hard -- and typing linter finds you many more bugs per effort spent. That does not mean that we should always specify every type in program explicitly, like Java does. Unspecified types are great for interactive exploration, or a quick hack. But as you move to production, don't understimate typecheckers -- they can help a lot.

gjvc 5y ago

> The paradigm they're going for is TDD for everything. Smalltalk facilitated Kent Beck's invention of TDD.

zelphirkalt 5y ago

For version control they have Iceberg, which should allow you to use git for your projects. It doesn't have to be all in an image.

igouy 5y ago

> As you just sort of hack your image to do what you want, it just sort of turns into a ball of mud. No, it doesn't just turn into a ball of mud all-by-itself. As you said, we can export our app code and bake a new working image (vendor image + our app code — kind-of like a container, kind-of like a reproducible development process.)

mark_l_watson 5y ago

As a very long time occasional Smalltalk user (on my 1108 Lisp Machine, Commercial on early Mac, later Squeak, then Pharo), I agree with you, except that Pharo has nice git integration that I can recommend spending the time to set up. Also, I used to create Squeak headless standalone applications - plenty of tutorial material for this. Lisp used to get a similar bad rap, but SBCL has good app packaging available and the commercial LispWorks makes it easy to build small standalone apps.

musicale 5y ago

> It inherited a lot of the unique Smalltalk features Because it is a version of Smalltalk.