Related
Well, I think I have enough knowledge of cocoa that I can go learn another thing. What would you recommend learning after learning cocoa? (Ex. Core animation, OpenCL, core data)
I really depends what your goals are. If you want to stick to Objective-C, dive into Cocoa Touch if you haven't already. I'd also suggest checking out frameworks such as MacRuby if you want to stick to developing Mac apps, it is pretty sweet.
If you want to go somewhere totally different, I've been messing around with Rails and Android a lot recently.
Learn LISP.
It is fundamentally different from pretty much every other programming language there is. It will force you to think of problems in new ways. Even if you never ever will use LISP in a real world project (I never did) you will become a much better programmer.
Anyone who wants to call themselves a programmer should known about (spent at least a full week with):
C - to know the heavy lifting and how it actually works.
LISP - to understand functional programming.
Smalltalk/Objective-C - to understand real object oriented programming.
Prolog - to understand logic programming.
C++, and any language that derives its OOP design from it, is just C structs with function pointers. Yes Java and C# I look at you too.
Learning PostScript is a good way to broaden your understanding of the drawing model also used by Quartz and AppKit, and can be useful for prototyping your drawing code.
Learn another language. Maybe C/C++ since they are similar. Or maybe C#. Or you can try something completely different such as python, pascal, D or VB.
depends what you aim for
but if you are not strong in C/C++ I would suggest that. A) its what cocoa is based on B) if you want to port your code to other platforms, usually you'll have a good chance of reusing directly the C/C++ withou a lot of changes.
(Ex. Core animation, OpenCL, core
data)
those are just tools, if you want to specialize in iphone then its good practice to look up the various feature, look at the examples and then implement a little example for yourself.
otherwise if you have no precise goal you can also go to the bookstore and pick a random book ^^
I've heard a few debates in the past over which is more mature: RubyCocoa or Obj-C/Cocoa... but I have felt that the answers jet right over the "newbie" that would truly appreciate an answer.
So the question is: for a total beginner, with little-to-no programming experience, is it easier to learn Ruby and explore Cocoa via the bridge (then possibly tackle Obj-C) or to straight up jump right into Objective-C and Cocoa.
Both communities are strong and have a plethora of resources, but as many people have pointed out the syntax of Obj-C is just daunting. Perhaps for a true beginner it would be easier to learn Ruby then tackle Objective-C?
Update: I apologize, but when I said "learn Ruby and explore Cocoa" I did not mean to learn programming via RubyCocoa, but rather to learn Ruby (and once one feels confident enough) begin to explore Cocoa with the possibility of leveraging their growing skill-set to tackle Obj-C.
I would not recommend learning to program with RubyCocoa.
I love Ruby and think it's a great language to learn programming, but the RubyCocoa bridge isn't documented well enough that I'd recommend it as a learning environment. You'd be learning general programming concepts, the Cocoa frameworks and the quirks of RubyCocoa all at the same time. That's a lot of stuff to shove into your head.
If you're bound and determined to start with Cocoa, start by learning Objective-C. Otherwise, you could learn Ruby to begin with and then transition to Objective-C once you feel a little more comfortable as a programmer. And once you've done all that, you can use RubyCocoa, but then you'll know enough that it won't make you go crazy.
I would start with what Apple is preaching: Objective-C/Cocoa
Writing Code is the Easy Part
No point really in:
Try to see which is easy, if you are opting for the easy way, you will always get it wrong.. fear not what is hard, for hard is to fear not.
Trying to compare languages/approaches that way, as per the post I added, thinking what's easy/nice/hard in this case is a question of syntax, which ultimately boils down to interpretation, beauty is in the eye of the beholder.
Depending on what they will ultimately attempt to do with the technology you will find somethings are "easier" than others in one approach or the other..easy is a hard thing to define
Only one question matters: What does one know before being exposed to any of the two approaches? -- you said:
for a total beginner, with little-to-no programming experience
My answer:
Often near where I live tourists ask:
"How do I get to placename X from here?"
People here usually answer:
"If I were you, and I was trying to get to placename X, I wouldn't start from here.."
So.. the answer to your question is:
Neither
Total beginners should always study the basics of programming as per what #Tafkas said.. (not necessarily needing to study OOP languages.. but programming...) before making any kind of decision on what to study and/or implement. (This + requirements gathering)
..Otherwise the people learning these language/technology skills will be just another set of script kiddies on their way to becoming copy paste code monkeys
The problem with starting with RubyCocoa is that you end up learning both ruby and cocoa and the interaction between the two at the same time. I would say learn ruby, or learn Objective-C/Cocoa. Jumping right into RubyCocoa is going to throw you off.
It sounds like your goal is to learn to program in Cocoa, using either Ruby or Objective-C as the language.
While I've never used Ruby (or RubyCocoa, for that matter), my understanding is that Cocoa is written with Objective-C as the primary language, and the bridges (Python and Ruby) come in second. While they generally work well, there are some rough edges that aren't there when using Cocoa from Objective-C.
I would say that you should go the Objective-C/Cocoa route. It might not be bad to start with another language first - C if you want to learn it (which would be useful, since Objective-C is a superset of C), or something like Java if you want to go the OO route.
That's not to say that RubyCocoa doesn't work or isn't useful. It's great for what it does, but I don't think that it is the place to start with Cocoa programming.
I would suggest that if your going to be serious about writing Applications for OSX and/or the iPhone I would highly suggest you get your feet wet with Objective-C and Cocoa.
The reason are simple:
The Documentation from Apple on Objective-C is excellent.
You're going to get more help from the community here at Stack Overflow because there are more Objective-C/Cocoa developers than RubyCocoa. (from what I've seen so far).
The Objective-C Developers are very good at helping each other out and I could not find a better group of developers with open arms to new people learning the language.
Great Developer books are available as well as outside training if you want it.
The big one that I see is that you can NOT develop for the iPhone using RubyCocoa. But if you learn Objective-C/Cocoa you can pretty much dive right into Cocoa Touch.
There is no guarantee that Apple will keep RubyCocoa updated as much as they do with Cocoa.
Don't get me wrong, learning Ruby is a great language and I don't think you can go wrong learning it. However right now if you have the option right now to learn either or, go with Objective-C/Cocoa.
I think you're in for a harder road by going with RubyCocoa if you want to build serious applications for either OS X or especially later for the iPhone.
The main reason is simply being able to find answers to common programming questions that you might have. There is a burgeoning community around Objective-C/Cocoa with a lot of forum support, code snippets, samples, etc. It will be infinitely easier for you to rapidly learn how to you use Cocoa if you understand Objective-C. It will also be easier for your peers to troubleshoot your code and help you out when you get stuck. Objective-C is really not that hard to learn, especially if you have some kind of grounding in OO concepts.
I would suggest to start with an oo language such as c++ or java. After understanding the basic comcepts of oo it should not be to hard to learn objective-c.
The problem with ruby cocoa is that there is no guarantee apple will support this in the future. They have dropped the cocoa-java bridge in the past.
I think this depends on how much the beginner already knows. If you already know object oriented programming, you should definitely learn objective-c. Thinking in paradigms like messaging, delegation, and categories will help a lot to understand the Cocoa system. If you've got a few languages under your belt, but no object oriented programming, then you probably also have enough experience to learn OOP through Cocoa, but understand that it handles things differently from languages like C++. If you have very little programming experience, then ruby may be better in the short term.
One other advantage of objective-c to keep in mind is the manual reference counting memory management paradigm. It can be much easier to deal with than malloc/free, but it doesn't allow the laziness that Java and scripting languages engender.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Do I really have to learn Objective-C to develop solid Mac Apps?
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
So do I really have to learn Objective-C ?
I would prefer a dynamic language.
Objective-C is a dynamic language, as far as the Objective-C parts go. Here's a little summary article: http://www.macdevcenter.com/pub/a/mac/2003/04/28/objective-c.html
The syntax is scary at first, but it grows on you. I suggest biting the bullet and slogging through it.
If you want to work at a "real job" doing Mac programming with other people, you're going to need to know Objective-C (in my opinion, anyway).
I think the short answer is yes, you need to learn Objective-C.
The Python and Ruby "bridges" work, but it's not what Apple is pushing or using itself. A few years ago there was a Java bridge to Cocoa but that's now deprecated. Who knows what will happen to the non-ObjC languages?
In any case, Objective C is pretty dynamic. Not in the way that Ruby/Python are perhaps, but it's certainly not like C++.
Short answer: YES :)
Our first app was built in Python, using the PyObjC bridge. From experience I can tell you that to build an application with a bridge you need to learn:
The idiosyncrasies of the bridge
To read and write code in the bridge language (Python in my case)
To read code in Objective-C (All useful sample code is in Obj-C)
To write pseudo-code in Objective-C (if you ever want to ask questions on a mailing list or likewise)
Cocoa
Of all those things to learn, Cocoa is the biggy. It's where the really interesting stuff comes in and the thing you really need to wrap your brain around. After working on this PyObjC project, it's become pretty easy for me to code in Obj-C, even though I had no prior experience coding in C.
So my advice is: Focus on learning Cocoa, and use the language that's most suited as a tool to do that (Obj-C). If you ever find a particular reason to use a bridge, such as having a need for an ORM that can deal with networked SQL, etc. you can apply around 90% of what you learned writing your first Obj-C/Cocoa app(s) in the bridged project.
Finally: I don't really understand the resistance many people who're new to the platform have to learning Objective-C. Isn't it exciting and gratifying to learn new stuff and build the best possible things armed with this new knowledge?
You definitely need to learn Objective-C even if you choose to use one of the bridges. Apple has already shown by their treatment of Java that they're not really interested in providing huge amounts of support or backwards compatibility to the use of Cocoa through anything but Objective-C.
So use one of the bridges, if you like, but have a firm grasp of the Objective-C runtime and the bridges so that you can manage them yourself, if need be.
Do I really have to learn Objective-C to develop solid Mac Apps?
Currently, yes.
As Mac users tend to use only applications that have a nice (native) GUI, i don't think that Mono and GTK+ or any Java GUI (Swing) will fit their needs.
Correct.
There are projects like Cocoa#, PyObjC and RubyCocoa, but are they ready for primetime?
Cocoa#: I don't know, as I don't use C#.
PyObjC: Sort of, but Cocoa in Python is a bit of a hack, since Python isn't Smalltalky enough.
RubyCocoa: Maybe. I'm waiting for MacRuby to mature, though. See also:
Jens Alfke on MacRuby
Jesper on MacRuby
There are a small number of successful Cocoa apps written in bridged languages, so you don't necessarily need to use it that much, but you do need to learn it. People who try to learn to write Mac OS programs in bridged languages do themselves a huge disservice. The bridged languages are great tools, but they are the sort of things that allow someone with a knowledge of the bridged language and Objective C to become extra productive, not skip learning Objective C.
In order to use something like PyObjC or MacRuby effectively you need to really have a good understanding of how the native runtime works to deal with all the impedance mismatches that can occur between the bridged language and the Objective C runtime.
Short answer is yes, longer answer is "you can use Objective-C++." Either way you're going to have to learn at least some of Objective-C. Once you start digging into Cocoa (the framework for building Mac OS X apps), the Xcode tools, and the Apple Human Interface Design guidelines, you'll realize that Objective-C is the way to go.
Not only you have to know Objective-C (the easy part), you must be very comfortable with plain old C. That's in my opinion the biggest challenge for most people.
If you already know C, Objective-C is pretty easy to learn.
Ruby and Python are both viable for "real" Mac apps. ADC has a few articles on the topic. MacRuby looks like it will be replacing RubyCocoa.
I would still recommend learning Objective-C though. Most of the example code you find will be in Objective-C and the books tend to be Objective-C (though the Pragmatic Programmers have a RubyCocoa book in the works. Most Cocoa apps are written in Objective-C.
And Objective-C is dynamic. Take a closer look at it, it isn't nearly as intimidating as people think. It's Cocoa that tends to have the steeper learning (or unlearning) curve.
No you don't have to learn cocoa however it is worth looking at because it is an incredibly powerful api and very well documented, if you already know C then its very easy (honestly it is - i know it looks daunting syntactically).
The problem with the bridged approach on OS X is it seems to be very immature and only really designed for people who are prepared to read the documentation associated with the main cocoa api.
In all honesty if you know c you will pick up the basics of obj-c with a book, the one by Arron Hilligas (spelling?!?!) is superb.
If you try hard enough, you can go about producing software without using Objective-C that has the potential to be great except for the fact that at the end of the day it won't be very good. You will spend more time trying to harangue a language into doing something that it isn't the absolute best at. At WWDC I wore a shirt that said "Learn Objective-C or Retire" which didn't go over too well with some people who still held dearly onto the last threads of Pascal's life, but the point is altogether true - Objective C is where it's at on the Mac and to pretend otherwise is to do yourself a disservice.
Having said that, you should definitely not rule out the bridges on the platform for extending your application - Bill Bumgarner is quick to point out how much power the Twisted networking framework provides to Cocoa applications via the PyObjC bridge.
Not programming in a scripting language turns out to not be so bad when you're using XCode. The GDB integration is very good; I'm primarily a Perl guy, and I find the XCode debugger very nice and very easy to use.
The "fix" feature will really surprise you with how usable it is. Imagine finding a bug in your ObjC code, fixing it, and then telling the debugger to continue on. It actually works in a lot of cases.
Try ObjC. You may find you like it a lot better than you think you will.
"have to", well... technically, no.
Since most Mac app jobs are done thro ObjC (for a very good reason I might add), I wouldn't kid yourself and learn it.
Hell no. You can use a number of languages to make a nice GUI with. It just depends on what's the usual/easiest solution for the platform. In Mac OS X's case, Objective-C and AppKit are pretty easy to use choices. However, I use REALBasic sometimes, and that allows cross platform development (and, of course, a performance hit).
So really it depends on how much work you want to put into it. You should learn Objective-C if you want to really do serious Mac development. But you can get by without it....
No. While Apple is strongly pushing Cocoa, Carbon is still supported. It uses plain C instead. As for good-looking GUIs, just use Interface Builder.
However, I must say that Objective-C is a great language. It is really easy (it was my first language) and very powerful.
In general yes; but even if you (correctly IMHO) ruled out Mono, GTK and SWING because they don't fit well in the GUI, try Qt. it's REALLY respectful of Mac GUI standards (HIG: Human Interface Guidelines), and can be equally programmed on C++, Python and Java. the last version is cocoa-based and 64-bit capable.
the only thing missing from Qt that you'd get from Objective-C is those awful non-HIG-compliant modern Apple applications (yeah, Aperture and Final Cut, I'm looking at you!)
I've become very comfortable in the world of pointer-free, garbage-collected programming languages. Now I have to write a small Mac component. I've been learning Objective-C, but as I confront the possibility of dangling pointers and the need to manage retain counts, I feel disheartened.
I know that Objective-C now has garbage collection but this only works with Leopard. My component must work with Tiger, too.
I need to access some Cocoa libraries not available to Java, so that rules out my usual weapon of choice.
What are my alternatives? Especially with no explicit pointers and automatic garbage collection.
What do you mean by "component?" Do you mean a chunk of code or a library you are going to hand to other people to link into their apps? If so then it is not realistic to use any of the bridged languages at this time. While a lot of the bridges are very nice, they almost always have complications and issues that most app developers will not be willing to deal with to use a single component, especially if it involves bringing in a substantial runtime.
The bridges are most valuable to bridge other language libraries into your Objective C app. While you can write fairly complete apps using them, doing so often requires a better understanding of Objective C than simply writing an Objective C application, since you need to understand and cope with the language, object model, threading, and memory allocation impedance mismatches that occur.
This is also why many people argue that even if you are quite familiar with a language, trying to learn Cocoa using that language through a bridge is generally more difficult that learning it using Objective C.
Finally, much of the recent support for bridged languages was due to "BridgeSupport," a feature was added in Leopard. Even bridges that predate that have been migrating towards, sometimes in such a way that using the bridged language on Tiger and Leopard can have substantial differences. Also, there is currently no bridge support for iPhone, and most bridged languages will not work on it, if that is an issue.
Ultimately, if you are writing a library that is going to be linked into other apps, you need to run on Tiger and Leopard, and you need to access Cocoa only APIs I think you will find using any non-Objective C solution quite difficult.
You can try PyObjC to write Cocoa apps in python, or MacRuby if you are interested in Ruby.
You shouldn't be intimidated by Cocoa's retain/release reference counting. It's much, much easier in practice than GC fans would have you believe. The Cocoa memory management rules are dead simple, they only affect a tiny amount of your code, and even that code can be generated automagically.
Here's the trick. You encapsulate your MM code in accessor methods, and always use accessors. Xcode has built-in scripts to generate the appropriate accessors, or if you need more flexibility there are 3rd-part apps like Accessorizer.
This isn't an intrusive approach - you only need to worry about retaining an object if you're going to need to keep it for later use, and if you're going to do that you'll need an instance variable in which to keep it anyway. And, if you're using KVO and bindings, you'll need to use accessors to make sure the appropriate observer notifications are fired. Basically, if you're using good OOP and Cocoa practices, there's practically no additional thought or effort involved with memory management.
Most folks who have difficulty with Cocoa's "manual" memory management are doing so as a result of misusing it. The most common mistake is to scatter the relevant code all over the place. That means that a missing retain, extra release, etc will be difficult to find.
Try any of the Cocoa bridges listed in here http://www.cocoadev.com/index.pl?CocoaBridges
You can also try F-Script - a smalltalk dialect that is written specifically for MacOSX/Cocoa.
RubyCocoa is getting steadily more impressive, and I've seen lots of successful implementations using it. That is, of course, if Ruby's your cup of tea...
You can always use REALbasic (www.realsoftware.com). Real easy and fun to use, not free though. You can not make dylibs (or dll's) using it, but you can use dylibs and dll's in your code. And you can use cocoa libraries as well
Don't forget that you can use java as well, and i don't mean java-cocoa bridge, i mean actual java.
There's also a package from apple that provides you with access to a couple of osx features as well.
Also to comment on Shem's point, if your targeting osx 10.5 and above, you can take advantage of garbage collection.
If you want lisp syntax then Nu is a lisp implemented on top of Objective-C http://www.programming.nu/
Also, FreePascal can generate native Carbon Apps (in progress working for Coccoa)
Look at Python and wxPython (the wxWidgets in Python).
The wxWidgets have a very elegant App-Doc-View application design pattern that's very, very nice. It's not used enough, IMO. I haven't found any wxPython examples of this App-Doc-View example, so you have to use the C examples to reason out how it would work in Python.
I'd post examples, but I haven't got it all working yet, either.
.NET via Mono mono-project.com
See NObjective (http://code.google.com/p/objcmapper/) bridge to Cocoa. It provides more features than others with less overheads.
I'm looking into Mono too. Objective-C is a little too bizarre for me at this point. Too many years doing C/C++, Java, C#, Perl etc. I suppose. All these seem pretty easy to float between. Not so for Objective-C. Love my Mac but afraid it will take too much precious time to master the language.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
My questions is simple!
Would you start learning Smalltalk if you had the time? Why? Why not?
Do you already know Smalltalk? Why would you recommend Smalltalk? Why not?
Personally I'm a Ruby on Rails programmer and I really like it. However, I'm thinking about Smalltalk because I read various blogs and some people are calling Ruby something like "Smalltalk Light". The second reason why I'm interested in Smalltalk is Seaside.
Maybe someone has made the same transition before?
EDIT: Actually, what got me most excited about Smalltalk/Seaside is the following Episode of WebDevRadio: Episode 52: Randal Schwartz on Seaside (among other things)
If you like Ruby you'll probably like Smalltalk. IIRC Seaside has been ported to the Gemstone VM, which is part of their Gemstone/S OODBMS. This has much better thread support than Ruby, so it is a better back-end for a high-volume system. This might be a good reason to take a close look at it.
Reasons to learn Smalltalk:
It's a really, really nice programming environment. Once you've got your head around it (it tends to be a bit of a culture shock for people used to C++ or Java) you'll find it to be a really good environment to work in. Even a really crappy smalltalk like the Old Digitalk ones I used is a remarkably pleasant system to use. Many of the old XP and O-O guru types like Kent Beck and Martin Fowler cut their teeth on Smalltalk back in the day and can occasionally be heard yearning for the good old days in public (Thanks to Frank Shearer for the citation, +1) - Agile development originated on this platform.
It's one of the most productive development platforms in history.
Several mature implementations exist and there's a surprisingly large code base out there. At one point it got quite trendy in financial market circles where developer productivity and time-to-market is quite a big deal. Up until the mid 1990s it was more or less the only game in town (With the possible exception of LISP) if you wanted a commercially supported high-level language that was suitable for application development.
Deployment is easy - just drop the image file in the appropriate directory.
Not really a reason, but the Gang of Four Book uses Smalltalk for quite a few of their examples.
Reasons not to learn Smalltalk:
It's something of a niche market. You may have trouble finding work. However if you are producing some sort of .com application where you own the servers this might not be an issue.
It's viewed as a legacy system by many. There is relatively little new development on the platform (although Seaside seems to be driving a bit of a renaissance).
It tends not to play nicely with traditional source control systems (at least as of the early-mid 90's when I used it). This may or may not still be the case.
It is somewhat insular and likes to play by itself. Python or Ruby are built for integration from the ground up and tend to be more promiscuous and thus easier to integrate with 3rd party software. However, various other more mainstream systems suffer from this type of insularity to a greater or lesser degree and that doesn't seem to impede their usage much.
Well, since you mentioned me by name, I feel I should chime in.
As I said in that podcast interview, and as I have repeatedly demonstrated in my blog at http://MethodsAndMessages.vox.com/, this is "the year of smalltalk". And having now done Smalltalk advocacy for the past ten months, I can see that it really is happening. More customers are turning to Smalltalk and Seaside, and the Smalltalk vendors are all working hard to capture this new influx of attention. More larger Smalltalk conferences are being planned. More job postings are being posted. More blog postings are being made.
If you turn to Smalltalk today, you are not alone. There are many others who are out there as well.
Edit
Well, a number of years later, I'm now recommending Dart instead. It's a great language originated by Google but now owned by an ECMA committee. It runs serverside in node.js style, but also clientside in modern browsers by transpiling to JavaScript. Lots of good books, blogs, help channels, IDE support, public live pastebin. I think it's definitely got legs... enough so that I'm writing courseware to teach it onsite or online, and I'm pretty sure there's a book or two in the works from me. And Gilad Bracha, an old-time Smalltalker is a major contributor to the design, so there's a lot of Smalltalk in Dart.
Smalltalk is a good language to learn, and the great thing is that it only takes a day to do it. It's a lot more than just an academic language. People are building huge, scalable, replicable applications handling billions of dollars. They just don't talk about it much. See, for instance, GemStone and Orient Overseas Container Lines:
A Shipping Industry Case Study.
Seaside is a good reason to learn Smalltalk, but I don't think you'll find it orders of magnitude better than Rails.
The thing that convinced me was GemStone. I really like Gemstone's GLASS (GemStone, Linux, Apache, Smalltalk, Seaside). The killer part of that is GemStone, which handles all the object persistence for you mostly without you thinking about it. Seeing some of their demos and hearing about what people are doing with GemStone reset my idea of what "big application" meant.
The part that bugs me the most about Rails is the object-relational mapping. That's nothing against Ruby because it sucks just as hard in GLORP (which handles ActiveRecord for Smalltalk), or Perl, or anything else. Mapping objects to database tables is just painful. With GemStone, thinking about the database disappears, so the work with the database disappears too. It's like a huge stone (or a troop of monkeys) is taken off my back.
> couldn't find a Smalltalk development environment that didn't cost both arms and a leg
Google - free smalltalk
Cincom Smalltalk, Squeak, GNU Smalltalk
Learning Smalltalk will give you a grounding in object oriented software development from the perspective of the man who invented OO (Alan Kay). The idea of a overlapping windowing environment came from Smalltalk.
A stumbling block to learning Smalltalk is that it is a message passing system with a strange syntax for flow control like:
i < 60
ifTrue: [ self walk ]
It has a very mature class library that has a consistency I've not seen too many places. The class library in all environments (even commercial Smalltalks) has available source which allows you to learn from the masters of the language. When programming Smalltalk, I always ask the question how is it done in the environment.
Smalltalk is generally implemented in an image which is a live environment for all the objects in your system.
The interactive debugger really seperates Smalltalk from Ruby.
Seaside is the web development framework and has given Smalltalk a new spotlight. It is a continuation based environment that allows for intra-hit debugging and a smooth Rich Client type development experience (top application flow can be designed in a single method). It's integration with script.aculo.us has been done in such a way that it is easily called from within Smalltalk.
Nigel, one quote I have is this:
Although it's now a long time since I did anything with it, I nominate Smalltalk, I still haven't come across anything quite like it for being able to transfer thoughts into computer code. It's not just the language: It's the wonderful browser environment, the libraries, and the culture of writing clear, well-designed code as quickly as anything else can crank out spaghetti. When the participants at JavaOne were extolling how Java was so much more productive than anything else, I needed a brown paper bag. Oh well, back to sorting out my classpaths... -- Martin Fowler (Software Development Magazine, Jan 2001)
I found it here.
Would disagree with the poster who reckons you wouldn’t use Smalltalk for large apps – that’s precisely where it shines. But I have created fairly groovy (note lowercase) prototype apps in under a week too.
I learned OO in ST starting in 92, incredibly glad I did so. It gave me a real background in OO. Thinking in classes. No types. ST has a real emphasis on messaging. If you want to know something send an object a message and get an answer. IMHO, the ethos and the IDE really encourage you to do the right thing with your coupling and cohesion.
In my Java day job, I’m stuck with files, generics, IDE’s like eclipse that are orders of magnitude less productive that any ST IDE. I was using ST the only time I finished a development ahead of schedule. In fact it was so productive, and we got so much reuse I had to be moved off to another project, as I had nothing to do! (Ok, maybe I could have spent time learning to estimate...)
Download squeak, find a good book and play. Only downside is that if your day gig is using Java or C#, you’ll end up wishing you could use ST. You’d get home sooner.
Chris Brooks
I recommend everybody to learn Lisp (Scheme) or Smalltalk.
Smalltalks have wonderful IDEs which you dont want to miss once you got over the culture shock. And yes, there are more than one free ones: Squeak, Dolphin, Smalltalk/X, and Visualworks (Non-Comercial).
Lisp may be even cleaner in its mathematic foundation, though.
regards
PS: actually I recommend learning both !
I do not know Ruby..
Smalltalk is a pure OO language. If you feel the need to really understand OO, and not just the simulated OO of most popular 'OO' languages (like C++, Java, etc), then I would recommend that you play with smalltalk.
In smalltalk everything is an object, with attributes, behavior and meta. In the simulations you have data types that you use in your objects.
I would say play with it, you will only benefit.
I'm totally in your shoes. Im using RoR and looking into Smalltalk land. Here's some pros & cons I find important:
Pros:
Mature & stable environment
Fast development cycle
Makes you think more and write less
Cons:
Requires different thinking
Still didn't quite grasp it
It's quite funny how I got to know about Smalltalk. It was this one thing that keept popping up in Google results when searching for Lisp and Erlang stuff. One day I checked it out and was amazed with nice windows environment. Few moments later I've found Aida/Web framework. I was hooked and started learning Smalltalk through web development with this framework.
Still not quite there, but it's so damn interesting I just can't sit still... :-) I'm having fun again.
Would not start learning it if I had the time. Why not? Because it would be more productive and lucrative financially to learn C# or Java.
On the other hand if your a hobbyist, and would like to go on an archeological dig, then I'd suggest spending some time looking at the What, When, Why and how of smalltalk by researching Alan Kay. Fascinating story and an incredible person (after all, he earned the Turning Award). Then maybe play with squeak a little to get a feeling for the language. After this you might have a newly found respect/understanding of blocks, closures, and Object Oriented principles.
I know and use Smalltalk, have for about 15 years, still maintaining it, and would not recommend Smalltalk to a friend. Why not? Employment is a good thing to have and keep getting. Although you can learn a lot from Smalltalk you can't easily turn that into gainfully being employed in this day and age.
Also, you appeared to be excited over Seaside and I would assume the Seaside/GemStone partnership. I've used GemStone for quite some time and the two together are very appealing. I hope they can get the market share and momentum required to be successful.
Don't! If you really start learning it, you might not want to programm in something else anymore ever.
This may be not true, if you are a lisp programmer.
Absolutely, learn Smalltalk! This is 2015 and Smalltalk is on the rise again, thanks to Pharo. Pharo is FREE. Pharo is evolving quickly into a powerful enterprise tool. At Version 4.0, and soon to be 5.0, it has matured a great deal in just four years!
Then there's Amber, which is Smalltalk for the web. It's also FREE and evolving quickly.
Despite Smalltalk's reputation, this is not your father's Smalltalk. Modern Smalltalk is exciting and promising.
It's true that Smalltalk jobs are not (yet) plentiful. But if enough of you aggregate to a new wave of Smalltalkers, then the industry will adapt to it and we'll see wider adoption of Smalltalk in business. The question is, do you have the vision?
I was taught Smalltalk in one of the first graduate college level Object-Orient Programming courses (circa 1988). The teacher thought it best to start was a "pure" OO langauge,before moving on to a more trendy one (we did a bit of C++ at the end of the semester).
By that measure, it's still best to start with pure OO, although these days we have Java & C#, both of which are "nearly-pure" OO -- close enough that you can get by ignoring the non-OO features of them, and limiting yourself to the Pure-OO subset of the langauges.
If you want a better understanding of Extreme Programming (and even Scrum) I'd say yes.
Why impatient Java programmers need to learn Smalltalk:
http://www.dafydd.net/archive/2010/why-smalltalk-isnt-just-another-language/
I've been a software engineer for quite a few years now. I've heard people bring up Smalltalk a few times, and certainly Smalltalk has been around since about 1980, but it's one of those languages that's never seemed to make it into the software mainstream. Sort of like Objective C, CLIPS, PL/I, etc--something you may have heard of, but something that most folks have never programmed in.
I probably wouldn't take the time to learn Smalltalk unless I needed to for a particular job. I looked at some Smalltalk tutorials and examples briefly a few years back, and it looks like it has some clear advantages for certain aspects of OO programming (like the message concept seems cool). But sadly, it is not mainstream, and doesn't seem to be gaining much momentum.
This thread has become very actual for me. I'm planning for a Software migration to a web-application. It's a database based software. I'm especially checking the alternatives
1) Rails
2) Seaside
If I can get the figures for the Gemstone/S as Database, I'll consider that also. So for me it means I have to learn Smalltalk (better) than before. Because it could be that it will be my work for the next 15 years. You would (and should not) work with software you don't like for that long ;-). I've the impression Gemstone/S is one of the "killer" applications. But persistence of Objects still is a very difficult field....
1) Yes! It's always good to learn a language. If you are going to learn a language, make it a powerful, influential language that can be learnt easily and quickly.
Smalltalk remains a pre-eminent language and environment for learning OO concepts.
It is all objects, all the way down. This makes for a really consistent approach to working.
Integers are instances of Class Integer. Strings are a collection of character objects. Classes are singleton instance objects for the class they define.
Control structures work by sending get messages to instances of Class Boolean.
Even anonymous methods (blocks of code, aka blocks) are objects.
Everything is done by sending a message to an object. The syntax can be fitted on a postcard.
The clarity of the concepts and their implementation in Smalltalk mean that you can develop ways of thought which transfer directly into Java, Ruby and C#. I expect it's true for Python, too.
It's so good for making the concepts clear that a major UK University used Smalltalk to train 5,000 people a year in object-oriented computing.
Squeak 5, has just been released. It has gained major performance increases from its new Cog/Spur VM, which features with progressive garbage-collection.
Pharo 4 has a lovely clean-looking desktop theme. The next version, Pharo 5, will be released soon. It will move to using the Cog/Spur VM, it will have about 5,000 classes in the release, and additional packages of classes are readily available from the net via the Configuration Browser tool.
Squeak 5 is performant even on first-gen Raspberry Pis, and is almost 50% faster on the new $5 Raspberry Pi zero. $99 buys you a Raspberry Pi 2, screen and case - running a mature, fully feature-complete IDE.
Leading edge research is being done on co-ordinated, distributed OO systems in Smalltalk (e.g. Naiad and Spoon).
Some of the world's largest corporate databases are run on Smalltalk - including tracking of 60% of the world's shipping containers, and trading systems in the world's largest bank.
You can use Smalltalk as a sort of super-powered CoffeeScript, writing in Amber Smalltalk and transpiling to JavaScript, running in the browser.
Squeak, Pharo, and Amber are all Free, Open-source, open-licenced languages and environments.
Squeak and Pharo provide write-once, run anywhere facilities for MacOS, Windows and Linux. (Possibly RiscOS, too).
Dolphin Smalltalk is targetted firmly at native Windows look-and-feel, and lets you compile closed .exes of your finished work for distribution to end users. Further development of Dolphin by the vendor has stopped, but it is completely functional, and, like all Smalltalks, designed to be massively extensible. (Did I mention that Pharo now has 5,000 classes, compared to Squeak's 3,000? Pharo is a fork of Squeak 3.9)
**There is a How-to guide for installing and starting Squeak, Amber, Pharo, Cuis and Dolphin at: **
http://beginningtosmalltalk.blogspot.co.uk/2015/11/how-to-get-smalltalk-up-and-running.html
The Seaside web framework runs on Squeak and on Pharo. It's a wonderful mature tool, as is the more traditional AidaWeb framework.
VisualAge, VisualWorks and Gemstone all provide enterprise-grade robust systems. Gemstone provides an infinitely scalable object database with transactions and persistence.
2) Yes - I do already use it.
I learnt it via the Open University, and was immediately productive in Ruby (a copy of the Pickaxe book and the library reference by my side). It helped me enormously with Java, and with Xerox Moo-code.
I have just returned to it to write apps to control manage and distribute responsive, massively multi-platform mobile apps.
I expect that soon I'll be re-writing my JavaScript mobile apps using Amber, too.
I don't really know what you're looking for.
If you are looking for a different language to write in, I'd think that would depend heavily on the libraries available. I know neither Ruby nor Smalltalk, but it seems likely that the most efficient way to write Ruby on Rails-sorts of applications may not be Smalltalk.
If you are looking to learn the ideas behind Ruby, this might be a very good move. I don't have anything quantitative, but I always felt better about using tools (such as language systems) if I knew more than just the tools, if I kmew the ideas behind them or how they worked.
If you want to learn different sorts of object-oriented languages, you might well want to learn Smalltalk (if it differs significantly from Ruby), something like Java or C++, and perhaps also the Common Lisp Object System.
If you just want to learn something different, Smalltalk may well be a good choice. I'd also suggest Common Lisp, and other people will doubtless have other suggestions (can you get a good Forth system nowadays?).
Yes, I'm interested in it. Tried to start once already, but couldn't find a Smalltalk development environment that didn't cost both arms and a leg.