@b3m2a1 That was interesting to watch. I just skimmed it, but it seems (at least currently) that the problem with Total[a*b]=> a+b is simply that it should output an error message for the missing curly braces, rather than a result, right? But, in the future, is the idea that you could use Total without the braces by adding the option AllowedHeads->All? Seems easier to just use Plus (which doesn't require the braces) in that case, but perhaps there are instances when Plus is problematic.

@theorist the issue is that Total wants to thread over every possible head, where it should only really work with properly iterable types like List, Association, and the array types.

Plus would require an Apply call to imitate Total and doesn't have the flexibility of the two-argument form. Also Plus will still have the problem that Total does if applied in that way.

Of course I think @HenrikSchumacher found that multi-argument Total isn't optimally implemented anyway...

Thanks for the quick reply. I was thinking of instances like the problematic example given above, for which you wouldn't need an Apply call to get a total from Plus (e.g., Plus[a*b,c*d]== Total[{a*b+c*d}]) but, of course, that only works for the simplest cases.

edit: Plus[a*b,c*d]== Total[{a*b,c*d}] (I often use the former to save typing)

@halirutan Not me.

@Kuba No time to check now, but would that work with infinities? Infinities aren't numeric according to Mma.

@kirma Atomic expressions would be left as they are by default and DirectedInfinity only accepts one arg which will be left fine. Not sure what to do with deeper Total.

I guess I prefer weird but consistent solution rather than 'user friendly' full of exceptions.

@Kuba Yeah, that would probably be welcome.

I must say I watch the streams occasionally and only if topic seems particularly interesting, because I don't have shortage of software design meetings that I'd need to fill in my life. ;)

Yes, I've only seen one or two. Id love to see better table of contents than optional notebook with meeting plan somewhere in video.

@Kuba No, I don't remember having seen something similar. I was glad to see image processing, but I missed the second meeting yesterday as I had rehearsal.

@halirutan It is just sad. (stagnation in FE area) I hope projects like PresenterTools (its recent malfunction during official talks) will open their eyes on the state of Dynamics in modern world.

I wonder if they think 'it is fine' or 'it is not worth humanpower'.

@Kuba I'm not sure how WRI perceives the quality of Dynamic and their GUI in general. They must have people that see the larger picture of current web-dev and mobile-dev and I'm sure those people acknowledge that Mathematica's GUI is not comparable concerning UX.

There are so many things that fall behind what is possible in other frameworks. Since several versions, I have inverted buttons on Linux (they appear to be pressed in their normal state), I have to wait several seconds before I can open a new notebook because the log into WC is happening at the same time, the grid/column/row layout is painful to work with, etc, etc..

And the slow performance of the notebook interface speaks for itself.

@halirutan sure they have people. By 'they' I meant folk(s?) behind decisions.

@Kuba One of the questions that bother me is if Dynamic was ever planned to be used to this extent throughout the system. My guess is that the current state comes from throwing more an more tasks onto a framework that's just not made for handling all this.

@halirutan I don't know. But I don't think Dynamic alone can be regarded as a dead end or not. The major limitation is that it is unbearable for larger application without insight / tools to access FE.

Understanding and access to things like dynamic module number, dynamic objects etc would enable users to create completely new patterns based on common ui design patterns. You don't trust automatic updating of Dynamic? No problem just combine tracking system and DynamicObject api and you can create whatever you want.

But no, 'take this, this is fine, Dynamic works, you don't need complicated internal tools'

And we end up with limited api which can't be trusted, not to mention scaled.

Has anyone ever seen them discuss the units syntax? The current units package has very good functionality, but its syntax seems poorly chosen, with an unnecessarily high cognitive footprint. In one video I heard S. Wolfram criticizing something as "inelegant", yet if that's an important criterion for them, why one earth did they choose to require the user to type, say, Quantity[x, "Meters"] to tell the program x meters?

@theorist because you need some highly structured way to represent data types or they're much harder to use. You can always write a front-end construct to simplify that for you. Or a helper function to use as x~qn~"m"?

@theorist I find that control-equals "10 metres" works quite well.

@CarlLange it's brutally slow though. With code-completion I can type Quantity[10, "Meters"] faster.

@CarlLange Thanks for the suggestion. I address, in detail, the advantages, pitfalls and limitations of ctrl= in my answer at the bottom of this thread: mathematica.stackexchange.com/questions/15338/…

@b3m2a1 In this thread (mathematica.stackexchange.com/questions/15338/…) several front-end constructs are proposed to address the cumbersome units syntax. In my answer at the bottom I cover, in detail, the problems with all of the proposals.

@b2m2a1 [continued]. If you have an alternative that is canonical, and doesn't require you to know in advance what units/physical constants you will need (i.e., doesn't require they all be pre-defined within the construct), that would be great. Also, regarding your first point: I'm not a software engineer, but why couldn't one enter those data types using, say, x "Meters" instead of Quantity[x, "Meters"]? I.e., why couldn't Mathematica's parser interpret the former as the latter?

The infix idea is interesting--I'll play with that; though even with that, the other issues I mention remain.