[HN Gopher] Benefits of Not Using an IDE
___________________________________________________________________
Benefits of Not Using an IDE
Author : defaulty
Score : 142 points
Date : 2021-08-21 14:06 UTC (8 hours ago)
(HTM) web link (alexander-hansen.dev)
(TXT) w3m dump (alexander-hansen.dev)
| elondaits wrote:
| There are some things that I feel that IDEs do better than a
| terminal or editor:
|
| - Running tests (test running requires juggling a hierarchy of
| tests, their results, their declarations, plus with an IDE you
| can run tests directly from the test declaration)
|
| - Lint / Static analysis (you get the warnings automatically as
| you code)
|
| - Debugging (it's easier to watch several things at once, easier
| to inspect a complex object, you can inspect through a tooltip
| when hovering over a variable on the code)
|
| I really don't care about how anyone prefers to work, but I fear
| that anti-IDE people in many cases don't even debug (except by
| printing), lint or test... which I _DO_ care about, if I have to
| work with them. These things are about being a responsible coder.
|
| I could also add that the "Local history" feature of Jetbrains
| IDEs can save code from accidental deletion, which is another
| thing that goes beyond personal preferences.
| Lio wrote:
| Seems like the features you've mentioned are already available
| in most editors or through external tools such as test
| runners/watchers or debuggers.
|
| For example you mention the "local history" feature of
| Jetbrains IDEs as being essential.
|
| Vim, and I think Emacs, have had that built in for more than 20
| years in the form of backed up undo trees.
|
| There are still somethings IDEs can do that editors can't e.g.
| deep static analysis, but with LSP support that set is reducing
| all the time.
| bastardoperator wrote:
| I have no need to do any of this locally outside of debugging
| when I can commit/push early/often and get the same feedback
| from my CI/CD process. It also solves the "local history"
| problem because my code lives on a remote. If anything what
| you're describing sounds like a lack of standardization or
| gates in order for code to reach production. That's an
| engineering problem, not an IDE vs text editor issue.
| voidhorse wrote:
| I've used vanilla vim more or less without plugins and with a few
| keymap tweaks for the majority of my software development work.
| Every now and then I have to use an IDE to match some upstream
| requirements, and I much prefer using a near featureless text
| editor. Sure the auto-suggest, tab completion, etc. are nice, but
| I feel like the downsides aren't worth it. I also find it's easy
| to get lazy when using an IDE and produce sloppier code on the
| whole.
|
| In most cases I feel that using an IDE nets you short-term,
| micro-productivity gains and also nets you long-term
| rot/maintenance headaches. imo it's typically not worth it.
| noidesto wrote:
| I share the same sentiment after using IntelliJ w/ Pycharm for
| a little over a year.
| Shorel wrote:
| Well, I get linters (errors are highlighted even before the file
| is saved), jump to function definition and a lot more in Sublime
| Text.
|
| I mean, I don't use an IDE, but at the same time, reading the
| comments, I don't miss much of what it offers.
| jayd16 wrote:
| Sure but doesn't that just mean sublime is a pretty good IDE?
| Shorel wrote:
| I'm fine with that =)
| bluedino wrote:
| "The benefits on not working with enterprise Java"
| wvenable wrote:
| This definitely feels more like a rant about Java than about
| IDEs.
| nrvn wrote:
| Benefits of being a troll,
|
| And art of creating clickbaity titles.
| schipplock wrote:
| > Some Projects with 40000+ files might take >5 minutes to load.
|
| I would buy a more powerful computer. I have a project with 34908
| files and IntelliJ doesn't care. Not quite 40_000+ files but
| still a lot :).
|
| Also with IntelliJ I make fewer mistakes. This "thing" is just
| more intelligent than I am. Add "SonarLint" to the game and I
| sometimes don't even know _why_ I am wrong :P.
|
| Also I think "Avoid IDE lock-in of your project" is the wrong
| subtitle for the following paragraph. You would have the same
| problems by using just a text editor.
|
| Rd6n6 mentioned refactoring. Do that in an editor and you will go
| crazy after a while :).
|
| I love and hate my IDE :).
| mcguire wrote:
| Pro tip from an ex-performance guy: Allowing your developers to
| use machines more powerful than your minimum targeted device is
| a very good way to produce software that will not run on your
| maximum targeted device.
| h4x0r12345 wrote:
| The minimum targeted device is sometimes not even capable of
| running the development environment. Doom was developed on
| $10k NeXT workstations. Good luck trying to develop Doom on a
| 386.
| habibur wrote:
| You need an IDE for Java. That language is built for IDE.
|
| The requirement is a little bit less for some other popular
| languages.
| hota_mazi wrote:
| Any statically typed language benefits greatly from an IDE,
| if only for the automatic refactoring.
|
| Dynamically typed languages can hardly be automatically
| refactored.
| wizzwizz4 wrote:
| I don't like PyCharm, but it can certainly refactor Python
| programs. What are you talking about?
| wokwokwok wrote:
| Listen, long story short: just say no to nonsense like this.
|
| Given the choice of a) tooling, or b) no tooling, you're not
| being smart, cool or clever by choosing b.
|
| Obviously, what tools you pick _are important_ and heavy IDEs
| like IntelliJ are a trade off between speed and functionality,
| and yeah, more nimble tools do exist, and it's _definitely_ worth
| trying different development tools to see what makes you most
| productive.
|
| ...but "no IDE" is just rejecting everything because you didn't
| like one thing; it's just being lazy.
| abetusk wrote:
| IDE !== tooling
|
| Your sentiment about the right tools for the job is spot on,
| and one should strive to choose tools that make you more
| productive but IDEs are one tool of many.
|
| There's a host of other things to consider, like what is the
| testing environment like, library management, repository
| layout, etc. When you're working across a wide variety of
| languages, setups, environments, etc. choosing an IDE like
| Eclipse or Atom might not always be the right tool for the job.
| This also completely neglects the fact that vi/vim and Emacs,
| while mostly considered "text editors", can be enhanced to
| essentially be IDEs in their own right.
|
| I think the article's arguments are weak, but so is this
| counter-argument, sorry.
| bbrree66 wrote:
| Agreed. It's obvious this is written by some pseudo
| intellectual who wants to feel smart and different by saying
| they don't use an IDE. Benefits easily out weigh any downsides.
| toiletaccount wrote:
| jesus christ. coding used to mean something. i guess we all
| should eat baby food because we arent being smart cool or
| clever by wasting time and energy chewing.
| Mikeb85 wrote:
| Dunno, I kind of like no IDE. If you use an IDE, it's basically
| editor + a bunch of command line tools being invoked from the
| IDE's interface. You can also just use an editor + those
| command line tools from a terminal. It's the same functionality
| with a slightly different workflow and IMO not worse.
|
| I disagree with the author's dislike of code completion tools
| but somewhat agree with the other points. In particular how
| some IDEs create their own project structure.
| drunkpotato wrote:
| The best developers I've found are the ones who know how to
| work without an IDE, even if their preference is to use one.
|
| Contrastingly, the worst, slowest developers I've worked with
| rely on their IDE without understanding what it's doing for
| them, and are helpless in new/unsupported situations. They
| also, 100% of the time, screw up their git repositories on a
| regular basis, and need someone who knows what they're doing to
| help them out, costing their colleagues time and frustration
| helping them when they won't help themselves.
|
| Some people from the first group find they prefer not using an
| IDE. It's rather the opposite of laziness, it's choosing the
| workflow they find most productive, even if it differs from
| your preferred workflow.
| oldsecondhand wrote:
| But you don't use git to write your code. Code autocompletion
| and cross referencing are pretty big productivity boosters
| that won't prevent you from learning command line git. Also I
| bet you don't use the command line for diffing files.
|
| Also the problems is that most IDEs half ass their git
| client. When I was using Sourcetree, I rarely ever felt the
| need to go to the command line.
| dmurray wrote:
| > Also I bet you don't use the command line for diffing
| files.
|
| Wait, isn't this normal? I run "diff" and "git diff" all
| the time (I think I have those both set up to invoke
| colordiff, but it's still a command line program). Also vim
| -d.
|
| Occasionally I browse diffs on Github or Bitbucket instead.
| I don't find it an improvement. I do favour editors over
| IDEs, but I don't think I'm an extremist on this one.
| tester756 wrote:
| It's not about IDE or not, it's about curiosity how do things
| work under the hood.
| deltasixeight wrote:
| Nah if you ever used a modern IDE from the jetbrains line. In
| order to even get the IDE working with a project you need to
| configure it to work.
|
| That absolutely necessitates understanding of the details of
| what's going on. You are literally building automation by
| using additional tooling. It doesn't build it for you.
|
| Also screwing up a git repo, what does that even mean? A bad
| commit?
| h4x0r12345 wrote:
| If you have a Maven project, IntelliJ will open it and
| configure itself automatically. The IDE user doesn't need
| to know anything about Maven build configurations. It just
| works.
| irrational wrote:
| That sounds more like a problem with git than a problem with
| the IDE. Why does git allow you to screw up your repository?
| slim wrote:
| Bacause git is powerful
| moron4hire wrote:
| Being able to do the wrong thing should not be confused
| with power. It's just a broken tool, that is broken so
| often, it needs this so-called "power" to clean up after
| it when it shits the bed.
| Akronymus wrote:
| The very power that allows you to screw up is the power
| thar makes the tool worth using in the first place.
| aoms wrote:
| Git simply gives you the power to do 'things', if that
| results in a state you didn't want.. well.. go figure
| kristjansson wrote:
| Exactly this. Productive use of IDEs (or vim, or emacs, or
| vsc, or ...) is the opposite of cargo-culting: one knows
| exactly how to decompose the abstractions presented by the
| IDE. Should they fail, or prove limited, one grumbles a bit
| and then goes and does it by hand.
|
| Using or not using an IDE because good developers use but
| don't need an IDE misses the point. It's never the choice of
| tool, it's knowing how to use it.
| thrower123 wrote:
| The worst developers I've worked with have been sado-
| masochists who refuse to use IDEs.
|
| People take pride in being less productive and making things
| harder than they need to be.
| rzwitserloot wrote:
| This is a bit of a cargo cult argument.
|
| Specifically: "The best developers" indeed know how to work
| without an IDE. They also know 5 programming languages, 50
| libraries, and know a whole bevy of esoteric randomness, such
| as difference between a Thompson-NFA style regex engine and
| the limitations thereof, or something like that.
|
| There is no such thing as a 'the best developer' that doesn't
| know much. The 'knows many things and has lots of experience'
| is a tautologic argument.
|
| In the mean time, bad programmers 'use an IDE a lot and are
| lost without it'. That's also tautologic.
|
| In other words, your observation proves absolutely nothing,
| in regards to whether it is wise to use an IDE or not. You're
| not going to magically turn a bad programmer into a good one
| by uninstalling their IDE. You're not going to ensure a new
| programmer is going to turn into a good one if you advise
| them to forego an IDE, nor will you ruin a potentially good
| one if you install an IDE on their computer.
|
| It says nothing.
| CharlesW wrote:
| > _The best developers I 've found are the ones who know how
| to work without an IDE, even if their preference is to use
| one._
|
| "Best" is a marketing term. How do you mean it as it applies
| to software quality or productivity?
|
| I'm trying to understand if you're serious, since the author
| (who notes "I myself use IntelliJ, CLion and MySQL workbench
| almost everyday") doesn't even seem to believe what he's
| writing.
| lultimouomo wrote:
| > The best developers I've found are the ones who know how to
| work without an IDE, even if their preference is to use one.
|
| The best swimmers can stay afloat with pounds and pounds of
| weight dragging the down; the worst swimmers will drown.
| Doesn't mean weighing you down makes you a better swimmer.
| falcolas wrote:
| Ironically, it would make you a better swimmer - it will
| help you build up strength, stamina, and technique.
|
| An excellent choice in analogies.
| cwyers wrote:
| I mean, assuming you don't drown.
| bryanrasmussen wrote:
| Harrison Bergeron would never have ascended so high, were
| he not so greatly weighed down first.
| dimgl wrote:
| I'm not even sure what to make of this. No sane developer I
| know will work without an IDE, much less prefer not using an
| IDE.
|
| Sure, we can probably write code without an IDE but in what
| way does that mean I'm a better developer? I feel myself
| cringing whenever I hear that a developer is going to reach
| for TextEdit or Notepad++ to write code.
| deltasixeight wrote:
| Those editors aren't really part of the conversation
| anymore. I would say they were maybe over 12 years ago. Not
| so nowadays.
|
| People are referring to SublimeText, Vim, Emacs, VSCode as
| Programming Text editors. VSCode is currently the most
| popular with vim as purist second and Emacs for "elite"
| hackers.
| bccdee wrote:
| The thing I hate most about IDEs is when they insinuate
| themselves into a project's development workflow so deeply
| that you can't make do without them.
|
| Do I have to spin up a whole session of the IDE just to run
| my test suite? Do I have to dig through eleven nested GUI
| settings dialogues to find out what the command to build the
| damn project is, just so I can tweak a build parameter? Is
| there so much boilerplate or XML or whatever within the
| frameworks we're using that writing or changing code is
| impossible without automation? These are bad things.
|
| An IDE can be a powerful abstraction, but when the underlying
| layer it's abstracting over becomes inaccessible, then all
| it's doing is adding more complexity by obscuring concrete
| details.
| tester756 wrote:
| >An IDE can be a powerful abstraction
|
| how IDE "can" be an abstraction?
|
| It's tool, it's wrapper (e.g button over commandline
| commands), but abstraction?
| xxpor wrote:
| The line between the two isn't very clear, nor is it
| productive to really argue about it, IMO
| tester756 wrote:
| >nor is it productive to really argue about it
|
| I do agree
| Nevermark wrote:
| It was still a good question!
|
| There is a line between a tool:
|
| A) that makes managing relevant information more
| efficient, while not hiding any of that information.
|
| B) vs. a tool that hides some details, providing a
| tradeoff of higher productivity MOST of the time, but at
| the cost of requiring a fall back tool on other (rare?)
| occasions.
|
| I would say, once a tool stops providing access to any
| (even rarely) relevant details, it has become an
| abstraction.
| jeffeld wrote:
| "An IDE can be a powerful abstraction, but when the
| underlying layer it's abstracting over becomes
| inaccessible, then all it's doing is adding more complexity
| by obscuring concrete details"
|
| This. All day long.
| squarefoot wrote:
| And night, and the whole week.
|
| I can edit, compile and install my kernel and all its
| drivers in a few command lines from shell, why more and
| more projects, most way simpler than a kernel, ask me to
| install for example VSC just to build them? Give me a
| Makefile and possibly enough instructions to integrate
| its options into the favorite IDE, but making the IDE a
| requirement, especially for small projects or those one
| simply wants to build and install, adds only more
| complexity.
| Yajirobe wrote:
| > The thing I hate most about IDEs is when they insinuate
| themselves into a project's development workflow so deeply
| that you can't make do without them.
|
| Isn't this the case with Android Studio? Is it even
| possible to do Android development without Android Studio?
| papaf wrote:
| _Is it even possible to do Android development without
| Android Studio?_
|
| Oh yes: https://www.lambdanative.org/
| rzwitserloot wrote:
| > Do I have to spin up a whole session of the IDE just to
| run my test suite?
|
| In the java ecosystem at least, the answer is no. But in
| highly CI-based situations, the answer is still no, but you
| DO need the CI system to be up, and the only way to run a
| test at all is to just commit something and see the CI
| system run it, e.g. because the tests require a database
| engine that isn't installed on your development machine.
|
| I'm not saying that's a good idea, just saying that I have
| seen that in real (as in, for pay and for real eyeballs)
| dev teams. I've never observed 'I only know how to run my
| tests inside the IDE'. IDEs (again, this is mostly speaking
| from the perspective of the java ecosystem) use build tools
| as project definitions, and those build tests all know how
| to run the test suite from the command line. `mvn test` is
| all you need to type.
|
| > Do I have to dig through eleven nested GUI settings
| dialogues to find out what the command to build the damn
| project is, just so I can tweak a build parameter?
|
| No, it's `mvn install` or `mvn build` or whatever take on
| 'build' you are looking for specifically.
|
| If you ditch your IDE, __nothing__ whatsoever would change:
| Your build is _still_ based on a build tool. (it better be,
| in the sense that trying to run the build by hand or by
| patching a bunch of shell scripts together is almost 100%
| correlated with very low quality dev teams in my
| experience).
|
| In other words...
|
| what are you on about? IDEs don't abstract such details
| away to extreme degrees. In fact, insofar that they ever
| did (generally in GUI builders, which, what with the web
| and languages like java and Adobe Air and silverlight
| falling by the wayside in the past few years for front-end
| dev - are kinda dead), the new takes on such tools all very
| explicitly keep the whole 'actually this just edits a text
| file of some sort and this automated click-the-GUI-together
| tool is bending over backwards to ensure that the
| underlying file looks as close as possible to what you
| would write by hand.
| szatkus wrote:
| In my current organization I saw a project, where there
| is no Maven. The build system is a couple of
| configuration files for Eclipse IDE and that's the only
| way to run it. I'm glad I didn't have to do anything
| around that.
| touisteur wrote:
| The ant eclipse plugin does some lifting for you.
| Sometimes, it can be better this way than having 2
| buildthings not in sync... But yeah ant all the way if
| everyone's happy with it...
| AmpsterMan wrote:
| My team used to have stuff off that nature after we
| inherited the code base. Acquisition and movement of HQ
| meant a brand new team on a 15 year old B2B SaaS. Trying
| to move away from the combination of shell scripts, perl
| scripts, eclipse config, etc. Over to Gradle has been
| painful, but with it for onboarding new devs.
| eropple wrote:
| That definitely does happen with _really_ poorly
| considered starting points, but in my experience it 's
| also maybe a day's work to pull that apart and put it
| into Maven/Gradle (unless you've also got, like, some
| really terrifying ant stuff to go with it, and even then
| you can sometimes ask "is this even necessary?" and get
| with the chopping down).
|
| IntelliJ even has tooling to get you started:
|
| https://www.jetbrains.com/help/idea/convert-a-regular-
| projec...
| wheybags wrote:
| If you're not familiar with them, have a look at visual
| studio SLN files. They are exactly what was described.
| There is more and more being pushed into the msbuild
| files instead (a separate format, that is at least
| theoretically separate from visual studio) but the weird
| and underdocumented sln file still exists. And msbuild
| files are absolutely unreadable XML crap anyway, good
| luck writing one by hand.
| SV_BubbleTime wrote:
| There's only one place I can disagree.
|
| Some examples of Teaching/learning.
|
| The US Navy is teaches C without an IDE. This makes sense for
| them. If they had institutional knowledge going back to the
| 1970s, it all still pretty much applies and looks the same as
| it did 50 years ago, or another 50 years from now.
|
| Yes. You should use a good tooling if your goal is to make
| something.
| newbamboo wrote:
| "Men have become the tools of their tools. Money is not
| required to buy one necessity of the soul. Most of the luxuries
| and many of the so-called comforts of life are not only not
| indispensable, but positive hindrances to the elevation of
| mankind."
|
| Henry David Thoreau
|
| One day the IDE will do most of the coding. Users will just
| click "ok" and spend most of their time asking IT to reboot and
| reinstall things until it all just works(tm).
| Waterluvian wrote:
| "Power drills have batteries or cords and motors that wear down
| and they're more expensive and complex and can break more
| easily and it's just smarter to bring hand crank tools to the
| worksite."
|
| - Nobody
| zucker42 wrote:
| People still use shovels even though excavators exist.
| citizenkeen wrote:
| Those are not comparable. If there was a backpack mounted
| shovel that powered my digging I'd never use a shovel
| again.
| beebeepka wrote:
| People still drink water even though Brawndo exists
| bluedino wrote:
| Portable electric power tools are such a game changer when
| working on cars. I could never go back to the days of doing
| it by hand, it would be ten times worse for construction.
| desine wrote:
| I would never use power tools on my motorcycle or car. On
| threading, nuts/bolts/screws should always be torqued
| gently into spec. On unthreading, I prefer to feel if
| there's significant resistance, warranting a
| cleaning/deoxidization of the part.
|
| Predrilling a screw hole in some hard wood? Yeah I don't
| need to feel anything except the power of lithium cells
| dumping electricity into torque.
| the_third_wave wrote:
| Power drills are simple tools, they are the 'vi' equivalent
| of the 'ed' manual drill.
|
| The physical equivalent of an IDE would be a laser-guided
| auto-centering/levelling drill with automatic drill bit
| changer/sharpener, depth guide, dust evacuation and material
| sensor with automatic lookup for which hole size and depth to
| use for the given task. It would weigh 15 kg, need an
| external power pack and be unusable in tight corners. For
| some tasks it would be a great time saver, for others it
| would just be in the way. Some workers would love it, others
| would fight it. Some would be more productive using it,
| others would be far more productive if only that damn
| megadrill did not insist on using that oversized drill bit
| while they knew the construction would be much stronger by
| using a slightly smaller bit, necessitating them to override
| the megadrill tool selector for each and every hole they
| drilled.
| 9front wrote:
| The Hole-Hawg drill is the IDE equivalent. Recently
| discussed on HN:
| https://news.ycombinator.com/item?id=28015229
| the_third_wave wrote:
| No, a Hole-Hawg [1] - made famous in these circles by
| Neal Stephenson's essay 'In the beginning was the command
| line' [1] - is just a powerful drill without any bells
| and whistles, a "lump of metal with a handle sticking out
| of it". It would be more sort of an 'ed on steroids',
| trading off ease of use for raw power.
|
| [1] https://www.milwaukeetool.com/Products/Power-
| Tools/Drilling/...
|
| [2] https://web.archive.org/web/20180218045352/http://www
| .crypto...
| grogenaut wrote:
| I think you mean cnc machine. And those are amazingly
| productive.
| the_third_wave wrote:
| No, a CNC machine is a distinct entity which enables the
| user to create objects which can not be created using
| only a power drill. The lower-tech predecessor of a CNC
| machine is a milling machine [1], not a hand-held drill.
|
| [1] https://en.wikipedia.org/wiki/Milling_(machining)
| dogma1138 wrote:
| There isn't anything a CNC can make that someone with a
| file and a lot of times on their hands cant.
|
| Heck you can do that with a drill too mostly using jigs.
|
| I had to create a few times quite complex shapes from a
| block of aluminum and what I did I just 3D print a bunch
| of jigs and drilled out 98-99% of the material away in
| the same way a CNC would and finished it with dremmel.
| the_third_wave wrote:
| > There isn't anything a CNC can make that someone with a
| file and a lot of times on their hands cant.
|
| True, but the comparison here was against a power drill,
| not a person with a file and lots of time on his hands.
| While it may be theoretically possible to achieve the
| accuracy of a CNC mill using a power drill it would not
| be the tool of choice. Achieving the repeatability of a
| CNC mill using hand tools is hard, the more complex the
| piece the harder it becomes.
|
| To get back to basics without getting lost in a forest of
| tools these comparisons are based around the 'To IDE, or
| not to IDE' question. The CNC mill was pulled in through
| a side door but doesn't really feature in the comparison
| which was between a simple power drill and the
| hypothetical 'smart drill' I dubbed 'megadrill' which
| tries to be as 'helpful' as possible. Some people would
| like such a contraption, others would shun it.
| [deleted]
| mionhe wrote:
| CNC mills are super useful. But not all the time. I
| regularly (not all the time, or even a majority, but
| regularly) choose a manual mill over my cnc because for
| simple jobs that only require a part or two, it's faster
| than setting up the 3d model, deciding on cutting
| strategies, setting up the tools, etc.
|
| My choice in editors follows the same logic. If I just
| need to jot down some notes, or knock together a simple
| bash script or something, it doesn't really matter what I
| use. Whatever has syntax highlighting and is available on
| that system is great. Something more complex, where I
| don't want to spend brain cycles on repetitive tasks or
| management that the tools can handle for me, I'd rather
| use something that will handle that for me.
| jayceedenton wrote:
| This is probably a good time to mention Tim Ewald's talk,
| Programming With Hand Tools:
|
| https://youtu.be/ShEez0JkOFw
| jkepler wrote:
| Wouldn't another analogy be knowing how to navigate a boat
| with a sextant and a chronometer versus modern radio and GPS
| maritime navigational aides? The latter's more efficient, but
| those with deep knowledge of navigation understand how to use
| the former if necessary.
| mayankkaizen wrote:
| As someone replied to GP, you should definitely know how to
| complete tasks with only basic tools and without advanced
| tools. But it doesn't mean you should only use basic tools
| or no tools at all. I mean I do know how to calculate
| without calculator but it doesn't mean I dont use
| calculator. I use it all the time. Of course deep knowledge
| almost always means that you have a strong hold on the
| basics.
| Waterluvian wrote:
| Yep. I was taught how to navigate with a compass and
| sextant and such.
|
| And then we did it once.
|
| And then we used GPS and Total Stations ever since.
| hakfoo wrote:
| Conversely, for model building, I have much better results
| using #80 drill bits in a hand held twist drill than trying
| to chuck them into a power drill and hope that it will not
| break the bit or rip the delicate work asunder.
|
| Similarly, an IDE can be overkill when you're writing a self-
| contained one-off task, or dealing with an opinionated IDE
| that doesn't fit with the project you're importing.
| throwaway09223 wrote:
| I think you've hit upon an important distinction, because
| while construction workers won't be bringing hand tools "to
| the worksite," there are in fact many people who do use hand
| tools for fine woodworking in their woodshops.
|
| People work with wood for different reasons and people write
| software for different reasons. All of these tools and
| approaches can be valid.
|
| Some may be interested in rapid and low cost large scale
| construction - big teams working fast. Others may be
| interested in creating a thing of beauty either independently
| or in small groups of likeminded craftsmen. It shouldn't be
| surprising that we have many different tools and practices.
| jakear wrote:
| Exactly. When I'm tinkering around in Scheme crafting
| cutesy little interpreters a simple text editor is great,
| and having an IDE would feel like having someone standing
| over my shoulder whispering to me every rule of a game I
| already know by heart.
|
| On the other hand, when I'm working on a new area in a
| several thousand file project with dozens of contributors,
| or any number of its side-projects that I may have never
| seen before in my life, it's more like having talented
| counsel at my shoulder informing me of all the various
| contracts I'd be expected to observe for any possible plan
| of action I might consider taking.
| Waterluvian wrote:
| I agree and love this distinction.
|
| When I'm paid to produce, I use tools that help me produce.
|
| When I'm enjoying my passion, I actually do use an entirely
| different set of tools!
| tpoacher wrote:
| You seem to be mistaking lack of an IDE with lack of tooling
| ...
| TeeMassive wrote:
| Me too I dislike this kind of absolute statements about IDEs.
|
| The author make a few good points about abusing some features;
| just like abusing _any_ tool beyond their intended purposes.
|
| IMO the best is the compromise of making the code IDE agnostic.
| So yeah, I do use IDE _s_ and other tools in conjunction to
| that the tools I used and the skills I know are not bound to a
| specific project.
| adrian_b wrote:
| There is a very large difference between a very smart source
| code editor (e.g. Visual Studio Code) and a complete IDE. I
| consider the first essential and the second completely useless.
|
| For editing or just navigating the source files, the smarter
| the editor is, the better.
|
| On the other hand I have never seen any IDE where the
| management of projects (e.g. adding/deleting/moving/renaming
| files and setting compilation/linking options) and the
| compilation/building/running functions are as simple and fast
| as how that can be done without using an IDE (if you know how
| to do it in the right way).
|
| Especially the Eclipse-based IDE's provided by many vendors of
| embedded products are the worst offenders.
|
| I have wasted too much time with helping puzzled coworkers to
| find where in the hierarchy of IDE menus one could find
| whatever was needed. Even when knowing where to find the
| commands, using the IDE menus was many orders of magnitude
| slower than what I could do outside the IDE to perform the same
| function upon the project.
| eyelidlessness wrote:
| > There is a very large difference between a very smart
| source code editor (e.g. Visual Studio Code) and a complete
| IDE. I consider the first essential and the second completely
| useless.
|
| I know VSCode is positioned this way in the market, probably
| to differentiate it from VS. And I switched to it from a much
| less "smart" editor (TextMate, which I still adore! No
| offense meant to TM creator/maintainers!).
|
| I'm having a hard time seeing this as a clear distinction,
| however. I mean, VSCode has a built in debugger/protocol,
| language server/protocol/intellisense, file system aware
| refactoring, code rewriting refactoring, integrated git
| client, inline blame and history navigation, GitHub
| integration, linter integration including automated fixes...
|
| I understand it's a different tool than VS, but I honestly
| don't have a clear understanding of what separates editor
| from IDE in this case.
| adrian_b wrote:
| The good editors for programmers, since ancient times, for
| example already in the BRIEF editor for MS-DOS, before
| 1990, provide means to attach arbitrary CLI commands or
| scripts to menus or keyboard shortcuts.
|
| Therefore, if you want you can invoke from inside the
| editor any commands needed for project management or for
| compiling/linking/running/debugging.
|
| So in the end you are right that a powerful editor can do
| what an IDE does, after some customization.
|
| The main difference with IDE's is that the project
| management provided by the IDE is normally non-optional,
| you are forced to always use it.
|
| In 30 years of experiencing a very large number of IDE's I
| have not seen even a single one where using its project
| management functions would not waste a lot of time
| comparing to non-integrated alternatives.
|
| I think that it is sad that only a very small number of
| developers know how to use correctly the ancient program
| "make". I do not know why this happened. To use correctly
| "make" I have never needed anything else besides reading
| the GNU make manual provided with gmake, but it seems that
| very few people read the manual.
|
| The only time when I had to write makefiles was more than
| 20 years ago, when I have written a set of universal
| makefiles, which I have been using unchanged for every
| software project ever since. For any new project I need to
| just (optionally) add a file with some extra definitions,
| e.g. a list of directories where the source files are
| located or the names of the executables or libraries that
| must be built. If no definitions are provided, suitable
| defaults are used, e.g. the directory with the Makefile
| also contains the source files and the target is an
| executable with the same name as the directory. The
| Makefile per target directory may contain just a single
| line, with an include directive for the universal makefile.
| The universal makefile searches all the source directories
| for all the possible types of source files, selects
| automatically the appropriate compilers based on the
| language indicated by the file name extensions and on the
| cross-compilation target if one is specified, generates
| automatically all the dependencies and so on.
|
| Instead of using "make" like this, almost all the open-
| source projects that I have seen have huge and immensely
| complicated makefiles that are much more difficult to read,
| understand and modify than the source files of the
| programs. When the makefiles are generated from templates,
| those are typically even more difficult to understand and
| modify.
|
| I have no idea who loves those extremely complex methods of
| compiling and building software projects.
|
| During the years, a lot of replacements for "make" have
| been introduced, which are better than "make" used wrongly,
| but I have not seen any which is better than "make" used
| rightly, without pointless complications.
| cweagans wrote:
| Have you published this makefile somewhere? I'd love to
| take a look at it.
| Zababa wrote:
| I think the difference is that when you start out with
| VSCode, you tend to do things by editing text and using the
| CLI, and with time you add plugins and tools that makes it
| more into an IDE. When starting out with IntelliJ or
| Pycharm or whatever, you first start by trying to
| understand the IDE itself to generate your project, and
| then you start writing code inside the project. A bit like
| libraries and frameworks. At least that has been my
| experience.
| bdcravens wrote:
| It also depends on the language. I don't think I'd consider
| working in a .NET project with an IDE, but it's overkill for
| Ruby or Javascript projects.
| HelloNurse wrote:
| Regarding especially Eclipse, project and build management in
| an IDE _can_ be good. Typical Java projects that use Maven
| and are built "officially" with scripts and CI systems
| without an IDE can be worked on by Eclipse quite cleanly by
| - Checking sources out of version control - "Importing"
| them in the Eclipse workspace as projects from existing code
| in an arbitrary location - Configuring what Maven
| installation, and with what configuration files, is to be
| used to build your projects - Defining a grimoire of
| Maven command lines (build and test locally, build and deploy
| somewhere else, package for release, etc.) as run/debug
| configurations
|
| The impact is limited to harmless project metadata files
| (containing nothing important that isn't mirrored from Maven
| POM files) and repeating in the closed world of Eclipse
| options configurations, paths etc. that are probably already
| in scripts, CI pipeline definitions and so on.
| IncRnd wrote:
| It's not being lazy. There is no need for me to use an
| Integrated Development Environment.
|
| Many of the most highly productive people use Separated
| Development Environments. The integration is most times not
| necessary. I have never had an IDE provide a feature that I
| needed and couldn't quickly create or obtain.
|
| People let you install your tools in your monolithic IDE
| package. Why are you so insistent on degrading people who are
| experts in their fields?
| z5h wrote:
| In 20 years of working as an engineer and also interviewing,
| I've seen maybe 3 people that could be as productive without
| an IDE. They certainly exist, but I believe they are rare
| exceptions.
| IncRnd wrote:
| I understand. So, the differences must be the backgrounds
| or amount of time the people have spent as programmers.
|
| I'm, of course, not talking about certain platforms that
| almost certainly expect or require the use of a specific
| IDE build tool.
| thinkharderdev wrote:
| It kind of depends on how we are defining IDE. Every
| developer I know who doesn't use an IDE uses either VS Code,
| vim or emacs with a bunch of plugins which approximate IDE
| functionality (but are much more customizable and
| configurable which I suspect is what they like about it). At
| the end of the day every IDE is just a text editor with
| plugins too. It really comes down to whether you want
| something that just works (and probably forces you to do some
| things THEIR way on some margin) or you want to tweak your
| dev environment to be just right for your workflow.
| bccdee wrote:
| Yeah, that's true. For me, it'd be somewhat irritating to
| work without LSP features like "jump to definition," "hover
| to view doc string," or even tab completion. Arguably,
| these are IDE features. But when it comes to higher-level
| features like build tooling or even grepping, I'd much
| rather work from a command line.
|
| Something like tab completion can't exist outside the
| editor, but as soon as features can exist as separate
| tools, bundling them together begins to feel like a
| limitation. Having separate tools means you can discard the
| ones you don't need, which is part of what leads to fully-
| featured IDEs feeling so bloated to me.
| thinkharderdev wrote:
| True. I've been slowly moving towards VSCode from
| IntelliJ over the past year or so and that has mostly
| been driven by better Scala LSP implementation (Metals
| has gotten immeasurably better over that time). And even
| when I used IntelliJ exclusively, I more or less used it
| as a text editor with code completion/jump to definition.
| I still used a separate terminal for git, builds, etc.
|
| I think there are also certain efficiencies that come
| with bundling as well though. You end up with a bunch of
| things specifically designed to work together so they in
| some cases are better than the generic, composable tools.
| I still find myself firing up IntelliJ from time to time
| because sometimes it just seems to work better (faster,
| more responsive, etc) even though the feature I am using
| technically exists in VSCode + Metals.
| the_third_wave wrote:
| > ...but "no IDE" is just rejecting everything because you
| didn't like one thing; it's just being lazy.
|
| This is the vi vs emacs debate transposed to build tools and as
| such will never conclude. Some like their tools to be as
| "complete" as possible, others want them out of the way. You
| might be closer to the first camp, I'm close to the second,
| others are in between. All of these choices are fine, there is
| no canonical truth here and as such the "nonsense" label used
| above is just that, nonsensical.
| alpaca128 wrote:
| For me the choice is more a) tooling that does everything but
| distracts me all the time b) tooling with some limitations but
| versatile, consistent across languages and completely modular.
|
| I'm not rejecting IDEs because I didn't like one thing. I like
| nothing about IDEs except the refactoring feature; but even
| that doesn't make up for the painful UX. IDEs are like MS Word:
| they do everything I need but I hate every moment of it.
| chooseaname wrote:
| c) choosing a platform that over complicates things and
| requires tooling that most developers use but never quite
| understand.
|
| > you're not being smart, cool or clever by choosing
|
| c
| l0b0 wrote:
| Definitely. There's no dichotomy though. I use _some_ of the
| features of my IDE: editing obviously, interactive debugging
| and just general exploration via Ctrl-click are infinitely
| faster and more powerful than anything I 've used on the
| command line. It's not great for everything though. So I keep
| swapping to the terminal for everything which I find more
| effective there: Git, running tests, creating projects, and the
| like.
|
| Basically, don't think a single toolset is always going to be
| superior to your other toolsets. Feel free to mix and match,
| and change over from one toolset to the other when it's
| convenient or just more efficient. But of course moderation
| isn't going to get the clicks.
| bootlooped wrote:
| There is a common perception with electric bicycles that the
| rider will pedal less hard to go the same speed. But there is an
| alternative: they could pedal the same amount and go faster.
|
| I kind of view IDEs like that. You can use it as a crutch, or you
| can take the energy you would have used thinking about the things
| the IDE is now doing for you and focus it elsewhere.
| lifeisstillgood wrote:
| veering off-topic, that's one of the problems I have with
| electric bikes - they stop being bicycles and become another
| kind of vehicle - a faster vehicle that needs longer stopping
| distances and now has a highe r fatality rate when colliding
| with a pedestrian.
|
| We see this in London cycle lanes. Some cycles are doing a
| commute, some are trying out for the olympics, some people are
| doing 25 on a electric scooter and these are _alien_ - hard to
| predict because they don 't obey our intuition about physics. A
| guy on a scooter does 10mph tops and puts his foot down a lot.
| rohansingh wrote:
| What blows my mind is that in New York, we've decided to deal
| with this by requiring speed governors on pedal-assist
| bicycles to limit them to around 20mph... while they're
| required to share the street with cars that are free to
| travel at almost any speed.
| u801e wrote:
| Traffic rules basically give drivers a way to deal with
| other vehicles going different speeds. So a the driver of a
| scooter going 20 mph and the driver of a car going 40 mph
| can share the same road, just like a driver of a truck
| going 40 mph can share the road with the driver of a car
| going 60 mph.
| rohansingh wrote:
| And yet, that same car can go 80 or 90 or even over 100
| mph, which would be illegal on any road. Why?
| gene91 wrote:
| The key difference is whether a motorcycle driver's license
| is required. The electric bicycle manufacturer can choose
| to forgo the speed governors and be subject to motorcycle
| safety/licensing/etc regulations.
| [deleted]
| dharmab wrote:
| Motorcyling channel Fortnine did a video in depth on this
| topic: https://youtu.be/wM8Xli2KTzI
|
| (They've also done some more motorized cycle and electric
| content lately. A recent video showed how to rebuild an old
| motorcycle's frame into an electric motorcycle using a kit.)
| dncornholio wrote:
| An e-bike that goes 60kph seems a bit out of the ordinary.
| Most are limited to 25kph or 45kph. But even 45 is still
| fast with only a bicycle helmet though
|
| I see, your own peddling can make them go faster. Ok these
| things should be illegal!
| taeric wrote:
| In practice... You absolutely peddle less hard on electric
| bikes. You still go faster, because motors.
|
| So, at large, I would guess the "as a crutch" use happens far
| more.
| rhn_mk1 wrote:
| > they could pedal the same amount and go faster
|
| Nitpicking, but in the world of regulations, electric assist
| tapers off until around 25-30 km/h, at which point you start
| carrying the entire bike anyway, plus the dead weight of the
| battery and the motor.
|
| I wonder if this simile could be extended to programming. Being
| hindered by not being able to choose your own tools?
| bootlooped wrote:
| In the US, class 3 electric bicycles can assist up to 28
| miles per hour, or around 45 km/h. I _might_ be able to ride
| 28 miles per hour on a regular bicycle, but I can 't do it
| for very long.
| luckylion wrote:
| Are they regulated like non-electric bikes? In Europe, I
| believe the main difference is insurance and license, which
| are required for e-bikes with motor-supported speeds >
| 25km/h (at least in some countries, not sure how uniform
| it's handled).
| bootlooped wrote:
| As far as I know there is no jurisdiction in the US where
| you need either a license or auto insurance for a class 3
| electric pedal assist bicycle. I think you generally ride
| them wherever regular bicycles are ridden.
| chrismorgan wrote:
| Not everywhere. Australia supports both the European pedelec
| classification of 250W with a 25km/h cutout and a local one
| of 200W with no speed limit (which can be hand-throttle in
| some states but must be pedal-assist in others). New Zealand
| just has a flat 300W with no speed limit.
|
| I live out in the country in Australia. I'm planning a
| velomobile with an auxiliary motor for both touring and local
| use, and with this combination I expect and hope to attain an
| average speed of over 50km/h for the ~39km trip to the
| nearest town for church and groceries on Sundays. (I
| currently tend to average 22-24km/h on my recumbent tricycle
| with no motor, the trip typically taking 1h35-1h50m, with an
| estimated average power output of 120W. 200W is quite a lot
| to add!)
| snazz wrote:
| To extend that analogy, I choose a regular bicycle because I
| ride for fun and exercise, not speed. But if biking were a
| serious mode of transportation for me, I would get one that
| gave me the most assistance possible so I could go faster and
| farther.
|
| IDEs are similar. If you want to be as efficient as possible
| and get as much done as possible, you want an IDE. But if
| learning and exercising your mind is the goal, you'd be better
| served with a text editor.
| vletal wrote:
| There has been a great surge of ebikers among people working
| in food delivery services around Prague last year. Before
| that most of the guys used regular bikes.
| zo1 wrote:
| Now imagine your job being to get from point A to B. 99.5% of
| all the devs I've seen that insist on "VS Code" struggle so
| bad it's laughable, and yet when you point it out they turn
| it into some sort of IDE pissing contest.
| djhworld wrote:
| Ehhh, I dunno.
|
| I've yo-yo'd between minimalist setups and full blown IDEs over
| the years.
|
| Nowadays I'm happy with IntelliJ for Go development and a little
| bit of Rust. There's something quite freeing from not having to
| tinker much with configs and just get on with actual work!
|
| Admittedly I do use the terminal feature in IntelliJ quite
| extensively so I'm not making full use of the features, but meh.
| cgh wrote:
| For context, the author is a student with little real-world work
| experience producing software for a paycheque. To put it mildly,
| there's a lot more to writing software in a modern work
| environment than your choice of editor or whatever.
| h4x0r12345 wrote:
| Exactly. The youngsters like to show off their L337 hacky
| editor configurations. The rest of us are just getting actual
| work done in IntelliJ or Visual Studio.
| spapas82 wrote:
| I was developing python/django for a couple of years in
| notepad++. I had a very slow computer this time and using
| anything else seemed way too slow. The featured I missed most
| from notepad++ was not being able to quickly open files for
| editing (ie like using ctrl+p in vscode).
|
| Beyond that, it was a great experience. Of course, using python
| contributed to that great experience since most things can be
| easily remembered and the autocompletes are not so useful due to
| the dynamic nature of the language. When I needed to do
| Java/spring development I always fired up eclipse even if though
| I knew it would take 5 minutes to start and a couple of seconds
| for each suggestion to appear. However, trying to develop in Java
| without an IDE by having the javadocs open and copying and
| pasting all the package and class names all the time and missing
| everything static typing offers your is a nightmare!
| fartcannon wrote:
| In Linux, it often feels like the whole OS is the IDE. In the
| same shell, you can edit source files, compile, debug, execute,
| rename, search, create and execute scripts to do literally
| anything with any language, use git, surf the web, update,
| reboot, launch a game, etc, etc.
|
| An IDE on top of that always felt restricting to me. Like why
| limit yourself? But maybe that's a windows/Mac thing.
| bitwize wrote:
| What about refactoring tools? What about integrated debugging,
| stepping right into the code you're editing on your screen?
| What about hot reload?
|
| If Unixheads would stop pretending their stone-knives-and-
| bearskins development tools were equivalent to full-fledged
| IDEs, development would have advanced much more than it has
| decades ago.
| fartcannon wrote:
| I use both, one method is just less restrictive.
| mst wrote:
| The whole "real men use vi" type superiority complex
| failure mode is intensely annoying (and I say this as
| somebody who often has original ex-vi installed) but the
| inverted version where you just have a superiority complex
| from the opposite direction isn't actually any better.
|
| It continues to amaze me that "it's worth becoming familiar
| with a wide range of tools and then pick the one that's
| going to work best for _you_ in any given situation " is a
| concept so many people have trouble with.
| fartcannon wrote:
| Def. Just be careful not to read passion as a superiority
| complex, or a recommendation as condemnation.
| pittmajp wrote:
| We have that to. We even have post Mortem debugging. Did you
| know you can load a core dump into gdb? To me it seems like a
| new generation of developers is reinventing the wheel because
| they don't know about what tools are available.
| ByteJockey wrote:
| > What about refactoring tools?
|
| The old unix editors have had rename across project, find
| references, go to definition/implementation for several years
| at this point via lsps (the same way vscode gets its
| functionality).
|
| > What about integrated debugging
|
| Those are usually (slightly ecosystem dependent) wrappers
| around a terminal debugger.
|
| > What about hot reload?
|
| Correct me if I'm wrong, but these are also wrappers around
| cli functionality (once again, might be ecosystem dependent).
| And you're probably just saving yourself the trouble of
| writing/running a script.
| p_j_w wrote:
| >>What about integrated debugging
|
| >Those are usually (slightly ecosystem dependent) wrappers
| around a terminal debugger.
|
| And, in my experience, are vastly more convenient than
| terminal debuggers alone.
| detaro wrote:
| Running an IDE doesn't stop me interacting with the shell, why
| would it?
| fartcannon wrote:
| In fact lots of IDEs have a nice little terminal baked in to
| use. Just depends which way you wanna go about using these
| tools, yah know?
| [deleted]
| teddyh wrote:
| > _the whole OS is the IDE_
|
| This view is _exactly_ the view esposed by Brian W. Kernighan
| and Rob Pike in _The Unix Programming Environment_ from 1984:
|
| https://en.wikipedia.org/wiki/The_Unix_Programming_Environme...
| liorben-david wrote:
| This is the equivalent of never washing your hands to build up
| immunity. You're just spending more time and energy to solve a
| problem that the tool can solve for you.
|
| Are you more independent for it? Sure, I guess. But I'd rather be
| efficient then get brownie points
| MagicWishMonkey wrote:
| I know it's a personal anecdote, but 100% of the devs I've worked
| with who refused to use an IDE ranged from below average to flat
| out bad at software development.
| pskinner wrote:
| Funny because my anecdote is that any devs I've worked with who
| only use an IDE are average to flat out bad at software
| development.
| gnuvince wrote:
| I conclude from your comment and the one above you that devs
| are average to flat out bad at software development.
| enriquto wrote:
| Using an IDE is like playing the piano and putting stickers with
| the name of each note. There's no objective downside to doing
| this, but it's not really going to help you play better music
| once you go beyond the very basic stuff. It may give some people
| a false sense of security, but it won't make a difference to a
| professional programmer. Some of those programmers (but not all,
| and that is OK) will become annoyed at the stickers once they
| know how to play the instrument.
| thinkharderdev wrote:
| I'm not sure the piano analogy is really apt. A piano has 88
| keys (and really it's just the same keys repeated across
| multiple octaves) so any competent player will of course
| quickly memorize the keys and playing the piano would be
| impossible by actually reading the labels on the key anyway.
|
| Doing software development means using a variety of different
| standard APIs which many combinations of methods/parameters/etc
| as well as any number of custom, project-specific APIs. Sure,
| if you work on the same project using the same codebase for
| years on end then you can probably effectively memorize all the
| relevant APIs, but few developers are in that situation. You
| move from project to project and have to drop in to large,
| existing codebases with their own conventions and abstractions.
| walshemj wrote:
| Isnt an editor with syntax highlighting, Atom for example and an
| IDE
| unknownOrigin wrote:
| If you're no using an IDE, you're not working in big enough
| codebases or are not required to move fast enough - either way,
| I'm not really interested what you have to say. After you work in
| this business for over a decade, you'll know dumb ideas just
| because you've seen them several times before. "No IDE" is just
| that. A dumb idea.
| bigbillheck wrote:
| I don't find any of that person's arguments particularly
| compelling, especially this one:
|
| > Respect the Unix Philosophy
|
| I have no respect for the unix philosophy.
|
| They go on to clarify:
|
| > (Visual Studio's poor man's autocomplete is a prime example)
|
| And so from this I deduce that the author considers autocomplete
| to NOT be part of the "one thing" that an editor, under the Unix
| Philosophy, is supposed to do. But both emacs and vim have
| autocomplete capability, so either autocomplete in an editor is
| only philosophically acceptable if it's good enough, or emacs and
| vim are not worthy of the Philosophy.
| BrianOnHN wrote:
| Switching between languages frequently, VS Code is great. Other
| IDEs are better for specific languages/contexts.
|
| However, I credit my understanding to the time I spent in
| Notepad++ and times I explored code on the whiteboard while
| reading docs. Thus, I feel my "internal compiler" would not be
| anywhere as useful if I had always relied on productivity tools
| (IDEs).
|
| That said, my input isn't maximized by more efficiently producing
| the same thing, like a factory, in which case I say IDE all the
| way.
| ju_sh wrote:
| I can understand people using text editors (a la Vim, Emacs) if
| they've been using them for donkeys years and are extremely
| proficient and productive with them, additionally for making
| quick changes to files from the terminal.
|
| However, why any developer would reach for one of these tools now
| when working on application development is beyond me (other than
| to feel like a 1337 OG hax0r of course)
|
| Power tools > hand tools
| bitwize wrote:
| Always use an IDE for significant software projects. Maybe not
| for small scripts, or for faffing about on your own learning to
| code Charles Petzold style. But for professionals working on
| production code, artificially restricting your productivity by
| denying yourself the time- and effort-saving features of a good
| IDE is tantamount to goldbricking.
| jlokier wrote:
| Counterargument: Artificially restricting your productivity by
| denying yourself the features of a high-functioning daily-
| driver editor and CLI git+make and replacing them with a low
| quality IDE that lacks useful features and the features in it
| don't work very well anyway is tantamount to goldbricking.
|
| This is very common in embedded systems.
|
| I ditched one such IDE in a project a couple of years ago and
| switched to Emacs + git + make + command line compilers. The
| productivity improvement was huge. Finally, decent tools.
|
| Even debugging worked better via command line GDB. It was more
| reliable than the one in the IDE, and scriptable.
|
| The quality of what went into the repo went up as well.
| klodolph wrote:
| These days I'm seeing more common support for using an IDE with
| an external build system. Best of both worlds... you get to have
| the IDE add the tedious import statements at the top of your
| file, and people without the IDE won't have any problems with
| your project.
|
| Depending on the language and build system, this might be
| something I set up manually (set up an IDE project to mirror the
| build system), something you can set up automatically (export
| build system to IDE project), or there might be a standard layout
| for source code that mostly works.
| dave333 wrote:
| In the early days of IDEs (1990s) there were projects where I
| spent more time trying to figure out the IDE than I did on the
| project code! Same goes for many frameworks. Just when you get
| competent, the IDE/framework changes. AFter a few generations,
| informal standards developed in IDE functionality so it was
| easier to switch. But still by far the most powerful tool I know
| that I only had to learn once is the Unix pipeline.
| agumonkey wrote:
| one trauma from eclipse days, is that for instance, libs thus
| classpath management was left to eclipse devs .. and I had no
| idea what was going on, why it worked, what differences between
| the options ..
|
| when I could write a makefile to finally jar / launch a java app
| on my own, I felt such a relief..
| the_third_wave wrote:
| I think the benefits of working with KISS tools - the opposite of
| 'everything but the kitchen sink' in Emacs parlance - is that it
| significantly lowers the cognitive load. This may sound odd when
| comparing a rather bare-bones vi + tools setup with a bells-and-
| whistles IDE like Visual/Android/whatever Studio but it just ends
| up working that way for me. I already need to keep enough state
| in my head for the project I'm working on so I'd rather not have
| to worry over the state of whatever tools I'm using.
|
| As an aside, I feel the same about the unbridled growth of
| tooling around certain languages (Javascript being a prime
| example) and environments (Android comes to mind). Maybe it is
| just because of the way I started out with 8-bit assembly where a
| macro assembler was a luxury which could not entirely be trusted
| to do the right thing but I know I'm not the only one.
| eirki wrote:
| Absolutely agree. The myriad of overlapping tools were the
| biggest problem for me when learning javascript.
| willjp wrote:
| Agreed, I like (trying) to understand as much as I can about
| how my environment works so if/when something breaks I only
| need to learn the last 30% in a crisis, and I'm already
| familiar with the core. It doesn't always work, sometimes there
| is just too much.
|
| It's usually useful, at least in some abstract way to the team.
| It felt essential when I worked alone and was accountable for
| everything.
| bitwize wrote:
| > I think the benefits of working with KISS tools - the
| opposite of 'everything but the kitchen sink' in Emacs parlance
| - is that it significantly lowers the cognitive load.
|
| No. You're wrong. Not having the right tools raises the
| cognitive load. You just think it's simpler because you are
| severely restricted in the complexity of the programs you can
| create with just your brain and the documentation.
|
| IDEs expand the complexity of what you can build and make you
| more productive building programs of any size, because features
| like autocomplete and refactoring take thr cognitive burden off
| you.
| the_third_wave wrote:
| You forgot to add " _for me ..._ ". You also implicitly
| defined IDEs as " _the right tools_ ". After that you imply
| that those who do not use " _the right tools_ " (in your
| definition of "right") are " _severely restricted in the
| complexity of the programs [they] can create_ ".
|
| In other words, you state that _your way_ is the _right way_
| while _my way_ is _wrong_.
|
| Notice I did not state that my way is the right way for
| everyone? What makes you think yours is?
| bitwize wrote:
| It's one of those "the mouse is objectively faster than the
| keyboard, no matter how much it _feels_ otherwise " things.
| So much of the taxing minutiae of programming is automated
| away by a good IDE that, unless you're working on a very
| small project, the time and effort saved is worth it.
| the_third_wave wrote:
| That argument can easily be turned around by adding a
| short phrase:
|
| _As long as you 're working on a fairly standard type of
| project_ much of the taxing minutiae of programming is
| automated away by a good IDE that, unless you're working
| on a very small project, the time and effort saved is
| worth it.
|
| In other words, that IDE which may assist you while
| you're building yet another CRUD project gets in the way
| when you're, say, developing a driver for a sensor on an
| IP camera based on a reverse-engineered example.
| mst wrote:
| I feel like this is reductive and a better way of looking at
| the question is that for any given situation you have to
| figure out _where_ to most effectively allocate your
| available cognitive load budget.
|
| Sometimes, all the things the IDE lets you not think about is
| hugely more helpful than the additional cognitive load of
| modeling what the IDE itself is doing in your head.
|
| Sometimes, having the thinnest possible layer between you and
| what you're running is hugely more helpful than the
| additional cognitive load of handling the things the IDE
| would've turn for you in wetware.
|
| As ever, it's trade-offs all the way down.
| atribecalledqst wrote:
| > The Antipattern of the directory layout of your typical Java
| Enterprise Project is a Testament to this.
| (src/main/java/org/company/product/...)
|
| My eye twitched when I read this. My company recently switched to
| a new build system and for whatever reason this required (I
| guess??) a change to the src/main/java... structure. The commit
| history going back over a decade, gone. It's not great.
| oneplane wrote:
| None of this matters in the slightest as soon as you have to work
| with other people on stuff. At that point common tooling is more
| important than specific personalised tooling.
|
| If everyone is using IntelliJ and you're using Atom, it's going
| to be problematic. Not because of either of those tools, but
| because you now have a discrepancy that is not relevant to the
| work you're doing yet it's creating problems for the work you're
| doing. Adding friction like that doesn't help anyone.
|
| "Works on my machine" doesn't just apply to the artifacts you
| build, it also applies to the way you work on your project.
|
| Of course there is some difference between multiple people
| editing random plain text in a random editor and multiple people
| building a piece of software with a toolchain, deployment
| strategy, tests etc. If everyone in your team can scaffold the
| tests in 1 second because that's what the IDE does, and you're
| the only one that has to burn half a day on manually stubbing out
| the same scaffolding, you're the problem.
| dolni wrote:
| Enforcing an IDE across a team for consistency is a real stinky
| smell.
|
| You don't have CI/CD? You sure as hell aren't going to run an
| IDE in CircleCI or Jenkins to do your builds.
| oneplane wrote:
| This has nothing to do with CI/CD or forcing anything on
| anyone. It has to do with being similar enough in a team to
| be able to work together. Being unique or different to a
| degree that it is hurting your (and by extension your team's)
| performance is bad.
| [deleted]
| Lio wrote:
| I don't quite get this as an argument for forcing a prescribed
| IDE on team members.
|
| You mention scaffolding tests, things like this can be left to
| external tools and then it works for all IDEs and all editors.
|
| Then you can let people use what they find most ergonomic.
| zo1 wrote:
| Not OP. But having to sit for an hour watching some Vscode
| dev struggling to run tests or get auto complete on some
| random function is a waste of time. They spend more time
| faffing about fixing and fiddling with that than it would
| take to install a proper IDE and load up the same project and
| have it 100% work.
|
| Like I get it, some people know their language inside and out
| and can fix it in a second because they know all the pitfalls
| and inner workings of the tool chain. But 99.5% of them
| don't, yet when they fix it they act like code ninja messiahs
| because they configured some random json config file after
| googling it and it worked. That's all I see Vscode users
| doing.
| Lio wrote:
| Against though that sound like more of the same argument.
| If you set up external tooling to run the tests you can
| just tell them to use that with nothing to set up.
|
| Either way whatever tool you use, nothing can be worse than
| pairing with someone who copies and pastes with a mouse.
|
| I can just feel my life ebbing away as my inner voice
| screams "LEARN THE SHORTCUTS" and they slowly move 3
| characters across the screen, make a mistake and try again.
| :P
| oneplane wrote:
| I mentioned that because in 2005 that was a real PITA and the
| first example that came to me. It's not a 'real' problem in
| Greenfield problems today. It also isn't really the point,
| but just an example for people who don't get the point (and
| apparently not a good one at that).
|
| The point was: if you make it difficult to work together
| because you have a high horse / hill to die on / unique
| incompatibility, it makes teamwork unreasonably hard and
| inefficient, which becomes a problem as soon as time and/or
| money is involved. The "haha I am so much better because I
| don't use an IDE" line of thought falls within that category.
| So does "I run TempleOS so that my code is blessed" and "I
| don't like git so I use TFS and you can all suck it".
|
| Now, say you have something much easier to not care about
| tools; i.e. a gitops driven workflow for your terraform code.
| Then it doesn't really matter what you have locally because
| until your code is merged it is in no way/shape/form going to
| create a problem. On the other hand, if you refused to use
| efficient tooling your performance might be half of what
| other people might present and that means the people that pay
| you don't get a good value from your work. Efficient tooling
| might mean: something that understands the syntax or AST of
| what you write and points out errors so you don't find out
| after the fact.
| chmod775 wrote:
| When people say "no IDE" what they usually mean is the concept of
| an IDE turned on its head.
|
| Your command line with vim/emacs and other tools that together
| arrive at the same feature set as a _Integrated_ Development
| Environment are still... a development environment.
|
| Not using an IDE doesn't mean you can't have autocomplete, syntax
| checking, linting, automated rebuilds, and all that other good
| stuff. It's just not all in one package.
|
| And yes you shouldn't force your choice of (integrated)
| development environment on others. Different people have
| different needs: News at 11.
| npapag7 wrote:
| You must know how to work without an ide. Then you can learn on
| top an ide.
| [deleted]
| S_A_P wrote:
| Sometimes people need to prove that they are a rare breed of pure
| developer. Their superior discipline and tastemaking in the
| development toolchain far surpasses the masses of regular
| developers who are dependent on old slow crutches to get any
| meaningful work done.
|
| Meanwhile there are real 10x developers out there that while they
| care about the tools stay out of the weeds of them.
|
| This line of blog post reminds me of a Paul McCartney interview I
| read where someone asked him what kind of strings he uses on his
| guitar. Paul replied "shiny ones". I think Paul is actually a lot
| more technical than he lets on in interviews and probably knew
| full well what kind they were. What he communicated to the person
| asking the question was that it doesn't matter so much.
| beebeepka wrote:
| Real men don't need IDEs, nor filthy GUI tools for kids. Shit
| was the defacto culture at the two Linux only shops I've worked
| at
| ausbah wrote:
| real men use punchcards write bug free code from the get go
| beebeepka wrote:
| I've had some 20 year olds with such attitude.
|
| Me: you realise always doing things the hard way does not
| improve your output, right?
|
| Young jedi: nah, it's fine. GUI only slows me down, also
| Perl is the best
|
| Me: alright then
| neonbones wrote:
| Well, this is my friends and me in my early 20s. The only
| true way is to use vim/emacs, CLI tools for everything.
| GUI is for losers. And the only TRUE and SERIOUS
| languages for COOL KIDS are C++, Haskell, and Perl. If
| you don't use them, you are code monkey.
|
| And here I am, doing everything in typescript for my job,
| use VSCode and Webstorm, in love with GitKraken. What a
| shame. I'm not a cool kid anymore.
| slifin wrote:
| There's no rule that says you can't use multiple editors
|
| I'm happy taking advantage of the strengths of many editors for
| many different situations
| shreddit wrote:
| I think that's why VSCode is so popular. It's a very powerful
| text editor, not a light version of an IDE.
|
| On the other side, I'd never use vsc to edit a normal text
| file...
| simonw wrote:
| I've spent my entire career avoiding IDEs, and now VS Code has
| finally sucked me into what I'm increasingly suspicious is an
| IDE cunningly disguised as a text editor.
|
| I use it to edit random text files full of notes too, because I
| trust it to bring back my unsaved work if my laptop crashes.
| bootlooped wrote:
| Everybody I know that uses VIM and VS Code uses them with a
| bunch of plugins to make them more IDE-like. The result will
| still probably be more performant than a true IDE, but the
| downside is there is additional setup time and brittleness. The
| JetBrains IDEs, at least the ones I've used, just work.
| adamnemecek wrote:
| I don't get why these articles get written. They are so
| predictable and just...overdone. What's next "the unreasonable
| effectiveness of the vim text editor"? You are literally verbatim
| repeating the a thing that has been written one million times.
| OJFord wrote:
| > You are literally verbatim repeating the a thing that has
| been written one million times.
|
| I highly doubt that.
| Kaze404 wrote:
| Couldn't the same be said about your comment?
| Rd6n6 wrote:
| A good ide is all about auto completion and refactoring tools.
| The autocompletion means you don't have to spend as much time
| memorizing apis, so you can focus more on simplifying your design
| and minimizing coupling. In something like unreal engine, the
| intellisense really sets ides apart. The refactoring means you
| can quickly and easily make large changes to make the code easier
| to work in. You can just work significantly faster if you have
| both of these things.
|
| I don't really use other ide features. Separate terminals are
| great
| codewithcheese wrote:
| I'm surprised how many of my colleagues don't use the debugging
| features of their IDE. Being able to step through code line by
| line and see all the variables states at any time and evaluate
| arbitrary expressions given those states seems far superior to
| print/console based guesstimation. However, somehow my
| colleagues still do great work!
| mst wrote:
| So far as I can tell from having worked with lots of people
| with lots of different preferences, there is basically no
| correlation between preferences in debugging approaches and
| ability/productivity.
|
| I do however really wish the world made it easier to help
| turn both state introspection via interactive debugger and
| state introspection via printf shotgun into structured trace-
| level logging that could be shared and/or committed to the
| codebase independent of the original debugging tool used.
| nicoburns wrote:
| Depending on which ecosystem you're working with you may be
| able to get those tools elsewhere. If you're working with
| client-side JavaScript for example, then you have multiple
| choices of browsers with excellent debuggers built in.
| dntrkv wrote:
| That's still not the same as debugging within your IDE.
| Having to switch from the browser back to your IDE to find
| the files to make changes is just another context switch
| that slows you down. Plus, dealing with async loaded files
| can be a pain in the browser.
| Macha wrote:
| I've tried using VSCode's debugger for Javascript before.
| And it can be kind of nice, but ultimately on larger
| projects with their own build tools it can be hard to
| keep the sourcemaps working in such a way as to not screw
| up VSCode's debugger, and the gain over Firefox's built
| in debugger wasn't worth the effort for me to continue to
| maintain that config.
| nicoburns wrote:
| You can actually configure chrome to be able to edit your
| local files and save changes directly. Although
| admittedly it was a bit unreliable when I tried it.
| newbamboo wrote:
| Ah but who will debug the debuggers.
| est31 wrote:
| I prefer printf debugging. a) it works everywhere, even say
| when the bug is only reproducible in a remote CI, or in
| languages that don't have good IDE support. My printf skills
| are top notch thanks to using it everywhere. b) the printf
| stuff can stay around until the next compile. I can easily
| vary it, put it into VCS, share it with others, etc. For IDEs
| such features may exist, but again I'm locked into an IDE.
|
| Sure, in some settings the source code is not available and
| you still want to debug. Then I use debuggers. But outside of
| that I prefer printf debugging.
|
| Note that I'm not saying that people who prefer debuggers are
| wrong. They probably have their reasons, as I have. Everyone
| should be allowed to use the method they prefer the most.
| nooorofe wrote:
| Concurrent code is not easy to debug line by line. Logging is
| a good alternative.
| AlisdairO wrote:
| For large codebases, the code exploration features are
| priceless. Call hierarchy is an absurd productivity booster.
| dntrkv wrote:
| Using this right now to break apart a 5k line file. Being
| able to see the call hierarchy of all the functions allows me
| to move over functions with less dependencies and slowly work
| towards the ones that are heavily intertwined. I can see it
| all at a glance without having to jump from one function to
| another over and over.
| 6gvONxR4sf7o wrote:
| Error detection is a big one too. My code in an interpreted
| language wouldn't error until this corner case hit, but my IDE
| tells me the issue as soon as I write it. It's a huge boost.
| mankyd wrote:
| Refactoring is where it's at for me. The ability to rename
| functions and variables across not just a local file, but all
| references in the code base is huge.
|
| Relatedly, the ability to find all usages of a symbol and
| navigate between them is indispensable for me at this point.
| lacksconfidence wrote:
| > Relatedly, the ability to find all usages of a symbol and
| navigate between them is indispensable for me at this point.
|
| I don't know if people just aren't aware, but vi and emacs
| have been doing this since at least the 90s. This isn't some
| fancy feature that requires an IDE. Recently the support has
| improved even more through LSP.
| h4x0r12345 wrote:
| > I don't know if people just aren't aware, but vi and
| emacs have been doing this since at least the 90s. This
| isn't some fancy feature that requires an IDE. Recently the
| support has improved even more through LSP.
|
| We know about them. When you start adding these scripts to
| vi and Emacs they're no longer in the realm of plain text
| editors. You can add a bunch of hacks to turn vi or Emacs
| into a poor mans IDE.
| jcelerier wrote:
| > I don't know if people just aren't aware, but vi and
| emacs have been doing this since at least the 90s. This
| isn't some fancy feature that requires an IDE. Recently the
| support has improved even more through LSP.
|
| No, rtags & friends aren't remotely comparable to an IDE
| which has a semantic understanding of the code, and will
| catch the uses without false positives.
| lacksconfidence wrote:
| I mean, I think they are? Sure jumping to a generic
| definition like getId will give you more choices, but i
| know which one i want. Having to push space and then 9 to
| get the second page and choose the one i want isn't the
| end of the world.
|
| Recently LSP provides exactly what you desire anyways
| with context sensitive jumps.
|
| Edit: Regardless, perhaps our difference here lies around
| what the minimum specification is. My reading of this
| thread and the post i responded to is that people think
| moving around in code without an IDE means closing one
| file, navigating to the next file and opening that one.
| This is patently not how it works, and what i was
| adressing.
| OJFord wrote:
| LSP gives you exactly the same functionality though,
| since it's what VS Code is also using.
|
| Whether the implementation is prone to false positives
| (it really shouldn't be) is up the server, not the client
| (e.g. vim or VS Code). The client actually _doesn 't_
| have 'a semantic understanding of the code' - that's the
| point of it, not needing every editor to implement an
| understanding of every language it wants to support.
| newbie2020 wrote:
| This is my favorite IDE feature! I don't know how text editor
| folk do this
| OJFord wrote:
| Plenty of LSP clients to choose from for vim.
| k__ wrote:
| I used Webstorm for years, but switched to VSCode.
|
| It's just more flexible, which allows me to use new tech/langs
| very quickly.
|
| If you don't focus on IDE features, you tend to implement quality
| of life improvements at a level that also works in an editor.
| Like in the language, framework, or library you're using (See the
| code generators point in the article).
|
| With languages like Rust, that have zero cost abstractions, you
| don't even run into performance problems when doing so.
| [deleted]
| avisser wrote:
| > I used Webstorm for years, but switched to VSCode. > It's
| just more flexible, which allows me to use new tech/langs very
| quickly.
|
| I'm sure you know, but Webstorm is limited by license/design.
| JetBrains sells editors to deal with almost every tech. I
| personally subscribe to the Toolbox for ~$200/yr and get all
| the IDEs. Some languages (like Rust) don't have a custom IDE,
| just a plugin into IntelliJ, the ur IDE from them.
| blumomo wrote:
| I started with Q-Basic about 30 years ago, which came with an IDE
| which was as powerful as Textedit or Nano. No auto-completion, no
| refactoring, nothing. Then came Delphi, MS Visual Studio, Visual
| Basic, Eclipse, IntelliJ/AppCode/Android Studio, Xcode, Visual
| Studio Code - all in that order.
|
| I came to realize that the more the IDE did for me the worse I
| became as a programmer!
|
| Today I'm back to plain text editing with a powerful text
| manipulation tool - (Neo)Vim.
|
| And I program like back in the 90s -- I have all file names,
| methods, the complete code structure of _all_ products and
| services of our company on my mind. I can see the final solution
| in my mind before I start typing a single letter. Refactoring is
| done with regex, it works the same in all programming languages.
| I work full stack. And I'm really fast. And I'm not tired by
| having all code and APIs in my mind. Because programming is pure
| joy again for me. Pure text editing is what makes me fast and
| having tons of fun. I ship so fast and things very rarely break.
| Bugs are fixed within minutes because I see the root causes
| flashing up in my mind.
|
| To me IDEs are for intermediate programmers. It's a good thing to
| temporarily improve your skills but I don't see them as a means
| to achieve mastery, at least not for the mastery that I could
| achieve.
| throw3849 wrote:
| I feel most of those points are obsolete with Idea. It takes
| seconds to start and so on.
|
| Only benefit I see is remote development over terminal.
| bootlooped wrote:
| The JetBrains IDE family is half way there. You can run your
| code on remote targets now, but I think the code itself still
| has to actually be on your machine.
|
| https://blog.jetbrains.com/idea/2021/01/run-targets-run-and-...
| ch_sm wrote:
| The obligatory XKCD: https://xkcd.com/378/
| nerdbaggy wrote:
| He bashes VS Code at the end but that seems exactly what he
| wants. VS Code is more of a text editor then an IDE, and you can
| turn off all the "issues" he complains about.
| sxldier wrote:
| He's referring to Visual Studio.
|
| https://visualstudio.microsoft.com/
| ThePadawan wrote:
| Man, I've been going back to full-fat VS after working in VS
| Code for a while, and boy, does VS just _chug_ even opening a
| "Hello World" C# project.
|
| (I used VS at work regularly and the performance on a
| million-SLoC solution was _quite_ bad, but I didn 't expect
| it to be much better given the size of the solution)
| GiorgioG wrote:
| Have you tried VS 2022 (beta)? It's 64-bit finally. It's
| way faster in my experience, but I don't have a million-
| SLoC solution laying around to test.
| ThePadawan wrote:
| Not yet! Might give it a try, thanks for the idea!
| nerdbaggy wrote:
| I find Visual Studio auto complete 100x better then VS Code
| auto complete.
| scoopdewoop wrote:
| For what language? Because I use VSCode for C (microsoft's
| C/C++ plugin with intellisense) and Typescript (built-in)
| and it works pretty dang great.
| Shorel wrote:
| Now add a linter for your comments.
|
| https://languagetool.org/
|
| (it is 'than', not 'then')
| [deleted]
| IlliOnato wrote:
| The author seems to use IDE for one purpose only: to auto-
| generate boilerplate code. But this is far from the only benefits
| of IDEs!
|
| I rarely use IDEs for code generation, I don't even like
| autocomplete. For this stuff I use code snippets; I develop
| collections of those for any language I use. You don't need an
| IDE for it; any good text editor has such features.
|
| For me really important features of a good IDE are:
|
| - Navigation. Being able to right-click on a function or method
| name and jump to its definition is very handy. Yeah, I may
| remember where it's defined; I can also use grep (which does not
| work all that well for methods). But jumping is so much faster
| and does not take you out of the flow.
|
| - Code refactoring. I am refactoring code continuously as I work
| with it. Even simple stuff like renaming a variable or a function
| (or a method!) is much easier with an IDE.
|
| - Error highlighting.
|
| Note: I can and sometimes do work without an IDE (esp with more
| obscure languages which don't have good IDE support). There is
| some fun it it too, like going camping and living for a while
| without creature comforts like running water and electricity. But
| normally, if a tool is available, why not use it?
|
| About languages: I agree that a well-designed language allows you
| to factor away most boilerplate code. (This was one thing I
| really liked about Perl! It basically allows you to develop a
| language dialect for your particular needs. The downside with
| Perl was that everybody was "reducing boilerplate" in their own
| way, but this is another story)
|
| Just my 2 cents :-)
| jcelerier wrote:
| > - Error highlighting.
|
| this so much. it's priceless to just type a line and have some
| warnings such as "hey, you're moving this value but using the
| variable afterwards, take care" or "hey, it looks like you are
| only using this argument as a reference, consider not passing
| it by value" just pop up next to the offending line ; when
| compared to an IDE-less workflow I pretty much divide the
| amount of hitting "build" I need by ten or more since the IDE
| tells me everything wrong beforehand.
| dharmab wrote:
| I get those exact same warnings in Vim :)
| jcelerier wrote:
| Vanilla vim without any extension ? Otherwise you're just
| reimplementing your own IDE by hand in your vim config
| dharmab wrote:
| It's 8 lines of config, more than half of which are
| cosmetic customizations for colorblindness accessibility
| that I'd need with an IDE anyway.
| lawn wrote:
| Obviously extensions.
|
| And it's not "reimplementing" the whole IDE, it's
| choosing and configuring parts to work just the way you
| want it to, and it's usually done in a handful of lines.
| 988747 wrote:
| Any sufficiently advanced vim config would contain ad-hoc,
| poorly specified, bug-ridden implementation of a half of
| Intellij IDEA :)
| javcasas wrote:
| There are languages and environments that are more prone to
| requiring IDEs.
|
| For example, when I write React and I use the Foo component,
| either it is defined on the same file or it is in one of the
| imports.
|
| On the other hand, with Angular, the foo component is not
| imported anywhere. In fact, there is no foo component, just one
| or many Foo components which declare to use the foo tag, and
| one or another may be loaded depending on the context of the
| current component. Good luck getting anything done with such an
| obfuscated environment without tools to deobfuscate it.
|
| And then you have the heavy enterprise frameworks that make a
| science out of obfuscated code, so that you don't know what
| code is being executed, because it is hidden behind several
| layers of inheritance and interfaces, and the instance to
| create is choosen via xml-configurable meta-programming based
| dependency injector. Working with such code is guaranteed
| insanity without heavy IDEs. I would say it's also insanity
| with heavy IDEs, but people tend to find that opinion
| controversial.
| throwawayboise wrote:
| > Good luck getting anything done with such an obfuscated
| environment without tools to deobfuscate it.
|
| There's always the option of not working with such obfuscated
| environments. I know I don't.
| ByteJockey wrote:
| If those are the things you're using to define an ide, then
| vim/emacs/vscode have been ides for a while now.
|
| Seriously, lsps have gotten really good.
| realusername wrote:
| Just about every editor has a language server support nowadays,
| that's far from a compelling argument to use an IDE. Even
| emacs/vim have those now.
| kevindong wrote:
| For Java at least, the language server built into IntelliJ is
| comically further ahead than VS Code + extensions.
| realusername wrote:
| I know I'll make some people not happy by saying this but
| the only reason you need so much complex IDE tooling with
| Java compared to other languages is because the language
| itself & the tools associated to it are not very well
| designed. Just about everything requires some insane
| boilerplate where it should not.
|
| It's not a solution to a problem, it's a problem searching
| for a solution.
| kevindong wrote:
| I don't entirely disagree. But the situation is what it
| is.
|
| The reality is that Java at this point is a mature
| platform broadly supported by many, many stakeholders.
| Its benefits and issues are, in general, decently well
| known and understood.
|
| Billions (likely even trillions) of lines of Java are
| running in production today and those applications will
| need to be maintained moving forward. IDEs make Java
| development a much more pleasant experience and so there
| will be a place for IDEs.
| realusername wrote:
| Yes I do understand why things evolved that way, it does
| make sense, all the tooling is there to improve the
| environment. I just personally don't want to work with
| such tech as much as I can though.
| dharmab wrote:
| I'd like to point out that you don't need an IDE for error
| reporting. Most editors these days integrate with a language
| server for inline errors and linting. Even features such as
| jump-to have existed in Vim/emacs for many years.
|
| I would add graphical debuggers to your list. You can get by
| with command line debuggers and there are external attachable
| debuggers but neither is really comparable to an IDE.
| noidesto wrote:
| Does emacs or vim with lsp count as an IDE?
| gpderetta wrote:
| I would say yes, although they might not be as featureful as
| special purpose IDEs.
| crispyambulance wrote:
| "Not using an IDE" can mean very different things depending on
| how you define "editor".
|
| I would say that an editor that INTEGRATES knowledge of your
| source in some way, like auto-complete, or red-squiggles, is very
| much a big step towards an IDE and should could as "using an
| IDE". Whether it does that using plug-ins/extensions or natively
| doesn't matter. If it has that functionality there's not that
| much more separating it from an IDE.
|
| VSCode, for example, is more like an IDE than an editor
| especially as you add more and more extensions.
| willjp wrote:
| I guess it depends on your definition of an IDE, and where you're
| most comfortable/productive. I see a lot of posts about
| autocomplete, refactoring, linting, tooltips, tests-by-
| cursor/file, snippets. Thanks to a very friendly plugin
| community, you can get all of these in vim, emacs etc. I like
| vim, and it has nothing to do with hubris.
|
| For me it's mostly about:
|
| 1. proximity to the terminal: I find cli tools very useful for
| most of my daily tasks. Using an editor puts the terminal first,
| and my editor second. One-off tasks are a tmux split/tab/session
| away and everything is neatly organized.
|
| 2. consistent interface: Working with a terminal is neat because
| everything is text and it is composable. Working in vim, all
| menus are just buffers - you can navigate them the same way as
| you would your code. Searching, navigation, jumping between
| windows/menus, filtering -- everything stays consistent.
|
| 3. quick n' dirty workflows: If I identify a task-specific
| workflow I want to improve in vim, it is pretty easy to drop in
| functions and/or keybindings to do what I want. The interface was
| built in a way that makes this easy. Writing a plugin for
| visualstudio, or jetbrains etc. requires knowing a lot more about
| the editor you're working in and how it's built. Maybe it just
| feels that way to me.
|
| 4. 0% adjustment when working over SSH: tabs, splits, etc. both
| in my editor and terminal are identical in an SSH session. No
| discomfort. Mostly useful at home.
|
| 5. low distraction: This one's personal. IDEs are intimidating,
| hundreds of buttons, menus, logs prompts all fighting for your
| attention. If I click through a deeply nested menu I often forget
| what I'm doing - especially if there is a fire. Functions and
| Muscle memory works for me. It clearly does not work for
| everyone.
| Macha wrote:
| > Thanks to a very friendly plugin community, you can get all
| of these in vim, emacs etc. I like vim, and it has nothing to
| do with hubris.
|
| > 0% adjustment when working over SSH: tabs, splits, etc. both
| in my editor and terminal are identical in an SSH session. No
| discomfort. Mostly useful at home.
|
| Aren't these two benefits mutually exclusive? If you're got a
| very personalised vim setup, then vim on your workstation is
| going to be potentially dramatically different to vim when
| sshed into a remote machine
| willjp wrote:
| That's a good point! If you have your own user account you
| could dump your .vimrc on there.. but maybe you don't want a
| lot of vim plugins on a server.
|
| Now that vscode has a plugin that uses your local setup to
| edit files over SSH, my argument is a lot less compelling.
| Even at home, I have a lesser vimrc I provision to servers -
| I found it hard to justify installing treesitter, linters,
| etc. on a server where I'm mostly dealing with
| json/yaml/shellscript.
| onion2k wrote:
| Not having an IDE doesn't make me remember things. In my case it
| just means I use a very limited subset of the features, because
| I'm not being reminded of the things I don't remember and I don't
| get to see newer language features unless I happen to read a blog
| post or see something here on HN. I tend to fall back to
| implementing things with primitives and fail to use built-in
| functionality.
| Frost1x wrote:
| For the longest time I was a proponent of limited tooling. In
| many cases its good to know what you're automating or
| simplifying because I often found myself in situations where I
| may have environments I need to do things where I didn't have
| my tooling to lean on.
|
| In the past, this was possible without too much pressure on
| cognitive load. In modern code bases with all sorts of
| libraries and layers of abstraction ontop of abstraction ontop
| of abstraction ad infinitum, it's just not feasible anymore. I
| got to a point in certain development ecosystems where not
| relying on tooling started to really hinder me. Self reliance
| was no longer a strength and a point occurred where I simply
| had to lean on more and more tooling or I'd be lost.
|
| I still think if you have tooling that does something, you
| should understand what it's doing and how it's doing, at least
| once, then let it do every subsequent need for that task. It's
| good not to have black boxes in your ecosystem. Unfortunately
| even _that_ is becoming difficult because of the number of
| layers of abstraction in some ecosystems ( _especially_ web
| development).
|
| I've never been a fan of black boxes that I simply trust and
| don't know their tradespaces, then hope for the best.
| dolni wrote:
| I think one could make the case that IDEs enable the type of
| complexity you're referring to.
|
| I don't know that I view that as a positive. A lot of
| software development is about managing complexity. IDEs allow
| developers to be sloppier.
|
| In the same way that faster CPUs have resulted in less
| optimized software over the years, IDEs have resulted in more
| complex software.
| luckylion wrote:
| I'm not sure it's about sloppiness, some things are more
| complex than others. I believe IDEs are tools that allow
| one to handle more complexity. They have resulted in more
| complex software, but maybe that's because they've enabled
| us to write more complex software (and more of it).
|
| Like an architect that uses CAD to create plans for a large
| building -- sure, they could do that with a pen on paper as
| well, but it would require a lot more people and a lot more
| time.
| timdaub wrote:
| Hey Alexander,
|
| thanks for your genuine post. I can't help but notice the big red
| disclaimer you put on the beginning.
|
| Once I wrote a blog post about a thing I didn't like about
| Typescript and submitted it to Hacker News [1]. Bad choice. The
| hate was immense and unnecessary. I even had one guy write a long
| post about what a "soy dev" I am. That made me feel sad and
| dislike the HN and dev community.
|
| Anyways, I just wanted to say that I appreciate your blog post
| and that I think you've made some good points. Thanks!
|
| -1: https://timdaub.github.io/2020/09/01/typescript/
| tester756 wrote:
| whenever people are talking about not using an IDE I do wonder
|
| whether they had an opportunity to use Visual Studio's features
| like
|
| expression evaluation during debugging with access to local
| variables,
|
| ability to change code at fly,
|
| ability to execute code in immediate window with access to local
| variables
| Insanity wrote:
| As the author points out, it does depend on the language. I
| switched to vim "full-time" when moving to a Go team. (Prev
| Java).
|
| Java is a language that does not lend itself to vim. Even just
| compiling and running a sufficiently large java program can be a
| pain without an IDE setup.
| approxim8ion wrote:
| Same. I would very much like to use a text editor full-time
| given how strapped for resources my machine is, but I work on
| either Java or Angular 90% of the time. The productivity loss
| is too much to deal with, and the solution is to add a bizarre
| number of plugins to the editor to the point that it becomes
| somewhat of an IDE itself, without the guarantee that the
| plugins will interact well with each other.
| [deleted]
| ibraheemdev wrote:
| Neovim + LSP for C# development worked really great (until I
| ran into a Roslyn bug...). You might consider that an "IDE"
| though.
| mst wrote:
| Editor/IDE is, ahem, a spectrum, not a binary.
|
| Much holy warring ensues from people forgetting this ;)
| wvh wrote:
| If I am the main developer on a three year project, I use
| whatever editor, command-line tools and custom scripts I need to
| get the job done. The whole project, from code to ops,
| architecture, security and documentation, is in my head.
|
| However, if I'm thrown in half-finished projects as consultant,
| the tooling in IDEs can help me to get a grasp on what needs to
| get done without necessarily having to construct the whole map
| inside my head. Whether this approach leads to better code is
| highly dubious, but one doesn't always get to pick outside
| factors.
|
| These are just tools, each with their own purpose, benefits and
| weak points. The main criticisms of IDEs seem based on a certain
| type of developer that does not know the world outside of their
| favourite IDE and programming language, which of course is not a
| problem of the tool itself.
| YuukiRey wrote:
| One of my personal role models, https://github.com/Gabriel439/,
| uses mostly vanilla Vim. Maybe they'd be 10x as productive with
| an IDE, but I doubt it. And in any case, the difference in
| quality and output between them and me is certainly not the
| tools.
|
| I don't think the tooling matters at all, unless you work in a
| very specific field where certain tools may be mandatory.
|
| Whether you look up APIs in documentation or read that same
| documentation in your editor, who cares? Seeing red squiggles as
| you type or in a terminal window that refreshes on change? Who
| cares. It wouldn't even make a difference if you only saw errors
| when manually starting compilation.
|
| None of it really matters in the end.
| mattgreenrocks wrote:
| Maybe I'm weird, but at some point I stopped fixating on which
| tools to use and just settled on a personal workflow:
|
| * terminal open at root of project used for source control
|
| * one or more tabs for ssh/VMs etc
|
| * IDE/VSCode/vim for editing
|
| Any of those is fine. And sometimes I switch between them
| depending on my mood. If I'm out and about it can be nice to
| conserve battery and focus by going full terminal mode. If I have
| AC power and a full screen then I don't mind an IDE as much.
|
| One thing I insist on is doing as much work with git from the
| CLI. IDEs often do things like staging new files automatically
| that I'm not a fan of.
| tcoff91 wrote:
| vim-fugitive is also a great way to interact with git since you
| use vim.
| u801e wrote:
| I use vim's stdin and stdout redirection to interact with git
| and can do things like staging or unstaging files or diff
| hunks and committing from within the editor.
| noidesto wrote:
| magit for the emacs folk
| lanstin wrote:
| Truly one of the best new things in emacs in some time.
| Even better than org mode. Tho I still use command line for
| check ins and pushes, old habits.
| Macha wrote:
| > IDE/VSCode/vim for editing
|
| To the point on this one, I sometimes find myself running
| neovim inside the IntelliJ or VSCode terminal, when I need to
| edit a config file quickly while running scripts in that
| terminal, or just to edit a file outside the project directory.
| Or like you, I primarily use the git CLI, because IDEs often
| use to me unintuitive mappings of GUI buttons to git actions
| ("what does Synchronize do for git?"), so then it pops open
| $EDITOR to write my commit message.
| andruby wrote:
| I'm similar.
|
| When I need to create a lot of "new" code, I'll usually use
| nvim. When I need to edit/refactor existing code, I'll more
| often use atom or vscode.
|
| I like both a lot. When bashing out code that is already
| reasonably clear in my head, vim works faster and with less
| "overhead". An ide like vscode works better for me when I need
| a good global search & replace, or something the ide has
| plugins for.
| jillesvangurp wrote:
| The downside is losing access to refactoring, auto-fixes,
| integrated debuggers, auto complete, countless plugins, etc. Some
| of that stuff is nice & helpful. Some of it stops you from doing
| silly things. And some of it automates the detection and fixing
| of problems you would otherwise introduce without realizing. The
| latter is why it's important to use proper tools. Because
| introducing such preventable issues to any code base is just
| really not excusable for a professional software developer.
|
| Of course, tooling is better for some languages than for others.
| But even the ones you think are not that well supported actually
| do have some nice IDEs these days. Worth checking out such tools.
| Of course you can compensate with discipline and use command line
| build tools to tell you what's wrong and then manually look up
| the code location and fix all the issues .... or you could just
| autofix the warning in your IDE and move on to dealing with more
| interesting problems.
|
| As a good friend used to tell me, laziness is a sign of
| intelligence. In IDE terms, if you spend half an hour manually
| fixing something that a tool could have fixed for you in seconds,
| you are being an idiot. Or alternatively, if you can't be
| bothered to understand and use the command line tools available
| to you, do consider using an IDE as it will save you some time
| mastering those tools you clearly can't be bothered with
| mastering. It's the intelligent choice.
| clircle wrote:
| The difference between an IDE and a souped-up vim or emacs
| configuration is ... very little. Your average fancy pants vim
| config has auto-completion, debuggers, etc.
| yoz-y wrote:
| I find that spinning up QtCreator on a new machine is orders of
| magnitude faster than transporting a vim configuration.
| noidesto wrote:
| 1. Optional: do install of neovim 2. git pull dotfiles 3. cd
| dotfiles 4. install.sh 5. Profit $$$
|
| Sure, there's some initial setup time but I'm not seeing how
| its orders of magnitude faster unless your vim config is
| super bloated and/or has a lot of external dependencies.
| yoz-y wrote:
| Yeah. For my vim I need fd, fzf and rg. So my dotfiles repo
| also has an install script. I never had the patience to
| setup lsp correctly. Maybe I'll try again with all lua
| neovim plug-ins and config.
| GlennS wrote:
| I think this is not wrong. When you are using the better
| quality IDEs (for example C# with Visual Studio, or Java with
| IntelliJ), they offer you a lot this isn't there in Emacs or
| VIM.
|
| I currently mostly work in Python using Emacs, because I don't
| know of anything that adds really compelling full-blown IDE
| features for a dynamically typed language.
|
| I will also say that Datagrip and Microsoft SQL Server Studio
| are both way ahead of any Emacs SQL packages I've tried.
| nwatson wrote:
| With JetBrains PyCharm or the PyCharm plugin in IntelliJ, you
| can treat all python3 as statically typed ... use the type-
| annotations and then linter will catch your mistakes.
| ngai_aku wrote:
| You can also do this using emacs with lsp (specifically
| with pyright as the backend)
| noidesto wrote:
| This.
| tasuki wrote:
| Wow these are really weak. And I'm not much of an IDE lover...
| sod wrote:
| > By not using an IDE, you have to remember the syntax
|
| > because there is just so much, that it becomes impractical to
| remember
|
| I got more comfortable and faster with large projects when I
| stopped caring about remembering and switched to search & find.
| I'm always amused seeing someone trying to navigate a directory
| tree of 2000 files.
| matt2000 wrote:
| None of these feel particularly true to me, but in particular
| "less code is more readable" is just so clearly not true. If this
| was the case we'd all still be using Perl.
| klyrs wrote:
| I see some truth to this, under a more reasonable
| interpretation. Clearly, well-golfed k/j/q/apl isn't doing the
| reader any favors. On the other hand, unnecessarily verbose
| code can be just as tortuous as unnecessarily terse code. And
| when you're comparing apples to apples (e.g. same algorithm,
| same data structures), shorter code is somewhat correlated to
| better performance.
|
| In terms of developer productivity, less code faster to write
| and faster to read. To a point. The sweet spot is the shortest
| code that's still easy to read & write.
| mst wrote:
| That's not even true in Perl.
|
| However "less conceptually complex code is often easier to
| reason about' is absolutely true and it takes most people a
| fair amount of practice (and at least if you're me, a lot of
| wondering why your foot suddenly has a hole in it) to properly
| appreciate the difference between "less conceptually complex"
| and "less".
| graycat wrote:
| So, we are talking about tools. First some generalities:
|
| We can expect that considering tools has to be complicated, e.g.,
| apparently the rise of civilization involved the development of
| many tools for many purposes.
|
| Closer to Hacker News, there is a LOT of _data_. The explosion in
| price /performance of computing and digital communications has
| the amount and variety of data growing. So, handling data can be
| a challenge, and picking tools can also be a challenge.
|
| For handling data, there are some tools/data types, e.g., SQL,
| IDEs, Word, TeX, Aspell spelling checker, the old file search
| utility grep, HTML, JPG, comma separated values (CSV),
| spreadsheets, ....
|
| Of course, if concentrate on one source of data for a few narrow
| purposes, then can have some specialized tools that were
| expensive to develop and needed training to learn to use but with
| a lot of usage can be very productive. Maybe a good analogy is
| the factory that produces the cans of beef ravioli that I eat
| sometimes for a fast meal -- no doubt they prepare ravioli by the
| square mile, and I doubt that they use a rolling pin!
|
| Then there are people; they tend to be different: Some of these
| people work in a gold/copper mine, coal mine, on a huge fishing
| trawler that goes from catching the fish to having them frozen in
| retail packages, ..., down to changing the air filter in the
| family car once a year, getting the garage door back on track
| about each two years, cleaning up after the kittens have
| accidents, .... Some of this work uses big, expensive,
| specialized tools, and some uses just simple, old, general
| purpose tools, hammers, pliers, screwdrivers, maybe Vise Grips, a
| 1/4" electric drill, etc.
|
| So, to give some evidence of case n = 1, me, and in computing, I
| use various tools. Examples include Google, Wikipedia, YouTube.
|
| But for what I do on my PC where Google, etc., doesn't help, I
| settled on a broad strategy: As much as I reasonably and
| efficiently can, stay with text, standard ASCII (maybe more
| accurately with some UTF definition) text. Then to manipulate
| this text, use my favorite text editor, KEDIT.
|
| I can _customize_ this editor using its macro language, Kexx, a
| version of the M. Cowlishaw Rexx. Rexx is no toy -- before
| internets or the Internet, IBM had something similar in their
| internal computing, and a lot of it was run by servers written in
| Rexx. Currently I have something over 250 Kexx macros for KEDIT.
|
| So, where I make use of KEDIT directly?
|
| (a) Since some of my most important writing is pure/applied math,
| I've had to get good with D. Knuth's math word processing TeX --
| I've written about 100 macros in TeX. So, I use KEDIT with its
| macros to type in documents in TeX with my TeX macros. Now that
| I'm good with TeX, it is also my favorite word processing for
| letters, business cards, and more.
|
| (b) For remembering URLs, phone numbers, mailing addresses, other
| little items of information, I have a very simple little system
| based on KEDIT and a few, simple macros. All the data is in one
| file of, currently, 3,368,455 bytes. Currently I have 5947 such
| entries starting in September, 2005 and more in other files going
| back some decades. With the 5947 entries and 3,368,455 bytes,
| that is an average of
|
| 3,368,455 / 5947 = 566
|
| bytes per entry.
|
| Since
|
| 5947 / 16 = 371
|
| on average I add an item to this file about once a day.
|
| KEDIT makes it fast and easy to count the number of entries.
|
| (c) In a file I maintain with KEDIT, I keep medical, diet,
| exercise, etc. history. I have some macros I use to extract data
| to read in with Excel and draw graphs.
|
| That Excel will read in data from just simple text files is
| terrific.
|
| (d) Mostly KEDIT is good for editing files one or a few at a
| time, but I use the Windows file system as a _taxonomic
| hierarchy_ for organizing the files. Then I have a little program
| in Rexx that puts the data describing a file system subtree in a
| text file with several columns of fixed widths and use KEDIT to
| sort, search, _select_ that content.
|
| (e) One of my favorite macros is IDC, _insert dated comment_ ,
| e.g., Modified at 13:24:42 on Saturday,
| August 21st, 2021.
|
| So, with IDC I can slap time/date stamps on content and do so
| many times a day. Yes, the little macro reads the file type and
| puts in appropriate comment delimiters.
|
| Just these time/date stamps are a good, fast, single way to
| provide first-cut documentation of work -- that months or years
| later are great to have if don't have anything else.
|
| (f) I wrote a little KEDIT macro _calc_ , abbreviates _calculate_
| to evaluate simple numerical expressions. E.g., at one point in
| my career my manager believed that a disk drive of 100 million
| bytes was _large_ , much larger than necessary. At Amazon I just
| ordered an external hard disk drive with 5 trillion bytes. So,
| using calc, we can find the ratio
|
| (5 * 10*12)/(100 * 10*6) = 50,000
|
| (g) So I write code in Rexx, Kexx, TeX, C (occasionally), and
| Microsoft's .NET. And now that I'm good with KEDIT, I use it to
| write all this code. In .NET, with a little C, for my startup I
| typed in code in 100,000 lines of typing with 24,000 programming
| language statements. So, about 75% of the lines are documentation
| for me to understand the code! Some random exogenous events
| pulled me away from that code, but I will be back to it soon, and
| then the comments will be very welcome, get me back to 100% in
| understanding all the code.
|
| Most of the comments have tree names on my development computer
| of, usually, HTML files of .NET or other documentation, and,
| sure, I have a macro that helps with that. E.g., with one
| keystroke, Firefox will display a file of HTML documentation.
|
| The comments are essentially just text, technical writing, and
| KEDIT with its formatting is good for that. Also my standard
| spell checker, Aspell, works with that text. That is, the code
| is, to KEDIT and Aspell, just text.
|
| (h) Sure, I use KEDIT to write email and often to read email. I
| went for some years using some code I wrote in Rexx for email --
| then email got more complicated and I had to use Outlook or now
| what my ISP provides (I intend to return to Outlook). But when I
| write email, I still use KEDIT. When I receive email that is just
| simple text, I use KEDIT to format ( _flow_ it) and read it.
|
| (i) Sometimes I still want to print some things, e.g., shopping
| lists, envelopes, etc., and use KEDIT for that.
|
| I'm numbering, labeling, my external hard disk drives with
| PASSPORTnnn sequentially with integers nnn, and I print these
| with KEDIT.
|
| (j) Sure, eating is necessary, and I cook my own food. For that,
| I develop recipes and use KEDIT to create those. To take a recipe
| to the kitchen, I can print via KEDIT.
|
| (k) Sometimes URLs have hex characters. So, I have a little KEDIT
| macro to convert those URLs back to just text.
|
| (l) And, sure, I'm using KEDIT for typing this Hacker News post.
|
| So, as in these examples, (a) -- (l), as much as I can I use just
| simple text files maintained with KEDIT. Then I get good with
| KEDIT, macros, _muscle memory_ , etc. and use that skill as much
| as I can.
|
| I can't use KEDIT for everything, so sometimes I use other tools.
|
| Once I tried to use Microsoft's Visual Studio. I didn't like the
| documentation but charged ahead. I created a _project_ , and
| before I had typed in any code I looked and saw a directory
| subtree with maybe, IIRC, 50 files I knew nothing about. I
| stopped right there. Maybe someday I will see need to use an IDE,
| maybe Visual Studio, and will return to it.
|
| All the programming I do is in languages where the code is in
| just simple text files. To me that use of simple text is
| terrific, and I take advantage of it.
|
| So, net, I use KEDIT and simple text files for dozens of
| varieties of work; in principle each variety, done with enough
| volume, could be done with more productivity with a specialized
| tool, but for just my work, where I use KEDIT and text files,
| none of the varieties are worth the investment, overhead, of a
| specialized tool.
|
| By analogy, to me KEDIT is like a Swiss Army knife with 15 tools
| including a can opener. If I opened enough cans, I might want
| some restaurant kitchen $500 counter top electric can opener, but
| for me, now, the Swiss Army Knife is better.
| wyager wrote:
| I write very different code when not using an IDE.
|
| If I'm not using an IDE, my code has to be contextually simpler
| for me to remember it (because I can't just jump to definition)
| which makes my code ultimately better organized. However, I
| assume this comes at some speed penalty, at least in the short
| term.
|
| For personal projects I don't use an IDE, but for work because
| everyone else writes IDE-style code, I also need to use an IDE to
| wrangle it.
| MontyCarloHall wrote:
| > When you have to manually find a file to change a subroutine
| implementation, or to refactor a subroutine, you will have good
| file names and a good directory structure. The Antipattern of the
| directory layout of your typical Java Enterprise Project is a
| Testament to this. (src/main/java/org/company/product/...)
|
| To play devil's advocate, isn't the goal of a good IDE to
| abstract away the actual filesystem organization of the code? As
| long as I can quickly look up function definitions via the IDE, I
| don't care how they're actually organized on disk. As an analogy,
| I'm sure my Gmail inbox is internally stored across multiple
| different databases and would be a nightmare to manually browse
| at the database level, but I don't care because I can easily
| access all my messages through my email client or the web UI.
|
| Disclaimer: I'm not an IDE user myself (simply because I'm
| oldschool, have all the emacs keybindings burned into my muscle
| memory, and I've never taken the time to learn one well), and in
| principle agree with the author's point. IDEs are not (yet) at a
| point where they've rendered the filesystem completely
| irrelevant, although some are getting pretty close.
| scoopdewoop wrote:
| I may be talking out of my ass, as I've never used it, but this
| is my impression of most smalltalk environments, that they just
| expose objects and functions, not files. For example:
| https://pharo.org/features.html under "Software as objects"
| z3t4 wrote:
| Another advantage is better naming, better parameters, as you
| need to remember them. I would say less bugs also as you have
| most of it in your head.
| jbverschoor wrote:
| > By not using an IDE, you have to remember the syntax of the
| language you are using, the subroutines from your own project and
| their arguments. You also remember (standard-)library subroutines
| better for your chose programming language.
|
| Use an IDE, and discover + learn the syntax by being assisted.
| Start biking on a unicycle, and fail.
|
| > When you have to manually find a file to change a subroutine
| implementation, or to refactor a subroutine, you will have good
| file names and a good directory structure. The Antipattern of the
| directory layout of your typical Java Enterprise Project is a
| Testament to this. (src/main/java/org/company/product/...)
|
| There were no IDEs for Java when it started. And it immensely
| structured everything. Not having an IDE doesn't mean anything
| about naming.
|
| > With big projects, it might slow you down to have the IDE load
| the entire project before you can start working. Some Projects
| with 40000+ files might take >5 minutes to load.
|
| But in return you'll get something that will tell you what's
| going on, or even do hot code swaps, saving you a lot more than
| those 5 min.
|
| > This is almost always the result of bad language design and/or
| bad library design. An example is developing android apps in Java
| with Android studio. Here, you will be slowed down a great deal
| in order to program without Android Studio. There will be a steep
| learning curve.
|
| The IDE does more than just edit code. Welcome to different
| resolutions, devices, etc. Please tell me you'd rather have the
| device mess of J2ME // Symbian.
|
| > Good Open Source Projects encourage people to clone, fork, and
| maybe even to contribute to a Project. People are able to
| directly edit files on github, if an IDE is not required and they
| know the language being used. Not requiring an IDE makes it
| easier for blind people, who might be using screenreaders to
| understand your project, and enables people without modern
| hardware (which might be unable/impractical to run an IDE) to
| work on your project.
|
| IDEs have makefiles / build.xml / whatever. You're totally
| uninformed
|
| > Have you ever seen a Java Enterprise Project? Sometimes the
| Java classes in there have 20+ import statements, automatically
| generated by the IDE. Working in this style, with such long
| package names and lots of classes/namespaces eventually almost
| forces you to use an IDE because there is just so much, that it
| becomes impractical to remember.
|
| All Java IDEs support maven or whatever is popular right now.
|
| > Not having Autocomplete / Code Generation guides you naturally
| to writing more compact and idiomatic Code in the Language of
| your Choice. It helps you to learn language-specific features and
| syntactic sugar.
|
| That's a language design issue.
|
| In Java, there is the Concept of Getters, Setters, toString,
| hashCode and so on. These methods can be auto-generated by the
| IDE. In practise, this leads to bloat. The IDE is simply
| compensating for missing language features (built-in hashing of a
| composite data type, built-in string representation ).
|
| That's a language design issue.
|
| What a shit article
| AlisdairO wrote:
| > That's a language design issue.
|
| Agreed. And, also, who cares? Yes, Java is a mediocre language
| and way too verbose. I spend a bunch of time in Java and I
| don't notice the worst of that because I (like literally every
| Java dev I know) use an IDE. You shouldn't separate a language
| from the standard tooling it comes with/enables - they're
| intertwined.
| nwatson wrote:
| Java fields themselves, along with their setters and getters,
| are entry points in which to control via annotations whether
| properties are read-only, write-only, or read/write in multiple
| contexts (e.g. Spring Configuration, JSON de/serialization),
| how they're serialized in JSON (serialized type can be
| different, field name can be adjusted), field ordering, and
| human readability.
|
| Just thinking setters and getters set and get the property is
| naive and retrograde.
| hsaliak wrote:
| I don't use an IDE but I use emacs. Heavily use Helm, heavily use
| its ag integration to navigate around projects and I yasnippet
| useful patterns and rely on them a lot. Am I using an "IDE" - no.
| But am I using tooling to make my life way easier than a raw text
| editor? Absolutely. Will my productivity fall off rapidly without
| this tooling? Most likely.
|
| So I reject the argument made in the article. Just choose your
| IDE wisely and make the tradeoffs you want to be productive.
| blunte wrote:
| Things I would greatly miss without Rubymine IDE:
|
| 1. interactive debugger
|
| 2. quick jump to function/constant implementation
|
| 3. show usages of function/constant under cursor
|
| 4. source control (Git) diffs
|
| 5. database browser
|
| There are probably other things I'm forgetting to mention.
|
| Sure, all of these can either be cobbled together to some degree
| out of the fundamental individual tools. You can add plugins to
| Vim or Emacs to help with many of these. With enough effort you
| can get close to what a polished IDE offers... but you're
| effectively making your own quirky, fragile, non-portable
| inferior IDE.
|
| Yeah, a heavy IDE is slow to start and resource hungry. But
| hardware is cheap, and you only start the IDE once every few days
| (or weeks).
|
| When I'm on a remote server, then I'm in a shell using vim. Fine,
| and doable. But to really build and get things done, saving my
| brain for actual problem solving, I wouldn't want to give up my
| IDE.
|
| Also, some of the cons on OP's list are problems with the
| language being developed in, not the IDE.
| Zababa wrote:
| > simply listing Reasons, The Antipattern of the directory layout
| of your typical Java Enterprise Project is a Testament to this.,
| contribute to a Project, idiomatic Code in the Language of your
| Choice.
|
| What's with the wild capitalization?
| [deleted]
| city41 wrote:
| I consider not needing to remember library and api details a
| benefit. I'd rather dedicate my brain cycles to something else.
| As for syntax, I don't recall ever struggling to remember syntax
| of languages I frequently code in.
|
| Also the point about IDEs auto generating toHashCode, toString,
| etc. If your class needs these methods, whether they were auto
| generated or not seems besides the point. The point the IDE is
| "compensating for lacking language features" doesn't make sense
| to me, the code is compensating, whether a human or IDE writes
| it.
| falcolas wrote:
| Why do doctors memorize medicines and their effects? Because
| it's faster to retrieve from memory than from documentation,
| even automatically presented documentation. It removes a
| context switch.
|
| The "brain cycles" are only run while doing the memorization,
| not while actually doing the work.
|
| > I don't recall ever struggling to remember syntax of
| languages I frequently code in.
|
| Because you've memorized it.
| inglor_cz wrote:
| I'd rather have my doctor consulting recent knowledge base
| than use their 30 year old memories from school. Medicine is
| not set in stone and recommendations change.
| falcolas wrote:
| As I've heard it, use your memory, then back it up with
| documentation if/when you need the certainty.
|
| You can't easily consider a treatment or remedy or library
| function you don't remember.
| loa_in_ wrote:
| The problem with using cache is that you can feel certain
| it's correct but you don't really know until you check
| with the source. And since you check with the source
| anyway, the cache becomes a drag to correctness
| elzbardico wrote:
| You definitely have no idea of how doctors work if you think
| they don't heavily rely on reference books for most of the
| stuff they do
| dfee wrote:
| I don't think you're being generous with your reading of
| their point.
| falcolas wrote:
| You can't easily consider a treatment or remedy or library
| function you don't remember. Better to use all the tools at
| hand (memory being a useful tool - a L2 cache as it were)
| than handicap yourself by only using a few.
| city41 wrote:
| Do they have every single medicine memorized, or just the
| ones they most commonly use? Sure, I tend to remember the
| parts of libraries and apis I use often, but I'd still argue
| my editor having a reminder just a keystroke away is very
| beneficial.
| falcolas wrote:
| More than just the most commonly used...
|
| https://www.youtube.com/watch?v=jR7d56UeeeU <= Song-based
| memorization aide for 200 different medications
| city41 wrote:
| There are over 20,000 approved medications in the US. I
| don't really feel like this analogy is holding up very
| well. But, have I happened to remember about 200 or so
| API and library calls over my career? Probably.
| csomar wrote:
| Reality: They rely on medical representatives to know what
| the actual medicines are. They remember the ones with the
| most kickbacks.
| dntrkv wrote:
| Yeah the idea that I have to remember everything in our
| codebase of millions of LoC made up of TS, JS, Ruby, Kotlin,
| and Java is ridiculous. IDEs allow me to drop into these
| codebases and be decently productive from the get go.
| nooorofe wrote:
| Do you memorize all those IO/XML/JSON/Hadoop
| (HDFS/MR/Core/...)/AWS/Azure/... APIs by heart?
| zenexer wrote:
| The parent explicitly said they do _not_ want to memorize
| APIs.
| nooorofe wrote:
| I understand, I just wonder if he/she really means to it.
| Who knows, some people have very good memory. When I work
| with a new (for me) topic, I am trying to get basic
| understanding of topic, still it far from remembering exact
| method signatures.
| throwawake wrote:
| When you start to work with too many languages frequently,
| using syntax from one while writing another is common and IDEs
| really help at this point. I too prefer not to remember APIs
| and methods, but with time, our brain starts maintaining a
| cache of these. Completions make this faster.
|
| That and error detection are only features I like in IDEs. For
| everything else, dedicated tools are often better (but not
| necessarily easier) than integrated ones.
| zerubeus wrote:
| No thanks I can't live without Intellij Ultimate + ideavim, I
| just can't...
| noidesto wrote:
| I'm on my way back to doom emacs after a year using intellij +
| ideavim.
|
| I get 90% of the features with LSP. Faster performance. Magit.
| Extreme configurability. It's easier to write a quick function
| in elisp and have it at my fingertips at anytime. (ie. M-x
| my/do-repetitive-thing)
| moron4hire wrote:
| Why is it so important for some programmers to convince others of
| working the way they work?
|
| The complaints levied at Java and Android specifically are issues
| I've really only seen in that language and on that platform.
| Excise that and all these arguments feel very flat and empty. It
| has not been my experience at all that using an IDE means I can't
| remember my project layouts, API calls, etc.
|
| And frankly, this wreaks of the same sort of elitist arguments
| that only a small minority of grammarians make against spell-
| check. So what if the tool is a crutch? ALL TOOLS ARE! That's the
| point of tools, to off-load some forms of manual labor. A table
| saw and a fence are going to let me make straight cuts a lot
| quicker and easier than using a hand saw. Humanity grows and life
| moves on and troglodytes complain that the field is being
| "ruined", but what they really mean is they can't keep up.
| noidesto wrote:
| Does emacs/vim using lsp count as an IDE?
| devsatish wrote:
| IDEs are tech equivalent of power tools. You need them. Of course
| you can always chisel down when needed, but tooling helps.
___________________________________________________________________
(page generated 2021-08-21 23:02 UTC)