Prev: Confusion in address generation for MIG generated DDR2 interface
Next: Writing Hex values to file in VHDL?
From: Nico Coesel on 25 Mar 2010 14:02
Patrick Maupin <pmaupin(a)gmail.com> wrote:

>On Mar 24, 6:57=A0pm, n...(a)puntnl.niks (Nico Coesel) wrote:
>> My experience is that people don't like change and like to stay stuck
>> in old unproductive methods. Sometimes you need to push people
>> forward.
>
>My experience is that learning a new tool is only worthwhile if you
>are going to use it a LOT and gain a LOT from it. My experience is
>also that a cursory examination of a tool can usually give you a
>reasonable feel for whether this is going to happen or not.

Which is why Eclipse is such a fine tool: it supports a lot of
languages and platforms so you'll need to learn one tool and get going
with many languages and platforms.

>> Thats rubbish. Perhaps true for the simple IDEs intended to give
>> people a quick start. I don't like those either.
>
>See, those are the ONLY ones I like.
>
>> Eclipse is a whole other story though. It is designed to aid working
>> on complex projects. I have several projects that share a common code
>> base and some of those projects result in 10 to 20 slightly different
>> binaries. Eclipse helps me to organize such projects. A makefile
>> keeping all the defines and projects definitions apart would be a
>> nightmare. And that is besides the many aids Eclipse provides like
>> having a list of types, variables, defines and functions from a file,
>> showing call hierarchies, shading parts that are not getting compiled,
>> refactoring (renaming symbols), comparing versions from a version
>> control repository, etc, etc.
>
>No, the nightmare is finding the configuration button to set the
>project exactly right. IMHO, if you delegate the complex stuff to an
>engine like this, you lose control over it rather than gain control.
>And once again, I will refer you to Linux -- is your project really
>more complicated, with more options, than the kernel? Do you really
>think all the kernel hackers are Luddites?

Yes, they are. My job includes kernel hacking and I'm finding the
total lack of proper documentation, comments and the obfusticated C++
objects simulation in C a big hurdle. IMHO the audio handling in the
Linux kernel is a complete mess. Kernel hackers may like the Linux
kernel the way it is now but in reality it is a cow's turd you want to
stir in as little as possible.

>> Ofcourse you can do all this with a command line tools but it is way
>> less productive and more prone to errors than having everything
>> presented to you in a GUI. I never liked developing while peeking
>> through a key-hole. When I need to work on an software project I
>> always load the source into Eclipse because it allows me to examine
>> the structure of a piece of software very quickly. Where is this
>> function called from? Just open the call hierarchy. What is this
>> define? Just move over it with the mouse pointer. Where is the define
>> or symbol declared? Shift-click and you'll have the answer. Open a .h
>> file for examination by shift-clicking on it.
>
>You haven't described anything in this paragraph that can't be done
>with a decent modern editor.

In that case Eclipse contains a decent modern editor.

>> Not to mention debugging. Its all there. And I forgot the best thing:
>> Eclipse works the same way for different languages. Writing and
>> debugging a C/C++ program works the same way as debugging a PHP
>> script. Eclipse is about learning one workflow and apply it to any
>> language.
>
>Ahh, THERE is a difference between editors and IDEs. Yes, debugging.
>Well, I write most of my software in Python and spend very little time
>debugging. Most of my Verilog tests are self-checking, and I
>sometimes look at waveforms, but very little else. I don't think I
>have personally set a breakpoint in about 15 years, since I used to
>have to write C/C++, so this is not very high on my priority list (and

I wonder how much time you spend on finding a typo. A debugger is most
helpfull in those cases. I use the debugger mostly for verification so
I'm absolutely sure my software does what it is supposed to do and not
that the answer seems right.

>Of course, one probable reason for that is that somebody started to
>document how impact works in batch mode, and gave up because the
>software sucks so badly that you can't accurately describe its
>behavior without calling attention to just how bad it really is.

LOL!

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico(a)nctdevpuntnl (punt=.)
--------------------------------------------------------------
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7 8
Prev: Confusion in address generation for MIG generated DDR2 interface
Next: Writing Hex values to file in VHDL?