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

[Dennis Hendriks <dh_tue@xxxxxxxxxxx>]

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