Favourite Linux IDE?
Page: «8/9»
  Go to:
tuubi May 11, 2019
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.
ageres May 11, 2019
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.)
Cedron May 11, 2019
"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
monnef Jul 11, 2019
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.
Pangaea Jul 12, 2019
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.)
PrivacyParanoid Jul 12, 2019
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.
tuubi Jul 12, 2019
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?
monnef Jul 12, 2019
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).
tuubi Jul 12, 2019
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.
monnef Jul 12, 2019
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. 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.)
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.