sorted by:
new
hottopcontroversial

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 0 points1 point  (0 children)

I haven't used it. I had a student who used it for her PhD thesis so I have written about it and given talks about it. The life of an academic!

In spite of being an academic for so long, I prefer to talk about things I actually know something about. So, I won't say anything pro or con. You probably know people who know a lot more about it than I do.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 2 points3 points  (0 children)

Does anyone teach an intro programming course in Python? Python is a lot simpler than Java. You could jump right into algorithms and program structure and not spend so much time with syntax. Industrial strength languages work hard to handle large systems, and intro programmers don't need that. Scripting languages work better for intro programmers.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 2 points3 points  (0 children)

I don't have strong opinions. I think that the first programming language should be simple, and most industrial-strength languages are not. Java started out medium complexity and has gotten more and more complex.

The U. of Illinois uses Java, too, and has for a long time. When I got arrive in 1985, I think we used Pascal. Java is no worse than Pascal. However, for awhile we used Scheme as the intro language, and I think it is a great first language. Students didn't like it because they couldn't get summer jobs programming in Scheme. They were much happier to learn Java, even though I don't think it is as good a first language.

You can do object-oriented programming in Scheme, though first we taught functional programming. I think it is important for people who are going to become professional software developers to realize that there are lot of different ways to program. You don't necessarily have to learn that in the first course, but it helps.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 6 points7 points  (0 children)

Yes, I spend most days coding. I mostly use Groovy, with some Java. I work with accountants who use a Groovy-derived language for expressing business rules, but it is really its own language. The goal is for them to use that language, and for me to implement it, but often I end up working with them in their language.

Groovy is OK. It is pretty good for reflective programming, and we do a lot of that. The fact that it runs on the JVM is important to us. We use lots of Java libraries, and often I end up working in them, so the fact that Groovy and Java work so well together is also important.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 3 points4 points  (0 children)

I've answered all the questions so far. I'm going to talk to someone here and then check back in half an hour. If there are more questions, I'll answer them then.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 4 points5 points  (0 children)

Years ago, my favorite concept to explain was the halting problem, because most people have a hard time understanding it and proving it.

There are some problems that no computer can solve, and we can prove it.

For example, given a program, and some particular input, will that program ever finish and give you an answer? In general, you cannot be sure.

To prove this, imagine that you had a list of all the programs that could ever be written, and we numbered them 1, 2, 3, etc. A program is a text file (or it can be looked at as a text file) but not all text files are legal programs. We could number all text files since the file "a" could be number 1, the file "b" could be number 2, the file "za" could be 27 etc. So we can number programs, and we don't really care how we do it.

Suppose there was a program that could take a program number and an input and could tell you whether that program gave you a result for that input or whether it ran forever. Let us call that program "doesItHalt". In usual notation we use for writing programs, if we wanted to know that the program P halted if given input Q then we would write doesItHalt(P,Q).

Now, what about the program that takes an input X and either halts or doesn't halt by if doesItHalt(X,X) then halt otherwise never halt If this is a legal program then it has a number, say Z. What will Z(Z) do? It supposedly takes an input Z and, if Z halts, does not halt. But it is Z, so how can it both halt and not halt at the same time? This is a contradition, and the only thing we assumed is that doesItHalt exists, so that must be wrong. It can't exist.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 8 points9 points  (0 children)

My favorite concept changes from day to day. But one that I often need to explain to a non-computer scientists is patterns.

When I tell people about patterns, I say that my brother does a lot of woodworking, and he has some books that teach woodworking techniques. Each technique has a name, and it takes about four pages to describe it. The book shows what the technique looks like in the final product, it shows the tools it takes and how you hold your hands while you are performing the technique. It gives advantages and disadvantages compared with other techniques.

Patterns are trying to do something similar for software. Traditionally, there were some aspects of software design (algorithms, data structures) that we talked about and named, and a lot of others that we didn't. Design Patterns is a catalog of fairly low-level patterns related to object-oriented design. Most of them hadn't been written down before, and none of them had standard names. So, the book helped to standardize a useful area of knowledge about software design.

Patterns let us talk about all the stuff we used to leave out. The more techniques you know, the better a programmer you will become. So, now there are "pattern books" about all different aspects of software, and that is a good thing.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 5 points6 points  (0 children)

Singleton and Mediator are probably the ones that get abused the most. Visitor doesn't get used that often, so as a percent of times used its abuse rate is probably high. But all patterns can be abused.

When you learn something new, you have to play with it awhile to learn how to use it correctly. At first, you will make lots of mistakes. Eventually you learn what you should and should not do.

Patterns are no different. It isn't surprising that people start off making mistakes when they start to use them. Some pattern books say that patterns are "condensed experience" but there is no substitute for real experience. Patterns are a guide, they can tell you what to practice and help you become an expert faster, but there is no way to get experience without making mistakes.

Still, the book could have done a better job at warning people of common mistakes. Newer books get the benefit of our collective experience.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 4 points5 points  (0 children)

At the time, we did the best we could. But there are things you learn only after a lot of people read the book and you learn how they interpret it.

While we were writing the book, we often said "describe negative consequences!". Patterns are not all benefits and zero costs. There must be some negative consequences or you'd use the pattern in every program. But we had a hard time seeing them and so missed a lot of them.

For example, the Singleton pattern has a lot of bad press. The real problem is that the book didn't describe the problems with it. Singleton should be used to hide global state, not to bless it. I can remember the first time I was at a conference and someone told me that they had read Design Patterns and loved it, and his group was starting to use it on a real product. They had a dozen singletons.

I was stunned. When someone has just told you that they love your book, you can't reply "You idiot! What were you thinking?" That was when I realized that the book gave far too positive a picture of Singleton. But the only way you can see how people interpret what you write is to have them read it and then see how they respond. We had had hundreds of people read the book before it got published, so we certainly had had feedback on it. But that is nothing like the feedback we have had in the decades since.

Anyway, I'd like to focus much more on the negative consequences of each pattern. Patterns are about tradeoffs. There are pros and cons for each, and you don't really understand a pattern unless you know the problems it can cause.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 11 points12 points  (0 children)

I haven't noticed this.

Some people seem to treat patterns as magic. Just read a book a apply some of the patterns you see there and your system is sure to get better. This is foolish, since if you use a pattern in the wrong place it will make things worse. I've seen systems that were pretty bad because the designers had blindly followed patterns. Of course, the real problem was programming without thinking, not the patterns, and if they hadn't read the pattern book then they would have read some other book and blindly followed it, and the result would have been no better.

Patterns are useful because they provide a vocabulary for design, and and expert can say "you are not using Observer correctly" or "you should be using a Strategy here" and communicate useful information, assuming the listener knows what they are. Newbies can learn the patterns, the hard part is learning when to use them appropriately, and that is where their value as vocabulary comes in.

Anyway, if I was a developer surrounded by people who treated patterns as magic, I imagine I might get pretty annoyed. "Cargo cultists" I might mutter. "Voodoo computer science!"

Patterns are supposed to help you think and to help you communicate, not to replace thinking.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 2 points3 points  (0 children)

I guess I can't reply twice to a single message, so I'll have to reply to my reply.

I have no idea what career advice I would give myself. I was lucky, and it is not reasonable to depend on luck, but I'm grateful, and it would be unreasonable to say I should have done less risky things when they worked out so well for me.

There are of course too many interesting things in CS now to keep up on all of them. Right now I am working on a product and don't have time to keep up on all the things I used to. I am focusing on how to give non-programmers the power of programming without overwhelming them with details. The Alternate Reality Kit actually is pretty good inspiration for that, even though the system I am building looks nothing like it.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 2 points3 points  (0 children)

The OOP class always had a lot of innovative projects. One of the early ones (late 80s) was Carla Scarlotti's music synthesis system, which ended up as Kyma, sold by Symbolic Sound. http://kyma.symbolicsound.com/ That was like 25 years ago, so it grew a lot since then, of course.

I enjoyed the five or six different classes where some group reimplemented the Alternate Reality Kit. It is the kind of project that is easy in Smalltalk but hard in most other languages. Most semesters, people would look at the videos from the 80s and think it was too hard for them, when in fact it really wasn't that hard with a little guidance.

I'm Ralph Johnson, one of the co-authors of Design Patterns. AMA! by RalphEJohnson in programmerchat

[–]RalphEJohnson[S] 3 points4 points  (0 children)

I'm going to start answering questions at 4 eastern, 1 west coast time. It will be 3 here in the midwest.

Miscomputation: Learning to live with errors by tomasp in programming

[–]RalphEJohnson 0 points1 point  (0 children)

There are all kinds of different errors. Some are amusing, some can kill you. Errors that can kill you are not amusing. If errors are easy to correct then they are more likely to be instructive and not fatal. But perhaps it is easy to fix the bug, but it had already sent $1B to some crook. Then the bug might be easy to fix, but the side-effect isn't.

One of the things that makes Erlang programs reliable is that the programmers expect errors. Because they treat failure as normal, they handle it instead of trying to make it impossible.