What languages do people prefer to code in?

I can write one line programs in python too. I did my c assignments in about 20% of the code that the assignment said it would end up being. I took a look at it and rewrote it to what the assignment told me was a good length. Why? You honestly can't maintain that code. Just cos you can do it in one line doesn't make it better, but anyway that's not the point of this thread is it. I forget it.

 

I'm glad someone has said something I agree with

 

I'm glad I was taught Haskell. It was a fundamental learning block in thought patterns for me. Infinite lists still blow my mind though.

 

I think Objective-C is great

If you like python, you would probably like Objective-C.

 

Lisp serves an extremely important part of AutoCad software, hence it is useful. I know this how? my olde man uses AutoCad for mechanical drawings.

 

Nonsense! I just had a quick look at some of my code, and there are places where there are ten indentations deep. That is a result mainly of the mathematical algorithm (7 do loops deep), but also of special case code in if blocks and the usual indentation for routines.

Regards,
Daniel.

 

I agree that if you're indenting that much, you should be dividing code into functions. even if you didn't want to, you could just use 1 or 2 spaces for indenting, that's perfectly legal in Python

 

I deliberately didn't break it up into functions because I did try it and the performance hit was too great. The routines I mentioned are already in four do loops and several if statements deep - the overhead of function calls is very significant, and the optimising compilers I tried didn't do a good job of inlining.

I didn't know you could use spaces for indenting in Python, it sounds ok then .

Regards,
Daniel.

 

I didn't say that Haskell was implemented on phones. Ericson do a fair bit more than phones, too (IC's and such).

 

Now I get what you ment.

 

You got it!

myFunc != myFunc

...in many languages. For example, calling a function that increments, say, a global variable by one, calling it twice will not return the same thing!

A beautiful example, pulled from the haskell.org site, is the following comparison between quicksort in haskell and C:

Code:

qsort []     = []
qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x
                 where
                   elts_lt_x   = [y | y <- xs, y < x]
                   elts_greq_x = [y | y <- xs, y >= x]

Code:

qsort( a, lo, hi ) int a[], hi, lo;
{
  int h, l, p, t;

  if (lo < hi) {
    l = lo;
    h = hi;
    p = a[hi];

    do {
      while ((l < h) && (a[l] <= p)) 
          l = l+1;
      while ((h > l) && (a[h] >= p))
          h = h-1;
      if (l < h) {
          t = a[l];
          a[l] = a[h];
          a[h] = t;
      }
    } while (l < h);

    t = a[l];
    a[l] = a[hi];
    a[hi] = t;

    qsort( a, lo, l-1 );
    qsort( a, l+1, hi );
  }
}

Plenty of things have been written in Haskell too. Quake has even been ported to it, which is really amazing. Imagine having to write quake recursively without any variables

 

It might be important to point out that less code does not always imply better code. There are many examples where extra code improves the efficiency of the algorithm significantly.

Also, isn't there a quicksort routine in the C standard library? (it's been a while).

 

Thats true, although which of the above would you prefer to debug?

Because Haskell (and other functional languages) are so 'pure', their compilers are able to do much more optimisation. For example, doing a simple recursive factorial function under Haskell, and asking it to do 1000!, it'll spit it out almost immediately.

And since every function you write under Haskell is recursive...

 

Personally I'd prefer the debug the second one as I can stop it exactly where I want it. Although some people might prefer the other.

I wouldn't make a habit of relying on compilers for optimisations. There's some pretty sucky ones out there. I guess it depends on the application.

 

did you give inline functions a go and if so was it still sucky performance?

 

Yeah tried that, but is usually best to inline it yourself. Take an example of inlining a function that uses a fixed-size large temporary array inside a do-loop. A good compiler would inline the code and see that the memory could be allocated only once and outside the loop. It could then go on to arrange the variables in memory for better cache hits etc. Which compilers can do all this? I don't know and don't want to know the details of every compiler. Instead, I assume the worst and make it as easy as possible for a compiler to work out what to optimise, and trust them to do their own custom optimisations like loop blocking, vectorisation etc.

Compile times and memory usage go up too if you tell the compiler to do inlining, because they try to inline most small functions. Some compilers have switches to specify which functions to inline, but that's just messy.

I don't remember performance benefits with just compiler inlining as it was years ago when I played around with it. I did a lot of stuff over a few years to get performance up, but it was a mixture of special case code and inlining, more the former. I ended up with over an order of magnitude speed up, using Lahey Fortran (which does not produce particularly fast code). The Intel compilers probably does a better job. It's a nice feature, but I think it is safest to assume this feature does not exist.

Regards,
Daniel.