Layout is so difficult that it made me quit using Common Lisp and ncurses to build my passion project and become the very thing I swore to destroy (a React developer).
I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone given up and either embraced CSS3 (waiting for the LLVM backend) or gone back to plain text?
Author here, and I also teach web dev, including CSS, at the University of Utah (including this semester). Newer parts of CSS, like flex-box layout are both simple and powerful. Just use those! I think it's important to start thinking about learning all of the Web Platform like you'd think about learning all of the Windows APIs or all of the Linux system calls or all of your favorite programming language's features. People rarely do! (I have 15 years of Python experience, and I do not understand metaclasses or async.) There are lots of weird obscure corners, but you don't need to know those to build websites.
I was playing with Solvespace a few weeks ago, and the thought occurred to me that the constraint-based modeling approach is exactly what I want in a layout system, and it extends to 3d even. We're stuck with CSS for now, but this must be the future.
This is super neat - SBCL is an awesome language implementation, and I've always wanted to do CL development for a "real" game console.
I'm also surprised (in a good way) that Shinmera is working on this - I've seen him a few times before on #lispgames and in the Lisp Discord, and I didn't know that he was into this kind of low-level development. I've looked at the guts of SBCL briefly and was frightened away, so kudos to him.
I wonder if SBCL (+ threading/SDL2) works on the Raspberry Pi now...
I'm not doing the SBCL parts, that's all Charles' work that I hired him for. My work is the portability bits that Trial relies on to do whatever and the general build architecture for this, along with the initial runtime stubbing.
My current unannounced project is a lot more ambitious still, being a 3D hack & slash action game. I post updates about that on the Patreon if you're interested.
I'm currently very slowly making my way through Geometric Algebra for Physicists by Doran and Lasenby. The book is a delight to read, but I'm not a mathematician, and this article is showing me that my small amount of understanding is...not nearly as deep, and especially not nearly as rigorous, as I would like. I should try to re-read with Eric's criticisms in mind.
For a physicist it eventually becomes necessary to understand exterior algebra.
This is often done in the context of differential forms, but of course can be brought back to vectors easily. With those well established tools GA doesn't offer much. This blog post seems to point out exactly this fact.
I always come back to Schutz's Geometrical Methods of Mathematical Physics as my reference for notation, but I agree. I came to this by way of General Relativity, so that colors my perceptions. The few treatments of GA that I've looked at (briefly) weren't very clear about the distinction between 1-forms and 1-vectors and seemed to assume Euclidean metric everywhere, so I left thinking that it seemed a little weird and not quite trusting it.
In any case, my experience is that the coordinate-free manipulations only go so far, but that you pretty quickly need to drop to some coordinates to actually get work done. d*F=J is nice and all, but it won't calculate your fields for you.
> It's true that any kind of pay-per-use would be a hard, hard sell, though. Who wants to have to think about whether every click is worth the nickel it's going to cost?
I've heard this argument before, but there's a common existence proof to the fact that it's possible: video games. People who play many different kinds of video games (RTS, MOBA, MMO, RPG) get used to making decisions as to whether to buy things many times an hour with barely any cognitive load - their brains just get used to working with smaller units of time and money.
And why shouldn't they? I found sources online that say that a YouTube video earns about $5 per 1k views, or 0.5c per view. If I have to pay half a cent to watch a video, even a short five-minute one, that's almost below the threshold of caring, and even those making median income are probably going to be constrained by the actual time that they have available to watch, rather than the cost of the videos. People will spontaneously spend $20 to go out to eat - after the initial adjustment to a micropayment system, they should have very little trouble spending 60 cents to watch YouTube for five whole hours after work, especially if the micropayment system has common-sense features such as clearly showing your wallet balance over time, how much you've recently spent, and how much longer your balance will last at your current rate of consumption.
Now, to be fair, the fact that it's possible, and that people will quickly get used to it after they spend some time with it, doesn't mean that people will be interested in trying it in the first place, and that's a much harder problem, because subscription services are more lucrative for companies. I think the only way to get micropayments off the ground would be a grassroots movement supported by a bunch of content creators making their stuff available on a micropayment platform. Otherwise, companies that move away from ads (e.g. Google) will just turn to subscription services to lock their users in.
> My fear for end users is that once an alternative App Store opens or direct side loading is allowed it will reduce users options and harm the users ability to effectivly control privacy.
This is massively misinformed. The majority of privacy controls exist in iOS itself completely independently of the distribution method, and many more unimplemented potentially beneficial privacy controls can also be implemented at that level. This has been true for years.
Privacy controls are not a panacea against abuse by malicious developers. Permissions can be granted for legitimate purposes and then abused for nefarious purposes once granted.
Many of the App Store privacy rules relate to what you are allowed to do with the user data after access is granted by the user. In other words they relate to data retention rather than access in the first place.
For example they recently added a rule saying if a user can create an account inside your app you have to also give them an option to delete the account from the app as well. This is a behavior enforced by app review, not by operating system privacy controls.
> Privacy controls are not a panacea against abuse by malicious developers
Sure, I never claimed that they were a panacea - just that the majority of privacy controls implemented by iDevices are actually in iOS and not Apple's App Store review process.
Additionally, those privacy controls are more fundamental than those in the App Store. It's more important that the app not be able to toggle the microphone at will than for you to be able to control what it does with that audio after capture.
> Many of the App Store privacy rules relate to what you are allowed to do with the user data after access is granted by the user
That's not an iOS problem, and Apple fundamentally cannot regulate that, App Store or no - after your personal information goes to a third party's servers, Apple has zero visibility into what happens.
This is also not an Apple-specific issue - this happens with Android, Windows, Chrome, and random online websites. Apple cannot and should not be responsible for fixing this - we need a good set of government regulations designed to restrict how your personal data is collected or used. Otherwise, just like you said, an entity (e.g. a bank) can ask for your personal data, then store it, and it gets leaked.
> Additionally, those privacy controls are more fundamental than those in the App Store. It's more important that the app not be able to toggle the microphone at will than for you to be able to control what it does with that audio after capture.
I mean both are equally important really. I might want to grant you access to my microphone to run a voice command but that doesn't mean I want you to collect my voice recordings and sell them to someone else. I might want to grant you access to my contacts so I can message my friends but that doesn't mean I want you to scrape my contact list to data mine my social network.
> That's not an iOS problem, and Apple fundamentally cannot regulate that, App Store or no - after your personal information goes to a third party's servers, Apple has zero visibility into what happens.
Yes they can. Maybe not perfectly but the App Store Review Guidelines define specific restrictions on what you can do with personal information, with the threat of having your developer account terminated if you violate those restrictions.
> Apple cannot and should not be responsible for fixing this - we need a good set of government regulations designed to restrict how your personal data is collected or used.
Sure, specific privacy regulations would be great, but the government moves very slowly and the government itself isn't going to be able to enforce such regulations on a massive scale in the same way that the app review process currently does.
> I mean both are equally important really. I might want to grant you access to my microphone to run a voice command but that doesn't mean I want you to collect my voice recordings and sell them to someone else.
Throughout this thread you’ve demonstrated that you don’t understand how the OS itself works and assume App Store review is somehow protecting you from this, the OS already prevents this.
Even with controls on the device companies act in bad faith and take liberties with your privacy - I was going to the beach yesterday and my friend shared his location through messenger, to view it I had to share my precise location too - why? You can deny the permission all you want but that won’t stop them blocking features unless you tick the box, even if it is unrelated or not needed for the functionality.
That's a clear example of a bad technical control, whose fix can still be implemented in iOS without the App Store. It's pretty trivial to add a feature to iOS that allows you to fake your location - there was an Android fork that had that feature for a while a few years ago.
> You can deny the permission all you want but that won’t stop them blocking features unless you tick the box
Many permissions (camera, mic, location, etc.) are trivial for the OS to spoof and don't require app store vetting.
One of my relatives is in her early 20's and has a large amount of difficulty using Linux (even for relatively simple needs like what you describe above), despite dozens of "support interactions" and assistance. Other relatives are in their 40's and failed to use it as well.
It's not enough for some people to be able to use Linux - if you want to recommend it for general use, it has to be usable for almost everyone.
I've tried to get multiple non-family members set up with Linux and have failed, with constant bugs from Linux, and confusion from the family members. Windows is far more reliable and easier for them to use.
This clearly invalidates your point, and supports "Linux would be either painful or more realistically a no go", because it's obviously not enough for some relatives to be able to easily use Linux - most of them need to be able to. The fact that you have more capable-than-normal relatives or more Linux-friendly-than-normal hardware is irrelevant to the fact that most people do not.
This seems like a reasonable take - there's only one problem: you haven't told us how to draw the rest of the owl.
How does one learn how to (1) think in this way (which necessitates not only abstract description but multiple concrete examples) and (2) what workflows and commands are necessary to effectively implement this?
1. a ref (branch or tag) that builds (compiles & passes all tests including UAT)
2. every shared ref has a clean revision history that allows for graceful change management ( read changelog, fork, integrate, revert, A/B test)
Any ref shared by a team member (e.g. git push) must meet those two qualities. Team members must reconcile refs on their end (e.g. rebase) before they can submit a new ref meeting those expectations.
This way you are not prescribing a workflow (e.g. git-flow). The team needs to agree on that to their software delivery pipeline requirements.
In order to deliver these two expectations, they need to understand refs (pointers to a digraph) and how to manage them (rebase). tell them to RTFM the git manual on those topics.
Just like memory management, pointers, algos etc these skills are essential . They are not a "nice to have" to build software.
I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone given up and either embraced CSS3 (waiting for the LLVM backend) or gone back to plain text?
reply