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…
Problems with DSLs for non-programmers
101–110 of 144 posts
Re: Problems with DSLs for non-programmers
#102Re: Problems with DSLs for non-programmers
#103Unlike 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
#104Earlier 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…
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
#105Re: Problems with DSLs for non-programmers
#106Earlier 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…
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
#107Earlier 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.
Re: Problems with DSLs for non-programmers
#108Re: Problems with DSLs for non-programmers
#109The 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.
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.