[Ldsoss] Wireless Networks in Church Buildings

[Ben Galbraith]

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.

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.

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 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.

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
>>>>> Ldsoss at lists.ldsoss.org
>>>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Ldsoss mailing list
>>>> Ldsoss at lists.ldsoss.org
>>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Ldsoss mailing list
>>> Ldsoss at lists.ldsoss.org
>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>>>
>>
>> _______________________________________________
>> Ldsoss mailing list
>> Ldsoss at lists.ldsoss.org
>> 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
> Ldsoss at lists.ldsoss.org
> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>