Ben Galbraith wrote:
> Paul,
>
> For what it's worth, the folks I cited as having opined on the subject
> are a small, small subset of those supporting the
> "concurrency-is-hard" position. I could add Brendan Eich (inventor of
> JavaScript), Kevin Lynch (Chief Software Architect, Adobe), and many
> others to the list, all of whom have publicly or to me privately
> discussed the issue.
>
I could trot out a list of names as well, and that would prove nothing,
and get us no where in the discussion other than
we would all know their opinion.
> Your intimation that those thinking threading is hard are simply just
> not schooled in the same fine arts of computer science that you were
> ("Do they not teach these basic skills anymore?", as you put it) is
> probably not a defensible position.
>
I ask the question rhetorically, as more and more, people seem to want
to revisit the same old problems
and call them new.
> Every now and again I meet people who argue your position, which I
> essentially distill as: "C is for real programmers, Java and other
> languages are for sissies". If I have to work with such individuals,
> I'll engage in a thoughtful debate. If not, I usually smile and
> continue on my merry way. <Smile>.
>
I never said that. What I did say was Java is fine for what it does, I
personally don't like it for what I want it
to do, and I find C and other tools better for my problem solving. But,
you are welcome to your opinion, just
don't put words in my mouth in the process. <Smile>> I feel my point is getting lost: it is not trivial for the MLS team to > make data transfer occur in the background (whereas displaying a modal > dialog is trivial). However, your feedback is great and I'm sure > they'll appreciate it and all the various requests from folks on this > list to make data transfer in MLS a non-blocking operation. > I agree with you - but, again, you are taking the position that just because it's difficult for them, by fiat, it must be difficult for everyone else. It's not. The question on the table should be: how are "we" going to solve this issue? If they find my feedback useful - great. If they want my help, they can hire me. ...Paul > Ben > > > On Nov 22, 2006, at 6:40 PM, Paul Penrod wrote: > >> Hi Ben, >> >> My comments below... >> >> Ben Galbraith wrote: >>> Hi Paul, >>> >>> On Nov 22, 2006, at 2:36 PM, Paul Penrod wrote: >>>> Forking a process for communication does not require significant >>>> additional complexity >>>> if it's done right. Even DOS was capable of background transmission, >>>> which I did way >>>> back in the 80's. Windows XP is the baseline for all the machines here >>>> in our stake and >>>> it is far more capable of background transmission - especially over >>>> modem. >>> >>> Creating a thread == easy. >> Agree... >>> >>> Dealing with the complexity of having created the thread == hard. >>> >> It can be in some situations. Generally not, when design is proper. >>> Please allow me to preach to you for a paragraph: It is generally >>> acknowledged across all modern programming platforms that the problems >>> of dealing with concurrency are amongst the most difficult facing >>> software developers today. Anders Hejlsberg (lead architect, C#), Doug >>> Lea (foremost Java concurrency expert), Brian Goetz (author, Java >>> Concurrency in Practice -- the best concurrency book today), and >>> others have all spoken out on this topic. Perhaps Anders characterized >>> it best when he told me that today's threading models don't scale >>> because "there aren't enough Ph.D.'s in the world." >> Ok, I won't argue that, given these folks are talking Java, etc. >> However, I will disagree with the threading model >> comment. It doesn't take a PhD to improve a threading model as evidenced >> by such examples as BSD, Linux, >> and the like. >> >> As to dealing with concurrency, that was the same problem facing >> programmers back in the 50's and 60's, so this is >> nothing new. >> >> Back in my generation, the scaling complaint with concurrency was with >> COBOL, RPG, etc. >> >> Wrong tool for the job, but people tried anyway. >> >> Java was originally designed for the General Instruments set top box. It >> has since grown into the amalgamation it is today. >> I'm not saying Java is not useful, but I do not like the design of the >> language and extensions for concurrency, as that was >> never part of the core, when Gosling first wrote it. >> >> My tools of choice include C, which by it's simplicity of design >> (created to write operating systems, etc.) allows for >> concurrency, object modeling, and all the goodies many of the current >> and coming generation of programmers think >> is the foundation of computing. It's not, but then most of the new EE's >> in the last 10 years don't design with discrete >> components, but rather IC's and ASIC's. >> >> It's all a matter of perspective. >> >> The advantage of many of these tools you have to work with is that you >> can abstract the hardware and many times >> the OS away from the application development. This is also the short >> coming. Without a clear understanding of how >> an OS works, how a scheduler threads, how many of the "hidden" functions >> work, you are left totally dependent on >> the abstracted layer to get the job done. This only comes back to bite >> you when things do not work as they should. >> >> Personally, I think Unix and it's variants work just fine for >> concurrency, especially when you have tools like X, Qt and >> an OS that is designed from the ground up to be multi-user, >> multi-tasking. It makes the job that much easier, since you >> don't have to fight the environment. But I digress. >>> >>> Having said that, as has already been observed in this list, Afaria >>> does the communication for MLS. Thus, there is already a separate >>> process performing the communication. Discussions about creating >>> separate threads to do this or that at the data transmission layer is >>> orthogonal to the issue at hand. >>> >>> The issue is whether MLS deals with the complexities of allowing you >>> to use the program while the data transfers in the background. Among >>> the issues to consider are: how to notify the user of the status of >>> the transfer in progress, how to reconcile live changes you may be >>> making with conflicting changes that may be received from the server, >>> what to do if you try to quit the application while the transfer is in >>> process, how to prevent re-entry to the same process, and so forth. >>> Compare this complexity with "display modal dialog to user". >> Common issues in a MU/MT environment. >>> >>> These problems, when viewed individually, are not rocket science. In >>> aggregate, the additional complexity in simply designing the user >>> experience for a multi-tasking interface is considerable, and that's >>> not including all the complexities associated with the implementation >>> of the interface and ensuring that race conditions and deadlocks are >>> all properly handled (conditions which are difficult at best to debug). >> I'm sorry Ben, I just don't share your sense of the complex here. >>> >>> I'm not saying one shouldn't design multi-tasking GUIs and so forth. >>> But please understand it's not an issue of saying, "Oh, let's flip the >>> thread switch and the problem is solved." It's an undertaking, one >>> that must be prioritized with a long list of additional undertakings. >>> But as I said originally, I'll pass the feedback along. I can't speak >>> for the MLS team or the Church in any official capacity, but I am >>> aware of many discussions by those responsible for MLS on this topic >>> and I anticipate a solution to these problems will emerge. >>> >> If people are going to get all wound up about this as being difficult, >> please, don't bother. >> It will only cause more confusion. >>> If only this were simply an issue of a communications layer. That, as >>> you are right to say, is the easy part. >>> >>> Best, >>> >>> Ben >>> >> I can appreciate your position. But as I said before, this is all a >> matter of perspective. My days of programming and >> design were centered around solving problems like this all the time, and >> with much more "primitive" tools and kernels. >> >> I did not learn to program in a modal environment such as DOS/Windows. >> >> Do they not teach these basic skills anymore? >> >> The root problem, as you have partly surmised, is not in the technique >> of threading, etc. but manifests in the design of the >> application. However, it's not application, but the mindset around it's >> creation that needs to change before real progress >> is going to be made. If you have a group of software people that >> understand monolithic / modal only - that is what you will >> get for a solution every time. It's what they know. >> >> That's not a bad thing, but it's not a one size fits all solution. >> >> Best, >> >> ....Paul >>> >>> >>>> >>>> As someone who spent years in communications - it's not that hard to >>>> engineer properly >>>> the first time. These days however, there is a serious lack of talent >>>> that understands serial >>>> communications at a low level. They would rather throw it over the >>>> fence >>>> to an API and >>>> whine about how hard it is, when things don't work. >>>> >>>> As a stake financial clerk, I would regularly see 15-30+ minute work >>>> stoppage due to >>>> transmission times, cryptic status messages, retransmissions, and >>>> complete transmission >>>> restarts, as the modem would lose the connection. >>>> >>>> MLS fixing their communications layer (or lack of it) would go a long >>>> way to make things >>>> work much better. Also, since it appears you have someone's ear, >>>> placing >>>> useful status >>>> and/or progress messages in the status window would go a long way in >>>> help clerks understand >>>> where they were in the process and in the problem resolution phase >>>> where >>>> they would be on the >>>> phone with SLC and could articulate where the process died and the >>>> message that last appeared. >>>> >>>> Basic QA... >>>> >>>> ....Paul >>>>>> Also, as finance clerk, I'm pretty good at making sure I transmit my >>>>>> changes >>>>>> to SLC. However, it often annoys me that instead of taking just a >>>>>> short >>>>>> time to transmit my finances, I get a lot of membership updates, and >>>>>> have to >>>>>> print out all those reports. Sometimes I really wish that if a >>>>>> finance guy >>>>>> transmits, only the finances are dealt with. Likewise for >>>>>> membership >>>>>> I'm >>>>>> sure. (Although I doubt he ever gets finance reports) >>>>> >>>>> Good feedback; I'll pass that along. >>>>> >>>>>> My apologies for the tirade. It's just something that has always >>>>>> bothered >>>>>> me, and I can't explain why. >>>>> >>>>> It's a separate thread to explore this topic, but of course we're all >>>>> very bothered by software that forces us to go through extra work to >>>>> accomplish repetitive tasks -- especially those of us who by our >>>>> natures try and be as efficient as possible. >>>>> >>>>> Thanks, >>>>> >>>>> Ben >>>>> >>>>>> >>>>>> ---- Joe >>>>>> _______________________________________________ >>>>>> Ldsoss mailing list >>>>>> [email protected] >>>>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Ldsoss mailing list >>>>> [email protected] >>>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Ldsoss mailing list >>>> [email protected] >>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss >>>> >>> >>> _______________________________________________ >>> Ldsoss mailing list >>> [email protected] >>> http://lists.ldsoss.org/mailman/listinfo/ldsoss >>> >>> >>> --No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.430 / Virus Database: 268.14.14/547 - Release Date: >>> 11/22/2006 5:41 PM >>> >>> >> >> _______________________________________________ >> Ldsoss mailing list >> [email protected] >> http://lists.ldsoss.org/mailman/listinfo/ldsoss >> > > _______________________________________________ > Ldsoss mailing list > [email protected] > http://lists.ldsoss.org/mailman/listinfo/ldsoss > > > --No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.430 / Virus Database: 268.14.14/547 - Release Date: > 11/22/2006 5:41 PM > > _______________________________________________ Ldsoss mailing list [email protected] http://lists.ldsoss.org/mailman/listinfo/ldsoss
