Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Development Environments

phaazon.net

Post reply on HN
Print view View original

51–60 of 145 posts

Re: Development Environments

#51

Post by samsquire »

namaria wrote: post #17

I understand where the author is coming from and I myself sympathize with the idea of sticking to Unix philosophy of composing small focused tools instead of using complicated tools. That said, I have learned to stick to defaults and start from a clean slate every time. I often say that the main problem in software is containing complexity. When you need to deliver a product that works reliably, you want to remove al…

I completely agree. I find the idea of using someone else's Vim or Emacs config horrifying. They'll do everything differently and not necessarily better.

I memorise how to configure vim how I like it and do it each time. Or how to change tmux bindings to use ctrl-a which I still need to memorise.

Then I'm someone who remembers commands and switches and doesn't need to use recursive search to find commands I type in.

Starting from fresh each time gives you a perspective of what is easier. Reader, can you write a Java application build.gradle, C makefile or Kubernetes YAML without copying and pasting from the web? Can you SSH jump from a bastion host from memory with -W? Can you create the directory structure of a Java project without copying from existing? Or do you write some terrible static configuration generator that doesn't get updates I've seen that so many times on projects. Saving time on the wrong thing rather than just learning the thing to begin with.

I also prefer IntelliJ to Emacs and vim to Emacs. But I use Emacs keybindings in bash. Also I prefer bash to the other shells.

Re: Development Environments

#52

Post by lispm »

pjmlp wrote: post #25
invalidname wrote: post #2

I've been programming since well before we had IDEs... I love them. Proper modern IDEs provide a level of insight and tooling that the anti-IDE crowd just don't get. A couple of decades ago they were problematic. But today's unified toolchains and improvements made them far better. The one semi legitimate problem people have is performance. I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultima…

Same here, heck even James Gosling, the author of XEmacs and many UNIX utilities, says he would rather use an IDE nowadays.

James Gosling is the author of XEmacs?

Re: Development Environments

#53

Post by jrop »

annowiki wrote: post #43
sirsinsalot wrote: post #34

Many people seem to think using a commercial proprietary IDE means you somehow forget how to use the CLI or other editors to get the job done. Like they're junk food that makes you dumb. This is as ridiculous as saying an electrician will forget how to correctly wire because their wire cutters are too good. I used to be a build-my-own IDE person via VIM. After using PyCharm and realising an IDE is more than an editor…

I consider myself quite adept at cli, I can sed, grep, find, vim, and git quite well. However, what I never found convenient in cli was debugging. I was a print debugger for years until my job convinced me to try PyCharm. I've always thought the reason I never found a suitable debugger in cli was just because I was either too dumb to figure out integrating something like vimspector, or too lazy to get used to gdb/pdb…

I use NeoVim for everything except debugging. For that I (frequently) open up VSCode or Chrome to debug (NodeJS). I haven't figured out a good debug workflow for Rust, though, because I hate print debugging.

Re: Development Environments

#54

Post by jrop »

chriswarbo wrote: post #18

I agree that it would be nice to cache a command's output, so we can iterate processes on it. I'm a heavy user of Emacs, which is based around "buffers", so should naturally support such a workflow; yet in the decade I've been using it, such a workflow hasn't really occurred to me. Emacs makes it easy to run commands, e.g. with M-&; the output goes into a buffer called `Async Shell Command`. Unfortunately, that buffe…

This is how I use NeoVim's terminal: run a command, visually select the lines I want to operate on and yank them, then paste them in a new buffer. After that, it's a matter of transforming the text via whatever means one normally does (macros, text objects, search/replace, etc.)

Re: Development Environments

#55

Post by jacobyoder »

a-dub wrote: post #32
invalidname wrote: post #2

I've been programming since well before we had IDEs... I love them. Proper modern IDEs provide a level of insight and tooling that the anti-IDE crowd just don't get. A couple of decades ago they were problematic. But today's unified toolchains and improvements made them far better. The one semi legitimate problem people have is performance. I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultima…

the problem i have with ides is that you never know when some boss or it department will stand in the way of your favorite being available. from open source work at home to the most paranoid of high security environments, vim tends to be there pretty reliably.

i got stuck with 'vi' at a place a few years back because "that's good enough - they're pretty much the same". I don't mean as main development tool, but on server builds, 'vi' was 'good enough' and also "it's smaller - we need to keep this small". So any time anyone had to do anything on those remote servers... years of muscle memory gone because... oh yeah, it's 'vi' not 'vim'. it was jarring to be reminded of how different they are.

Re: Development Environments

#56

Post by jacobyoder »

invalidname wrote: post #48
bandrami wrote: post #46

Earlier quoted context omitted.

There's something to that argument, though. You probably shouldn't use an IDE when you're learning a language. You should at least understand what it's doing behind the scenes and why.

I think that when you're learning you should take the easy route and the IDE reduces some of the frustration we get when dealing with simple errors.

Good IDE will usually highlight style and basic issues as you're typing them, and you can get a better idea of what 'canonical' foo-lang is. I'm not a ruby expert, but using RubyMine I'm reminded of some things while I'm coding, and (some) errors (or just style issues) are spotted before I run.

Re: Development Environments

#57

Post by chriswarbo »

jrop wrote: post #54
chriswarbo wrote: post #18

I agree that it would be nice to cache a command's output, so we can iterate processes on it. I'm a heavy user of Emacs, which is based around "buffers", so should naturally support such a workflow; yet in the decade I've been using it, such a workflow hasn't really occurred to me. Emacs makes it easy to run commands, e.g. with M-&; the output goes into a buffer called `Async Shell Command`. Unfortunately, that buffe…

This is how I use NeoVim's terminal: run a command, visually select the lines I want to operate on and yank them, then paste them in a new buffer. After that, it's a matter of transforming the text via whatever means one normally does (macros, text objects, search/replace, etc.)

Manipulating text within the editor is pretty common; e.g. I use shell-mode in Emacs, which is mostly just a normal text buffer (except Return acts differently when the cursor is over the commandline!); eshell is similar.

What I was describing above is manipulating such buffers with external commands (similar to Emacs `shell-command-on-region`)

Re: Development Environments

#58

Post by pjmlp »

lispm wrote: post #52
pjmlp wrote: post #25

Earlier quoted context omitted.

Same here, heck even James Gosling, the author of XEmacs and many UNIX utilities, says he would rather use an IDE nowadays.

James Gosling is the author of XEmacs?

I got it wrong,

https://en.wikipedia.org/wiki/Gosling_Emacs

XEmacs is the Lucid one, https://www.emacswiki.org/emacs/LucidEmacs

Re: Development Environments

#59

Post by jacobyoder »

a_imho wrote: post #41
tsujp wrote: post #23

Earlier quoted context omitted.

What happens when you now want to work in say.. Crystal, or Shell, or Rust, or Zig, or any other language for which there is not an IDE (even those also by JetBrains) which is 1:1 feature compatible to IntelliJ? Not all JetBrains IDEs have the same features. Rider (for .NET) only recently got remote editing support which IntelliJ already had for instance. Now you're only as good as your tool (IntelliJ) and you cannot…

I have to admit I'm guilty of this, so much so that I'm tending towards discussing programming language features is moot without discussing the available tooling. In fact, I'm starting to think tooling is (slightly) more important.

Tooling and an active ecosystem around a language are generally more important for most projects. Lang-feature-X, on its own, is almost never the reason a project succeeds or fails. An active community fostering discussion about the best ways to address particular problems, with an ecosystem of libraries and examples that show one or more ways to deal with those problems - that is useful. As the language develops, the ecosystem will incorporate those newer features to build on the previous approach.

Re: Development Environments

#60

Post by [deleted] »

pjmlp wrote: post #26
dhzhzjsbevs wrote: post #20

Earlier quoted context omitted.

Yea but you only need all that junk because you use Java. The rest of us just don't have that many files to refactor when we change things. I don't really hate ide's, I get the appeal, and sometimes it works out useful. It's just that most of the time it comes back to enterprisey software being the source of your problems, not the lack of features in your editor.

Good IDEs precede Java, e.g. Borland products for Turbo Pascal and C++, Common Lisp and Smalltalk environments. The anti-IDE crowd seems to like to pick on Java.

[deleted]
Post reply on HN