- This topic has 15 replies, 14,733 voices, and was last updated 8 years, 3 months ago by .
-
Posts
-
We are wanting to know how important a Unicode version of Multi-Edit is. Is it worth our time to continue to add further enhancements to the current code or just switch to a new Unicode core?
None of my code is in unicode. The only time I ever touch a unicode file is when you export registry keys. And I can edit that in notepad.
I know very little about unicode, so I’ll offer this wish: Can I just save all my unicode in utf8, and can MEW do just enough unicode to edit utf8?
Is there some (20%) minimal set that could be really easily implemented that would cover 80% of the need?
-Andy
For me Unicode support is much less important than fixing long outstanding bugs, like no undo after a mouse click setting the insertion point, very slow appearing help and file dialogs, files appearing blank after they got changed externally and reloading them requires macros or several mouse clicks… I already wrote that my workgroup decided against Multi-Edit, because of these trivial but annoying problems.
More and more of my code is Unicode, especially with loads of XML editing I have to do. More often then I like, I have to switch to another editor.
Daniël
Unicode is getting more important for me as well (although the long-standing bugs would also be nice to have fixed)
While my programming is still in English, the web pages, logs, and other data files are slowly starting to have more and more non-English characters in them. So far no script languages, such as Hindu, but I’ve had to work with Chinese, Japanese, Korean, Russian, and a handful of European languages. I have to use Notepad++ for those, which is a disruption in the routine because I have pop open an external editor for some project files.
Plus, you might be able to open ME up to the international market.
–James
Unicode is very important … !
I don’t use unicode, but I may be forced to it over time.
Please take the experience of others and don’t attempt to rewrite the entire codebase at once.
It nearly destroyed Netscape.
I have a Ruby IDE that I like that died when the author attempted too big a rewrite at one go.
See http://www.joelonsoftware.com/articles/ … 00069.html for one article on this viewpoint.
See http://www.joelonsoftware.com/articles/ … 00069.html for one article on this viewpoint.[/quote:1fcgyvye]
I disagree with this article, at least partially. Working as a software architect in our company, I don’t say our code is holy mess (as programmers always do) according to the article. Instead, I’m rather happy with it. This is because we threw away a lot of messy code more than year before and rewrote it from scratch. With new, much better architecture. I spent a lot of time with it design, tried to avoid all old code drawbacks, learn from previous experiences and achieve new goals which were impossible with the old code. Then spent a lot of time with discussions with developers to explain them reasons and make corrections according to their feedback. Then it was implemented which took months for two teams and now it is already proven successful. Of course, we continued using old code and had several releases in between until the new code was qualified. It took us many man-months of time but I’m sure we’d spend much more time messing with the old code with worse results.This is not my first experience like this. Rewrite always gave me better results and took finally less time than keeping old code. Of course, I always reuse functionality and parts of the code, usually refactored. I also have opposite experience, one is still bugging me. About 7 years before we were under time pressure and I based driver for our devices on MS sample. Bad design, not very good code. Within years I rewrote at lest half of the original code and fixed a lot of bugs. Still I’m not quite happy with it and know about few problems which can’t be fixed. If I throw it out within first two years and write a new one from scratch, I’d spent much less time with it. Unfortunately, I couldn’t find several months necessary for it and now it is so big it is virtually impossible. It became pretty stable but any change is very dangerous. Because of bad original architecture.
As for MEW, the best would be to keep the old code base and write new version in parallel. It is rather big but not sooo big. The new code would have to be carefully designed, of course. For next 20 years
*Without* Unicode, ME has become no more than a helpful tool that I use very little now.
I *need* Unicode and am actively searching for another editor that will be worth modifying to meet what my highly customized ME does now.
See http://www.joelonsoftware.com/articles/ … 00069.html for one article on this viewpoint.[/quote:b78mz73y]
I’ve read the first half of this and I think that it is very sage advice.
I’ve been on full-rewrites and they’ve always made everybody involved (management, customers, developers and qa) wish they could find another job now!
Rewrite one chunk at a time with an eye towards the architecture you want to eventually achieve.
The customer benefits from incremental improvement.
The producer benefits from regular upgrade purchases.
The developer benefits from a steady pace of accomplishment (instead of a huge gumption killer from biting more than can be chewed).For next 20 years
[/quote:2w6afqof] hehe, we all know it’ll need major rework every decade. That’s the business, life moves fast for us.But that definitely is the *spirit* !
I want to continue standing behind this product. Help me do that please.
Michal: after reading the first couple of sentences of your post, I was sure the author is not from an old capitalist country, like Germany or the US. Checking your info on the left confirmed it. Everybody knows that we should first develop a working prototype to learn the issues, measure performance, etc. and having the testers’ and first users’ feedback we rewrite the code from scratch. But we never have time for a rewrite. Just keep patching the old code. If a large project is rewritten, new bugs are introduced, new bottlenecks show up making the resource planning difficult, and in the time the cleaned up version is finished a whole new project could be brought to the prototype phase. There is never time and money for a cleanup. Almost. With special prototyping tools I succeeded recently, the first time, to make a slow, memory hungry version of our latest project, which went through beta testing, and now it is rewritten in C for speed. This is the exception.
Coming back to MEW: if the known bugs are not fixed first, Unicode support will be in vain. I will not upgrade our MEW licenses, if the next version does not fix all of the serious bugs.
I’m affraid it will disturb your picture a bit but I’m working for US company for long years and previously working for German one. We don’t do rewrite without a good reason and having a bit messy code isn’t a sufficient one. The good reason is design limitation which slows down or even blocks next development or which makes support cost too high. It is necessary to see bigger picture; time spent for rewriting pays off many times in the future. And opposite, any "temporary" patch can stay for years.Maybe there is some misunderstanding. Rewriting code from scratch doesn’t mean everything old is discarded. What we usually do can be taken as a new generation grown from previous one. New code based on experience taken from old one. Including good parts of code, of course.
Finally, I’m really lazy person so I’m trying to save myself from unnecessary work. If it is necessary to rewrite old code to make my work easier, I’m for it
In other words, I’m willing to spend more time now to make my life easier in the future.Joel’s primary objection to total rewrites seem to be:
1) Many times what appears to be merely cruft is due to numerous bugs that were fixed over time. This was, so I hear, one of the issues with Netscape. I read an article by the author of the original FTP code, and he made the point that nearly all of the code in it was to respond to some edge case for some browser or FTP server somewhere, and throwing the code out was discarding all the captured knowledge.
2) The only way to manage refactoring a codebase into a new architecture is to have a suite of automated test to tell you when you broke something, and then to do a sequence of small, planned refactorings to get the job doen.
If by rewrite, we mean new code carefully informed by the working codebase (note that this presumes a prototype was discarded earlier), and then done carefully, it can work, as other posters point out.
I am involved with an attempt to migrate a 16-bit assembly program that evolved over decades. the primary developer wrote the original code. Another developer created an application using the scripting language. An attempt to write the entire application from scratch foundered. An attempt to rewrite just the base application appears to be foundering. We may and up having to refactor our way into an upgraded version that actually works.
The only point is that the decision to do a total rewrite is not one to be taken lightly.
I believe that both options can exist for now, but later implementation of Unicade will be needed anyway…
- You must be logged in to reply to this topic.