SoylentNews is people
SoylentNews
Developer Tim Bray, of XML fame, has written an ode to The Sacred "Back" Button.
Younger readers will find it hard to conceive of a time in which every application screen didn't have a way to "Go Back". This universal affordance was there, a new thing, in the first Web browser that anyone saw, and pretty soon after that, more or less everything had it. It's a crucial part of the user experience and, unfortunately, a lot of popular software is doing it imperfectly. Let's demand perfection.
Why it matters · Nobody anywhere is smart enough to build an application that won't, in some situations, confuse its users. The Back option removes fear and makes people more willing to explore features, because they know they can always back out. It was one of the reasons why the nascent browsers were so much better than the Visual Basic, X11, and character-based interface dinosaurs that then stomped the earth.
Thus I was delighted, at the advent of Android, that the early phones had physical "back" buttons.
[...] Nowadays Android phones don't have the button, but do offer a universal "Back" gesture and, as an Android developer, you don't have to do anything special to get sane, user-friendly behavior. I notice that when I use iOS apps, they always provide a back arrow somewhere up in the top left corner; don't know if that costs developers extra work.
[...] People using your software generally have a well-developed expectation of what Back should do at any point in time, and any time you don't meet that expectation you've committed a grievous sin, one should remedy right now.
The undo function has been around since the beginning, though invented and reinvented several times. Some systems got it much later than others, but now its presence is universally expected.
(Score: 2) by fadrian on Tuesday April 13 2021, @09:08AM (2 children)
You can serialize pretty much any object-oriented data structure as is as if casting integers to floats without having to bother giving the file structure a second thought.
You may not have noticed this, but OO is not what it used to be. It's now being seen as a swamp of unmanageable global state packed into object silos which can't easily be reasoned about. It will ultimately be subsumed by the functional programming paradigm just as OO superseded procedural program models - functional code is just that much easier to write/understand. And I say this as a programmer who cut his teeth on imperative programming languages and then moved to OO - from Smalltalk to cfront (Bjarne's first version of C++) to Java to Ruby and Python and just about everything in between. I've now moved on to functional languages - Clojure, F#, and Haskell - and can say that the code in this space is much better - easier to write, more generic, and usually thread-safe without all the complicated mechanisms of doing that in OO. So pointing out that anything was great for OO is like pointing out technology that was great for large prop planes in the early days of jets - interesting, but in the long run, irrelevant.
That is all.
(Score: 1, Insightful) by Anonymous Coward on Tuesday April 13 2021, @09:41AM
object-oriented data structures != object-oriented programming paradigm
Just because your data structure is object-oriented does not mean you have to use an OOP language and just because you are using an OOP language does not mean you have to use an object-oriented data structure. Some things are easier to think about as objects with attributes or are objects with attributes, so it is just easier to keep the data structured that way. Other things are not objects with attributes or are difficult to think of that way, so it is just easier to structure data in a different way. That's all that means. You are free to program around them however you please. For example, you can do object-oriented data structures in Haskell just fine, but they aren't objects in the OOP sense; and you can do non-object-oriented data structures in Smalltalk, but they are still objects in the OOP sense.
(Score: 4, Interesting) by RamiK on Tuesday April 13 2021, @11:20AM
When protoyping I want my code easy to write and generic. When debugging I want my code easy to read and as explicit, imperative and static as C so I won't have to stop and think if everything going in and out is per expectations.
I believe what we actually want is a language that can be "compressed" into generics and state machines and "decompressed" out of generics losslessly without losing variable and function names and looking like assembly out of a debugger. Something akin to classroom java workflow where you're glued to the debugger since it's not clattered, only with actual editable code instead of looking at a stack.
I know there's a lot of hard problems and limitations for this sort of "specs". But nevertheless, I reckon a dual-language such as this will be a great generic language that you'd then embed some C and such in for the performance parts.
compiling...