Re: [escet-dev] Things that break the code editing flow (was: Openness/t

[Dennis Hendriks <dh_tue@xxxxxxxxxxx>]

Hi Albert,

In general I agree not everything is perfect. I also agree that we can't change the whole Eclipse ecosystem.

I have similar experiences reporting issues to JDT. It feels like you have to make a Gerrit contribution yourself to get the ball rolling. I did that for some of the runtime Java compilation issues, and then those were quickly reviewed and merged. It greatly depends per project though.

What we can do is selectively improve the biggest issues. I've created a few issues in the ESCET GitLab already and adressed one of them. If we make concrete issues and discuss proposals, we may be able to improve things over time.

I guess I'm "in" now myself, due to years of experiences and spending the effort on finding things out when they bug me or don't work. But I agree the learning curve can be steep for some things.

I'm not so bothered by JDT/Checkstyle warnings. I just continue and fix them later. I also never write imports myself. I use the organize imports function to clean them up. It also adds any imports that are missing. If a class exists in multiple packages, it gives a popup to choose the one I want. And yes, there too the order is not always optimal. But is works quite well for me in general and saves a lot of effort. I'm similarly also never bothered by whitespace warnings. I just auto reformat to get rid of them.

One way to get rid of the warnings temporarily is to just change the warning settings for the project, changing all warnings you don't want to 'ignore'. Then save the changed settings file in the .settings folder of that project somewhere. And just change between the standard and new 'light-version' of the settings file as desired. It requires a single copy action to switch, but maybe that is useful for you?

Dennis

---

Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Verzonden: maandag 4 oktober 2021 15:39
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: Re: [escet-dev] Things that break the code editing flow (was: Openness/transparency)

 

Hello,

Second attempt of sending this, first one stranded in "not authorized to send mail".

> Regarding 'Eclipse editor forgets everything when you don't have a syntactically correct file': Do you mean that if you save you lose things you entered? Or something else? I'm not yet sure I understand what you mean here. If indeed you lose what you typed then that would be a serious bug!

This was in context of auto-completion. I have disabled the "add matching closing curly brace when you type an open curly brace" option, since I like to explicitly decide that myself.

This means that in any code that I am editing, I have a syntactically broken Java file most of the time.

Obviously the compilation happening in the background detects this and starts throwing errors. That is fine, I just ignore them.

However, as auto-completion also depends on the compiler, I at least then also don't have auto-completion for anything further down the file, even if the compiler saw that part before while I had a valid Java file (that happens when I finish a method or an inner block by typing matching closing curly braces). In other words, the compiler deletes all its knowledge and rebuilds the information from scratch it seems rather than updating parts and keeping untouched parts until a full pass can be run again.

Not sure I am missing other auto-completion parts, I never bothered to verify exactly what part is dying there.

I know about existence of the configuration options of auto-completion, but didn't try changing them to what I like. It looks like it can only change the order of recommendations instead of having different recommendations that better match what we need.

Fairly reasonable cases are missing I think:

• You have a 'final' variable. I would say a reasonable option is to have a constructor that takes that value as a parameter. It isn't offered afaik.
• You have 5 object variables (not final). Again a reasonable alternative would be to offer autocompletion to take these variables as parameter, but fair enough maybe that is not always desired. I copy/paste the type + name into the parameters part of the constructor. I do get auto-completion of assigning a parameter to the field, but 1 at a time, and the name of the parameter isn't matched with the name of the class variable (auto-completion thinks alphabetic order is "most relevant" apparently).

Likely there are many more if you start looking for them.

Insertion of proposals isn't bug-free either. An empty generated constructor gets a "// TODO: write code here" comment. The first parameter copy statement to its field gets inserted above that comment line, the second parameter copy statement gets inserted below the comment line.

Template instantiation isn't quite right either. We have a standard blurb with the constructors, and I inserted that blurb in the javadoc list to save typing. I type "/**" and then ENTER above the constructor, and I end up with an additional " * " line in the inserted template, since it first inserts the template, and then still processes my ENTER leading to  an additional line.

In whole, the entire editor seems very inadequate in handling things. One reason that I use it is because it's faster at autocompleting class-names, and methods than I can type. Another reason is that trying to use something else is mostly impossible.

I am very weary of sending bugs to JDT. The things I notice seem so blatantly obvious that you cannot miss them, yet it's not there. We can't be the only people that write java and initialize object variables from the constructor. I also had the experience to report a problem in switch statements where the wrong deduction was made, only to get the issue closed automatically a few years later without addressing the problem.

This claiming of success even though it barely works is another thing that happens more often. Did you try a dark theme? Eclipse says it works, but if you try it you'll spot lots of problems immediately, and many more if you actually use it.

> Regarding Eclipse configuration and documentation not being clear ...

It's the entire eco system indeed. It's accepted policy by Eclipse that useful documentation isn't relevant. I can file issues but that doesn't solve my problem of wanting to do something and only getting frustratedly stuck in the swamp of useless HTML reference documents, errors that say nothing, explanations that say nothing, and third-party web sites that only cover the trivial good weather case and claim problem solved (if they even take a good solution instead of a bad one).

Again this is everywhere, people must be together spending eons finding out how to do simple things in Eclipse due to not having adequate documentation.

I am very stuck with Eclipse. I can't get "in", since it assumes this unknown large amount of knowledge that is not written down in an accessible way. I have no idea where to start reading or how to look for things, every attempt just ends in the swamp without getting wiser. I can't get "out", since we're very much glued to this Eclipse thing and there isn't a viable alternative.

I'd write a code editor and ditch everything eclipse if I'd have the time to make it.

I still prefer plain "javac" and "jar" over anything else, since the latter are much harder to understand and get running, throws errors I don't know how to fix and give no major improvements in what I need to do.

> Regarding Checkstyle warnings: Is it about the style that we use to highlight Checkstyle warnings ...

The style is quite overboard, but it's more the timing. I use code as a srcatch board to understand the problem at hand, and work out where the gaps and fundamental problems arise. I just want to write "will this have a fair chance of flying" code then, lots of stubs and half-finished functions, different classes that should work together but aren't connected yet, etc.

I am focussed on the problem that needs to be solved looking at the core steps that must be done, fleshing out the global structure. I don't want distractions  because I inserted an additional empty line somewhere, broke a curly brace rule, a max length line rule, or a code formatting rule, didn't write javadoc for a trivial function, did a static import "*", or have 10 imports that I copy/pasted and currently don't need all of them.

It's a scratch implementation for finding out that the approach will work at all. It's not production code that fulfills all rules of the house. I can't write the latter without knowing the former will give me a positive answer. You may work differently, I don't know.

The warnings in themselves are somewhat useful in pointing out omissions at some point. There seems to exist a distinction between things where I knowingly break the rules to allow for focussed working (pasting 20 imports at the very start as I likely need at least 15 of them in the future, including a few non-standard "*" static imports as  I will need those functions in the solution, not fully handling all cases in a switch, not handling all control flow for returning a value from the function call), rules that don't serve a purpose at the time (white space and strict formatting rules for example), and rules that help me in spotting things I missed. Type errors in expressions, for example.

---

From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Wednesday, September 29, 2021 17:55
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: Re: [escet-dev] Things that break the code editing flow (was: Openness/transparency)

 

Hi Albert,

Sorry it took so long for me to reply. I had lost track of this email. I just found it while cleaning up my mailbox.

Thanks for providing concrete information on what bugs you. Without this type of information, we can't take action on it, to improve the situation.

Regarding each item:

• Regarding the formatting of 'if' and '{': I've created #194 to discuss further, and see whether we can improve things.
• 
  
• Regarding 'Eclipse editor forgets everything when you don't have a syntactically correct file': Do you mean that if you save you lose things you entered? Or something else? I'm not yet sure I understand what you mean here. If indeed you lose what you typed then that would be a serious bug!
• 
  
• Regarding auto-completion: The Eclipse JDT Java editor has many options to control auto-completion:
  
  
  
  For instance, the 'sort proposals' option can be used to configure the order of proposals. If you can come up with better settings, we could consider adding these to our Oomph setup. If there is no order that fits for you, then I propose to create an issue for JDT to suggest something better, such that they can implement it.
• 
  
• Regarding Eclipse configuration and documentation not being clear: I'm afraid I can't change the whole Eclipse ecosystem. If you have specific issues, I propose to create issues on the corresponding projects. I've done so myself as well in various situations.
• 
  
• Regarding the new Java file template: I've created #195 as I like the idea a lot. Also, I seem to have it working correctly, I think.
• 
  
• Regarding Checkstyle warnings: Is it about the style that we use to highlight Checkstyle warnings (the whole background gets an orange color)? Or does it also concern Eclipse JDT warnings (yellow squigglies under the line)? See the following screenshot for the difference:
  
  
  

Dennis

---

Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Verzonden: woensdag 23 juni 2021 13:22
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: Re: [escet-dev] Openness/transparency

 

> I don't experience this myself. So I'm very curious if you could indicate what breaks your flow? That way, maybe we can improve things?

Bit of a collection of niggles.

• I still don't like the "single statement needs curly brackets" thing. It makes handling a trivial case costing 3 lines, and if you have a bunch of such lines, it explodes in length.
  

    public Node conjunct(Node a, Node b) {

        if (a == b) return a;

        if (a == Tree.ZERO || b == Tree.ZERO) return Tree.ZERO;

        if (a == Tree.ONE) return b;

        if (b == Tree.ONE) return a;

    public Node conjunct(Node a, Node b) {

        if (a == b) {

            return a;

        }

        if (a == Tree.ZERO || b == Tree.ZERO) {

            return Tree.ZERO;

        }

        if (a == Tree.ONE) {

            return b;

        }

        if (b == Tree.ONE) {

            return a;

        }

I don't know about you, but I find the first version much easier to globally grasp there are 4 if statements. If there is an empty line below it, it trivially makes a group of code. The bottom version takes effort to understand, at least I need to search for the start of the next statement. Conditions and actions are mixed vertically.

• Eclipse editor forgets everything when you don't have a syntactically correct file, which is the case a lot of times. I typically don't have a balanced number of braces since I work top-downward, and not outside-inward. The editor is simply not handling that well to say the least.
  
• Auto-completion and quick fixes don't fit my style (or our style). Apparently it's weird to have a variable name in the constructor parameters, and assigning that to a class variable with the same name, as it's consistently near the bottom of the options. Import resolution has very weird order for anything generically named. Trying to import the Tree class from multivalues project gave me links from all kinds of Tree things, but not the one I had opened in the projects.
  

• Configuration of eclipse is frustrating. I wanted to add the eclipse standard file header to the new-file template after creating 2 new files and finding myself having to paste the standard header each time. I found that template, then saw it has a "filecomment" variable intended for it. But where is this thing? The documentation lists it as available, but no link, no mention where it can be found except at silly places like "you can specify variables at the command line". In fact, a search in the docs pointed out the only spot where it is explained is in that "it is available" list. Preference searches turned up nothing on various keywords. So what should have been a 15 second job turned into 30 minutes frustrated searching and still not finding. In the end I just modifed the new-file template, killing the ${filecomment} line, as it's not usable anyway.

• The real killer for flow is however Checkstyle being highly annoying with big yellow stripes at places I either do intentionally (eg "import static something.*;" so static functions are resolved without effort until done, or by accident (paste an import at a random place because eclipse cannot figure it out, delete some code and you end up with more than one empty line, or type a single line "if (..) return;").

Yes I agree it's not the code style, and yes, I will fix it, but not now, go away! I don't want yellow strips flagged as error while trying to formulate an algorithm, thinking about which cases to handle, and while making changes at lots of places to get all the bits and pieces fitting with each other.

Once it works, fixing all the minor code style troubles is early enough.

For some reason, the editor and the tools you write perfect code from the start. If you don't all hell breaks loose. Editors become useless, checker tools throw errors at you about non-relevant stuff at that point in time.

---

From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Monday, June 21, 2021 17:35
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: Re: [escet-dev] Openness/transparency

 

Hi Albert,

For #122 if the code was already there, then I fully understand. And indeed #124 is very small and so obvious, so maybe not that relevant indeed.

> To be honest, I am not sure I would want to develop in ESCET. Everything is so nailed down, tools are panicking all the time and would be breaking my flow.

I don't experience this myself. So I'm very curious if you could indicate what breaks your flow? That way, maybe we can improve things?

Dennis

---

Van: escet-dev <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, Albert <A.T.Hofkamp@xxxxxx>
Verzonden: vrijdag 18 juni 2021 16:21
Aan: escet developer discussions <escet-dev@xxxxxxxxxxx>
Onderwerp: Re: [escet-dev] Openness/transparency

 

Controller check (#122) is work that already existed (part of PhD work of Ferdie), which is just converted to ESCET, modulo some code that relates to other tools.

Empty container type-safety (#124) was something I noticed, which literally took less than an hour to change to a better standard Java alternative.

For the former, I am not sure what there is to discuss. ESCET is not the primary development platform. ESCET is a platform for publishing finished work. Stuff comes as-is. If this is a problem, the higher-level process should be discussed.

For the latter, could be done, but on the other hand, discussing whether we want more type-safe code seems like a question with only one possible answer.

To be honest, I am not sure I would want to develop in ESCET. Everything is so nailed down, tools are panicking all the time and would be breaking my flow.

---

From: escet-dev <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Friday, June 18, 2021 14:13
To: escet developer discussions <escet-dev@xxxxxxxxxxx>
Subject: [escet-dev] Openness/transparency

 

Hi Albert

I noticed you created issues like #122 and #124 and then immediately provided a branch / merge request. Are these things that have been worked on in the past (in a fork for a closed-source research project), that are now being contributed to open source? Or did you do work on them specifically for Eclipse ESCET?

It would be preferable if you could create the issue before you start working on it, to improve openness and transparency. Now suddenly there is an issue and a solution, without the possibility for the other committers and the larger community to discuss the ideas.

Dennis