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

101–110 of 145 posts

Re: Development Environments

#101

Post by invalidname »

eikenberry wrote: post #79
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…

IMO this has 2 issues. #1 If you need an IDE to handle simple things like you list I think the language's development model is designed with IDEs in mind (eg. Java). Better language support and tooling makes all these things trivial without an IDE. #2 There are no good Free Software IDEs and I will not make ethical compromises with my maker tooling.

Java didn't have a decent IDE for the first 10 years of its existence and I hated IntelliJ/NetBeans etc. when I first used them. The tools improved. They work great for all the languages I use.

I'm not smart enough to keep an entire code base of every project I ever worked on in my head. Maybe you're a genius of a different level, even then... Wouldn't it make sense to clear the area of your brain that needs to remember every parameter name to a method call so the IDE will show that to you.

IntelliJ community is free and open source. NetBeans too and it's decent. So is Eclipse. VSCode isn't exactly an IDE so I won't go into that.

Re: Development Environments

#102

Post by bitwize »

invalidname wrote: post #47
eadmund wrote: post #44

Earlier quoted context omitted.

> Modern IDEs really improved since then and I haven't seen a feature that emacs can do that they can't. Easy extensibility. Read email. Run a calculator. Run Lisp … Meanwhile, there is literally no feature any IDE has which Emacs cannot do. It's just a simple matter of programming.

Everything is "just programming" but deep semantic heuristics from an IDE can't be done reasonably in Emacs. Most of the big features require keeping a full AST model of the project in RAM. That would make emacs/vi really slow. IDEs are 100% extensible via plugins. Wrote a few of those myself.

Extensibility via plugins is quite a bit different from extending the editor as you use it. Emacs admits the latter, and useful functionality can be added in a page or less of Emacs Lisp.

I tried writing a plugin for Visual Studio Code. It made me want to throw furniture.

Re: Development Environments

#103

Post by invalidname »

Narishma wrote: post #85
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…

> I run on an M1 Max with 64gb of RAM and gave a lot of RAM to IntelliJ (Ultimate). It flies. As professionals we need to spend on our tools and on our hardware to get the most out of both. The problem with that is you'll more than likely create applications that work fine on your fancy high-end systems but end up unusably slow on normal people's hardware.

That's why we have software testers. Most of the stuff I build nowadays is server backend stuff and mobile. For server backend this runs on strong machines. No problem.

For mobile I use a device.

For desktop stuff we have a minimum machine which we test. Also IDE's have profilers integrated where you can see if you take up too much RAM or CPU. There's no need to suffer slow performance to create apps that run in constrained resources. You can have more than one computer too. Even as a one person shop.

Re: Development Environments

#104

Post by invalidname »

ungamedplayer wrote: post #89
invalidname wrote: post #29

Earlier quoted context omitted.

I can use text editors and other IDEs just fine. An IDE gives me more power and for 99% of my work I can live within it. I'm just slower. I used Visual Studio when working with C# which is fine. Not as great. Didn't get a chance to do either Zig or Rust in practice (both look great and I would want to go there). This argument is like arguing against shoes because of "what will you do when you're barefoot".

I think its more like "what will you do when you need need hiking boots and you've got snow shoes and no budget"

If I have no budget then I'm probably not a professional. Would you expect a contractor to build your house with just a hammer just because he ran out of cash buying the materials?

I accept that some people live in poorer countries. I work with a lot of them and spend a great deal of time abroad. Even they have more powerful machines than the median and they get great discounts for those machines. Maybe not a machine as powerful as this but somethings that can still make the IDE fly.

Re: Development Environments

#105

Post by invalidname »

bitwize wrote: post #99
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…

If you need an IDE to manage the complexity in large, complex software projects, then you need an IDE for the kernel -- one of the largest, most complex single software projects around. IDEs are written for this purpose -- modern CodeWarrior, for one. The fact that many kernel devs including Linus himself get along fine without one suggests that IDEs are not the universal good you seem to think they are. In particula…

I accept that I'm not nearly as smart as Linus. Also most Kernel developers know their own relatively narrow module not the entire project.

Again, I programmed without an IDE (in Java too) and manage that completely fine. Just like I can walk barefoot without shoes. Same thing. It's a power tool that provides amazing capabilities.

I go out of the IDE a lot too. I prefer using the native terminal rather than the one builtin the IDE (although some use that and that's fine) we each have our habits.

CTO of my current company is a VIM nut. Uses it a lot. And an IDE. He uses each in the context he sees fit to his needs. I used to see a lot of people at my later days in Oracle (after the Sun acquisition) switching between Emacs and an IDE back and forth. Sometimes even on the same project. Each tool has its own power.

It isn't a zero sum game between the two. I use external editors too for the right things.

Re: Development Environments

#106

Post by meatmanek »

chriswarbo wrote: post #19
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…

> write a Dockerfile I was sort-of agreeing with you until this point. In my experience "write a Dockerfile" usually means "run a bunch of fragile, non-deterministic nonsense, like `apt-get update && apt-get -y install`, `yum install`, `pip install`, `npm install`, etc.; often all at the same time!" (AWS are a serial offender IMHO, e.g. their documentation recommends this sort of crap https://docs.aws.amazon.com/lamb…

Docker is a way of taking fragile, non-deterministic things like package installations, and make them less fragile, in very practically-useful ways.

Compared to the old way of doing these things (which would likely be a shell script that would run those exact same apt-get/pip/yum/npm install commands), Dockerfiles give you:

  - a much more predictable starting state, which lets you remove a bunch of complexity from your installation script. The old style of installation script might need to detect which OS it's running on, which version of Python is installed, whether you're using GCC or clang, whether libgomp or lzma or whatever is installed, whether or not the script is running as root, whether or not there are existing sites configured in the local nginx install. With a Dockerfile built on a slow-moving image, you can know exactly where everything is, what version is installed, and whether there are any other conflicting applications.
  - limiting side effects (As a user, you can be fairly sure that a `docker build` isn't going to clobber your nginx configs.)
Containers have a whole pile of downsides, but making builds _more_ fragile is not really one of them.

Re: Development Environments

#107

Post by invalidname »

bitwize wrote: post #102
invalidname wrote: post #47

Earlier quoted context omitted.

Everything is "just programming" but deep semantic heuristics from an IDE can't be done reasonably in Emacs. Most of the big features require keeping a full AST model of the project in RAM. That would make emacs/vi really slow. IDEs are 100% extensible via plugins. Wrote a few of those myself.

Extensibility via plugins is quite a bit different from extending the editor as you use it. Emacs admits the latter, and useful functionality can be added in a page or less of Emacs Lisp. I tried writing a plugin for Visual Studio Code. It made me want to throw furniture.

That is true. IDE plugins are a nightmare to write and VSCode is by far the worst to write. Still, JetBrains is remarkably extensible and mature, I was able to integrate things very deeply in the editor. The downside is writing in Swing which is pretty long in the tooth by now.

Re: Development Environments

#108

Post by Hello71 »

anonymoushn wrote: post #73
invalidname wrote: post #69

Earlier quoted context omitted.

I worked on the mess of make file and C dependencies created on Emacs in Sun Microsystems back in the day. You can make a mess with any tooling. It was impossible to navigate and I spent most of my time constructing complex regexes for grep just to follow the flow. In an IDE I can right click an element to find usages/dependencies, etc. Some of them are just highlighted.

As a point in support of this comment, I recently perused the xxhash sources looking for the actual implementation of the hash functions, but it's difficult because there are like 20kloc of mostly preprocessor macros. This probably was not created using an IDE, and if it was, the IDE is not the cause of these issues...

i was able to find the xxhash core within 5 minutes, with no particular experience in xxhash or hashing algorithms.

1. google xxhash, click first result (github)

2. open xxhash.c

3. see it is mostly empty, go back and open xxhash.h. this file is 6k lines (not 20k), it probably has most or all of the implementation somewhere.

4. starting from top of file, read intro docs: "xxHash [...] is proposed in four flavors, in three families: 1. @ref XXH32_family: Classic 32-bit hash function." i will select XXH32 for illustration.

5. scroll down to examples, which calls "return XXH32(string, length, seed);"

6. ctrl-f "XXH32(", could be done in any text editor (even notepad)

7. press enter 6 times

8. see "@brief The implementation for @ref XXH32().", we have probably arrived at the core or reasonably close to it. if that didn't work, then I would try "XXH32 (", which would immediately find the XXH32 function.

of the 6k lines, about 550 are empty, about 2800 are comments, and about 800 are preprocessor directives. the comments appear to be mostly useful comments, not the "/* Frobnicate the bar. */ int Bar::frobnicate()" type which tend to be seen in IDE-overuse projects.

Re: Development Environments

#109

Post by UglyToad »

soggybutter wrote: post #64
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.

100% agree with this. I've seen plenty of devs who type a couple dozen characters in a session and spend the rest of their time clicking around on IDE prompts. This isn't necessarily a bad thing, but I've seen newer devs become completely crippled if their IDE misbehaves. And it's not uncommon for them to have very little understanding of the project structure because their IDE abstracts most of it away. It also prom…

No one has yelled at you yet so let me be the first to represent for the can't type contingent.

Why would I want to type? It's entirely the wrong model for interacting with code. I think a lot of languages are held back by this idea that the best way of using them is typing out every character.

To give an example of what I mean, 'toDring()' is meaningless, it's garbage, it's not something I care about. 'toString()' however is useful. I don't remember the casing in JS but I think 'tostring()' is also useless. What's important here isn't the 10 characters in any event and I don't care to type them effectively. If my language can't tell me which is valid it's frankly like mowing a lawn with nail scissors. Fun for a certain kind of eccentric but not what you need when your day job is gardening.

If I have defined a 'toDring()' method then expose it by letting me type 't', 'down key' (to choose the non tostring version), 'enter'. If I haven't then don't let me type it. I think (heavy reliance on) text manipulation as a way of interacting with languages is a sign of either a bad/underdeveloped language, or a community which gets off on the 'hard for the sake of it' mindset.

Re: Development Environments

#110

Post by ivanivanovich »

funklute wrote: post #78
invalidname wrote: post #70

Earlier quoted context omitted.

I haven't written LSP so I'll reserve the opinion at that. What I understood about emacs is that it doesn't have a concept of a project so I don't see how it can form dependencies that are more sophisticated. But maybe I don't understand something about that. I can totally write these sort of plugins for any IDE I worked with. Notice that all of these capabilities are symbols of a bygone time where you stuck everythi…

> What I understood about emacs is that it doesn't have a concept of a project Not built-in, but there are packages available for that.

I think project.el is builtin
Post reply on HN