jwhite

I'm with you.

I once spent days trying to figure out why a 10 hour timer on a battery charger chip was going off hours too early, leading to the device draining its battery instead of charging it. Turned out the manufacturing partner had substituted another part, functionally equivalent except for the one feature we were relying on...

I can't remember what it was that made me actually look at the chip to check the part number.

Thanks for the reference, I'll have to find a copy.

Generally agree, but I think that by 1880 the British had finally come to their senses and given up on Arctic exploration. Franklin's expedition [0] was 1845 - 1848 or so, and the subsequent extensive searches for him into the 1850s provided a lot more knowledge of the geography, but they seem to have also made everyone finally confront the futility of the task. The British Admiralty didn't fund another expedition until 1875-1876 when the Nares expedition to reach the North Pole failed [1], and the general conclusion was that there was no Open Polar Sea. They gave up on Arctic exploration after that.

So maybe shift 1880 back to 1840.

[0] https://en.wikipedia.org/wiki/Franklin%27s_lost_expedition

[1] https://en.wikipedia.org/wiki/British_Arctic_Expedition

EDIT: formatting

There's a worse problem, which I've seen in the wild:

    int some_function(...);

    int some_other_function(...)
    {
       int r = -1;
       /* imagine a bunch of other locals defined here */

       r = some_function(...);
       if (-1 == r)
       {
           return -1;
       }
      
       ...
    }

Now imagine someone changes the return type of some_function():

    char *some_function(...);

    int some_other_function(...)
    {
       int r = -1;
       /* imagine a bunch of other locals defined here */
       char *s;

       s = some_function(...);
       if (-1 == r)
       {
           return -1;
       }
      
       ...
    }

Oops! Every other reference to r has been removed except the declaration and the test. Now some_other_function() will always take the early exit, and because r is initialized in its definition the compiler does not complain. (In real life, hilarity ensued.) If it was 'int r;' with no initializer this would have been caught by the compiler.

Modern gcc is great at finding uninitialized and unused variables. -Wall -Wextra -Werror FTW.

EDIT: referred to some_function() where it should have been some_other_function().

I guess parent is just saying that macros allow programmer control of evaluation order, which you can't get otherwise in a strict language, but you can with laziness.

The point could have been worded better I think.

GDB mostly works for x86. I used to swear at GDB many times daily when using it to debug an embedded ARM target with openocd a few years ago.

Very frustrating when it crashes just as you've got the target into the state where you think your bug will trigger. And then GDB repeats the performance reliably for you... On those days you end up resorting to a lot of creative thinking.

It seems true on OS X and Linux. I'm not sure if it's 100% statically linked, or if it depends on a particular version of glibc on Linux. Edit: I would check, but I'm not close to a linux box.

I haven't tried it on Windows.

The download instructions say it depends on libffi, libgmp and zlib, which I didn't realise, plus some other tools (gcc, etc.) which I assume are for building packages that wrap C libraries.

http://docs.haskellstack.org/en/stable/install_and_upgrade/#...

Haskell's stack tool is aiming for something like this. All you need is the stack binary. stack will download GHC for you at a given version, and fetch your dependencies for you. The dependencies are locked to a fixed snapshot of versions. There are curated snaphots, with an LTS model that guarantees all packages in the snapshot work together, so you're insulated from package authors randomly breaking API compatibility on you, and you can upgrade to newer LTS snaphots when you're good and ready.

http://docs.haskellstack.org/en/stable/README/

It doesn't change the conclusion, but note that in a relativistic regime you can't use F=ma because the mass is no longer constant. You need F=dp/dt, where p is the relativistic momentum. The Lorentz factor here works out to 1.02, i.e. 510 N, not 500, so not a big effect if I got my maths right.

... and now you have two problems.

Looks neat. When I searched for 'common lisp' I got a nice tree of CL standard library functions and macros, etc.

When I searched for 'haskell' I got this:

    'undefined method `each' for nil:NilClass'

Plus a big stack trace.

:-)

I think a lot of the posters supporting Telegram in this discussion here are astroturfers.

I think we can excuse you, given that the boat was _literally_ netting quite a lot of money... in the form of fish :-)

I myself don't mind if you make such comments. It can be important to question people's motives for saying things (politicians, for instance). However, as another data point for you though, and not knowing anything about Dave Winer before today, when I read the Marissa Mayer article I didn't have the impression of any self-aggrandizement.

Your mileage varies, obviously.

I think they described their clients as muppets, not puppets: http://www.nytimes.com/2012/03/14/opinion/why-i-am-leaving-g...

To elaborate on what tedunangst said, for those less experienced with C:

To some extent it's a matter of nomenclature, but one can draw a distinction in C between arrays of arrays and 2D arrays. It does matter. The following is an array of arrays of ints (a "ragged array" as tedunangst mentioned), if I malloc an array of pointers to ints and then add a loop that mallocs an array of ints for each a[i]:

  int **a;

  a = malloc(N * sizeof(a[0]));
  int i;
  for(i = 0; i < N; i++)
  {
      a[i] = malloc(M * sizeof(a[i][0]));
  }

Then a[i][j] picks out a single int from the array of arrays. The layout in memory is then like this:

      +--+--+--+-       -+--+
  a:  |  |  |  |   ...   |  |   (array of pointers to arrays of ints)
      +--+--+--+-       -+--+
        |   |
        |   |
        |  +--+--+--+-       -+--+
  a[0]: |->| 1| 2| 3|   ...   |  |  (array of ints)
           +--+--+--+-       -+--+
            |
            |  +--+--+--+-       -+--+
  a[1]:     |->|41|42|43|   ...   |  |  (array of ints)
               +--+--+--+-       -+--+
    .
    .	
    .

Note that you cannot rely on these arrays to have any relationship with each other in respect to their positions in memory. That's entirely up to malloc(3).

However, the following is a 2D array of ints:

  int a[3][4];

The same syntax as before can be used to pick out one of the ints in the 2D array: a[i][j]. But this time the C standard gives us that this object is laid out in memory in row-major order. So if you initialize it like this:

  int a[3][4] = { {1, 2, 3, 4}, { 5, 6, 7, 8 }, { 9, 10, 11, 12 } };

then its memory layout looks like this:

      +--+--+--+--+--+--+--+--+--+--+--+--+
  a:  | 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|
      +--+--+--+--+--+--+--+--+--+--+--+--+
        ^        ^  ^        ^  ^        ^
        |__a[0]__|  |__a[1]__|  |__a[2]__|

This means you can index it manually like this:

  int x = *((int*)a + i * M + j);

where M is the length of each row, in this case M==4. You can't do that with the ragged array-of-arrays.

Exercise: try taking sizeof(a) in both cases, as suggested in the grandparent.

Exercise: 3D arrays?

For those who missed it, this is the most important paragraph in the article:

"It's a tablet Christmas there's no doubt about that," said Ben Mcintosh, general manager of technology and entertainment at Harvey Norman. "There is no doubt in my mind that we will sell out of just about every tablet we have in stock by the end of the month."

I'd better go out and get mine before they run out!

See: http://www.paulgraham.com/submarine.html

If his ideas offend you, you should rebut them, rather than making such an uncouth, sweeping value judgement.

Link to homepage is a nice convenience to people who land on your site somewhere other than the homepage (e.g. via a search result).

Thanks!

I agree. What would you recommend as a good modern book on software estimation?

There's also the fact that the ability to discern two colours depends on the two shades involved, and the shades that nature presents are probably different to the ones chosen by Faber-Castell. Also, when I was a kid I could tell the purple pencil from the blue if I held them together, but had trouble if I had just one on its own. (Still true today but I don't come across colour pencils so often...)

Duplicate: http://news.ycombinator.com/item?id=4273724

There's also Aquamacs for emacs fans.

Shake [1] is a Haskell library for writing build systems. I've been trying it out on a small side project lately. It isn't mature so it doesn't do everything you want, but the approach of supplying a library of build system construction tools instead of forcing you into a more rigid framework and/or DSL gives one a lot of flexibility. It seemed interesting and novel to me, but I don't know if it has been done before or not.

Not having a configuration system is a big drawback, enough to make me consider using autoconf in conjunction with Shake. Also you have to know Haskell, which will turn a lot of people away.

[1] http://hackage.haskell.org/package/shake

A friend once took a 30 minute car ride with two successful people, both multimillionaires, back when that meant something. He asked them how much money they would need to feel financially secure. By the end of the trip they had bid each other up so far that they agreed that it would take a large multiple of their current net worths, just to feel truly safe and independent enough to retire.

How do they qualify the devices coming out of China without running firmware on the manufacturing line?

They're not altogether useless. They keep the sun off your face and neck, which can be very useful in some climates. In Australia, where I live, a hat is now a compulsory part of every school child's uniform, and they are expected to be worn in the playground, because we have very high rates of skin cancer here. I don't know if that will translate into adult fashion or not. It might be too early to tell.

I suspect watches may diminish but will always be around because they signal status in a way that hats don't.

Thanks for your comment and link, I'll read it tomorrow. As to choice-free supermarkets, isn't Aldi somewhere in the ball-park of choice-free shopping?

> > For obvious reasons, that’s not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard.

> I don't know. Doesn't most of the programmers program to a particular scheme or lisp implementation(sbcl, racket, clozure, gambit, clojure)?

Common Lisp libraries seem to be getting much more portable across implementations, so within the CL dialect the language implementation is becoming less of an issue I think. And QuickLisp is one counter point to the OP -- it has broad community support.