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. 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.