Are there technical reasons why Emacs is better than an IDE?

Mon Jun 27, 2011 1:06 pm   

It is no secret that Sigasi wants to take on Emacs and the Emacs VHDL
mode. I have posted several articles about the fundamental differences
between Emacs and Sigasi: http://www.sigasi.com/emacs
It usually boils down to the limitations of regular expressions and
pattern matching. There are just certain things that require a parser
rather than a simple pattern matcher.

To end my series of blog posts about Emacs vs. Eclipse/Sigasi, I am
interested to hear what you think: are there any _technical_ reasons
why Emacs is still better than an IDE solution? Or is it just a matter
of "I love this tool and nobody is going to deny me my rights?"

http://www.sigasi.com/content/room-improvement

thanks

Philippe

--
Philippe Faes
http://www.sigasi.com

Mon Jun 27, 2011 11:23 pm   

In comp.emacs Philippe Faes <philippe.faes_at_sigasi.com> wrote:

Who? What?


Emacs is free software. Anybody may take it on.


"It"? Differences come down to limitations? Sir, you are not expressing
yourself at all clearly.


Of course there are. What's new? Arbitrarily nested structures (think
program source) cannot be parsed by regexps. Try using a push-down
automaton.


Yes.


Hmmm. On comp.emacs. You wouldn't happen to be trolling, now, would
you?


--
Alan Mackenzie (Nuremberg, Germany).

Mon Jun 27, 2011 11:42 pm   

On 6/27/2011 4:06 AM, Philippe Faes wrote:

The full language is hard for a parser as well,
but all you need to cover are the parts
that my simulator can't feed back.

I am most interested in clean sim interfaces
and makefile generation because my simulator
is already good and fast at marking errors in
syntax (vcom -c a_unit) and
elaboration (vsim -c a_unit).

Getting these errors fed back to emacs vhdl-mode
requires careful configuration and a few custom
elisp functions. This seems to be an area where
you might have an advantage.



In any case, there are many fewer emacs users than non-users,
so you have a good chance.

-- Mike Treseler

Wed Jun 29, 2011 8:03 pm   

Le 27/06/2011 13:06, Philippe Faes a écrit :


Emacs can do soooooo many more things than VHDL editing.
Why use a different IDE for each language ?

Nicolas

Wed Jun 29, 2011 9:02 pm   

On Jun 27, 4:06 am, Philippe Faes <philippe.f...@sigasi.com> wrote:

Just a few off the top:
1) emacs can be run in batch mode, so all of the 'AUTOs' can be
updated at once.
2) emacs is a much more powerful editor. There are times you NEED
rectangle cut/paste.
3) emacs developers don't spam usenet.

I prefer less volatile discussions than editor choices - religion and
politics are typically less incendiary.

Wed Jun 29, 2011 11:24 pm   

On 06/29/2011 10:03 PM, Nicolas Matringe wrote:

That is not the proposal, quite the opposite. The proposal is
to use Eclipse as the IDE, and Sigasi HDT as its "VHDL mode".

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com

Wed Jun 29, 2011 11:32 pm   

On 06/29/2011 09:02 PM, NeedCleverHandle wrote:

The fact that you actually need 'AUTOs' (?) and batch mode shows that
a more powerful IDE may be quite useful.


Whatever it is in emacs, this is certainly not easier than
'Toggle Block Selection' (Shift+Alt+A).


This is on-topic content, written on a specific occasion by real
people. Calling it spam just because you thoroughly dislike the
message is a little cheap.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Python as a HDL: http://www.myhdl.org
VHDL development, the modern way: http://www.sigasi.com
World-class digital design: http://www.easics.com

Thu Jun 30, 2011 3:19 pm   

On 27 Jun., 13:06, Philippe Faes <philippe.f...@sigasi.com> wrote:

Maybe it is just the fact that emacs is for free and good enough, so
why bother about Sigasi?
I assume you already included open script interface in your sigasi
tool to be at least on the obvious parts on-pair with emacs, but as
long as I'm fine with gnu tool, I see no reason to check alternatives
every 6 months.

Thu Jun 30, 2011 7:12 pm   

Read "Beautiful Architecture" [1] chapter on emacs for a good look at
how and why emacs is great, and how it compares to other architectures,
namely Eclipse and Firefox.


[1] http://oreilly.com/catalog/9780596517984
Chapter 11 GNU Emacs: Creeping Featurism Is a Strength

Thu Jun 30, 2011 8:33 pm   

Thank you all for your input.

The technical arguments I hear are:

Mike Treseler wrote:

including correct navigation and refactoring.


improve on this.

NeedCleverHandle wrote:

This particular use case (automatic template expansion in Verilog)
would be a good argument for interactive tools rather than batch
processing. Checking and updating sensitivity list is something that
can easily be done interactively.

If you want to discuss any specific other use cases for batch mode,
I'll be happy to dig deeper into this subject.


interested to learn of other features that make Emacs a much more
powerful editor.

Nicolas Matringe wrote:

platform will offer a wide range of language-specific plug-ins to
choose from.

Ted Zlatanov (received this by email) wrote:

A built-in parser enables several things such as semantic highlighting
and correct navigation. As I pointed out in my original post, I have
discussed this at length elsewhere.

I'll throw in one myself:
Sorting lines alphabetically is a pain in Eclipse. There are some not-
so-stable or not-so-recent plugins that support this feature, but
people usually don't install a new plugin just to get one simple
operation.

Any other thoughts are still more than welcome.

-- Philippe

Fri Jul 01, 2011 4:46 pm   

On 30 jun, 21:12, William Stevenson <yhvh2...@gmail.com> wrote:

I looked it up and I quote:
"As a development environment, Eclipse provides valuable features that
Emacs lacks. For example, the Java Development Tools plug-ins provide
extensive support for refactoring and code analysis. In comparison,
Emacs has only a limited understanding of the semantic structure of
the programs it edit and can't offer comparable support."

Fri Jul 01, 2011 7:02 pm   

On Thu, Jun 30 2011, Philippe Faes wrote:

[...]


Emacs has a couple of advantages over tools like Eclipse. The biggest
advantage, IMHO, is that it is easy to add new code. You don't have to
compile anything, or install any plugins. You can add a new function to
your currently running instance of Emacs with just a few keystrokes. I
often find myself creating "throw-away" code to do some little editing
task that would be very tedious to do otherwise. Not only does Emacs
have code for sorting lines (and paragraphs and pages), but it is easy
to add code to sort however or whatever you would like.

Another big advantage is that you can realistically use it for most of
your text editing tasks. I spend quite a bit of my time in front of a
computer writing code. However, the fact that the Emacs skills that
serve me while writing code are also useful when creating other
documents, reading email, planning my day, taking notes, etc. means that
time spent learning to use Emacs well can be leveraged across most of my
computer-using activities.

Personally, I have high hopes that the recent integration of CEDET into
Emacs will begin to give Emacs hackers the tools that they need to build
smarter Emacs modes.

Jason

Tue Jul 05, 2011 2:22 am   

Hi everyone,

One thing I have trouble understanding is the following. Designers
typically spend way more time debugging VHDL code, running
simulations, debugging "real" hardware than writing actual code.
Therefore, I have trouble understanding why comparing Sigasi to Emacs
is so important? A lot of the Emacs feature are basically tools to
write code faster (code completion, sensitivity list updating, etc.).
Even If I write code 10% faster, this is probably the equivalent of a
driver speeding up only to being forced to stop because the light is
red. The analogy is imperfect, but basically in real life I'm limited
by the simulation speed of my simulator, I'm limited by the synthesis/
p&r of Xilinx/Altera/etc. I'm limited by real-life issues like a
faulty board, unclear specifications, project management, etc. Rarely
have I felt limited by notepad++ even though it is a simple code
editor with syntax highlighting.

I agree than Sigasi looks interesting from a code refactoring, project
management and code comprehension perspective but less so from a
"writing code faster point of view". What would be important for me,
is good integration with Xilinx (or Altera) and good integration with
Modelsim (or Aldec).

Just my 2 cents.

Benjamin

Tue Jul 05, 2011 7:41 pm   

On 7/5/2011 2:22 AM, Benjamin Couillard wrote:

How do you debug your code? Isn't this process of "debugging real
hardware" just a matter of reading your code and understanding what it
is doing? After all if the hardware doesn't work (except for
pathological cases of bad pcb/pca, see later) is just because you wrote
something wrong.
From this perspective having an editor that helps you out in the process
of reading and editing your file is definitely a powerful tool.

Would you write code with notepad? or a word processor? or with a pen
and paper?
If the answer is no (as I presume), than the added value of a smart
editor is not negligible.


That is why you should spend more time reading and editing the file
rather than running simulation.
If you try to write an ARM architecture full of peripherals and then
assume your simulation will run through and spot all the problems then I
understand your frustration, but I also believe the approach is wrong.

Project segmentation is a very old technique that is always applicable.
Make your components generic enough to be reusable, not too small
otherwise you will loose the overview of your design and you will
clutter the code with components instantiation. Not to big otherwise you
will loose valuable details of the design (usually the brain is the best
tool to decide where to put the boundary).
At this point test your components individually with a dedicated test
bench (try "C-c C-p C-t" on emacs and then let's review your 10% speed
increase) in order to trust your basic elements of your design. Only
then you can more reliably move to the next step of connecting the
components together, to build a bigger piece.

Usually this approach force the designer to think about the interface
between the components and maybe try to make it standard (like a bus).
So the outcome of this process is not only more reliable, but enable the
designer to build a mental toolbox of "good practices" rather than
"dirty tricks".


The faulty board, unclear specifications, project management, etc. issue
are certainly part of the process.
This is why your work flow should be such that the PCB is going through
a verified building process, your PCA is visually inspected and your
components are previously screened for "infant mortality" before you can
even think about testing anything.

About the unclear specification that is certainly something you need to
work out earlier with your customer, otherwise you'll be off doing
something different from what he/she had in mind. And this has nothing
to do with the hardware at all. Same conclusion applies to the project
management problems which are not a good reason to justify your faulty
design (even though they maybe blamed for an incomplete one).

My background comes from antifuse-logic, where one chip programmed is
certainly one chip thrown away if you don't verify your code. Code
review and also "rubber duck debugging" are most of the times very good
practices that helps you out in getting rid of clumsy and unmaintainable
implementations.
I understand that it's tempting sometime to "load it and see if it
works", but if you face all the problems at once you may get in real
trouble with your schedule. IMHO this temptation is mostly due to the
volatility of the work, which comes from the nature of the hardware
used. The so called firmware we load in fpgas is similar to software
from an "easy to change" standpoint and this affect deeply the mindset
we have in the design and implementation phase.
Should you pay from your own pocket every time you release a version
that needs to be one time programmed on a chip at a cost of several K$ I
bet my salary you would definitely go back and thoroughly review your
process to make sure you don't miss anything anywhere and if you do I
bet the second salary you will try to understand what you did wrong the
first time.


Code refactoring is not the only motivation for a good editor. Browsing
capabilities in the components structure is extremely important since it
allows you to navigate your source in a faster and more efficient way,
leaving you the time to think about the problem, as opposed to the
simulation where you need to go for a coffee or maybe two, since you are
"waiting" for the result.
Spending more time with your editor will also allow you to write better
maintainable code, since if you do have some sense of aesthetic you will
find that a poorly written code is poorly maintainable also.


In response to the OP I have to say that having an editor instead of a
tool is way much better, since editing is something that is part of our
daily work and every time we use the editor we learn better how to use
it, regardless of the mode.

Tue Jul 05, 2011 10:54 pm   

Sorry for raising a doubt about Emacs, won't happen again...