I believe any Azure user might be able to compile their 100 reasons to not use Azure, and the same will be true for most big pieces of software.
Even as someone that had minimal exposure to other clouds, I could easily see how Azure user experience lags due to the lack of proper care.
The amount of pages with a filter bar that will not work properly until you remember to click the load more should clearly be zero at this point, this is an objectively bad pattern that existed for years and should be "easy" to fix. But the issue will probably never be prioritized.
The fact is that unless tackling those issues are part of the organization core values or that they are clearly hitting their revenue stream, they won't be fixed. Publicity and visibility of those issues will always be crucial for the community of users.
This makes sense if you came from touch ui. Mouse and keyboard UI favours the old design because the way you hit things with the mouse is different. It is also bad to compare the two screenshots because the sizes are not in the same scale.
The new grouping is not a clear cut, like why is the position of the docked grouped with window behaviour? The older makes it trivial to discover that the dock moves unlike the newer one.
My view is that the design is much less refined and have a lot of space to improve. It isn't bad, the potential is there if you consider a touch + mouse ui. So let's wait I guess.
> The new grouping is not a clear cut, like why is the position of the docked grouped with window behaviour?
Both seem faulty in that regard. Both cram Dock and Window behavior into the same section, when each should be a separate section similar to the Menu Bar section at the bottom. But that's not a fault of the design language here, and can be fixed without changing it.
As a trans person, I've spent most of my life wandering, evading some kind of self-loneliness. But in the last two years I've started comprehending that is not only about the way we spend our time, but also how we use our body-mind credit too.
Living as much about the present as it is about the future. So it is important to understand that overworking today may impact your mental health tomorrow.
With this in mind, the one thing for me is peace of mind. I want to have a nice live and enjoy the world around me in a healthy way. Giving my best to ensure that it not only does apply to me, but apply to people around me.
I really do not care if this means improving a banking system do deliver better prices to clients, cooking or teaching people. If I can excel and do some good, it is valid.
> it is important to understand that overworking today may impact your mental health tomorrow
That is so true.
I find it helpful to go into situations like that with the cognizance that my main reason to do extra work now are to do less work later (spending a little extra time double checking work, for example, might make you stay an hour or two later for a while, but the return comes when you spend less time fixing bugs or responding to production issues).
Not nearly as helpful to be working extra simply because a business operates as a skeleton crew, for example.
I’m not a daily go programmer. I’ve learned the language two years ago and know some the background behind it. Based on that I don’t see a place for sum types in Go because it does not solve a problem that is hard to solve with modern Go code.
But considering the proposal itself. I would approach it much differently.
Sum types could be represented as a closed enum.
type Result enum int{…}
const ( Ok Result = iota{interface{}}, Err Result = iota{string} )
The initialization would be done like:
Ok{10}
Err{“Something went wrong”}
The variable itself would act just like and other enum with unpacking being done somewhat close to this:
Ok{variableName} := result
Where the variableName would be set to the zero value in case of a bad match.
The enum prefix would enforce a single const block and no extension outside the module package.
You are seeing it through the lense of an application developer. As a library author the world looks different though - here you cannot know/define the types in advance.
MacOS major updates are far from only cosmetics. Apple does a bad job in sharing it with the broad public but every year they bring new features. Sometimes they are slower, an API addition one year, a deprecation in the next one and so on.
My main takeaway is that Swift is complex and tries to solve many problems. As a result it is going to frustrate almost everyone in one bit or another.
I'm not an expert in the Swift Evolution process but I must praise it in terms of ease of reading. Back when I was invested in learning more about Swift, reading some proposals helped me understand it better. But I believe the Swift team/community will need to define a boundary some time in the future on what must be added or not to the language as its complexity grows. In the long run, even if a proposal makes sense, is implemented and was reviewed, it usually will also add a new thing to the language that implies in a bigger documentation and another way to code/solve a given problem.
In the AnyObject dispatch regret [0], the author wrote "As I’ve mentioned many times (though not so much on this blog), Swift had to be as good as Objective-C at making most Cocoa apps, or people wouldn’t use it no matter how good the new stuff was". My first real contact with Cocoa was while learning Swift and I can imagine all the hard work that was put into it. Then SwiftUI came on together with a bunch of new features to a language that I was still getting used to. After getting frustrated with the lack of documentation (combined with the lack of knowledge about some patterns) and no clear way to solve small problems while studying it, I've decided to dive again into Objective-C to not only grasp most of in one week but also to find that I did not need most of the features Swift delivered.
And this is something that is part of Swift. By design it offers you multiple ways to tackle your problems and by design it is only going to offer you more ways as time passes. I consider this a trait that is bad for the language itself in the long run. Looking back 7 years after the introduction of Swift I guess Apple would be better served if it just kept investing in Objective-C. But who knows what will Swift and its ecosystem look like in 2028.
I would not call "Mountain Lion was the best" just nostalgia. The UI was more concise and polished in general. Consider the Big Sur sidebar, on some Apps it acts a shortcut list, on other as a tab bar and on others its used to host hierarchical views. It not only does not improve the UX in a functionality, it also breaks the reading flow as we need to look in the toolbar (left to right) and then on sidebar (top-bottom) as Apple is pushing developers to use it. It's not to say that skeuomorphic design was perfect too.
Using Mountain Lion in 2021 is going to feel less aesthetic than Big Sur just as using System 8 in 2011 felt. Overall consistency and sizing of Mountain Lion is superior to Big Sur if you consider a keyboard and mouse based OS just as Big Sur is superior if you're used to touch input and modern iOS UI.
Agree. A desktop OS has different needs than a mobile OS, and Apple is trying to foist iOS onto its desktop users under the guise of progress, but really nothing has fundamentally changed about using a keyboard and mouse to interact with the computer in decades. And that experience is very different, if you are skilled, than using fingers.
Of note, macOS has always been very good at having consistent keyboard shortcuts across apps, something Linux is still trying to learn.
Coming up next: Excel Lambda back-end experimental support on LLVM. (Just a joke)
Excel is a very useful tool for many non-programmers employees. With LAMBDA they can have a more expressive system without the need to touch VBA, JS, PQ M language, nor jump to Python.
Are we able to generate side-effects with it? Like poking the value of a cell?
Even as someone that had minimal exposure to other clouds, I could easily see how Azure user experience lags due to the lack of proper care.
The amount of pages with a filter bar that will not work properly until you remember to click the load more should clearly be zero at this point, this is an objectively bad pattern that existed for years and should be "easy" to fix. But the issue will probably never be prioritized.
The fact is that unless tackling those issues are part of the organization core values or that they are clearly hitting their revenue stream, they won't be fixed. Publicity and visibility of those issues will always be crucial for the community of users.