Been using Atom since my last post here ( 2 years ago already? :o ) until recently that is - the editor has just become so slow and unresponsive even on small files. It's properly my fault for loading why too many nifty addons, but that was kind of the selling point of the editor.

I've switched to Visual studio code with the atom dark theme, so far my only complaint (other than having to relearn keyboard short cuts) has been that there does not seem to be any way to get a method/function outline?

Figured I'd also update this thread. I switched to Vim somewhat recently and then proceeded to check out Neovim. Not much of a difference between the two to my untrained eye, but I stuck to Neovim since that's what cool kids seem to be using these days. I've got it configured with Syntastic and YouCompleteMe for basic IDE functionality and I'm quite happy with it, definitely happier than I was with Geany, although Geany is still installed on my systems just in case.

Emacs, VSCode. Java development!

Vim; most programming I do these days are small scripts. Vim with syntax highlighting is perfect for this, and installed on basically all Linux machines and VMs.

I generally use nano or Kate, these days. I have VSCodium installed though, for when I collaborate with VSCode users (which is rather often).

Also a VSCodium user, mainly for C++ and Python, although I fall back to nano if need to hack together a quick bash script.

When I first started developing on Linux, I started with the IDE I'd used in high school. Code::Blocks worked, but was an inferior experience to VisualStudio I had to use at university. So I looked for alternatives. In QtCreator, I triggered a bug in the installation process, commented on a report someone posted about the bug before me, and never tried it again. Does it allow a CMake only workflow now? Last time I checked, it used qmake which I didn't want to bother with. After that, I settled on Atom for ~a year, which worked fine but I couldn't get breakpoints to work. We had VSCode preinstalled on work computers and I found it easier to debug python in, so I switched to that, after finding a telemetry free version.

visual studio code is very cool

Generally, on Linux, my "IDE" has been a text editor and a command line. I try to format my code clearly enough so that syntax highlighting is unnecessary. I realize that many people programming are younger and have known nothing but color coded editting. That's progress, I guess.

Earlier this year I found the Gambas. Gambas is a VB like, but vastly improved, IDE for developing desktop applications (or command line) in Linux. Since VB6 has always been my favorite programming environment, finding Gambas was way overdue, and a very pleasant surprise. I don't know why I hadn't found it before, it has been around for quite some while and is fairly mature.

It is not really a game development platform, though I am using it as such, in a sense. (If anybody wants a shared library for gamepad input, let me know, I wrote one.)

If you are interested, I suggest you start with the sample programs I posted on a Gambas forum:

"Programming is supposed to be fun" at https://forum.gambas.one/viewtopic.php?f=4&t=674

Ever seen a scrollbar act like a cannon with recoil? You'll find it in the second example.

PPA: gambas-team/gambas3

The latest version is 13.0

A very helpful website is: http://gambaswiki.org/wiki

It is absolutely the best IDE for learning how to program I know of. The nice thing is you will never "outgrow" it. It is a byte code interpreter though (but so is Java and Python, excepting JIT which Gambas has too). It is really easy to call C .so libraries, so anything computationally heavy can also be tackled.

It is Linux specific, but it is supposed to work on Raspberry Pi.

Ced

Quoting: CedronGenerally, on Linux, my "IDE" has been a text editor and a command line. I try to format my code clearly enough so that syntax highlighting is unnecessary. I realize that many people programming are younger and have known nothing but color coded editting.

Modern text editor features like syntax highlighting make even the nicest code quicker to skim and parse. And a proper IDE can help you work faster and avoid mistakes, no matter how old you are. Their features are even more helpful if you often work on code someone else wrote, like many of us do at work. And the helpfulness is proportionate to the size of the code base.

Quoting: CedronThat's progress, I guess.

Indeed it is.

What's wrong with highlighting? It helps reading and navigating. It has been used since the first colour displays. You must be a dinosaur if your first computer was monochrome. I was introduced to the amazing world of programming by Turbo Pascal in Windows 98 which looked like this:


(Actually, when I was in elementary school, there were Yamaha MSX-based computers with one-colour displays, high school students used them for studying BASIC, but I never had a chance to use them.)

"Monitor? You have a monitor?" he asks incredulously as he plays 52 card pick up with his punch cards.

Don't get me wrong. I like syntax highlighting a lot. The point I am making is that it is sort of a crutch for improving code readability (and it does improve readability tremendously). Thus, if that is all you are used to, then formatting your code to be readable when displayed in monochrome is not a consideration that is in the forefront in your mind, if even at all.

On the other hand, if your code is very readable in monochrome, it is even more readable in technocolor.

I.e., IDEs can make you lazy and sloppy.

I like code completion as well. It saves a lot of copying and pasting (no, you shouldn't retype variable names, this practice only encourages cryptic naming conventions, though cryptic names are okay for local variables).

How about procedure separators? Most IDEs provide them. I turn them off. Instead, I put a comment line in like thus:

//=================================================================

That way it is part of the source file and is there no matter which context it is viewed in. As in the first example in the forum post I linked above.

Ced

I am a big fan of IDEs from JetBrains (but not blind, I did try Atom, Sublime, VSCode, Eclipse, Visual Studio and a few more obscure ones).

At work I am using IntelliJ IDEA for JavaScript, TypeScript, CSS, Sass, SCSS, HTML.

When working on games I tried CLion (Godot) and now I will be probably using Rider (Unity). Currently I am working on a small platformer game in Godot, using GDScript so the IDE is Godot's editor and I miss a lot of functionality from IDEA (that's one reason I am planning on going to Unity and C#, because in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).

For other projects I use IntelliJ IDEA usually for Haskell, now trying ReasonML for front-end needs for which Haskell, or rather its tooling, is very far from ideal.

It would take me a long time and my productivity would take a giant hit, if I would have to use feature-less editor instead of a proper IDE. For example type-aware autocompletion is priceless.

Quoting: BlackBloodRumPersonally, I now prefer "Geany" simply because it is fast and lightweight and "just works" I used to love Eclipse but release after release it just felt heavier, slower and slower in the end I ditched it and went Geany. Honestly best decision I ever made!

Low-pro here. Started fiddling about with XML, CSS and wikitext again, and re-discovered Geany in the Software manager. It's an excellent little piece of software -- even if it isn't a proper IDE (?). Does all I need, and better than online highlighting, and of course the Text Editor.

Light-weight, and "it just works".

(Back in the Windows days, Notepad++ was the go-to.)

I love JetBrain products. They're so refined and customizable that i cannot use anything else anymore. I don't mind the proprietary approach used for the Ultimate version and the *Storm/*Charm versions since i care about open computing mostly when it comes to the platform (OS) and not the final applications.

Quoting: monnefbecause in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).

I'll take your word for GDNative, but didn't Godot get C# support in 3.0?

Quoting: tuubi

Quoting: monnefbecause in Godot you can either use GDScript [not supported in IDEA and the language itself has many downsides] or C++, so GDNative which is an undocumented, poorly supported and buggy mess).

I'll take your word for GDNative, but didn't Godot get C# support in 3.0?

Yes, docs for C# are better - well, at least some exist and API is more closer to GDScript, so separate docs for everything are not needed. For GDNative (C++) it, all documentation, was literally one page on wiki which described basic setup with example which didn't work (didn't even compile). There are many differences between C++ and GDScript API, e.g. different types, custom memory management which isn't documented (Godot team is ignoring current C++ features which implement mostly same thing), code within C++ API (bindings) is undocumented too. It was a nightmare to use - if you are not familiar with Godot internals, do yourself a favor and avoid GDNative (with C++) at all costs.

When I was briefly testing C# with Godot, there were some significant downsides - for example missing stack traces after crash, broken project file for C# which had to be manually fixed, more boilerplate compared to GDScript, issues with custom C# types (IIRC struct isn't supported at all = performance problem or use a lot less readable solution), undocumented differences in API compared to GDScript (worst were conversion rules between C# types and GDScript ones, it is not a smooth experience). Performance-wise C# isn't bad (much better than GDScript), but marshalling (converting data between C# and GDScript) is very costly and one has to be careful about memory management (GC). I don't like very much how a lot of things in Godot API is "stringy", it really undermines static typing of C# (and C++).

Simply put, Godot supports GDScript well, nothing else, even though they claim C# and GDNative (C++) are officially supported. One of reasons why I am going back to Unity is because I want to write in a language which is properly supported by the engine, its team and community (by supported I don't only mean technical side, but also docs, guides, tutorials, community, marketplace). Unity is just so much more mature.

For my use-case was quite important debug view which Godot misses (viewing real 2D/3D instances in editor when game is running). Another thing I don't really like is that a node can only hold one script (forcing deep branches in a node tree), cumbersome addressing of these inner nodes, difficult refactoring, missing inheritance or any equivalent mechanism. With Godot I picked C++ because of performance, but it might be possible to reach similar performance in Unity with C# using their custom compiler (so I could write in a reasonably nice language - C#, C++ is for me too low level, unnecessarily complex and wordy). Maybe in a few years I'll try Godot again (after 3D supports basic features like occlusion culling and unlimited number of lights).

Quoting: monnefUnity is just so much more mature.

Well that's a given. :) Godot has some catching up to do. And I do wish it does. I really like the idea of free and open source game engines, even if they're used to produce proprietary games.

Thanks for the insight.

Quoting: tuubi

Quoting: monnefUnity is just so much more mature.

Well that's a given. :) Godot has some catching up to do. And I do wish it does.

I am looking forward to the Vulcan rewrite (v. 4), real static types in GDScript (e.g. currently there are no types for custom classes or even interfaces for dictionaries) and at least some FP support (currently there are no anonymous functions, no closures and passing a function is a pain).

To not be entirely off-topic, I should say that GDScript editor (the IDE) quite surprised me, because it makes using (at least writing) those "stringy" APIs a lot easier. For example when you are writing a node path (addressing a node in a node tree) it will suggest you all different currently available paths in proper context (current node).

My last rant: I still don't understand why Godot team refuses to implemented int variant of vector2 and 3 (can be used for example for coordiantes in a desk game or a voxel world). Their recommended "solutions" were either difficult to use, or very slow, or both. This is a major issue, because GDScript doesn't allow defining custom "structs", so a GDScript user cannot implement performant primitive type (that's only possible if you modify engine itself, in C++, and then you will have to maintain your fork if you want to get fixes and new features from main repo).

Quoting: tuubiI really like the idea of free and open source game engines, even if they're used to produce proprietary games.

Thanks for the insight.

Godot being FOSS and having really good Linux support were the top reasons I decided to try it. It definitely has a potential and I believe in a few years it will start competing with "big dogs" in small/middle sized 3D games. :D

PS: I am sorry for the offtopic. :whistle: If any mod is reading this and if you have some free time, it might be worth clean this up a bit, e.g. duplicating my first post to a new thread and move there all subsequent posts from here. (Not sure how this forum works, I am new here, so maybe I am entirely off.)

Can't go wrong with Emacs. It's a rock solid editor; cross platform (all I need to instantiate my current config on a windows/Mac machine is to copy the init.el); completely reproducible results, and more importantly it plugs into everything you may want, including eclipse.

The only thing it's missing is a kitchen sink.

Tough pick between neovim and doom emacs.