Solving vs managing problems
Posted 2019-07-15
Blog
Articles- terminal.d gets clipboard functions, ldc 1.20 out.
- DConf keynote speaker announced: Lua architect Roberto Ierusalimschy, Named args DIP discussed
- February 3, 2020
- Adam's terminal suite explained
- Understanding mixin templates, terminal.d improvements
- My attribute-by-default proposal. Also dmd 2.090 came out.
- DConf 2020 announced: June 17-20 in London. @safe by default debated. Adam did: Android, JNI, WebSocket in arsd libs
- tar.xz, --DRT tip, dom bug fixes, more Android and JNI, link to old phobos docs
- LDC 1.19 - Android, AVR. My rant on tests, update on JNI and COM.
- Walter's string interpolation proposal is OK but not great. My Android thing nearing beta release. dub downtime explained.
- Android project update, introduction to arsd.jni
- New pattern about interface contracts
- Adam shares Windows console secrets - DO NOT USE chcp!!
- Adam's rant on benchmarks
- Socket tutorial
- November 4, 2019
- October 28, 2019
- arsd package updates, forum nonsense
- Update on Android
- Adam does iOS "goodbye world"
- September 30, 2019
- D turns 20, Adam rants on software freedom
- Named arg DIPs and my thoughts on code organization
- September 9, 2019
- I wrote about mixin templates vs string mixins on Stack Overflow
- August 26, 2019
- Bug bounty in D again - my hot take, on reusing code, a fun picture, my tentative plan for the next month
- Time invested is worth a lot
- cgi.d's new scheduler, static this tricks
- July 29, 2019
- July 22, 2019
- Solving vs managing problems
- A big week in the arsd repo
- July 1, 2019
- June 24, 2019
- June 17, 2019
- CRTP thoughts, named arguments DIP review, DConf videos now on youtube
- musings on hybrid CT/RT tests, some more progress on new web framework
- a little more webassembly
- May 20, 2019
- Adam's string interpolation proposal
- DMD 2.086 live, GCC 9 with D support formally released, DConf coming soon, links to posts on builder pattern and disallowing implicit conversions with templates, and 2d array op overloads
- template constraint error improvements coming?
- dmd 2.086 beta, dstep 1.0 released, Adam works on memory usage
- obj-c and webassembly report, tips on is expressions linked.
- new ldc, new dmd, dpp on the blog
- D's future discussed in forums
- LDC beta, DConf blog link, Adam introduces gamehelpers.d
- March 18, 2019
- LDC 1.15.0-beta1, responsive design rant
- dmd 2.085.0 released
- Obj-C interop and D without druntime code to copy/paste
- dmd beta, more info coming next time, demo of new web framework initial prototype
- automatic web interface discussion, reflection tips and tricks
- Adam busy with weather and a move, lots of community announcements
- January 28, 2019
- Working on official blog 2018 retro, C++ new wrapped, dmd reading zips?
- dmd obj-c growing, Adam static foreaches an interface to RPC
- dmd 2.084, hope for future, but busy non-D week for me
- IDE tools released, my cgi.d gets new features
- DConf announced, tip, Adam rants: mouse trap
- This Week in D is back!
Not much time to work on D this week. Got some open source contributions, but mostly the free time was spent elsewhere. This next weekend, I'm visiting family so don't expect much then either.
But that said, I'll write a bit on solving vs managing problems and metaprogramming today.
Core D Development Statistics
In the community
Community announcements
See more at the announce forum.
Adam's thoughts - solving vs managing problems
I like to draw a distinction between solving problems and managing problems. When a problem is solved, you don't have to worry about it anymore. By contrast, when it is managed, you can move on... but the problem will require ongoing work to manage.
For example, in most dynamic languages, you manage the problem of variable name typos crashing a production system. With unit tests and the sort you can prevent this problem from stopping you, but these solutions must be consistently used going forward; tests need to be continually updated and run, or the problem creeps back in.
With a static language like D, however, the problem is solved (well, except in templates, but even there, it is impossible to ship a broken template to a production system) - thanks to the compiler being an intrinsic part of the system and it including these checks across the entire program, you don't have to worry about it getting to production.
I confess there's a bit of a grey line here - is running the compiler really more of a solution than a CI test and deployment system? Well, it can be a judgement call, but I'd say anything where you have to specifically think about the problem in the future tends toward managed, and if not, tend toward solved. This might change based on your perspective too - a vendor managing a problem might solve it from the perspective of their client, for example.
I'd argue that a programming language ought to aim to solve as many problems as it can, and provide mechanisms to manage the rest. D does a generally good job here, and this is where I feel D's metaprogramming is unique.
D's metaprogramming and solving problems
Lots of languages have some form of reflection and method generation, and the associated syntax sugar to make it work fairly well; you can do a lot of cool things with it.
D has all this... plus integration into the language's mandatory static checks. With the type system plus user-defined constraints and static asserts, you can solve many classes of problems of incorrect code getting live. If you want to add methods that fit particular names, you can do that, easily, with opDispatch. If you want only a particular combination of types, you can check that and abort the build if it isn't good enough.
Then, of course, you still have various tools to manage problems it cannot solve like unit tests, asserts, contracts, and, of course, other startup or runtime exceptions, but those are relatively common. (Though D's startup tests are a step above many languages, I'll write about that another time.)
All this can lead to a new problem though: potential compile time growth. And alas, all we can do is manage that one, but it can be managed, so not the end of the world.
But overall, D is strong at solving problems other languages only manage, and that is part of why I have found and continue to find so much success using it for so many years.
A minor, tangential wish
I sometimes wish we could transform existing types though. Like @transform struct Foo {} would actually generate a different Foo than the one we see in the code.
Of course, mixin templates can kinda do that... but just kinda. They still have to work with the names already there.
What I will sometimes do is something like:
which removes the tailing underscore. But I don't love it.
So I kinda wish we had some syntax sugar there, even if it is just more easily passing anonymous structs. You can sorta fake it with string mixins however, but meh. And the documentation of these things can be non-obvious. Just another problem to manage :)