If you're marking up arbitrary prewritten text, then yes, I agree. But if you mark up as you write, then Markdown really does save you a ton of time. You can try out new headings, split paragraphs, etc—without worrying about balancing tags.
It's really intended to be a writing aid, not a markup or styling tool. I've been writing HTML since 1994 and swear by Markdown—so much so that I ported it to Objective C. I use InDesign to layout print materials, but I would never write directly in it.
It would run fine... Game engines are just not that CPU intensive, and JS can do a few megaflops on low end hardware. The reason no one has done a game that elaborate in JS is that there's no way to charge for it.
Right, but that's not a technical issue; it's a policy issue. If people started buying web apps, there would be tremendous demand for Apple to turn on WebGL and JS optimization, and they'd do it.
I hate to say it, but in the world of end-user apps, Javascript won. (Note that I'm not talking about niche applications like 3D rendering or server software.) And I write this as a committed Mac and iOS developer. Moore's Law and improved JS compilers have made Javascript responsive enough for 99.9% of applications. Native end-user apps will stumble along for a while, but they're walking dead.
There are no more technological hurdles for Javascript to overcome. The payment model is the last nut to crack. Firefox is working on that. Maybe it'll take a bigger player to make it happen. But make no mistake: it will happen. It'll happen because it's cheaper to pay one development team that can deploy to every device.
As recently as last year, Facebook moved away from mobile to native, but that move already looks amazingly dated. Since Facebook moved from "HTML5" to native ObjC, Apple released the iPhone 5, which was over twice as fast as the 4s, and then the 5s, which is about twice as fast as the 5. The Javascript version of Facebook may have felt unresponsive on an iPhone 4 or 4S, but those days are history.
A lot of people may be reading this and thinking "yeah, yeah, people have been talking about 'write once, run anywhere' for decades." They're right—we've been staring at the oncoming freight train for decades, and now it's finally here. If you write end-user apps and you're not polishing your Javascript right now, that train will roll right over you.
Yes, I develop apps for both platforms. Both OS X and iOS are brand names for an Apple-augmented version of Darwin—a POSIX-compliant UNIX OS. It's the same OS with a different face.
They share so much that they even use the same drawing layer. In Linux terms, that would be sort of like if Android ran X Windows, and it was the same flavor of X Windows as Ubuntu. (In fact OS X and iOS share way, way more than Android and Ubuntu.)
The biggest difference is between OS X and iOS is obvious: the UI. The reason for the difference is also obvious: one of them is touch-based. The UI layers (think window managers) are named AppKit and UIKit, and they share many similarities. Many of the APIs are nearly identical.
About the only thing they don't share is binary compatibility, because iOS is made for ARM as opposed to x86. However, this is not a technical hurdle; Mac and iOS applications are designed to handle multiple architectures. Technically, Apple could allow Mac applications to include an ARM64 binary, or iOS apps to include an x86 binary. Practically, the differences in input devices wouldn't be ideal, so Apple hasn't done it yet.
But make no mistake; it's the same OS, and they could ship truly Universal apps tomorrow. In fact, there's currently a rumor circulating that Apple wants to consolidate slightly, and produce MacBook Air notebooks running ARM. Given the performance of the 5s, they may be on to something.
Absolutely. I'm working on a camera app that does image processing, and it can handle 400 megapixel TIFFs all day. There's no excuse to load an entire image into RAM just because it's more convenient for you as a developer.
The whole RISC vs. CISC thing blew over when I was still in short trousers!
Precisely my point. Unless you write assembly, you don't even need to think about it.
Yeah... and if you wish to make an Apple pie from scratch all you would have to do first is invent the Universe.
Eh? I've moved tens of thousands of lines back and forth between iOS and MacOS, 32bit to 64 bit. It's essentially painless. Did you have an actual point?
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X, so at this point virtually all processor-dependant code has been abstracted away. They could switch the Mac Pro to a 128 core 32 bit ARM chip—or the iPhone to an Intel 64 bit chip—and all you would have to do is recompile. So yes, the transition will be easy.
Regardless, it's 2013. If you're writing assembly or ultra low-level C and you aren't simultaneously writing generic fallbacks, then you're basically "doing it wrong."
The entire idea of an "exit strategy" exemplifies what's wrong with startup culture. An entrepreneur should be focused on building a great product and a lasting company, not on finding someone to cash them out after 18 months of part-time schmoozing.
Oh, I think execution speed is overrated anyway. In terms of user interaction, 30ms is the same as 150ms: "fast." If you have to do some heavy lifting that will take multiple seconds to compute in Python, you can always dip into C for that section.
But yes, the ease of typecasting and assignment are double edged swords in C. They can save you a lot of time, but it's easy to cut yourself. That's why, like many C developers, I use typedefs and structs heavily, and avoid using arrays for data types. For example, I would never define a color as:
Of course this doesn't prevent me from assigning someColor.red = somePoint.z, but hopefully if I didn't mean to do that, it's a little easier to catch than someColor[0] = somePoint[3];.
But I often need to store a small array of those colors or points, and the C array mechanism is very helpful. And needless to say, when iterating over an image, the pixel buffer is most naturally addressed as an array (for CPU-based processing, anyway).
Hmm. An array has no intrinsic meaning? It's a list. I mean if we're going to get deep, nothing has any intrinsic meaning, man, but I don't think that's what you're trying to say. Can you explain?
As a C developer, I often need to collect a list of things and then iterate over them in a very specific order—whether it's computing a rolling average or just storing a list of items in a table for display. Not to mention the image processing I do, which depends on 1D, 2D and 3D arrays.
I don't know... I'm scratching my head over here. What am I missing?
Have you seen their recent work with predictive tracking? It seems they were able to improve the perceived lag a great deal from the version that shipped with the developer SDK.
I still don't buy it. What you're describing is passion, not talent. You're not born knowing C, and if you take to it quickly, it's not talent, it's just passion. Of course some people are better creative problem solvers, but that's just another skill; not talent.
When I wrote "can," I meant it in terms of potential, not ability. I should have rephrased that. My point is that we essentially brainwash people to think they can't do things outside of their specialization. It's a shame, because many times an outside perspective can provide a fresh idea.
That's my point; people have the potential to do either or both, but they're pigeon-holed into a specialization. You still need to develop those optimization or strategic thinking skills to realize that potential, but I maintain that it's just a different kind of creativity.
...and so is the idea of being "gifted." Pardon this little rant, which is not directed at you, AC, but what we call "talent" is essentially skill plus passion. When a person is phenomenal programmer, or writer, or guitar player, they didn't get that way because it was gifted to them. They either put in thousands of hours practicing, or they had an all-consuming passion for it.
So skill wins out in this reductive comparison, because in technology, you must be creative to be considered skillful.
That's true, and it's sad. People overspecialize these days, and underestimate themselves as a result. If you can optimize integer math, you can think big picture, and vice versa. Creativity is creativity.
Ugh, I wish I could moderate this +1000. Javascript is actually fast. The reason people think it's slow is that they're loading elephant.js, cucumber.js, antidisestablishmentarianism.js, squeek.js, and basically any word appended with ".js"
Your use sounds pretty professional to me. Your options are: pay $20 / month for Photoshop, buy an old copy on eBay and forget about upgrading, or fork GIMP and start coding.
You would be shocked to know how many different industries rely on Photoshop. It's not just magazine retouchers. There's a reason why Photoshop is such big business. If GIMP was going to have an impact on Adobe, it would have happened already. It's fun enthusiast software, but it's basically a red herring when discussing whether or not Adobe can make money selling Photoshop.
Slashdot Mirror
If you're marking up arbitrary prewritten text, then yes, I agree. But if you mark up as you write, then Markdown really does save you a ton of time. You can try out new headings, split paragraphs, etc—without worrying about balancing tags.
It's really intended to be a writing aid, not a markup or styling tool. I've been writing HTML since 1994 and swear by Markdown—so much so that I ported it to Objective C. I use InDesign to layout print materials, but I would never write directly in it.
For writing on the Mac, I swear by Mou.
It would run fine... Game engines are just not that CPU intensive, and JS can do a few megaflops on low end hardware. The reason no one has done a game that elaborate in JS is that there's no way to charge for it.
You have it backwards—developers will hate the move to JS, and users won't notice. It's exactly the opposite of what you describe.
Developers won't do it willingly, but their clients and/or employers will demand it. It's strictly financial.
Right, but that's not a technical issue; it's a policy issue. If people started buying web apps, there would be tremendous demand for Apple to turn on WebGL and JS optimization, and they'd do it.
I hate to say it, but in the world of end-user apps, Javascript won. (Note that I'm not talking about niche applications like 3D rendering or server software.) And I write this as a committed Mac and iOS developer. Moore's Law and improved JS compilers have made Javascript responsive enough for 99.9% of applications. Native end-user apps will stumble along for a while, but they're walking dead.
There are no more technological hurdles for Javascript to overcome. The payment model is the last nut to crack. Firefox is working on that. Maybe it'll take a bigger player to make it happen. But make no mistake: it will happen. It'll happen because it's cheaper to pay one development team that can deploy to every device.
As recently as last year, Facebook moved away from mobile to native, but that move already looks amazingly dated. Since Facebook moved from "HTML5" to native ObjC, Apple released the iPhone 5, which was over twice as fast as the 4s, and then the 5s, which is about twice as fast as the 5. The Javascript version of Facebook may have felt unresponsive on an iPhone 4 or 4S, but those days are history.
A lot of people may be reading this and thinking "yeah, yeah, people have been talking about 'write once, run anywhere' for decades." They're right—we've been staring at the oncoming freight train for decades, and now it's finally here. If you write end-user apps and you're not polishing your Javascript right now, that train will roll right over you.
Yes, I develop apps for both platforms. Both OS X and iOS are brand names for an Apple-augmented version of Darwin—a POSIX-compliant UNIX OS. It's the same OS with a different face.
They share so much that they even use the same drawing layer. In Linux terms, that would be sort of like if Android ran X Windows, and it was the same flavor of X Windows as Ubuntu. (In fact OS X and iOS share way, way more than Android and Ubuntu.)
The biggest difference is between OS X and iOS is obvious: the UI. The reason for the difference is also obvious: one of them is touch-based. The UI layers (think window managers) are named AppKit and UIKit, and they share many similarities. Many of the APIs are nearly identical.
About the only thing they don't share is binary compatibility, because iOS is made for ARM as opposed to x86. However, this is not a technical hurdle; Mac and iOS applications are designed to handle multiple architectures. Technically, Apple could allow Mac applications to include an ARM64 binary, or iOS apps to include an x86 binary. Practically, the differences in input devices wouldn't be ideal, so Apple hasn't done it yet.
But make no mistake; it's the same OS, and they could ship truly Universal apps tomorrow. In fact, there's currently a rumor circulating that Apple wants to consolidate slightly, and produce MacBook Air notebooks running ARM. Given the performance of the 5s, they may be on to something.
iOS (then iPhone OS) basically is a miniaturized OS X. Nothing changed.
Absolutely. I'm working on a camera app that does image processing, and it can handle 400 megapixel TIFFs all day. There's no excuse to load an entire image into RAM just because it's more convenient for you as a developer.
Gelatin won't work—the technology in the Touch ID sensor requires a live finger.
The whole RISC vs. CISC thing blew over when I was still in short trousers!
Precisely my point. Unless you write assembly, you don't even need to think about it.
Yeah... and if you wish to make an Apple pie from scratch all you would have to do first is invent the Universe.
Eh? I've moved tens of thousands of lines back and forth between iOS and MacOS, 32bit to 64 bit. It's essentially painless. Did you have an actual point?
Apple has transitioned 32 -> 64 bit and RISC -> CISC already with OS X, so at this point virtually all processor-dependant code has been abstracted away. They could switch the Mac Pro to a 128 core 32 bit ARM chip—or the iPhone to an Intel 64 bit chip—and all you would have to do is recompile. So yes, the transition will be easy.
Regardless, it's 2013. If you're writing assembly or ultra low-level C and you aren't simultaneously writing generic fallbacks, then you're basically "doing it wrong."
The entire idea of an "exit strategy" exemplifies what's wrong with startup culture. An entrepreneur should be focused on building a great product and a lasting company, not on finding someone to cash them out after 18 months of part-time schmoozing.
No, Dog loves these solar systems—he needs somewhere to store all those half-chewed slippers.
Oh, I think execution speed is overrated anyway. In terms of user interaction, 30ms is the same as 150ms: "fast." If you have to do some heavy lifting that will take multiple seconds to compute in Python, you can always dip into C for that section.
But yes, the ease of typecasting and assignment are double edged swords in C. They can save you a lot of time, but it's easy to cut yourself. That's why, like many C developers, I use typedefs and structs heavily, and avoid using arrays for data types. For example, I would never define a color as:
double rgb[3];
But rather:
typedef struct { double red; double green; double blue; } ColorTriplet;
Of course this doesn't prevent me from assigning someColor.red = somePoint.z, but hopefully if I didn't mean to do that, it's a little easier to catch than someColor[0] = somePoint[3];.
But I often need to store a small array of those colors or points, and the C array mechanism is very helpful. And needless to say, when iterating over an image, the pixel buffer is most naturally addressed as an array (for CPU-based processing, anyway).
Hmm. An array has no intrinsic meaning? It's a list. I mean if we're going to get deep, nothing has any intrinsic meaning, man, but I don't think that's what you're trying to say. Can you explain?
As a C developer, I often need to collect a list of things and then iterate over them in a very specific order—whether it's computing a rolling average or just storing a list of items in a table for display. Not to mention the image processing I do, which depends on 1D, 2D and 3D arrays.
I don't know... I'm scratching my head over here. What am I missing?
Have you seen their recent work with predictive tracking? It seems they were able to improve the perceived lag a great deal from the version that shipped with the developer SDK.
I still don't buy it. What you're describing is passion, not talent. You're not born knowing C, and if you take to it quickly, it's not talent, it's just passion. Of course some people are better creative problem solvers, but that's just another skill; not talent.
When I wrote "can," I meant it in terms of potential, not ability. I should have rephrased that. My point is that we essentially brainwash people to think they can't do things outside of their specialization. It's a shame, because many times an outside perspective can provide a fresh idea.
That's my point; people have the potential to do either or both, but they're pigeon-holed into a specialization. You still need to develop those optimization or strategic thinking skills to realize that potential, but I maintain that it's just a different kind of creativity.
...and so is the idea of being "gifted." Pardon this little rant, which is not directed at you, AC, but what we call "talent" is essentially skill plus passion. When a person is phenomenal programmer, or writer, or guitar player, they didn't get that way because it was gifted to them. They either put in thousands of hours practicing, or they had an all-consuming passion for it. So skill wins out in this reductive comparison, because in technology, you must be creative to be considered skillful.
That's true, and it's sad. People overspecialize these days, and underestimate themselves as a result. If you can optimize integer math, you can think big picture, and vice versa. Creativity is creativity.
Ugh, I wish I could moderate this +1000. Javascript is actually fast. The reason people think it's slow is that they're loading elephant.js, cucumber.js, antidisestablishmentarianism.js, squeek.js, and basically any word appended with ".js"
Your use sounds pretty professional to me. Your options are: pay $20 / month for Photoshop, buy an old copy on eBay and forget about upgrading, or fork GIMP and start coding.
If you can't justify the ROI on $20 / month for Photoshop, it must not be very important to your business.
You would be shocked to know how many different industries rely on Photoshop. It's not just magazine retouchers. There's a reason why Photoshop is such big business. If GIMP was going to have an impact on Adobe, it would have happened already. It's fun enthusiast software, but it's basically a red herring when discussing whether or not Adobe can make money selling Photoshop.