Comment Re:Yes, I agree (Score 1) 564
You seem to be very much agreeing.
You seem to be very much agreeing.
No, I just envisage what will happen when this is introduced on Windows.
And again your thinking is being limited by Windows. It's like dismissing pneumatic tyres because they don't fit on horses hooves.
But adding metadata to files that is not "in your face" is not the best suggestion I've seen for that.
Whilst we could debate the usefulness or not of file types being in your face, there was precisely nothing of that suggestion in my post. As I've already told you in the post you're replying to.
Obj-C is not as portable as C++
And C++ isn't as portable as C. Or as efficient.
There really is no downside to using C++ in core code rather than Obj-C.
But there are downsides to using it in this capacity rather than C. Which is why few do so.
Cross-platform compatibility of C++ code is excellent these days, C++ can call low-level Apple APIs exactly as well as C, and there is no performance cost to C++ unless you choose it.
1) Good but not as good as C.
2) But it's an unnecessary third layer. Obj-C has the objects. C has the speed and compatibility. What do you need a third layer for?
3) Indeed. So virtually no one uses it in this scenario.
Only time I see it used is when it's a library that was written in C++ on another platform and is simply being used on a Mac.
some meta-information that's probably hidden by default.
Who says it's hidden? There's nothing special about a a filename that means it is visible in the UI. As this very story shows.
You're thinking is being limited by what you are used to. You're lacking imagination to envisage better alternatives.
Expecting users to notice the filetype and act cautiously is not much of a security technique. Security should be imposed by the system, and the system can see all of the filename and all other metadata and contents too.
No. A user should be able to trust the name of the file.
They can. The user is guaranteed that the name of the file is what the filename is. They can have 100% trust in that.
You seem to be confusing that with file types. Your name is jedidiah (or at least your alias). But that's not your file type. I assume you're human. Yet we don't call you jedidiah.human.
Spaces in names is a pain when you're typing at the command line......who wants to have to type quotes around their file names?
Geeks et angry over perceived limitations in GUIs. Yet they give the limitations of a CLI a pass. Here the fault is with CLIs. How braindead that a valid file character is used as a separator.
Elimination of clutter focusses the mind. Whilst to the hoards of sysadmins and IT workers that congregate round here file types aren't clutter, to users they are.
Because it has been demonstrated for a long time that it can be dangerous to hide stuff.
So if I set something to be "malware.jpg.exe", Microsoft will present that as "malware.exe".
That doesn't demonstrate it's dangerous to hide stuff.
It shows first of all that it's a bad idea to have file type encoded in the filename. But secondly, OSX doesn't have this danger, whilst still allowing hiding filetypes in more normal situations. i.e. If you have hidden filetypes, a filename that have a double file extension will still display in full to highlight the attempt.
The bug here is not that extensions are hidden.
Thinking about the bigger picture...
If it's the "same file", then really the bug is that a single "document" ought to be able to hold multiple formats for those different purposes.
If it's not really the same file, then the bug is that the OS has allowed the person to call multiple documents by the same name.
Showing extensions is a bodge. A quick hack. Not the proper fix to an OS.
OSX Has used file extensions exclusively as the file type for a while now. You might edit a filename to remove the file extension and see that it still has an app icon, and think that file names are optional. But all that's really happened is that the "hide file extensions" flag has been added to that file. Use CMD I to see what's really going on when you rename a file in finder.
So the file extension is actually a good way to know what type of file it is.
No, it's brain dead. The filename is a name. The filetype should be another piece of metadata. (and not just an executable flag either - a complete file type.)
If the file type needs to be seen by the user, then that's a UI design issue, not a reason to have brain dead mixed purpose metadata fields.
Good operating systems don't use part of the filename to store the file type. It's 2015. File types ought to be indicated by mimetypes or some other such metadata unconnected to the name.
Sadly we're limited by everyone copying the lowest common denominator.
With Apple switching to swift, you'll be learning an orphan language. Best bet is to learn c, then c++. This way you get the basics first.
If someone was planning on learning a language as a stepping stone to Swift, c or c++ would be a bad choice, leading to developing bad habits that will cause frustration when moving to Swift. As I understand it they'd be best learning a functional language, after which they'll approach problems in a way which fits very well with Swift's world view.
I can't recommend the particular functional language, as I DID come up the procedural/oo path.
However, if you think you're going to make money developing for OSX starting from zero, seriously, what universe do you think you're in?
As an indie, perhaps. But salaries are good in OSX/iOS programming.
For God's sake, stop researching for a while and begin to think!
