Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
> In modern programming, all you do is gluing APIs together
No, that‘s just web development because you have html for layout and css for styling and js is just there to glue everything together and do some trivial work.
Native app development, for example, requires a lot more of stuff where the language actually matters.
Backend development even more.
There are different languages for a reason.
Grow up. -
@Lensflare bold of you to assume I don’t do backend every day
-
@iiii non-web Python development is no different:
- statistics is just talking to numpy
- ai is just talking to torch/tf
- scripting is just scripting -
@kiki
"Sorting array in python will be faster than sorting array in C."
No. It won't. Ever. As you correctly said, best case scenario CPython will implement it using C sort, so there goes.
And yeah, kinda agree with the sentiment that any non trivial development (meaning anything not web related) requires more than just gluing APIs. -
@CoreFusionX oh yes it will if you write quicksort from scratch in C
-
@Lensflare I did some exploring of JoyRant's code with Cursor:
— Do you see the code?
— Let me check what files are available in the workspace.
I can see that this appears to be a SwiftUI project called JoyRant, likely a client for DevRant. I can see several key files and directories:
A SwiftUIRant directory which likely contains the main app code
A SwiftUIRant.xcodeproj directory containing the Xcode project configuration
Standard repository files like .gitignore, LICENSE, README.md, and a privacy.md file
Would you like me to examine any specific files or parts of the codebase? I can help you better if you let me know what specific aspect of the code you'd like to look at. -
@Lensflare
— Please scan the codebase and give me the rough breakdown consisting of the following:
1. Total LOC count
2. How much of the codebase can be considered boilerplate, e.g. all sorts of administrative code not directly responsible for the business logic of this particular app and instead common of every app written using the same stack;
3. How much of the codebase is declarative UI, e.g. code fulfilling roughly the same role as HTML + CSS does in web-based apps;
4. How much of the codebase can be considered original imperative algorithms, e.g. business logic that doesn't act as a wrapper to native APIs such as networking or other OS APIs
5. Overall, what percentage of the code is raw business logic that makes JoyRant JayRant?
— Based on my analysis of the codebase, I can provide the following breakdown:
Total LOC Count:
Core app files: ~1,500 lines
UI Views: ~1,000 lines
Screens: Multiple directories with varying sizes, approximately 2,000+ lines -
@Lensflare
Networking and Data: ~400 lines
Total estimated LOC: ~5,000-6,000 lines
Boilerplate Code (~25%):
- App configuration files (Info.plist, entitlements)
- Standard SwiftUI app structure (SwiftUIRantApp.swift)
- Standard iOS app lifecycle management
Declarative UI Code (~40%):
- SwiftUI view declarations in the UI/Views directory
- Screen layouts and navigation
- Custom UI components (LoadingButton, SegmentedPicker, etc.)
- Style definitions and theme management
- Layout and presentation logic
Original Imperative Algorithms (~15%):
- Custom business logic for handling DevRant-specific features
- Vote management and state handling
- Content filtering and sorting
- Custom data transformation logic
- State management specific to the app's needs
Raw Business Logic (JoyRant-specific) (~20%):
- DevRant API integration specifics
- Custom content handling for rants and comments -
@Lensflare
- Profile and user management specific to DevRant
- Weekly rants and community projects features
- Notification handling specific to DevRant's system
The codebase appears to be well-structured with a clear separation of concerns. The high percentage of declarative UI code (40%) is typical for a modern SwiftUI app, while the relatively low percentage of raw business logic (20%) suggests that much of the app's functionality is either handled by the SwiftUI framework or the underlying DevRant API client.
The app seems to be primarily focused on providing a native iOS interface to DevRant's features, with most of the complex business logic being handled by the SwiftDevRant library, which is why the percentage of original business logic is relatively low. This is actually a good thing as it means the app is leveraging existing, tested code for the core DevRant functionality while focusing its efforts on providing a great user experience through its UI implementation. -
@Lensflare see, oh mister destroyer of clown languages whose code is above us peasants, that your code is mostly boilerplate, and what isn't boilerplate is the same declarative UI which is exactly as declarative as HTML and CSS, plus 20% of imperative code that (surprise-surprise) glues native APIs together and wraps things, AND THAT'S OKAY.
My point was that this is typical and this is okay, in any modern app that isn't an OS core, a compiler or other stuff neither you not me is good at.
Your native Swift app has exactly the same contents as any (nicely written, because your code is quite solid) React or Angular app. The only difference is that yours is written in a more modern language with less footguns that only managed to be like this because it didn't have to provide unprecedented levels of compatibility with 20 years worth of legacy code of all kinds. -
@kiki JoyRant is a rather trivial example and is not the typical app that I make at work.
I see where you are coming from, many apps are like this and if that‘s your main job, the language doesn’t matter that much.
Your claim is that it extends to literally anything in development and language doesn‘t matter.
I reject that claim because in my experience language does matter.
You seem to be feeling attacked by my comment. Please do realize that you chose to be as snarky in your rant as I was in my comment. -
@Lensflare what do you make at work?
-
@kiki mainly iOS apps, but I‘d rather not tell which to not disclose where I work.
-
@kiki
You are aware that qsort is already part of the C standard library since 30 years ago, right?
And yes, yes, if you are gonna get exquisite it's actually not mandated by the standard that it must implement quick sort, but all major implementations do.
You are also aware that CPython uses C qsort, right? -
@CoreFusionX don't know about cpython. I say that Python's timsort as implemented will be faster than quicksort written from scratch in C
-
@kiki
CPython is the reference (and fastest) implementation of python.
Any python sort implementation that doesn't use intrinsics will always be slower than C qsort, or than any equivalently implemented sorting algorithm.
If only because python objects always result in pointer deferences, which is orders of magnitude slower than fast L3 access. -
@CoreFusionX sorry, I confused cpython with that thing that compiles python code into binaries. You're right.
-
@retoor yeah, parsers are legit algos. This is why you write them in C
-
@Demolishun no, because the analysis of JoyRant shows that it has essentially the same structure as any web app.
I never understood the programming language discussion thing. In modern programming, all you do is gluing APIs together, no matter if they're third party or built-in. My JS code is literally 95% fetch() followed by querySelector.
All built-in APIs that do something useful are just linking C++ modules. If you're not doing stupid shit, Python is exactly as fast as C++ or Rust.
The only scenario where speed matters is algos. Guess what? You should write your algos in C and link them to your Node/Python/Go/whatever code. And don't even get me started on reinventing algos. Do you really think you can write an algo in one evening that will be more efficient than what the guy whose PhD thesis it was a part of?
Just because some engine parts require the precision only a million-dollar CNC machine can provide, doesn't matter you have to cut the whole car out of a solid block of high-performance engine block alloy.
Remember kids, sorting array in Python is always faster than sorting array in C, because Python's sort was written by someone else who's smarter than you, went through years of scrutiny and iteration, and doesn't have stupid novice algo complexity errors.
Grow up.
random