[HN Gopher] IDEs we had 30 years ago
___________________________________________________________________
IDEs we had 30 years ago
Author : titaniumtown
Score : 378 points
Date : 2023-12-28 11:38 UTC (11 hours ago)
(HTM) web link (blogsystem5.substack.com)
(TXT) w3m dump (blogsystem5.substack.com)
| DeathArrow wrote:
| I spent countless hours in Borland Pascal and Borland C as a kid.
| This brings back nice memories.
| hnbad wrote:
| I was expecting the author to mention Smalltalk because I
| distinctly remember people praising Smalltalk for its IDE but I
| think the IDE I was thinking of is from the late 90s or early
| 00s.
| rwmj wrote:
| I don't think SmallTalk ever had a TUI. Even the very early
| versions on the Xerox machines used a GUI, and that GUI
| persisted even when it was all ported to Solaris.
| zozbot234 wrote:
| Oberon was this weird mix where you had a proper GUI on thr
| screen but it would basically only show text. You could run
| commands by selecting text from inside any arbitrary window.
| The plan9 OS and Acme editor have kept this workflow.
| xkriva11 wrote:
| Digitalk had Smalltalk TUI for DOS named Methods. https://pbs
| .twimg.com/media/ET8sPbsXQAAcgpb?format=jpg&name=...
| hnbad wrote:
| The title of the article doesn't mention TUIs (or UIs at all)
| but I was thinking of a GUI. Specifically it seems I was
| likely thinking of Pharo (which is '00s not '90s so off by a
| decade).
| igouy wrote:
| The article subtitle is: "A deep dive into the text mode
| editors we had and how they compare to today's".
|
| The second paragraph says: "This time around, I want to
| look at the pure text-based IDEs that we had in that era
| before Windows eclipsed the PC industry."
| mananaysiempre wrote:
| An interesting continuation of that evolutionary line is the
| Open Dylan IDE: https://opendylan.org/history/apple-
| dylan/screenshots/index.... the deconstruction of the object
| browser / Miller columns seems interesting even as a general UI
| concept.
| tcard wrote:
| I think it's fair to say Smalltalk(s) have had in many aspects
| the most advanced IDE in existence at every moment since its
| introduction.
|
| Demos for a couple old versions:
| https://www.youtube.com/watch?v=NqKyHEJe9_w Demo for Pharo:
| https://www.youtube.com/watch?v=baxtyeFVn3w
| pjmlp wrote:
| Not only Smalltalk, all Xerox PARC Workstations
|
| Interlisp-D, Mesa (XDE) and Mesa/Cedar, all shared same ideas
| with Smalltalk, regarding developer tooling.
|
| Same on Genera with Lisp Machines.
| masklinn wrote:
| > I think the IDE I was thinking of is from the late 90s or
| early 00s.
|
| Smalltalk's from the 70s and 80s, and almost certainly had what
| you're thinking about given it's where both Microsoft and Apple
| got their foundational ideas (restricted to significantly less
| powerful hardware), and later unrelated smalltalks retained a
| lot of now quirky considerations and behaviours. Self inherited
| a lot of those and is from the late 80s.
|
| So yes, I was also expecting the author to talk about
| Smalltalk.
| eschaton wrote:
| If you actually look at Xerox's hardware, it's quite a
| stretch to call Lisa or Macintosh "less powerful." It's kind
| of amazing what Xerox was able to accomplish on such
| underpowered systems; they did it largely by having
| _multitasking microcode_ to handle performance-sensitive I
| /O, and implementing BitBlt there too.
| 010101010101 wrote:
| I suspect there are quite a few more niche languages/interfaces
| that the author didn't consider when it comes to GUI IDEs. I
| thought of EiffelStudio immediately, myself, having worked with
| a group that used it in a past life.
| bayindirh wrote:
| People still forget Eclipse when it comes to a full-blown yet not
| bloated IDE. That thing consumes less than a bare bones VSCode
| install while running 5x the tools. It can handle everything from
| code to git to CI/CD and remote development since 2013.
|
| I'm using it for 20 years and I think it's the unsung hero of the
| IDE world.
|
| This article doesn't mention it either as a modern GUI IDE.
| RcouF1uZ4gsC wrote:
| But Eclipse was often laggy and slow. So it felt bloated to the
| users than VS Code which is snappier even though it is bigger
| bayindirh wrote:
| It _was_ , for C++, for a couple of years, 12-13 years ago.
| It's neither laggy nor slow for the last 8-9 years. I've
| written my Ph.D. thesis on it, on C++, which was a sizeable
| high performance code.
|
| It never crashed, allowed me to work remotely if required,
| integrated with Valgrind, allowed me to do all my tests,
| target many configurations at once, without shutting it down
| even once.
|
| Currently it has a great indexer (which is actually an
| indexer + LSP + static analyzer and more), LSP support if you
| wish, and tons of features.
|
| It gets a stable release every three months, comes with its
| own optimized JRE if you don't want to install one on your
| system, etc.
|
| Plus, it has configuration snapshots, reproducible
| configurability, configuration sync and one click config
| import for migrating/transforming other installs.
|
| That thing is a _sleeper_.
| magicalhippo wrote:
| While Eclipse today is certainly a quite decent IDE, I use
| it mostly in the form of STM32CubeIDE[1] now, it was
| servicable at most back in 2005-2006 when I used it for
| some Java classes.
|
| In any case, it's a younger product than the offerings in
| the article.
|
| [1]: https://www.st.com/en/development-
| tools/stm32cubeide.html
| bayindirh wrote:
| > In any case, it's a younger product than the offerings
| in the article.
|
| Yeah, but my gripe was about the closing of the article,
| which mentioned VSCode. I think the author just doesn't
| know about it.
|
| Eclipse is my DeFacto C++/Python IDE and I'd love to
| develop a decent Go plugin for it, too. Maybe someday.
| hnlmorg wrote:
| Not just C++. I used to use it for Java development and had
| the same experiences as the GP too.
|
| I'm sure it's really good these days. But I've moved on now
| and my current workflow works for me, so I don't see the
| point in changing it until I run into issues again.
| bayindirh wrote:
| Java never got _that_ slow, but it used to tax the system
| a lot in the earlier days, yes.
|
| I developed Java with Eclipse, but the project I did was
| not that big when Eclipse was not its prime, and it was
| in its prime when I was experienced enough to be able to
| "floor it" in terms of features and project complexity.
|
| Now it's just a blip on the memory usage graph when
| working with big projects, and way way more efficient
| than the Electron apps which supposed to do 20% of what
| Eclipse can do.
| hnlmorg wrote:
| There's a reason people don't talk much about Eclipse these
| days and it's because it was a pain to maintain back when it
| really should have shone.
|
| I really wanted to like Eclipse but gave up on it a decade ago
| because it required constant management from release to
| release. I remember one job I had where I didn't need an IDE
| all that often and I would spend nearly as much time
| configuring Eclipse again upon the next time I came to use it,
| as I was spending time writing code in it.
|
| I'm sure it's improved leaps and bounds in that time - 10 years
| is a heck of a long time in any industry, let alone IT. But I
| do know I wasn't the only one who got frustrated with it. So
| myself and others switched to other solutions and never looked
| back.
| bayindirh wrote:
| I was there, but it has changed. "Four updates a year" was a
| great decision to make, to be honest.
|
| It just updates now, and I export my installation XML and
| send to people when they want the exact same IDE I use.
| lawgimenez wrote:
| I started Android development with Eclipse. That IDE is a
| beast. People also forgot about Netbeans.
| oogali wrote:
| Netbeans was my absolute favorite IDE for Java development.
| After its last release, I honestly felt lost.
|
| I've gotten back up to speed via IntelliJ but it still
| doesn't feel as effortless as it did in Netbeans. And way
| less care and feeding than Eclipse.
|
| Sorry, there's a lot of "feels" in this post but for me,
| Netbeans was the one Java IDE that I didn't have to fight
| with.
| lawgimenez wrote:
| Yes Netbeans was very underrated, I used it for making
| Nokia ME apps. And learning Java.
| pjmlp wrote:
| Still is, quite a few features like Swing editors, or the
| two way editing between rendering templates and Java
| code, or the quality of profiling tools for such open
| source product.
| badsectoracula wrote:
| I also used NetBeans a bit years ago, though that was
| mainly because it had a (mostly) WYSIWYG editor compared to
| Eclipse (technically Eclipse had a plugin for that which
| supposedly was also superior in how it worked - it parsed
| the code to figure out what the GUI would look like and
| updated in place instead of NetBeans' generating code with
| commented out sections you wasn't supposed to touch - but
| in practice it was both slow and clunky).
|
| For Java specifically i felt NetBeans was faster and
| simpler though i bounced between it and Eclipse because i
| also used Eclipse for other stuff (C++ mainly) so unless i
| wanted a GUI i used Eclipse. I did stopped writing Java
| some time ago though.
|
| I did try a recent NetBeans build but i found it much less
| polished than what i remember from before it became "Apache
| NetBeans".
| ludsan wrote:
| My first Java IDE was Symantec Cafe (which became Visual
| Cafe). I haven't thought about that in 25 years.
| layer8 wrote:
| What do you mean, "last release"? NetBeans 20 was released
| just this month. I still use it.
| oogali wrote:
| Apologies for not clarifying -- the last release of
| Netbeans prior to the Oracle acquisition of Sun.
| jbverschoor wrote:
| I love eclipse, but it's unbearable on macos
| bayindirh wrote:
| How come? I use it regularly. Genuinely asking.
| jbverschoor wrote:
| I don't know. It's even worse with IntelliJ. IntelliJ
| crashes regularly. It unbearable.
|
| Running m1 sonoma
| perrylaj wrote:
| Interesting - I run Intellij Ultimate on Macbooks (both
| Intel and m2) and never have a crash. Infrequently run
| into bugs when upgrading the ide or 3rd party plugins;
| that requires some sort of cache invalidation or project
| reimport (couple times a year), but it's pretty smooth
| sailing for something I use across many different
| projects and languages. Java, kotlin, TS, python, groovy,
| shell scripting, json/xml/yaml/html/tsx are all generally
| touched 40+ hours on a weekly basis - it just works.
|
| I do agree intellij is memory hungry with multiple
| projects open and a variety of languages involved, but
| RAM is cheap enough (and VMs/Docker/K8s hungry enough)
| that I just don't buy a machine with less than 32GB
| anyway, so I give intellij up to 6 GB and never give it
| another thought.
|
| I don't do much android development, but do find Android
| Studio to feel clunky and slow at times, guessing because
| of the heavy integration with Android dependencies and
| emulation, but not really something I know enough about
| to comment with any sense of authority.
| hugi wrote:
| How so? Use it daily, with hundreds of open projects and it
| just flies.
| jmyeet wrote:
| VSCode is really a text editor-in-IDE-clothing. Also, it's an
| Electron app and those are notoriously resource heavy.
|
| ~20 years ago I became an early IntelliJ user. From version 3
| maybe? It's hard to recall. I've never looked back.
|
| But I did try Eclipse and... I never got the appeal. For one,
| the whole "perspectives" thing never gelled with me. I don't
| want my UI completely changing because now I'm debugging. This
| is really part of a larger discussion about modal editors (eg
| vim vs emacs). A lot of people, myself included, do not like
| modal editors.
|
| But the big issue for Eclipse always was plugins. The term
| "plugin hell" has been associated with Eclipse for as long as I
| can recall. Even back in the Subversion days I seem to recall
| there were 2 major plugins (Subclipse? and another?) that did
| this and neither was "complete" or fully working.
|
| To me, IntelliJ was just substantially better from day one and
| I never had to mess around with plugins. I don't like debugging
| and maintaining my editor, which is a big reason why I never
| got big into vim or eclipse. I feel like some people enjoy this
| tinkering and completely underestimate how much time they spend
| on this.
| verelo wrote:
| I've been using vscode for a few years now and while i find
| its search amazing, it doesn't do much more for me. Its
| syntax highlighting is good, but the auto complete
| recommendations have been driving me insane recently.
|
| Writing rails api with a nextjs ui, anyone got any
| suggestions on alternative paths i should take?
| victorbojica wrote:
| JetBrains solutions. It think it's called RubyMine.
| jmyeet wrote:
| This may not apply to you but I find it so weird how many
| programmers won't invest even a modest amount into software
| they'll use 8 hours a day every day. Particularly when
| we'll so easily spend money to upgrade RAM or buy a new PC.
|
| RubyMine on a cancel anytime personal license is
| $22.90/month (or $229 for a year). That's nothing. I'd say
| just try it. If you don't like it, you might only be out
| $23.
|
| I'm not a Ruby person so can't comment on that really. For
| Java (and C++) it's a lifesaver. Things like moving a file
| to a different directory and it'll update all your packages
| and imports. Same with just renaming a class or even a
| method.
|
| The deep syntactic understanding Jetbrains IDE have of the
| code base is one of the big reasons I use them.
| bayindirh wrote:
| For me, perspectives are perfect, because it provides me a
| perfect set of tools for everything I do at that moment. It's
| probably a personal choice, so I agree and respect your PoV.
|
| The plugin conflicts were way more common in the olden days,
| that's true, however, I used subclipse during my Master's and
| it was not incomplete as my memory serves. It allowed me to
| do the all wizardry Subversion and a managed Redmine
| installation Assembla had to offer back in the day.
|
| It's much better today, and you can work without changing
| perspectives if you prefer, so you might give it another
| shot. No pressure though. :)
|
| Trivia: VSCode Java LSP is an headless Eclipse instance.
| marcosdumay wrote:
| At a minimum, perspectives play very nicely with the
| plugins system.
|
| Eclipse was created over that extremely interesting idea
| that you can write a plugin to do some completely random
| task, and have all of it reconfigured on the perfect way
| for that task.
|
| But you can't have a rich ecosystem of plugins without
| organizing them in some way, and nobody ever created a
| Debian-like system for them as it's a lot of thankless hard
| work.
| indymike wrote:
| For about five years, my daily start of the day ritual was
| starting eclipse, going to a 10 minute standup, and coming back
| two minutes before it stopped loading. To be fair, it's
| probably better now, and I stopped doing Java work in 2014.
| gosub100 wrote:
| what I dont understand about java is why doesn't it just take
| what it _needs_? If I commanded eclipse to open, _that 's
| it_. Open an editor, maybe 2-3 recent files, and let me move
| the cursor around. If IntelliJ isn't ready yet, so be it, but
| dont slow _my UX_ down because it 's running a bunch of
| services I didn't ask for. If I hit the IntelliJ autocomplete
| then fine, I'll wait if it's not ready, but until then, the
| editor frames should be just as snappy as notepad. Java
| doesn't put the user first!
| hinkley wrote:
| One of the biggest tricks with Java IDEs was not giving
| them more memory, but giving them more initial memory.
|
| Tuning startup heap size could cut upward of 40% off of
| startup and settling time.
| hinkley wrote:
| Anyone who thinks Eclipse is compact is hallucinating.
| badsectoracula wrote:
| I used to like Eclipse but honestly it was and still is a hog.
| At the time i used it in the late 2000s it was basically the
| best IDE for C++, having features that Visual C++ users either
| did not have or needed to pay extra for plugin to get. I used
| it at work then when everyone else used Visual C++.
|
| However at home i had a computer i bought late 2003 (which was
| a high end PC at the time but still) and the program was so
| heavy i remember despite running it under a lightweight
| environment (just X with Window Maker) i had to choose between
| Firefox and Eclipse because otherwise things would crawl due to
| the excessive memory use both programs made :-P.
|
| Eventually i switched to other IDEs and forgot about Eclipse.
| But i did try it recently again and while obviously doesn't
| feel as heavyweight as it did back then (i'm running it on a 8
| core machine with 32GB of RAM so it better be), it still feels
| sluggish and startup time is still quite slow.
|
| Also TBH i never liked the idea behind workspaces.
|
| These days i don't write C++ much but when i do i use either
| QtCreator or Kate with the Clangd LSP (which i also use for C).
| bayindirh wrote:
| I think 9 seconds startup time with 1GB of memory use is
| pretty acceptable for an IDE at the size of Eclipse (just
| timed).
|
| Considering I'm not closing it down for whole day when I'm
| using it, waiting for ~10 seconds in the morning is not that
| bad.
|
| In 2003, Eclipse was at its infancy and was an absolute hog,
| I agree on that front.
|
| Actually you are not expected to have "n" workspaces. Maybe a
| couple (personal and office) at most. Project relationships
| and grouping is handled via "referenced projects".
|
| Kate is an awesome code-aware text editor. I generally write
| small Go programs with that, but if something gonna be a
| proper project, it's always developed on Eclipse.
| badsectoracula wrote:
| > Considering I'm not closing it down for whole day when
| I'm using it, waiting for ~10 seconds in the morning is not
| that bad.
|
| I tend to close and run the IDEs (and most programs)
| multiple times per day - a clean desktop kinda lets me
| clean/reset my thoughts - so long startup times are
| annoying. Of course i wouldn't avoid a program if it was
| responsive, fast and did what i wanted after it started up.
|
| > Actually you are not expected to have "n" workspaces.
| Maybe a couple (personal and office) at most. Project
| relationships and grouping is handled via "referenced
| projects".
|
| Yeah i also had a single workspace but i worked in a bunch
| of other things, including some Java stuff in NetBeans and
| i want to have everything in one place. I do use and prefer
| IDEs but every other IDE could just store projects wherever
| i wanted.
| LanceH wrote:
| There were a couple things going on in 2003.
|
| First, it was quite common for a company to buy a developer
| the exact same corporate standard computer as everyone
| else. So lots of computers had limited ram to run things
| like J2EE, Lotus Notes, and Eclipse at the same time. It
| was painful.
|
| The startup was always slow because it preloaded
| everything. This was a deliberate choice to not load things
| and interrupt the developer. Just don't close it all day
| and the experience was very good.
|
| A plus compared to the standard of the day was that it ran
| native widgets. So doing something as simple as opening a
| file explorer to browse through your project was
| considerably faster than comparable IDE's at the time.
|
| Personally, I loved the customization which was dialed all
| the way up. I could have multiple windows with different
| arrangements of panels within them, all saved. I haven't
| run across anything as configurable since then.
|
| It also had the big benefit of their plugin system which
| shined when working with multiple languages in the same
| project.
|
| It always felt to me like it became trendy to crap on
| Eclipse because of the slow startup time and it never could
| shake that.
| saulpw wrote:
| > I think 9 seconds startup time with 1GB of memory use is
| pretty acceptable.
|
| 9 seconds of startup time on a modern GHz computer is
| completely unnecessary and unacceptable IMO. There may be 9
| seconds of work it wants to do at startup, but there's no
| way it needs to do it in a single thread before letting you
| start to interact with it. This is an optimization effort,
| nothing more. Give me a month with their codebase and I
| could get that down to under a second. (So could most
| decent software engineers.) It would just need to be
| something they actually put effort into.
| bayindirh wrote:
| In that 9 seconds, a Java VM starts up, starts up an OSGI
| compliant platform and loads all the plugins you have
| installed and enabled in that particular Eclipse
| installation. When the window appears 9 seconds later,
| the VM is warmed up, all your plugins + IDEs (yes
| multiple) are ready to use. No additional memory
| allocations are done WRT your development plugins. Also
| remember that these plugins are not in isolation. There's
| a dependency graph among them.
|
| In the following seconds, updates are checked and indexes
| of your open projects are verified and re-run if
| necessary which takes again <10 seconds on different
| threads. Your computer may scream momentarily due to
| increased temperature on all cores if indexes are
| rebuilt.
|
| If you think that code is not optimized in the last 20
| years, you're mistaken. Many tools from Android Studio to
| Apache Directory Studio runs on that platform.
|
| Nevertheless, I'll try to profile its startup tomorrow if
| I can find the time.
| saulpw wrote:
| It may not be about optimization, but about user
| experience. You may have to be clever and think outside
| the box. Can you save a snapshot of all that work so that
| the next instance doesn't have to do it before showing
| the window? And then assuming it has to do the work
| (which may not be necessary if it just started up--once a
| day is probably sufficient), it can redo the work in a
| separate thread.
| bayindirh wrote:
| Eclipse already does non-critical background tasks on
| separate threads, and non-critical startup tasks are done
| in "deferred early start" queue, which is emptied after
| initial startup.
|
| Normally Eclipse IDE is not something like Vim, which you
| enter and exit 10 times a day. It just lives there and
| you work with it. 10 seconds in the morning for a tool
| that big is very acceptable, esp. after considering that
| _everything is instantaneous_ after that 10 seconds.
| IAmLiterallyAB wrote:
| Android Studio is IntelliJ
| bayindirh wrote:
| It _was_ Eclipse when they first started. Still tons of
| IDEs run on Eclipse platform, too. Esp. on the embedded
| space.
| hinkley wrote:
| It wasn't "a hog" it was _the hog_. I don't know where OP
| gets the idea that it was svelte. IntelliJ is considered a
| pig and a half in most eras but at the time, for most if not
| quite all projects, Eclipse had a worse memory footprint, for
| less functionality.
|
| Also the UX was mediocre at best and infuriating at worst.
| Practically every interaction worth performing in that editor
| took at least one more click or keystroke than IntelliJ, and
| I would rank IntelliJ as merely good, but not amazing with
| input economy.
| ben_w wrote:
| I have good memories of Eclipse, from back when I was doing
| Java. I remember at the time it seemed everyone dissed it, much
| as it feels like everyone disses Jira now and for the last
| decade, but I liked it.
| fredgrott wrote:
| I think you are mistaken, Eclipse takes up 3 times the ram
| VSCode does...I can use VSCode using only 6gig ram even with
| big projects with native code such as kotlin, java, c, swift,
| etc..Eclipse will not run on 6 gig ram neither will jetbrains
| or android studio.
| bayindirh wrote:
| My system monitor says it's using 1.3GBs after warming up,
| and even forcefully reindexing a big C++ project.
|
| I don't think VSCode will use 400MBs with that amount of
| code, plus electron, plus all the LSP stuff you run beneath
| it.
|
| In that state Eclipse will fit into a 6GB system just fine.
| I'd love to try that at a VM right now, but I don't have the
| time, unfortunately :)
| hinkley wrote:
| If memory serves, fully loaded Eclipse would take about
| 20-25% more memory than IntelliJ, which was itself rightfully
| called greedy.
|
| At the time most of us felt it was worth the cost of entry
| for all of the tools you got, which eclipse had a subset of.
| jen20 wrote:
| A blast from the past there. I used Eclipse for Java in its
| infancy while I was at university and thought it was decent
| enough compared to whatever version on emacs would have been on
| whatever version of Solaris was on my CS department servers.
|
| A couple of years later I started an internship at a bank and
| spent ~3 hours trying to get a project building before someone
| introduced me to IntelliJ, which I still use every day almost
| 20 years later!
| felipemnoa wrote:
| There does seem to be a lot of hate for eclipse. The complaint
| I always hear is that it is a pain to use. Personally I've
| always liked it, even though I've used the other popular IDEs.
| hugi wrote:
| Agreed. And there's simply nothing that comes close to the
| power of the workspace when working on multiple projects that
| share dependencies.
| pjmlp wrote:
| The original idea was to replicate the Smalltalk image
| approach, but backed by a virtual filesystem instead.
|
| Eclipse is Visual Age for Smalltalk reborn, after all.
|
| It was common to have plugins corrupt its metada, but
| somehow it finally became quite stable.
| pjmlp wrote:
| Same here.
|
| You will find old rants from me complaining about workspaces
| metadata, but that problem has been sorted for quite sometime
| now.
| flohofwoe wrote:
| Sorry, but "not bloated" really doesn't enter my mind when I
| think of Eclipse. The few times I used it for Java programming,
| it took forever to start up, and the UI was laggy as hell
| during regular use. Granted, that was about 10 years ago, but
| on a (at the time) beefy Windows PC.
| jmmv wrote:
| I (author) wouldn't say I "forgot" about it. I was there when
| Eclipse became a thing, and my memories are all pretty grim.
| Difficult to use, slow, very resource hungry... so I never
| really paid much attention once I finished school. It probably
| is better now as others are saying, but I don't know nor care
| at this point to be honest.
| nunez wrote:
| Ha. I mostly used Eclipse in college. I learned how to compile
| programs from the Command Prompt (Windows user back then)
| primarily to avoid Eclipse LOL. It was dog slow and somewhat
| difficult to navigate
| agumonkey wrote:
| Interesting. I hate Eclipse with a passion, I find the
| ergonomics so horrendous, and back in the days it was a hog.
| Maybe on today's hardware it's leaner than webkit based vscode.
| But the last time I tried to use git with it .. it made things
| 10x harder than the CLI. It was so bad that I developped RSI in
| 24h (and I'm a daily emacs user)
| hinkley wrote:
| It's possible that Eclipse has had a "Firefox moment" where
| someone carved it down to a lighter core, but I've no reason
| to check.
|
| Seconded on the ergonomics. They were a joke. Longest inputs
| of any IDE I've ever used. If your sequences are longer than
| vim you need to get your head examined.
| agumonkey wrote:
| eclipse was a child of the java components era, even a
| trimmed down eclipse would still have tons of baggage
|
| i really despised (to stay polite) everything about
| eclipse/java culture.. lots of generic layouts and
| components, nothing i cared about or bringing me dense
| information about code. way too much chrome and
| perspectives and what not. it was a cultural dead end, the
| people who "enjoy" working this way are on a different axis
| from me.. give me emacs+magit where things are right under
| your fingers and easy to extend.. and people using this
| kind of tools (i'm sure vim/neovim crowd likes that too
| even more) produce more tools of that kind
| elric wrote:
| I still love Eclipse, and you can pry it from my cold, dead
| hands.
|
| The last couple of years, however, it feels like Eclipse is
| actively getting worse. And I don't mean that it's lacking
| features. I mean that every new release seems to break
| something else.
|
| I tried reporting some bugs, but that required signing some
| kind of soul-selling agreement with the Eclipse Foundation or
| some other nonsense.
|
| I then tried fixing those bugs, but there is no up to date
| documentation on how to build the IDE from the myriad of
| repositories and modules. So I gave up.
| layer8 wrote:
| I'll raise you NetBeans to that.
| olejorgenb wrote:
| Eclips also had (have?) The very interesting mylyn plug-in
| which narrows down the code to the context your working within.
| Think collapsing everything in eg the project tree and also
| functions within files.
|
| This context is built up based on what part of the code you
| work on.
| whalesalad wrote:
| Eclipse is the first thing that comes to my mind when I think
| of the most bloated and stodgy IDE on the earth.
| thiht wrote:
| > People still forget Eclipse
|
| thank god
| icedchai wrote:
| My experience with Eclipse, about 10 to 15 years ago, was the
| exact opposite. It was incredibly bloated. With some
| combination of plugins installed, it became unusable. At a
| previous company, we were using some sort of Scala plugin, and
| Eclipse couldn't even keep up with my typing! I moved on to
| IntelliJ around that time.
| hinkley wrote:
| All of the JetBrains users sitting around comparing notes,
| trying to figure out what was wrong with our coworkers that
| they thought eclipse was worth using, let alone defending.
|
| JetBrains has plenty of problems, which they seem to want to
| address but I fear Fleet won't fix, and I lament but
| understand people wanting something lighter these days, but
| eclipse isn't even in that conversation.
| icedchai wrote:
| Additionally, I always felt the whole Eclipse "user
| experience" was terrible. Setting up a project was a mess.
| The default layout left a tiny window for code. The default
| fonts were bad. I could go on.
| miohtama wrote:
| For the comparison:
|
| Interview with an Emacs enthusiast
| https://m.youtube.com/watch?v=urcL86UpqZc
| zozbot234 wrote:
| Emacs actually supports drop-down menus in text mode, with a
| different key shortcut:
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Me...
| There is also a special incantation for proper mouse support in
| the terminal, because the default is to keep the default
| handling as copy/paste:
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...
| RcouF1uZ4gsC wrote:
| One thing these IDEs had was an integrated debugger.
|
| It seems Unix/Linux really got a nice integrated debugger with
| ann IDE and gdb is powerful, it is very cumbersome. Hence, it
| seems there is a lot more printf debugging on Unix, and less use
| of debuggers than say on Windows where Visual C++ and Borland
| Turbo C++ both had very easy to use debugging integrated into the
| IDE.
| pjmlp wrote:
| Commercial UNIXes had nice graphical debuggers like dbx on HP-
| UX, while Solaris and NeXTSTEP had good IDEs.
|
| Linux eventually got DDD.
|
| Unknown to most is that gdb has a TUI, and is highly scriptable
| in Python.
| lsllc wrote:
| Agreed, for the most part debugging has gone backwards (aside
| from Xcode, Visual Studio 20xx) and was always pretty bad on
| UNIX. Still amazes me that there isn't a really nice, batteries
| included TUI debugger (e.g Periscope!).
| zozbot234 wrote:
| I do wonder what the easiest, most straightforward path to a full
| TUI IDE would be today. Perhaps starting from the codebase of a
| lean graphical IDE like Lapce and adding a TUI-powered backend.
| (Note that text editors do exist with that kind of interface, the
| real gap is wrt. the IDE features including LSP and DAP interop.)
| magicalhippo wrote:
| One could always use the updated Turbo Vision library[1], which
| originally was used for the Turbo Pascal/Turbo C++ IDEs
| mentioned in the article...
|
| [1]: https://github.com/magiblot/tvision
| hnlmorg wrote:
| Vim and emacs do already have plugins for LSP. Probably DAP
| too. But like everything CLI, it might take a bit of initial
| set up to get it right.
| iamgopal wrote:
| Turbo C/C++ was my first IDE, when you know all short cuts, it
| was quite fast. Then came DJGPP with RHIDE...and for many years,
| IMHO, Visual Studio 6 was best for kid ( and window user ) like
| me.
| bluetomcat wrote:
| Visual Studio and XCode are the closest experiences to "first-
| class IDEs", reminiscent of the Borland stuff from the early
| 1990s. They offer tight integration with the native toolchains
| and a set of menus that mostly make sense. Environments like
| VSCode or Emacs are a generic platform for text editing and file
| manipulation, a lowest common denominator for a variety of
| languages, workflows and tastes.
| bayindirh wrote:
| Try Eclipse, or Geany if you want something very small, yet
| powerful for its size.
| Findecanor wrote:
| 30 years ago, I used Trash'em One on the Amiga. It was a text
| editor, 68000 assembler, debugger and memory monitor in one. I
| preferred it over its predecessor Asm One (which had been based
| on Seka), but I don't remember what feature it was that made me
| switch.
|
| https://www.pouet.net/prod.php?which=92408
|
| You can run Asm One in the browser here:
| https://archive.org/details/ASM-One_v1.02_1991_Gram_Data
| mihaic wrote:
| For me, the closest modern successors to the Borland suite are
| Visual Studio (not VSCode) and the Jetbrains IDEs. The feel like
| they're the only one with a holistic, batteries included, design
| that actually focuses on debuggability.
|
| I actually feel that the terminal-based focus of modern FAANG-
| style development actually hindered proper tool development, but
| I was never able to explain it to anyone that hasn't used Borland
| C++ or Borland Pascal in the past, except maybe to game
| developers on Visual Studio.
| aulin wrote:
| out of the loop, how is terminal-based development related to
| FAANG?
| marcodave wrote:
| I guess it's caused by the "brogrammer" culture of Silicon
| Valley, where you would get hazed if you dared using a GUI-
| based tool. Also, being more focused on open-sourcing their
| tools (because other companies do not open source them,
| therefore being un-cool), which begets a "simpler" and
| "engineeristic" approach to UX, which do not need UI experts
| and designers.
| bluetomcat wrote:
| Except maybe Apple, all the others are service-oriented
| companies. They run heterogenous pieces of code on their
| servers and their ideology is "move fast and break things".
| It's a hipster culture that reinforced the use of 1980s
| "video terminal" editors and CLI tooling because they were
| supposedly more flexible for their workflows.
| MonkeyClub wrote:
| It became sort of a hackerish trend in the past decade,
| usinga hyper customized (neo)vim in lieu of an IDE.
| jpollock wrote:
| Lots of companies end up with their own internal tooling.
| They have their own build systems, packaging systems, release
| systems, version control, programming languages,
| configuration languages, everything.
|
| Some even have their own editors.
|
| There is a lot of value in picking a transferrable editor and
| using that. From that point it becomes "what is the best
| editor that will _always_ be available". Emacs/Vim fit that.
|
| Then the muscle memory can begin to grow, and there is one
| less bit of friction in starting a new job.
|
| One of the best pieces of advice I received was "pick an
| editor and go deep".
| pjmlp wrote:
| C++ Builder versus Visual C++ for RAD GUI development.
|
| I never understood why Redmond folks have so hard time thinking
| of a VB like experience for C++ tooling, like Borland has
| managed to achieve.
|
| The two attempts at it (C++ in .NET), and C++/CX, always
| suffered push back from internal teams, including sabotage like
| C++/WinRT (nowadays in maintainance as they are having fun in
| Rust/WinRT).
|
| The argument for language extensions, a tired one, doesn't
| really make sense, as they were Windows only technologies, all
| compilers have extensions anyway, and WinDev doesn't have any
| issues coming with extensions all the time for dealing with
| COM.
|
| Or the beauty of OWL/VCL versus the lowlevel from MFC.
| becurious wrote:
| DevDiv vs WinDev. The Windows group maintains the C++
| compiler. So you get the resource editor for dialog templates
| and that's about it. And that actually got worse from Visual
| Studio .NET onwards, my guess is that it got took over by the
| DevDiv people when they unified the IDEs.
| pjmlp wrote:
| Yes pretty much that.
|
| Windows could have been like Android, regarding the extent
| of managed languages usage and NDK, if DevDiv and WinDev
| had actually collaborated in Longhorn, but I digress.
| jbverschoor wrote:
| Ahhh.. Borland TUI. But also Visual C++ was really great. With
| offline docs!
| pjmlp wrote:
| Those Borland IDEs, a show of hands for Turbo Basic as well, were
| the main reason why I never liked the UNIX development
| experience, until a professor showed us XEmacs, at the time much
| more feature rich than Emacs, and vi was still vi, not vim.
|
| Thankfully with KDevelop, Smalltalk, and when Java started to
| make IDEs more common on UNIX, I no longer needed XEmacs.
|
| Ironically for all IDE-haters, even James Gosling, inventor of
| XEmacs, says people are missing out not using IDEs, he surely
| moved on from Emacs ecosystem.
| aulin wrote:
| Seems a bit quick to dismiss modern TUI editors. Emacs in
| terminal mode has feature parity (almost?) with the GUI version.
|
| And by the way classic curses like menu bar can be opened in text
| mode with M-x menu-bar-open which is bound to <f10> by default.
| You can even use mouse with xterm-mouse-mode.
|
| The one he was looking at was text menubar emulation which is
| pretty powerful too if you take a minute to appreciate it.
| marcosdumay wrote:
| He claims they are unintuitive so he didn't bother exploring
| them.
|
| What is completely fair. Emacs in particular is more featureful
| than VS-Code, but hell, it's hard to make use of all of it.
| ParetoOptimal wrote:
| If vertico and context-menu-mode were defaults you might not
| be able to say that.
|
| Or just the menu and toolbar weren't immediately disabled by
| most.
| dep_b wrote:
| 30 years ago people were using Interface Builder already.
| Admittedly not that many, but the drag and drop interface is
| still there integrated into Xcode.
| pjmlp wrote:
| They were, and had it not been for Apple's reverse acquisition,
| it wouldn't be there in Xcode today.
|
| My graduation thesis was porting a visualization particles
| engine from NeXTSTEP/Objective-C/OpenGL into Windows/Visual
| C++/OpenGL, as the department was seeing the end of NeXT and
| they wanted to keep the research going on.
|
| My supervisor had a NeXT Cube getting dust on the office
| corner, waiting to be collected.
| danieldk wrote:
| I loved Turbo Pascal, but to me the high point of Borland's
| tooling was Delphi (1995). I don't want to sound like _old man
| yells at cloud_ , but every time someone says that _building GUIs
| with Electron is so easy compared to native apps_ , I just wished
| they experienced Delphi in its prime.
|
| There are some very short/simple demos on YouTube:
|
| https://www.youtube.com/watch?v=m_3K_0vjUhk
| pjmlp wrote:
| They can still experience it today with the community edition.
| mikewarot wrote:
| If you can agree to their very strange terms and conditions.
|
| Or, use Lazarus/Free Pascal, which is almost identical,
| except for the documentation, which needs a massive overhaul,
| in tooling and content.
| pjmlp wrote:
| Not everyone is religious against such agreements.
|
| Those can profit from very latest version.
| lelanthran wrote:
| > but every time someone says that building GUIs with Electron
| is so easy compared to native apps, I just wished they
| experienced Delphi in its prime.
|
| Every time someone says that, I mention Lazarus. I stll get a
| thrill out of using it (one of my github projects is a C
| library, and the GUI app is in Lazarus, which calls into the
| API to do everything).
|
| The problem I find with Lazarus is that it seems to be slowly
| dying; yes, they still work on it, but feature-wise they are
| very behind what can be done with HTML+CSS and a handful of js
| utility functions.
|
| A wealthy benefactor could very quickly get Lazarus to the
| point of doing all the eye-candy extras that HTML+CSS let you
| do (animated elements, for example).
| hinkley wrote:
| I will happily fill an hour with trash talking Microsoft, but
| getting the father of Delphi on board is one of the shrewdest
| things they've managed. I wish he'd found a different project
| to sink his teeth into though.
| fiforpg wrote:
| We used Turbo Pascal and Turbo C++ for my high school classes,
| and I have very fond memories of both. This must have been on
| Windows.
|
| Borland really had a series of these fantastic products, it's a
| shame they are no more. The only modern company in this space is
| JetBrains, it seems, so the niche is small.
| zozbot234 wrote:
| Turbo Pascal and Turbo C++ are _still_ used to this day in some
| high schools and even college intro courses. Of course nowadays
| you need Dosbox to run them on modern computers.
| markus_zhang wrote:
| I found myself lack of energy and time stepping into my 40s and
| vowed never to waste time "learning" cool editors such as Vim and
| Emacs.
|
| VSCode is now my one stop editor of choice on Linux and VS on
| Windows. I also use Jetbrain editors for work.
|
| I'm done. For people like me, who write SQL and Python for data
| pipelines, the Jetbrain IDEs are no-brainers. We don't actually
| get the time or energy to do a lot of side projects so it doesn't
| make sense to learn advanced editors such as Vim and Emacs: 1)
| These two need a lot of muscle memory just to start using it, but
| we don't use it on a daily basis, 2) I'm not smart enough to
| write code as if I'm writing this reply so fluent coding
| experience without mouse isn't useful for me ----- I have to stop
| and think hard every few minutes anyway.
| onehair wrote:
| I'm in my late 30s. So maybe not so far away from the age of
| lack of energy :P
|
| I like JetBrains a lot. Things work seemlessly and easily
| integrate with external tools that make up the whole
| experience. But from 2012, I tried to rely as much on shortcuts
| as possible, for one simple reason, the mouse.
|
| There is no problem with using the mouse. But everytime I have
| to use while focusing and coding, I find that that small
| gesture to move my hand from the keyboard to the mouse a bit
| flow breaking.
|
| I have to move to the mouse, do a thing or two, then find my
| way back to the J key notch.
|
| I like what NeoVim and emacs bring with regards to the reliance
| on the mouse. They allow for maintaining the same posture most
| of the time and focus only on typing.
|
| I dislike how brutal they are at learning how to use them to
| full potential, and that making them into IDEs takes ages of
| IDE building rather than project coding.
|
| I like Helix. Which takes a lot of inspiration from
| Vim/NeoVim/Emacs. But require no configuration to get you going
| right away. The documentation is easy to read, as of now there
| is no plugin system but there is a builtin integration with a
| lot of LSP servers for most of the popular languages by
| default.
|
| Keys and navigation is easy, it even shows a helper popup to
| show you which key to use next.
|
| My suggestion is, if you ever want to start a new silly
| project, and you're feeling free to take it slow for 2 days.
| Try using Helix on said project.
|
| PS: Helix isn't fully complete by any means, but it really is
| capable of doing everything you want in many projects without
| being a hindrence if you can adapt to the lack of some built-in
| features like git and file tree. Its annoying but I am less
| upset about it and use alternatives
| Tainnor wrote:
| You can use a VIM plugin for many IDEs, including IntelliJ.
| messe wrote:
| IntelliJ (and the whole Jetbrains suite of IDEs), has one
| of the best VIM plugins I've seen in an editor. It's hard
| to say what it does differently to others, but I've rarely
| encountered a situation where it does something common in
| my workflow differently to (neo)vim. It's just pleasant to
| use and gets out of my way, and has a nice method of
| configuring whether a shortcut should be handled by the IDE
| or the VIM plugin when they might conflict.
| Tmpod wrote:
| I've found multiple features and motions that do not work
| the same as in (neo)vim and end up breaking my flow a
| bit. However, I have to agree it is probably the best vim
| plugin I've seen anywhere, and is life saviour for me :)
| benrow wrote:
| I was looking for this comment. I'm very happy with the
| combo of IntelliJ features and vim movement commands.
|
| The only inertia vim adds to my workflow is escaping into
| command mode. I have a 'jk' shortcut combo rather than
| escape, but if I'm hammering away I often mistime it and
| need to backspace out my jjkk or whatever.
| thesuperbigfrog wrote:
| VSCodeVim (https://github.com/VSCodeVim/Vim) brings Vim-
| style input to VS Code.
|
| Good Vim input plugins can make IDEs more pleasant and
| efficient for users who prefer vim, neovim, vi, elvis, etc.
| wiseowise wrote:
| Shame it falls flat whenever you open big files.
| xtracto wrote:
| Honest question: are other jetbrains IDEs "feel" similar to
| the Android Studio one that can be downloaded for free?
|
| I installed it a couple of weeks ago to modify some android
| app, and boy it gave me vibes of the old Eclipse : sluggish
| Java feel , with "stuff" happening all around and being slow
| to render basic editor stuff.
| matwood wrote:
| They can be slowish to start, but IME are fine performance
| wise for all the features they provide.
| wiseowise wrote:
| > Honest question: are other jetbrains IDEs "feel" similar
| to the Android Studio one that can be downloaded for free?
|
| Android Studio is generally one generation behind
| mainstream Intellij and has its own modifications on top of
| it. It depends on your target language. With the exception
| of CLion, all other forks of Intellij work much faster than
| Android Studio from my experience.
| bionsystem wrote:
| Funny because I entirely agree with you, even though I do the
| exact opposite. Everything I write is in vim because I'm too
| lazy to learn an IDE which may or may not still be around in 5
| years. I use 0 plugin and 6 lines of .vimrc config which I know
| by heart, so I don't care if I'm using it locally or remote, I
| can always get started in 1 minute.
|
| I tried to install plugins but there is always something that
| fails somehow. Nvim distributions don't install and run out of
| the box for the most part, I get weird errors regarding lua or
| something and just give up. As for VSCode I wrote my first
| python project using it a couple weeks ago (I'm not a
| developper) and it's alright but a few things annoy me, like
| the integrated terminal and some things getting in my way.
|
| At the end of the day, each of us should chose whatever we feel
| comfortable with. I spent maybe 2 hours in my life learning vim
| movers and never looked back. I don't even use tmux or
| anything, just open 1 or 2 terminal windows and alt+tab between
| them, with the occasional :split or :vsplit command.
| agumonkey wrote:
| There's a strange dance of IDEs coming and going, with their
| idiosyncracies and partial plugins.. you still have to invest
| and devest everytime a new wave comes. Meanwhile emacs is
| still mostly emacs. I understand the dread emacs can impose
| on you, from old keybinding cultures and elisp but there's
| something timeless and freeing in emacs.
| bionsystem wrote:
| Yes I used emacs at school 15 years ago, and I agree that
| it was great for development ; with OCaml at the time (and
| also C with gdb integration, and 68k assembly later on) we
| shared a few tips with other students and the workflow was
| convenient for dev.
|
| But vim is ubiquitous which is a huge plus when you are
| like me always connected remotely on a different machine.
| Once I learned a few shortcuts I never went back (and never
| dug into the tool itself actually, I can't even run a macro
| ; I'm still faster than most people I know with an IDE).
|
| The only thing I was impressed with is I think phpstorm,
| watching a laravel dev crafting an SQL query. If I ever get
| serious about developping I would look into this kind of
| things (not just for SQL but also framework and module
| functions), especially if I can get vim movers, and a
| screen that isn't bloated. VSCode displays like 15 things
| and I'm only interested in 1 of them 99% of the time for
| example.
| agumonkey wrote:
| i never used vim in a large codebase though, do you ? I
| understand the remote edition appeal, and I use vim 90%
| of the time in cli
| bionsystem wrote:
| Again I'm not a dev but :
|
| - for ansible on reasonably large projects (a dozen of
| roles) it was never a problem ; you have to understand
| how the project has been structured and be able to use
| grep and find though
|
| - when I was playing around with os161 I don't remember
| it being an issue. Although for this particular case I
| did use the cscope vim plugin which is helpful to
| navigate through the codebase (there are equivalents for
| various languages). Not sure if os161 would qualify as
| "large codebase" but it's a bunch of files in a bunch of
| folders.
| ndiddy wrote:
| If you're dealing with a large C or C++ codebase, Vim's
| native cscope support scales way better to large
| codebases than the newer language server solutions from
| visual studio code, etc.
| clows wrote:
| > There's a strange dance of IDEs coming and going [...]
|
| Intellij IDEA 1.0 was released in 2001 - is still in active
| development - and as far as I know the keyboard shortcuts
| are still the same (depending on the configuration one
| chooses)
|
| The first Microsoft Visual Studio release was in 1997.
| XCode was first released in 2003.
| dijit wrote:
| Fog of the future not withstanding; most people aren't
| going to have been using IDEA since 1.0.
|
| If you learned Java between 2001-2012 then the default
| was Eclipse or netbeans.
|
| So you should not be comparing IDEA from 2001 to today
| (or any individual IDE), you should be comparing the IDE
| _landscape_ or ecosystem of 2001 to today, and part of
| that analysis should be a requirement to weight IDE 's
| based on popularity and the recommendations of
| established institutions (academia, companies).
| clows wrote:
| My first java IDE was Visual Cafe by Symantec 1999 - and
| if I remember correctly I started using IDEA around 2002
| (and still do - incl. Rider, etc).
| dijit wrote:
| That's cool, I didn't know you were most programmers.
| clows wrote:
| I only wanted to mention that certain IDEs still used
| today are not coming and going but have been around for
| decades and are still more or less the same (keybinding,
| etc).
|
| Maybe I just don't understand your comment - even
| translated it still confuses me tbh. (I'm not a native
| speaker). Sorry if you feel offended I guess.
| dijit wrote:
| Not offended, but not understanding because of
| translation is fair.
|
| My entire point was that it's _unusual_ for someone,
| especially someone who is new to IDE 's or programming in
| general, to pick something brand new. As educational
| institutions will take time to change from the popular
| thing and most companies will also need time to adjust.
|
| Distilled: my point is that you should not compare IDE
| release dates to the stability of IDEs vs Editors. -- you
| must consider the entire ecosystem of each at the time.
|
| Another perhaps good example to conclude this would be
| something like python backends. One could (unreasonably)
| argue that Python has been around since 1991; but
| _backends_ typically were written in Perl or PHP for a
| very long time. It wasn 't until 2008 or so that Python
| started making headroom for web backends (ruby around the
| same time) -- The possibility existed but the popularity
| wasn't there.
|
| A similar argument could be made for Sublime text (which
| is uncommon these days) but was extremely common in 2010.
| Or Atom, which doesn't even exist any longer but took
| considerable market share from Sublime in its heyday.
|
| It's not fair to say _" x has been around for y time
| therefore it is not changing"_, the ecosystem does change
| and it has darlings and detractors.
|
| The only exception to this ecosystem over tool argument I
| can think of is probably visual studio itself as that was
| a monoculture and stuck around because of that.
| xbar wrote:
| I was using Visual J++ in 1998.
|
| We did a bakeoff of Eclipse, NetBeans and IDEA upon its
| beta in 2001. IDEA won hands down and is still the IDE of
| choice among the developers who work on our codebase.
| maccard wrote:
| So you've changed IDE once in 22 years? That doesn't
| change the argument in any meaningful way.
| dijit wrote:
| I know my school has changed IDE recommendation 7 times
| in 22 years.
|
| But my point is much, much broader than one persons
| experience.
| markus_zhang wrote:
| It is not really the learning curve, but it takes just too
| much time to set up to match VSCode or VS or Jetbrain IDEs,
| plus it requires too much muscle memory to use it
| effectively. It's difficult to stick unless one uses it
| frequently. I simply can't afford it.
|
| TBH everything on Linux/Unix variant (except MacOS) is like
| that, there is no open-box solution. There is always too
| many configurations and even begin with (even VSCode is too
| configuration heavy for my taste but I use it as my Linux
| VM is light). This is definitely good in its own sense
| (more powerful), but most of time I just want something to
| work and concentrate on what I really want to learn. I
| mean, if I really want to learn how an editor works, I'd go
| ahead to build one myself, but in the mean time I just want
| to write a toy compiler so please just let me do it.
| kfajdsl wrote:
| You can use Jetbrains IDEs on Linux.
| markus_zhang wrote:
| Yeah I'm going to try it out when I purchase a dedicated
| Linux machine. Usually I ran from a 4GB-6GB VM so it's a
| bit stretchy.
| duped wrote:
| One of the nice things today is that DAP and LSP (while
| very much designed around VS Code's internal extension
| APIs), the things that use them are basically duct taped to
| tiny VS Code extensions over JSON RPC. They can and will
| outlive VS Code as the IDE of choice.
|
| While on the surface that means that language support
| doesn't have to be designed for a particular editor/IDE,
| what's less obvious is that LSP (in particular) can be used
| as a generic IDE plugin API. I've heard of some non-
| language support extensions (ab)use LSP to get cross-editor
| support with the same codebase.
| TheRoque wrote:
| > you still have to invest and devest everytime a new wave
| comes
|
| Not really... When a new editor/IDE comes and replaces the
| rest, it's because it seduces the original userbase of the
| previous IDE, so usually the transition is smooth (same
| shortcuts, similar functionalities and ergonomics).
| Moreover, I find it weird to "invest" time in an IDE,
| usually you don't really need to, you learn the basics of
| it and you're good to go for years.
| hgs3 wrote:
| > There's a strange dance of IDEs coming and going, with
| their idiosyncracies and partial plugins.
|
| The Language Server Protocol [1] is the best thing to
| happen to text editors. Any editor that speaks it gets IDE
| features. Now if only they'd adopt the Debug Adapter
| Protocol [2]...
|
| [1] https://microsoft.github.io/language-server-protocol/
|
| [2] https://microsoft.github.io/debug-adapter-protocol/
| randmeerkat wrote:
| > I use 0 plugin and 6 lines of .vimrc config...
|
| What are the six lines in your .vimrc?
| bionsystem wrote:
| set tabstop=2
|
| set softtabstop=2
|
| set shiftwidth=2
|
| set expandtab
|
| syntax on
|
| set bg=dark
|
| optionally :
|
| set autoindent
|
| on wsl :
|
| set t_u7=
|
| (no value ; almost pulled my hair finding this one out)
| lsllc wrote:
| In case anyone is wondering what the `set t_u7=` is all
| about:
|
| https://vi.stackexchange.com/questions/27391/why-it-
| enters-r...
| gtirloni wrote:
| For me, cool editors are vscode and jetbrains. I've tried to
| make them my default editors many times but always go back to
| vim (which I've been using for decades).
| markus_zhang wrote:
| I agree that since you are well versed in Vim, it doesn't
| make sense to switch unless for something vastly better ---
| which I don't see in any existing product.
| atrettel wrote:
| I'm a heavy Vim user but I agree with your sentiment. I learned
| Vim during some down time in my first job out of college. It is
| a great skill to have in my opinion. It helps me complete
| complicated text editing quickly and easily, especially
| operations that I otherwise would never have attempted without
| it, but I never would have had the time or energy to learn it
| later in my career. I don't think learning Vim or Emacs is a
| waste of time but I can see how it is definitely not a priority
| when you have so many other things to do and little time to do
| them.
| gosub100 wrote:
| I am a life-long vim-er and I only use probably 30% of its
| features and thats ok. I learn new things all the time,
| sometimes adding them to my repertoire, sometimes not.
| There's so much time that can be wasted if you mess around
| with configuring tools but either fail to remember to use
| them or fail to get them set up. I wanted to set up ctags and
| tried a few times, but fell short of memorizing the forward-
| back shortcuts and got frustrated at the delay when it goes
| off scanning my HDD instead of the local code 1-2 directories
| away. so I just gave up.
| arkh wrote:
| I started with emacs. I love the buffer / windowing system and
| the on-the-fly macros. Also being able to do everything with
| the keyboard.
|
| But the time spent getting multimode up or good autocomplete
| when you can simply fire up something like jetbrains IDE,
| having most of your ecosystem tools integrated the second you
| launch it makes the decision to switch easy.
|
| Also, dev machine tend to have a lot of resource nowadays so
| the RAM hungry IDEs are not a problem.
| worthless-trash wrote:
| I felt the same way about, atom, pulsar, vscode and whatever
| comes next.
|
| These editors are going to be replaced and emacs and vim will
| be kicking.
| matwood wrote:
| I wouldn't consider myself a vim user, but learned the basic
| keybindings awhile back (IMO modal editing is the correct way
| to edit). Knowing those makes it much easier to bounce between
| IDEs. Sometimes I don't realize if I'm in VSCode or IntelliJ
| (especially the new UI) until I try to run something.
|
| > I'm not smart enough to write code as if I'm writing this
| reply so fluent coding experience without mouse isn't useful
| for me ----- I have to stop and think hard every few minutes
| anyway.
|
| I've worked with good programmers who literally hunt and peck.
| It drove me nuts, but as most will agree, typing is rarely the
| bottleneck when programming. I've also worked with people who I
| would consider vim power users, and while they were faster at
| typing out some tasks than I am, I found they were often
| typing/moving around the file as their method of thinking.
| Whereas I might reach for the mouse and scroll around instead.
| Again, typing speed is rarely the bottleneck.
| vehemenz wrote:
| VSCode and JetBrains are better overall, but many of the good
| editing features of Vim are available via their respective Vim
| emulation plugins. It is still worth it to learn and use Vim
| mode for efficiency (in my opinion).
| Tistel wrote:
| I have tried to use VSCode more, but, the original emacs
| keyboard movement is burned into muscle memory. VSCode has a
| keyboard mapping for emacs, but, its does not feel right. At
| the end of the day, who cares? Its just a tool, whatever works.
| FpUser wrote:
| Same here. Jetbrains and VS Code.
| sircastor wrote:
| VSCode has solved so many problems for me. The only time I step
| out of it is when I run into something that might be a
| configuration issue. For instance, if I'm programming an
| Arduino, and it's not working, it's worth hoping over to the
| official Arduino IDE to make sure that the "supported" way
| doesn't work as well.
|
| Otherwise, VSCode solves almost all my problems, and virtually
| all my key-bindings are identical.
| smrtinsert wrote:
| they're really not that difficult, its not a badge of honor to
| use them. I used xemacs and liked it ages ago, and I still use
| raw vim for quick edits or views occasionally. The reality is
| modern ides are simply better for 99.99% of use cases. I might
| not use idea for open log files that are massive, and that's
| about it.
| bdcravens wrote:
| Likewise. I'm 46, and started my career in the late 90s using
| mostly light editors on Windows (Homesite, etc). Along the way,
| I've tried a few times to really dive into vim, but just
| couldn't see the advantage over editors like VS Code, Sublime,
| Atom, or some of the editors popular before then like Eclipse.
| However, I do feel comfortable enough in it that I can edit
| files on servers/containers, which is something I feel is
| useful for everyone.
| cosmez wrote:
| wow, i had the same experience. reaching my 40s and decided to
| drop all the cool kids stuff. i used to have emacs/scheme
| evangelist phases in my life, now i do all my coding using
| enterprise languages and tools.
|
| i have never been so productive.
| guytv wrote:
| Ah, this takes me back.
|
| Turbo Pascal and Turbo Prolog - those were the days. Borland had
| the greatest products, and the accompanying books were always
| well written, used beautiful fonts, and, not less important,
| smelled nice.
|
| If my memory serves me right, Borland even released their Text
| User Interface (TUI) library for developers to use in their own
| applications.
|
| Fond memories indeed!
| lwhi wrote:
| Windows was around .. what about GUI based IDEs? Visual basic?
| Aardwolf wrote:
| At least the programs in the screenshot have actually useful and
| visible scrollbars. Seriously, scrollbars are super useful and
| should never be hidden, they both provide information you want to
| see and actions you want to do, why is everything trying to make
| them as subtle as possible today, even most Linux UI's which I'd
| expect are normally made more for usefulness than "design
| trends"?
| ryanjshaw wrote:
| GitHub's Android app doesn't even show scroll bars. And no
| scroll grab or snapback in apps even when there is a scroll
| bar. Am I the only person who scrolls back to check something
| and wants to quickly return to where I was in a document? Even
| if just FF on Android had this I would be happy.
|
| On desktop we can drag scrollbars but I can't imagine what it's
| like to use modern 4-8px action area scroll bars if you have
| fine motor control challenges.
|
| I just don't understand how we got to this point. Do people not
| use the apps they write?
| posix86 wrote:
| This must be a bug though. If you unfold hidden comments, you
| jumpt to the BOTTOM, where you just WERE, rather than the
| top. So you scroll up, with no scrollbar, frantically,
| because you don't know how far you have to go. Until you
| reach the top - and you drag down ONE MORE TIME, because
| you're scrolling frantically, so the whole thread reloads,
| and everything is folded again, and you're back where you
| started.
| analog31 wrote:
| Moreover, make the scrollbars big enough for my thumbs on my
| touch screen. Or at least make it optional.
| badsectoracula wrote:
| On Linux this depends on your theme really, all the themes i
| use have scrollbars - e.g. here is an example with Gtk3 (which
| IIRC introduced the "autohiding scrollbars" to Linux
| desktop)[0]. It is "cdetheme-solaris" which i think is from
| [1]. I might have modified it a bit though. Though normally i
| use Gtk2 apps with a modified "cleanlooks" theme (a screenshot
| from Lazarus[2] i made a couple of days ago shows it -
| including the scrollbars :-P).
|
| [0] https://i.imgur.com/CAyu5Ay.png
|
| [1] https://github.com/josvanr/cde-motif-theme
|
| [2] https://i.imgur.com/Yw1tTcD.png
| miki123211 wrote:
| > there are a few things that VSCode doesn't give us.
|
| > The first is that a TUI IDE is excellent for work on remote
| machines--even better than VSCode. You can SSH into any machine
| with ease and launch the IDE. Combine it with tmux and you get
| "full" multitasking.
|
| I definitely disagree with this sentiment. At my last job, I had
| to do most of my work on a remote server (because it had a GPU),
| and I found VS Code far more pleasant to use than plain old SSH.
| People recommended using an editor on the server side or freaking
| around with Win SCP / Cyberduck, but VS Code was just so much
| better in so many ways.
|
| Because of VS Code's web roots, it can easily run its frontend on
| your own local computer while running its backend somewhere else.
| This means that most common actions, like moving the cursor or
| selecting text, can be done locally, without the need for a round
| trip to the server. The operations that do have to be executed
| remotely, like saving a file for example, are properly
| asynchronous and don't interrupt your workflow. Everything is
| just far snappier, even if you're working from home, through a
| VPN, on barely working WiFi and an ADSL line.
|
| As a bonus, you get fully native behavior and keyboard shortcuts
| that you'd expect from your platform. Things like text selection
| and copying just work, even some of your addons are carried over.
| medo-bear wrote:
| Using the editor on the server from a remote connection is
| silly. However VSCode is not unique. On my local Emacs I use
| ssh via tramp [0] to browse files on the server and then edit
| localy. HOWEVER I also have physical access to my server. Emacs
| then gives me the added benefit of being able to run in
| terminal on the physical server without any window manager
| installed.
|
| [0] https://www.gnu.org/software/tramp/
| benterix wrote:
| > Using the editor on the server from a remote connection is
| silly.
|
| Why?
| gtirloni wrote:
| Constant screen redrawing and input lag.
| tomjen3 wrote:
| Which is not only not the case with VS Code, but that is
| explicitly explained in at the top of the thread.
| Zambyte wrote:
| > Which is not only not the case with VS Code [...]
|
| Which is also immediately mentioned after the claimed
| that using a remote editor is silly.
| actionfromafar wrote:
| Tramp is quite slow though, IMHO, and last I used it Emacs
| very much expects file access to by synchr.
| 3836293648 wrote:
| Tramp has like four backends, try sshfs if ssh is too slow
| mbreese wrote:
| _> Using the editor on the server from a remote connection is
| silly._
|
| In my experience, this is the best way to do remote work. The
| alternative is to either not work with remote resources
| (data, hardware, etc), work locally and sync changes to
| remote, or work locally with a remote mounted file system
| (unless you need remote hardware).
|
| For the parent, they needed GPU access, so they had to run
| remotely for hardware access.
|
| I normally need particular data that is too big to move
| locally, so I like to work remotely for that reason. I could
| remotely mount drives via an SSH Fuse mount, however the IO
| speed for this method can quickly become a problem. For me,
| it is a much better experience to either use a remote web
| editor (rstudio server), VSCode remotely (which is a remote
| web editor over ssh), or vim. With web based remote editors,
| you still draw the screen locally, but get updates from
| remote. And more importantly, compiling and building takes
| place remotely.
|
| I find this method much better than either pure remote access
| (VNC/RDC/X11) or local-only editing with syncing code and/or
| data. But it very much depends on your work. When I don't
| need to work with remote data, a locally managed Docker
| devcontainer provides a much better development experience.
| globular-toast wrote:
| In my experience, it's the worst way to do remote work.
| There are so many better solutions.
|
| If TRAMP is too slow, just mount the remote filesystem
| locally using FUSE somehow. Use SSH to run processes on the
| remote system like compile and run the program. No need to
| run the text editor on the remote system.
|
| You can also do it the other way around: have your remote
| system load your local data. I developed a small bare metal
| OS this way. Ran the cross compiler locally, had the output
| go to some NFS mount which was also available via TFTP.
| Booted the target system with PXE.
|
| Running a text editor on a remote system is good for one
| off things and maybe as a last resort, but that's it.
| xuhu wrote:
| Is there an _efficient_ way to do "Find in files" from a
| vim or vscode instance running locally and
| editing+compiling remote files via ssh ? Preferably
| something that runs instantly for 1 GiB repos ?
| blackoil wrote:
| Haven't tried on exceptionally large repos, but in VSCode
| since actual find logic is on server, it should work
| simply fine. If I remember correct, even on vscode.dev
| (in browser with no server), your browser downloads the
| search index and then search and navigation are fast.
| Though it may struggle with very large repos.
| mbreese wrote:
| I'm not sure what you mean by vscode running locally with
| editing via ssh. I'm fairly certain that when you do a
| remote connection in vscode, it literally runs the vscode
| program remotely and you are just connecting to a
| tunneled web interface. The only thing running locally is
| the Electron browser shell. So, remote "find in files" is
| running remotely, so it should be as efficient as it
| would be from that side.
|
| That said, you can also open a terminal in vscode and use
| grep. If you're running remotely, the terminal is also
| remote. That's what I normally do.
| ReleaseCandidat wrote:
| VS Code uses ripgrep under the hood (locally and remote).
| mbreese wrote:
| _> just mount the remote filesystem locally using FUSE
| somehow_
|
| This is the step that never works consistently for me.
| There is always some amount of random extra latency that
| makes the this workflow painful. I work with some
| extremely large data files, so random access to these is
| the primary issue.
|
| In general, the idea is that it is often better to do
| compute where the data already is. My experience is that
| you should also do the programming closer to where the
| data is as well. This tends to make an iterative
| development loop tighter.
|
| But this is highly dependent upon what you're doing.
| globular-toast wrote:
| That's a different thing, though. You don't edit the data
| in a text editor interactively, do you? I would do any
| interactive editing with a local editor and then fire off
| remote processes to operate on the data.
|
| It's funny because my reasons against using a text editor
| remotely are exactly the same: to make the development
| loop tighter. I am very upset by latency and always try
| to remove it where possible. I think this is the kind of
| thing where we'd need to look over each other's shoulders
| to understand our respective workflows.
| Tistel wrote:
| I worked at a place that had a half built distributed system
| that we still needed to use (many bidders buying Ad space
| from a API based market). one great thing with tramp is that
| you can tramp into multiple systems simultaneously. So you
| are editing say files from 5 different systems (tweaking the
| yaml or whatever) at the same time. You could then start
| eshells on each of those systems at the same time. It made it
| really easy to adjust the settings and restart multiple apps
| really quickly (big screen, 5 files on top, 5 shells on
| bottom). I always get a kick out of people saying "you use
| that! you need to switch to editor X it has feature Y!" And
| me thinking yeah, that feature has been in emacs since before
| you were born. it is getting a bit crufty in its age though.
| Its main attraction is for people who like LISP. There a
| project called lem (IIRC) that is rewriting it in much higher
| performance Common Lisp.
| vindarel wrote:
| Absolutely: https://lem-project.github.io/ Works for Common
| Lisp out of the box (it's a Lisp machine) and for other
| languages (LSP client).
| pjmlp wrote:
| I was doing exactly the same 30 years ago with X Windows and
| XEmacs.
| OsrsNeedsf2P wrote:
| Even in 2023 you can get vim to be more powerful than VS
| Code. But it's that much more difficult.
|
| As the author states, IDEs haven't necessarily gotten a lot
| better, but imo advanced features have become a lot more
| accessible.
| TheRoque wrote:
| What does it mean "more powerful" ? Do you mean in terms of
| productivity ? It probably depends on your task anyways. In
| 2023, it's still a pain to have decent debugging in Vim.
| For pure text editing, I can believe you, but for software
| development, I highly doubt it.
| falcor84 wrote:
| > Even in 2023 you can get vim to be more powerful than VS
| Code. But it's that much more difficult.
|
| I absolutely agree, assuming you're using "powerful" in the
| same sense as saying that a Turing machine is more powerful
| than a MacBook.
| miki123211 wrote:
| You still had to do a roundtrip for every single click
| though, right? I don't think X Windows has any kind of client
| side scripting system.
|
| That's better than SSH for sure, but still not as good as the
| web model.
| pjmlp wrote:
| X Windows server runs on the client machine.
|
| The client is the server application.
| dpassens wrote:
| The point still stands, though. You need a roundtrip,
| even if it starts from the X server rather than the X
| client.
| pjmlp wrote:
| You always need some level of round trip between keyboard
| and UNIX procecess.
|
| The server application isn't guessing keys, regardless of
| the connection format.
|
| What matters is how the communication is being compressed
| and local optimizations.
| johannes1234321 wrote:
| The difference here is that VisualStudio code fully runs
| the GUI on the local machine and only file IO or external
| programs (compiler, the actual program being devleoped,
| ...) run remotely. Thus the UI reacts promptly to all
| interactions and many of the remote interactions happen
| asynchronously, thus even saving a file will not block
| further actions.
|
| Whereas any non trivial X application does work in the
| client, thus even basic interactions have a notable
| delay, depending on connection.
| pjmlp wrote:
| It shows you never used slow telnet sessions over modems.
|
| There is no difference between doing this over text or
| graphics, in terms of the whole setup regarding network
| communications for data input and output.
| Rusky wrote:
| VS Code isn't doing this with text _or_ graphics, though.
| In X terms, it 's running both the client and server on
| your local machine. It simply doesn't put the network
| boundary in the same place as an X application.
|
| VS Code's "backend" that runs on the remote machine is
| rather only in charge of more "asynchronous" operations
| that aren't part of the UI's critical path, like saving
| files or building the project. It doesn't speak anything
| as granular as the X protocol.
| pjmlp wrote:
| Classic UNIX program architecture in distributed systems,
| apparently some knowledge lacking here.
|
| Long are the days using pizza boxes for development it
| seems.
| Rusky wrote:
| The comparison you made wasn't to arbitrary distributed
| UNIX programs, though. It was to X applications, which
| don't work this way.
| johannes1234321 wrote:
| Again: The key difference is that in VS.Code the UI runs
| local, thus all UI interactions are "immediate" and there
| is no difference between local and remote operation. Yes,
| IO has latency, but where possible that is hidden by the
| UI (possible: saving a file happens without blocking UI;
| not possible: loading a file requires the file to be
| loaded .. but even then the UI can already prepare the
| window layout)
|
| Thisnis very different form a system, where each
| keystroke and each menu action has to be transfered
| first, before the remote side can identify the needed UI
| update and send that back
| pjmlp wrote:
| Again: learn UNIX distributed computing architecture.
|
| Not going to waste more my time explaining this.
| johannes1234321 wrote:
| Telnet is a way more low level protocol. Please learn
| what you are talking about and have a good day.
| keyle wrote:
| Pjmlp is right. You need to read on how X was designed
| for remote work.
| falcor84 wrote:
| I'm sorry to say I'm as confused as I was before I read
| these sentences.
|
| Let me try to rephrase: with X Windows, the UI server
| runs on your local machine, while the UI client runs on
| the remote machine (e.g. your application's server). Is
| that correct?
| pjmlp wrote:
| No, the whole UI runs on the client machine, which in X
| Windows nomenclature is the server.
|
| The client application (on X Windows nomenclature), runs
| on the remote server and is headless.
|
| Instead of sending streams of bytes to render text, it
| sends streams of encoded X Windows commands to draw the
| UI.
|
| Everything else regarding compilers, subprocesses and
| what have you keeps running on the server, regardless how
| the connection is made.
|
| Think big X Windows terminals or green/ambar phosphor
| terminals accessing the single UNIX server, used by the
| complete university department.
| falcor84 wrote:
| Thanks for elaborating, it helped a bit and now this
| section of the Wikipedia article fully clicked for me:
|
| """The X server is typically the provider of graphics
| resources and keyboard/mouse events to X clients, meaning
| that the X server is usually running on the computer in
| front of a human user, while the X client applications
| run anywhere on the network and communicate with the
| user's computer to request the rendering of graphics
| content and receive events from input devices including
| keyboards and mice."""
| freddie_mercury wrote:
| > This means that most common actions, like moving the cursor
| or selecting text, can be done locally, without the need for
| a round trip to the server
|
| No, you weren't doing this. You were making a round trip to
| the server when you moved the cursor or selected text.
| gumby wrote:
| > You were making a round trip to the server when you moved
| the cursor or selected text.
|
| Of course this being X, your machine ran the server and the
| remotes were the clients...
| pjmlp wrote:
| No, as gummy well putted it, all of that was done on the
| client computer.
| pierrebai wrote:
| The fact that it is easy to confuse the server with the
| client in X, it does not change the fact that the XServer
| and XEmacs are running on different computers, so each
| interaction is a round-trip.
| pjmlp wrote:
| XServer and XEmacs are both running on the client
| machine.
|
| Also it is impossible by laws of physics by using
| distributed computing, not having each keypress and its
| display on a rendering surface, being a two way street.
| LegionMammal978 wrote:
| By the "client machine" where XServer and XEmacs are both
| running, do you mean the machine where the human user is
| entering keypresses and viewing windows? Or do you mean
| the machine where the files are ultimately getting
| edited? Clearly, there has to be _something_ running on
| each of the machines, since otherwise one side would have
| nothing to connect to on the other side. What is running
| on the machine opposite the "client machine"?
|
| The idea with VS Code is that neither the keypresses nor
| the displayed windows are being sent over the network,
| but are kept within the same machine where the user is
| entering or viewing them. Only the file data (or debugger
| status, etc.), which are cached and far less frequently
| updated, are sent over the network. Are you saying that
| XEmacs can also function remotely in this way, with
| neither keypresses nor displayed windows sent over the
| network?
| oivey wrote:
| There's some confusion in some of the replies here. The
| point this person is trying to make is that you get the
| remote machine's key bindings, not the local's. That's an
| artifact of the experience being a remote desktop.
| lelandbatey wrote:
| It's similar in outcome (doing "stuff" remotely), but not the
| same architecturally.
|
| VScode runs on the computer in front of you, and it _does
| not_ send key-presses or other user input over the network at
| all. Instead VScode sends file-changes over the network to
| the remote, and executes commands on the remote (e.g. SSH's
| in and runs 'gcc ...').
|
| With X, XEmacs is not running on the computer in front of
| you; it's running on a computer far away. Every key-press and
| mouse click must be transmitted from the computer in front of
| you over the network, received by the remote computer, then a
| response sent from the remote to the computer you're
| interacting with, where it'll be displayed.
| ncruces wrote:
| 100% agree. Remote VSCode over SSH is great.
|
| The resource consumption on the client doesn't bother me one
| bit. Any minimally decent laptop can put up with that load, on
| battery power, for hours.
|
| I would agree with "whatever it takes to make the server
| install leaner, more portable, etc" just without sacrificing
| many features.
|
| If the server side doesn't run on FreeBSD that's really too
| bad. If Microsoft makes it hard to improve by not making those
| bits open source, that's very unfortunate.
| hlfshell wrote:
| This ability also proves useful when trying to do complex
| package management in an isolated manner with ROS; I ultimately
| used a remote vs code shell running off the robots OS to just
| have my ide recognize the many local and built dependencies
| that requires a full ROS setup.
| Tmpod wrote:
| I've been wanting to try something like that with neovim's
| remote features, but haven't found the time. Has someone
| attempted this? If so, how successful was it?
|
| I've always been a big user of powerful laptops because I do
| like the mobility (allows me to work/browse stuff outside my
| home office) and I dread the pains of properly synching my
| files across a laptop and desktop (not only documents/projects,
| but also configs and whatnot).
| blackoil wrote:
| VS Code remote in some cases is better than local.
|
| As the remote can be a docker container, so when I have to do
| some experiment, I create a container takes 5 min to setup. I
| than can play around, test dozen packages and configs, once I
| am comfortable commit last version.
|
| If I want to do some quick testing on project by different
| team, again a local container is setup in 2-10 mins. Once done
| delete the container and my local system isn't messed up.
|
| Last is obvious use case if you want to test anything on
| reasonable large data or GPUs. Create a cloud server, get data
| run your code, tests. Push data to S3 and done.
| ParetoOptimal wrote:
| vscode's model of server on host is good because of low
| latency.
|
| It can be a bit heavy in cpu usage depending on plugins
| though.
|
| I like emacs tramp in theory since it doesn't impose that,
| but latency suffers.
|
| With correct ssh config it usually works well, but many times
| I'd prefer lower latency with emacs being on the host.
|
| That's supposedly possible, but I've never gotten it working.
| eurekin wrote:
| I use that all the time in my hobby tinkering pseudo cloud
| server on a odroid SBC. It feels like I'm literally on that
| specific computer directly. Plugins like docker work as well
| caskstrength wrote:
| > I definitely disagree with this sentiment. At my last job, I
| had to do most of my work on a remote server (because it had a
| GPU), and I found VS Code far more pleasant to use than plain
| old SSH. People recommended using an editor on the server side
| or freaking around with Win SCP / Cyberduck, but VS Code was
| just so much better in so many ways.
|
| I'm not familiar with VS Code setup for remote editing. Does it
| run LSP on remote and give you full hints, errors, etc.
| locally?
|
| > As a bonus, you get fully native behavior and keyboard
| shortcuts that you'd expect from your platform. Things like
| text selection and copying just work, even some of your addons
| are carried over.
|
| Selecting text with Shift+ArrowKey or something like that is
| not a "bonus", it is just a bad text editing experience.
| Keyboard shortcuts are the way they are on Vim/Emacs not
| because their developers can't figure out how to bind
| Ctrl+C/Ctrl+V...
| aidos wrote:
| My understanding follows (I don't use it but I've noticed the
| processes running on other people's machines). Corrections
| welcome.
|
| It's split into a client (web frontend) and server that's
| doing all the work. The server can be run anywhere but it's
| effectively a bunch of stuff installed in a docker container.
| When you start an instance for a project, it creates a
| container for that instance with all the code folders etc
| bound in. LSPs are running in that container too.
|
| It's possible to use your own image as a base (you might have
| custom deps that make installing the requirements for an LSP
| hard, for example).
|
| The trick they use here is that there's some base
| container/volume that has most of the server stuff downloaded
| and rest to go. Whether you start a normal instance or from a
| custom image they do it the same way by just mounting this
| shared volume and installing what they need to bootstrap the
| server.
|
| It also appears they create a frontend window per server
| process too. So the master client process starts, you select
| a project folder, they create a new server container and a
| new client window connected to it. The frontend client is
| local while each server can be anywhere (obviously you could
| run the client with X if you wanted to further muddy that).
| saghm wrote:
| > I'm not familiar with VS Code setup for remote editing.
| Does it run LSP on remote and give you full hints, errors,
| etc. locally?
|
| Not sure about other languages, but when I use VS Code to
| develop Rust remotely, it prompts me to install the rust-
| analyzer extension (which is my preferred LSP server for
| Rust) to a remote whenever I'm opening a project for the
| first time. VS Code is able to distinguish between extensions
| that need to be installed on the same machine as the code
| (like the LSP server) and extensions that are just making
| changes to the local UI.
|
| > Selecting text with Shift+ArrowKey or something like that
| is not a "bonus", it is just a bad text editing experience.
| Keyboard shortcuts are the way they are on Vim/Emacs not
| because their developers can't figure out how to bind
| Ctrl+C/Ctrl+V...
|
| I use an extension for vim keybindings in VS Code. When
| connecting to a remote host, the vim plugin still works fine,
| itand doesn't prompt me to install anything on the remote
| side, since the changes are synced to the remote host at a
| much higher level than that (i.e. locally mapping "dd" to
| "delete this line from this file" and sending that to the
| remote rather than sending the remote the keystrokes "dd" and
| having the remote determine how to interpret it).
| andyjohnson0 wrote:
| Thirty years ago is 1993, and I was a junior dev using CodeCenter
| on SunOS. It was a nice editor/debugger with a C interpreter mode
| that iirc let you inspect aa variable's history and un-execute
| lines of code.
|
| A few years later I was using SparcWorks on Solaris. When I
| realised you could pause on a breakpoint and hover the cursor
| over a variable in the editor to see its value, my brain nearly
| fell on the floor.
|
| A few years after that I moved to PC development using Visual
| C++, and then Visual Studio 97 on NT4. Drag and drop UI builders
| for Windows and Web.
|
| And 30+ years later I still spend a significant part of my
| working day in VS.
| Apreche wrote:
| I love the aesthetic of Borland Turbo TUIs. I went back and tried
| to use TurboVision some time last year. It was not good, to say
| the least. Would be pretty cool if VSCode were themable to the
| extent that WinAmp was, so we could reclaim that old style.
| ytch wrote:
| In the early 2000s, back in my homeland, high schools were still
| stuck using Turbo C for programming classes. This was mainly
| because there weren't many free and lightweight C IDE options
| available for Windows (I know Turbo C is not a free software
| technically).
|
| While Dev-C emerged as a possible alternative for console
| programs and programming contests, it wasn't enough for
| developing native Windows GUI applications without shelling out
| for Visual Studio.
|
| This limitation ultimately led me and some friends to explore
| development on alternative platforms like OS X and Linux.
| Ironically, even to this day, none of us mastered the WIN32 API.
| flohofwoe wrote:
| One nice side effect of modern TUI applications is that they can
| be distributed via Docker Hub as platform-agnostic applications
| that just require a compatible color terminal.
|
| E.g. here's my C64 emulator running in Docker (it's a real C64
| emulator underneath, but only renders the C64 PETSCII buffer via
| ncurses, e.g. no graphics or audio output):
| docker run --rm -it flohofwoe/c64
|
| ...code is here: https://github.com/floooh/docker-c64
| ThinkBeat wrote:
| I loved TurboPascal. I agree with everything the post argues.
|
| I would like to expand a bit on it being before the Internet was
| a huge thing.
|
| The manuals that came with TurboPascal were nearly excellent. It
| included most of what you would need to get started. When you
| didn't quite understand something, you had to spend time to
| figure it out and how to do it well. This could be time
| consuming, but afterwards you gained important knowledge.
|
| Then there were other books to get, there were "coding"
| magazines, though at the moment I cant remember any TurboPascal
| specific ones. and if you were lucky you knew one or two other
| people who were into coding and you could share problems,
| solutions, hints and tips. and warez.
|
| There were also a lot of BBSs out there. Where you could ask
| questions, help others, etc.
|
| These days most people if they face a problem, Google it (maybe
| now ChatGPT it) find someone posted a solution, cut and paste the
| crappy code, crosses fingers that it works and off you go.
|
| (or pull down libraries without having any idea what in the world
| it actually does)
|
| At the same time things have gotten a lot more complex . In my
| TurboPascal days I knew most of the stack. The programming
| language, the operating system, assembler, a lot of how the CPU
| worked.
|
| These days understanding javascript, understanding the runtime /
| compiler etc, before you even get close to the underlying OS, and
| certainly not down into assembler amd CPU
| wwweston wrote:
| I'm not sure whether the issue is stack complexity / depth, but
| there is definitely something in the culture where it's common
| for docs and how-tos and Q/A to tell you _what_ to do, the
| steps /commands/etc, but to do little to help you build any
| kind of relevant domain model.
|
| This isn't exactly new, there's always been documentation like
| this, but I think the proportions have changed dramatically
| since even the early 2000s.
|
| One of my vaguely defined theories is that as valuable as
| automation is, the culture of automation / process has started
| to diffuse and act as an influence on how we think, in steps &
| commands rather than models.
|
| Possible that we've always been steps-results / input-output
| beings, but I wonder.
| Vegenoid wrote:
| I recently created some documentation for a process at work
| where I explained the 'why' for most of the steps and
| commands. Not in great detail, but just a bit of detail. I
| thought that it was good as a step-by-step recipe, while also
| giving context that could help someone in the event that
| something didn't go according to plan.
|
| I was asked to remove much of the context that I provided, so
| as not to confuse the reader, and to make it as direct as
| possible. This is documentation intended for experienced,
| technical professionals. I think that the revised
| documentation is less helpful.
| nunez wrote:
| I _think_ edit.com still ships with Windows!
| zozbot234 wrote:
| Not the 64-bit version, surely. They're thinking about shipping
| a new TUI editor, though.
| nunez wrote:
| So I've been using vim as my IDE for the last ten years. I've
| really enjoyed using it, but VSCode is super duper popular. Has
| anyone like me converted? If so, are you still using Code or did
| you go back to vim? If so, why?
| whinvik wrote:
| I did. I eventually got tired of fiddling with configs, not so
| great debug experience, copy paste issues etc.
|
| Now I just use Vim mode in VSCode. Don't get me wrong, you also
| need to spend time on Configuring VSCode, but it's so much
| better.
| Kamq wrote:
| I gave VSC a shot. It's the stupidest thing, but I just can't
| get over how the side bar (not the file explorer, but the
| little activity bar that you can open the file explorer/plugin
| menu/etc from) keeps re-appearing every time I open certain
| things. I know it's petty, but I can't get over it.
|
| I was able to, mostly, get things to work the way I wanted in
| it, but that ended up meaning I turned it into basically my vim
| setup.
|
| I've moved to jetbrains products at work. Same story there, I
| basically turned it into vim, and hid all the sidebars (but it
| does let me do this). Mostly I'm using it for the debugger, the
| jetbrains debugger is legit.
|
| Still use (n)vim at home a lot, especially for anything that
| doesn't have a dedicated jetbrains ide.
|
| Other than that, the only thing I've really had problems with
| is that graphical editors all seem to think in terms of files
| instead of buffers, and there's no equivalent to vinegar. I
| think that really throws me the most.
| JoachimS wrote:
| Yes, the Borland TUI was pretty good. But nothing came even close
| to what we had on the Commodore 64 with the X-Ass Dev Kit. You
| could code in a nice TUI with syntax highlighting. Press a key to
| assemble in a split second, execute the program, press reset and
| be back in the TUI exactly where you left off. And this with
| source file > 64 kByte, creating executables that occupied the
| complete memory space of the computer.
|
| https://csdb.dk/release/?id=27625
|
| http://www.fairlight.to/docs/text/xass_docs.htm
|
| So productive and easy to use.
| marcosdumay wrote:
| Well, I guess we are lacking any LISP or Smaltalk fans to one-
| up that today :)
| peteri wrote:
| Interesting mention of Sidekick Plus, there was a complete SDK
| for it which I don't think ever got released anywhere (I had a
| copy as I was working for Borland at the time). It allowed
| multiple documents to be open at the same time.
| tgv wrote:
| 30 years ago, THINK C for the mac was already nearing
| discontinuation. It was a great compiler plus plus graphical IDE
| with debugger for its time. Hard to find info about it, but this
| site has some screenshots of the various versions:
|
| https://winworldpc.com/product/think-c/4x#screenshotPanel
| eludwig wrote:
| Yes! I absolutely lived in Think C for many years. You're right
| though, it was on the way out by then, supplanted by
| CodeWarrior and MPW, which were both really good too.
| wzdd wrote:
| How odd to find a mistake in 30-year-old Turbo C++ man pages from
| a screenshot. printf and vprintf send send formatted output to
| stdout of course, not stdin.
| zubairq wrote:
| Somehow those text based IDEs of 30 years ago feel special to me,
| maybe reminding me of a simpler time when there were not too many
| things to master
| __s wrote:
| Language server protocol has really improved things. I use it
| with neovim. Makes it straightforward to get IDE features in vim
| for a variety of languages & allows code analysis part to
| compete. With Go I'm mixing golangci & gopls. In Rust there was a
| transition from rls to rust-analyzer. & this effort is able to be
| shared between vim/vscode/emacs/etc so once someone makes a good
| lsp implementation it doesn't need to be ported everywhere
| bregma wrote:
| 30 years ago I was using vi and the shell on a Wyse 85 terminal.
|
| Nowadays I used vim and the shell in one of many terminal windows
| on one of many workspaces.
|
| Every now and then I try an IDE but I always find the loss in
| productivity and the lack of discoverability to be hampering. I'm
| there to get work done, not to stare at cartoons and fumble
| around for wherever the mouse or cursor has disappeared to again.
| marmakoide wrote:
| I am easily distracted (as in, ADHD-like), I enjoy very sparse
| work spaces in general. Tools with lots of icons, windows, and
| other widgets are very uncomfortable to me. I prefer typing
| commands, I believe a well written command language and a good
| search function are more comfortable. I will go to great lengths
| to avoid some tools if it means avoiding a clickodrome : for
| example, when coding for STM32 devices, I prefer bare metal GCC +
| makefile over STMCube.
|
| To each his own tho, it's nice to have different tools for
| different peoples.
| jmclnx wrote:
| Brief by underwear was by far my favorite in the DOS days. It ran
| great on the 286 I had at the time.
|
| IIRC, something like it was ported to Linux in the mid 90s for
| purchasing. But Linux had vi and Emacs so I do not know how
| successful that was.
| scottlilly wrote:
| I remember a version named "dBrief", for those of us
| programming dBase/Clipper code. It was a great tool back then.
| ilaksh wrote:
| I agree with the article. Turbo Pascal was terrific. There is
| some kind of psychological thing that has me using neovim in a
| terminal all the time for many years.
|
| I guess it's convenient for ssh. But I miss the affordances of
| Borland IDEs. Even last night I was working on a web application
| and was tempted to add a menu at the top of the page, remembering
| how useful they were back in Turbo Pascal and such.
|
| I did a Google search and found this
| https://github.com/skywind3000/vim-quickui
| mamcx wrote:
| TurboPascal and other Borlands IDE were great, but just a lesser
| version of FoxPro!
|
| With FoxPro, you have the features of them, but also, RAD
| form/menu/table/report builder. Like "Let's add MS Access to your
| IDE".
|
| That is the dream.
|
| One of my goals is to built it!
| layer8 wrote:
| Screenshots using 80x50 mode would be nice, which I remember
| using in the early 90s.
| intrasight wrote:
| 30 years ago - and from about 89-94 - my IDE was DataViews. Still
| all these years later I don't know of any IDE that can create
| such graphical interfaces.
| schemescape wrote:
| Is Doom Emacs really 500 MB? How did the author determine that?
|
| I use vanilla Emacs and I believe it was closer to 100 MB when I
| installed it.
|
| Related: I've spent a lot of time trying to find a development
| setup that runs on low-end hardware (as a reaction to modern
| bloat, and also as a way to minimize distractions). It has many
| flaws, but Emacs with Common Lisp is my current sweet spot of
| "price" (resource requirements) to "performance"
| (features+speed).
| pshirshov wrote:
| I'm not aware of anything so convenient and learler-friendly as
| Borland IDEs were.
| orsenthil wrote:
| I remember using Borland Turbo C++. It was the most convenient
| piece of software to get started with programming. If I had been
| introduced with anything else, I would have found it much more
| difficult to cross the initial curve.
| graycat wrote:
| Did a lot of programming without an IDE. Then some years ago,
| tried an IDE: Opened a _project_. Looked at the resulting
| directory ( _folder_ ) and saw ~50 files with what I knew nothing
| -- hadn't even started the work yet.
|
| Got rid of the IDE and returned to my favorite tools and the
| software I was writing.
|
| My favorite tools work fine, and in particular in the directory
| I'm in I actually know what each file there is, what it is for,
| what is in it, where it came from, etc.
|
| In my work, I need to do some programming, that is, _software
| development_. So, I do it.
|
| Difficulties are nearly all from poor documentation of other
| software I need to use. The parts of the programming that are
| really mine are like cooking lunch -- no problems for my part,
| but if the pepperoni is not good, that's a problem. To me,
| programming is, define some variables to store the data, have
| expressions to manipulate the data, If-Then-Else, Do-While, call-
| return, input, output, and that's about it.
| softirq wrote:
| Vim is the only tool I've been able to use at every place I've
| ever worked at, from intern to staff engineer in three FAANG
| companies. I've watched tool teams spend months integrating the
| latest GUI editor, only for it to get killed by corporate
| acquisitions and replaced with N+1 that offers an almost
| identical feature set.
|
| Meanwhile there's always a community of vim and emacs users who
| build all the internal integrations by themselves. Vim and Emacs
| aren't editors, they're platforms and communities, and the
| benefit of using them over VSCode of JB is that you get to be a
| part of these communities that attract the best talent, give the
| best troubleshooting advice, and share advanced configurations
| for everything and anything you could possibly ever want. They
| are programmable programming environments first and foremost, and
| that attracts people who are good at programming and like to hack
| on stuff.
|
| Technologists who choose the propriety path of least resistance
| when it comes to their most important tools I think are
| ultimately missing out in a lot of ways, least of all is the
| actual editing experience. A craftsman should understand his
| tools inside and out, and picking something you can't fully
| disassemble and doesn't have the breath of knowledge a tried and
| true open source tool ultimately becomes just as frustrating as
| the initial learning curve of these older tools.
| cies wrote:
| > that attract the best talent
|
| I've seen hugely talented folk on vim/emacs/emacs+evil, and on
| VSCode/JB. I think was the latter tools do, it make some of the
| advantages of being proficient in vim/emacs/regex available
| with less learning curve.
|
| Currently there are some combinations that simply best-in-
| class: VSCode+TS, JetBrainsIDEA+Java/Kotlin,
| VisualStudio+MicrosoftGuiStuff. vim/emacs may come a long way
| in these areas, but cannot beat the integration level offered
| in these combinations.
|
| Also, you mention "proprietary", but JetBrainsIDEA and VSC are
| opensource to some extend, which does improve community imho.
| But, the fact that they are less "open access innovation"
| projects, and more company owned is clear to everyone.
|
| Finally: AI will come to software devt, and I wonder if AI
| tools will ever be available on true open access innovated
| IDEs.
| softirq wrote:
| > I've seen hugely talented folk on vim/emacs/emacs+evil, and
| on VSCode/JB. I think was the latter tools do, it make some
| of the advantages of being proficient in vim/emacs/regex
| available with less learning curve.
|
| Take Reddit and Hacker News as a fitting analogy, a community
| with a higher barrier to entry/more niche will be smaller,
| but the quality is vastly improved. There's still going to be
| people who sit in both communities, and smart people in both,
| but it's not controversial to say that an initial learning
| curve tends to attract people who can pass the learning curve
| and are motivated to do so. Another great example is the
| linux kernel development process.
|
| > Currently there are some combinations that simply best-in-
| class: VSCode+TS, JetBrainsIDEA+Java/Kotlin,
| VisualStudio+MicrosoftGuiStuff. vim/emacs may come a long way
| in these areas, but cannot beat the integration level offered
| in these combinations.
|
| Integration in some ways, in other ways a terminal based tool
| that adheres to the unix philosophy is more integrated with
| thousands of tools than an IDE where every tool has to be
| converted into a bespoke series of menu items. Just look at
| fzf, git, rg, etc. integrations in Vim. They are only lightly
| wrapped and so the full power of the tool shines through, and
| it's easy to customize it to your specific needs, or add more
| tools.
|
| > Finally: AI will come to software devt, and I wonder if AI
| tools will ever be available on true open access innovated
| IDEs.
|
| In the same vein, AI tools that act as black boxes and are
| integrated in the same transparent way as git or rg in Vim at
| least allow the editor to remain full transparent to the end
| user, and leave the complexity in the LSP or bespoke tool. I
| really see no difference between how AI tools will relate to
| editing as LSPs do today.
| cies wrote:
| > Take Reddit and Hacker News as a fitting analogy
|
| In so many ways they are not, but I see why you come to
| this conclusion. Some overlap in users.
|
| To me opensource is "common good" stuff, HN and Reddit are
| "us playing on some one else's computer+software".
|
| All options have integrations, gits, fzf's, etc. And AI is
| not just "another black box", it's going to save you a lot
| of typing very soon. This is good: more time for thinking
| and crafting; less time for boilerplate-y stuff.
| mjburgess wrote:
| Er.... "VSCode+TS" ... wat?
|
| ITT: people who have not used tools they're talking about
| with confidence.
|
| Everything available in VSCode is available in (neo)vim,
| without a slow buggy UI, modals, misfocused elements, and
| crashes.
|
| All the LSPs used by vscode are easily available, including
| copiolt, full intellisense, and full LSP-backed code
| refactors/formats/etc.
| dabeeeenster wrote:
| I use VSCode every day and cant remember the last time it
| crashed or the UI glitched.
| mjburgess wrote:
| The file explorer constantly glitches -- it never knows
| where the focus is supposed to be so
| adding/moving/deleting/etc. files ends up selecting the
| wrong ones.
|
| Most plugins to add barely any IDE-like functionality
| grind the whole thing to a hault.
|
| Whether you're on insert mode or replace on autocompletes
| is random, and changed by plugins.
|
| The list goes on.
|
| VSCode is an extremely poor quality piece of desktop
| software hacked together with web tech. It's an amazing
| plugin for a website.
| Hackbraten wrote:
| VS Code has been crashing at launch in Wayland since more
| than eight months ago:
|
| https://github.com/electron/electron/issues/37531
| pritambaral wrote:
| Just today I helped a coworker patch their
| /etc/bash.bashrc because VSC's bash integration was
| broken enough to not load bash-completion. Apparently,
| VSC would rather hijack bash's entire boot process (via
| the --init-file flag) and then simulate, obviously
| poorly, bash's internal loading process, instead of just
| sourcing a file into bash after it loads.
| cies wrote:
| Neovim has been hugely problematic for me as an IDE (lots
| of plugins). Lots of errors related to OS dependencies I
| need to manually install and keep up to date.
| caskstrength wrote:
| > VSCode+TS, JetBrainsIDEA+Java/Kotlin,
| VisualStudio+MicrosoftGuiStuff
|
| Do any of these finally have something remotely as good as
| Magit? Or a good email client?
| cies wrote:
| I found JetBrains' Git better in many ways than my console
| flow. Tried, but never got into Magit, as I moved on from
| Emacs.
| FpUser wrote:
| >"Technologists who choose the propriety path of least
| resistance when it comes to their most important tools I think
| are ultimately missing out in a lot of ways"
|
| Nope. Not missing Vim. Live and let live
| bmc7505 wrote:
| The best part is, you don't need to choose between using IDEs
| and your favorite text editor! Most modern IDEs with proper
| plugin support can be configured to provide a superset of Vim's
| functionality. I personally use IdeaVim on the IntelliJ
| Platform [1] with AceJump [2] and haven't looked back. You can
| import many of the settings from your .vimrc and it
| interoperates fairly well with the IDE features. Although I
| prefer Vim keybindings and it is technically possible to hack
| together an IDE-like UX with ctags and LSP, the IDE experience
| is so much better I wouldn't even consider working on a large
| Java or Kotlin project from the command line.
|
| [1]: https://plugins.jetbrains.com/plugin/164-ideavim
|
| [2]: https://plugins.jetbrains.com/plugin/7086-acejump
| softirq wrote:
| I think you missed the point of my post. The value of
| Vim/Emacs isn't the modal editing or key chords. It's the
| community and architecture, which you lose if you're still
| using JB with a frankenport of Vim on top. In fact, I think
| what you're suggesting is the worst of both worlds - a
| reimplementation of Vim on top of an already resource hungry
| and complicated IDE that's supposed to let you do things with
| a mouse. So you're left guessing whether something from real
| Vim will be the same in your Vim, plus you now have two
| competing environments for ways to do things, and you have to
| wait for JB to implement features that (neo)vim have already
| implemented, without supporting the opens source communities
| that did the work in the first place.
|
| You also lose the killer feature of Vim, which is being able
| to work over an SSH connection on any sort of device, even
| those that don't have a GUI.
| maccard wrote:
| > You also lose the killer feature of Vim, which is being
| able to work over an SSH connection on any sort of device,
| even those that don't have a GUI.
|
| In the last decade, I can count on one hand the number of
| times I have SSH'ed into a machine to do actual editing -
| and in every situation, nano would have been totally fine.
| Crippling my workflow so I can handle the most obscure
| scenarios that we've moved past for the most part, is not a
| good decision
| softirq wrote:
| As I said, I have worked at several FAANG companies where
| people had to wait for editor integrations because the
| source repos were so big you couldn't work locally.
| Having a tool that works everywhere no matter what has
| been incredibly valuable to my career. I also wouldn't
| say working for one of these companies that pays very
| well and handles a large portion of the world's traffic
| is obscure.
| oooyay wrote:
| > I can count on one hand the number of times I have
| SSH'ed into a machine to do actual editing
|
| Both companies I've worked at previously employed zero
| trust networking. That means developer laptops don't have
| privileges to things like secrets management
| infrastructure or even feature flag config. You end up
| making a choice: mock services that require trust, which
| comes with its own set of dangerous tradeoffs, or build
| remotely in a trusted environment. Many devs choose the
| latter.
| smrtinsert wrote:
| decade and a half for me and even then I remember telling
| my tech lead, this feels like the stone ages
| JohnFen wrote:
| > In the last decade, I can count on one hand the number
| of times I have SSH'ed into a machine to do actual
| editing
|
| And I need to do this multiple times every workday.
| Generally speaking, this isn't an obscure scenario that
| we've mostly moved past. It's just not a common scenario
| in your particular work environment.
| arminiusreturns wrote:
| It's very telling who has had to actually support prod
| systems and who hasn't when it comes to this topic. Very
| often the only interface we used to have before better
| CI/CD pipelines and idempotence was a serial tty or ssh
| connection. There were a lot of sysadmins run off in the
| 00s (for various reasons such as increasing salaries) and a
| lot of institutional knowledge about real operations such
| as this was lost or diluted.
|
| Another reason why I like to encourage people to not
| customize their vim/emacs too much (at least for the first
| year or so of learning) - because when it's 0300 and prod
| is down you don't want to fight your tools to match your
| expectation. Another example while HN loves to hate on
| bash, but I love and live in bash.
|
| The names and titles have changed, but I still see the same
| dev/ops battles.
| bmc7505 wrote:
| I assure you, the open source community around modern IDEs
| is thriving. I see plenty of innovation in plugin
| marketplaces that is hard to find in even the Emacs/Vim
| ecosystem. Despite its share of detractors, there is a lot
| of value in having a business model that prioritizes
| language support, platform stability and a well-curated
| plugin marketplace. The IdeaVim integration is thoughtfully
| designed and I seldom notice much difference coming from
| Vim. I see where you're coming from with resource
| consumption, but even Fleet is starting to offer
| rudimentary Vim support, which I expect will address many
| of the issues around bloat. [1]
|
| [1]: https://youtrack.jetbrains.com/issue/FL-10664/Vim-
| mode-plugi...
| Tyr42 wrote:
| I'm a happy ide with Vim bindings guy. We do exist.
|
| I think in vim edit patterns when editing text, but I don't
| particularly care about most of the : commands. I'm happy
| to use the vscode command palette for that.
| bitwize wrote:
| > You also lose the killer feature of Vim, which is being
| able to work over an SSH connection on any sort of device,
| even those that don't have a GUI.
|
| The gold standard for remote development is Visual Studio
| Code. All of the UI stuff happens locally, and it transfers
| files and runs commands remotely. It's way less chatty than
| going over SSH or an X11 connection.
| softirq wrote:
| I heavily disagree. From experience, working over SSH
| with tmux allows me to work with my editor, run commands,
| start up various qemu instances, start debuggers etc, and
| other tools that have their own TUIs. I think remote
| VSCode makes sense to people who have very narrow needs
| to edit specific projects rather than live on a remote
| machine.
| maccard wrote:
| Changing IDE isn't that big of a deal.
|
| I would much rather have to spend a few days to relearn a tool
| every few years and to get the benefit of that tool, than
| accept a lower quality tool just to avoid a few days work.
|
| If you worked in C++, then visual studio has been around for 20
| years - visual C++ for 10 years before that. If you use java,
| then intellij has been around for 20 years. Pycharm for 15
| years. If you're writing JavaScript, I don't know what to say
| because the framework du hour has changed so many times in that
| time frame that I don't think the tool saves you much.
|
| > Technologists who choose the propriety path of least
| resistance when it comes to their most important tools I think
| are ultimately missing out in a lot of ways, least of all is
| the actual editing experience
|
| Equally, I can say purists or idealogists are so concerned with
| theoretical changes and breakages, and so afraid of the
| possibility of something changing that they miss out on game
| changing improvements to tooling.
| softirq wrote:
| A person using Vim or Emacs has had best in class integration
| with the unix environment, modal editing, and remote
| development. Today, both editors have integration with VCS
| via fugitive or magit, fuzzy finding, LSPs, tree sitter, and
| code generation tools using LLMs. These tools have not
| stagnated, they've continued to evolve and stay best in class
| in many areas. So the "one tool is better than the other"
| argument doesn't really sway me. My point still stands that
| the community and open architecture are more important than
| any one editing feature.
|
| > Equally, I can say purists or idealogists are so concerned
| with theoretical changes and breakages, and so afraid of the
| possibility of something changing that they miss out on game
| changing improvements to tooling.
|
| Blindly following the crowd is also dangerous. Making choices
| based on principle is what allows good things like open
| source communities and solutions not swayed by corporations
| to exist, even though they might require more up front
| investment.
| cmarschner wrote:
| The problem with these tools is that despite having worked
| with computers for 35 years, I don't get them. My brain is
| not made for them.
|
| I only use out of the box vim when I work on consoles
| (which is still a fair amount of the time), I can exit
| (hey!), mark/cut/copy/paste (ok, yank!), save, and
| find/replace if I must. Everything else is just beyond what
| my brain wants to handle.
|
| A lot of Jupyter lab and some VSCode otherwise. I can't say
| I know all about those either.
|
| The last IDE that I knew pretty well was Eclipse, in about
| 2004. I even wrote plugins for it for my own use. That
| wasn't too bad for its time, I don't quite get why it got
| out of fashion.
| saiya-jin wrote:
| There are those of us that still use it :) productivity
| gains lie elsewhere. And running various maven and git
| commands from command line instead of clicking around...
| something about keeping the skills in better shape
| lolinder wrote:
| > My point still stands that the community and open
| architecture are more important than any one editing
| feature.
|
| No, it doesn't, because it's essentially a matter of
| opinion, not an objective fact that can be measured and
| proven. You prefer to have an open architecture and a
| community of enthusiasts. I prefer to have most of my
| editor features available out of the box, and modal editors
| just confuse me.
|
| At the end of the day, developer productivity is _not_ a
| function of their editor of choice, so what matters is that
| each developer is comfortable in the environment they work
| in, whether that be Vim, Emacs, IntelliJ, or VS Code.
| softirq wrote:
| Learning curves are uncomfortable, so by your logic we
| should all always take the path of least resistance and
| use the tool that makes things easy up front without
| considering the long term benefits of using something
| like Vim or Emacs. I find this to be counterproductive to
| having a great career as a software engineer.
|
| Rapidly assimilating difficult to understand concepts and
| technologies is an imperative skill to have in this
| field. Personally, I find the whole notion of Vim being
| difficult to learn, or not "ready out of the box"
| perplexing. Writing some code that's a few hundred lines
| or less, where it's mostly just importing git repos, is
| easy. Vim has superb documentation. How hard must regular
| programming be if it's difficult to just understand how
| to configure a text editor?
| oooyay wrote:
| I think the way people use IDEs is a lot deeper than just
| reducing them down to "purist" or "ideologist". That sounds a
| tad bit dismissive for something that is essentially your
| trade tool. It's akin to saying all keyboards are created
| equal because they have the same keys. The way you lay the
| thing out and the perspective that you build it for matters
| quite a lot. Distilled in a quote, "the whole is greater than
| the sum of the parts."
|
| I got used to JetBrains' key mappings when I was at my last
| company, I also adored their debugger. My new company uses
| VSCode and I started down the venture of remapping all of
| them to JetBrains keys. I ended up with a lot of collisions
| and things that no longer made sense because the keys were
| mapped using a different perspective when laying them out.
| I'm sure I'm not alone being in a pool of engineers that
| primarily navigate using their keyboard.
|
| VSCode's debugger is better now, but it still doesn't really
| stand up to JetBrains'. On the other hand, launching VSCode
| on a remote box is much easier and their configuration is
| much more portable with their JSON based settings files. I
| like using VSCode, but it took me months to get up to speed
| with how I navigated, and more generally operated with,
| JetBrains' IDEs.
| winrid wrote:
| just to add my $0.02 WebStorm makes writing NodeJS feel a lot
| more like Java - it's pretty good.
| saghm wrote:
| > I would much rather have to spend a few days to relearn a
| tool every few years and to get the benefit of that tool,
| than accept a lower quality tool just to avoid a few days
| work.
|
| I've worked with engineers who studiously avoid configuring
| any sort of quality of life improvements for their shell,
| editor, etc. because they claim it makes things easier when
| they have to use an environment that they can't as easily
| configure, like sshing into a shared box without a separate
| user for them to customize. This mindset has always been hard
| for me to understand; not only does it seem like they're
| optimizing for the rare case rather than the common one, but
| it seems like they're actually just lowering the quality of
| their normal experience in order to make the edge cases feel
| less bad without actually improving them at all
| giantrobot wrote:
| > optimizing for the rare case rather than the common one
|
| This has been a common enough case for me to not get too
| used to super customized local environments. I'd rather
| learn the vagaries of commonly available tools than build
| myself a bespoke environment that I can't port anywhere
| easily. That's not to say I don't do any QOL changes but I
| try to be careful about what I end up relying on.
| anp wrote:
| I've usually had this attitude in the past and for me it
| came from my background: I worked IT, help desk, PC repair,
| etc for years before I got into programming and none of
| those contexts allow customization. And then for a while I
| did infra work where I'd be ssh'd into a vanilla VM or
| container instance to debug a deployment issue. Even though
| I mostly work in my own bespoke environment now, I still
| try to stay fairly vanilla with my tools. It's pretty nice
| to be able to reset my workstation every year to get a
| clean slate and know that it'll only be a couple of hours
| of customization to get back to what I know.
| JohnFen wrote:
| > I've worked with engineers who studiously avoid
| configuring any sort of quality of life improvements for
| their shell, editor, etc.
|
| This is me. It's really easy to explain my mindset here,
| though. If I get used to a nonstandard tool or tool
| configuration, then it causes real productivity issues when
| I'm using a system that lacks that tool or the ability to
| customize.
|
| This is not a rare edge case for me at all. I constantly
| work on a half dozen very different platforms. Having each
| platform work as much like the others as possible _is_ a
| quality of life improvement, and improves the efficiency
| and quality of my work.
| wg0 wrote:
| >I would much rather have to spend a few days to relearn a
| tool every few years and to get the benefit of that tool,
| than accept a lower quality tool just to avoid a few days
| work.
|
| Vim police has issued your red warrants. Justice will be
| served.
|
| Jokes aside, I'd say yes. I have worked with Eclipse,
| NetBeans, JB and nowadays I'm happy with VS Code. For a
| polyglot, it's the best out their at price point $0.0 and
| tooling is pretty good for me.
|
| I'm doing Python, Go, Typescript and occasional Rust without
| missing anything.
|
| Few keystrokes faster with command kata would not going to
| save years of labor. Actuall effort in software engineering
| is not in typing text or in text editing. Not at all. The
| battle is far far beyond that and bigger than that.
|
| EDIT: Typos
| kcb wrote:
| In my anecdotal experience the best developers are the ones
| that don't overly focus on their tools at all. One of the most
| proficient developers I've known was perfectly ok programming
| on a little square monitor with Visual Studio where the code
| window was 40% of the screen real estate.
|
| It doesn't have to be that extreme but it reminds of hobby
| craftsman who focus on having a garage full of the tools of the
| trade while never finding the time to work on a project with
| them.
| SoftTalker wrote:
| At some point in a developer career one shifts from a tool
| focus to a work focus.
|
| I used to be picky about my operating system and often would
| spend time making the tools that I wanted or preferred to use
| work within the project dev environment, as opposed to just
| using the tools my employer provided. It usually ends up just
| being easier, and if everyone is using the same tools then
| pair programming or collaborating becomes easier, too, as
| compared to having to deal with the one stubborn dev who
| insists on using Emacs on a Mac when everyone else is using
| Visual Studio.
| winrid wrote:
| the ide is not more complicated than your customized Vim setup
| once you get it close to functionality (you won't). I use all
| keybindings anyway, so it's not like the UI adds anything bad?
|
| I switched from lightweight editors to IDEs many years ago and
| my productivity went up A BUNCH - even if sometimes it uses
| gigabytes of ram. so what? Even my old used machines have
| 8-16gb of memory now.
|
| I would honestly much rather hire people that work in IDEs than
| people that like to "hack" on their vi/vim/emacs setup. The
| number of times I've been in a screen share with someone while
| they're trying to code or debug something with Vim etc, it just
| feels so slow to watch them work that I get that embarrassed-
| for-them feeling.
| nineplay wrote:
| Mileage varies, even the most ardent vim user I know gave up
| and switched to VS Code this year. It's just too much to try to
| keep up with when projects and technologies change. I've
| programmed in C++, Go, Python, Java, and Angular just in the
| last year. I can believe that there's vim plugins to handle all
| those, but the energy it would take to find auto-complete and
| navigation and formatting and debugging and any number of other
| out-of-the-box IDE functionality is more than I'd like to thing
| about. Then there's the associated tools - Kubernetes yamls,
| swagger, markup, Makefiles. In IDEs they are only one plugin
| download away.
|
| I love vim, I used it exclusively for years when I was doing
| C/C++. I still ssh into servers a lot and use it pretty much
| daily. Still, I'm far to lazy to try to turn it into my full
| time development environment .
| bheadmaster wrote:
| > I can believe that there's vim plugins to handle all those,
| but the energy it would take to find auto-complete and
| navigation and formatting and debugging and any number of
| other out-of-the-box IDE functionality is more than I'd like
| to thing about.
|
| Well, I'll be the bearer of the good news, then!
|
| NeoVim has a native LSP client which unifies all auto-
| complete/navigation/formatting into a single plugin, only
| requiring you to install per-language LSP server.
|
| As for debugging, there's also DSP (Debug Server Protocol)
| which NeoVim doesn't have native support for, but there's a
| plugin for that.
| ParetoOptimal wrote:
| Emacs also has LSP support built-in with eglot and a good
| start for treesitter support.
| josephg wrote:
| There's more to language support than LSP.
|
| I use vscode and IntelliJ these days. In rust, IntelliJ
| lets me rename functions and variables across my entire
| project. Or select a few lines of code and extract them
| into their own function. It'll even figure out what
| arguments the function needs and call it correctly.
|
| I'm writing a paper at the moment using vscode and typst (a
| modern latex replacement). The vscode plugin shows me the
| resulting rendered pdf live as I type. I can click anywhere
| I want to edit in the pdf and the editing window will
| scroll to the corresponding source text.
|
| Maybe there's ways to do all this stuff in vim but I never
| found it. I used vim on and off for 20 years and I barely
| feel any more productive in it than when I was 6 months in.
| As far as I can tell, IntelliJ is both easier to learn and
| more powerful.
|
| Making nontrivial software in vim just doesn't feel
| productive. LSP is the tip of a big iceberg of features.
| christophilus wrote:
| The rename across the project scenario is a LSP feature
| that Neovim supports. I use it frequently. I do miss the
| ability to trivially extract a function. I used to do
| that all the time in Visual Studio back in my C# days.
| sunshowers wrote:
| VSCode is a significantly more pleasurable experience working
| over a 100ms+ network connection than either vim or emacs (this
| being the reason why I switched away from emacs/tramp myself).
| diatone wrote:
| If you haven't already, and I know this doesn't hold up for
| GUI emacs or vim, but consider running them through
| https://mosh.org/
| sunshowers wrote:
| Mosh is definitely an improvement over ssh, especially for
| connections with lag spikes (and I use it for terminal
| sessions). But it's no match for VSCode.
| bitwize wrote:
| Visual Studio Code is currently where all of the tooling effort
| is focused. For the best tools with the best integration you
| should be using it or, depending on language, JetBrains. These
| are easy to use and developers can be productive in them from
| the word go -- without extensive customization. Hell, if you
| open a file in a new programming language, VSCode will suggest
| plugins to install.
|
| You do NOT want to build integrations by yourself. You want to
| build whatever product you're building. The fact that vim and
| emacs users do this is yak-shaving that pulls precious time
| away from the task at hand and serves as a distraction for
| editor fetishists. Do not become an editor fetishist. Modern
| IDEs help you become more productive faster and give you more
| support for things like debugging. (You _are_ using a debugger
| to inspect and analyze your code, right?)
| petercooper wrote:
| I forget if it were a MS or Borland thing, but I recall some of
| these DOS IDEs having an "expert mode" feature in the menus where
| you'd get, by default, only the most useful features, but could
| then turn on all the menu features by enabling said expert mode.
| Anyone remember this? Some tools (VS Code..) could sorely do with
| this today, I feel.
| rurban wrote:
| I loved Multiedit Pro and Walter Bright's Symantic C IDE back
| then, besides emacs. Still with emacs, the others are gone.
| vrnvu wrote:
| Loved the concluding question. "So the question I want to part
| with is: have we advanced much in 30 years?"
|
| Every time I see all the bloated software we are putting out. Is
| it really worth it?
|
| One program that does it all vs many programs that do one thing
| really well. Oh, maybe someone should write about this concept,
| it maybe interesting to ponder :)
| NikkiA wrote:
| 30 Years ago Watcom would be ripping through Borland's assumed
| monopoly and rapidly becoming the most used C/C++ IDE, only to
| have Visual Studio do the same to it in 2-3 years time.
| wkat4242 wrote:
| I was always kinda partial to the Borland IDEs. I even used the
| concept on Linux for a while in the form of "RHIDE". It wasn't
| bad UX but the software was pretty badly written so in the end I
| dropped it. I never enjoyed anything as bare bones (or requiring
| such a learning curve and setup of adding) as vim. Right now I
| use VS Code. Not a huge fan of it and I really wish it was
| available as a TUI application but for now it seems to be the
| best around.
| lumb63 wrote:
| Even if VSCode/other IDE had features that blew Neovim out of the
| water, I don't think I'd move over. The customizability, modal
| aspect, and open-source-ness are huge for me. I can create macros
| on the fly for repetitive tasks, can navigate without ever having
| to stall my train of thought to touch my mouse, and customize
| every single key binding and the code that it runs. I can create
| custom commands to do every single thing I've ever conceived of
| wanting to do. I can upstream bug fixes and see those others have
| suggested that haven't been up streamed yet. I will concede that
| for some, maybe this is too much work to set up "just a text
| editor", but I enjoy it, and I spend most of my day editing or
| viewing text, so to me, it's worth it.
|
| If there is one thing I've learned in my years of software
| engineering, it's that everyone prefers different workflows. Let
| people build their own, however they want, with whatever tools
| they want, and they will be happier for it.
| bwann wrote:
| I'm surprised there's no mention of QBasic that shipped with MS-
| DOS >= 5.0. This was built on top of EDIT.COM, and while it only
| ran a BASIC interpreter instead of compiling an executable like
| full-blown QuickBasic.
|
| IIRC it had a rather extensive help lookup system for functions,
| data types, reference tables, error codes, and whatnot. You could
| step through your program, set debug points, all without exiting
| to DOS. It was my first ever exposure to an IDE, I thought it was
| pretty nice for what it was.
| djur wrote:
| I loved QBasic. That integrated help system also came with
| extensive sample code for each function, including some full
| programs. Copying and modifying those was a huge boost to
| learning how to program.
|
| (The article does mention QBasic, though.)
| owlstuffing wrote:
| My favorite part of late 80s early 90s C/C++ dev was the shitty
| auxiliary monitor used as a dedicated debugger screen. I swear I
| STILL find situations where I want that back.
| lowbloodsugar wrote:
| Separate _computer_ talking to SoftICE over serial port.
| owlstuffing wrote:
| Not mentioned in the article is JetBrains CLion. Best C/C++ IDE
| to come along in decades.
|
| https://www.jetbrains.com/clion/
| masto wrote:
| Meanwhile, outside the world of PCs and DOS...
| https://youtu.be/uknEhXyZgsg?si=nx7IEAC9RZDwEeWY&t=3251
| 123sereusername wrote:
| Sorry, gotta call bullshit on this post. There were several
| _good_ IDE GUIs 30 years ago.
| anon-sre-srm wrote:
| Borland C/C++ 3.1 came in the largest by volume and by weight
| shrink wrapped box ever due to inclusion of printed library and
| API references for DOS and Windows and other tools.
|
| Borland-branded products were the pro versions compared to the
| Turbo-branded ones.
| SomeHacker44 wrote:
| Did not see mention of Symbolics Genera, a vastly better IDE than
| any of the ones pictured in this article. And it was quite mature
| 30 years ago.
| btbuildem wrote:
| The Borland IDEs really were the swiss army machine guns of their
| time.
|
| Turbo Pascal was one of the first languages I learned -- never
| really used it again, but looking back, it was an excellent
| beginner language.
| malkia wrote:
| The two most indispensable programs for me are "midnight manager"
| for Linux/OSX and the like, and "Far Manager" on Windows (and mc
| there too under wsl2).
|
| I'm lost with Far Manager at work. I've stopped using Explorer
| long time ago (and use it only to verify some reported workflow
| from other users, or some obscure thing not possible in Far
| Manager).
|
| Other tools: tig (pager), emacs, mg (mini-emacs) - I wish that
| was available on Windows too without needing msys2/cygwin, and
| few others.
|
| Back in the DOS days - it was Norton/Volkov Commander, PC Tools,
| but also Turbo/Borland Pascal 3, 4, 5; the most awesome E3 editor
| (from this series - https://en.wikipedia.org/wiki/E_(PC_DOS) ) -
| and many more
| charlieyu1 wrote:
| 15 year old me could use the Turbo Pascal debugger well because
| it was so intuitive. Now I'm just not comfortable with using
| debuggers at all and I keep spamming prints in my code.
| TheCapeGreek wrote:
| Does anyone here feel kind of trapped by their IDE now?
|
| PHPStorm + Laravel Idea + the laravel-ide-helper package provides
| such a great PHP/Laravel development experience that I haven't
| been able to replicate in VS Code or Sublime. But chowing as much
| RAM as it does, it feels sluggish. Or at least, not as snappy as
| the alternatives. But I just haven't been able to find a middle
| ground with the lighter alternatives.
|
| Running the IDE as a thin client with Jetbrains Gateway sounds
| like a decent solution, if your backend server is close enough
| for latency to feel okay. From a ~4GB PHPStorm usage, PHPStorm-
| via-Gateway on GitPod was 1.2GB max.
| Throw839 wrote:
| Perhaps consider better hardware, not some cheap chromebook.
| 4GB RAM is very little usage for advanced IDE.
| dvh wrote:
| Installer for Delphi 1 looked like this:
| https://delphicodemonkey.blogspot.com/2012/06/delphi-10-inst...
| Trixter wrote:
| The article covers some good points, but misses a few extra
| things that the Turbo Pascal 7.0 IDE included that made it a true
| powerhouse:
|
| - A full OOP tree to determine parents/traits of descendant
| objects
|
| - The ability to edit, assemble, and trace through both inline
| _and external_ assembler code
|
| - A registers window that showed all registers and flags at any
| stage of runtime
|
| ...all while able to run on the first 4.77 MHz 8088 IBM PC, which
| was long in the tooth by the time TP 7.0 came out. (The OOP tree
| required a 286 as they only added it to the protected mode IDE.)
| This made the TP 7.0 IDE a complete development and debugging
| environment _for assembler_ as well as Pascal.
| badsectoracula wrote:
| > ...all while able to run on the first 4.77 MHz 8088 IBM PC
|
| Eh, more like it walked rather than ran :-P.
| fred256 wrote:
| > MS-DOS shipped with a TUI text editor since version 5 (1981)
|
| MS-DOS 5 came out in 1991, not 1981.
| novok wrote:
| IMO the real loss in IDE tech is the speed that visual basic 6
| gave you to make desktop guis.
|
| Web and mobile development (which I have done all 3) are
| significantly slower than what you could do with VB6. It's really
| strange why we haven't gotten back to it.
| hk1337 wrote:
| Would this be similar to the .NET Webforms? That could be done
| in C# or VB.
| haddr wrote:
| Or even better one: Delphi (if you were into pascal)
| dkersten wrote:
| I've often heard people mention that Delphi was a superior
| RAD GUI experience than Visual Basic, but as someone who's
| never used it, what is it that made it so great compared to
| VB or other GUI builder type tools (eg Qt Designer)?
| 1vuio0pswjnm7 wrote:
| As a Windows software user back then, I preferred
| applications written in Delphi. They were always smaller and
| faster for me than alternatives.
| purplejacket wrote:
| XY-Write anyone?
| lowbloodsugar wrote:
| SlickEdit was around back then, in TUI form. Fantastic.
| shagie wrote:
| Twenty nine years ago, Metrowerks Code Warrior was released
| https://en.wikipedia.org/wiki/Metrowerks
|
| I had the shirt (
| https://www.rustyzipper.com/shop.cfm?viewpartnum=282427-M558... )
| and wore it for many years... wish I knew where it was (if its
| still in one of my boxes somewhere).
|
| The IDE was no where near as clunky as a text only DOS screen.
| https://www.macintoshrepository.org/577-codewarrior-pro-6
| shultays wrote:
| 30 years ago late 1980s / early 1990s
|
| Yeah, no
| LoulouMonkey wrote:
| Fantastic article, thanks for sharing.
___________________________________________________________________
(page generated 2023-12-28 23:00 UTC)