I'm not a programmer, please forgive me, but I love using sublime as of writing tool for legislation and public policy in my work. The color coding system popular in programming, has been invaluable in drafting legislation.
super interesting!
I'm thinking out loud: could be possible that there is niche waiting to be untaped with new tech–tools for lawyers (and others professions)?
Edit:
I mean, no high–tech, but tools with a higher level of complexity where the UI isn't a dumbed down version, and where the software exposes some functionality to a better skilled user.
I'm thinking the "millennial" professional, should be more comfortable with software and pushing the limit a little bit.
I'm a third year law student (well, my last day was this week!), and I've been using Sublime to take notes and outline things for class. I use a custom syntax highlighting (modified version of the markdown syntax) to make it easy to read.
It is common for law students to digest course material into a short-ish (20-30 pages, depending on the class) outline of the material, as a way of studying. With my modified syntax highlighting config, I use different color bars to represent different level headings to make it easy to see how my document or outline is organized.[1] I then have a latex template for pandoc which lets me convert it to a beautiful document that is useful during open-book exams.
Using Sublime as a WYSIWYM editor is much more pleasant, as the editor is far more responsive, than using a WYSIWYG editor (like MS Word). I actually recently wrote a paper for class entirely in Markdown in Sublime. Pandoc lets you convert markdown to PDF (it uses latex internally), and when you convert to docx format for Microsoft Word, you can use a reference file to define the style formats. It's really easy to write something like a brief or a memo and convert it with a reference file to a format that others can work with, properly styled.
This is pretty neat. As a programmer, my editor not only color codes, but it gives me sort of hyperlinks to other definitions i am using/referencing, both to others work and my own. It also provides me hints and help about the current context i am writing about (working in), and it is often very relevant to what I am currently working on. that help is invaluable.
I'm actually building a note-taking webapp based around Markdown! I was wondering what features you found lacking or wish you had with your setup? (and if you'd like to try it out feel free to dm me)
I desperately want git-style DVCS for complex contract drafting with multiple contributors. It needs to handle a Word docx file natively, so it'll me do blame on a line, merge changes, all that good stuff, as well as retain proper version control so I have one file on my drive instead of a hundred variants of v1_changes_final.updated.doc.
There is no reason why plain text wouldn't work. You have something like Pandoc (with a markdown type text) convert the text to your format (Word docx for example or a PDF).
Difficulty there is collaboration with various groups that are completely set on Word. Some of those groups are external: in most cases contract format is dictated by the client and that invariably means a Word document laid out in their specific structure with tables for deliverables and subheadings and boilerplate and the rest. Reverse-engineering hundreds of those things into something Pandoc can spit out is a giant challenge and likely a bit fragile. Then you have internal legal function which uses Word and various workflow plugins to do their job of sense-checking all of it.
The obvious suggestion would be to have internal groups (excluding legal) collaborate on some common plaintext markdown format where DVCS tools would provide an advantage, then publish to docx and hand over to legal for review. Unfortunately what always happens is that major changes to the contract are needed after legal has done their work, and it's easier (and acceptable) for all groups to work on the final paper together. That's where it breaks down.
I really feel that in 2016 having some poor bastard do clerical coordination of this stuff is just wrong. It's a mechanical task that's highly both error prone and a major source of operational risk, and it should be doable by the computer.
I actually kind of want to build this. Word (and the rest of office, I have the same problems with spreadsheets and powerpoints) plus plugins as the IDE, solid version control in the backend.
Why exclude legal? Understanding a commit graph isn't too technical.
As far as I know, passing docx files back and forth is more similar to working with git than a google doc, so the workflow also wouldn't be dramatically different.
If it was a "web" app and people approved of PDF files that are of a certain version it could track changes based on responses back from the PDF approval process.
Through git and pandoc in the background and put a UI on top that is idiot proof and boom.
The funny thing here is that, if people wouldn't rename the document, Word handles change control natively (including comparison of versions). You can also do it with documents named differently, but the bad habit of baking each file differently really makes that a mess.
Given how many developers I've seen use Sublime, in the modern age of social media I'm so surprised SublimeHQ is still invisible. They hardly do any marketing that I've seen online, no social media engagement, nothing. Not necessarily a bad thing, but Sublime just seemed -primed- to be that sort of company with a hyper-engaged user base.
Looks like it works IF you have something to say, the topic is an important one and your audience knows how to listen... and all the others are yelling. (the translation into the zeit-geist of marketing deliberately not provided)
Also every time this under-marketing and under-hype of sublime comes up I wonder if we already reached the stage were semi-objective and subjective evaluation of tools is not enough to legitimate their use, if some sort of "hype" is necessary to release users from the burden of own evaluation and decision making...
Is marketing and hype a feature?
Is there maybe a generation of developers missing the pure joy of using under-hyped yet powerful hidden-gems?
Also: code-editors lagging at text input with the history leading to this funny state of affairs must be an entry in the encyclopedia technica for this civilization. ;) /scnr
And despite their lack of "social media engagement", they do have a Twitter account (@sublimehq) with nearly sixty thousand followers - and they tweet just about as regularly as updates for Sublime Text are released!
I've been using Visual Studio Code for a project recently. I told myself I would give it a try as I get pretty annoyed by the Sublime prompts and general wonkiness of the plugins.
It's not a real competitor by any means. I don't need git integration or a debugger in my IDE, these are wasted features for web dev (the best debugger is the browser because that's where the code actually runs...). I dislike how the "search across project" works - sublime presents search results on a huge screen, but Code is confined to the side bar, really difficult to find what you're looking for given ~250px of space. Code's code highlighting is very bare, it doesn't highlight enough for me, I have to read the code too much. And Code wants me to Tweet my feedback? They actually built twitter into an IDE? Wtf
It's just a typical Microsoft product; too little too late, and nothing special.
For your use case perhaps, debuggers are invaluable if you are using a backend language that isn't javascript, XDebug with Intellij is outstanding for those rare times you really need a proper debugger.
And I get that, in which case the developer would be better served to use one of those IDEs. Sublime text doesn't have a debugger and it's not really needed because of the type of work you would do in it. I wouldn't write Java or C# in sublime, why would I do that in Code?
To my point, Code is just a weird mish-mash of features. Is it an advanced text editor like sublime or is it an IDE? In either case, it's bad at both.
VSCode is still a bit far from ST. I still can't use VSCode for Go programming since it will randomly cause BSOD's, as well as several file-size and file-saving issues.
Gonna guess they're on Windows 7 and the graphics driver is crashing - VSCode enables hardware acceleration via a Direct3D DLL. I'd still like to get a hold of the memory dump to run `analyze -v`
I tried it for a few minutes and the lag and weight far exceeds Sublime... YMMV.
So no, from the available evidence, VSC and Atom, there is no way that an editor written in a heavily abstracted and interpreted language and VM can match the performance of Sublime.
The problem might be not JS but using DOM (every colored word has to be a separate node and every time you add or remove a letter there would be a reflow) instead of custom widget written in compiled language and heavily optimized for displaying colored text in monospace font.
Sublime uses high level language (python) too but not for rendering.
Probably because their success is essentially due to 1) picking up the ball that TextMate dropped and 2) there really aren't any alternatives that are truly competitive when it comes to both features, plugins, and speed, esp. across multiple platforms.
When moving away from ST2 (too many workspace/plugin issues), I strongly considered Atom. With plugins, I could replicate nearly everything I had spent a couple years setting up in ST2 config and plugins.
But then I landed a contract using vim, and found it has more functionality than both, if you're willing to spend the time. I especially like being able to SSH/Tmux into a session from a tablet remotely and pick up where I left off, even over slow connections.
loved my time with sublime, then atom crossed a line where, while not as good as sublime in some area, it got good in other areas... then... vscode came along and showed how snappy an electron app could be, but didn't have a lot of stuff.... then bam, it opened up, and still not as many toys as Atom, and not quite as slick as sublime, it hits a bit of sweet spot somewhere in between.
My biggest objection to Atom over Sublime is the memory overhead when opening even moderately large files.
I'm in ops rather than dev, so often deal with 10mb+ log files - but don't have a lot of the IDE type requirements of my colleagues. Sublime open them in seconds and is nice and quick to search through and look at. Trying to open a 10mb file in atom causes it to chew up 1.2gb of ram and it's laggy when scrolling nevermind when trying to search etc.
Sublime on the other hand not only starts up quicker and is more responsive, but it's only costing me 100mb of ram for my 10mb file as well as 20 others I've not bothered closing.
If I try and load a 100mb file in sublime it doesn't balk. Takes about 8 seconds to load, but once loaded it's amazingly responsive (to the point where I thought I still had my 10mb not 100mb file loaded). Atom attempts to open the file but takes forever and then dies after exhausting the 8gb ram on my laptop.
tldr: sublime feels stable, lean and fast vs memory munching and perceivably slow.
Edit: oh, and atom's installer is 104mb, the new build of sublime3 is 8mb.
edit2: Even after a clean boot atom just crashes trying to open a large file well before it fills up my memory, so no idea.
My only interaction with Atom so far was trying to paste a 8k chars line in a dojo on someone's recent mac pro. It crashed every single time and crashed again on opening as it was trying to load the file with the long line on startup.
In the end I had to use vim to open it, was instant and I could actually remove that line (not a vim user).
This was a concern of mine before switching from Sublime to Atom on the Atom 1.0 release, but I don't open moderately large files often so I really don't worry about it anymore.
There have been times where files have been too big even for Sublime Text to load on my Macbook without slowing it down. In those cases I've used Vim with the LargeFile plugin.
> Trying to open a 10mb file in atom causes it to chew up 1.2gb of ram
Truly?! That's a factor of 100x, that's ridiculous.
TBH, I'd kind of expect an editor to use a factor maybe 2x of the loaded file (for quick access indices, searching, etc). More if you count undo-buffers, of course.
I could well be reading the stats wrong, but yes; really - this is tested on Windows 7 64bit (latest updates). Opening Atom without any plugins, themes or files loaded seems to require approx 150mb just to be alive.
Depends what I'm doing. Sometimes I need to edit as well as just view them. I have seen the Atom text-tail plugin that keeps getting mentioned but when I went to install it the homepage says Atom now copes with large files so it's been depreciated... I have to be honest, at this point I lost interest and went back to sublime.
Call me old fashioned, but the #1 feature I want from my text editor is the ability to edit plain text files... everything else is gravy (though syntax highlighting and regex's are two "features" I really like).
Amusingly (and only tangentially related), I just realised that notepad.exe on windows 7, which I always remember balking at files in the single MB range copes with my 100mb test file amicably and only chews 225mb of ram (21mb for my 10mb test file).
I have tried both (vsc and atom) and they both have significant typing lag. I want my text editor to be snappy , don't care about fancy features. Unless they plan to port this to c++ or something I am happy with sublime text.
That's what I've found. I've been using Atom for a couple of weeks now and have decided to give up on it. I'm using it on a fairly substantial Macbook Pro and the start up lag drives me nuts. Back to ST3 I guess...
Human seem to have very different tolerances for latency. I've had someone call me over to their desk to show that Eclipse could be fast, and what they described as 'responsive' I find 'hair tearingly laggy'. He's not wrong, and I'm not right, we just have different expectations.
When it comes to typing lag specifically, anything more than "imperceptible" is too much for me, and I think most people would agree. Having said that, I have never observed any kind of typing lag from Atom.
So JavaScript is the reason different Atom users have different levels of lag? You realise they're all using JavaScript right? It isn't optional on Atom.
Disclaimer: I haven't used any of the 3 extensively, but I do play around in them from time-to-time. The main difference to me is that ST comes as a bare-metal editor with the potential to do just about anything, while Atom and VSC come with some built-in features that just make life easier and the ability to extend it further.
A concrete example would be VSC's git support; out-of-the-box, it's a full-featured git client, and even if you prefer the git cli for most operations like I do, VSC automatically reads the .git directory and then creates a tab that shows your current changelist (modified, staged) with a visual diff of the files. Also allows you to easily do the common stuff like checkout a branch, commit, push, etc.
If you're a big fan of ST, you probably won't like the alternatives unless you have some frustrations with ST, because ST is probably more powerful overall, but compared to Atom & VSC, the learning curve is also quite a bit higher.
The fact that a minor update got released isn't a rare enough occurrence to warrant a highly-voted post on HN.
Snark aside, VSC has grown up quite a lot, very quickly. If you like Sublime, good for you, stick with it. But it looks like VSC is going to pick up support for more new things, faster. Personal favorite: support exists to plug in third-party debuggers and get debug tools/build errors inside VSC.
The way people number their versions does not mean anything (React is actually in v15 now). 0.xx has no meaning, except if the developer of the software explicitly indicates it's unfinished. Version numbers are entirely subjective by default.
I agree with you on the stability of Sublime Text, but the label beta has, on the opposite of version numbers, a consistent meaning: it's not finished.
Can you tell me how many times have you used their advantage of being open-source? Everybody keeps talking about ST not being open sourced, but how many people have actually went and dig into the Atom code and changed something in a core of it? I just want to write code with a fast editor, I don't really care if its open source or not if it does what I want it to do
I'm still using ST, but there have definitely been times when I wished it would be possible to modify some functionality. [1] I've sent them feature requests, but as they barely manage to implement their own ideas, mine have been ignored. If it were open source, I could've implemented it myself, which I certainly do for other tools that I use and find lacking.
[1] For example the find-replace dialog closes itself when I press "Replace All", as opposed to other editors I've used where it doesn't. It's annoying to have to reopen the dialog after every different search.
The benefit of open source is really better plugins. It's much easier to create plugins for an editor if you can see the editor's source code. This is true for IntelliJ IDEA and Atom in particular. I have been able to create pretty great UIs and other features in IntelliJ plugins from looking at and introspecting the IntelliJ code to see how it was done there.
The other benefit is that if the company dies you know you wont have wasted all that effort with the editor because open source editors don't live and die at the behest of the company that started them.
I've stepped through some atom code to figure out how to properly configure syntax highlighting (ended up being me misunderstanding how certain regexes work...)
I haven't changed anything in core, but having the ability to walk through all the code is super useful in debugging.
>I don't really care if its open source or not if it does what I want it to do
You care about the utility of your editor, and that's fine. Several other comments here try to highlight ways in which open source projects are more pragmatic, like the ability to make modifications yourself or take advantage of community contributions.
All of that is just arguing about utility, though. For many people open source is a moral issue. RMS is a notable example here. And I prefer open source tools for this reason.
If you believe open source software is morally superior to closed source software then the utility considerations are of secondary, or perhaps even zero, importance.
I think it is not about doing the actual digging and changing code of open source project. It is more the idea that it is possible and can be done if needed.
Why does the advantage necessarily have to be personal? Why can't it be communal? Though I don't fancy myself as capable to make significant contributions to FOSS projects, I do use and promote them (though, if I'm honest, HN exposes more to me than I do here) so that others can have exposure to them, use them, provide feedback/contribution to the project.
Atom and VS Code listen to your .gitignore when showing a folder of files. Quick searches ignore those files as well. In Atom those folders/files are still openable (the explorer pane thingy shows them as grayed out).
To get the same functionality in Sublime, AFAIK, you have to create a couple of project files first and add folders into it. Then, if you later make a new folder via the terminal you have to edit your project file to include it.
That's been my biggest headache around Sublime vs. Atom. It's the smallest thing but it's like sand in my shoe.
Atom is a small bit slower than sublime, but it has just as many or possibly more plugins, has a nicer settings and plugin interface, and is open source and free.
I switched to Atom a few months ago, and I agree with all your points, but I think you're being a bit generous calling Atom "a small bit slower". On my machine (2013 MacBook Air) Sublime opens instantaneously, while Atom takes 2-3 seconds. Opening files is also noticeably slower, though not by as much. Memory usage is also far higher, in the hundreds of MBs vs tens.
I forget that not everyone is in the dev channel and was wondering why this was on the front page. There's new dev's every couple days. Didn't realize there haven't been a stable in a long time.
Looking at the change list, it notes that there won't be artifacting with theme changes any more? If so that's freaking huge. For a while there it would start up, the package manager would update stuff, and then the interface would sorta crap itself. A quick reload fixed it, but damn annoying.
Would you suggest switching to the dev builds? I really wouldn't mind being on the bleeding edge if it meant getting fixes like that sooner.
>Looking at the change list, it notes that there won't be artifacting with theme changes any more? If so that's freaking huge. For a while there it would start up, the package manager would update stuff, and then the interface would sorta crap itself.
How is that "huge"? It happened at most 1-2 times a year, and a simple 1 second restart fixed it -- and still left all the files you had loaded.
Due making a backup shortly before a breaking glitch, it actually happened a whole bunch of times across a whole bunch of computers. Sublime's licensed to the user, not the machine, so over a few months while I was setting up a slew of machines I kept forgetting about it when I restored my app directory. Add that one of the packages would freak out when curl wasn't already installed first and it was a mess. Sublime would start, update, screw up the interface, popup, and then I'd have to close it and restart a few times until the package manager got it up to a stable point.
I say huge because it was god damn irritating. In a giant checklist of stuff I was worried about, it was always an afterthought that caught me by surprise. When the artifacting completely craps out the side bar such that the folder tree no longer updates when files change, you can't even tell if the files are still there.
EDIT: To really drive the point home: this happened a whole lot. The above is a story of woe and sadness, but the real kicker was simply the autoupdate as noted elsewhere by `jbrooksuk. For a long time I used the Soda Theme [0], one of the top packages on Package Control. It had a wierd glitch with hotkeys and would end up reloading shortly after startup. It was possible that it would garf things up even on restart as a result (possibly as a race condition such that if no updates were performed, it restarted fast enough to not bork whatever drew the iterface). I used Soda theme for years, but have recently switched to Seti and enjoy the change quite a bit.
While not a sublime, I frequently switch iterm's themes when I code outdoors. A dark background is my preference, but a light theme works much better in sunlight.
It's not that people often switch themes, it's that when you open Sublime, Package Manager updates themes and it has to reload them, which used to cause the UI glitches.
If the author of Sublime is reading this thread, please know that I love your work! I happily paid the $70 and use this as my primary editor (except when using vim when working over SSH).
I'd also like to see more activity on the Twitter account or just more engagement with the community. You've got a killer product :)
RANT: "Ubuntu 64 bit - also available as a tarball for other Linux distributions."
Linux requires THREE files (.deb, .rpm and a .tar) I personally use OpenSUSE and can easily compile the software BUT you are not "supporting" Linux when you only support Ubuntu.
So, they have two out of three then. Does there appear to be any reason you couldn't use the .deb for Ubuntu on Debian? Perhaps someone would be willing to take the tarball and make a RPM file for him to host (or set up the tooling to make it dead simple for the author).
Packaging is hard. I personally use fpm and have found it solves a lot of issues.
Does the rpm they provide not work on opensuse? Typically they bundle everything so it's not dependent on your system node. If not, there may be an opensuse build service that has a maintained sublime.
I use Gentoo and they're portage overlays for Sublime, but I don't really care anymore as atom has gotten to the point where I prefer using it. It has all the features I had out of Sublime, plus it's free and open source.
I was trying to choose a Mac text editor recently; got it down to Atom and Sublime, and then discovered that both of them do code folding wrong. They think it's based on indentation, not syntax, so if you try to fold something like:
if (something) {
some code
//commented-out code
more code
}
It folds everything from the opening bracket to the comment, then stops.
I didn't write the code in question, but I've done the same thing before. Usually it's because I'm cursoring up and down a file, see some lines I want to comment out, and don't bother moving over to the start of the text first. Syntax highlighting greys out the comment, so it's not visually obtrusive. (Which is another reason I'm baffled that Atom and Sublime both misbehave this way--they've got syntax highlighting! They're already aware of block delimiters! Why don't they apply that knowledge to code folding?)
And I understand there are other reasons to not indent. In some languages, it's conventional to have certain kinds of declarations come at the beginning of a line, even if they're inside a block. (I think C++ does this, but I haven't used it since college--anyone want to comment?)
If such commenting is being done using the generic comment/uncomment keyboard shortcut, whether that happens is influenced by TM_COMMENT_DISABLE_INDENT in the language package's Comments.tmPreferences file.
Really? That's my comment style, so I'd be affected by that if I ever used code-folding. I don't want this to come across as 'blame-the-user', I'm just genuinely interested - what does code-folding help you with?
At the time, I was attempting to modify a very large, nonbranching clusterfuck of a function, and there wasn't time to properly refactor it, so I wanted to examine each chunk and then fold it away once I'd determined that it wasn't related to what I was looking for. (And the code I was looking for turned out to be scattered across three different parts of the greater monolith, so I was glad I could fold away the bits in between.)
But yeah, generally it helps me get a high-level overview of the code without getting lost in the details.
In lisp, if you have a let with a variable declared on the same line and another below, it only folds the variable parts of the let, and leaves the body unfolded. Super frustrating.
I recently updated from Sublime Text 2 to ST3. One thing I loved about version 2 was that it was insanely fast. Version 3 is significantly slower. Can anyone point me to any resources that might help me determine why the slowdown?
I had to disable all my linters, because I also ran into severe input lag. It fixed the worst input lag, but I still have no idea what exactly the culprit was.
Really wish packages could be subjected to some kind of performance benchmark to shame the worst offenders to fixing their isht.
Mostly because instead of using the DOM and a general purpose renderer (Blink), Sublime's text editor component is actually an OpenGL canvas made specifically for that.
That's not why Atom feels slow. You're running a machine that can run JS faster today than any machine could run C 10 years ago. There haven't been any major innovations in text editor technology in that time, none that would warrant such a huge slow down.
Atom feels slow because it's over engineered. They try to make everything run through the plugin system.
The point is not if JavaScript is fast or not (which btw it isn't faster than C++ or not even just as fast), but how many layers of abstraction JS has to go through to display stuff on the screen or do anything useful. Having to fight with DOM and CSS to do anything like syntax highlighting is effectively triggering execution of millions of lines of code compared to sublime text that does a raw win32 or Cocoa call.
Comparison with 10 years ago is also not so relevant. 10 years ago you didn't try to autocomplete through an average modern JS project where thousands of files are created on disk even before you create your first div. Data processing needs are outgrowing CPUs improvements by far.
IOW there's no way Atom is getting as fast as Sublime, because of the huge stack it is built upon. It might get fast enough though, but my feeling is that the discrepancy is actually getting bigger rather than smaller, as we evolve our average needs as programmers
There are more ways than just the DOM to render text. And I didn't claim JS was faster than C, I said JS on modern hardware is faster than C on 10 year old hardware. Yet we still managed to run text editors "fast enough" 10 years ago. Finally, I made the specific point to say that Atom is not a good example of what should be possible in JS.
Regarding the comparisons with Atom, can I take the opportunity to ask if anyone from ST could expand on their answer here[0] as how they go about making a custom OpenGL interface?
Do they use GLEW? Skia? How do they ensure anti-aliasing is done right?
Sublime Text 1 used OpenGL (1.1 only, hence no GLEW) and Direct3D, while 2 and 3 are mostly software only.
While Sublime Text 2 and 3 do use Skia, only a tiny fraction of its functionality is actually used, just for rasterizing lines and blitting images. Font rendering is done by using the underlying platform APIs to do the glyph rasterisation.
In case anyone was wondering, the new JavaScript syntax highlighter appears to understand ES6, but chokes on JSX. If you're writing React, the Babel package is still a good idea.
Is there a roadmap anywhere? I bought ST2, and I think I'm going to need to pay again for ST3 when I decide to upgrade, but it's still in beta and has been for over 3 years now. Would be nice to know when it will eventually be released.
I don't think so, it's the sort of software that's ready when it's ready. You can use the pre-release versions of ST3 (ie what's currently available) on a ST2 license. That gets rid of all the nag screens.
I bought ST2 too in 2012 after a few weeks using it. It was certainly an expense but given how much it was speeding some things up, I considered it very good value.
I've used it for at least 6,000 hours since then, probably closer to twice that. I'm not going to fight an upgrade when it eventually gets here.
I was in the past a long time on ST2 and refused to upgrade to ST3. It was a bad decision... many plugins work on ST3 only and I had less problems on ST3 overall than with ST2. I did not need to pay again for ST3.
Upgrade Policy
A license is valid for Sublime Text 3, and includes
all point updates, as well as access to prior versions
(e.g., Sublime Text 2). Future major versions, such as
Sublime Text 4, will be a paid upgrade.
So I paid for Sublime 2 as well, but I use 3. Don't know if it was a temporary thing, but my 2 license carried over. Try emailing support if you can't get yours to work. They were helpful with mine.
Who told you it lags? Version numbers? That's because stable version X+1 come after dev version X.
This doesn't mean it lags, just that the dev version came out first, and only after it was checked for a while, it was deemed worthy to hit the stable (well, actually beta) channel.
That's not different than any other project I know.
I don't look at the version number only, but at the changelog, too, but didn't pay much attention, until now.
Most sane projects create a build and test it, and don't rely on testing source code because the build process itself can cause defects as well.
What we've been testing as a dev build should have been promoted to stable, but, I realize now, he has the changelog embedded in the executable, and it's possibly merged across dev builds. He also has differences in the functionality between the dev and beta builds as you can't run the dev without a key.
It sounds like his approach is similar to the Windows 10 Insider Builds model of Fast Ring & Slow Ring. Even if all the Sublime builds in Dev are stable, I don't want to be updating every 2 days to get some minor bugfix. When I launch Sublime, I mostly just want to get to straight to work, not be thrown out of the zone by an update.
It took me a while to learn that lesson from my own customers. As a developer I'm excited to make sure customers always get new features ASAP, but customers would complain they were perfectly happy with what they'd bought & only wanted an update maybe once or twice a year. But everyone's different - that's why the option of a Dev/Beta channel & a Stable channel is good.
And that's why I wonder why he doesn't push to us on the dev channel to test for a bit before pushing as stable. Yeah, it would be different packaging than the /3dev build, but does it matter? As long as he can get feedback and keep us on the last version, it works for me!
PSA: If you haven't updated yet, I'd wait. The new version apparently broke syntax highlighting for many languages. Check out their support forum[1] - it's causing ripples.
I really haven't seen any correlation there at all. Sublime's had sporadic and at-their-own-pace updates since before Atom came out.
And... Why would it be sad?! Two excellent solutions competing to make a better product is pretty much the opposite of any sense of the word sad I can think of. It's great to have choices that are under active development.
There's a sweetness to that sentiment, but I think it's misplaced. I mean, Jon Skinner has technically been working on this thing for over a decade. It's this guy and a couple other people polishing it for years; saying it's like Microsoft is like calling git-annex just another Dropbox.
And don't forget: this is a product and a business. If someone comes up to eat your lunch, you can roll over and die or adapt and improve. We've come a bit full circle in the Complaints Department here: when Atom was first coming out, a vocal lot decried it was just a Sublime Text rip-off picking on the little guy. Turns out it's a pretty good editor! Sublime's got a few updates and it's just perfunctorily playing catch-up? Well, I liked it before, and now it's better, so... I think that's pretty good.
I'll have to disagree with this, the VS Code team has made me reconsider electron as a desktop platform. Compared to atom, it's far snapier, and loads much quicker. I think you're giving the new Microsfot short shrift.
When I said "better", I should have said merely that Sublime's improved, not as a qualitative statement for comparison to others :)
I pretty strictly follow the idea that you pick something that works for you and use it. I happen to be familiar with Sublime, but man, I really like IntelliSense when I'm in SSMS (or when I did Excel VBA hacking - don't judge me!). Honestly, until Sublime Text 2's vast improvement in startup times it wasn't my go-to editor, and oddly it's what kept me off Atom the few times I gave it a cursory whirl (my previous alternative? Notepad++). I have zero doubt Atom will eventually be just as snappy - heck it may even be now; I haven't checked.
That all said, I think the VS Code team is going to eat everyone's lunch within the next few years if no one watches them and keeps up. And my money is everyone does try to keep up and we're left with a new browser war situation where we have lots of ultrahigh quality options!
I dunno, I'm just not a fan of Electron-based apps especially for a text editor or IDE. Native desktop applications always have such superior performance and memory-management.
VS Code startup lasts at least 100 times longer than ST3. It also takes twice as much RAM. Maybe on your PC it's not noticeable, but the difference is there.
VSCode does seem pretty nice -- One thing I can't figure out is the Ctrl+P quick find. It doesn't seem to auto-complete/open files I have added in explorer? The same behavior works flawlessly in Sublime.
What exactly are you looking for in ST improved? I just can't find anything that I think can be any better, it's just perfect already for me, I've tried using Atom but always went back to ST after a week of poor performance and battery drainage of Atom.
Yeah Atom still has issues. I've had crashing problems on 4 year old Macs.
But ST makes you pay $70. And also isn't open source. And more people know JS than Python to hack on it. And Github has a powerful marketing team and lots of resources to put behind Atom and it's development. And ST doesn't get updated too often.
$70 is absolutely peanuts for a tool that you use for hours every day.
The main reason so much modern software is bad is that people aren't willing to pay for even a fraction of the actual value it delivers. I would happily pay $700 for my main code editor if that would guarantee regular updates and new features.
To your point I think a lot of people would pay that kind of money if it guaranteed the company would both, continue to update and continue in its current direction. But that really hasn't been the case with most projects, and the open source products tend to have better shelf life.
I am happy to pay for these kind of things but rarely in a big upfront block like that. I doubt I'm the only one.
Very few people are willing to pay the kind of money that would actually sustain a company.
Let's run the math, and see if we can build a business around a text editor.
Let's say we can get away with 2 good developers (across 3 platforms, that seems difficult to me). Let's further stipulate they are willing to take a pay cut from their previous life at Facebook and are willing to do this as a labor of love. 90k/yr salary, 180k/yr for both.
Now we need a technical writer, to handle API documentation etc. Let's say we can get a CS major to do it part-time at 20 hrs/week at $20/hr. 20k/yr.
We also need a sysadmin to wrangle the CI setup, website hosting, install updates, setup email, etc. Suppose they automated everything in Ansible/Docker/Kubernetes/whatever_the_cool_kids_do_these_days and so we only need 10 hrs/week at $50/hr. 26k/yr.
We need a QA engineer to bang on things and file proper bugs. $50k/yr. Let's further stipulate that this same person will handle customer support, because we're a lean startup and combine multiple roles in the same individual.
We need somebody to handle marketing (or maybe direct sales, since it's a $700 pricepoint). Let's call it another $50k/yr.
We're now up to $325k/yr. Traditionally we would now have to lease office space, buy macs, call our AWS sales rep, etc., but let's assume for this conversation everybody works from home, they have their own equipment, and we got free startup AWS credit, which is not very realistic at all, but whatever.
So let's stipulate this is a stable burn rate. Nobody will get poached by Facebook, nobody needs to raise a round, if we can pull in only 325k/yr, we can do this forever.
When we sell our $700/license, let's say we net 75%. That is actually very high: most software companies net around 50-60%, because the App Store, WalMart, the state, etc., take their pound of flesh. But our $700 text editor is so amazing that people will buy it direct from us, we will have a strong brand, handwave. So we take home an incredible $525.
We now need to sell 700 licenses year-over-year in order to keep this thing going. Not even 700 licenses one-time, but we actually need to close 60 licenses a month, 2 licenses a day, 365 days a year. To do that, we needa sales process.
I would love to live in a world where a salesman knocks on your door, does a 2-hour demo, and at the end you have 50% conversion to writing him a $700 check. I just don't live in that world. And that's the kind of sales process you'd need to sustainably develop a text editor.
Anything short of the exercise I just went through will result in a failed product. A developer might take a pay cut for a year but will lose interest if they're well below market. If we don't hire good QA then our quality will be shit and not worth $700, just think of all the shitty software you use already. If we don't have support then nobody will want to spend $700 to get their emails ignored. If we fund via VC then we will have to blog about Our Incredible Journey the next time Google Docs needs an engineer.
The result of this analysis is the current market. The only way to develop a text editor is either all volunteers (like Atom), a small part of a large corporation's marketing budget (VSCode), or a labor of love from one and a half underfunded and overworked people who we somehow expect to stop being underfunded and overworked even though we only paid them like half a billable hour several years ago (ST).
You DO know that apart from a programmer and a helper sales guy, ST has none of all those other "roles".
And judging from the community size, polls, and similar numbers from other project, it has sold at least 10.000 licenses (x70 -> 700,000) and i all probability much more.
>The result of this analysis is the current market. The only way to develop a text editor is either all volunteers (like Atom), a small part of a large corporation's marketing budget (VSCode), or a labor of love from one and a half underfunded and overworked people who we somehow expect to stop being underfunded and overworked even though we only paid them like half a billable hour several years ago (ST).
Maybe it's the analysis that's way off base, especially the dev numbers.
In fact the whole breakdown sounds ludicrous, like assuming the only dev work out there is done in cushy Facebook style jobs in the Valley or with extravagant VC money.
In fact tons of successful indie apps, not just editors, fly in the face of all you wrote above. No reason to believe a graphics editor (e.g. Acorn) or VST plugin (e.g. uHe Diva) or FTP Editor (e.g. Transmit) has much more potential users than a language/OS agnostic programming editor. And yet, all these companies exist for years, and even have several employees and nice offices.
As for editors, there's not only IntelliJ, that has tons of people working for it and is doing just fine, but other long time companies, like UltraEdit (that boasts 2 million users), a whole ecosystem around paid Eclipse plugins, etc.
> Now we need a technical writer, to handle API documentation etc.
Sorry, but you've already lost me there. That's firmly in the "nice to have" camp. For example: the documentation on Sublime's API is shoddy at best, but enough plugins still get made that I'm incredibly happy with it as a product. Your math adds up to what would be a great team, but there's no way you can call it the bare minimum to create and maintain a great product.
You're setting up a company that expects massive growth. I would expect most text editor companies to start out with one person only, and expand only later if they have a steady revenue stream. The extra personnel are nice but not at all necessary when you are at a low sales volume with a single product.
I think my point was that I would pay 20/mo and as long as the product is what I want it would work. I think that many times projects do the one time thing because it's a hobby and a bit of a money grab (IE, people love this I could charge for it), but in real life they should have done a monthly setup since they have bugs to fix and features to write.
Or you could use one of the multitude of free editors that have regular updates, and the open source ones that you can update yourself, or the extensible ones that you can upgrade as you see fit. For zero dollars.
I am a vim user, so I don't really use SublimeText often if at all. I was happy to pay $70 for it, just to support what I saw as a fresh take on editors.
I wish developer could find more sustainable way to make a living from this and work on it more.
I don't think I ever regretted paying for it and I made number of companies with people using it, pay for it.
>And more people know JS than Python to hack on it
I wouldn't call the proliferation of npm modules a good thing. I'd rather have Python programmers coding my editor plugins.
>And Github has a powerful marketing team and lots of resources to put behind Atom and its development.
Marketing sounds like reason to avoid a software. And all the resources didn't manage to make it tolerably fast/low on cpu those 2-3 years its out. Whereas at least VSC got that right.
One thing that has me switching between editors is Visual Studio Code's multi-file code information feature, or "intellisense". It's especially awesome for types. Another thing is that I find that Atom's syntax highlighting is sometimes better.
ST's plugin API is extremely limited. There's hardly anything a plugin can do to influence the rendering of the text editor. ST plugins can:
* Show autocompletion boxes (e.g. cmd-T)
* Update the status bar
* Edit text
* Tag text regions (which can be used for custom highlighting, e.g. underline errors)
Atom plugins can do almost anything by modifying the editor DOM, but more formally they can:
* Display compilation error messages inline
* Show popups
* Display custom panels (e.g. the neat Git conflict resolver) within the editor window
* Draw custom settings UI
* Extend the file tree sidebar's rendering
* Create and arrange editor windows
* Create custom windows (e.g. Markdown Preview splits the current editor window and shows a live preview on the right-hand side)
etc.
Atom has also been better designed with regard to pluggability. For example, it comes with a single autocomplete system that packages can extend with custom autocompleters. Plugins don't have to invent their own autocompletion system.
The fact that ST's plugins are executed in a sandbox environment also causes (afaik) issues for plugins that want to use toolchains such as Go.
The only proprietary software that I use as a matter of choice is Microsoft products and VMWare products, For something as trivial as a text editor, I wouldn't dare use something closed source, proprietary like this.
I don't think it's quite fair to classify Sublime as a text editor. Your comment trivializes the quality of the editing experience, the rich plugin ecosystem, the speed of the editor compared to common competitors, etc.
You are of course entitled to your preferences, but I'm not sure why you wouldn't "dare" use this?
I don't think it's quite fair to classify
Sublime as a text editor.
While I may not agree with the totality of what @_RPM states, there is no doubt that Sublime is "a text editor" when the official site states thusly[0]:
Text editors are one of the few very-well specified systems. The requirements are very well known and there is plenty of information available on design and implementation. Yes, text editors are very easy to implement.
The problems come when people think it's so easy they can just jump in without doing any reading.
Hey, I'm currently in the stage where I do research to build a text editor. Would you mind linking some of this information about the design and implementation you're talking about? More interested in the UX/higher level things that the low-level code for optimizing and such.
I can't tell if you are sincere or you are trying to be passive aggressive. We've been talking about raw performance and you ask about trimmings. Also, I'm not going to do your googling for you.
It's not about dev friendliness in general, but "friendliness" for js/html/css web dev who refuses to learn right tools. So it's about education (a lack of).
