horrido

The word "own" is pretty meaningless. What does "own" even mean? Classes and objects (thought of as "types") are an organizing principle for organizing your functions. If you didn't organize them in this manner, then you'd have the same functions that operate on the same data types, only they're scattered everywhere, just like in functional programming.

And why is "common discussion" technically relevant? This is not a fault of OOP but of education.

It's Uncle Bob who says objects are bags of functions. And this is not specific to Smalltalk nor dynamic languages. In Java, C#, and C++, objects are still just bags of functions.

Nothing prevents an object's methods from being referentially transparent. It just depends on how you choose to write them.

Starting points matter, but this depends on the programming situation. That's why you use OOP or FP where it is most appropriate or suitable. Neither OOP nor FP is a panacea. Neither OOP nor FP is the universal programming tool.

Inheritance is not a strict requirement of OOP. In OOP, you can always use composition, in which case the question also never arises.

Inheritance is there if you need it. It's an available option.

It has nothing to do with ownership. In FP, a function can only operate on data of a particular type. In OOP, a particular type (or class) gathers all the applicable functions (or methods) under one roof. Same difference.

Nice!

Would you mind if I used this?

A few important points:

1. Breaking code is nothing specific to a language. The usual weapon also in Smalltalk is to monitor if something breaks - for instance by using CI. Continuous integration only makes real sense when you have tests.

    One should remember that "test first", "unit testing" and "Extreme programming" (XP)
    like many other things had their roots in Smalltalk. Because in dynamic
    languages testing using code was and is part of the culture (ranging from lively verifying
    with workspace expressions and inspectors up to fully written tests).

    The first unit testing framework "SUnit" was written by Kent Beck for
    Smalltalk (SUnit), later he ported it to Java with Erich Gamma on a flight
    to OOPSLA OO conference. Java helped to push the popularity afterwards.

    Meanwhile also static language enthusiasts have understood that it is better to
    rely on tests than type checking compilers and they now hurry up to follow
    what Smalltalk already had years ago.

    One last thing you should try: try to query your system how many test methods were
    written. When you solved this easily with a Smalltalk expression retry
    this in Java ;)

 2. Commercial Smalltalks which are often used in big projects provide solutions
    which are repository based like the famous ENVY (written by OTI, was
    in VisualAge for Smalltalk from IBM, now VAST) or Store (VisualWorks). For
    more details try the commercial evaluation versions or read [1] or [2].
    A screenshot of Envy can be seen in [3]. I worked with ENVY and it is really
    good - but mostly only for internal work/teams. If I remember correctly
    ENVY once was also available for VisualWorks (VW) ... but later got replaced
    for business or license reasons. I'm not sure about that point.

    Cincom developed Store for VW as a replacement which is also nice as it allows to work
    in an occasionally-connected mode, so work offline and push packages/versions later to
    a central team repo.

    In the open source world there are different solutions (including Monticello
    which is available for nearly all Smalltalk derivates) or newer solutions
    like FileTree or Iceberg allowing to work with Git.

    The workflow depends on the tool and your requirements.

 3. Often it makes sense to automatically build and regular distribute a fresh daily
    developer images to the members of your team. This helps in later merging
    code.
    For instance Kapital (a big financial project from JP Morgan) works that
    way and I've seen that model very often. See [4]

    Again nothing special to Smalltalk. In more file based languages it also makes
    sense to stay close to the main line and merge as well as resynchronize with the
    team.

    In Pharo for instance we have the PharoLauncher that allows you to download
    any (fresh or old) image built provided by the open source community.

 3. Versioning can be done on many levels. Simplest level is the image itself.
    Smalltalk not only has an VM and image concept - but also the concept of a changes
    file. If you evaluate a code expression, create or modify a class or method
    in the system this gets logged there.
    It prevents you from loosing code and it is easy to restore quickly for instance
    an earlier method versions/editions that one has implemented.

    Most Smalltalks now also work with packages and you can define package
    dependencies as well as declaring versions that fit together to provide
    a project, goodie or app (for instance with a Configuration class in Monticello)

    While in file based languages this is often done in an XML file (Maven for instance)
    or a JSON file in Smalltalk this is usually expressed with objects and classes again.
    This also makes it more flexible as you can very easily do queries on it or
    use refactoring tools to even restructure or reconfigure.

 4. Usage of shared code repositories is very common also in Smalltalk. While you
    now can also use GitHub, GitLab, Gogs and others with Iceberg and friends in Smalltalk
    there are also repository systems implemented in Smalltalk itself like
     - SqueakSource (http://source.squeak.org, http://squeaksource.com)
     - SqueakSource3 (http://ss3.gemtalksystems.com)
     - SmalltalkHub (http://smalltalkhub.com)

 5. Beside repositories where code and goodies are hosted one often finds registries
    with infos about loadable components.

    Pharo for instance has http://catalog.pharo.org which is accessible also
    directly from the image.

 5. If you work in a team you can also use a custom update stream. This is how
    for instance open source projects like Pharo and Squeak are managed.
    So anyone can hit an "update" button to get the latest changes.

    In Pharo http://updates.pharo.org is used and you can have a look at UpdateStreamer
    class to see how easy that works over the web or how to customize it for own needs.

 7. If one requires not only collaboration for the development team (coding) but
    would like to collaborate also with other projects members on other artefacts
    (Excel, project plans, documents, ...) then one should have a look at tools like this

    http://www.3dicc.com

    which is implemented in - guess what: SMALLTALK.

This list could be endless ... the first few points should only give a glimpse on what is there and available.

[1] https://www.cambridge.org/core/books/mastering-envydeveloper... [2] http://www.cincomsmalltalk.com/main/documentation/VisualWork... [3] http://www.edm2.com/index.php/Installing_the_VisualAge_UML_D... [4] http://www.slideshare.net/esug/13-yanndmonclair

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-o....

Exactly what I was thinking.

Java is currently the most popular language in the world. There are far more job postings for Java than for any other programming language. Java is the enterprise standard language. Java has a tremendous ecosystem and a vast user community. Java is pretty much unassailable.

However, in 1995 Java was nothing more than a hopeful upstart from Sun Microsystems. There were no job opportunities for it. It had no ecosystem to speak of and relatively few users. Performance-wise, it ran like a slug (today, the JVM is well-optimized). How did Java achieve today's status?

To a large extent, it was thanks to Sun Microsystem's marketing efforts. People were drawn to the promise of "write once, run everywhere." They also liked that Java was a fairly simple and easy-to-learn language. In time, Java developed a large community and widespread usage.

The point is, all programming languages have to start from zero. They either grow from grassroots, or they grow from corporate sponsorship and marketing. Incumbent languages with their large ecosystems and user communities eventually yield to newer languages with their promise of greater ease, productivity, flexibility, power, etc. Getting the job done is important, but one should also look to the future. That's the hope of languages such as Go, Swift, Dart, Julia, Rust, Elixir, Smalltalk, and so on.

The material is available in both French and English. The videos have English subtitles. There is no language difficulty.

You're over-generalizing. This is very much a matter of personal taste/inclination. Do ALL Lispers love the Lisp style of syntax? Of course not.

Moreover, for many programmers, it's asking too much of them to wrap their heads around a syntax where you need to give it time for the parens to "fade" away. This cognitive hurdle is real and it's why Lisp isn't more popular.

Let's not bury our heads in the sand.

In the article, I linked to: http://techbeacon.com/how-learning-smalltalk-can-make-you-be.... This is where you'll see an example of Smalltalk code.

Many programmers obsess over performance, but the fact is, in today's computing world, performance is a non-issue in most situations. That's why Python, PHP, Ruby, and Perl are so useful and popular. That's why Erlang/Elixir absolutely rock for concurrent systems. That's why Smalltalk is used commercially around the world. Performance is not the be-all, end-all of computing.

Try this Pharo MOOC: http://files.pharo.org/mooc/

The actual course is over, but all the course material is still available. It's an excellent resource.

"It's often argued the impedance mismatch with version control is what killed Smalltalk."

Wrong argument. Here's the truth: https://medium.com/smalltalk-talk/why-smalltalk-failed-to-do...

Smalltalk does have version control. It's just not the same version control software that everybody else uses (eg, Git, Subversion, etc.).

I've never made any bones about this. Of course, I'm an evangelist.

The size of the Smalltalk user base isn't large enough to support a healthy ecosystem. Hence, the reason for my evangelism to grow the community!

Another issue is fragmentation: there are too many dialects. That's why I generally promote Pharo, which is the largest open source Smalltalk. If I can get developers to rally around Pharo, then we will have the best chance of developing a strong ecosystem.

Smalltalk doesn't only rely on OOP. It has lambdas and closures so that you have functional capabilities, too. Not strictly multi-paradigm, but close enough. This is why Smalltalk is so powerful.

Multiple inheritance has its problems, too. I prefer the greater simplicity of single inheritance.

There was, and it's explained here: https://medium.com/smalltalk-talk/why-aren-t-people-using-sm...

Thank you for this! I learned something today. I shall have to post this in the Comment section of the article.

Unfortunately, no.

The article explains how you can be productive. It's mostly in the "live coding/debugging" environment, which dramatically shortens the edit-test-debug cycle. The low cognitive friction of the language itself is also preeminent.

The clutter-free Smalltalk IDE is one its main selling points. I've used Xcode and Eclipse and Visual Studio, and the Smalltalk IDE is a breath of fresh air. Beauty is in the eye of the beholder, and I like Smalltalk very much. Dolphin, in particular, is prized for its excellent IDE implementation.

In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here.

I use Amber Smalltalk to write cross-platform mobile apps for Android and iOS: https://medium.com/smalltalk-talk/amber-alert-we-can-do-mobi...

Smalltalk is not stuck as an academic language. Cincom and GemTalk would be very surprised to hear that. It is, and has been, used all around the world for commercial purposes for over three decades: https://medium.com/smalltalk-talk/who-uses-smalltalk-c6fdaa6...

It is possible to create shrink-wrapped distributables, but these days there really isn't much call for it. Most of the action is in the web and mobile space and IoT and so on.

Regarding performance, it was an issue prior to circa 1995, but today's hardware is more than fast enough. That's why Python and Ruby and Perl and Erlang are so popular, being no faster than Smalltalk.

The language and IDE are so simple that it takes very little effort to learn, at least, in my experience. But you're right about the class library. However, is this really any different for any OOP language that has a rich class library? Or any language that has a rich API (<cough> Java <cough> C# <cough>)?

Smalltalk documentation isn't that bad. Here's a very, very gentle tutorial: http://amber-lang.net/learn.html

Here's a great (free!) book: http://sdmeta.gforge.inria.fr/FreeBooks/ByExample/

And a great (free!) book for GNU Smalltalk: http://stephane.ducasse.free.fr/FreeBooks/Gnu/ProgrammingUsi...

And a great set of instructional videos from the late James Robertson: http://www.jarober.com/blog/st4u.ssp

And a great Pharo blog: https://medium.com/concerning-pharo

And, of course, you may ask questions at StackOverflow and the Pharo user forum: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

I don't understand what you mean. I've only ever gotten one pop-up, if even that. I've never found TechBeacon to be intrusive.

You gauge this be looking at complaints on the web. There are numerous posts about how JavaScript programmers abuse the language and don't understand the functional nature of programming. With most of the other FP languages, you hear the odd complaint now and then, but for the most part, if people tackle FP, they get it right. The worst complaint I've ever heard is that Haskell's monads are really hard to wrap one's head around.

> There are some big, bold ideas being explored in React, Angular, Om, elm, clojurescript, etc.

I'm glad you mentioned ClojureScript. I didn't successfully add this link to my previous comment because ycombinator had a hiccup, but I recommend using transpiled languages instead of JS: https://medium.com/javascript-non-grata/the-super-surrogates...

Languages like Amber, Brython, ClojureScript, Dart, Haxe and Scala.js are great alternatives to using JS.

Interesting, but it remains to be seen how many businesses will actually use HANA. Until you can identify what percentage of Fortune 500 will use HANA XS with Node, I stand by my statement.