71–80 of 93 posts
> Real Hackers have also known, for a while, that C and C++ are not appropriate for most programs that don't need to do arbitrary bit-fiddling. Strongly disagree with this statement. I've read it so many places now that it has to be a meme. I actually wish I could use C++ on the web instead of this JS nightmare ecosystem. I don't understand where the idea comes from. I'm never "bit-fiddling" in C++ and almost never n…
OP posted despite the opening paragraph! > Update on October 6, 2017. N.B.: Please stop submitting this to Hacker News! Look at the Hacker News search results for this essay. Check out the note for the first entry: Come on, everyone! Let's beat the dead horse one more time! Past discussions https://hn.algolia.com/?query=The%20Lisp%20Curse&type=story&...
Dunno, I've been on HN since 2007 and this is the first time I've seen this story.
I wonder why the author is upset about the posts. Does it generate too much costly traffic? Do they receive a lot of e-mail because of their essay?
Check out https://github.com/factor/factor. Check out how much stuff they have implemented early on, just 2-4 guys tops. I found it really impressive.
Earlier quoted context omitted.
Yeah, I agree. If you're willing to use a garbage collection library [0], you can even have a pleasant syntax for ObjectiveC style OOP in C: var result = call(foo, "bar: %s boo: %f", baz, hoo); The garbage collector will pick up the stray memory and release other resources (files) as needed, and all the standard compilers will check the varargs format string for you. Dynamic typing, arbitrary messages, and no memory…
Why do you need GC to support this syntax? The syntax has nothing to do with whether or not the semantics of the language permit memory leaks.
call(
window, "draw: %d %d %p", x, y,
alloc("Circle radius: %d color: %u", r, 0xFF0000)
);
This is all in response to the article claiming you "need to be Bjarne Stroustrup to add OOP to C, but it's a sophomore assignment to add it to Lisp". If I hadn't mentioned the GC, someone else would've jumped on the example for how unpleasant manual memory management is in comparison to Lisp.
Earlier quoted context omitted.
Why do you need GC to support this syntax? The syntax has nothing to do with whether or not the semantics of the language permit memory leaks.
You don't need the GC of course, but manually tracking and releasing the memory takes all the fun out of this kind of high level programming, particularly when you start to nest expressions. As a hypothetical example: call( window, "draw: %d %d %p", x, y, alloc("Circle radius: %d color: %u", r, 0xFF0000) ); That ignores the return value and loses track of the temporary argument. This is all in response to the article…
> If you're willing to use a garbage collection library [0], you can even have a pleasant syntax for ObjectiveC style OOP in C:
That sounded to me as if you were claiming that GC is a pre-requisite for having a particular syntax. But I gather that's not what you meant. I'm still a little unclear about what you actually meant. You can have memory leaks like the one in your example above in vanilla C without any OOP features at all. GC is completely orthogonal to OOP, and both are completely orthogonal to syntax.
otherwise, he speaks from my heart. social issues only
Earlier quoted context omitted.
You don't need the GC of course, but manually tracking and releasing the memory takes all the fun out of this kind of high level programming, particularly when you start to nest expressions. As a hypothetical example: call( window, "draw: %d %d %p", x, y, alloc("Circle radius: %d color: %u", r, 0xFF0000) ); That ignores the return value and loses track of the temporary argument. This is all in response to the article…
I was responding to this: > If you're willing to use a garbage collection library [0], you can even have a pleasant syntax for ObjectiveC style OOP in C: That sounded to me as if you were claiming that GC is a pre-requisite for having a particular syntax . But I gather that's not what you meant. I'm still a little unclear about what you actually meant. You can have memory leaks like the one in your example above in v…
var temp = alloc("Circle radius: %d color: %u", r, 0xFF0000);
var ignored = call(window, "draw: %d %d %p", x, y, temp);
drop(ignored);
drop(temp);
I just wish more people understood that something being Turing Complete isn't a feature, it's a flaw.
Turing completeness may be a flaw, but it is nearly impossible to avoid.
I just wish more people understood that something being Turing Complete isn't a feature, it's a flaw.
How so?
Note that you can still build useful programs this way since such languages can still allow certain forms of recursion such as primitive recursion, structural recursion etc... You can also use sized types [1] to allow even a larger set of (halting) programs.
[1] This is a way of compiler statically analyzing the size of each type (i.e. how many recursive constructors necessary) which puts an upper bound on the number of recursions need to be performed.