> If you're using someone else's labor, it's only fair they're allowed to dictate the terms of how you're allowed to use it.
And they are, that's what choosing a licence is all about. In case of MIT/ISC/BSD/WTFPL licensed software, this someone else just decided to dictate a lot less than he could have.
Except many of them then come out complaining how Amazon (just to pick an example) is leeching their work, while they are perfectly in line with the chosen license.
And that's why whenever I want to contribute to a MIT/ISC/BSD/WTFPL licensed project, instead I just fork it and make my own changes GPLv3 only.
If companies can make proprietary forks, I can make a GPLv3 fork. Best of all, no company can take my changes and make them proprietary. And if the maintainers want to merge my changes, they've got to relicense to GPL.
When you fix a bug in X11, you keep it in your one‐star‐on‐Gitlab personal fork under GPLv3 to prevent it from ever making it into HP‐UX, rather than contribute it to the upstream project, where tens or hundreds of thousands of individuals using X11 under free and open source licensing in free software distributions (not proprietary forks) could have experienced the benefit of your fix?
I mean, you’re free to do that, but taking pride in it sure feels odd to me.
I don't use X11, but I've had a very negative experience trying to contribute back to MIT/BSD/etc licensed projects anyway, as they're usually just one close team of developers publishing something and rejecting any outside PRs or requests.
License choice is a political choice, and it's not a coincidence that corporate-friendly licenses are usually on projects that have a strict vision and reject outside changes.
I've got the features I want, in the way that I want them. If you want to use them, you're free to switch — for some of my projects, tenthousands of people have done so.
I'm using Fish for years, tried Nushell recently, but it didn't click for me. While I like the principle of data being more than just plain text, it probably was just too alien to me.
A few here said they don't use Fish or another shell due to compatibility issues, but I wonder what the problem is: If I want to use a script written for another (POSIX) shell, it most likely has a shebang (or I can add it), so it will get properly executed using that other shell…
Game dev is large part C++ exclusive because of legacy (the widely used engines were started long before Rust existed), so does one really have a choice if the goal is learning game dev? In the end, you learn what you need to accomplish your goal, even if you'd prefer other tools.
It's simultaneously a good and a bad thing Git is so dominating nowadays. On one hand everyone can just jump on everywhere as the tooling is familiar, but on the other hand there's so much more out there. Fossil looks really nice, but I see no use (for me) as long as there's Git and surrounding tooling (Github and similar).
Always have local and offsite backup, so you can get to it quick when the laptop dies, but still have options when the house burns down. For me that is:
* Connect an external drive every few days for Time Machine to do it's magic. If I forget, it will remind me after a week or so.
* Continuous offsite backup using Backblaze. Really, they're great!
If you want continuous backup locally too, you could use a NAS for Time Machine to backup to instead of a simple drive.
I used to use Crashplan on Windows back in the day, but their interface is (was?) horrible and it's all Java, so when I switched to Mac I compared some options and in the end chose Backblaze.
I wonder how big the market is for this. Despite being an actually nice language, Swift is not that popular outside Apple's ecosystem, so I guess most developers would use XCode for it's integration (with Apple Developer, SwiftUI/preview etc).
I don't think XCode is exactly popular or viewed as anything other than necessary evil by many Swift app developers. Like a sibling comment mentioned, many people already use other IDEs to write the code and just use XCode to compile stuff because it is just so ass. Get the compiler invocation experience and maybe even the Apple Developer integration to a decent enough shape in a VS Code extension and XCode can start counting its days methinks.
> many people already use other IDEs to write the code and just use XCode to compile stuff
I've never met anyone who actually does this. JetBrains is even discontinuing AppCode, which as far as I know was the only real alternative IDE (and it had a lot of holes in its functionality).
Xcode lacks decent refactoring tools but otherwise it's a perfectly fine IDE, and has some really powerful debugging abilities. Don't get me wrong, I don't think Apple is giving it the attention it deserves, but in my experience most people hate it just because it isn't IntelliJ or VSCode.
My issue with Xcode isn't a lack of features, its the fact that the features don't reliably work. And not the advanced stuff, the very basic features. I routinely have issues with stuff like clicking through classes or syntax highlighting.
Another thing thats highly annoying is that compile errors don't get properly cleared on builds, so if there are multiple errors, it might just be that one of them is a real error, but the others are stale.
Lately I've been working with Swift Packages, and now restarting Xcode many times a day is part of my workflow - otherwise compile errors persist.
Ive been in iOS for a decade now, so mostly I don't get hung up one these issues, I know how to clean the "derived data" folder, I know how to jiggle it "just so" to get it to do what I want. But still its frustrating that the most important tool in my job is doomed to be moderately broken forever.
It might be a "grass is greener" scenario, but whenever I hop to IntelliJ, I don't encounter any of these kinds of problems.
Oh, and BTW, if you want to check Xcode out for yourself and have trouble downloading it, its not you - Xcode is like 20GB big. I guess you need lots of space for the world's most broken syntax highlighting algorithm...
> compile errors don't get properly cleared on builds, so if there are multiple errors, it might just be that one of them is a real error, but the others are stale.
Oh wow, I opened it about once to compile something, had this issue and had to clear a bunch of caches. I thought I was holding it wrong. Signing to get an ios-on-mac app to run was also a hellish experience; I think I ended up using the iPad emulator to preview the thing.
It felt a lot like they don't want you to develop things and I guess that fits with their general perceived disdain for general purpose computing (download the big-corp SaaS app from the App Store and shut up).
Well I do it. Or did till App Code was killed. I still do some Swift in CLion.
Here’s my reasons:
- Xcode has many failure cases for refactoring or is slow at finding symbols across extensions. Jetbrains handled it effortlessly. God forbid something crosses a target boundary.
- Xcode is really terrible for multi language projects. If you’re sticking to ObjC and Swift, it’s fine, but the C++ support is really poor. If you need to throw in Python or anything else, good luck. Jetbrains handle multi language super well.
- extensibility is a big deal. Xcode isn’t extensible (well only in a very limited way) and there’s many plug-ins that I either use or create for myself to speed up my work.
If Xcode supported LSPs, it would honestly change the equation greatly. But today myself, and several other devs I know, edit outside Xcode and build via the command line tools instead.
Fair enough. My point wasn't that literally no one does it, but more that it's pretty uncommon. You can't get live errors/warnings in Swift or ObjC outside of Xcode, right?
I’m curious what refactoring tools are missing? I don’t use many other IDEs so would be interested to hear about them. I’ve used Xcode’s existing refactoring tools quite a bit, but haven’t felt I was missing anything, probably because I don’t really know what else is available. (They were terrible for many years, supporting only Objective-C, but they now support C, C++ and Swift as well.)
My experience is limited to using it with Swift and Objective-C. Xcode has been getting better recently but tools like IntelliJ have support for a bunch of useful things that Xcode doesn't. Off the top of my head:
* refactoring functions/methods: adding and removing parameters, renaming parameters, etc.
* safe-deleting symbols
* advanced search tools. Not just "find selected symbol in workspace", but "find places where this variable is being written to"
Also, the refactoring tools that Xcode does include are very unreliable. Even simple renaming will often fail, even on small projects, or will mistakenly rename unrelated symbols.
Oh, AppCode absolutely kicked ass in 2013-2014 when Obj-C had been somewhat modernised but wasn’t changing too fast, and Swift was yet to be announced. Xcode was an even worse editor back then too.
It was always a struggle for JetBrains to keep up with Apple dropping new stuff with no notice though, and I can’t remember when I last tried AppCode
I’ve only started learning Swift, so I don’t know how it performs on bigger projects, but so far I’ve been loving playgrounds, if not for the dog-slow compilation, but that’s in-character for all LLVM-based compilers, so maybe not exactly XCode’s fault.
Slowly but surely things are getting better in terms of cross-platform, with the latest in that realm being Apple itself committing to an open source rewrite of Foundation, which will fill in some holes and improve consistency on non-apple platforms.
Swift on server has been usable for a while now too.
I think the next big bottleneck on popularity will be tooling, and a solid VS Code extension is a small step forward in addressing that issue.
As someone who’s been using Swift for years on iOS/macOS, I’d love to use it for desktop development on Windows and Linux. I think the language is well suited for that purpose, and it strikes a nice balance between safety, speed, features, ease of writing, and clean syntax which isn’t matched by too many other languages.
Well, with WASM everywhere I think that it might realize some of its potential as tooling improves. Don't you want to write your algorithms and data structures in such a nice language? Slap the native UI, when in iOS its SwiftUI and when on the web its ReactJS or something and when its on Android its whatever Android uses but have your actual processing of the user inputs in Swift.
The traditional cross platform approach is to write it in JS and use the native UI framework API, which works but its not native anywhere and you have to write JS.
So instead of doing that, you can start with Apple platforms and port to the other platform where porting would mean just UI and device specific API implementation as the Swift can be portable. You wouldn't be trying to build native UI with Swift but you would use the Swift code as a service which handles everything except the UI where the UI implementation will communicate with your Swift code.
The advantages are:
1) Working with Swift, which is pleasant to work with.
2) Apple's all platforms are on the same architecture and as a result, running your code for mobile on your dev machine works at full speed. This means, even the cheapest Apple Silicon device provides great performance on your workflow. No more sluggish emulators.
3) Preserve the data structures across all platforms and these data structures are not JS data structures. You have integers for example :). Categories of bugs and work to make things fit vanish.
I agree. I personally find XCode absolutely bewildering.
The several times I've tried to do anything with it, I just gave up and found an alternative. My guess is that if you've been using Apple tools for years, then it makes sense, but to me it's indecipherable. The menu options don't seem to match with the GUI, resource views don't seem to match the files, random panels appear with unnecessary information, resources are needed for unclear reasons and more.
It's all very Apple, but in the worst way possible. It's like the IDE version of AppleScript - seemingly useable but based on a logic which totally escapes me.
The use case is mainly for writing packages, command line tools or server side components where the Swift toolchains are quite nice to work with. The experience is very much like using Rust or Go.
It’s such a shame, i really envy some of the features in Swift but I just can’t justify the risk with how Apple-centric it is. Too many times I’ve been bitten by ducks that quacked just like that one, I suppose.
I’d love to see like a gccSwift the way there’a a gccRust coming together. I think that would be really cool.
You can already develop Swift code on non-Apple equipment
You can’t develop for iOS as their frameworks are as of now (this is changing, they’re rewriting Foundation) tied to macOS, so this doesn’t change much
> There’s only one big tech company that seemingly never played this hire-for-the-sake-of-hiring game, and thus hasn’t announced any layoffs at all, let alone a headcount that would fill a basketball arena. Just one. One company that has, at its best, always kept its cool in the face of economic swings both up and down.
Well, he doesn't call it an apple here, but I think his observation nontheless is sound, that most of these companies just hired for the sake of hiring the last years. Another observation I read yesterday (forgot where), MS laying of 10k isn't that much considering they hired 12k last year.
Finding the source in the header was obvious, but I can't figure how to decode that properly. I can see the rules for body{} and @keyframes{}, but no idea where all the text (the before/after rules) are hiding..
The header " The Page With No Code " is in the html::before content property.
The first paragraph "It all started when..." is in the body::before content.
The second paragraph "This web page has..." is in the body::after content.
And finally, the footnote "* Obviously there's some code somewhere..." is in the html::after content property.
I found those in the inspector, sure. But I can't find them in the base64 encoded header.
Edit: Nevermind. I tried like 10 different online base64 decoders before, till I found one wich didn't show just garbage (maybe they all hiccup on the emojis?), but even that one didn't decode properly as it seems. Either the eleventh one now told me the whole truth, or I should've used curl -i from the start instead of copy/pasting from Firefox's developer tools.
> The btoa() method creates a Base64-encoded ASCII string from a binary string (i.e., a string in which each character in the string is treated as a byte of binary data).
