8 ms·
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 re
by ghc 7y ago
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 program extremely complex systems to perform tasks in much shorter timeframes than would be possible if programmers needed to get involved.
Why did these DSLs succeed? Funding, manpower, and experienced project managers who delivered constant access to domain experts.
Delivering a successful DSL targeted at narrow domains with non-programmer users is much more resource-intensive than normal software--it's more on the complexity level of a compiler or small OS--but that doesn't mean it can't or shouldn't be done. Plenty of systems couldn't be automated otherwise.
- zwkrt 7y agoAnyone 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.
- christophilus 7y agoI came to say that exact thing. Good DSLs are almost unnoticed, because they are frictionless.
- sligor 7y agoGood DSL are hard and expensive to design and maintain. Look at the good example of DSL in comments here. They are not small project with small workforce. If not very limited, a DSL is an ambitious project (if very limited a GUI will surely do a better Job). Developers should think twice before writing a DSL for "non-programmers"
- hhas01 7y agoNonsense. Making a good DSL is easy. I’ve built production DSLs that users adore. What’s hard is finding developers who know the domain and its users in the first place. You can’t solve a problem if you don’t understand the problem space. And most devs don’t understand shit except how to turn it off and on again, nor are they willing to learn. So if your average professional university-educated programmer can’t even get a simple turnkey CRUD app right, what chance of them delivering a tool that successfully hands those keys to its users? .. Go read the “Collaborative Work Practices” chapter of “A Small Matter of Programming: Perspectives on End User Computing” by Bonnie A Nardie that describes how basic users, expert users, and trained developers can develop their own software tools together, where each layer supports and educates the layers above and below it. And then count the number of programmers you know who’d embrace working like that. Sadly I doubt you’ll run out of fingers.
- snarfy 7y agoThe 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.
- ethbro 7y agoThere's one key I've seen to DSLs that really work: scope your DSL with iron. You should be able to clearly say 'This DSL can do X. It cannot do Y.' (Then, if Y sometimes needs to get done, provide an escape hatch integration point to C et al.: but don't ever expand your DSL beyond the domain!)
- zwkrt 7y agoYou can see this with how VB became much more monstrous and complex as soon as they tried to shoehorn in a multi-table paradigm.
- ethbro 7y agoI think later-legacy-VB (eg 6) suffers harshly from failing to properly separate primatives. Imho (open to disagreement), one should think incredibly hard before adding primatives to a DSL. Because what that's essentially saying is "My abstraction was incomplete over the target domain, and now I'm going to hack something in." And now you have a "domain + some other stuff" language, which starts to look like a general purpose language. SQL vs VB is an excellent example of focus. (Although I do think VB.net added sanity back to the mix, by saying more clearly "These are VB things" and "These are .net things", and if you want to do the latter in the former, just make a library call)
- quicklyfrozen 7y agoI saw VB6 used by many non-programmers. It often wasn't pretty, but got the job done (helped in no small part by a rich ecosystem of COM/ActiveX components).
- marcosdumay 7y ago
- njharman 7y agoThe technical public. Huge percentage of the general public can't effectively use excel, let alone write code for it. To be clear by technical public I mean much more than just developers. Like everyone that could get a basic stem degree whether they have one or not.
- Semiapies 7y agoI wouldn't go as far as that, but yeah. Adding up a column is not the same as actually coding in Excel or even using a few math functions in a cell. And considering how many people take classes just to handle the basis spreadsheet functions, much less anything complicated, the naive accessibility of Excel can be overstated. I've never tried to make a DSL for non-technical people because every single time I've seen a client get an expensive product aimed at their industry and designed to "not need a programmer" to customize, they end up paying to have me or a coworker to not-program customizations for them in an excruciating interface. On the other hand, I think a lot of this side stems from insistent terminology in treating programmers like some tiny priesthood separate from the general public. That woman who can actually put together fairly complicated SQL queries? She has learned to program in SQL. That guy who put together a ramshackle VBA atrocity that gets the job done? He has learned to program in VBA. All the mess comes from not accepting that. No DSL or templating interface or whatever will let people do programming without learning how to program to some little extent. Acceptance fails when the "public" doesn't want to give/can't spare the time and effort to do so. On the flip side, when it doesn't fail because the "public" does work to learn to program in some case, developers take that to mean that this can work in any case, so long as the public is approached properly with the right DSL/graphical environment/etc.
- derefr 7y ago> designed to "not need a programmer" to customize > they end up paying to have me or a coworker to not-program customizations These things aren't contradictory, though. The software doesn't need a programmer to customize. They likely tested that, and proved that regular people can set it up just fine. Regular people just aren't normally motivated to do so, when it's so easy to just spend money in order to not have to learn something new. IMHO there's a clear division that forms between people very early in life, and it can be predicted which side of the line someone falls on as early as the third grade: there are humans for whom solving puzzles that involve "wrapping their brains around" a new mental skill is a fun diversion; and there are humans for whom that same experience is aversive and something they will flinch away from. And—importantly—this has nothing to do with how good they are at doing it! We can endlessly invent new ways to make hard things easy, but no matter how easy we make them, as long as they're at all novel or unfamiliar, the people for whom absorbing new mental models is an aversive experience will just do everything they can to avoid it. It's like people with social anxiety doing way more work of some other type to avoid socializing, but with "forming new mental connections" in place of socializing. But the fact that a large part of the population is like this, doesn't mean that there's no value in these customizable systems. They still increase accessibility, bringing tasks that were impossible for a non-programmer into the realm of possibility! It's just that for most people, the line isn't between "possible" and "impossible"; it's between "trivial" and "not worth the trouble." The question only becomes one of possibility when you're forced into a corner of solving the problem yourself, no matter what, unable to even quit and walk away. When people are in that situation, they're thankful for these systems. But only then.
- lordnacho 7y ago> 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.
- coldtea 7y ago>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. That's just developer snobbism. Millions non-devs use Excel with excellent results, even whole business of billions depend on it. (Excel has some flaws, and can give wrong results in some cases, but that's like "gotchas" in any language).
- IshKebab 7y agoI don't think it is snobbishness. Some programming systems definitely encourage hacky spaghetti more than others (if you don't believe me try using LabVIEW) and Excel is definitely in that category. There are ways that they could make it less so, like only allowing cell references by name, using a saner scripting language than VBA, allowing multiple cell grids on a single page/sheet, etc. "Millions of successful businesses are built on Excel" is no argument at all. You can build a successful business with pen and paper.
- scroot 7y agoOr Hypercard, which was popular among non-programmers in its day
- taeric 7y agoThere is a great article that explained how an entire office was comfortable with LISP because it wasn't pushed as programming. First hit searching shows it linked off of: https://www.reddit.com/r/emacs/comments/3tj71x/even_office_secretaries_learn_lisp_why_do_the/ https://www.reddit.com/r/emacs/comments/3tj71x/even_office_s...
- dajohnson89 7y agohighly technical domain experts are not quite general public.
- azhenley 7y agoIs any one person the general public? No one is the average.
- cpach 7y agoI wouldn’t say that doctors are necessarily technical (when it comes to software).
- accnumnplus1 7y agoCasual conversation I had with a top surgeon trying to login to an account: me: It's case sensitive - you need a capital letter. him: How do I do that? me: Hold down the shift key. him: Where's that?
- cpach 7y agoHaha! I’m not surprised :)
- ethbro 7y agoEveryone has to admit there's a lot of programming minutiae that could and should be thrown overboard. If you show your language / app / webpage to someone and they ask "Why is X preventing me from doing work?", it would behoove all of us to honestly ask ourselves "Is X important enough that we should keep it?" Otherwise, we end up with 10,000 gotchas and only someone who studies for 2 years can use things. And I'd personally much rather that surgeon be studying medicine for those 2 years!
- wool_gather 7y agoWhich is a different way of saying that most computer UI still sucks for most users. I agree, and I think that one of the key reasons programmer-y people are successful at navigating computer tasks that stymie the proverbial grandma is this: faced with a question about how to accomplish a task inside some UI, we're just inherently more likely to follow a similar train of thought as the person who wrote the program in the first place, and reach the correct conclusion. (And case-sensitivity in a username is exactly the kind of keen (textual) detail that we're both wired and trained for.) In other words, we're just iterating on trying things [as xkcd observed][0]. The key is that inside that first decision box, locating an action to try, we have a huge leg up on the "...which looks related to what you want to do" part. I sometimes describe this as "knowing how computers think", but really it's knowing how the people that wrote the program think. Not that it's an easy problem, but I think we still have a lot of work to do as a field, to make stuff accessible to people whose brains don't follow the same patterns as ours. [0]:https://www.xkcd.com/627/ https://www.xkcd.com/627/
- twa927 7y agoAre such successful DSLs described somewhere? Generally my feeling is somehow similar to the one expressed in the blog post, ie. that DSLs don't work for non-technical people. If someone is able to use a DSL then he/she is also able to do regular programming, and many people don't have such abilities. And regular programming languages are better tools for the ones with the abilities.
- ethbro 7y ago> If someone is able to use a DSL then he/she is also able to do regular programming, and many people don't have such abilities. I'd disagree with this characterization. Because a good DSL abstracts away things that are not relevant to the domain (e.g. in Excel, memory pointers and allocation) while retaining those that are (which data transformation you want to apply). It doesn't follow that someone who understands the concepts in the DSL must also understand the superset of all regular programming concepts. Hell, most Java coders couldn't even write a memory manager from scratch! Which is exactly where their power comes from. Because each time you shrink the required knowledge to do work, you broaden the pool of people who can perform that work. > SQL is used widely, but it does not work that well for people who are not programmers. Is the key phrase that shows the author has no idea what they're talking about. I can count 20 analysts, off the top of my head, that I personally interact with on a weekly basis at work that disprove the point. They have incredibly deep knowledge of their particular datasets. They know more than enough SQL to produce efficient queries for their needs. And they wouldn't understand exception chaining if it bit them in the ass. But they still run their part of the business better than I would. Author is making an "anything shy of perfection isn't worth doing" claim, which misses the forest for the trees. The objective of programming (DSL or otherwise) is to get work done. Not to be ideologically perfect. Which is one reason Python is wildly successful, despite all its Oops design bits. > (In author's defense of DSLs) There are AWK, RSpec, EJS, Emacs Lisp, bash scripts and a lot of others that are cool because their domains are steady and they are used by professionals. The pompous twit... so data retrieval isn't a steady domain and business analysts aren't professionals?
- davps 7y ago> Because a good DSL abstracts away things that are not relevant to the domain (e.g. in Excel, memory pointers and allocation) while retaining those that are (which data transformation you want to apply). I agree, I wrote this small example on using DSL for E2E testing, where you abstract away a lot of asynchronous calls, headless browser specifics and other low level concepts to expose a simple API so domain experts can help you to write tests https://github.com/davps/tic-tac-toe/blob/master/src/App.test.feature.calculateResults.js https://github.com/davps/tic-tac-toe/blob/master/src/App.tes...
- hyperpallium 7y agoThey became programmers... To use a DSL without becoming a "progammer", by virtue of that fact, it needs be non-programmable: non-Turing equivalent (at the very least).
- scarface74 7y agoI would actually go as far as saying Basic good enough SQL is easy to teach to people. You can make it easier by creating views for them.
- argd678 7y agoWhat 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 made in long complicated formulas in little tiny input boxes with no way to comment or even explain what on earth the formula calculations are doing? Yet that’s still not addressed, and it’s a nightmare when you come across complicated spreadsheets for this reason.
- wyattpeak 7y ago> ...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 written by a "non-tech" person is something which would previously have required either the endless back-and-forth of a middle manager trying to explain a poorly thought out spec to a programmer or, more likely, simply have been done by hand till the end of time. Maybe it could have been better accomplished by that middle manager learning a real language. But it's neither here nor there, because that was never going to happen. Excel, for all its faults, actually convinced people that they could build simple programs (by pretending they weren't). That is the criteria by which it is successful. The question I'd ask is: why do you think it's important that all of these features be included? Why should it have a debugger? The people using it don't want one - make it look any more like programming and they'll go back to asking IT. The people who'd appreciate a debugger - they aren't programming in Excel. Who is served by making Excel a more sophisticated language?
- argd678 7y agoYou 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.
- philwelch 7y agoThere are important differences here. One is the level of engineering effort, but another is the nature of the user of the DSL. Doctors, engineers, and SIGINT specialists are all types of people who are accustomed to doing some type of specialized technical work themselves rather than depending upon others to do it for them.
- whateveracct 7y ago> experts needed to program extremely complex systems to perform tasks in much shorter timeframes than would be possible if programmers needed to get involved I always think of DSLs as automating my own job as a software engineer. It makes it possible to have someone with a different skillset than me not need to go through me to build features.
- acapybara 7y ago> I always think of DSLs as automating my own job as a software engineer. It makes it possible to have someone with a different skillset than me not need to go through me to build features. It's interesting that this sort of drives against our own motivation of professional self preservation. In my own experience, it has generally worked out better to just empower others as much as possible, rather than trying to lock down and add friction and permission to the system. It's a great feeling to give someone the power to do something they couldn't do previously.
- gpsx 7y agoMatlab - That was designed for engineers who are not experts in software, even if they were highly technical.
- vbezhenar 7y agoAre those successful DSLs just texts with editor UI? Or they are something like block diagram?