But rarely do we look at our own very work the very same way. We wish to liberate accountants and ware house workers from drudgery. What's worse they also carry that kind of thinking to any tool they want to use.ĭevelopers are generally bad at automating our own work. It's a tool largely designed for beginners and people refuse to move beyond that. Growth of Python is a big problem for programming community at large. If you are wasting man-hours to weeks doing what should be done in man-minutes you probably have a huge gap in the way you are used to thinking about how your work in general. To me that's kind of a gap in developer training itself.
#Find textmate manual#
Sometimes its entirely manual effort because eventually you need to learn Perl regexes, or sed or awk really well, and that's another black hole in itself. Most people tend to write tons of shell/perl/python scripts and take a lot of time recreate the magic of emacs outside it, Sadly most of it is also throw away effort with a lots of manual effort in between. Vi usage is here to stay, even if not heavy usage, some one has to always change something in a file on a server and has to use vi.Īpart from that, Emacs usage mostly correlates how much of text heavy tasks a programmer is doing. Personally, I'm not looking to increase the ways that I'm locked into my current operating system, so all else equal, I'd favor an editor that runs everywhere. They want someone to have written the plugin/extension they're looking for. It makes sense that developers would trade stock platform-widgets in exchange for an editor with greater cross platform reach because users of these tools benefit from network effects of these tools having wider reach. You might be able to make the case that using stock widgets matters for non-developer tools (and I would only partially agree there), but for developer tools when people say they want "native" they are more likely to mean they want the performance that more often comes with natively compiled languages without a VM. The problems that people have with the dominant players that have gained traction is the performance. They are the ones that have become dominant. Just look at the market share of developer tools and IDEs/editors that don't use stock platform widgets. I'll adopt whatever definition you want "native" to mean for the discussion - and under your definition of native, I would say it's pretty clear that users of text editors and developer tools don't care much at all about "native"(your definition of using the platform provided widgets).
#Find textmate mac#
(Shortcuts on iOS is trying, but it's not on the Mac yet, and it gets pretty clunky if you start doing overly complicated automation bits with it.) I don't think we have a "modern" replacement yet - certainly not in the Apple ecosystem, and I'm not sure anywhere else. I actually think it's a shame that AppleScript has been kicked to the curb. You arguably can't script the AppleScript-intensive BBEdit to the same level that you could, say, Emacs or Vim, but imagine the possibilities of a suite of apps from different makers that all had complete scripting dictionaries that could all be woven together with a deep system-wide scripting language. Applications can provide "dictionaries" of commands that, when implemented well, provide GUI applications with the kind of "snap together for amazing effect" you get with shell scripts and a host of well-written CLI tools. TextMate never had AppleScript integration, AFAIK.Īlso, I'm not convinced we should ignore those "archaic" technologies, at least in the abstract.
0 kommentar(er)
