Live data from Hacker News

Learning to code vs. learning to automate

daedtech.com

21–30 of 190 posts

Re: Learning to code vs. learning to automate

#21
Obligatory RPA: GUI-based automation to mimic user interactions, leveraging existing application and web GUIs as an API to automate against.

Not something I'd recommend to backend developers / data crews. But it's pretty awesome stuff for non-developer, front-line business users.

What is RPA? - https://www.uipath.com/rpa/robotic-process-automation

UiPath free, "unlimited time for non commercial use" trial - https://www.uipath.com/product/studio (you're looking for "Community Edition")

Disclaimer: I have no financial interest in UiPath as a product, past running a business user-focused automation enablement team that is currently using it. I've been in the space about a decade, and just happen to think they do it "better" than anyone else currently (YMMV. Pegasystems' RPA offering is also great, but they don't talk to non-Fortune 500s or advertise it)

Re: Learning to code vs. learning to automate

#22
post #15
post #11

The whole nature of coding is that is essentially motivationally self-taught. As for automation- that’s what better coders do. Perhaps this is being confused with “Find a good problem that motivates you, and fight a knock-down, drag-out battle to solve it.”

Programmers drastically underestimate the amount of poor abstractions we've created. There's no reason someone should have to learn object oriented programming in order to be able to do 4 actions across 2 apps. Fundamentally, that's what this article was getting at for me. Should we (a) encourage more people to learn to code (in existing languages / frameworks), so that they might use coding to automate their own wor…

To put what you've said more succinctly, even though reductionism is valid for a computer, there is no reason for us to reduce everyone to transistors.

My mother is an accountant for example, and she could easily pick up SQL or a programming language, but the issue with teaching her one is that it doesn't solve any of her immediate problems. Excel already automates most of that work away, so for her that's all she needs.

Your company's accountants can probably write excel statements that are equivalent to complex SQL statements, so I wouldn't underestimate them :)

Re: Learning to code vs. learning to automate

#23
When I was younger I dreamed up an idea of a shock suit, basically it would have been a set of long underwear top and bottom with electrodes that would act like a TENS machine to gently(or not so gently) nudge the wearers into performing a repetitive task with machine accuracy. I figured this would be great for an assembly line and could provide a cheaper alternative to a very costly robot while still providing employment. I never pursued the idea after telling my Dad about it who told me it was an immoral idea.

Personally I would still be willing to wear a suit like that if the pay was good enough. Put on the suit, turn off my mind and put in a days work.

Re: Learning to code vs. learning to automate

#24
post #11

The whole nature of coding is that is essentially motivationally self-taught. As for automation- that’s what better coders do. Perhaps this is being confused with “Find a good problem that motivates you, and fight a knock-down, drag-out battle to solve it.”

I'm struggling to parse "essentially motivationally self-taught" but if you mean to say something like "only self-taught programmers will successfully learn to program" that's a myth that isn't backed up by the evidence and serves to exclude people from programming.

This talk addresses that misconception: https://www.youtube.com/watch?v=g1ib43q3uXQ

The paper discusses "constructionism" (which, loosely put, is the idea you give someone a toy and let them figure it out): http://morganya.org/research/2018-Ames-CSCW-Constructionism....

There is more out there but that's all I have time to find right now.

Re: Learning to code vs. learning to automate

#26
post #7

Any recommendations on a good MacOS GUI automation tool that isnt Automator? Seems like the windows automation ecosystem has several options, but I’m struggling to find a good Mac solution that’s capable of automating desktop apps with fine-grained workflows

what's wrong with automator exactly? i've been wanting to get into it on my new mac but i'm not entirely sure what i will use it for yet.

Personally I find it very weird to work with. I don’t see the point of learning a different and less powerful coding paradigm. It would be fine if it had it a current UI but you also should be able to write plain text code.

Re: Learning to code vs. learning to automate

#28

Any recommendations on a good MacOS GUI automation tool that isnt Automator? Seems like the windows automation ecosystem has several options, but I’m struggling to find a good Mac solution that’s capable of automating desktop apps with fine-grained workflows

Keyboard Maestro is my go-to tool. It's incredibly powerful and I've automated so many things in so many applications that I really don't even know if I could use a computer without it anymore. https://www.keyboardmaestro.com/main/

Another vote for KBM

Re: Learning to code vs. learning to automate

#29

Any recommendations on a good MacOS GUI automation tool that isnt Automator? Seems like the windows automation ecosystem has several options, but I’m struggling to find a good Mac solution that’s capable of automating desktop apps with fine-grained workflows

There used to be Userland Frontier, which was actually earlier and better than AppleScript!

https://en.wikipedia.org/wiki/UserLand_Software#Frontier

>UserLand's first product release of April 1989 was UserLand IPC, a developer tool for interprocess communication that was intended to evolve into a cross-platform RPC tool. In January 1992 UserLand released version 1.0 of Frontier, a scripting environment for the Macintosh which included an object database and a scripting language named UserTalk. At the time of its original release, Frontier was the only system-level scripting environment for the Macintosh, but Apple was working on its own scripting language, AppleScript, and started bundling it with the MacOS 7 system software. As a consequence, most Macintosh scripting work came to be done in the less powerful, but free, scripting language provided by Apple.

Both AppleScript and Frontier supported Apple's "Open Scripting Architecture" (kind of like OLE Automation via Apple Events).

https://developer.apple.com/library/archive/documentation/La...

https://en.wikipedia.org/wiki/AppleScript#Open_Scripting_Arc...

Now Automator lets you use "JavaScript for Automation" instead of AppleScript.

>Under OS X Yosemite and later versions of macOS, the JavaScript for Automation (JXA) component remains the only serious OSA language alternative to AppleScript, though the Macintosh versions of Perl, Python, Ruby, and Tcl all support native means of working with Apple events without being OSA components.

https://hackernoon.com/javascript-for-automation-in-macos-3b...

https://apple-dev.groups.io/g/jxa/wiki/JXA-Resources

https://github.com/JXA-Cookbook/JXA-Cookbook/wiki

As an example task similar to what the article discusses, whose source code is actually readable, here's a script to change the font of all text in all master slides in Keynote. (Probably the world's first JXA script written in Literate CoffeeScript).

https://github.com/JXA-Cookbook/JXA-Cookbook/wiki/Examples#k...

I wrote more about Frontier and other automation tools:

https://news.ycombinator.com/item?id=20425970

>The thing that's missing from "Google Docs" is a decent collaborative outliner called "Google Trees", that does to "NLS" and "Frontier" what "Google Sheets" did to "VisiCalc" and "Excel".

Re: Learning to code vs. learning to automate

#30
post #15
post #11

The whole nature of coding is that is essentially motivationally self-taught. As for automation- that’s what better coders do. Perhaps this is being confused with “Find a good problem that motivates you, and fight a knock-down, drag-out battle to solve it.”

Programmers drastically underestimate the amount of poor abstractions we've created. There's no reason someone should have to learn object oriented programming in order to be able to do 4 actions across 2 apps. Fundamentally, that's what this article was getting at for me. Should we (a) encourage more people to learn to code (in existing languages / frameworks), so that they might use coding to automate their own wor…

"There's no reason someone should have to learn object oriented programming in order to be able to do 4 actions across 2 apps."

Object-oriented programming is extremely simple and is taught in high school and earlier.

Post reply on HN