As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Having recently come across this introduction to Factor, I've been a bit curious to learn more. Aside from the official FAQ mentioned there, do you have resources for learning the language (as well as the stack-based "paradigm," if that's the right word) that you've found helpful?
As a side note, would learning Forth help, or is that like comparing C to Python (or what have you)?
Factor is heavily inspired by Forth and other stack languages. It also grabs ideas from Lisp, and Smalltalk. From what I've read online, it's not necessary to learn any of those language before learning Factor. It won't hurt if you do, however :)
The biggest problems I've run into is the youthfulness of the language. In other words, code samples on various blogs/sites will be outdated because they used older versions of Factor (0.6, 0.7, 0.8, etc). Factor 0.9 and above are most likely to remain the same.
Once you get past the basics, the docs (online + in the listener) are pretty clear. The docs occasionally suffer from the same problem as blog posts: some outdated code examples. You still have the mailing lists/IRC to help out if you really get stuck.
I've only used the docs so far, instead of the mailing lists/IRC. I then experiment with the listener to further learn/explore a new concept I find in the docs.
This is the first language where most of my questions are answered just by digging into the docs of a function. Most of Factor is written in Factor, so things become clearer as you spend more time with the docs.
(The 2nd biggest problem I've had is trying to understand the web framework (Furnace). The web framework is more feature-rich that what I am used to. It's nothing impossible, just requires some practice and exploring the docs.)
The quickest intro. to concatenative languages I've found: http://github.com/raganwald/homoiconic/blob/master/2008-11-16/joy.md#readme
Your first steps to Factor: http://concatenative.org/wiki/view/Factor/Learning
These videos go into more detail regarding writing Factor code:
90 minute video might help learning Factor basics: YouTube: Factor: An extensible, interactive Language - Basically, Slava (Factor creator) gives a video intro. to Factor. It's part of the Google Talk series. (There is a high and low quality version in case you can't see the slides.) Factor concepts are also compared to other languages.
13 minute video: Forth # RubyConf 2008. A brief demo of Forth. It also mentions some ideas that are common throughout the software world.
100 minute video: Factor presented to Lisp programmers. Audio is not the best, but still very good video quality. If you watch the other videos, you can skip some of the beginning parts of this.
Some diversions:
Create a calculator + GUI: http://re-factor.blogspot.com/2010/08/calculator-with-gui.html
"Why I like Factor": http://jedahu.blogspot.com/2010/08/why-i-like-factor.html
Planet Factor: http://planet.factorcode.org/
Here are some blog posts that can help provide direction:
From Jan 2008, but it should still be applicable: "Learning Factor" by Daniel Ehrenberg (He's one of the core Factor contributors.)
This following quotation is from a blog post from Sept. 2008: Sorting strings with embedded numbers
Understanding the various abstractions and libraries which are available is key to grasping Factor: collections, generic words, fry, locals, macros, memoization, PEGs, the prettyprinter, and so on. Making effective use of these tools can reduce the amount of work required to solve a problem by an order of magnitude.
Factor is definitely the most fun language. It has fewer surprises than other languages. I find it easier to learn than Ruby or Lisp. Just for fun, here is a language shootout between Lisp and Factor:
Lisp code
Factor code
For anyone who is interested in stack-based languages, this article might help: The Joy of Catenative Languages (Parts 1, 2, 3) (It's more general and uses the Cat language for examples. It helped me with learning Factor basics.)
You can start here: http://concatenative.org/wiki/view/Factor
And there's a nice documentation included in the runtime/GUI. Just install and then "Browser" and you see the documentation with topics like "Your first program".
The documentation is available online, too: http://docs.factorcode.org/
(It's the same as the one you get when you install Factor.)
Don't forget to subscribe to planet-factor.
I think Slava Pestov's excellent presentation "Factor: an
extensible interactive language" at Google (Google Tech
Talk) counts as a good resource for learning Factor. There
are lots of demos of the different aspects of Factor that
you should be able to try on your system. For instance the
demo of using Factor for implementing an Internet time
server, approx. 1 h 07 min 20 secs and lexical closures, 46
min 35 secs. In fact most of the presentation is a demo.
The Flash video is 141 MB, 1 h 36 min 38 secs, presentation time
autumn 2008. Slava Pestov is the creator of the Factor
programming language and jEdit, a popular text editor.
I've been teaching myself Factor recently - I actually found Forth as a good afternoon's introduction to the concept of stack based languages (and as a bit of a software archaeologist, it's fun to step back a few years for a history lesson).
To that end I don't think it does any harm to take a few hours to install gforth or similar Forth implementation and start working through the first few chapters of starting forth or using ANS forth - I found it quite interesting, and because I only dipped my toe it hasn't taught me anything I've had to unlearn as I'm starting to learn factor.
Once I've progressed a little further in learning Factor I'll let you know what I've found useful (or not so useful!).
You could also start with Forth since it's a stack based language too:
Starting Forth
Thinking Forth
Forth Primer
Forth Language
Forth Tutorials
Pforth Tutorial
Gforth Manual
Begin Forth
Forth Links
WikiForth
OLPC Forth
Lets Build a Compiler
Jones Forth
(Edit: updated Jonesforth Link to new git repository - 4/18/14)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I wanted to do some research but i could not find any information about this topic.
The only information that i found -> http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=csharp&lang2=lua
And I'm not sure how i can interpret this chart.
If I'm right it basicly says that Lua is 10times faster than Mono.
But Mono's memory usage is ~8 times better than Lua.
What does this say about perfomance ?
Comparing Lua with Mono -> Advantages/Disadvantages
Edit:
[Gamedevelopment]
Cryengine 3 uses c++/lua atm. But some guys releasing a mono port for this engine. I'm very familiar with Mono. But now i wanted to do some research on Lua to see if its worth to learn this language or if I should stick with Mono
You're comparing apples to oranges. C# is a statically typed language, compiled to CIL which is a bytecode language, run (or usually JITted) by a virtual machine, and used for web and standalone application development. Lua is a dynamically typed scripting language typically run by an interpreter, often embedded as an extensible scripting language into a larger application.
Also, your interpretation of the benchmark is wrong. The bar chart shows that the Mono program takes around 1/10th of the time to run compared to an equivalent Lua program.
That said, this kind of microbenchmark is largely useless. Don't take my word for it; read what the Shootout itself has to say about it. You should read the whole thing, but I'll pull out some juicy citations:
"The performance of a benchmark, even if it is derived from a real program, may not help to predict the performance of similar programs that have different hot spots."
"It may seem paradoxical to use an interpreted language in a high-throughput environment, but we have found that the CPU time is rarely the limiting factor; the expressibility of the language means that most programs are small and spend most of their time in I/O and native run-time code."
"Programming languages are compared against each other as though their designers intended them to be used for the exact same purpose - that just isn't so."
Long story short: select your language based upon whether it does well at what you want to do with it, whether it lets you express your intent clearly, whether it lets you write clean, maintanable code; not based upon some largely meaningless numbers.
This says: Apples are greener than bananas.
You can't just say something like "Lua consumes less memory than C# but takes about 50% more CPU cycles". You have to compare them in respect to your context, e.g. what you want to build.
When you want to calculate 5*5, okay, Lua may be faster (in terms of implementation). But if you want to build an ERP-application with many clients, I wouldn't recommend Lua.
So we can't give you a definitive list of advantages and disadvantages, because it heavily depends on what you want to do.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So there are a lot of posts around here about what are the best ways to teach kids to program. I'm interested in the next step, teaching kids how to debug code that doesn't do what they want, or doesn't always work 100% of the time (I believe these are separate problems, but that could be subjective).
I ask from the point of view of a game developer who already has a working game (ROBLOX) where kids can code up a ton of crazy stuff in our embedded scripting language, which happens to be Lua.
What we are seeing is that as these scripts become more complicated they are suffering from edge cases that the kids didn't consider - ultimately limiting the scope of what they can do. Part of the solution is education and part of the solution is better debugging tools. Thus I ask a two part question:
What high quality, freely available sources of information exist on the internet that we can send aspiring script developers to with any expectation that they would get something valuable out of it? Maybe there aren't any and we need to write some?
What debugging tools do you think would be most useful to kids? I want to hit the payoff vs. complexity sweet spot.
Our target demographic here is motivated kids, mostly 12-15 years old.
IMHO: Never mind tools. Talk them through it. Teach problem-solving skills. And just as importantly, teach testing.
Well for the debugging part, my guess would be three things:
Avoid bugs in the first place by teaching them good programming practice
Test each part with eg. unit-testing (Lunit)
use print() enough for seeing what happens
you might be interested in debugger.lua or Remdebug
Use a decent editor with syntax highlighting, bracket matching, ...
For the general information:
Learning Lua on the Lua-users wiki
The Lua reference manual
Programming in Lua
That's the way I learned using Lua anyway :).
Of course, early start always helps. In the early years, brains aren’t wired to one particular language like in adulthood. http://blog.quib.ly/2012/10/30/can-kids-beat-adults-at-coding/
I don't know about the "sources of information" part. It looks a bit too generic to me. I learned about edge cases with painful experience, and don't know any other means. I'm not sure it is a kind of knowledge that can be taught formally. It's more like an intuitive thing to me. Kind of like swimming: in order to learn, you have to get wet.
But regarding payoff-vs-complexity part, I'd say that nothing beats the good old console + print duet. It might not be as fancy as other debugging means, but its complexity asymptotically approaches 0. And it's something they will be able to use in nearly any environment and any language they encounter in the future (unless something really big happens).
If you have iPad, now there's a nice app that lets you write programs/games/simulations and run it directly from your iPad. The language is Lua.
http://twolivesleft.com/Codea/
I would use Netbeans after stripping it down a bit. It has some very nice code hinting and comprehensible error checking and hinting.
Kids can have restricted access to tools like debuggers as an individual may not be registered as a programmer or (game) software developer in the state or at the national level. Lua can be run in debug or trace mode and there is something to be gained by reading through the program script or code and using a pen and paper with test input values to note the variables and their contents with logic jumps separately noted with any return expectation and assess the output data values created at relevant points. This is sometimes called dryrunning and is used normally prior to first full test in the development process. This can help in coping with sometimes complex logic progress and with stack element contents written from bottom to top or from left to right on the paper.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm a member of a software development team, working on a small project.
We think that we can release a beta quality product after 2 or 3 month of continuos work.
Since this is our first teamwork, I decided to ask, which software development methodology would you suggest for a small project with small number of developers (less than 10)?
There are two approaches to software development:
Write down what you are going to do, do it, then agree that you have done it.
Start developing stuff, agree that what you have done is good, repeat until finished.
Both have their adherents and both pop up repeatedly under a variety of names. Each new generation of software developers (ie about every 2 years, this is a fast changing industry and software developers have the lifespan of a mayfly) rejects the previous generation's approach, re-discovers the approach used by the generation before last, renames it something funky and declares it to be the ONE TRUE WAY.
The choice between the approaches ought to depend on the culture of (a) the customer organisation and (b) to a lesser extent, the culture of the supplier organisation (ie your software developer team).
So, if you work for a buttoned-down conservative enterprise approach 1 is indicated. If you look down and see that you are wearing surf shorts and came to work this morning on your skateboard, go with approach 2.
And, in case you have read this far, the most serious bit is the paragraph before the one before this final one, ie the one starting 'The choice ...' This is a cultural / organisational issue rather than a technical one. Both approaches have been used on many many successful projects, neither has a monopoly on unsuccesful projects.
This really does depend on what you are intending to build. If the project is going to be something you want to build upon and have regular intervales something like Agile / Scrum would be very suited.
But it really depends on what the project is to determine release iterations and the like etc.
I think that you need to start from Joel Test and try to implement most of this list:
http://en.wikipedia.org/wiki/The_Joel_Test
And as product development use KISS = Keep It Simple & Stupid, for first release
Also really good start is Getting Real book, available free from 37 signals:
http://gettingreal.37signals.com/toc.php
This really does depend on your customer.
If the customer can accept fixed
time, fixed resources, fixed quality
(100% working code), and slightly
variable scope, I recommend choosing
an agile methodology.
If the customer cannot accept the
above, i.e. the pre-condition for
using an agile methodology is not
present, I recommend choosing any
methodology you like.
The important thing is that you do have a methodology, learn what is working as you go, and use the knowledge to adapt the methodology.
Don't do waterfall, this never worked and will never work. Thinking waterfall is a working methodology is like thinking banging your head against the wall is good, because even the sturdiest wall MUST crumble at some point.
I'd go with a reasonable agile methodology, like Scrum (XP is a bit harsh). Also, introduce things like TDD, DDD, DBC and you should be fine.
I wont suggest this as THE best answer, without having a better idea of the context and circumstances, but I am personally becoming a fan of the Lean / Kanban approach. In general I find a lot of the agile / scrum methods can be fairly developer focused, and almost anti-manager sometimes, which is sometimes appropriate but not always. The lean approaches tend to address the entire value stream rather than just the development itself.
You can read more about it at :http://www.limitedwipsociety.org/
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
I realize that the question is likely o get a lot of "it depends", but I am curious anyway. When you hire somebody new (but experienced) to the team, and they don't have expertise in technology you are using, but know something similar, how much time do you budget for them to "get online."
I am talking about something fairly substantial, like a language, or a framework / product that has a lot of ways of doing things. Obviously, many libraries takes very little time to start using.
In my own experience (10 years of experience, including a fair amount of consulting, so learning new technologies is par for the course), it takes me about three to six months of experience to become proficient at a new technology, and about a year to feel like I am approaching expert level where I know all the basics and medium-difficulty issues, along with a few areas very well.
What do you do in your projects? How do you budget the time to account for learning.
It doesn't only depend on the individual involved -- it crucially depends on the specific technology as well as the individual's background; certain technologies, esp. languages, are just harder and slower to get into. I've seen world-class Java gurus with zero previous exposure to C++ take many months, say on the order of six or so, to be fully productive in C++; vice versa (world-class C++ guru with zero previous exposure to Java) I've seen take about 2-3 months; again for extremely experienced and skilled programmers with no previous exposure to dynamic languages, being fully productive in Python can be expected to take 3-4 weeks. In each case I'm talking about 100% full-time involvement in the relevant technology, by a programmer in the world's top one percent in terms of skill and experience, within a team having several other programmers of that caliber who also gurus in the specific language in use.
Factors that can shorten the time are previous exposure to "similar" languages/technologies, e.g. a solid background in C makes C++ slightly faster to learn, solid background in C# helps with Java, solid background in Ruby or Perl helps with Python. Factors that can lengthen the time include lack of suitably experienced teammates, not being 100%-immersed in the "new thing", and psychological resistance (not really wanting to do it with all one's heart!-).
I've focused on programming languages for my examples, but some technologies can be even harder, i.e., take longer to master -- if you've never written embedded real-hard-time programs (no dynamic allocation of memory allowed, proofs of upper bound on response time required of all function) even six months might not suffice; some application areas require mastery of application domains that, all on their own, can take even longer (if to understand at all what's going on, and therefore be fully productive, you need the equivalent of a BSc in Psychology, or deep knowledge of the Law, or a CPA's qualifications, etc, well, each of those takes years on its own!).
I don't think the language as such is the issue, rather the programming paradigm it encompasses.
e.g. earlier this year I tried C#, coming from a Java perspective. That was all very straightforward. However, I'm now trying Scala. Because of the functional aspect, I expect to be learning and honing my skills for a lot longer (you can write Scala in an imperative fashion, but you don't leverage its strengths doing that).
I suspect the same would apply when (say) migrating from a relational database to an OO database, vs. a MS-SQL/Oracle migration.
It does depend, mainly on how closely the language resembles a language they already know, as well as individual abilities at picking up new things. Moving between similar languages like C++, Java, and C# is very easy. Similarly, moving from (say) Win32 to MFC to .net is going to be easier than from MFC to MacOS.
Moving from C to C++ is likely to take longer, as the programmer has to learn OO methodologies. Moving from C++ to Perl or ML could take a lot longer!
However, you usually don't need to know much to get started. Moving from C++ to C# can be done in a few hours reading (on the main differences) and then you can start writing (or modifying existing) code. That's because (a) you already know how to do OO programming, and (b) 95% of the syntax is identical.
But the main thing it depends on is your definition of "proficient". With similar languages, you will be able to write good code within a few days (an algorithm is usually failry language independent), but it usually takes months or years to become truly "proficient" in a language or large library.
So I'd say as a rule of thumb, "up to (a reasonable) speed" in a few weeks, but you might see silly "mistakes" or inefficiencies in their code for months/years until they learn all the little tricks of the language.
In the case of people learning OO, usually it seems to take a few days to get the basic concepts, and then at about the 2 year mark, a moment of epiphany occurs where the programmer suddenly relises that they truly "get" it. (I guess this is when your brain starts thinking fluently in OO rather than trying to think procedurally and then translate that into an OO aproach)
In our environment (US health care revenue cycle) it is more than just learning and becoming proficient in the language or technology stack we use to deliver our solutions to our customers. The developer also has to understand the problem domain. We work with entities that often don't document the behaviors of their systems well-enough for external entities (us) to communicate with to get the data that our customers we want. Our developers are forced to think beyond the specs to build a functioning system.
There is also the inevitable "It doesn't work; fix it" problem report from the customer support staff. Frequently the problem isn't a defect in our software; it is an issue with other entities with which our software communicates. Our developers have to be able to identify (and sometimes prove) that it isn't our software so that our business analyst-types can go to that other entity and explain the issue in a way that will get them to resolve the problem.
You were expecting this answer but it all depends on the person/programmer. I have been in a situation where two equally skilled programmers had to pick up something new, one got it right away, while the other one took some time. Previous exposures to other technologies are also a factor.
Personally, in regard to something new, I budget my time to learning everything about it every chance I get. It would take about 6 months to fully be comfortable.
Hope this helps.
I am talking about something fairly substantial, like a language, or a framework / product
that has a lot of ways of doing things. Obviously, many libraries takes very little time to start using.
When you hire somebody new (but experienced) to the team, and they don't have expertise in technology you
are using, but know something similar, how much time do you budget for them to "get online."
Twenty-three work days, six hours, forty-three minutes, and seventeen point nine seconds.
What do you do in your projects? How do you budget the time to account for learning.
I think these questions are better!
Try to find an easy project in the new technology, and have them do that. If possible, have the person start by fixing bugs, then adding small features.
Learning is incremental. One can continue learning details of, say, C++ syntax throughout one's life. When one is an "expert" in a topic, it just means that the gains from learning more in that topic are growing smaller.
+1 for it depends.
It depends on such things as
the attitude and capabilities of the person learning it
is the problem area programming/paradigm well understood by that person
the similarity of the new technology / language to other technologies he/she does know
the consistency of the new technology / language in its interface (API, grammar, etc...)
what is proficient (knowing just the language, or als the basic library, or also runtime behaviour (interactions with underlying technology))
Having said that, in my experience a smart person learning a new language/technology will quickly be more productive than other people with more experience in that language/technology.
See Peter Norvig's Teach Yourself Programming in Ten Years for the related question of how long does it take to become proficient in programming.
It so completely depends on whether you already know languages that are similar to the new one, and know something about the problem domain the new language is suited for. I'd say don't expect to be reasonably proficient in less than 3-6 months, but again, it depends.
To take one example I implemented a PHP/MySQL web application a couple years ago (total effort was about 6 months). It was my first reasonably large web application, and my first PHP ever. I've used relational databases, but this was also my first exposure to MySQL. MySQL came very quickly, as expected, since it's really only a dialect of a language I knew well. What surprised me was that PHP also came quickly. I realized that not only did it borrow ideas from PERL and C/C++, but the whole paradigm of coding with integrated SQL statements strongly drew on some experience I had in the 90's with, of all things, Informix 4GL.
At the other end of the spectrum, I've never really learned a functional language, so I'm trying to pick up Scala. This is going to take substantially longer, and there'll be a long period where my Scala will feel like Java in disguise, and not be that functional.
So ... it depends! ;-)
I agree that it depends.
You also run the risk that if the person knows one technology/paradigm, they will code in the new language/technology using the old practices/paradigms.
For example, I picked up Python really fast (I'm a Java/C++ guy), but it took a long time since I stopped writing Java style code in Python and started thinking functionally.
To get really good, I think there's no replacement for experience. For instance, I'm sure I can easily pick up J2EE, but the experience to built up the best enterprise systems is not something you can pick up that fast.
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
This book was written in the era of time sharing systems, procedural programming, and about 30 fewer years in software engineering experience. With the improvement of things such as existing libraries, higher level languages, IDES, and the amount of documentation and examples available on the internet how much of the book still holds true?
While I can believe that adding new people to a project may initially slow it down I would think things such as unit testing, separation of concerns, and other forms of automation and design improvements would allow new members of a team to become productive faster then assumed in the book, assuming the project had good design documentation and processes in place.
I don’t have experience on large projects or with large teams so am interested to hear what those of you who do have experiences with them think.
edit:
I was wondering if new communication tools such as Wikis, instant messaging, and the internet in general decreased the time spent communicating. Based on everyones answers I would say that any increase in communications efficiency has been offset by increased complexity.
It is still as true today as the day it was written. This is because it is fundamentally about communication between people working on the same project, and none of the advances of the past 30 years have substantially changed that.
Of course, we have learned a lot in those 30 years, but all improvements in our tools and undertanding have been incremental, in accordance with Brooks' "no silver bullet" prediction.
Isn't this kind of like asking if Sun Tzu's Art of War is still applicable to warfare since we have modern equipment?
The book still has things to tell us, and I for one have experienced the problems in communication that increased team sizes bring. You should be aware that unit tests, separation of concerns etc. are not new concepts.
However, some things have not stood the test of time. I don't believe that writing ASCII flow charts in your code is a good idea, and the "surgical team" approach suggested has been tried by several people (Charles Simony at MS, most famously) and found not to work too well.
The idea isn't that "large teams don't work", it's that "throwing people/money at the problem isn't the answer". Things like unit testing, separation of concerns, etc. are doing other things rather than just throwing people at the problem. These other things allow you to carefully add more people in the right place to speed things up. If anything, the points you make support the ideas of the book.
Both of the famous Brooks writings, "No Silver Bullet" and "The Mythical Man-Month" are explanations of fundamental limitations, in programming languages and project management respectively.
While true that some of the chapters a bit farther than halfway through TMMM deal too heavily with the technology of the time, the remaining chapters are still as relevant today as they were when written.
In TMMM, Brooks follows a technique of "outline the problem", "show some false starts", and "propose my own solution". Some commentators above has pointed out that his own solutions may be considered outdated at this point, but his concise description of the problems inherent in large projects make the book worth reading.
One theme he keeps coming back to is communications overhead as a limiting factor for large teams. As a thought experiment, consider the effect of the Internet as a communications medium for programmers, and the catalyst that has been to large open source projects.
Personally, I would read the book just for the "The Joys of the Craft" section. I've never read anything that so elegantly describes what programming at it's best feels like.
(If you're curious, it's on page 7, and viewable in the amazon.com "Look Inside!" feature)
I certainly think things like "No Silver Bullet" are just as applicable today as they were decades ago, especially as we see more and more young people come into industry and think x is the latest and greatest killer language/technology and all the other technologies will die because of it.
Granted, the references to Ada or sharing computers are antiquated, but the concept of accidental and essential difficulties, buy vs. build, how code is complex by definition because we don't repeat parts, and all the other theoretical topics are still completely accurate and relevant.
The other argument for why TMMM is relevant is that, it's not really about software itself but about how programmers get things done. In this way, it's hard for it to become obsolete.
The two that stick out in my mind: "version 2" still applies and so does "adding more people not necessarily faster".
Spolsky discusses "version 2" in his own way. I do not recall if he specifically links to MMM but it is very similar in concept.
Communication has become a lot more efficient than when MMM was identified, however, I think it's all proportional. It takes a lot more to make software production ready than it did when MMM was written.
Someone said that everything in computer science was discovered in 1960 something and everything since then has been derivative.
Read TMM as a book outlining a problem, perhaps THE problem, in software engineering: its not the technology, its the people! All the improvements you mention spring from that core realization. They are all in place to solve the problems Brooks laid out. This is the book that I'm sure Kent Beck and Ward Cunningham and Alister Cockburn and Martin Fowler all read, took to heart and then began to craft their silver bullets.
I consider this to be one of the "must read" books for anyone who wants to understand the software development process.
The demand for development workforce has been growing rapidly last 40 years, and this need will not stop. Since the rate of clever (vide Joel’s “smart and get things done”) people in the population remains generally the same, educating more and more developers each year means that the average smartness of a developer is getting lower.
40 years ago, it was demigods who became developers; 20 years ago, it was a job for clever people, while now when I look at young CS students at my Alma Mater it seems that they are taking everyone who knows what a computer is.
This does not mean a disaster is coming – western world keeps importing smart people (or outsourcing work) from emerging markets or third world countries. The new development tools make it easier to develop good applications. Those factors seem to neutralize each other, making MM-M eternal true.
The Mythical Man Month is a very dated read, but the core truths still apply. Sure Brooks discusses the need for a secretary which is clearly not true today and his concept of a surgical team doesn't work well, but most of the book is still accurate. His insight that communication requirements increase along with the size of the team is still true. His observation that adding people to a late project makes it later has been born out by a lot of projects. Unit tests help a little, but they don't stop one from misunderstanding the code or asking a lot of questions. No Silver Bullet also continues to stand the test of time.
All of it. The simple fact is that software projects are nontrivial; we build our own domain knowledge, really, directly into our solutions. Domain knowledge transfer is costly, both for the transferrer and for the transferee; this has not changed. And I, for one, believe it never will, no matter what the practices and tools used. Things may get marginally better, but the simple fact is that teaching and learning are both expensive and difficult things, and there's just no way to avoid them.
The social factors are still present, because humans are still essentially the same beasts we were 50 years ago.
The technical examples are almost completely obsolete, and only make sense when you think about the 0.034 MIPS System/360 of 1964. When you've only got 8 KB of memory, suggesting that the user should be responsible for handling leap years, instead of wasting 26 bytes of system memory (as Brooks did) made sense, but today it seems downright silly. I don't know any system that small today -- your telephone is thousands of times more powerful than the most powerful OS/360 system. Today we know a lot more about usability and human-computer interaction, and making the user responsible for that category of thing is just crazy.
One programmer can now write more code/build more software than one programmer could back then, but adding the second developer is not going to produce twice as much.
If/when I get on a project with good design documentation and processes in place, I'll let you know if that improves anything.
If you think of a large project that is late, it is then most likely in crisis/panic mode, as with most things in this mode, the best answer is a half decent plan, simply throwing more resources at a crisis doesn't solve anything other than waste resources and compund the problem.
There is no substitute for scheduling (pronounced shed-uling), planning and decent management.
As with most of these "one liners" or "golden rules", consider them more guidelines (with context) than set in stone.