Coding is hard, let's go shopping!
-
And with VBA/TeX (depending on your system preference), you can replace the company for paying your paycheque too.
-
Other than Gmail (which is just passable), Google's never home-grown a product worth using.
I quite liked Voice. But they're ruining it with Hangouts, which doesn't know how to use a headset.
-
I feel like everyone understands what a doctor or a lawyer or a chemist does, and can assess whether they'd be happy in that career. By giving more people exposure to what programming is like, we enable them to make that assessment as well. Which is why I'm all for teaching as many people as possible just enough programming to get a sense of what it's like.
When I was young and exposed to programming it looked like fun, I did not expect for tps reports, meetings, running to implement salesmen lies, working around company policy, violent gangsta bosses, and a lot of shit that is not programming. I would probably be happier in a different path, but I'll never know.
-
I did not expect for tps reports, meetings, running to implement salesmen lies, working around company policy, violent gangsta bosses, and a lot of shit that is not programming
That stuff also applies to lawyering, chemistry, and doctoring, though. It's pretty much the cost of doing business.
-
On the overall topic, I have this to say:
- Most people can program and automate some tedious parts of their work. They just have fear and prejudice towards the Machine.
- Programming a computer takes skill and mindset, and that translates to time to learn. Trivializing it to a short 2-day outreach "course" which is just retyping a tutorial is the wrong way to do it.
- A few hundred years ago basic algebra was considered mad skillz, and now it's a part of high school curriculum. I think the basics of information theory and computer programming will eventually be trivialized enough. I don't see it happen overnight, though.
- The snobs who resent the fact it took them years to get skilled in something, and others are level with them after months, are damn wrong.
Another point... There is a difference between learning while being young and going to college, and learning while having a family and a job. It's easy to get disappointed even when the rate of information absorption stays the same. And it doesn't stay the same, given all the stress. It's unrealistic to demand of someone to pick up a whole new set of abstractions in the matter of weeks while having little time to let the brain digest that.
-
Trivializing it to a short 2-day outreach "course" which is just retyping a tutorial is the wrong way to do it.
Maybe. It's not totally different than how a lot of us got started, though, I'll bet. I remember copying BASIC programs from magazines and being amazed at the results. Which got me interested enough to keep doing and learning.
-
To write software that does X, you need to know a fuckload more about X than you need to know about software. You know who already knows a fuckload about X? The people you're writing the software for.
I'd say that to produce good software that does X, you need both somebody who knows a lot about X, and somebody who knows a lot about software, and they need to be in close communication, and will end up both learning a good bit about how the other's field works.
If you have just software expertise and no X, then you get the problem that at least half of all non-programming open source software has - tons of time spent building the wrong things, and wrong or half-assed implementation of the things that are most important to the users.
If you have just X expertise and no software, then once you get past a certain level of complexity, you'll have piles of unmaintainable and hopelessly slow crap, often riddled with security holes, subtle data errors not discovered until you already have a huge mess, and all of the other WTFs that we've all seen.
You can build some tools that make it easier for non-developers to do some minor development stuff, but there's always going to be a limit. There's just as much domain knowledge to be had about software as there is for any other professional field.
-
And Betamax was easily a better tape cartridge format than VHS. But everybody used VHS because that's what everybody used.
VHS had longer record times, which put it in the lead back when tapes were much more expensive. By the time the price of tapes went down, Betamax was already a non-starter. Basically, the one feature that mattered most to consumers, economy, VHS was better at.
That said, Betamax's greater quality at low run-times led to a long career in TV stations and other locations where high quality but relatively inexpensive video recordings needed to be kept temporarily.
-
the application developers need to put hell lot of work to make AppleScript actually usable with their particular app.
Not really. It as a "tax" you had to pay, but it wasn't as onerous as, say, crafting a non-shitty Windows installer program.
Another example: OBIEE.
Get those people a copy of Tableau, STAT.
-
Maybe. It's not totally different than how a lot of us got started, though, I'll bet. I remember copying BASIC programs from magazines and being amazed at the results. Which got me interested enough to keep doing and learning.
Well, depends with what sauce it's given to you.My fiancée was at a workshop that dumped a Ruby on Rails tutorial onto participants ("making a blog in 2 hours" or something; I vaguely remember the official docs doing the same). The pimply-faced youth in charge of the course tried to put it as if after completing it you could go and do a web app startup in a hitch (he probably had a startup fetish or something). Good thing that the workshop was free.
I mean, why not be honest and tell that this won't enable you to make great apps right away, that there is still a way to go, but at least you will leave with that satisfying feeling that you, you yourself can make a computer do exactly what you want it to do.
-
copying BASIC programs from magazines
I did that when I could hardly understand the English words. I started with GWBasic, then I attended few programming course: FoxPro (not sure why, perhaps it was available and I liked the shadow under windows), C, Assembly, Visual C++. All before I finished my high school around 1998. The classes each took 3 months and issued a certificate after an exam that I still have :). Of course without college, calculus, ... I could not be an engineer, but could still do fine as a programmer.
It was some sort of community college/apprenticeship. I have seen Germany has similar programs but not in the US. These coding dojo classes are fine if they are teaching it to some kids, as long as there is an oversight and semi-credited diplomas to offer. Like Google/Microsoft could provide the degree. But promising someone who is old, does not know math, and just wants a job, to learn to code professionally in 3 weeks is just scam.
-
I think a lot of my colleague started drilling into computing knowledge from their days using hex editor to hack their games using instruction provided on gaming magazines, so maybe that part (i.e.: having fun accessing "the more bare metal part of system") is important too.
-
Not really.
Yes really.It as a "tax" you had to pay
Was there any obligation from anyone? Was it a prerequisite to being Mac OS Classic Certifiedâ„¢?but it wasn't as onerous as, say, crafting a non-shitty Windows installer program.
TIL that making installers is burdensome, oppressive, troublesome and causes hardship; also, the obligation and responsibility for having one outweighs the advantages.Look. The whole idea behind AppleScript is to make a scripting language that kinda, sorta reads like English language (which is equally as nice as it is dangerous - I heard (probably somewhere around here) of a Python programmer who wrote things like "if x is not 5 or 6"...), and that would interact nicely with the applications. The latter 100% application-dependent, and in no way does AppleScript or Mac OS or any part of the ecosystem make it even a single bit easier to achieve than if they were to be built from scratch. To make scripting possible, the application needs to provide API. To make scripting not merely possible, but a real option, then the API must be very good. Making very good scripting API for GUI application requires twice as much effort spent on designing the application and about thrice as much on programming - because now the goal is neither to make a good GUI app (you can cut many corners in code and still get a good product) or good framework to code against (you don't have to deal with anything GUI-related, like windows or undo etc., which greatly simplifies the design) - your goal is now to achieve both. And for what? How many clients do you think would want to write scripts for your app?
-
The latter 100% application-dependent,
Wrong.
and in no way does AppleScript or Mac OS or any part of the ecosystem make it even a single bit easier to achieve than if they were to be built from scratch.
Wrong.
To make scripting not merely possible, but a real option, then the API must be very good.
Wrong; but of course the better it is the better it is.
Making very good scripting API for GUI application requires twice as much effort spent on designing the application and about thrice as much on programming - because now the goal is neither to make a good GUI app (you can cut many corners in code and still get a good product) or good framework to code against (you don't have to deal with anything GUI-related, like windows or undo etc., which greatly simplifies the design) - your goal is now to achieve both.
Fortunately the OS makers already did it for you.
And for what?
To piss off Gaska.
How many clients do you think would want to write scripts for your app?
Why would I want to limit what my users could do?
-
-
Wrong.
Explain.Wrong.
Explain.Wrong
Masochists aside, who would ever want to deal with shitty API if they could get the job done 200x faster manually? If the only way to interact with the app was to reproduce mouse clicks, then undoing in script would require resing window, moving it to top left corner, and invoking click at magic coordinates. Bonus fun if the size of buttons depends on device's DPI! Do you really think anyone in their right mind would use such abomination?but of course the better it is the better it is.
It works both ways - the worse it is, the worse it is. Beyond some point, it's so bad no one is going to use it.Fortunately the OS makers already did it for you.
Cool! I didn't know that MacOS had out-of-the-box solution for separating logic layer from presentation layer and reversible commands design pattern!To piss off Gaska.
Good luck with pissing me off by making my life easier.Why would I want to limit what my users could do?
We aren't talking about limiting. We are talking about extending. No, they are not the opposites of each other. Not extending doesn't mean limiting. Not limiting doesn't mean extending. Both extending and limiting require going extra mile to achieve the goal. Not extending and not limiting are literally free. If I can either do something or not do something, where not doing this something costs me literally zero in terms of time and effort, then I need a hell good reason to do it, because otherwise it's just not worth it.
-
Masochists aside, who would ever want to deal with shitty API if they could get the job done 200x faster manually? If the only way to interact with the app was to reproduce mouse clicks, then undoing in script would require resing window, moving it to top left corner, and invoking click at magic coordinates.
I don't know what magic pixie dust you Windows masochists use, but on macs, AppleScript very rarely involves coordinates (I can't imagine a use case. Maybe grab a part of screen into pasteboard?). It's mostly about: select menu item labeled this, click submenu item labeled that, in dialog sheet that opens, check a checkbox labeled such-and-such, whack the OK button. Almost in English (that's the ugly part of it).
-
The biggest issue I see with Average Joe trying to code is if someone else is going to then pick up that code after him. If he's been taught VBA in 7 days, that could be a painful and ultimately counterproductive experience.
Except that that possibility exists with the professionals too. There should be a site for that, maybe one that allows people to submit entries and share the WTF-ery with other pros. Wait a minute...
-
I don't know what magic pixie dust you Windows masochists use
None. Because the only alternative is to use generic click-replayers. And to have deterministic clicks, you need to know the pixel you want to click and what will be at this pixel when you click.but on macs, AppleScript very rarely involves coordinates (I can't imagine a use case. Maybe grab a part of screen into pasteboard?). It's mostly about: select menu item labeled this, click submenu item labeled that, in dialog sheet that opens, check a checkbox labeled such-and-such, whack the OK button.
How much effort, as an AppleScript-able application developer, do I have to put in to ensure that the user can easily refer to elements of my window? What can and cannot I use in my interface if I want to make it easily scriptable (treeviews, tabs, floating windows etc.)?
-
How much effort, as an AppleScript-able application developer, do I have to put in to ensure that the user can easily refer to elements of my window?
Well, you have to do everything in Objective-C (or Swift I suppose) so there's that…
-
So I kiss cross-platform goodbye?
-
cross-platform
You probably don't want to do cross-platform GUI apps between Windows and OSX anyway. It's not impossible, but it's really hard because the two platforms work differently to each other in many ways. If you just port something over without being careful, you end up with iTunes or worse.
-
You probably don't want to do cross-platform GUI apps between Windows and OSX anyway.
Something something limit my users?It's not impossible, but it's really hard because the two platforms work differently to each other in many ways.
Could you give me example? Are there some things that are drastically different between Mac and Windows (aside from right-click/cmd-click thing) that make it a bad idea?
-
Are there some things that are drastically different between Mac and Windows (aside from right-click/cmd-click thing) that make it a bad idea?
Colour and font chooser dialogs. On Windows, these are usually modal. On OSX, they're non-modal. Hiding that sort of difference is hard. There's probably a bunch more, but I can't be bothered to think that hard. There's just a lot of differences in how things work and what users expect in how things fit together — I'm not saying either is wrong, just different — and it is stupidly difficult to make a program that runs on both (allowing for a simple recompilation) and doesn't suck on at least one of them.
Of course, it's more usual for cross-platform GUIs to suck on all platforms they run on. The classic example of this that I used to use (reluctantly) was the Cisco VPN client: it used Qt so it was quite cross-platform, and it sucked balls everywhere. (The back-end driver code wouldn't have been very cross-platform, but that wasn't user-exposed.) I'm very glad that I don't have to use that any more!
-
Colour and font chooser dialogs. On Windows, these are usually modal. On OSX, they're non-modal.
Does it make any difference to people? Have you ever met anyone who was seriously annoyed by it being not the standard way per current OS (and by seriously annoyed, I mean at least the level of how people initially responded to this newfangled ribbon thingy in Office 2007)? Honestly, this is the last thing I would think about when designing cross-platform interface!BTW, do you happen to know how does Photoshop solve this issue? I own neither a Mac or a Photoshop, so I cannot check myself.
There's just a lot of differences in how things work and what users expect in how things fit together
All those tiny details that I have never seen actually documented anywhere and that average users don't notice themselves most of the time, even after these details are altered. For example, I'm pretty sure only power-users will ever notice that Windows 10 allows to snap windows to inner screen edges of multi-monitor setup too.Of course, it's more usual for cross-platform GUIs to suck on all platforms they run on. The classic example of this that I used to use (reluctantly) was the Cisco VPN client: it used Qt so it was quite cross-platform, and it sucked balls everywhere.
I'm pretty sure it isn't because of Qt, but because of Cisco.
-
How much effort, as an AppleScript-able application developer, do I have to put in to ensure that the user can easily refer to elements of my window?
Use Cocoa APIs and it comes for free.
Wait. Doesn't Windows expose the same things, I dunno, for screen readers and shit? Accessibility in UI usually means your widgets must be externally addressable.
-
Use Cocoa APIs and it comes for free.
In what form? If it's just giving the scripter a way to refer to any clickable or inputable thing in my program and click or input at will, then it's already great. Great, in the sense more than most people would ever need. In terms of actual usability, it's passable at best. And such "API" would be PITA to code against, especially something more than a throwaway script no one except me will ever use.If it's anything less than that, then it's nearly unusable as it is, and fixing it into proper state probably wouldn't be worth it. I can't imagine how a generic solution can be more than I wrote in the previous paragraph, so I won't even write the if for this case.
Wait. Doesn't Windows expose the same things, I dunno, for screen readers and shit?
None that I know of.
-
-
In what form? If it's just giving the scripter a way to refer to any clickable or inputable thing in my program and click or input at will, then it's already great. Great, in the sense more than most people would ever need. In terms of actual usability, it's passable at best. And such "API" would be PITA to code against, especially something more than a throwaway script no one except me will ever use.
Cocoa apps have their UIs defined in .xib's, UI Builder files, which are loaded on the fly. (You can build your UI programmatically, but it's pure masochism FWIW.) This gives program windows something not entirely unlike DOM, and that is good for a generic programmatic control.
If you need it better, a program must have its meat in a library, or in a machine-programmable backend (like a CLI launcher you can pass parameters to, or an IPC scheme) which gives you a higher level semantic API or something. Guess not many applications are programmed like this; lolcat apps are not, for the most part. Stock OS X utilities usually have command-line twins, or are using CLI tools as their backends.
-
Does it make any difference to people?
This tells me that you're not a competent GUI programmer. Goodbye.
-
The answer is yes it does.
I thought so, as I very much doubt readers would have to resort to OCRing screen contents in '95, though I don't know the implementation details; I'm not a Windows user. I know for sure GTK+ on Unixes has that too (and Qt, of course, as a given). Can't say anything about Java's Swing/SWT.
-
All those tiny details that I have never seen actually documented anywhere and that average users don't notice themselves most of the time
But they get really damn used to them, subconsciously. What does it mean I can't do it in your program? What does it mean you have your own half-ass font chooser? Things have always been like this on my damn computer! Fuck you and your lame software!
-
Swing/SWT
Swing looks god awful everywhere but if consistency is what you're aiming for it's quite good. It's the same god awfulness everywhere. I've never put much stock in the it's not pretty argument though. A: you can skin it however you like. B: my opinion should be discounted because I'm on win7 still rocking winxp theme. I don't care about how it looks as long as it's functional and not unnecessarily complicated and drawn out.SWT just wraps OS widgets. So if there is something idiotic in the OS widget you can bet there is 2000 lines of code in SWT to replicate that behavior in a custom widget.
I can't comment on javafx. The places I've worked are not hip enough to use that new fangled technology.
-
Swing looks god awful everywhere but if consistency is what you're aiming for it's quite good.
The question is "can I make an external program invoke a dialog and click a button in a Swing program without having to manipulate the mouse cursor?"
-
@DogsB said:
Sorry, I've overlooked that. I very much doubt it.Swing looks god awful everywhere but if consistency is what you're aiming for it's quite good.
The question is "can I make an external program invoke a dialog and click a button in a Swing program without having to manipulate the mouse cursor?"There are testing and automation frameworks that will do that for you but the skullfuckery involved to get that working externally is not worth the hassle. I think swt stuff is clickable with tools like AutoIt though.
-
Sorry, I've overlooked that. I very much doubt it.
If the application is built around
Actions and they've been exposed right, then for sure, you can do it. But some applications just decide they're going to go straight to doing their own thing from the ground up, and then you're left with synthesising raw low-level events as the only way in.
-
Raymond Chen has a whole series of articles on how to make use of those APIs, both as a maker of assistive tools and IIRC he had some handy things some normal non-assistive-tool apps could do with them as well.
Part of the problem on Windows is that so many applications are made with shitty frameworks that don't use native controls, so those APIs don't work. I used to bitch specifically about that IM program I can't remember the name of written in GTK+ and how NONE of the features of my tablet PC worked with it because they didn't use any native controls.
And think of how much work Mozilla has done, over the years, to get their fake-ass controls to behave like actual native ones. Why they never just threw up their hands and made them native, I don't know. But at least Mozilla put in the work; GTK+ never fucking bothered.
-
And think of how much work Mozilla has done, over the years, to get their fake-ass controls to behave like actual native ones. Why they never just threw up their hands and made them native, I don't know.
They are native under several layers of hoods. The gfx framework calls to a platform-specific class which calls the native toolkit. Also, they use GTK+ on Linux, and it works with assistive features there (ATK/AT-SPI2).
GTK+ on Windows didn't get enough workforce to support whatever there is (MSAA, I reckon?).
Anyway, truly cross-platform applications have their UIs written separately for each platform. If you go the lazy route, the app is going to run on all platforms, and to look and feel like shit on all of them.
-
Anyway, truly cross-platform applications have their UIs written separately for each platform. If you go the lazy route, the app is going to run on all platforms, and to look and feel like shit on all of them.
A.k.a., the HCF of cross platform framework UI, when we talked about Java applets in early Y2K.
