(Poll) What features do you wish you had in AutoIt?

[TheSaint]

On 7/21/2021 at 9:48 PM, Earthshine said:

it matters because because it scales well and debloats the output. it matters on large scales stuff. He's a perfomance guy... that's a good thing in my book. He's talking about a smart linker that only pulls what's necessary into the executable so it's not a fat, bloated piece of software

Sorry for the late reply.

I cannot see how it makes any difference to performance. If something is not referenced surely it is not processed.

I don't like bloat, but you have to view things realistically. Does the bloat impact anything other than a slightly larger file.

I'm not against a smart linker, but it would seem to me it would require considerable effort to produce that, which might be better spent elsewhere. I certainly don't see the lack of a smart linker in AutoIt as an issue.

I am also not seeing fat & bloated, rather skinny or in comparison bloated (but not fat).

There are ideals and there are compromises. I have always rather favored the compromise, especially as you tend to get more done by doing so. I guess it all depends on how you define perfection. I see it as an overall state, rather than every bit being perfect.

[TheDcoder]

14 hours ago, jchd said:

If Execute is smelling that bad, please offer an alternative to the sample AutoIt code I posted above.

I don't recall seeing Execute in your code, but I will surely provide some alternative which would make arrays more "manipulable".

10 hours ago, seadoggie01 said:

Java's objects, but only because I know them much more. I'm sure with a bit of time I won't mind JS's objects. And I probably would mind JS's objects less if the IDE found more errors, but that's another story. Edit: And your knowledge on Java vs JS objects seems to be correct... as far as my knowledge goes

Interesting, but they are fundamentally incompatible with dynamic typing, so unfortunately you will have to live with whatever non-OOP objects that end up in ECI.

Quote

Sorry for the delay in replying.

No problem!

Quote

(...) the trouble I keep running into when AutoIt is controlling the higher-level/interfacing stuff is that bytecode is just too slow for things like data conversion, for example reading in a large csv file and converting the contents to binary floats/doubles; it can literally take many hours.

I see, but I don't think AutoIt uses any kind of bytecode, perhaps the interpreter runs purely based on the parser without any intermediate? This would explain why it takes a very large overhead.

In my opinion the overhead shouldn't be too big if the instructions are ready in advance, I would expect a slow down of 10x at max, so it shouldn't take hours like in AutoIt.

Quote

But I'm not clear what your hardware targets are. Do you really want to be able to run EasyCodeIt on refrigerators and doorbells?

I mean, I don't want to limit my imagination

I'd want to be able to atleast run it on SoC type computers, like RPi and mobile phones, and perhaps some advanced micro-processors.

Quote

If you're sticking with x86 for now, I would consider offloading some of the very labour-intensive tasks to some prefab precompiled solutions. Of course even better would be if you could provide a compiler for turning your bytecode into a machine-coded version. Shouldn't be more than a few years work...

Of course, that goes without saying, I'd be implementing all the labour-intensive tasks in C and provide functions from them. As for a compiler, I think we can target LLVM and have it translate the IR into actual machine code instead, it is a very mature platform which supports many targets, so we get those benefits for free

I am imagining something like this Parser -> Byte-code (ECI-specific IR) -> LLVM IR -> Whatever LLVM can give you

Initially I'd be implementing an interpreter which will work with the AST, and after there is enough momentum we can switch to bytecode, don't want to start too quick and mess up the bytecode stuff before we have a working proof of concept.

Once the project is mature enough we can start thinking about LLVM, JIT and all that fancy stuff

Quote

Re. boost, I don't think you're being fair.

Quote

I'm not trying to  promote C++ here, I was hoping you would find some of these programming features sufficiently useful to consider incorporating them in your  own fashion.

Sorry about being so dismissive about it, I initially thought you were suggesting a more direct integration. I appreciate your suggestion, I will surely be implementing the useful utility functions you mentioned, we will see to what degree we can adopt them

Anyway, how does a library implement a language feature like lambdas? Is it all just a bunch of macros?

Quote

I think this is very wise. structs are fine, objects (basic structs with de/constructor, not so sure about methods) are fine, but object inheritance is deep dark chasm, inviting poor design, nigh-untraceable bugs, and plain misuse; I fear you will be wailing in programmer-hell for all eternity (and your users too) if you were to pursue this.

Since functions would be first-class features, you could use them as a value in any place. Maybe I can make "constructors" possible by implementing sub-functions which inherit the parent function's calling context, effectively adding state to it .

No inheritance system for now... unless I change my mind for some reason or if people really ask for it.

Quote

But writing a solid multi-threading code (esp. for GPU) is very hard, the pitfalls numerous (locks, barriers, wait states, synchronised values anyone?) optimising the memory management is a total nightmare (my CUDA codes require several AutoIt preprocessing steps just to figure out how to divide up the CPU RAM and GPU global /local/ thread-specific memory most efficiently, and which vars to store where), and debugging race conditions while your OS is happily playing interrupt-bongo is no fun at all. I'd be very careful before implementing more than the most basic support for this (I saw you voted for this yourself).

No doubt, but they GPU code you mentioned is an extreme case in my opinion, I don't really see people using ECI to write efficient graphics stuff, I am sure @UEZ and co would happily explore the limits, but not serious stuff really.

The multi-threaded system I am imagining would be baked into the language itself, not like an after-thought as it is usually implemented in many language. All of the locking, barriers, synchronization etc. would be handled internally, your MT code would look just like the ST code, but it will block when reading locked variables etc.

This shouldn't be an issue for a high-level scripting language like AutoIt or ECI.

Quote

Anyway, I wish you fortitude and perseverance.

Thank you! I am absolutely going to need them if I am ever going to lead this project towards fruition

9 hours ago, seadoggie01 said:

I like RTFC's ideas on objects. I don't need inheritance (even if I like it) and I could deal with objects being a collection of properties... wait this is just a dictionary now, right? Well a dictionary with a constructor at least... hmm

(...)

Edit: If objects are dictionaries, and functions are first-class citizens, then could objects have methods applied by adding the functions to the dictionary? And inheritance would be simply creating the super dictionary and adding extra stuff to it?

I like his take on objects too, also see on my thoughts above about implementing "constructors" via sub-functions and inheritance.

Quote

Regarding multi-threading, would borrowing the Promise from JS be easier than a full implementation?

Nah, not really, JS isn't a multi-threaded language, but it has the ability to switch the context of execution whenever it needs to, so it creates an illusion. It is a nice way to implement non-linear code but it doesn't really work if you don't have an event-based approach.

Promises are just wrappers around the event-based stuff in JS, they are handy but I would never use them outside JS.

Quote

I think my main reason for wanting it is to have GUIs display nicely while I'm running background code. I've only really ever wanted/used multi-threading in a handful of applications anyways

If I am being pedantic I could say you can do that with OnEvent mode, I use it in one of my programs (ProxAllium). Multi-threading is seldomly used in scripting, but having it available can be a blessing! Imagine myself when I had to implement a complex scheduler in AutoIt, all single threaded 😭

8 hours ago, TheSaint said:

Sorry for the late reply.

I cannot see how it makes any difference to performance. If something is not referenced surely it is not processed.

(...)

No problem about late replies.

It doesn't effect performance directly, but I get your point, you don't want there to be extra effort for only a little less bloat. I am in the same boat (pun unintended), I'd only look into this when it is time, not something I am racing to implement in v1

--

Damn, did this post beat my previous post's record?

[JockoDundee]

On 7/21/2021 at 5:18 AM, Earthshine said:

it matters because because it scales well and debloats the output.

FYI, debloater.com is available

[TheSaint]

3 hours ago, TheDcoder said:

Damn, did this post beat my previous post's record?

LOL. I am giving you the Word Wall prize of the day.

Congratulation on all those Wurdles.

P.S. For those who don't know, a Wurdle is a Word Wall broken down into little hurdles you need to leap over to get to the end. Breaks down the Word Wall for easier consumption.

P.S.S. Maybe we should accuse you of Post Bloat. 

Edited July 26, 2021 by TheSaint

[RTFC]

5 hours ago, TheDcoder said:

how does a library implement a language feature like lambdas?

It's a template library creating a localised, unnamed abstraction layer, so basically like Execute, but able to handle multiple lines of code, local vars, bound arguments, and such). Quite handy.

5 hours ago, TheDcoder said:

I'd be implementing all the labour-intensive tasks in C and provide functions from them

You made me very happy.

5 hours ago, TheDcoder said:

unless I change my mind for some reason or if people really ask for it

Be careful with that; that's how I got myself married.

5 hours ago, TheDcoder said:

useful utility functions

Please implement my personal favourite: tribooleans (False, Undecided, True). Think of how humanly waivering your codes could be (I might show you a GUI..., or not, or later, if you're good, however...). You know that old Monty Python song:

Spoiler

I love traffic lights,

I love traffic lights,

I love traffic lights,

I love traffic lights,

I love traffic lights,

I love traffic lights,

I love traffic lights,

But only when they're green.

 

4 hours ago, JockoDundee said:

debloater.com

Is that part of Weight Watchers? Can i send my sister?

Edited July 26, 2021 by RTFC

[JockoDundee]

30 minutes ago, RTFC said:

Is that part of Weight Watchers? Can i send my sister?

Nah.  It's a hidden utility from @Earthshine's bootleg of Windows11. 

You run it right after you do something stupid, like decide you want every font known to man installed because wtf.

[jchd]

20 hours ago, seadoggie01 said:

@jchd Correct me if I'm wrong, but with the style of array TheDcoder has mentioned, an array element will contain another array. So you could recurse through each array's elements to sort them. Something like this:

Your code sample doesn't solve the problem, as it pushes the burden of implementing the actual sort to the user function, which is what we want to avoid.

[jchd]

9 hours ago, TheDcoder said:

I don't recall seeing Execute in your code, but I will surely provide some alternative which would make arrays more "manipulable".

 

[jchd]

I find this thread has shifted too far away from the initial title (and IMVHO intent) and seems to turn into: "which paradigm and features would you love to find in your ideal language?".

If necessary, this just proves once more that threads are evil.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
http://becpp.org/blog/wp-content/uploads/2018/01/Frederik-Vannoote-Threads-are-evil.pdf

The most serious problem with threads is that you can't build a strict formal model using them, hence you can't prove program correctness. The most powerful formal methods (B, event B, COQ, TLA+, whatever) can't deal with multiple classical threads.

[JockoDundee]

Just came across this 7yr old  “debate” over the use of dot notation with structs, and worries about the potential for misuse.
Interesting…

<spoiler alert - it doesn’t end well>

 

[TheDcoder]

@jchd Sorry, but I don't see the Execute function anywhere in your code, maybe you omitted it before submitting?

11 hours ago, jchd said:

I find this thread has shifted too far away from the initial title (and IMVHO intent) and seems to turn into: "which paradigm and features would you love to find in your ideal language?".

Somewhat true, and I was expecting a slight deviation when I started this. People like sharing their opinions and discussing, I am not complaining as it provides me with valuable feedback on what people are looking for.

About threads, the arguments you present are a bit one-sided, sure multi-threading isn't the magical panacea for programming, but it is just another tool that you can use, it comes with its own drawbacks but it also offers unique benefits.

I am not really concerned about the theoretical argument about correctness as this is a high-level scripting language and we can apply restraints when needed, the rest is left up to the programmer's code design. You can take a horse to the water but you can't make it drink

@JockoDundee Yikes, that got nasty in the end. However I think it was because of the confrontation, not due to the merit of the facts that were being discussed. Also TIL there were something called "Tables"

I'd end up implementing records/objects/structs at some point anyway, so those could be used as a replacement for DllStructs

[JockoDundee]

13 minutes ago, TheDcoder said:

Yikes, that got nasty in the end.

Yeah, it did - but I warned you.

The part I found interesting was the concept of building features into the language (that are desired by the community) and then not telling anyone about them for fear of “misuse”.

It wasn’t exactly clear how the dot notation was discovered by the Hoi Polloi, but it certainly could have been someone not familiar with the language guessing.

Makes you wonder what else may lie dormant, just waiting for the AutoIt ingenue to stumble upon…. ThreadCreate() perhaps?

[TheDcoder]

1 hour ago, JockoDundee said:

Makes you wonder what else may lie dormant, just waiting for the AutoIt ingenue to stumble upon…. ThreadCreate() perhaps?

There already is a way to create threads in AutoIt, yes, real actual threads. You literally call the CreateThread function via DllCall (since it's a Win32 function), someone even made a wrapper UDF around it: https://github.com/jesobreira/thread.au3

It works, but crashes are imminent because AutoIt was designed to work in a single thread, so once the thread does something which conflicts with the main thread, the program segfaults and crashes hard.

1 hour ago, JockoDundee said:

The part I found interesting was the concept of building features into the language (that are desired by the community) and then not telling anyone about them for fear of “misuse”.

Yeah... I am being careful of that too, I don't want to make ECI yet another OOP language, the beauty of AutoIt is in the simplicity, no complex object hierarchy and convoluted code.

I guess there is no way to enforce this but making the standard library not use objects extensively should set an example for those who want to write code with the best practices.

[JockoDundee]

1 hour ago, TheDcoder said:

There already is a way to create threads in AutoIt, yes, real actual threads…

Yes, this is true.

However, as far as AutoIt is concerned, I am totally ok with fake Autoit threads, if they are ever implemented.

I don’t think it would that hard to do and still make it “thread safe”, because much of the work has been done, implementing other psuedo-concurrent facilities, like hotkeyset and adlib. 

It could work much like Adlib does today but with a persistent program location and a finer time slice < 1 ms.

Except that you could just call a function with some keyword Async that would run interleaved with everything else until it returns.

True, it’s not perfect, and the programmer could totally screw up by not managing global references, but I think it would reduce the demand for true multithreading in many cases.

 

[TheDcoder]

@JockoDundee I think you are talking about asynchronous execution, JavaScript uses this model as an alternative to multi-threading.

This is how multi-threading used to be implemented in the days of single core processors I think. Anyway, I still haven't looked much into how I would be implementing threads, but the time is coming nearer.

[CoffeeJoe]

I am way late to the discussion, and I'm not sure its still open.

My request is intended to be more broad than specific. I want some sort of parallel processing capability.

Call it multi-threading, call it multi-processing, call it bob.

For me I'd be happy if AdlibRegister simply spawned a  new process and didn't require the main process to even notice.

Programming in Java was fun and I see people talking about OOP - for me the one thing I miss is Instantiation - again an issue without parallel processing.

Then I remember that its a scripting language not an application development platform.

Just the things I was thinking as I tread through this thread.

[argumentum]

@CoffeeJoe, there is forking you can do with AutoIt. Look at my signature.

[TheDcoder]

@CoffeeJoe No problem, the discussion is always open in my threads. Thanks for the input

@argumentum Cool, I was thinking about making a multi-tasking UDF myself back in the day, even started writing it I think. I have a couple of unreleased bits of AutoIt, and I guess they will never see the light of the day as I was much less experienced when writing them.

I sometimes cringe at the stuff I used to write... still good to have something to look back to.

[JockoDundee]

3 hours ago, argumentum said:

there is forking you can do with AutoIt.

Similar to Unix fork() ?

or more like exec() ?

[Loc]

wish for multithreading 😰