HackerTrans
TopNewTrendsCommentsPastAskShowJobs

trealira

1,226 karmajoined 3 lata temu

comments

trealira
·3 dni temu·discuss
> even GC isn't necessary

Um, isn't it? Don't all Lisp variants have it? IIRC McCarthy's LISP just ran out of memory until the GC was written.
trealira
·w zeszłym roku·discuss
> I'm not saying zero, I'm just saying null.

What would happent to the primitive types of that language, then? When I said that, I was thinking of languages like Go and Java, both of which implicitly initialize integers to 0, booleans to false, floats to 0.0, and references to nil or null. That's what I'm calling less user-friendly than disallowing variables that aren't explicitly initialized before being used in all branches.
trealira
·w zeszłym roku·discuss
I think it depends. Not having uninitialized variables by requiring the user to provide some value, as in expression-oriented languages, makes sense to me, because it wouldn't make sense in an expression for a variable not to have a value. An example of SML:

  1 + let val x = 1 in x * 2 end
That's both conceptually simpler and seems like one of the good solutions.

On the other hand, in languages where you don't have to explicitly initalize variables after declaring them, I think the best solution is to do flow analysis and forbid uses of uninitialized variables rather than implicitly set them all to null or zero. The latter solution just leads to confusing bugs if you ever don't initialize a variable in all branches (which is why I think that should be a compiler error). It's only a little better than C's solution of just letting the value be undefined, or in practice, a non-deterministic garbage value. An error message just seems more user-friendly, particularly for beginner programmers who are more likely to make mistakes like those and not immediately understand what the problem is.

I do get what you're saying about it being simpler, but I don't think it's conceptually simpler for the user to always initialize variables to zero or null.
trealira
·w zeszłym roku·discuss
Thanks for explaining. I guess that makes sense, but it surprises me: language implementors choosing to do the slightly worse option not due to technical limitations or historical baggage, but just because it's easier. I thought only C was like that. That's not to insult any of them; it's not like I'm the maintainer of a compiler for a major programming language.
trealira
·w zeszłym roku·discuss
This is a self-response, but I've thought of a case where it might be fairly difficult for a compiler to prove a variable is always initialized, because of the use of pointers. Take this function to copy a linked list in C:

  struct node {
      struct node *next;
      int data;
  };

  struct node *copy_list(struct node *list_node) {
      struct node *new_list, **indirect;

      indirect = &new_list
      while (list_node != NULL) {
          // Pretend malloc can't fail
          struct node *np = malloc(sizeof(*np));
          np->data = list_node->data;
          *indirect = np;
          indirect = &np->next;
          list_node = list_node->next;
      }
      *indirect = NULL;
      return new_list;
  }
The variable "new_list" is always initialized, no matter what, even though it's never explicitly on the left hand side of an assignment. If the while loop never ran, then indirect is pointing to the address of new_list after the loop, and the "*indirect = NULL;" statement sets it to NULL. If the loop did run, then "new_list" is set to the result of a call to malloc. In all cases, the variable is set.

But it feels like it would be hard for something that isn't a formal proof assistant to prove this. The equivalent Rust code (unidiomatic as it would be to roll your own linked list code) would require you to set "new_list" to be None before the loop starts.
trealira
·w zeszłym roku·discuss
Somehow Rust is able to do it, though. Is it really that hard for compilers to do flow analysis to detect and forbid uses of uninitialized variables? Not even being sarcastic, I genuinely would like to know why more languages don't do this.
trealira
·w zeszłym roku·discuss
Niklaus Wirth wrote about this in 1995, in his essay A Plea for Lean Software.

About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. (Modern program editors request 100 times that much). An operating system had to manage with 8,000 bytes, and a compiler had to fit into 32 Kbytes, whereas their modern descendants require megabytes. Has all this inflated software become any faster? On the contrary, were it not for a thousand times faster hardware, modern software would be utterly unusable.

https://www.computer.org/csdl/magazine/co/1995/02/r2064/13rR...

That said, as someone fairly young, I still don't think that makes it wrong or something only an old man would think. Software seems to perform exactly as well as it needs to and no more, which is why hardware advances don't make our computers run software much faster.
trealira
·3 lata temu·discuss
Yeah, I thought it was funny too, and upvoted it, but I guess more people disliked it than liked it.
trealira
·3 lata temu·discuss
> I'm not sure what the original estimate was, but I think it was intended to cost something like 200K for a year of operations, but we were now close to a million dollars.

> ...

> I return to work the following Monday. I suspected that this would save a bunch of money, and guess what, our projected bill dropped from a million to half a million dollars, and everyone is losing their fucking minds.

Wow, so they're still over budget by 300k dollars. This is a funny story, but the company sounds incompetent.