On Mon, 2005-07-25 at 09:00 +0100, Ben Clewett wrote: > I like what you say about computer science being a Science. This is > exactly my point. A science is a collection of theories which hold true > within a domain until otherwise dissproven. For instance Isac Newtons's > law of gravety and Einstain's law. Both are true within a fixed domain. > Both are used today. Neither are truelly corrrect. There will be > another more complex theroy in time.
You have that backwards. They remain theory until proven. Not the other way around. > This is the same with Threading. There may be places where this is > useful. There may be places where it should not be used. Both are > theories within computer science which hold true in a limited domain. > So when I said this was my opinion, I should have stated this is my > theory within a fixed domain. However when you stated that I was wrong, > I don't think this is compatible of your statement that Computer Science > is a Science. Nothing in any science is either right or wrong. That's > a Religion. You have that backwards. Science most certainly has right and wrong. We also find it useful to examine things that aren't known to be right or wrong, but it is that that makes science different than religion. > I don't want to spend ages on the argument, I can see there are > passionate views. I only want to explore the idea that threading is a > viable strategy for a modern high level language and can produce stable > applications with low development time. That's incorrect. Threading increases development time and produces less stable applications. In fairness: it's the skill level of the engineer that does this, but then, they _did_ chose to use a threaded development model. http://www.google.com/search?hl=en&lr=&q=problems+with +multithreading&btnG=Search Maybe you're special. Most people aren't special and as soon as you throw threads into the equation they can't find their ass with both hands. > For instance a call to a TCP blocking Wait. It's perfectly possible for > one thread to cycle round handing GUI events, then checking on the port > for new packets. > > But an alternate method is to partition the code space into two > autonomous threads using their own variable set. Two simple sets of > code which are not coupled, and remain highly cohesive and encapsulated. That's why we have the select() system call. That's why GTK uses glib to encapsulate file descriptors (including those of sockets) so that event programming can allow the GUI events to be processed "immediately" and then handle "other things" without worrying about threads. If you use a language like Java or Javascript (or lisp or perl or etc, etc) you get something called a "closure" - and they make using event-programming-think a real pleasure, because you don't have to worry about locking, or surprises because race conditions simply won't occur. http://www.kegel.com/c10k.html Should be read by anyone thinking they need threads "for performance reasons". > Communicating through a thread-safe object. Such code is fast to > write, easy to read, robust and does the job. I can complete this in c# > in ten minutes, and it will not break. With large amounts of time, > better methods may be available. But this theory is viable within its > domain. This is speculative, and doesn't provide anything useful to anyone reading this thread. > > I wasn't about to consider Windows a modern GUI system :) > > Are you saying it's not modern, or not a GUI? It may not be prefect and > it is very complex. But it's not about to go away, and it's installed > on modern computers. More importantly, my views on threads remain. If > you give the GUI it's own thread, you have implemented a simple solution > to ensure that the correct cursor and mouse events are honoured. Then a > worker thread is free to do what ever it likes without being coupled to > the GUI. Simple robust coding using thread-safe objects. It's a joke, and it's moot anyway. As Richard pointed out, Windows doesn't demand threads from its programmers either. > I am also interested in peoples views that threading is slower. Since > all processors are likely to be hyperthreaded, multicore, or both. I > can see no place where this will be true in the future. Threading is often slower, but if you're worried about the performance drops that _threads_ cause, you wouldn't use C#. Threading is _harder_to_program_. It makes buggier programs. Fewer people can follow and debug it as the program gets larger. And worst of all: people are continually encouraged to use it for exactly the opposite reason. > > Java uses references, not pointers. > > Is there any important difference? My point was not about language. It > was a question to Dr Hipp about what he feels is missing from the Java > pointer (reference) model. Perhaps I should have explained better. I brought this up. Pointers have their own value. References don't. The compiler can optimize away duplicate references, but it cannot optimize away pointers. > Yes, I understand that 'c' can make use of goto, and that goto is fast. > There are also very very bad places to use goto. Exceptions, breaks > and continue statements are linear code, easy to follow and more robust > to code changes. Goto is a legacy of assembler programming. I don't > think it's time to teach new coders about goto. Which is my theory > within a fixed domain. I think that the reason that you think goto should not be taught/avoided is the EXACT SAME REASON I think threads should not be taught/avoided. I think that there are perfectly healthy places and reasons to use goto, as well as perfectly healthy places and reasons to use threads. I simply affirm that if you can't use goto - for whatever reason, chances are you can't use threads correctly either. This mailing list is an excellent example of how many "professional programmers" simply can't deal with threads- every problem they run into, it's "how do I make sqlite work with threads". If you have to ask that question, you simply have no idea what you're doing.
