311–320 of 335 posts
Earlier quoted context omitted.
Then try to write Metal shaders in Objective-C.
Metal shaders != Metal API. Metal API is Obj-C. Metal shaders are written in MSL (Metal Shading Language). C++ is still not involved, though MSL is admittedly based on C++.
https://developer.apple.com/metal/Metal-Shading-Language-Spe...
"The Metal programming language is a C++14-based Specification with extensions and restrictions. Refer to the C++14 Specification (also known as the ISO/IEC JTC1/SC22/WG21 N4431 Language Specification) for a detailed description of the language grammar. This section and its subsections describe the modifications and restrictions to the C++14 language supported in Metal."
Also, the MSL and Objective-C compilers are built on top of LLVM, written in C++.
This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases. Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform i…
Could you explain what you think of the pros and cons of flutter VS IONIC? I think flutter and it's astonishing number of issues on github + their lack of manpower + their lack of major features + the presence of major performance and behavior bugs + the extremely small lib ecosystem (dart) is a major, useless risk for a startup for the benefit of tech hype. (just my point of view, don't take it personally)
Ionic lets me build a web app and publish it to any device pretty easily. I don't have to use their components either... in fact after using Ionic, you may not use Ionic anymore at all. All you need is Capacitor to publish it.
Flutter is it's own rendering engine, non-standard web language (Dart), and ecosystem. Ionic is just a CLI and collection of web components. Capacitor is Ionic's version of Cordova. It gives you access to device capabilities such as storage, camera, etc with very little code. So you can build a website, ask if it's Native on a device, and do more cool things if it is. Then push it to Android, iOS, and the Web.
Ionic supports Angular, React (now in RC0), and Vue (Beta). This allows you to learn popular frameworks while still developing with one code base.
Lastly, Ionic's Web Components are built using standard-compliant Web Components generated by a tool they made called StencilJS. So, now you can build a component in Stencil and publish it for simply the Web (No framework) or have them work with Angular, Vue or React. Larger corporations have started using StencilJS to manage their components when they use many frameworks. I use it because I don't know which framework I'll use next, or if I'll even use one.
Earlier quoted context omitted.
Enjoying lock-in - that's a new one. Instead, I enjoy breaking it (for example by using dxvk).
What you call lock in, we in the industry call productivity of being able to use SDKs not stuck in 80's UNIX world, full of endless extensions. Instead of shouting from a soap box that no one cares to listen to, get Khronos to actually provide a 21st SDK tooling. Then Sony, Microsoft, Nintendo (Vulkan is 2nd class on the Switch), Apple, Hollywood and all their partners might care. Until then, the wind takes it all.
Of course those who push lock-in like to present it as a positive thing and hide its real nature, but it's just a smokescreen which is easy to see through. Once in a while, they just can't help it, and express their real views: https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_...
Anyway, I don't think explaining this to you in particular is useful. You know it all well, but pretend it's a good thing. Which is very shill-like.
Unlike you, even developers of such lock-in stuff admit, it's a bad thing for the industry. Those who are interested, can find comments by Dan Baker (from Oxide Games) for example, who is a former developer of DirectX.
Earlier quoted context omitted.
I think it's exactly because they are so complex that those engines can afford to share a lot of code between platforms. For smaller and/or simpler applications, it's probably not worth it to deal with the cross-platform complexities.
Modern video game development is anything but simple.
Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Electron. All built in house though. They hired me as a JS/HTML/CSS dev, but same as the article states, the C++ work was the true bottleneck. They knew I had some C++ chops and set me to work doing C++ with a sprinkle of JS here and there. Due to incompatibilities…
> And lastly, as the article stated, we had a hard time finding new talent to cover the growing amount of work required to deliver our product. There just aren’t many C++/JS devs out there. Reading the article and now this, I really can't grok this perception. There are plenty of us out here, I think, it's just we're buried in the heap caused by mass resume farming, aka modern recruiting. Recruiters and hiring manage…
As for finding people like yourself, all I kept hearing was that they had trouble finding new people to fit their specific needs.
I agree with you though, there is likely a lot of missed opportunities due to the resume farming going on and bad filters.
Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Electron. All built in house though. They hired me as a JS/HTML/CSS dev, but same as the article states, the C++ work was the true bottleneck. They knew I had some C++ chops and set me to work doing C++ with a sprinkle of JS here and there. Due to incompatibilities…
> Due to incompatibilities in the compilers, there was a rats nest of dependencies, thousands of #ifdef’s to cover differing OS implementations, and we had to use some of the oldest versions of C++ to be compatible with both XCode and Visual Studio. My current work has me on a single C++ code-base for Linux, Windows and MacOS (not electron though, just native). You can avoid a lot of headaches by avoiding the platfor…
Unfortunately, once you get into users wanting OS specific feature support, all that goes out the window.
You now are forced to maintain multiple versions of your product that differ greatly per operating system.
Pair that with the fact the codebase was almost 20 years old, you get some fun legacy code support issues that a lot of C++ projects naturally have due to the fact that C++ is not a new language.
Recently worked at a company doing similar to this to support Windows and macOS. To add to the difficulty, they used Chromium as a UI front end much like Electron. All built in house though. They hired me as a JS/HTML/CSS dev, but same as the article states, the C++ work was the true bottleneck. They knew I had some C++ chops and set me to work doing C++ with a sprinkle of JS here and there. Due to incompatibilities…
I'm currently working on some code that is for VS/Windows, Clang/macOS, and GCC/Linux. I'm just setting the std to C++17 on all of them with no extensions. I have had some warnings that have sprung up on some platforms, but not others. But I haven't run into any show-stopping incompatibilities for vanilla C++17. What should I be looking out for? Or was this a matter of using different standards on different compilers…
However, in our case (like with many C++ code bases) the code was almost 20 years old. Even with the Herculean efforts made by the teams to keep the code base up to date and refactored, you run into issues of backwards compatibility with older libraries.
C++17 is definitely the go to for new projects! However, I've never personally worked on a pure green field project written in C++ that didn't have to latch onto some older libraries that require older C++ std versions.
I often struggle trying to explain to more junior developers that there are times when it's OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite. Sometimes, it's OK to write the same thing twice if the alter…
At the very least you need to repeat yourself in as much as repeating the names you defined for constants, variables, macros, and functions when later invoking them. A program written in the limit of the style of don't repeat yourself either repeats these names many times and/or has too many layers.