Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT feedback from students this semester

I¹m not sure we¹ve ever claimed that CDT has remote build capabilities at
all. So I¹m not that surprised you colleague had problems.

Nothing happens in CDT without contributions. Feedback would be awesome
but we also need people to implement improvements based on that feedback.

Doug.

On 2017-01-02, 5:05 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Mikhail
Barg" <cdt-dev-bounces@xxxxxxxxxxx on behalf of mikhail.barg@xxxxxxxxx>
wrote:

>Hello guys,
>
>I also have a kind of feedback on the latest Eclipse usability as well.
>My colleague recently faced a need to remotely debug some Cpp app, and
>asked me for a tool. Surely I've suggested using CDT for I knew it has
>mature remote build/debug capabilities.
>
>Later he came back to me and told me that he was not able to make sense
>of CDR remote debugging and instead used NetBeans, which "just works".
>He told me that all that he had to do for NB was to specify a network
>path where the project is located on a remote machine (and some
>credentials for logging in), and he got all the things he could think
>of, IDE just worked as if the project was local, while running and
>debugging it on remote linux machine.
>
>The thing that puzzles me is that the guy is not completely new to
>Eclipse, he's been working with CDT for few years (but that was also
>like 4 years ago, same as me) and he's completely new to NetBeans, but
>in the end he had to switch to NB.
>
>I can ask him to give a more detailed feedback regarding the problems he
>faced with CDT while setting up remote debugging, or how it compares to
>NB, if you feel like getting this kind of feedback.
>
>
>16.12.2016 0:31, Leo Ufimtsev wrote:
>> Hello,
>>
>> As per request in CDT discussion:
>>
>> I've had some feedback from students who used Eclipse CDT this semester.
>>
>> Here is a compiled summary based on around 10 replies that I got back
>> from survey. (Class of 150 students).
>>
>> *Context: *
>> - A 2nd year university (University of Toronto, Canada) course on System
>> programming in C.
>> - Eclipse CDT was used as their main IDE this semester (for the first
>>time).
>> - I held a guest lecture on how to setup and use Eclipse CDT at the
>> beginning of the semester and helped some students get going with it.
>>   Lecture slides:
>>
>> 
>>https://docs.google.com/presentation/d/1ztUv_Dgt6tFhP9-k4MuKJXXbk1ft-6Gzn
>>_IXrZ8XsX4/edit?usp=sharing
>>
>> - Eclipse was used for 3 C based assignments.
>> - I had University IT staff pre-install the Eclipse CDT spin on
>> university computers. (Ubuntu 14.04)
>> - Some students had familiarity with Eclipse JDT.
>>
>> Please note: Student's often complain that applications are too
>> complicated because they have very limited time to learn a tool.
>> This doesn't necessarily reflect the difficulty of learning Eclipse in
>> the industry.
>>
>> *Usage:*
>> - 7/10 used Eclipse.
>>    - One used CLion. The reason was that he learned to use Intellij a
>> year ago and didn't feel like migrating to Eclipse because he didn't
>> knew it very well.
>>    - Two used only a text editor (Atom).
>>    - Those who used Eclipse CDT would occasionally use text editors (eg
>> Atom) for simple little hacks like editing makefiles.
>>    - It was rare for students to do all their work in Eclipse (although
>> possible). Many resorted to terminal for SVN, compiling or other
>> external tools as it was too complex for them to figure out how to do it
>> in Eclipse. (Although info provided in the slides).
>>
>> *Problems/Complaints:*
>> - Dark theme was not functioning that well (for older Eclipse Neon
>> release). (This is not CDT specific, but CDT users liked to use Dark
>>theme).
>> - Debug perspective feels cluttered. Too many windows and each one is
>> too small. (Even on 1900x screens). (Not CDT specific, but debugging was
>> used with CDT).
>> - Valgrind was hard to install for them. Some didn't see what
>> functionality the visual valgrind had that the command line version
>> didn't. (But Valgrind extensively).
>>
>> *Most commonly used features:*
>> - Visual debugging  (Main reason people setup Eclipse).
>> - Code navigation
>> - Keyword highlighting
>> - Refactoring (variable name/function names), Autocomplete.
>> - Version Control / Local history.
>> *
>> *
>> *Also mentioned:*
>> - Students wanted to have a Terminal build into Eclipse.
>>   - They were not aware of TM Terminal's existence (which provides this
>> functionality).
>> - Students wished for a 'simplified' version of Eclipse. Something
>> similar to PyCharm's "Edu" version which would have a limited set of
>> features just enough for learning a new programming language.
>>
>> ---
>> Leo Ufimtsev
>> Software Engineer, Eclipse team.
>> Toronto, Canada
>>
>> Red Hat, Inc.
>> Leonidas@xxxxxxxxxx <mailto:Leonidas@xxxxxxxxxx> |
>> http://DeveloperBlog.RedHat.com/ <http://developerblog.redhat.com/>
>>
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe
>>from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top