SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
SoylentNews
Over at The New Stack is a brief but entertaining history of the editor vi and Vim.
"The editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore," Joy said. "It was a world that is now extinct. People don't know that vi was written for a world that doesn't exist anymore."
This discussion has been archived.
No new comments can be posted.
A Look at Vim, a Text Editor for the Ages
|
Log In/Create an Account
| Top
| 135 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
The last time I saw him he was walking down Lover's Lane holding his own hand.
-- Fred Allen
(Score: 5, Interesting) by MichaelDavidCrawford on Thursday August 23 2018, @01:11AM (7 children)
I am completely convinced that the reason Linux fanbois have always hated on IDEs so much so that even to this day I remain unable to find an Open Source IDE that I would touch with yer herpes-ridden dick is because the only other IDEs that Open Source coders have ever tried are those built by Microsoft.
LightSpeedC For System 5 - back before they started calling in "MacOS", before the system even had a brand name - LightSpeedC's major selling point was that you could test a source code change every single time rather than having to laboriously walk through your source manually as you mentally modeled what the CPU would do.
At the time the only other way that anyone serious about commercial code built for the Mac was to build their binaries on Lisas then transfer them to the target Macs on floppies.
As Mac's got faster and as Apple published the Macintosh Programmer's Workshop that was mostly OK to use directly on your target Mac, LightSpeedC's name was changed to ThinkC. It remained wildly popular, with MPW being used mostly when scripting was required. Almost all Apple Engineers used it for that reason but even so many Apple coders did their compile-edit-test with Think then transferred their source to MPW when the time for checkin was approaching.
ThinkC sadly fell out of favor when Apple transitioned from 68k to PowerPC. I don't clearly recall but I expect that Think never supported PowerPC.
Symantec was first was quite the kewal corp with Symantec C which was largely aa ThinkC clone. I interviewed there to work on Symantec C's support for Apple's Bedrock Win/Mac cross-platform framework. Remember bedrock?
Neither does anyone else. Good thing I decline Symantec's offer!
Metrowerks came from out of nowhere with CodeWarrior and saved Apple's ass. CodeWarrior at first was about the same as Think/Symantec but rapidly accellerated past them.
At the time Apple was building PowerPC binaries on IBM RS-6000 workstations with a whole whack of MPW shell scripts and a modest port of IBM's PL/1 POWER compiler to PowerPC. I actually used that when I was at apple in the mid-nineties and it was just like wearing The Cruel Shoes. There was no way Apple would ever convince any third-parties to use it and apple knew it.
Eventually every coder outside apple was using metrowerks as where many inside.
I used CodeWarrior with great success for Windows/Mac PowerPC AND 68k coding, but their windows product never really caught on with anyone who wasn't also working with macs.
CodeWarrior for Windows and CodeWarrior for Mac were both so much like each other that I never really cared whether I was running on a windows box or an apple box. I would switch from one to the other every week or so just so as to each ensure both platforms knew I loved them equally.
Eventually CodeWarrior grew weary of the expense of supporting windows so they sold their windows/x86 compiler to Nokia. We all know where that went.
Then - only AFTER codewarrior unloaded their Win support - Apple announced that they were moving to 32-Bit Intel. And yes: 32-Bit. My first MacBook Pro was a Core Duo, not a Core 2 Duo. It wasn't until a year or so after that that Apple started shipping the Core 2.
Metrowerks was eventually acquired by Motorola who I expect regarded CodeWarrior as a significantly valuable part of that acquisition. By then CodeWarrior ran natively on BeOS and supported a whole whack of embedded targets as a cross-compiler.
Eventually Motorola spun off Freescale whose tools are all built around CodeWarrior.
Freescale offers a free coderwarrior install for embedded targets whose only limitation is the size of the binary. Freescale seems to have been acquired by or perhaps changed its name to NXP. Try CodeWarrior for Hello World, you'll be glad you did:
PS: CodeWarrior for Mac supported Java up to 1.8 JDK, for Windows a much-later JDK build.
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by Alfred on Thursday August 23 2018, @01:24PM (1 child)
(Score: 2) by MichaelDavidCrawford on Thursday August 23 2018, @05:13PM
It's been using the Cocoa Text Widget for most of its existence.
I'm pretty sure Project Builder's editor wasn't NeXT's NextStep Text Widget.
That ThinkC really _was_ so very responsive I'm quite certain was the result of its editor being written in 68000 assembler. I expect CodeWarrior's was written from the start in C. I didn't use Symantec enough to really tell the difference.
It's only been since late 2016 that I've regarded Xcode's text editor as anything other than Hammering Nails With My Fists. And yes I've always ensured that _everybody_ in Apple's Tools Group knows what I think of - specifically - their text editor.
Using Xcode on my Mid 2015 MacBook Pro actually works quite well; however back in 2015, to have used the 2015 version of Xcode would not have worked well.
The difference is that Apple places an exceedingly high priority not so much on any of its widgets' performance but they do place quite a high priority on tuning the code that the widgets are built on top of.
That Mac OS X binaries always have the Mach-O Executable Format is specifically so that Method Lookups only need the address of the C string with the method name. Linux and I expect BSD can run Cocoa programs but their method dispatch does string comparisons rather than 64-Bit integer comparisons.
I don't know much about The Cocotron [cocotron.org] for Win and Linux other than that Andy Green [em.net] really likes it.
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by turgid on Thursday August 23 2018, @02:31PM (3 children)
What you want is TDD. I do it in C with bash, vim and gnu make. IDEs are bloated, buggy, slow, restrictive and yet another pile of garbage to be nursed.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by MichaelDavidCrawford on Thursday August 23 2018, @05:04PM (2 children)
Read The Fine Parent where I made crystal-clear that Open Source hate for Integrated Development Environments is the result of Visual Studio and not at all Metroworks, Think nor Symantec.
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by turgid on Thursday August 23 2018, @06:29PM (1 child)
Every IDE I've ever tried has left me longing for the command line, and simple but powerful scriptable tools. The point I was trying to make is that you can go much faster and with fewer bugs if you do it simpler.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by MichaelDavidCrawford on Thursday August 23 2018, @06:57PM
Whether or not you script, Xcode is quite a lot easier than Makefiles or Autoconfg to set up even for multi-target projects each of which has lots of sources.
Yes I Have No Bananas. [gofundme.com]
(Score: 2) by bobthecimmerian on Thursday August 23 2018, @07:22PM
Most people in most fields resist change. The biggest reason Linux fanbois aren't fans of IDEs is that most of the older ones - and a lot of us are in our mid 30s or older - learned to work and write code when most common IDEs were terrible. My first IDEs were Visual Studio 6, then Eclipse in the mid 2000s. I had a colleague that was an emacs wizard, and between his own general skill with software development and his emacs wizardry he was the most productive developer on the team. Of course that soured me on IDEs. But in the past five years among the people I know, the IDE users are generally more productive than the text editor and shell prompt fans and a few IDE users positively blew me away with their speed. I would be foolish and stubborn to hold on to vim or emacs as my primary development environment in the face of that. I'm an IDE user now.
I also think the value of an IDE is somewhat less if you use a language with dynamic typing. Intellisense + Jump to declaration + automated refactor are insanely handy in Java or C# or Scala or whatever. As far as I know, those features are less common or less reliable or both for Javascript, Python, Perl, PHP, etc... But admittedly I haven't tried any recent IDE for any of those languages, maybe they've improved dramatically.