Live data from Hacker News

Problems with DSLs for non-programmers

artur-martsinkovskyi.github.io

101–110 of 144 posts

Re: Problems with DSLs for non-programmers

#101

Earlier quoted context omitted.

Yep. But they're overused and underused each day... Everything can be a spreadsheet and nobody questions if there are better ways of holding that particular data

The issue that I've seen with Excel is that it's often seen as the hammer -everything is a nail- for people that are less inclined with technology / set in their way. They will use it both as intended, a spreadsheet for calculations, usually for reports. But also as publishing software (think InDesign) and format their spreadsheet to look like an invoice / quote, a hand made Gantt chart (yeah with arrows as delimiter…

Dan Bricklin himself said in an interview (I think this one [0]) that when they created VisiCalc (the first spreadsheet program) with Bob Frankston, they designed it to mix data and non-data. It was entirely part of their vision of a malleable information space. Of course at some point of using it for everything any tool become the wrong tool, but most of the time users creating sophisticated layouts in a spreadsheet actually use the spreadsheet as intended in the original, powerful vision of its inventors.

[0] https://www.youtube.com/watch?v=ryIxvrX4lyk

Re: Problems with DSLs for non-programmers

#102
"In the end when the serious stuff comes in it was always a better choice to hire someone who really understood what he was doing." - I know this is a side point, but it makes it very hard to engage with articles when their use of gender pronouns deliberately excludes you from being 'someone who understands what they are doing'. I understand that this is often accidental, but in 2019 I'd like to think people would be more careful about excluding a marginalised group in software.

Re: Problems with DSLs for non-programmers

#103
I'm surprised no one is talking about React JSX. I'd be very interested to hear the authors opinion on it.

Unlike the author's examples, JSX isn't intended to be used by business people, but I think JSX presents some of the same problems but instead with regard to web designers. JSX is a DSL that was intended to help simplify and streamline the process of building a web app, but the leakiness of JSX as an abstraction prevents anyone less than a full front-end engineer from working effectively with React.

Re: Problems with DSLs for non-programmers

#104
post #67

Earlier quoted context omitted.

What is the criteria you use to determine they’re successful? If you have an interactive debugger and a way to test the code, I could see it being feasible. If not, then there’s plenty of examples of DSLs that are in use that people are forced to use and squander time and brain power due to a lack of concepts that real languages have long since addressed. Since others have mentioned Excel, how many mistakes have been…

> ...how many mistakes have been made... It actually doesn't matter. Yes, we can all agree that Excel is a dreadful interface for a programmer. But programmers don't use it for things better done otherwise. The people using it are not programmers. If you suggest they try to accomplish their ends in more sophisticated language, they look at you with wide-eyed horror. Every moderately-sophisticated Excel document writt…

You could innovate and make spreadsheet debugable, or allow comments.

The argument that users don’t want a way to know what the logic they’ve created does is taking the point of view the users are idiots and don’t know any better rather than the developers aren’t thinking about how people are to reason about problems. If anything it’s the fault of the developers for not thinking clearly about how problems are solved in general and are locked into thinking in terms of their computer’s existing poor approximations of reasoning.

Re: Problems with DSLs for non-programmers

#105
I don’t necessarily agree. I have worked with financial analysts using Excel, SQL etc. quite proficiently. In fact, I am told that familiarity with DSLs used for data analysis/manipulation tools is considered a part of the job description by many companies nowadays.

Re: Problems with DSLs for non-programmers

#106
post #67

Earlier quoted context omitted.

What is the criteria you use to determine they’re successful? If you have an interactive debugger and a way to test the code, I could see it being feasible. If not, then there’s plenty of examples of DSLs that are in use that people are forced to use and squander time and brain power due to a lack of concepts that real languages have long since addressed. Since others have mentioned Excel, how many mistakes have been…

> ...how many mistakes have been made... It actually doesn't matter. Yes, we can all agree that Excel is a dreadful interface for a programmer. But programmers don't use it for things better done otherwise. The people using it are not programmers. If you suggest they try to accomplish their ends in more sophisticated language, they look at you with wide-eyed horror. Every moderately-sophisticated Excel document writt…

When an Excel document grows enough legs, just sometimes someone will decide that it's useful enough that they should build a proper service to replicate its functionality. That's the point at which so-called "real" programmers want a debugger in Excel: because someone with talent but lacking experience has built a monstrosity that now needs to be properly replicated and made maintainable.

Especially when the original developer's manager starts asking pointed questions about how their one "non-programmer" could build something in Excel that then takes a whole team ten times as long in a proper programming language.

Having a debugger available to help reverse-engineer the spec would be really useful.

Re: Problems with DSLs for non-programmers

#107
post #73
post #12

Earlier quoted context omitted.

Anyone who thinks DSLs for the general public can't work has never used Excel. The real trick is creating a domain model that "clicks" in the heads of your users.

The counterpoint would be Visual Basic. It was meant for non-engineers/managers to be able to write programs, but that never really happened. It was always easier for a manager to write an email 'I need an app that does X' than to write the app themselves.

This is exactly right

Re: Problems with DSLs for non-programmers

#109
post #12
post #8

The argument here boils down to: I haven't seen it work in places where I've been employed so it must not work. Reality check: I've worked on multiple large research teams that successfully developed DSLs still in use by domain experts -- military sigint in one case, doctors in another case, industrial engineers in another. We developed these languages for specific applications where the domain experts needed to prog…

Anyone who thinks DSLs for the general public can't work has never used Excel. The real trick is creating a domain model that "clicks" in the heads of your users.

> Anyone who thinks DSLs for the general public can't work has never used Excel.

I would say Excel is exactly the opposite of a positive example. Unless you mean being used as a sort of electronic scratchpad, which works okay.

But apart from that there's too much freedom in Excel to be used to make anything properly. Every time I've ever seen a non programmer use it, they make a pile of spaghetti. You never have any assurance that you're actually calculating what you want.

Even highly qualified domain experts (eg in derivatives trading) will end up building utter nonsense in Excel, and then use it to trade millions of dollars worth of exotics. Whenever they need something fixed, it takes an enormous effort to trace through all the cells to make sure things are correct.

Post reply on HN