4 ms·

I dislike most of these "modern IDEs". They seem to encourage Big Programs that shouldn't be written in the first place. http://michaelochurch.wordpress.com/201

I dislike most of these "modern IDEs". They seem to encourage Big Programs that shouldn't be written in the first place. http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-unix-philosophy/ http://michaelochurch.wordpress.com/2013/01/09/ide-culture-v... (IDE culture vs. Unix philosophy). However, you are right that, in terms of features, they deliver, if you keep your directory structure, language choice, and development practices within certain bounds.

blablabla123 14y ago
Yes... I mean even if the programs are big, IDEs encourage a massive footprint of just about anything. (I would not go so far to declare big programs per se as a bad thing.) Massive build instructions, massive Interface declarations, massive amount of stub files... Things happen with IDEs that would never happen when using a plain editor. Probably Java has a part of its verbose reputation due to the abuse of IDEs. It's just so easy to use 60 letter function names, if you used a regular editor, people would not do this because their hands would start to hurt.
- anon1385 14y ago
  >Massive build instructions […] would never happen when using a plain editor. How many non trivial projects do you compile by hand rather than using an automated build system (make etc)? How does autoconf or cmake prevent or discourage you from using 'massive build instructions'? Why is turning on more warnings or other compiler options a bad thing? >Probably Java has a part of its verbose reputation due to the abuse of IDEs. It's just so easy to use 60 letter function names, if you used a regular editor, people would not do this because their hands would start to hurt. You are talking about code-completion. What 'regular editor' do you use that doesn't have at least basic support for code-completion? pico/nano? Notepad? When these arguments/rants come up, it seems that the definition of 'IDE' changes to fit the argument being made. If somebody suggests they prefer to use an IDE because it has code-completion, they are quickly told that plain editor X also has code-completion. Then it is argued that IDEs are bad because they have code-completion which encourages you to write verbose code. This seems to extend to many other 'IDE' features: I've seen people argue against inline documentation lookup, against syntax highlighting, against a 'build' or compile command in the editor, against 'jump to definition', against interactive debuggers. I've also seen people argue that all those things are available in 'plain editors' and thus there is no need to use an IDE to get them. At this point I've no idea at all what the difference is between an IDE and 'plain editor'. Other than truly basic editors that hardly anybody uses to code, I think just about everything could be called an IDE.
  - jiggy2011 14y ago
    Agreed, my workflow is basically the same whether I use an editor or IDE. The only difference being that sometimes I wish the editor had more features and sometimes I wish the IDE had less stuff on the screen so I could just see the code. It is however a lot easier to configure an IDE into a dumb editor than it is the other way around.
qznc 14y ago
The fundamental question is how we compose things. The Unix way is to compose small programs via byte streams. Another way is to link lots of libraries via function calls. Yet another way is the image approach taken by Smalltalk and Common Lisp. These approaches all have tradeoffs and their own version of the dependency hell. Thanks to the batteries-included philosophy a few lines of python can yield power, which would be a Big Program in the early days of Unix. I assume nobody would suggest that Python's glob library should exec the find executable or something.
- jqgatsby 14y ago
  @qznc that's an intriguing formulation. Could you elaborate a bit? 1) What do you mean by "image approach"? 2) What example are you thinking of for the "link lots of libraries via function calls" approach? The trichotomy I am familiar with is to divide things up into lisp vs c/unix vs smalltalk schools, but that doesn't seem to map to what you are saying.
  - spc476 14y ago
    For "image" read, a runnable core file that can be updated (from within the program) and saved. Seriously. Forth and Smalltalk are two languages that are typically "image" based. Because of that, the concept of a "program" might not make sense, because it's more of an operating environment. And even if you do buy the concept of a "program", each program is, in essence, a potential development environment (if the REPL is exposed---it can be sometimes be hidden or even modified). As such, a "program upgrade" is (in my opinion) insanely difficult to manage in such an environment, as the customer may have extended the program in an incompatible way with respect to the upgrade. Also, the concept of "source code" might not exist as we understand it (a human readable set of instructions the computer will carry out stored in a file or files). Forth will compile the code directly; Smalltalk (disclaimer: I have no experience with Smalltalk) might store the code you type somewhere, so it can be viewed and edited, but there's no guarantee it's a "file".
  - qznc 14y ago
    As spc476 answered 1), I'll just expand on 2). Emacs would be an example of the link approach. It includes an editor and an email program, which are composed into a single program/image. In contrast, the Unix functionality (vim,sendmail) is split into separate programs. What is the difference between a function call and a program invocation? In both cases we have a name and maybe some arguments. In both cases the computer executes some code bound to that name parameterized with our arguments. The difference is primarily, how expensive is the name resolution. A shell command requires inspecting $PATH, looking through directories, fork/exec another program, which is a lot syscalls. A function call in the best case has been compiled to a "call" instruction, whose cost depends on the branch prediction. Of course, there are various levels in between (dynamically linked libraries, plugins, shell builtins, etc). There are more complex composition methods like SAAS or cloud computing. There are more efficient methods (inlining optimization). Semantically, it is interesting when a name is resolved. Compiled languages (C,Go) usually do this statically at compile time, where C is even more restrictive as it only looks above in the code. Dynamic languages (Python,Ruby) do it at runtime. In general, early binding is usually good for performance, while late binding is better for flexibility.
mark_l_watson 14y ago
After a few decades of emacs and Common Lisp, I strongly prefer the free community IntelliJ with the Clojure plugin. Sure, I have emacs setup for Clojure development, I just don't use it anymore, preferring IntelliJ. Times change :-)
- ced 14y ago
  Why?
  - mark_l_watson 14y ago
    I find that I can work a little bit faster and more efficiently. I admit that it is a close call.

blablabla123 14y ago

Yes... I mean even if the programs are big, IDEs encourage a massive footprint of just about anything. (I would not go so far to declare big programs per se as a bad thing.) Massive build instructions, massive Interface declarations, massive amount of stub files... Things happen with IDEs that would never happen when using a plain editor. Probably Java has a part of its verbose reputation due to the abuse of IDEs. It's just so easy to use 60 letter function names, if you used a regular editor, people would not do this because their hands would start to hurt.

anon1385 14y ago
>Massive build instructions […] would never happen when using a plain editor. How many non trivial projects do you compile by hand rather than using an automated build system (make etc)? How does autoconf or cmake prevent or discourage you from using 'massive build instructions'? Why is turning on more warnings or other compiler options a bad thing? >Probably Java has a part of its verbose reputation due to the abuse of IDEs. It's just so easy to use 60 letter function names, if you used a regular editor, people would not do this because their hands would start to hurt. You are talking about code-completion. What 'regular editor' do you use that doesn't have at least basic support for code-completion? pico/nano? Notepad? When these arguments/rants come up, it seems that the definition of 'IDE' changes to fit the argument being made. If somebody suggests they prefer to use an IDE because it has code-completion, they are quickly told that plain editor X also has code-completion. Then it is argued that IDEs are bad because they have code-completion which encourages you to write verbose code. This seems to extend to many other 'IDE' features: I've seen people argue against inline documentation lookup, against syntax highlighting, against a 'build' or compile command in the editor, against 'jump to definition', against interactive debuggers. I've also seen people argue that all those things are available in 'plain editors' and thus there is no need to use an IDE to get them. At this point I've no idea at all what the difference is between an IDE and 'plain editor'. Other than truly basic editors that hardly anybody uses to code, I think just about everything could be called an IDE.
- jiggy2011 14y ago
  Agreed, my workflow is basically the same whether I use an editor or IDE. The only difference being that sometimes I wish the editor had more features and sometimes I wish the IDE had less stuff on the screen so I could just see the code. It is however a lot easier to configure an IDE into a dumb editor than it is the other way around.

qznc 14y ago

The fundamental question is how we compose things. The Unix way is to compose small programs via byte streams. Another way is to link lots of libraries via function calls. Yet another way is the image approach taken by Smalltalk and Common Lisp. These approaches all have tradeoffs and their own version of the dependency hell. Thanks to the batteries-included philosophy a few lines of python can yield power, which would be a Big Program in the early days of Unix. I assume nobody would suggest that Python's glob library should exec the find executable or something.

jqgatsby 14y ago
@qznc that's an intriguing formulation. Could you elaborate a bit? 1) What do you mean by "image approach"? 2) What example are you thinking of for the "link lots of libraries via function calls" approach? The trichotomy I am familiar with is to divide things up into lisp vs c/unix vs smalltalk schools, but that doesn't seem to map to what you are saying.
- spc476 14y ago
  For "image" read, a runnable core file that can be updated (from within the program) and saved. Seriously. Forth and Smalltalk are two languages that are typically "image" based. Because of that, the concept of a "program" might not make sense, because it's more of an operating environment. And even if you do buy the concept of a "program", each program is, in essence, a potential development environment (if the REPL is exposed---it can be sometimes be hidden or even modified). As such, a "program upgrade" is (in my opinion) insanely difficult to manage in such an environment, as the customer may have extended the program in an incompatible way with respect to the upgrade. Also, the concept of "source code" might not exist as we understand it (a human readable set of instructions the computer will carry out stored in a file or files). Forth will compile the code directly; Smalltalk (disclaimer: I have no experience with Smalltalk) might store the code you type somewhere, so it can be viewed and edited, but there's no guarantee it's a "file".
- qznc 14y ago
  As spc476 answered 1), I'll just expand on 2). Emacs would be an example of the link approach. It includes an editor and an email program, which are composed into a single program/image. In contrast, the Unix functionality (vim,sendmail) is split into separate programs. What is the difference between a function call and a program invocation? In both cases we have a name and maybe some arguments. In both cases the computer executes some code bound to that name parameterized with our arguments. The difference is primarily, how expensive is the name resolution. A shell command requires inspecting $PATH, looking through directories, fork/exec another program, which is a lot syscalls. A function call in the best case has been compiled to a "call" instruction, whose cost depends on the branch prediction. Of course, there are various levels in between (dynamically linked libraries, plugins, shell builtins, etc). There are more complex composition methods like SAAS or cloud computing. There are more efficient methods (inlining optimization). Semantically, it is interesting when a name is resolved. Compiled languages (C,Go) usually do this statically at compile time, where C is even more restrictive as it only looks above in the code. Dynamic languages (Python,Ruby) do it at runtime. In general, early binding is usually good for performance, while late binding is better for flexibility.

mark_l_watson 14y ago

After a few decades of emacs and Common Lisp, I strongly prefer the free community IntelliJ with the Clojure plugin. Sure, I have emacs setup for Clojure development, I just don't use it anymore, preferring IntelliJ. Times change :-)

ced 14y ago
Why?
- mark_l_watson 14y ago
  I find that I can work a little bit faster and more efficiently. I admit that it is a close call.