What IDE are you using ?

[SiliconWizard]

What do you use guys, for Java programming?

Holy water and exorcisms.

 

[SiliconWizard]

The first rule of picking an IDE is: you don't use an IDE.
The second rule is... you don't talk about using an IDE.
 

[rsjsouza]

This is a feature that you rarely find implemented, but for me, it's very important.
IDEs like Avocet have it, but it's not for cheap. Keil's should have something.

Wow... That is a name I haven't heard in 20 years. I couldn't find them on my Google searches - are you sure they still exist?

[JVR]

Silicon is cheap, my time is not. So I have multiple Eclipse installs in version control for Java, Python and C/C++.

Next step is to get them running in a Vagrant + Ansible environment, so I don't have to care about backing up entire folders. The recipe stays the same.

[Bassman59]

Scriptum and HDL companion are good tools for writing HDL.
Plus Sigasi.

I remember when Sigasi first appeared. It's an Eclipse-based editor with a lot of cool features. And the guys pushing it were all "this will get you to stop using emacs for your VHDL!"

Except that it was ridiculously expensive -- I think something like $80/month. For an Eclipse-based editor! If you go to their website and look under Pricing, what do you see. Well, you don't see prices. You see a contact form. And that's always a sign that "you can't afford it." And for the money they charge, it should be more than an editor/code viewer/organizer -- it should also be a simulator.

So for me, emacs and its vhdl-mode remain the standard. Type pr-tab and bam, a process skeleton. Put the mouse in the entity's port list, choose "VHDL - Port - Copy" and then elsewhere choose "VHDL - Port - Paste As Instance" and voila, a new instance of your entity. And tab-completion works.

Nothing else really comes close.

[richardman]

Cosmic is no more in business, but you can still buy licenses (for hc11 and 683xx)

https://www.cosmic-software.com/ ? They don't exist anymore?

[richardman]

I eat my own dogfood and use our IDE, which is derived from CodeBlocks. The AVR compiler is ours and the new Cortex compiler is GCC, but the IDE works very much the same with the same visual debugger.

[DimitriP]

I'm probably a broken record on this at this point, but consider life with a powerful text editor and no IDE.

Vim has syntax highlighting and full programmability.
There are add-ons for syntax checking (syntastic), code completion (youcompleteme), git integration (fugitive) and much more.

Throw in the make utility of your choice, and you've got an "IDE" that you never have to abandon, ever.

Stumbled on this while on a different quest altogether  https://medium.com/commitlog/why-i-still-use-vim-67afd76b4db6 

[newbrain]

Stumbled on this while on a different quest altogether  https://medium.com/commitlog/why-i-still-use-vim-67afd76b4db6

That data is seriously out of whack, at least for VS Code.
On my work laptop (middle of the range Elitebook, Windows10) all that stuff is almost immediate (i.e. my fingers are slower than the editor), same with Emacs.
Loading is in the 1s range.

The memory occupation is correct, though: I suspect some swapping was going on for the large editors.

I'll try at home with the slowest machine I have (NUC i3-3217u), maybe I'll yank out some of the RAM to bring it to 4GB.

[brucehoult]

Stumbled on this while on a different quest altogether  https://medium.com/commitlog/why-i-still-use-vim-67afd76b4db6

That data is seriously out of whack, at least for VS Code.
On my work laptop (middle of the range Elitebook, Windows10) all that stuff is almost immediate (i.e. my fingers are slower than the editor), same with Emacs.
Loading is in the 1s range.

The memory occupation is correct, though: I suspect some swapping was going on for the large editors.

I'll try at home with the slowest machine I have (NUC i3-3217u), maybe I'll yank out some of the RAM to bring it to 4GB.

I don't know where he got 5 MB from for vim. On my NUC i7-8650U with Ubuntu 18.04 vim shows 9252 KB RSS and 3300 KB anon (i.e. non-shared), so I don't know which (if either) he's talking about.
In comparison emacs -nw gives 33128 KB and 13888.

So emacs is bigger than vim, but you can't say it's ridiculous.

Interestingly, sshing into a dual U74 64 bit RISC-V machine running at 100 MHz on an FPGA (and which actually has 4 GB RAM) I get for vi 2604 KB RSS and 392 KB anon.

That one is also vim, not vi:

VIM - Vi IMproved 8.1 (2018 May 17, compiled Jun 20 2018 02:44:05)
Included patches: 1-89
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by pkg-vim-maintainers@lists.alioth.debian.org
Small version without GUI.  Features included (+) or not (-):

[richardman]

cosmic-software.com
 They don't exist anymore?

I meant, for m68k! My license for Avocet is for m68k.
Cosmic is no more in business for m68k, but you can still purchase an old license.
(1600 euro full package, including the BDM debugger)

Well, Cosmic did not own the 68K compiler  as it was from Whitesmiths. I actually wrote most/all of the 68K code generator. My ghod, it has been so long and I have written so many compilers since then that I don't remember  Maybe it was just the 68020 improvements. It was my second major task at Whitesmiths after fixing bugs with the P2C Pascal to C compiler. Then I wrote a machine independent optimizer based on Barry Rosen's structured dataflow analysis...

[djacobow]

I don't know where he got 5 MB from for vim. On my NUC i7-8650U with Ubuntu 18.04 vim shows 9252 KB RSS and 3300 KB anon (i.e. non-shared), so I don't know which (if either) he's talking about.
In comparison emacs -nw gives 33128 KB and 13888.

So emacs is bigger than vim, but you can't say it's ridiculous.

Interestingly, sshing into a dual U74 64 bit RISC-V machine running at 100 MHz on an FPGA (and which actually has 4 GB RAM) I get for vi 2604 KB RSS and 392 KB anon.

That one is also vim, not vi:

VIM - Vi IMproved 8.1 (2018 May 17, compiled Jun 20 2018 02:44:05)
Included patches: 1-89
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by pkg-vim-maintainers@lists.alioth.debian.org
Small version without GUI.  Features included (+) or not (-):

I can't speak for the exact resource requirements, but I think we can all agree that Vim compares favorably with IDEs. But a fair comparison would be between a "big" vim (like one compiled with gui and syntax highlighting) and an IDE. Many Linuxes seem to ship with a "small" tty-only Vim that was compiled with a minimal list of features, so that makes a size comparison somewhat biased in Vim's favor.

Still, even the biggest Vim binary is smaller than the smallest modern IDE.

[colorado.rob]

I use Eclipse for most stuff, including embedded C/C++ (AVR, ARM, etc), Python, and Java; Android Studio (IntelliJ) for Android work; and Xcode for iOS.  My primary development environment is Linux, with OSX as secondary, and Windows tertiary for all the proprietary development tools that aren't written with portability in mind (thanks Microchip!!).

This is all I have for those doing significant development in vi and Emacs: 

I use vi to bang out a quick shell script, or Geany if I need to whack out  a quick Python script.  But anything going it to source control is a project and is mananged in an IDE.  A single mouse click has my update compiled and running on the device in a graphical debugger with ITM output.

Ain't nobody got time to mess around with vi when your project has scores of source files, an equal number of test suites, markdown documentation, and needs to be debugged on an embedded platform.

[djacobow]

Ain't nobody got time to mess around with vi when your project has scores of source files, an equal number of test suites, markdown documentation, and needs to be debugged on an embedded platform.

I deal with large, complex projects with vim all the time, and can build and deploy from within the tool. And in fact, I can do it with zero mouse clicks.

Well, everything except the debugging. For that I'll use gdb, which to a first approximation doesn't care if your are debugging on the host or an embedded target. however, I do not find interactive debugger-based debugging particularly useful on embedded platforms, where in addition to being embedded they are interrupt drive, and asynchronous, and stopping to inspect code at a breakpoint isn't very helpful. If I have an RTOS running, sometimes I can get the debugger to stop some high level code while some important low-level interrupts keep working, but that is often more trouble to set up than it's worth. Printing to a serial console is often easier, or even flashing leds if printing itself is problematic.

Perhaps you meant to say "I don't have time to learn how to use vim" -- which is a reasonable. But I just told you I do it that way, and I haven't much spare time, either, and last I checked, I ain't nobody.

[brucehoult]

Well, everything except the debugging. For that I'll use gdb, which to a first approximation doesn't care if your are debugging on the host or an embedded target. however, I do not find interactive debugger-based debugging particularly useful on embedded platforms, where in addition to being embedded they are interrupt drive, and asynchronous, and stopping to inspect code at a breakpoint isn't very helpful. If I have an RTOS running, sometimes I can get the debugger to stop some high level code while some important low-level interrupts keep working, but that is often more trouble to set up than it's worth. Printing to a serial console is often easier, or even flashing leds if printing itself is problematic.

Agreed.

Console can often be a bit slow and interfere with timing. Just sending the actual binary values to be printed, along with some kind of ID of a printf string, and doing the formatting on the host, cuts the overhead a *lot*. Or, lz4 (or zlib) is less work if you've got limited bandwidth but plenty of CPU and a bit of code and buffer space to spare.

[NorthGuy]

The serial port is relatively slow, and printfs is very slow. If you don't want to stop the code flow on bp/wp to inspect variables and you prefer to continuously monitor values, you'd better have a very fast channel, e.g. a USB2 bulk channel able to export things at 40Mbyte/sec on a very small protocol, and to a very fast machine able to log and triggers just what you want to observe.

I don't typically use debugger for embedded things. I rather manipulate a set of pins with my program then capture this and analyze the results on PC in the off time. I may also transmit some binary data through UART or SPI. It only takes one write to the peripheral register to write a byte.

[colorado.rob]

Perhaps you meant to say "I don't have time to learn how to use vim" -- which is a reasonable. But I just told you I do it that way, and I haven't much spare time, either, and last I checked, I ain't nobody.

I have likely forgotten more about vi and vim than most will know.  Seriously -- I've been doing software development for 3+ decades, and cut my teeth on ancient Unix variants few have seen.  I have done large-scale software development using vim.  I have also grown as a developer.  So I can tell you -- as someone who was an ace with vim -- that modern IDEs are more productive.

[richardman]

...
I have likely forgotten more about vi and vim than most will know.  Seriously -- I've been doing software development for 3+ decades, and cut my teeth on ancient Unix variants few have seen.  I have done large-scale software development using vim.  I have also grown as a developer.  So I can tell you -- as someone who was an ace with vim -- that modern IDEs are more productive.

I wasn't going to mention something similar  While I just barely missed TECO, ed/ex and regex were my friends... and IDE is much better. I think that big slow thing like Eclipse (seriously, I couldn't get Atollic to do ANYTHING) gives people a bad impression. IMHO.

[djacobow]

I have likely forgotten more about vi and vim than most will know.  Seriously -- I've been doing software development for 3+ decades, and cut my teeth on ancient Unix variants few have seen.  I have done large-scale software development using vim.  I have also grown as a developer.  So I can tell you -- as someone who was an ace with vim -- that modern IDEs are more productive.

Sometimes the arrogance displayed on this board just blows my mind. I mean, you can't even bring yourself to say "this works better for me" you can't help yourself from making a universal claim that is not just unprovable, but easily falsified by a single programmer who is more productive in his preferred environment than yours. Which I have already done.

Seriously, what would cause you to behave this way? Is this something you learned in three decades of software development? FFS.

[rsjsouza]

I tend to use Eclipse (Code Composer Studio) for most of my work. To me the project management abilities of this IDE are absolutely critical to consider any alternative. The most useful things for me are:
- single keypress (F3) to jump to the definition or declaration of the variable/function/object/class/whatever anywhere in your 100s or 1000s of source files so I can see its implementation;
- code shading/highlighting depending on precompiler directives;
- on a single key combination I can comment, indent, format or wrap code/comments;
- mouse hover to have a glimpse on the variable/function declaration - if the debugger is running, it shows the target address for pointers or variable values;
- Source file or project outline that helps navigate the code;
- Code completion, including struct/object/class elements;
- Search in Files, in project files (using only C syntax elements), etc.
- A history of modifications done to a file during the editing session;
- Built-in file compare tool (even more than two files)

And other less used features (at least for me).

[colorado.rob]

Sometimes the arrogance displayed on this board just blows my mind. I mean, you can't even bring yourself to say "this works better for me" you can't help yourself from making a universal claim that is not just unprovable, but easily falsified by a single programmer who is more productive in his preferred environment than yours. Which I have already done.

I'm sorry to have upset you.  Please accept my apology.

[Sal Ammoniac]

What I use:

ARM: Rowley CrossWorks for ARM -- lightning fast IDE and good debugging support. The editor is a bit primitive, but not too bad.

PIC32: MPLAB X.

C#: Visual Studio -- the IDE that includes everything, even the kitchen sink (well..., considering how popular add-ons like ReSharper are this really isn't true).

Java: Wouldn't touch that abortion of a language with a ten foot pole.

SystemVerilog/VHDL: Vivado, and, for general editing, VS Code with Verilog and VHDL plug-ins.

I generally tend to avoid Eclipse when I can, but when I can't I use the bare bones Eclipse with just CDT and Segger hardware debug support and nothing else.

[MarkF]

Visual Studio 2013 --> Windows C/C++
MPLAB X + XC8 --> PICs
Arduino IDE --> Arduino Uno

NEdit + GNU g++ --> When I use to build Red Hat Linux programs
I also heavily used the NEdit custom syntax color coding

[techman-001]

I'm using my own IDE design, it uses a collection of applications written by others, like many IDE's.

I wrote a "Project Builder' application which pulls in all the needed programs, files, templates, data etc and creates a IDE tailored for each new project in about 1 second.

It's designed for STM32Fxx 32 bit MCU's  tho I tend to only use STM32F051 QFN (64KB Flash, 8KB Ram) MCU's so far as they have far more resources than I'll ever need.

My design environment is near real time and uses cooperative multitasking, in other words I can light a LED driven by a GPIO by a command typed in the IDE, then turn it off the same way. I can see the contents of any MCU register in near real time, any time I want, while a LED is blinking.

The many benefits of interactivity are too many to list, but one of my favorites is examining the effect on the MCU when a bit or bits ares changed in a register to confirm what I *think* should happen when I find the STM documentation ambiguous. Even the "simple" STM32F051 has 37 peripherals, 413 registers and 3044 register bit-fields so you can imagine the humongous number of different combinations.

My system doesn't use a compiler on the PC, so it doesn't need the usual edit, compile, upload, test, repeat methodology of C. Overall my code runs about three times slower than that produced by a optimized C compiler, however it's a price I'm more than happy to pay for the interactivity of the system.

Everything I use is GPL or FreeBSD Copyright

Elements integrated into my IDE are:

• Editor: Gvim
• Serial Terminal: GnuScreen
• Schematic Capture: Geda
• Flowchart: Graphviz
• SCM: Fossil
• OS: Mecrisp-Stellaris

The IDE:
http://hightechdoc.net/misc/ide-tp-1600.jpg

The SCM which is in a separate window being Web Browser based:
http://hightechdoc.net/misc/ide-fossil-1024.jpg

[newbrain]

@techman-001
Very interesting setup, forth is always an handy resource for its balance between interactivity and performance.