Back in university, I did an introductory course in Smalltalk/Squeak as well as three seminars that used Smalltalk, two of which were group projects. (One chair was heavily invested into Smalltalk)
I won't use Smalltalk/Squeak professionally, and I've come to enjoy functional programming much more than OO programming (at least for non-UI tasks, which I generally enjoy more). That said, I do not regret learning and investing time into Smalltalk [1].
I'm dismissing the syntax-argument, as Obj-C has brought a Smalltalk-like syntax into the mainstream [2].
The one thing that I REALLY miss about Smalltalk sometimes is the ease of working with (stored) objects. You basically don't have to do anything. So much CRUD - just removed. I don't know how much time I wasted debugging or optimizing Hibernate-stuff in Java, or wrestling with CoreData in iOS.
With Smalltalks image, you just don't have to waste ANY braincycles on storing your data [3]. If you've created the object in memory, consider it stored. If you remove the last reference to it, consider it deleted. It's just so much more natural (for an OO program) than working with an ORM.
However, the image in Squeak was, in fact, the most difficult thing to get used to. The image contains not only your runtime, it is also your IDE. As an IDE, it had some good parts (similar to a browser where you can inspect any HTML-element, you can inspect any (visual) object with a right click), and after a while I was kinda OK with navigating the (not file-based) code. That said, it does neither rival a full-blown IDE nor Vim - the IDE always kept disturbing my flow somehow. And, with limiting your methods to a maximum of 7 lines of code, you're bound to use the IDE a lot.
> It's also hard to isolate a "program" in Smalltalk -- it's all one big heap of code, you may have added methods to Object, who knows what.
This hasn't been my experience at all. If you use some sort of versioning (we used SVN), you'll have to separate your code from your workspace. I don't remeber it to be any harder than it is in a traditional environment (do a diff before you check-in to make sure you've cleaned up everything and if your code/unit tests use any non-code files, make sure to check them in as well).
[1] In fact, I'd recommend anyone who is serious about becoming a good programmer to learn several (>3) distinctly different programming languages (i.e. Java and C# are too similar to count). And Smalltalk is really different, not only syntax-wise but conceptually a lot of stuff will broaden one's horizon.
[2] Thankfully, it's being replaced by Swift now. I've worked with it in the last 3 weeks, but I'm more happy to see the C-stuff go and functional programming concepts arrive than the Smalltalk-stuff removed.
[3] Well, for a certain scale at least... not feasible for Big Data, but sufficient for your average mobile or desktop app.
I won't use Smalltalk/Squeak professionally, and I've come to enjoy functional programming much more than OO programming (at least for non-UI tasks, which I generally enjoy more). That said, I do not regret learning and investing time into Smalltalk [1].
I'm dismissing the syntax-argument, as Obj-C has brought a Smalltalk-like syntax into the mainstream [2].
The one thing that I REALLY miss about Smalltalk sometimes is the ease of working with (stored) objects. You basically don't have to do anything. So much CRUD - just removed. I don't know how much time I wasted debugging or optimizing Hibernate-stuff in Java, or wrestling with CoreData in iOS.
With Smalltalks image, you just don't have to waste ANY braincycles on storing your data [3]. If you've created the object in memory, consider it stored. If you remove the last reference to it, consider it deleted. It's just so much more natural (for an OO program) than working with an ORM.
However, the image in Squeak was, in fact, the most difficult thing to get used to. The image contains not only your runtime, it is also your IDE. As an IDE, it had some good parts (similar to a browser where you can inspect any HTML-element, you can inspect any (visual) object with a right click), and after a while I was kinda OK with navigating the (not file-based) code. That said, it does neither rival a full-blown IDE nor Vim - the IDE always kept disturbing my flow somehow. And, with limiting your methods to a maximum of 7 lines of code, you're bound to use the IDE a lot.
> It's also hard to isolate a "program" in Smalltalk -- it's all one big heap of code, you may have added methods to Object, who knows what.
This hasn't been my experience at all. If you use some sort of versioning (we used SVN), you'll have to separate your code from your workspace. I don't remeber it to be any harder than it is in a traditional environment (do a diff before you check-in to make sure you've cleaned up everything and if your code/unit tests use any non-code files, make sure to check them in as well).
[1] In fact, I'd recommend anyone who is serious about becoming a good programmer to learn several (>3) distinctly different programming languages (i.e. Java and C# are too similar to count). And Smalltalk is really different, not only syntax-wise but conceptually a lot of stuff will broaden one's horizon.
[2] Thankfully, it's being replaced by Swift now. I've worked with it in the last 3 weeks, but I'm more happy to see the C-stuff go and functional programming concepts arrive than the Smalltalk-stuff removed.
[3] Well, for a certain scale at least... not feasible for Big Data, but sufficient for your average mobile or desktop app.