Development Environments
phaazon.net
Development Environments
1–10 of 145 posts
Re: Development Environments
#2I'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 (Ultimate). It flies. As professionals we need to spend on our tools and on our hardware to get the most out of both.
The depth of insight that IntelliJ allows me at a glance when debugging, reviewing, refactoring, etc. is as a league that is so beyond what the CLI enables. I can't even begin to describe that.
To be fair, this isn't universal. E.g. for kernel development, some embedded use cases, etc. the IDE might have less of a benefit. But for most day to day app development avoiding an IDE seems like a Luddite approach.
Re: Development Environments
#3The workflows enabled by Jupyter and iPython address some of your biggest concerns.
You have references to previous outputs, don't recompute things, and in browser can have GUI interactive elements. You can likely find live streaming monitors too. Though that starts to break what the environment is best at: composing an edited, rational path through a process based on interactive exploration, trial and error.
https://en.wikipedia.org/wiki/Project_Jupyter#Jupyter_Notebo...
Re: Development Environments
#4I'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…
It seems like Java is in a pretty unique place in terms of the quality of the tools and the frequent need to use complex tools to get even a vague idea what's going on.
Re: Development Environments
#5site gives 404 error when I try reloading it. firefox on windows
Re: Development Environments
#6I'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…
It seems like Java is in a pretty unique place in terms of the quality of the tools and the frequent need to use complex tools to get even a vague idea what's going on.
True. But Idea Ultimate works surprisingly well with JavaScript and very well with Typescript including react code, etc.
It's so much easier than going through NPM noise. Just auto fix and in 95% of the cases it's just what I need.
The JetBrains IDEs for other platforms have almost the same level of capabilities. I also worked a lot with xcode, its not nearly as good as AppCode but it's still an improvement over trying to build iOS from the command line... I did that a lot and that isn't a pleasant experience in the least.
Re: Development Environments
#7One part of the article that resonates with me is the need for composable software that uses a more sophisticated mechanism than Unix pipes to connect components to provide an integrated experience. Over the past few years I've been interested in the idea of component-based software through IPC protocols and metaprogramming. This year I've been playing around with Plan 9, and I've found its ideas of component-based software through the 9p protocol interesting. I also got to spend some time using acme, which is one of the editors that comes with Plan 9. What makes acme interesting is that I can run external commands in the editor to perform various tasks, ranging from text manipulations to tasks such as compiling code. Each output shows up as its own window pane. One could create a sort of IDE using acme's ability to run external commands.
While acme can seamlessly support external commands, a limitation, however, is there is no metaprogramming facility for changing the functionality of the editor itself. This makes acme less powerful than Emacs, which has the Emacs Lisp subsystem for extending and modifying the behavior of the editor. For example, suppose I wanted to add syntax highlighting to acme. Doing so requires modifying acme's source code. However, if acme provided some type of metaprogramming interface to the editor, then I could write code adding syntax highlighting. Ideally, this metaprogramming interface should be language-agnostic and take advantage of the 9p protocol. This would make acme just as powerful as Emacs, and in fact would give acme an advantage since extending acme won't require a specific language.
Come to think of it, some of this metaprogramming capability may already be present in Plan 9 through the use of the /proc directory, thus obviating the need for application-specific metaprogramming mechanisms, though its offered at the binary level. I'll have to investigate this some more, though.
My thought is that sophisticated IPC protocols and support for application-level metaprogramming can provide the rich interoperability that the writer of the article wants for creating composable development environments.
Re: Development Environments
#8I'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 think a professional software engineer can be expected/required to use proper tools. That includes using decent hardware. Fast computers allow you to wait less and waste less time. If you are any good, the accumulated savings in time are worth more than the hardware in a matter of days or weeks. So, don't cheap out on hardware. It's unprofessional. Within reason, you can actually get away with some budget hardware these days. And you can also use remote tools to make your hardware matter even less. But whatever you do, minimize the waste of time. And if you use e.g. rust, kotlin, or js based development tools, you likely have some non trivial build times that can benefit greatly from good CPUs, fast SSDs and enough memory. Those build times add up quickly.
I'm old and wise enough to not get between developers and their tool choices no matter how odd they are. So, I tend to give a lot of freedom to my people; and also take that freedom occasionally because I love trying out different things and optimizing my workflow. I love learning from others on how to improve my own workflow.
I have a simple rule: your code must be properly formatted, refactored, and free of warnings when you create a pull request. Boy scout rule basically. Anything less than that is sloppy work and I'll call it out and will make you fix it. Always be refactoring and cleaning up code. I don't care how you do it and whether you do it the smart way (using proper tools) or the dumb way (manually using notepad and staring at compiler output) as long as you do it and know how to do it and when to do it.
If it looks like you are being clumsy/sloppy/negligent with your tools, I'll have to have a word with you and tell you how to improve. That may include some not so subtle hints about your tool choices.
Re: Development Environments
#9I'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…
It seems like Java is in a pretty unique place in terms of the quality of the tools and the frequent need to use complex tools to get even a vague idea what's going on.
The only reason Java can even have the most powerful tools is because it is easy to see what is going on. Also, JetBrains does really well with all languages, generally more than any other IDE.
Re: Development Environments
#10I'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…
CLion for C++ is just brilliant.