> Conventional computer interfaces are generally not as latency demanding as virtual reality, but sensitive users can tell the difference in mouse response down to the same 20 milliseconds or so, making it worthwhile to apply these techniques even in applications without a VR focus.
I wish people would start treating text editors that they are developing this way. As hard real time systems. Don't care much about virtual reality, but I'm sick of text (and code) editors with unpredictable latency of basic operations [like typing a character, making find call, etc].
Darius Bacon and I have spent some time trying to figure out a buffer data structure that can scale to large files while guaranteeing predictable latency for basic operations like typing a character. (What's "making find call"?)
I think you mean "soft real time", though. A hard real-time system is one which is unusable if it fails to meet a deadline even once; a jet engine control system, say, where failing to meet a deadline could result in engine parts penetrating the fuselage. A "soft real time" system is one where failing to meet a deadline is a failure, but tolerable if infrequent; say, once every million keystrokes, or every 7 days of video play time.
Would you be willing to pay a recurring fee for using an editor? I have toyed with writing an editor at multiple points but have backed away because I think in the grand scheme of things its a one time sale to a pretty small market (The number of people who care enough about text editing that they would pay for a good editor when they see one)
I pay, effectively, a recurring fee for PyCharm. The personal license is €89 and comes with 1 year of upgrades. As they've been able to release upgrades after that year expired that looked interesting, I paid another €50 for it the next year support.
Personally I'm not keen on a recurring payment unless there's a clear benefit. For an editor, that'd be having a team committed to making it better. The JetBrain guys have shown good progress.
Doesn't seem to be too small a market for sublime or textmate.
What I would pay for would be an editor in the style of ST2 but with a few IDE features like being able to jump to method definitions by shift clicking etc.
Basically a very lightweight IDE with good text editing features (like VIM style keyboard shortcuts). Integrate a terminal into it, but do it in a very slick way with the ability to run "recipe" type commands.
For example if I forget the switches for a git command, I should be able to search for roughly what I want and have a result return which will populate a command in the terminal.
This might mean hyper focusing on a few languages however.
Not sure I would like the recurring model for just using the editor. Since this would likely mean you would have to implement some sort of always on cloud integration into the editor which would annoy me and make me worry about losing access to my editor.
What I might pay for on a recurring basis would be access to a repo of high quality plugins that were well integration with every version of the editor. Also maybe some functionality to allow me to share the editor session with someone remotely.
I dont want to gimp the user experience or implement cloud features just to get people to pay. At the same time if I am going to be spending 2-3 years to build something I would rather it be something that has a recurring income stream.
This is a good question - I dont think I have a good answer. I lean towards not implementing a check or stop your use. Maybe a monthly reminder for one / two months saying you have not paid. After that I would just assume that the user has stopped using my editor.
In order to justify a monthly payment I feel you would really have to be pushing out frequent high quality updates that just kept making it better and better.
If development started to get stagnant I would probably "forget" to renew it after my CC expired or something like that. Or at some point I'd just feel "I've given this guy enough money" and cancel even if I kept using the editor.
I totally agree about the Lightweight IDE thing. IMO Sublime is close to being great, but some missing features must be preventing people from writing great plugins like those in Emacs world.
Since I havent implemented anything I cant make any claims, what I can answer is things that I miss in the current landscape:
a) Fast startup times
b) Effective utilization of multiple monitors out of the box
c) Embedded prompt for dynamic languages
d) Minimal lag in the UI
e) Fast regex search over multiple files
f) Multi file mode - I want to be able to have multiple files mapped to the same buffer and have the ability to quicky seek to files
g) Outline mode that is code aware
h) Integrated lint mode
i) < 10 meg download size
All of the above in the same editor. Currently sublime comes the closest, I have also happily used emacs in the past but sublime feels snappier than emacs currently.
I guess if emacs could be as snappy and pretty as sublime what it would scratch all my needs, because modulo some polish it has most of the other features.
> I wish people would start treating text editors that they are developing this way.
IDEs. Most of the things people do in modern IDEs were done in Smalltalk (albeit, with uglier interfaces and some manual steps) over a decade back. One of the differences, though, is that these things were mostly highly responsive, because they were bloat-free. (Can't speak for IBM VisualAge. Also, one could rightly complain that they were feature-poor in their stock configurations.) This is in stark contrast to other IDEs and app server frameworks, which would take forever to start up, or forever to restart, or forever to complete an operation. One example, Extract Method, was always instantaneous. It's still lugubrious even in modern IDEs like XCode4.5.
The same rules that apply to Web Apps also apply to programmer's tools. Delays are yuck. Responsiveness is yum!
I'm also a musician, and from what I've seen playing around in Audacity, 5 milliseconds is definitely inaudible, even to some of the most talented, golden-eared musicians I know. I suspect that 20 milliseconds is going to start to bug some people, though they won't be able to say why.
Also, awareness of subtle modulations of very small variations in rhythm and how they affect the feel of music seems to be an indicator of intelligence and aesthetic awareness. So often, the difference between blah and great involves things that are subtle and hard to put your finger on.
> One of the differences, though, is that these things were mostly highly responsive, because they were bloat-free.
That's not my recollection of the Smalltalk IDE at all. I especially remember how selecting was crazy slow: press down the button, move the mouse to the end of the line and the selection takes two seconds to catch up with the cursor.
> That's not my recollection of the Smalltalk IDE at all.
Which one and from what time period? My experience was mostly with VisualWorks. Even just with that, there are variations. Going from version 3.* to 5i was actually a step down because of hastily released stuff from a company in turmoil. Also, lots of open source/free implementations started behind the curve in terms of technology. (Still doing bytecode interpretation instead of JIT.)
I get stutters with Sublime Text on my ancient MacBook Pro, but I'm often crushing the io systems (like a big Dropbox resync at the same time as a database compaction), so that may explain some of it.
I wish people would start treating text editors that they are developing this way. As hard real time systems. Don't care much about virtual reality, but I'm sick of text (and code) editors with unpredictable latency of basic operations [like typing a character, making find call, etc].