C Good IDE for C/C++ programming that doesn't look like the 1990's??

Jose said:
I use Eclipse for Java. It has decent support in Freebsd, and whereas it's bloaty, it's positively lightweight compared to Jetbrains' products.
Click to expand...
Oh right. Admittedly my most recent attempt a couple of years back was the Eclipse-CDT (basically a bunch of plugins for C development) and I couldn't get anything to work. Not sure if user error or a fairly unsupported toolchain. The complexity scared me off pretty quick. The extended time it took to load on my aging X61 also meant I had forgotten what I was meant to be working on anyway.

Jose said:
It also builds in about half the time as any Rust or Node-based project.
Click to expand...
I didn't know there were Rust written IDEs. I thought the community was too busy merely talking about it harhar! </troll>
 
kpedersen said:
Oh right. Admittedly my most recent attempt a couple of years back was the Eclipse-CDT (basically a bunch of plugins for C development) and I couldn't get anything to work. Not sure if user error or a fairly unsupported toolchain. The complexity scared me off pretty quick. The extended time it took to load on my aging X61 also meant I had forgotten what I was meant to be working on anyway.
Click to expand...
I went back and forth with the CDT several times. It works sometimes. I'm using Vscode for C/C++ nowadays, but am trying to get used to Geany.
kpedersen said:
I didn't know there were Rust written IDEs. I though the community was too busy merely talking about it harhar! </troll>
Click to expand...
I figure it's only a matter of time, and since it takes 2-3 hours to compile what should be a simple email client, I shudder to think how much time and resources compiling a Rust IDE is going to take.

Edit: I'm going to give QT Creator a try for C/C++ based on what I've read in this thread.
 
"language aware syntax autocompletion" is a feature I find useful when writing new code.
Like C++ creating header files, when I type "class" having the editor fill out the rest of a class template is nice because it saves me typing. I don't need it, but it's convenient.
emacs init files to give everyone on a project consistent coding style makes it a bit easier looking at code from everyone. Also makes it easier if the company is trying to enforce a coding standard.
Yes I know every other editor can be tweaked to do the same thing, but how easily?

Syntax highlighting. If you like it you don't need an IDE for it, heck this was talked about in the neovim thread.
 
drhowarddrfine said:
If you ever had eye surgery, there's a 50/50 chance your surgeon used my machine. Is that critical enough for you?
I've been doing this for about 40 years. I kinda know what I'm doing.
Click to expand...

Advanced high precision or medical device/machines are somewhat mission critical level.

I'll request my ophthalmologist to please not use any ophthalmic or ocular medical machines programmed by you ;).

Programming mission critical projects without all the bells and whistles provided from modern IDEs, including high resolution with high color bit depth fonts is like a color blind heart surgeon doing open heart surgery. Best believe that color blinded heart surgeon is talented in doing his line of work but I'm sure patients would feel safer in choosing a heart surgeon who has proper color vision to do open heart surgery.

One of the main reasons I do not like 1990's IDEs is because they have terrible pixelated fonts and minimal color depth range to which only have like 7 shades of color thanks to using ANSI color. With this situation, I would rather use monochrome color for programming than using ANSI color syntax highlighting. I think this is why old schoolers today to do not like colorized syntax highlighting.
 
mer said:
Syntax highlighting. If you like it you don't need an IDE for it, heck this was talked about in the neovim thread.
Click to expand...

I do not like IDEs "out of the box", since it has stuff I will most likely never use.

I like VS Code, it is a text editor and I can fine tune it to my likings and turn it into an IDE which has advanced Syntax highlighting.

VS Code is not an IDE for those who don't know.
 
First_Law_of_Unix said:
Programming mission critical projects without all the bells and whistles provided from modern IDEs, including high resolution with high color bit depth fonts is like a color blind heart surgeon doing open heart surgery. Best believe that color blinded heart surgeon is talented in doing his line of work but I'm sure patients would feel safer in choosing a heart surgeon who has proper color vision to do open heart surgery.
Click to expand...
Disagree and say that this is your opinion only.


First_Law_of_Unix said:
One of the main reasons I do not like 1990's IDEs is because they have terrible pixelated fonts and minimal color depth range to which only have like 7 shades of color thanks to using ANSI color. With this situation, I would rather use monochrome color for programming than using ANSI color syntax highlighting. I think this is why old schoolers today to do not like colorized syntax highlighting.
Click to expand...
Fonts can be changed/adjusted. Rebuilds of 1990s IDEs likely take advantage of modern fonts, you may have to actually set a font instead of accepting the default.

The bolded part is pure supposition on your part. As an "old schooler" I don't give a crap about colorized syntax highlighting. Why? Because it gives me nothing towards understanding the code. If I can't recognize an "if", "switch", "case", "else if" statement without colorization, honestly, I have no business trying to code in that language.
Yes that is my opinion, but I'm getting tired of generalizations that are roughly "well you old dogs are too stupid to understand how wonderful colorized syntax highlighting is". Again, my opinion, you are flat out wrong, I'd posit millions of lines of mission critical code, code where people could die (in a real physical sense), were done without use of IDEs and "colorized language sensitive syntax highlighting".

If it helps YOU write better code, fantastic, you do you, great. But stop peeing on people that find it of marginal use at best.
 
Or take a look at neovim and neovim-qt. The interface looks like 90's but under the hood you can do lots of customization with plugins.
 
  • Like
Reactions: mer
mer said:
If it helps YOU write better code, fantastic, you do you, great. But stop peeing on people that find it of marginal use at best.
Click to expand...
Agreed. If they plan on having any chance at getting hired by the "old dogs", I would suggest they hold in their pee (at least during the interview).
 
  • Like
Reactions: mer
mer said:
The bolded part is pure supposition on your part. As an "old schooler" I don't give a crap about colorized syntax highlighting. Why? Because it gives me nothing towards understanding the code. If I can't recognize an "if", "switch", "case", "else if" statement without colorization, honestly, I have no business trying to code in that language.
Yes that is my opinion, but I'm getting tired of generalizations that are roughly "well you old dogs are too stupid to understand how wonderful colorized syntax highlighting is". Again, my opinion, you are flat out wrong, I'd posit millions of lines of mission critical code, code where people could die (in a real physical sense), were done without use of IDEs and "colorized language sensitive syntax highlighting".

If it helps YOU write better code, fantastic, you do you, great. But stop peeing on people that find it of marginal use at best.
Click to expand...
I actually like to do things old school way, have no issues with old dogs with their "old" philosophy. In the engineering world of electrical and computer science/engineering, having knowledge of doing things old school is extremely powerful. It is the main reason why I am using FreeBSD, not because it's "FreeBSD" but because it's UNIX. But when it comes to colorized syntax highlighting, I'll bet that a software engineering team will create more bugs for not using it than those who does.

Here is a website detailing 11 of the most costly software errors in history, I bet majority of the programmers never had the luxury to use advanced colorized syntax highlighting:
raygun.com

11 of the most costly software errors in history | Raygun Blog

Software errors can cause chaos, with costs that bring down businesses or even governments. Not even NASA is immune from code errors - here are the most costly bugs, crashes and outages of all time.
raygun.com raygun.com

It's matter of science how humans process information, theres a reason why humans are able to see color it helps us to be more productive in terms of being biological humans in the physical world, it wouldn't make any sense how this concept does not apply to programming. I have nothing against with programmers who doesn't use syntax highlighting but I strongly believe it should be used and practiced in mission critical applications.

I hope scientist can someday prove/disprove using professional programmers about syntax highlighting in productiveness and coding safely. I am just discussing and having a conversation scientifically and not being a police to say what is right or wrong.
 
kpedersen said:
Agreed. If they plan on having any chance at getting hired by the "old dogs", I would suggest they hold in their pee (at least during the interview).
Click to expand...

Best believe I'll happily quit my job ASAP and start my own business if boss says to turn off the syntax highlighting. Yea, I don't want to be responsible for the great "big" catastrophe of the simple syntaxes errors.
 
Just imagine what it would be like to work at Google and be stuck using last century tools. The Google monorepo is over 2Tb of code. I reckon that you'd be lucky to do one grep per day on that (and one grep per month if you needed to search the entire code+history). Not surprisingly for a search engine company they have their own custom code browsing engine. And it seems to do syntax colouring e.g., https://cs.android.com/android/plat...libcore/json/src/main/java/org/json/JSON.java

AFAIK Google engineers are free to use the editor/IDE of their choice.

My experience is that when I'm working with multimillion LOC codebases that I'm not familiar with IDEs are a huge benefit (when the code model works correctly, which is unfortunately often quite difficult).
 
I did a quick scan of academic literature (mainly because I was already logged into the journals from a previous thread).

I am actually surprised by the results. I personally would have thought syntax highlighting would at least help novices when learning to code (i.e what part is a variable name, what part is a type, what part is a keyword) but oddly there didn't seem to be much evidence of that in their findings.

https://link.springer.com/article/10.1007/s10664-017-9579-0 (in IDEs)
https://bop.unibe.ch/JEMR/article/view/2429 (in code textbooks)

But for experienced developers, all this seems to be personal preference, from people I work with it really does tend to be 50:50. Along with font size; some guys use tiny fonts to fit as much as possible on the screen, some use larger fonts to they don't miss anything.
 
kpedersen makes sense to me. I'm one of those guys who don't use "IDEs" a lot, but really want syntax highlighting. But after all, this is just another visual aid to quickly grasp the structure of code ... somewhat similar to indentation. Probably, every human being would be slowed down a lot without indentation, while colors are a personal preference, but in the end, none of those concepts can help you unless you understand the language used ;)
 
There is a documentary on Netflix, I think, about some science on black holes. The video showed the scientists as they discuss what they think they have discovered. As a fun side note, even Stephen Hawking rolled in and gave some thoughts.

The interesting thing is, all the scientific work was drawn on on huge blackboards with chalk. A lot of it in notebooks with pen and pencil. They made huge discoveries with no computers involved at all.

Along those same lines, watch the many videos from universities online where they still tutor students using the same style of large blackboards and chalk. None of it in colored chalk I might add.
 
drhowarddrfine said:
Along those same lines, watch the many videos from universities online where they still tutor students using the same style of large blackboards and chalk. None of it in colored chalk I might add.
Click to expand...
That's a good point of view, I see that this is rather a burden for humans since in this time era, our brains can actually unlock more tasks and capabilities in writing and reading information more effectively when using many forms of added syntaxes not only just based on color. If theoretical scientists have the capabilities in writing their thoughts fast and effectively using color syntax, best believe they would. It would only make sense if the readers are also able to understand and parse the information.

It would help them from wasting time and effort in preventing solving math equations that have simple errors/bugs. Sounds like this could be a new venture to create products or strategies to help professionals to write their scientific work quickly, effectively and using much less characters, this would overall simplify their written work. Imagine writing material that takes up 2 pages when using more advanced human language can reduce it down to 1 page.
 
I'm currently trying to analyze a huge diff (affecting >1000 port Makefiles) created by some script, taking individual samples to check whether it does the correct thing. This is what I have in my terminal right now:
Code: 
 SPEEX_LIB_DEPENDS=     libspeex.so:audio/speex
 SPEEX_CMAKE_BOOL=      ENABLE_SPEEX_CODEC

root in default at testbuilder on  uses 
➜ git diff main -- x11/sddm/Makefile         
diff --git a/x11/sddm/Makefile b/x11/sddm/Makefile
index 7493f9aafa79..4f5b3f8005ee 100644
--- a/x11/sddm/Makefile
+++ b/x11/sddm/Makefile
@@ -27,9 +27,9 @@ RUN_DEPENDS=  dbus-run-session:devel/dbus \
 USES=          cmake compiler:c++11-lang cpe kde:5 pkgconfig python:build qt:5 xorg
 CPE_VENDOR=    ${PORTNAME}_project
 USE_GITHUB=    yes
-USE_KDE=       ecm_build
+USE_KDE=       ecm:build
 USE_QT=                core declarative dbus gui network \
-               buildtools_build linguisttools_build qmake_build testlib_build
+               buildtools:build linguisttools:build qmake:build testlib:build
 USE_XORG=      xcb
 
 CONFLICTS_INSTALL=     lightdm

root in default at testbuilder on  uses 
➜ git diff main -- x11/yakuake/Makefile
diff --git a/x11/yakuake/Makefile b/x11/yakuake/Makefile
index 2b581b8e9c68..418be4b9348f 100644
--- a/x11/yakuake/Makefile
+++ b/x11/yakuake/Makefile
@@ -15,9 +15,9 @@ USE_KDE=      attica auth archive codecs completion config configwidgets \
                jobwidgets kio newstuff notifications notifyconfig parts \
                service solid sonnet textwidgets wayland widgetsaddons windowsystem \
                xmlgui \
-               ecm_build
+               ecm:build
 USE_QT=                concurrent core dbus gui network widgets x11extras xml \
-               buildtools_build qmake_build
+               buildtools:build qmake:build
 USE_XORG=      x11
 
 OPTIONS_DEFINE=        DOCS

root in default at testbuilder on  uses 
➜

Now, compare it with what I actually see thanks to the diff colorization provided by git-diff(1):
1662463665865.png


Ok, if you tell me that you can realize the actual differences from the pure text at least just as fast, I will believe you, but I'm pretty sure most people will be a lot quicker presented with the colorized output.
 
zirias@ said:
Ok, if you tell me that you can realize the actual differences from the pure text at least just as fast, I will believe you, but I'm pretty sure most people will be a lot quicker presented with the colorized output.
Click to expand...
I tend to have a much larger terminal font, so the + and - in the first column stands out *much* more than in that screenshot.

The diff lines in red and green I can see as being useful but that root in default in testbuilder [...] being colorized is just a load of distracting noise in my mind. Arguably however some users will want that kept colorized but not the diff'ed lines potentially so without customizing the diff tool yourself, it will never be perfect for everyone. I rather bite the bullet and avoid all of that.
 
kpedersen said:
that root in default in testbuilder [...] being colorized is just a load of distracting noise in my mind.
Click to expand...
I really like prompts to stick out clearly. If they don't, it takes longer for my mind to realize where one command output ended and the next one started. So, very much depends on what you consider "noise".
 
zirias@ said:
So, very much depends on what you consider "noise".
Click to expand...
Once again, proving that everything visual has a personal preference component.
As for actual differences, the colorization does not make it any easier for *ME* to see the actual differences. But that is likely due to years of looking at diff output in monochrome.

If the colorization were limited to the actual differences instead of just highlighting the different lines, there would be more of an argument (like if the underscores and the colons were the only thing highlighted, then I can see the argument).

But again, my opinion, based on my preferences and not meant to discourage or disparage anyones preferences
 
mer, the thing is, without the colors, you always have to "scan" to the beginning of the line in order to know whether it is unchanged/new/deleted... this takes time, if only microseconds :cool:

But I agree, (additionally?) highlighting the changed characters would be awesome (and some GUI diff viewers do exactly that btw). Feature request for git? 🥳
 
mer said:
there would be more of an argument (like if the underscores and the colons were the only thing highlighted, then I can see the argument).
Click to expand...
Color is used an out of band way of adding more information to a standard 2D output. Same with bold / underlines characters when on an "extended" terminal.

Really we just need 3D computer terminals and we would be able to keep to the monochrome goodness. ;)
 
You must log in or register to reply here.
Back
Top