Other Languages (than PHP and C#) and Lack of Progress Since 1980
On the Stack Overflow question Open source vs Microsoft technologies as a career foundation on my answer post:
I think C# (especially 3.0) has more to teach you about software development than, say, PHP. I think your career long-term will be better off with a solid language like C# since you can branch off into languages like Java or C++, or even Haskell, more easily than PHP. (NOTE: Python also has these qualities in different ways.)
There is always a danger with locking yourself into any technology niche (especially for your own personal hacker development) so even if you go the .NET route make sure to try your hand at the dynamic languages and open source stuff out there, in your free time, for example.
there was an intriguing comment:
I know smalltalk has a lot more to teach you about software development than lets say C#, java or ruby. The lack of progress since 1980 has been amazing :)
This is my lengthy response.
re: Smalltalk having more to teach you about software engineering
More specific reasons I would recommend C# to programmers searching for a place to start their education/careers:
- it is a staring point/similar to other widely used languages (C/C++/Java)
- has less of the disadvantages of starting with C or C++ (SegFaults, manual memory management, inexcusably terrible "built-in" string support, even with STL or boost)
- and many of the advantages of starting with Python or Ruby (immutable Unicode strings as a first class type, generic collection types, garbage collection)
- It has low level C-like performance with unsafe and pointers if you need it
- It has a healthy mix of "advanced" features like lambda (anonymous functions), type inference, expression-oriented collection manipulation (LINQ/IEnumerable) without too much of the foreign feel of Haskell or Scheme.
I love Haskell and Scheme as much as the next guy, but for beginners, Scheme and Haskell are all wonderful languages to learn about software engineering and computer science but give you this feeling of betrayal after the honeymoon is over (perhaps Smalltalk has this problem; I can't speak from experience): they raise your expectations and cause you a real let down when you get a real paying job coding in Blub. With C# it's like they sneaked some of the power (definitely not the elegant syntax) from Haskell into a language your boss makes you use (aka Blub).
You can and will learn a lot starting with Smalltalk but from what I gather it is probably not a great career language. (I don't mean to imply that you shouldn't learn it or that C# will teach you more, just that you will definitely be let down when the rest of the world is less enlightened and doesn't know how to take advantage of it and pay you to use it. Same thing applies to Lisp/Scheme, Haskell, OCaml, etc.). Now if you are smart you will learn Smalltalk, slug it out and learn C#, and then go use something like SABLE or S# (Smalltalk on the CLR with access to all of the libraries) on certain parts of the project. Just don't tell your boss. (PS this also works with the Ocaml-like F#, IronPython, or IronRuby).
re: The lack of progress since 1980 has been amazing :)
No, you get off my lawn!
Haskell was born in 1990, making it nearly 20 years old. Yet many of the basic advances in Haskell or even ML (from the late 1970s) have not made it into other languages, especially mainstream languages (type inference/purity/laziness/monads). So in one way, you are right about the lack of progress, in general.
But saying nothing has happened at all since 1980 may be a bit naive, especially in the field of technology[1]. To learn whether Smalltalk has kept up with some of the amazing progress in programming languages since 1980:
- Does Smalltalk support multi-methods (like Slate or Common Lisp/CLOS or Clojure)?
- Does Smalltalk code run unmodified in parallel or concurrent situations (multicore anyone?) with the same behavior, by default (cf. purity in Haskell or Clojure)?[2]
- Can I write succinct, performant multi-core code in Smalltalk with Nested Data Parallelism?
- Can the compiler statically determine that my transactions (Software Transactional Memory) do not cheat and change state? (cf. STM/Monads in Haskell; in Clojure you get a runtime exception if you access a reference outside of a transaction but the built-in immutable data types give you lots of safety/sanity)
- Can you overload a function in Smalltalk based on the return type, e.g. based on how the caller uses the return value? :-) (cf. fromInteger :: Integer -> a in Haskell)
As I said, "There is always a danger with locking yourself into any technology niche (especially for your own personal hacker development)" so by all means, learn Smalltalk/S#, learn Lisp/Scheme, learn OCaml/F#, learn Haskell, just don't assume there is nothing more to learn, that there has been no progress, especially in the last thirty years.
(I too am surprised how old so many of the ideas were, but not surprised that it took so long to actually build and bring to a wide audience stuff like the web or GUIs (Vannevar Bush v. Tim Berners Lee, Sketchpad v. the Apple Lisa/Macintosh). If you traveled back in time to 1963 and showed Ivan Sutherland your iPhone my money says he would have been duly impressed). ↩︎
Smalltalk suffers from the same basic problem as PHP, Python, Perl, Ruby, C/C++, C#, Java, JavaScript: your state is spread across hundreds or thousands of little objects; this works fine in the single-threaded universe, but for everything else there is Haskell, Clojure, and Erlang. Software Transactional Memory libraries in any language can be helpful, but you (other programmers? not you, right?) can and probably will still "cheat" (introduce side effects or modify variables in place). In fact, the libraries that come with your libraries in your favorite language are probably built around "cheating" and may be part of the concurrency problem. ↩︎