Comment by tolmasky
11 years ago
Theres tons of successes, we just refuse to count them. Photoshop (as hinted in the article), is a super special purpose language for doing image operations. It no longer "looks" like coding, so we don't count it as coding for the masses. Excel is a much more general purpose language used by tons of "non-coders" (and arguably the most popular programming language on earth). Again, doesn't (often) look like normal programming, but then again, shouldn't this be expected? If it looked like normal programming, it would be normal programming and not successful.
Excel is a perfect example. The core Excel experience is basically functional programming on a virtual machine with a matrix address space laid out visually right in front of you. It even looks like traditional programming if you dive into the VBA stuff, which plenty of non-technical specialists, including MBAs and managers, do on a regular basis in the pursuit of solving their problems.
Any specialist user willing to invest some time in learning their tools can do this. A culture develops around it.
And replying to parent: those efforts around teaching 'civilians' to code are probably misguided. The investment needs to be in adding scripting and programmability into existing line of business tool, not on encouraging people to sit in front of an isolated REPL disconnected from any business value or context.
+1; many companies have tons of internal processes which rely on Excel sheets. When these become painful enough, another team (internal applications) can come in, evaluate the situation, and build out a custom solution which uses an actual database, but Excel still provides a ton of value, since at the most basic level it's a database table with no validation and a free-form schema.
The downside is, when all you have are Excel sheets, everything looks like rows and columns (and not e.g. objects with behaviors). If Excel had more robust import/export mechanisms that normal users could understand (e.g. built-in REST client with JSON + XML serializers + many database adapters w/ lots of helpful wizards or tools to guide you), it'd be way more powerful. Then again, if someone is at the point where they'd be able to look at some JSON and compare it with their spreadsheet and be able to describe the mappings, they're possibly better off going to some training sessions on ${your favorite programming language} to learn how to do this the easy way.
Nicely put. It's actually rather agile: Excel becomes a prototyping tool to allow the business users to describe what a solution looks like, helping to guide development of that custom solution. Sadly few IT organizations are confident enough to trust their users and work like this, instead starting from zero with a pedantic requirements gathering process before building something less flexible and useful. The problem is partly a lack of domain knowledge in the internal apps team (which is understandable), and partly a kind of technology-first arrogance which prevents that team from making use of the intellectual capital originated by the business in their spreadsheets and processes (which is inexcusable really).
Ideally, an organization comes to understand that Excel is a fantastic tool at the frontier where the business needs to adapt rapidly, but once a process is fixed, replacing it with a fixed system is worth the tradeoff in reduced operational risk.
To your second para., much of that falls to internal apps to provide decent RESTful APIs across their systems. Some companies are doing this, in the process getting to a point where the Excel frontier is just analyzing and reporting on data, not acting as a source in its own right. Then you have traceability for every data point in the organization, and you're in a pretty sweet spot operationally.
Something can't be "basically" functional programming without first-class functions.
It seems more like a non-functional declarative vm to me.
It's more a one-way dataflow language.
Thanks to John Foreman's book "Data Smart" I now regularly test small-scale machine learning problems in Excel. Sure, a developer will translate the end result to scikit-learn or AzureML, but this is stuff that's easily available to even mildly-technical enthusiasts.
Two other more contemporary examples are the Android app Tasker, and the website IFTTT ( https://ifttt.com/ ).
There's something about calling it programming that turns certain people off. I remember a story about a freshman in a physical mechanics class that complained about all the MATLAB code they had to write. The professors retort was that they were free to use a slide rule instead, and that particular freshman stopped complaining.
But you're right. The mere act of calling it programming is somehow a problem. It's as if doing programming pigeonholes you into being a programmer until the end of days.
> The mere act of calling it programming is somehow a problem.
There are some words that carry with them unshedable connotations that people want to get away from so strongly that they will call themselves something else at the first possible instant. "Programmer" is one of them.
"Poet" is another. No one makes money from poetry because as soon as a poet makes money they are something else: a musician, a performer, a copy-writer, whatever.
Just don't call them a "poet", because "poets" are poor, sad people with no future, just as "programmers" are neckbearded nerdboys who smell bad, and no matter how many programmers (or poets) fail to live up to those stereotypes people will continue to impose them on reality come hell or high water.
Until one shoots out the top. Then he/she can be a "poet" again.
Kind of like how calling programs for proofs seems to make most programmers uneasy. (Not that most programs that you'll run into are proofs in any interesting sense.)
I concur with your assesment. The point is not to turn a syntax into an AST into processor code. The point is to provide things of value and 'easy' computing platforms targeting users who are not professional programmers create tremendous amounts of end user value.
Sadly, when I point this out professional programmers often go 'pffft - that's not real programmming' as if being knees deep in stack traces and gigantic code bases was a something with intrinsic value.
I'm not sure I agree with you about Photoshop. Perhaps (probably) there are photoshop macros or pipelines that are closer to programming, but most people use Photoshop purely in an interactive mode. They enter commands directly, and the logic stays in the users' heads, not in the computer.
Photoshop is more like a REPL tied to an image-processing library than it is a programming language.
A Photoshop "program" would consist of the composition of image layers, adjustment layers, blend modes, styles, masks, text blocks, shapes, paths, and so on. You "run the program" when exporting to a bitmap format.
It probably doesn't help to think about it that way when using Photoshop, but it might be a useful mental model for developing Photoshop, or as an example of how a general visual programming language UI might work. Importantly, Photoshop does not give you a bunch of little boxes with arrows crisscrossing everywhere like all the clumsy and disappointing visual programming experiments I've seen.
Maybe "visual programming" is like "AI". Whenever you make something that actually works, it goes by some other name.
Sometimes the boxes-and-lines metaphor for creative design is what you want... professional video products work like this:
https://www.blackmagicdesign.com/ca/products/fusion
It's like After Effects meets Simulink.
Maybe. But by that standard, using a Xerox machine is programming because you can layer some pieces of paper and transparencies together and then copy it onto an image on a single sheet.
I think to be programming, there has to be some kind "logic" (conditionals, mathematical functions, loops, etc.) embedded in the structure (cf. https://en.wikipedia.org/wiki/Jacquard_loom) and I'm not sure Photoshop qualifies.
3 replies →
Re: pipelines, you can feed external data into a Photoshop doc [1]
[1]: https://helpx.adobe.com/photoshop/using/creating-data-driven...
Remember when search engines had Boolean operators?
Honestly I never heard of search engines working with boolean operators.. I just did a quick search and found this interesting article which gives information about websites using AND, OR, NOT, venn diagrams and concept declarations to deacrease the search node graph....How long ago this search mechanism terminated ???
I... you're trolling, right? Before Google rose to fame, Altavista was probably the most popular, but in order to find what you wanted, you frequently had to add AND, and NOT to your searches, and still needed to dig in a dozen pages in order to find what you were really after. Then Google came along, and the rest of them died.
4 replies →
I would say that Photoshop is a toolbox of predefined tools. If using that is coding, then people are also coding when they choose and use a screwdriver, some sandpaper, a hammer and some glue in succession from their physical toolbox to get a job done. That the operations happen electronically and that they are implemented as complex mathematical transformations of pixels doesn't change that.
Excel isn't much different in my view: most people are only using a very limited set of predefined tools to get a job done. Often badly: it is well known that there are many bugs in important, company critical Excel sheets. Excel seems like coding because it is mostly used to perform the fundamental mathematical operations we all associate with coding. But if that is coding, then so is constructing a Rube-Goldberg machine for a specific task from the parts you happen to have available. A nice exercise in problem solving under constraints. Which certainly has something in common with coding. But that doesn't make it coding.
Using Photoshop is instructing a computer to perform a series of operations, necessarily fairly high level ones, but conceptually not that different from text-based coding. I agree it stretches the definition pretty thin: where's the control flow? Conditionals?, but are those things really foundational characteristics of programming languages or are they simply the equivalent 'predefined tools' that, say, C gives us?
Excel is much closer to traditional programming: it's basically a purely functional language (absent VBA), but instead of a linear description of the program in a text file, you're in effect embedding functional code inside a virtual machine's memory.
EDIT: I suppose an important question about Photoshop is, can you do computation in it?
So, Excel is not coding, but an Excel sheet can have bugs?
Yes, just like a piece of furniture you built can have bugs
Well, if you wanted to be absurdly pedantic, you could call instructions in an architecture predefined tools, or protons and electrons.
I don't think it matters if the tools are predefined - what matters is that they can be used together to build a system greater than the sum of it's parts.
Yes, and that is exactly what very rarely happens when people use Photoshop or Excel and happens in coding all the time. Which isn't strange, because the former two aren't intended for that, while the latter is.
I think it can matter a lot whether the tools are predefined, because the exact nature of those predefined tools determines whether they are easily composed into something greater than the sum of its parts. You need iron ore, wood and a forge to construct a different hammer. Of course you can cobble something hammer-like together with the tools in your toolbox at home, but it won't be like the hammer forged afresh from more fundamental parts better suited for that purpose.
Yep, great examples. Also, pretty much any experienced Photoshop user will create their own actions to automate common operations. And then you have things like workflows in Alfred.