|
Boost : |
Subject: Re: [boost] [VS2017][release] vswhere.exe
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-04-06 15:17:26
On 4/6/17 7:40 AM, Andrey Semashev via Boost wrote:
> On 04/06/17 16:54, Paul A. Bristow via Boost wrote:
>>
>>> -----Original Message-----
>>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of
>>> degski via Boost
>>> Sent: 06 April 2017 14:19
>>> To: boost
>>> Cc: degski
>>> Subject: Re: [boost] [VS2017][release] vswhere.exe
>>>
>>> On 5 April 2017 at 20:23, Tom Kent via Boost <boost_at_[hidden]>
>>> wrote:
>>>
>>>> That doesn't help us for the installs of VS2017 that are already out
>>>> there
>>>> and may not see updates. We definitely can't depend on users getting
>>>> the VS
>>>> update in a timely manner.
>>>
>>> To those users that are unable to use google, unable to click a link and
>>> download an executable, and those who don't understand what "put the
>>> executable in your path" means, the use of most boost libraries is most
>>> probably above their pay-grade anyway. You're looking for nails at low
>>> tide...
>>
>> I disagree - MS IDE users expect it all to 'just work' from the IDE.
>>
>> They rightly don't expect to mess about with funny paths and hideous
>> command windows.
>
> While I generally agree that the simpler installation and use process
> the better, a developer who haven't heard of PATH or command line is not
> a developer.
>
> MS has brought the mess with toolset location on its users. We can do
> only so much to not make things worse from our end. Giving simple
> instructions to follow is IMHO enough.
>
>
An interesting little thread which goes to a large problem with software
of all kinds today. The problem is software which "usually works",
"mostly works", "can be made to work", etc. Rather than "works" or
"just works".
tl;dr;
If I'm working on a command line system it generally works as
advertised. I have to be pretty specific and coordinating all the
resources - libraries, compilers, debugging documentation, information
lookup while coding, etc. all has to be done "by hand". I have to
lookup command syntax all the time. It's straightforward but can be
(very) tedious. Enter the IDE, it integrates all the above in a slick
package. Very cool and slick - got to love it.... Until - I need
something and I can't find it !. It can be hours searching for menus
for the proper setting, or tweaking paths, or any number of things. So
now I'm back in to spending time on a bunch of stuff I had started using
the IDE to avoid! Now I'm told that if I'm a real developer, I should
know all this other stuff - That is, it's my fault!
The IDE maker has the solution - make the package even more
comprehensive and opaque - (that is, "user friendly"). This usually
means having deeper menus and settings sprinkled all over the place.
This compounds the problem rather than addressing it. The real solution
is to spend more time thinking about the IDE and it's design so that
there is more of a direct link from what I want to what I do. But
programmers don't want to do this. They just want to add more code.
When ever there's a complaint - we'll fix it with more code, more
settings, more "smart"/"automatic"/"environmentally aware" behavior, etc.
Of course it's not just the IDE it's everything websites, apps,
everything. Look at our own tools - they're more obscure than the
problems they are trying to address. (Include CMake and other build
tools as well).
The only real solution is more literate programmers, more feedback from
users, and more willingness on the part of programmers to accept the
fact that if it doesn't work for the user - the job isn't done. A
program is not just a collection of random features but needs to embody
a logical concept that the human brain can capture.
Robert Ramey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk