One of the biggest issues I ran into years ago was debugging outside of macOS was a nightmare. Even now, debugging is a terrible experience on a non-trivial project. I am not really sure if it the size of the projects I've worked on, interop with objc, compiler configs, project configs, or what, but it has always been a bad experience. I used it on/off for a project on Linux and the debugger didn't work at all. This was so long ago I am sure that has changed but at least so far in my experience, lldb will stop working at some point. I've worked on large Obj-C and C++ codebases and never ran into any of the problems I've run into with swift in this area.
Wasn't your intention whatever you typed in? That doesn't make you an artist and I don't want to hear the music AI made that you happened to type some words to and hit enter.
Tons of professionals use logic. Really, you will find money making musicians using any of the major daws. Pro tools might still be the standard for recording studios but that's likely it.
Logic Pro gets regular updates. I believe most of it is AI driven nonsense but they are making changes. Flashback capture was a nice fairly recent addition and surprising this wasn't implemented sooner. There are also regular bug fixes and performance improvements. I can't speak for the other apps.
It helps that you have to continue to buy their hardware to keep running said software. I guess they could be greedy and keep making me pay for Logic every few years so I'm happy they don't do that but they're still making money off my initial purchase of logic just in a different way.
I am not sure if you're disagreeing with the original poster here but you're both saying the same thing in different units. 1g/kg != 1g/lb which is A LOT more protein and a complete waste of time. As a mostly vegetarian who lifts regularly, I am targeting a bit more than 1g/kg but being from the US it is a lot less than 1g/lb. :p
A lot of it comes down to what the person you're responding to said, seasonality. I grew up in a very rural farming area and now live in a very large city. While the produce at the grocery store is generally inferior to that of being near a farm, when things are in season, it is at least comparable. That apple you buy in July is never going to be as good as one bought in the fall, it doesn't matter where you buy it from.
Frameworks from other companies. A lot of it is analytics/tracking, some payment processing, etc. There are a few open source libraries we're using as well but those probably are <5mb if I had to guess although I never checked.
Again, a lot of these companies have also been around so if my app has a ton of bloat from years of work, we're bringing in frameworks from other companies who have been around for years as well and probably have a similar amount of crap in their code. Plus they probably want to track everything we're doing so they're bringing in their own third party libraries. It's kind of ridiculous but that's where we're at.
Bigger companies won't have as many third party libraries as they can afford to do it in house but they're still bringing in similar sized libraries to do the same things.
You can access iCloud from an iOS app, it has its own public framework called CloudKit, so you could create your own version of it. If you don't like that example Chrome and Edge are both forced to use WebKit on iOS but are still much larger so.
You can though because a lot of those things you're talking about are available for any app. Sure Apple does have some private frameworks and what not that aren't available to everyone but I imagine if you wanted to recreate what the photo app is doing you'd be able to in 4.2mb or less.
Part of it is resolution. The icons and such in apps are much larger now than they were in 2013. Besides that I mentioned this in another thread but rarely will a team clean up after itself. There's probably tons of dead code and what not in a lot of these larger apps. I know all the ones I've worked in had a lot of bloat just from years of work. Some feature gets added 5 years ago by a team that no longer exists, it was turned off and no longer used but who is going to remove it?
Besides that, there's just a lot of garbage that gets added by various people with different interests. An unoptimized version of the app I'm currently working on has a ~15mb binary, the core app not including all the "extras" people have asked for. It has about 75mb of assets, probably 10-15% are unused but I have no idea. The download size is about 400mb.
It is dependencies but not from the GUI. As someone who has worked on several very large apps I can tell you 99% of the bloat is garbage. Someone somewhere wants this SDK from their friend's company in the app. Some manager wants to track X using this very specific framework. Some designer decided to add in animations in one screen that requires another framework to run and also 10mb in assets. etc, etc, etc. If your app is 10+ years old this all adds up and no one ever cleans any of it up. There's probably like 100mb of crap you can delete that doesn't even work anymore but who has time to remove that?
The first one you can configure and it is the default way you'd see this done in real life. You can add headers, change the request type, etc. Likely, if you were making an actual app the request configuration would be much longer than 1 line I used. I was mostly trying to show that the Swift example was hiding a lot of things.
The second one is for downloading directly from a URL and I've never seen it used outside of examples in blog posts on the internet.
In a sense it is telling someone else that yes, but more importantly, it is telling the compiler. I am not sure what the alternative is here, is this not common in other languages? I know Java does this at least. In Python it is hidden and you have to know to catch the exception. I'm not sure how that is better as it can be easily forgotten or ignored. There may be another alternative I'm not aware of?
As someone who has been coding production Swift since 1.0 the Go example is a lot more what Swift in practice will look like. I suppose there are advantages to being able to only show the important parts.
The first line won't crash but in practice it is fairly rare where you'd implicitly unwrap something like that. URLs might be the only case where it is somewhat safe. But a more fair example would be something like
func fetchUser(id: Int) async throws -> User {
guard let url = URL(string: "https://api.example.com/users/\(id)") else {
throw MyError.invalidURL
}
// you'll pretty much never see data(url: ...) in real life
let request = URLRequest(url: url)
// configure request
let (data, response) = try await URLSession.shared.data(for: request)
guard let httpResponse = response as? HTTPURLResponse,
200..<300 ~= httpResponse.statusCode else {
throw MyError.invalidResponseCode
}
// possibly other things you'd want to check
return try JSONDecoder().decode(User.self, from: data)
}
I don't code in Go so I don't know how production ready that code is. What I posted has a lot of issues with it as well but it is much closer to what would need to be done as a start. The Swift example is hiding a lot of the error checking that Go forces you to do to some extent.
What is the problem with that though? I honestly wish they moved the async key word to the front `async func ...` but given the relative newness of all of this I've yet to see anyone get confused by this. The compiler also ensures everything is used correctly anyway.
I played Might and Magic as a child but I never knew about this series nor have I ever played it. I also don't know anyone who has either now that you mention it.
So it is up to me to monitor your child? I don't work in porn or an even remotely related field but I have to implement age verification now because of Texas's law. Someone explain to me how this is protecting any children.
It is unique because everything is quantized. I've never used these tools but I am assuming you could give it some level of randomness but as someone who has performed and recorded a non-quantized performance is not random. So sure, it's super easy to quantize in your daw but it is a tool to be applied when needed, not something that is on all the time by default.
It is pretty rough but as someone who has been programming in Swift since 1.0 I can say it rarely happens in practice. In the early days it happened all the time where the compiler would trip up on random expressions. I can still get it to happen, especially on complex closure type things, but even if those did compile they're confusing enough where they really shouldn't make it past code review anyway. That url example should never either.
I am very curious as to what you're running into where you're seeing wildly slow type checking times.
For your first question, yes, it can be optionally turned on and set to a specific value. In the early days of Swift it was quite useful. I still have it on in one project but it rarely shows up anymore and when it does it is usually a mystery as to why it shows up and there's no clear way to fix it.
For your second point, this is mostly the case for Swift as well. 123 defaults to Int so if you wanted a floating point you'd have to write let x: Double = 123 or let x = 123.0. Most people will default to the latter because it is less typing.
Not quite. I have had a lot of musical training and have a very good musical memory. I can write down songs from my head or hear a song and write it down later, depending on how complicated it is, usually with only 1-2 listens, or play it back, etc. I can visualize things in my head but it is a lot more abstract, or rather, harder to explain.
I agree with the other person about singing. If you're any good at recognizing intervals already singing will really make it all click. Taking a few singing lessons would probably really help you even though it seems somewhat unrelated.
I agree with your last point. I get the criticism of Duolingo and it is fair, but I can't agree that it is completely useless. I learned/am learning French. I can get by with non-English speakers and people won't immediately switch to English when they hear me.
It took about 5 years of on and off practice. Not sure how much actual time I put in. Duolingo was one aspect, where honestly I probably learned like 75% of my vocabulary. I also have a French wife and friends, took classes, hired teachers, watched movies, read news, etc, etc, etc. I probably could have got to where I am without Duolingo but I'll never know. Learning a language is a pain in the ass and I don't think any one thing is really going to do it. Duolingo is free and can be one aspect out of many that will help get you there.
It's likely not like this everywhere but I've become a regular at a few places over my life time and asked about this. At least where I've been, it is actually all tracked. Generally, at least at bars, the people coming in and tipping well, are people who come in often and spend a lot to begin with so over the long run they end up making it back anyway. And honestly, when you're new to a city/place and don't have a lot of friends/are single, and you walk in somewhere and are greeted by name and served your usual without asking it's a nice retreat.
This is more or less how it worked in the small town where I grew up in the US as well. At night, almost all the lights would flash yellow from around 1AM til 6AM? I think. It's been a long time since I lived there.
There's still software I can't run on an iPad which is basically the only reason I have a MacBook Air. Maybe for some a windowing system may be the push to switch but that seems doubtful to me.