lainchan archive - /λ/ - 21973
[ Return /
Go to bottom ]
File: 1486701236162.png (8.58 KB, 300x232, ide.jpg)
Are they worth using on Linux, Or is command line the way to go?
What do other lains use/recommend?
What do other lains use/recommend?
Why would using IDE cable be a good idea?
I know I'm being pedantic, but you can have an IDE that's on the command line, or a GUI text editor. If you don't use an IDE you'll probably (but not necessarily) be running the code using the command line. Lots of people (professionals included) use an IDE but use the command line to run code too.
I suggest learning without an IDE. In a lot of cases you're expected to know how to do things without one and it's honestly easier most of the time, and definitely simpler.
If you don't know how to use the command line at all then you absolutely need to learn it, regardless of whether you end up using it long term.
I use a highly customized Emacs environment. It's different than an IDE in some ways but has the same features. I first learned using the command line and an editor like Notepad++ (I think TextWrangler because I was on OS X, but it doesn't matter, I nearly used it like vanilla Notepad). When I had the free time I learned Vim, and then learned Emacs, then learned how to use Vim keybinds in Emacs, etc. IMO, you should learn as little as possible at once.
I suggest learning without an IDE. In a lot of cases you're expected to know how to do things without one and it's honestly easier most of the time, and definitely simpler.
If you don't know how to use the command line at all then you absolutely need to learn it, regardless of whether you end up using it long term.
I use a highly customized Emacs environment. It's different than an IDE in some ways but has the same features. I first learned using the command line and an editor like Notepad++ (I think TextWrangler because I was on OS X, but it doesn't matter, I nearly used it like vanilla Notepad). When I had the free time I learned Vim, and then learned Emacs, then learned how to use Vim keybinds in Emacs, etc. IMO, you should learn as little as possible at once.
>>21975
>professionals included
I feel I should add that "on the job" you'd be fine using an IDE or not using one. You'll look like you're trying too hard if you come in using Vim and the command line but you'll also get a lot of respect from coworkers. Unless you're working for a company like Microsoft that has its own dev tools and requires employees to use them you'll be fine using whatever you want.
>professionals included
I feel I should add that "on the job" you'd be fine using an IDE or not using one. You'll look like you're trying too hard if you come in using Vim and the command line but you'll also get a lot of respect from coworkers. Unless you're working for a company like Microsoft that has its own dev tools and requires employees to use them you'll be fine using whatever you want.
File: 1486704609049.png (175.88 KB, 200x113, ide.png)
For my IDE I use a few terminal windows.
For user space stuff I typically have a large terminal window running a tabbed vim session with all the source files, a smaller terminal tabbed vim session with header / documentation files open, and a terminal window for compilation / running / debugging the software. For embedded projects I typically have the same setup, but with an additional terminal window for running a tui gdb session.
I have used 'normal' IDE's in the past for school, eclipse and visual studio to name a few; however these generally felt slow, bloated, over complicated and in general lacking in raw power. I felt like eclipse and friends obfuscated a lot of functionality that is pretty vital to my development process. Compilation / build options were hidden away behind a number of settings and menus and git / version control options were similarly squirled away behind plugin installation and ambiguous preferences. Not to mention that under the hood, at least on linux, more often than not all the IDE is doing is running gcc / make / auto tools behind your back while you fiddle with their pretty gui.
It might look a little messy, but it works wonders. And I'm sure a ricer could make it look great.
For user space stuff I typically have a large terminal window running a tabbed vim session with all the source files, a smaller terminal tabbed vim session with header / documentation files open, and a terminal window for compilation / running / debugging the software. For embedded projects I typically have the same setup, but with an additional terminal window for running a tui gdb session.
I have used 'normal' IDE's in the past for school, eclipse and visual studio to name a few; however these generally felt slow, bloated, over complicated and in general lacking in raw power. I felt like eclipse and friends obfuscated a lot of functionality that is pretty vital to my development process. Compilation / build options were hidden away behind a number of settings and menus and git / version control options were similarly squirled away behind plugin installation and ambiguous preferences. Not to mention that under the hood, at least on linux, more often than not all the IDE is doing is running gcc / make / auto tools behind your back while you fiddle with their pretty gui.
It might look a little messy, but it works wonders. And I'm sure a ricer could make it look great.
Although it is usually called a text editor, emacs meets all of the definitions of a general-purpose IDE.
File: 1486736122399.png (13.06 KB, 200x200, 1450012020308.jpg)
>>21976
>You'll look like you're trying too hard if you come in using Vim and the command line
>but you'll also get a lot of respect
W-what?
Im studying programming and Vim+CLI is all I've needed, and it hasn't felt very difficult at all.
My instinct on the matter is that UNIX was made to be a programmers workbench, why learn to use an IDE when I could just learn to use the command line? Some blogs and talks have confirmed and reinforced this bias.
Why would you be looked at like a computing wizard or a tryhard skid for just using the operating sy stem and the tools on it? What im I missing in my beginner-ness?
>You'll look like you're trying too hard if you come in using Vim and the command line
>but you'll also get a lot of respect
W-what?
Im studying programming and Vim+CLI is all I've needed, and it hasn't felt very difficult at all.
My instinct on the matter is that UNIX was made to be a programmers workbench, why learn to use an IDE when I could just learn to use the command line? Some blogs and talks have confirmed and reinforced this bias.
Why would you be looked at like a computing wizard or a tryhard skid for just using the operating sy stem and the tools on it? What im I missing in my beginner-ness?
>>21981
Sure.
For a terminal I use urxvt (the daemon version) for now, but I'm thinking of switching to termite soon. The tiling layout is just the stock master/stack tiling layout that comes with DWM. As for the colors I've included my .Xresources which has all that and my urxvt options in it.
I would not recommend the font I'm using though, it's another thing I'm thinking about changing soon. A few too many ambiguous characters for my liking; if I switch I'll switch to 'hack'.
Sure.
For a terminal I use urxvt (the daemon version) for now, but I'm thinking of switching to termite soon. The tiling layout is just the stock master/stack tiling layout that comes with DWM. As for the colors I've included my .Xresources which has all that and my urxvt options in it.
I would not recommend the font I'm using though, it's another thing I'm thinking about changing soon. A few too many ambiguous characters for my liking; if I switch I'll switch to 'hack'.
*color0: #2e3436
*color1: #a40000
*color2: #4E9A06
*color3: #C5A000
*color4: #3465A4
*color5: #75507B
*color6: #ce5c00
*color8: #babdb9
*color9: #EF2929
*color10: #8AE234
*color11: #FCE94F
*color12: #729FCF
*color13: #AD7FA8
*color14: #fcaf3e
*color15: #EEEEEC
urxvt*foreground: #d2738b
urxvt*background: black
urxvt*scrollBar: false
urxvt*font: xft:inconsolata:size=11:antialias=true:hinting=trueI recommend against terminal text editors. GUI editors usually have neat innovative features that makes things look nicer and more convenient to use.
I've never done anything big enough to warrant the use of big IDE, I would suggest gedit or something, kwrite, kate, there are better cooler new ones, I just don't know their names.
I've never done anything big enough to warrant the use of big IDE, I would suggest gedit or something, kwrite, kate, there are better cooler new ones, I just don't know their names.
>>21993
There's nothing inherent to GUIs that make them more fully featured. More accessible perhaps, but tailoring an IDE to the user who is not ready to learn his way around the software is a dead end.
I'd argue that Emacs remains the most feature rich, customisable editors there is and internally it's still pretending to be a terminal.
There's nothing inherent to GUIs that make them more fully featured. More accessible perhaps, but tailoring an IDE to the user who is not ready to learn his way around the software is a dead end.
I'd argue that Emacs remains the most feature rich, customisable editors there is and internally it's still pretending to be a terminal.
>>21996
I'm not an emacs user but I've been told that the emacs GUI can display latex symbols as equations (e.g.
That alone makes GUI more fully featured. I'm sure there's a lot of other things that could be used as an example of GUIs being fully featured.
Another cool thing with GUI is that they're usually faster than their terminal versions since they don't have to rely on unbearably slow escape sequence in order to get their what they want to display displayed.
I'm not an emacs user but I've been told that the emacs GUI can display latex symbols as equations (e.g.
$\Sigma$ would be displayed as Σ). I think that's pretty cool and although you can replace simple latex symbols with their corresponding unicode symbols in a simple terminal, you can't do that with complex equations.That alone makes GUI more fully featured. I'm sure there's a lot of other things that could be used as an example of GUIs being fully featured.
Another cool thing with GUI is that they're usually faster than their terminal versions since they don't have to rely on unbearably slow escape sequence in order to get their what they want to display displayed.
>>22003
That's true and I agree; GUIs are obviously more fully featured than CLIs, they are strictly a superset in terms of what can be displayed. Whether or not that's necessary is probably what >>21996 disagrees on. I agree with you, but think that everyone should try both and see which they like more.
That's true and I agree; GUIs are obviously more fully featured than CLIs, they are strictly a superset in terms of what can be displayed. Whether or not that's necessary is probably what >>21996 disagrees on. I agree with you, but think that everyone should try both and see which they like more.
I like that (graphical) IDE tries to guess what I'm going to write, and even pops up a list. The fancy name for this is intelligent code compilation. Saves my time. The feature is known as intellisense in VS, but apparently Eclipse can do it too. Also there are many other tiny things that I find amusing (e.g. assistance to refactoring, autogenerating a subroutine based on a call). I wonder if those things can be done in text-based solutions.
I agree that a beginner should maybe do it the hard way in the beginning to learn what is really happening. Then when one knows, one can continue to fully-fledged IDE which can improve the workflow.
I agree that a beginner should maybe do it the hard way in the beginning to learn what is really happening. Then when one knows, one can continue to fully-fledged IDE which can improve the workflow.
>>22009
>I wonder if those things can be done in text-based solutions.
Sure they can. Neovim and Emacs have plenty of plugins that allow you to interact with language servers that generate completion suggestions and things like that. I've especially been blown away by how smart tern-js is and how fast its neovim integration is with deoplete.
>I wonder if those things can be done in text-based solutions.
Sure they can. Neovim and Emacs have plenty of plugins that allow you to interact with language servers that generate completion suggestions and things like that. I've especially been blown away by how smart tern-js is and how fast its neovim integration is with deoplete.
>>22010
It should be noted that in Emacs at least the implementation of the visual pop-up is a huge hack. It's essentially temporarily replacing text in the buffer where the menu needs to be drawn.
Hopefully Emacs gets support for proper graphical overlays at some point in the future, because that's one area where it's totally beaten by more modern editors, but I doubt it can work with the infrastructure as it stands. I'd like to see what can be done with capabilities like that beyond silly things like this https://atom.io/packages/activate-power-mode.
It should be noted that in Emacs at least the implementation of the visual pop-up is a huge hack. It's essentially temporarily replacing text in the buffer where the menu needs to be drawn.
Hopefully Emacs gets support for proper graphical overlays at some point in the future, because that's one area where it's totally beaten by more modern editors, but I doubt it can work with the infrastructure as it stands. I'd like to see what can be done with capabilities like that beyond silly things like this https://atom.io/packages/activate-power-mode.
>>22025
>Hopefully Emacs gets support for proper graphical overlays at some point in the future
With 25.1 there's experimental support for Cairo[1,2] (when compiled with the --with-cairo flag). The situation isn't quite as bleak as it seems at the moment, which is good.
[1] https://www.cairographics.org/
[2] https://www.masteringemacs.org/article/whats-new-in-emacs-25-1
>Hopefully Emacs gets support for proper graphical overlays at some point in the future
With 25.1 there's experimental support for Cairo[1,2] (when compiled with the --with-cairo flag). The situation isn't quite as bleak as it seems at the moment, which is good.
[1] https://www.cairographics.org/
[2] https://www.masteringemacs.org/article/whats-new-in-emacs-25-1
>>21977
Oh, nice, and ARM embedded guy.
I've started playing around with EFM32 Wonder Gecko Starter Kit, since SiLabs makes some really nice micros.
I'm just using their Simplicity Studio IDE (which is Eclipse+some extra stuff from SiLabs like power monitoring).
I've been thinking about embedded development in CLI for a while, but I don't really see it for myself right now. The most I've done was using openOCD for flashing stuff on some STM32 boards.
Oh, nice, and ARM embedded guy.
I've started playing around with EFM32 Wonder Gecko Starter Kit, since SiLabs makes some really nice micros.
I'm just using their Simplicity Studio IDE (which is Eclipse+some extra stuff from SiLabs like power monitoring).
I've been thinking about embedded development in CLI for a while, but I don't really see it for myself right now. The most I've done was using openOCD for flashing stuff on some STM32 boards.
File: 1489106519518.png (14.04 KB, 200x63, tim_teitelbaum.png)
>>21973
current IDEs and the languages built inside them are an embarrassment of what they were meant for and what is possible
https://en.wikipedia.org/wiki/Tim_Teitelbaum
current IDEs and the languages built inside them are an embarrassment of what they were meant for and what is possible
https://en.wikipedia.org/wiki/Tim_Teitelbaum
>>22471
It means Teitelbaum (not the poster) thinks Interactive environments and "smart" IDEs are the way to go. A context aware editor can help you write and debug code easier than a plain text editor.
It's true, but for most tasks i don't think it makes a difference unless the language is a heavy "mind burden" one like C++, C#, Java, etc.
It means Teitelbaum (not the poster) thinks Interactive environments and "smart" IDEs are the way to go. A context aware editor can help you write and debug code easier than a plain text editor.
It's true, but for most tasks i don't think it makes a difference unless the language is a heavy "mind burden" one like C++, C#, Java, etc.
I am a fan of Lighttable when I'm not using Vim. Any lainons use(d) it and have any opinions?
File: 1490655115083.png (71.48 KB, 200x154, typewriters.jpg)
>>22490
>It means Teitelbaum (not the poster) thinks Interactive environments and "smart" IDEs are the way to go.
>are the way to go
they already are, every commodity chipset today is designed from beginning to end in an environment that doesn't make the hilarious error of treating code as text; VHDL files are useful intermediates, but no productive computer engineer is generating it in plaintext anymore
programmers that claim that plaintext alone is useful have ignored that the core mechanisms of what makes their code useful at all in the real world came about from abstractions built in EDA IDEs, it's just plain ol' psychological dissociation
>but for most tasks i don't think it makes a difference
when the relationship between a programmer/admin and a system is formalized, that domain should and will get automated
any code environment that isn't gathering statistics on user input and codebase comprehension for automation (Autocomplete is a primitive example) in some way is just that, an "editor", a word that should associated with turn-of-the-century workhouses with rows of tabloid monkeys breaking their fingers at typewriters to crank out crap
>>22672
whatever he means (is UTF-8 plaintext? or UTF-16? it wasn't always, generally with the posters complacent tone one assumes whatever contemporary regression to mediocrity), any system that has the potential to escape the confines of human psycho-linguistic limits to run more reliably and faster on behalf of its users should do so
>It means Teitelbaum (not the poster) thinks Interactive environments and "smart" IDEs are the way to go.
>are the way to go
they already are, every commodity chipset today is designed from beginning to end in an environment that doesn't make the hilarious error of treating code as text; VHDL files are useful intermediates, but no productive computer engineer is generating it in plaintext anymore
programmers that claim that plaintext alone is useful have ignored that the core mechanisms of what makes their code useful at all in the real world came about from abstractions built in EDA IDEs, it's just plain ol' psychological dissociation
>but for most tasks i don't think it makes a difference
when the relationship between a programmer/admin and a system is formalized, that domain should and will get automated
any code environment that isn't gathering statistics on user input and codebase comprehension for automation (Autocomplete is a primitive example) in some way is just that, an "editor", a word that should associated with turn-of-the-century workhouses with rows of tabloid monkeys breaking their fingers at typewriters to crank out crap
>>22672
whatever he means (is UTF-8 plaintext? or UTF-16? it wasn't always, generally with the posters complacent tone one assumes whatever contemporary regression to mediocrity), any system that has the potential to escape the confines of human psycho-linguistic limits to run more reliably and faster on behalf of its users should do so
I don't use an IDE to build my projects but I do use it for code inspections that standard text editors aren't capable of without a lot of effort to maintain some huge plugin (ensime). The ability to just hit alt = and show the correct type of an expression or hit ctrl [ and go to the actual definition (not what ctags guessed) can't be understated. Especially when that definition is in an external library.
Also the syntax highlighting can get several levels better than vim or emacs can since it can recognize the difference between a local variable and an argument, local method or a static method etc. Point is IDEs actually understand your code whereas vim and emacs just use regex patterns.
That said using an IDE to build your project is fuarrrking dumb and should be avoided at all costs.
Also the syntax highlighting can get several levels better than vim or emacs can since it can recognize the difference between a local variable and an argument, local method or a static method etc. Point is IDEs actually understand your code whereas vim and emacs just use regex patterns.
That said using an IDE to build your project is fuarrrking dumb and should be avoided at all costs.
I do mostly python/django development, with some react stuff on the front-end. I use Intellij products Pycharm and Webstorm. I'm a pretty novice programmer, but when I was learning Ruby/Rails I always just used vim.
Now that I work with Python, I find that 'code spelunking' is a really important part of my job - multiple inheritance and over-writing methods etc. Pycharm is really awesome for this. I right-click on an object and get taken to its declaration and source code. I've tried setting up exuberant ctags to mimic this behavior but have not had any luck - tags don't seem to be created from the contents of my env directory.
I fantasize about some point in the future when I am working remotely (from really remote locations) and using some kind of minimalist, low-power setup (rpi, eink monitor?) and of course going back to the terminal for doing everything. But I would really need to be able to quickly and easily crawl through source code. I don't really care about code completion.
Also, while I love Vim, I wonder if Emacs might be a better solution to this problem, as it is obvious I am pushing Vim to be more like a fully-featured IDE as opposed to just a fancy text editor. I'd probably use Emacs in vim-mode though; i do that with Pycharm.
Any advice?
Now that I work with Python, I find that 'code spelunking' is a really important part of my job - multiple inheritance and over-writing methods etc. Pycharm is really awesome for this. I right-click on an object and get taken to its declaration and source code. I've tried setting up exuberant ctags to mimic this behavior but have not had any luck - tags don't seem to be created from the contents of my env directory.
I fantasize about some point in the future when I am working remotely (from really remote locations) and using some kind of minimalist, low-power setup (rpi, eink monitor?) and of course going back to the terminal for doing everything. But I would really need to be able to quickly and easily crawl through source code. I don't really care about code completion.
Also, while I love Vim, I wonder if Emacs might be a better solution to this problem, as it is obvious I am pushing Vim to be more like a fully-featured IDE as opposed to just a fancy text editor. I'd probably use Emacs in vim-mode though; i do that with Pycharm.
Any advice?
>>22836
Either the IDE integrates with an external build system in which case your capabilities of that build system are limited to whatever is supported by the IDE. Or the IDE provides its own build system in which case other developers are forever forced to use that specific IDE. Eclipse is especially unforgivable because it uses its own compiler not javac. So projects made in eclipse might not even compile using javac.
Using an IDE also limits whatever deployment automation tools you may be using. Scripting a CLI build system is trivial compared to scripting an IDE.
Any large project will be inescapably tied to its build system so its better to tie it to a dedicated single purpose program than a full blown suite.
Either the IDE integrates with an external build system in which case your capabilities of that build system are limited to whatever is supported by the IDE. Or the IDE provides its own build system in which case other developers are forever forced to use that specific IDE. Eclipse is especially unforgivable because it uses its own compiler not javac. So projects made in eclipse might not even compile using javac.
Using an IDE also limits whatever deployment automation tools you may be using. Scripting a CLI build system is trivial compared to scripting an IDE.
Any large project will be inescapably tied to its build system so its better to tie it to a dedicated single purpose program than a full blown suite.