Excuse me for presuming, but that seems to be a 1st world view of ARM SBCs usage. There are plenty of places in the world where this may be the only computer used until traveling aboard or higher education, so the ability to run actual 'desktop' applications, super cheap, plugged into peripherals, is still a worthy usage of a pi and its ilk.
I have never seen anyone in my third world home country just carrying or even owning an SBC. Even the poorest people just buy a phone because it's wildly more useful and does not require a peripheral. Otherwise, they buy an older computer that can be had for cheaper than most SBCs.
Actually, I'd argue that the market segment is squarely a first world one, mainly because it's far from the most convenient computing platform and alternatives are far more useful when you can only afford to own a single computer. Being unable to make calls or use messaging apps (access to whatsapp is almost a requirement in tons of countries), and coming with no built-in battery makes them a complete non-starter as a potential main device.
To what extent are these used for this use case vs. very inexpensive laptop computers or Chromebooks? In most of my travels I've seen a lot more extremely cheap laptops than ARM SBCs.
I agree that there's a stronger justification for the desktop (and TV-dongle / emulation station, for which there's just a lack of better-suited competition) use case than the home lab one.
Additionally, many places have flaky or nonexistent power infrastructure. Having a computer that runs at 2-3W is a lot easier on small solar + battery than a computer running at 8-10W idle.
No, the article does not. I just rtfa and even Jeff is stating that once you pass the $100, you're in a different class altogether, and are competing with used mini pcs. He even mentions that trying to get a pi at MSRP isn't likely to happen any time soon, so even if we were to compare a $35 MSRP board to $150 board, the pi still has 2 advantages, cheaper price point (assuming MSRP PIs are available), and working software.
Yeah, but I think you're underestimating what the grandparent post is saying. The people who would PAY for some of these functions are already making do with Excel. And microsoft has responded in kind by increasing Excel's ability to do, well, everything. I'm pretty sure if someone wanted to include those features the article is talking about on top of Excel, they would. Just last week, we saw someone add onto Excel a C# IDE with debugger, and posted about it here. It seems one's limit with Excel is only one's imagination.
And PowerPoint is Turing complete, so I guess we may as well just throw away all these other programming languages and use that going forward because lots of people already use PowerPoint?
Excel as a format is an awful abomination of XML, and the program itself is an awful experience that people just stick with due to a mix of Stockholm syndrome and inertia. It’s not exactly something I would ever want to “aim for”.
"Excel as a format is an awful abomination of XML"
You and I may think so, but why would it matter for the end user?
"and the program itself is an awful experience that people just stick with due to a mix of Stockholm syndrome and inertia"
Disagree. For the purpose of what Excel was made for, it seems reasonable. Or rather, I've yet to see what benefits alternative experiences produce. For the vast 90% of users, Excel is a 1NF/2NF db, emphasized on visually viewing their data. It's dead simple to enter, dead simple to share, and reasonable easy to add some constraints, some linkage, and show data trends.
When it starts to actively harm or hinder you instead of help. If it's costing you time you don't have, resources you can't afford, or affecting your health, call it quits. Otherwise, at the very least, you'd maybe learn something new, and definitely have kept yourself entertained, regardless of its utility.
No, it isn't. It's just a tool designed to work with complex software development workflows, which 90% of software projects do not need. 8 commands (pull, fetch, merge, push, add, commit, checkout and branch) are all you need to get going for git, which is like 2-3 more than what you need for svn/cvs. It's like getting upset that cars that are manual have an extra pedal (clutch) compared to automatic cars with their 2 (brake, accelerator).
* Trying to merge feature branches together (main or other feature branches)
* Trying to remove feature branches
None of which are necessary in a lot of development models. If you have that many feature branches that you have to rebase constantly, it doesn't sound like feature branches as a concept are properly understood.
The idea behind feature branching is one of 2 models:
1) either the main branch always works, and development is done in a feature branch, only to be rebased into main when development, testing, and sign off occurred, or
2) serious bug fixes occur outside the main branch, to be re-incorporated back into the main branch once it's been proven to be effective.
The 1st model should only require a rebase when the feature is complete. The 2nd model MAY require a couple of rebasing, dependent on how extensive the bug fixes are, and how fast the main branch is moving along, but not to the point where constant interactively rebasing your branches is the norm.
If you're writing a local stack of commits, you need to do an interactive rebase to edit the commits in the middle. You can't just check out and amend earlier commits in the stack, since git has a branch-first rather than commit-first model (one of its biggest UI failures).
No, I don't. Again, this seems to be a personal design/preference rather than a behavior git is forcing upon you, which is my point (This isn't a git issue, this is a development workflow that seems needlessly over complicated). When I do development locally, I only commit changes I want to keep. If there is something wrong, or code that needs to be modified, I make those changes, and then commit. When the work is done, if pressed upon me by the team, I rebase the local commits to a single commit before submitting a merge request.
None of my serious workflows require rebases, much less interactive ones.
Not that I don't do interactive rebases sometimes in local branches, but that I absolutely do not make them a part of any more general workflows. I rather try to avoid rewriting shared history where I can, and I'm happy with DAG navigation tools like --first-parent.
How do you manage stacks of commits for code review? (I'm guessing you just don't -- a lot of git users have really messy, unprofessional repository histories. The fact that git doesn't have great tooling for history management is also an embarrassment to our profession)
> Not that I don't do interactive rebases sometimes in local branches
I don't have a problem with rebasing in local branches before code review. I just don't allow rebasing once a branch has started code review, and I especially don't allow rebasing in a public integration branch ever.
(I also rarely feel the need to rebase, personally, even in my own local branches. Working in better tools than git in a past life has given me a lot of the discipline I feel that I need to build good commits as I work. I make much more use of the git staging area than I see most devs generally do and use `git add --patch` and `git add --interactive` far more than `git rebase`. `git add --patch` especially is an under-sung hero that I think a lot of junior developers should learn well in advance of rebase.)
Also, I'm just not that bothered by messy histories in code reviews when I review other developers work. If the idea comes across even if the commit messages don't have the greatest narrative flow or are perfect, I'm perfectly fine with that. I make sure all merges are --no-ff and after that I can browse a "clean" history post code reviews with DAG traversal tools such as --first-parent. But that also gives me an opportunity to dig back into the mess months or years later after the code review if I need to research a bug or a regression. That sort of "sewage archeology" isn't "fun" by any means, but the number of problems I've been able to solve with it is high enough I appreciate keeping that mess around in source control. It's source control's job to keep the mess for me and present me pretty views for more regular work. That's why I prefer to trust tools like --no-ff and --first-parent over --squash, because that's what source control is built to do, control old histories messy or not.
What can I say. You're locked into a significantly worse maximum than is possible (and exists) using better tools. In a normal workflow your commits are small enough that you don't have to do "sewage archeology".
I don't think you are reading me correctly. That is a rare occurrence, but it is possible when using merge commits to correctly describe the DAG. It's entirely impossible if you overly rebase/squash. Those rare times that I've needed to do it it have "saved" a project a lot of time from a major bug or regression. My normal workflow I look at a "clean" faux linear view, but it's just the "--first-parent" view of merge commits, which gives me a "PR focused" or "integration focused" view of source control first.
If your average commit size is 30-40 lines of code, this isn't an issue. Stacks of small commits is a time-tested workflow, used by the Linux kernel among many other projects.
I think we are talking about different things at this point, but I may be losing the thread of your argument here.
I love a code review to consist of lots of small commits. I'm mostly fine if even some of them from developers more junior than me are just named "commit" if they are small.
When I finish the code review I prefer to only `git merge --no-ff`. All those small commits stay in the code history in the exact form they were reviewed under.
If I'm looking at history I'm most often using something like `git log --first-parent`. In my --no-ff integration branch that just shows me an integrated change list (PR list). Git gives me a "straight line" view down the DAG and hides irrelevant information I don't want in that moment like all the small "commit" commits.
If for some reason I find a bug or issue in some code, I may need to drill down into specific small commits including the "commit" commits, and I have that ability because all those commits are still in the DAG.
Medical Billing and Coding - I want at least one stream of income where I can work from anywhere, in case this downturn is severe enough to force my hands to come into an office.
Spanish - I want to be able to at least read on a 5th grade level.
Stocks - A general idea of what most of the terms mean.
Creative endeavors - Either drawing, music or writing. Something to escape with and have proof that it was an interesting journey.
Weight loss - Gained over 50lbs since the pandemic. Need to lose 3x time to get to a healthy weight.
I have many, many more, but these are the 5 I'm the most interested in.
Dishwasher. Never really had one growing up, and never managed to rent an apartment with one, or one that worked. I'm now finally in a place with a working dishwasher, and it makes life so much easier. I don't feel guilty about not doing dishes immediately after using them (I only have a set for 2, so if I don't clean it immediately, I'll quickly run out of usable dishes in a day.)
Folding Shopping Carts. Literally only had a car for the past 3 years so I could go grocery shopping (Before pandemic, took train to work. Parking wasn't free.) Now that I live in a place near a grocery store, I purchased a shopping cart, and don't really need the car anymore, which I sold last year. So, I don't care about gas prices, don't have to worry about maintenance, no insurance, and most importantly, I don't have to worry about parking!
I can only answer this as someone who's looked into Haxe for a couple of years now versus someone who has actually made an application/game/website with it, but from what I can tell, it's really the 'good at most things, great at non' option for easy interactive, multi-platform development.
What you may not know, is that HaXe started off as an alternative to using Actionscript to build flash/flash-like projects, without having to use Adobe products directly. When the bell started ringing for everyone to get out of the Flash pool (helped a lot by Apple not including it in IOS), they sort of pivoted to being the open source version to Flash (OpenFL), which they used HaXe to build. (One of the things going in their favor was that they were one of the 1st tech stack that tried to do what flash did in a compiled language that included mobile and web targets, besides desktop. The only other ones I can think of that tried was Java and a bunch of 'compiled' js and html files into executables.)
Once they realized that they could just change the target of what they were cross-compiling to, they started adding other targets as well (started with swf and actionscript, then went Javascript, Java, PHP, C, Ruby and who knows what else). People started adding other things to it, such as IDE, game engines, and even Adobe themselves are re-purposing Adobe Animator to target OpenFL. And it grew from there.
Where I usually get confused and leave it all alone is that there is so much churn in that area, that it's hard for me to even begin pick a stack to work with. Apache Flex competes in a lot of what HaXe does, same as Apache FlexJS, Apache Cordova, Cocos2d, Dart/Flutter, Monogame, and so much more in the same area. It got to the point where even Unity and Unreal engine provides much of the same features, pretty much for free until you've hit a certain monetary limit (I think both are around 250k to 1mil, USD).
So, to answer your question again after I've bored you, the catch is that it's one of many (and I do mean many) options for you to choose if you're trying to target many platforms from one code base. It's decent on most all of them, and was one of the firsts to succeed, but depending on your particular needs, may not be the overall best choice for you.
Small nit, Haxe doesn’t have the upper case X anymore...
One more caveat to add to the end of your note here... Actionscript was probably the biggest standardized language across all web browsers at one time. It’s dead largely because of a business decision, and this left a lot of developers in the lurch. This will undoubtedly happen again.
Haxe is run by a group of developers that insists on keeping control of their tooling and means of development, regardless of what other platforms emerge. This always involves dealing with some rough spots and friction getting things to work initially, but in the long run it pays of with greater flexibility and peace of mind.
Full disclosure - Member of the Haxe compiler team