6 ms·

I'm a big Lisp dialects proponent but I don't like that article very much. It's very naive and the author is unexperienced IMHO. For example the author writes

I'm a big Lisp dialects proponent but I don't like that article very much. It's very naive and the author is unexperienced IMHO. For example the author writes: "I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen." Ouch. The author doesn't seem to be very knowledgeable of "best practices" and IDEs from the last ten years available in the Java/C# world. Lisp dialects can really shine in various ways but "refactoring" ain't exactly one area where Emacs (which he mentions and which I do love) beats "modern IDEs". Apparently the author's only experience comes from old JavaScript development environments and some Perl hacking. He's hardly "connected" with real-word, modern, way of developing software. His description as to how he's upgrading servers by manually copying binaries also shows he's disconnected from actual enterprise deployment techniques. Overall it feels very amateurish. But kudos for picking a Lisp dialect and sticking to it and reaping the benefits of that smart choice...

michaelochurch 14y ago
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
Many people don't use IDEs anymore, I guess the only field IDEs are still dominant is the corporate environment. (And some LISP shops obviously ;)) So even if he hasn't used Visual C#, Netbeans or Eclipse yet, this doesn't necasserily mean that he is unexperienced. There is still software development going on beyond enterprise. ;)
- jiggy2011 14y ago
  I don't know, plenty of game developers, android developers and iOS developers are IDE users.
pnathan 14y ago
Yeah, the author obviously has never used Visual Studio (Or Eclipse or SlickEdit or...) in the last decade or so. However, the "real world deployment" thing is kind of a spectrum. There's definitely the super-tight provisioning/deployments with ec2/puppet/jenkins/etc, but it goes all the way down to "have debian and hand-install widgets". That seems to depend on the organization's willingness to buy into the "cloud" idea, which seems to be regulated by the leadership's comfort with software.
wglb 14y ago
So far as I know, Visual Studio won't show you the source code to length or read, whereas Lisp will.
- KirinDave 14y ago
  Except many popular, monder lisps still don't show you that. Native functions often can't be shown. Bummer, huh?
  - wglb 14y ago
    I am speaking about SBCL, in particular; don't know about others. You can drill all the way down.
    - KirinDave 14y ago
      I think some primitives are still unexposed. Cons, if, etc?
      - wglb 14y ago
        Well, so far I can drill into if, cons, unless, let*, let.
        PuercoPop 14y ago
        You can drill into the assembly code generated.
- eropple 14y ago
  You sure? I don't know if VS will by default, but (at least on my machine) it's installed under ${VS11}/VC/crt/src so I'm sure it's possible - not sure if it's the complete sources, though. Eclipse or IntelliJ will for Java if you install the JDK, though, and I'm pretty sure you can install the libc++ sources for XCode and go through them if you want (don't quite me on that though).

michaelochurch 14y ago

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

Many people don't use IDEs anymore, I guess the only field IDEs are still dominant is the corporate environment. (And some LISP shops obviously ;)) So even if he hasn't used Visual C#, Netbeans or Eclipse yet, this doesn't necasserily mean that he is unexperienced. There is still software development going on beyond enterprise. ;)

jiggy2011 14y ago
I don't know, plenty of game developers, android developers and iOS developers are IDE users.

pnathan 14y ago

Yeah, the author obviously has never used Visual Studio (Or Eclipse or SlickEdit or...) in the last decade or so. However, the "real world deployment" thing is kind of a spectrum. There's definitely the super-tight provisioning/deployments with ec2/puppet/jenkins/etc, but it goes all the way down to "have debian and hand-install widgets". That seems to depend on the organization's willingness to buy into the "cloud" idea, which seems to be regulated by the leadership's comfort with software.

wglb 14y ago

So far as I know, Visual Studio won't show you the source code to length or read, whereas Lisp will.

KirinDave 14y ago
Except many popular, monder lisps still don't show you that. Native functions often can't be shown. Bummer, huh?
- wglb 14y ago
  I am speaking about SBCL, in particular; don't know about others. You can drill all the way down.
  - KirinDave 14y ago
    I think some primitives are still unexposed. Cons, if, etc?
    - wglb 14y ago
      Well, so far I can drill into if, cons, unless, let*, let.
      - PuercoPop 14y ago
        You can drill into the assembly code generated.
eropple 14y ago
You sure? I don't know if VS will by default, but (at least on my machine) it's installed under ${VS11}/VC/crt/src so I'm sure it's possible - not sure if it's the complete sources, though. Eclipse or IntelliJ will for Java if you install the JDK, though, and I'm pretty sure you can install the libc++ sources for XCode and go through them if you want (don't quite me on that though).