Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To nitpick on a single statement:

> C has the fastest development interactivity of any mainstream statically typed language.

What? Despite all its shortcomings, Java in a modern IDE effectively has zero build time. The level of interactivity is as fast as that of interpreted languages. I haven't seen anyone manage this with C yet.



Agree completely about zero build time!

I've been using IntelliJ IDEA for Java development for the last 4 years, and before that I used C and C++ using Emacs for 7 years.

I am way more productive in IntelliJ IDEA than I was before. One reason is the instant feedback on syntax errors when I type the code. I don't need to compile to see them, as I used to in C and C++. Another reason is the navigation support you get in an IDE.

I've written more about the differences in development environment here: http://henrikwarne.com/2012/06/17/programmer-productivity-em...


That's the IDE not the language.

Java, itself, does not highlight your syntax errors. Nor does C.

There are IDEs out there that will do exactly the same thing for you for your C code.


The difficulty of writing static analysis software does depend on the language, though. In Visual Studio, for example, intellisense and autocompletion are vastly superior in C# compared to C++.

As a matter of interest, which C IDEs are you referring to? I'd like to check them out.


Try Xcode 4.5.x (wich uses Clang as the default C compiler).

VS2012 has similar capabilities for C++.


VS2012 is actually the IDE I was thinking of when I said VS C++ support is inferior to C#'s. While there is intellisense, it does not display any documentation. The closest thing it offers is variable names for a method's arguments.


In fact Eclipse features a special compiler that builds your code immediately and also allows IDE to highlight your errors better than any static analysis would. So actually it kind of does. Assuming compiler IS the language.


Eclipse+CDT provides some of the same features as well. Very useful :)

http://www.eclipse.org/cdt/


Emacs can do this with Flymake. I would stick with IntelliJ, though.


I have worked on several projects in Java (using Eclipse as an IDE). In my experience there is a 'significant' latency between when I hit run, and my program starts. (My suspicion is this time is spent starting the JVM, not compiling).

Every (non kernel) C project I have worked with has effectively 0 build time after making changes. This is because they all used make which (like Eclipse and likely all IDEs) only recompiles the files you changed. However, there is not the startup time of the VM (which for every non Java VM I have seen is also effectively 0.)

As an aside, does anyone know why Java has an unusually high startup time?


Regarding why Java has a high startup time, here's Wikipedia's take on the matter: https://en.wikipedia.org/wiki/Java_performance#Startup_time


> Every (non kernel) C project I have worked with has effectively 0 build time after making changes.

For trivial changes maybe. Rebuild time will depend on the size/complexity of the project and the number of dependencies on the thing that was changed.

A change to a header file of a core library may cause a rebuild of many parts of the project thanks to dependencies built on header files. We have such a library in our product and modifying a single file can cause ~40% of the product to need to be rebuilt.

Think about changing something like:

     #define VERSION "1.2.3"
which is compiled into every library and binary within the product.


As a tip I suggest running your code in debug mode. Which allows you to rewrite method contents as the program is running. If you place a break point in the method you are working in every time you save the program will reenter the method. I usually work in this mode.

JRebel is also worth investigating if you are getting paid to work with java code.


C and Java both have terrible productivity loops because they have a tedious compile step. Python you just run after editing. I was more productive in python using a test editor the very first week I learnt it than I ever was in Java or C++ even with IDE support and years of experience. Google App Engine python dev server reloads modified python files whithout server restart. That feature blew my mind after doing Java EE stuff (although that experience is 8 years old so maybe new Java servers can do this??). Talk about productivity!


Having a REPL is a big productivity boost for Python, not avoiding an explicit compile step. A compile step is utterly trivial to avoid (e.g. "make run" which builds and runs). Likewise, live reloading is possible in C using dlopen().


Yes modern java servers do this (if configured to do so of course).


At the risk of sounding like that guy, isn't this property of all Smalltalk descended languages?

And I mean on the basic language level, not "using a library to run a hot swap VM for my language" level like Eclipse and IntelliJ IDEA do.


I'd rather have a Repl than a "modern IDE".

C does not have or need a Repl because it's not designed for giant single programs anyway. Unix is the C Repl.


CERN researchers don't share your opinion:

http://root.cern.ch/drupal/content/cint


How is a unix shell going to help me debug the internals of my C program? You can use gdb from a terminal of course (yet another giant single program, funny how many of those I use every day…) but it's much more of a pain than a real REPL.

I noticed in another comment you said you are just learning C, perhaps you should wait till you have written non-trivial C before you declare what tools one does or does not need when writing it? C makes it very easy to make very nasty mistakes, so personally I take all the help I can get. I guess this means you think I'm an awful developer (according to your recent anti-IDE blog post), but I'd rather have code with less bugs than worry about violating some notion of 'purity' or hacker-hardcorness.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: