101–110 of 159 posts
Earlier quoted context omitted.
Ok, but that’s sw engineering issue. I still insist that a production grade compiler can’t leave performance on table. Which is where the current battlefield is.
I do not agree in the general case. There are very useful DSL compilers which do not consider performance at all, but just compile to a target which does the optimization for them (JVM, LLVM IR or even just C)
Earlier quoted context omitted.
I guess I wasn't very clear. I didnt mean to say, as a historical matter, were irrelevant. I meant to say the idea of a parser generator is a solution to a problem that that real world langs don't really have. When writing a programming language, your issue isnt how much time the parser is going to take to write, or how complex it's going to be. The parser is a relatively trivial part of the problem. Due to language…
The one thing parser generators do is that they ensure that the language you implement actually matches the grammar you wrote. That’s still an important assurance to have.
Earlier quoted context omitted.
if you aren't running on the gpu you're leaving 80+% of your computer's performance on the table. no optimizing compiler is going to make your legacy c or lisp or rust code run efficiently on the gpu, or even in most cases on a multicore cpu. nor, as thechao points out, can it compete with assembly-language programmers for simd vectorization on the cpu in summary, optimizing compilers for c or pascal or zig or rust o…
How come you made this about computer’s performance :)
Earlier quoted context omitted.
I think a production grade compiler not only can, but must, leave performance on the table when the cost is correctness (unless the performance gain is incredibly high and the correctness loss is minimal). Correctness is not all important, but it is the most important thing. Unfortunately, compiler writers do not agree and they do silly things like "let's assume UB cannot ever happen and optimize based on that".
Correctness is already a must, how did you arrive to this?
Earlier quoted context omitted.
The one thing parser generators do is that they ensure that the language you implement actually matches the grammar you wrote. That’s still an important assurance to have.
I've created many programming languages. All the ones I finished and were useful did not have grammars that "I wrote".
maybe you're talking about stuff you haven't released?
Earlier quoted context omitted.
I really really really want to get more into Ocaml but as far as I know there is no good support for a debugger to use in an IDE like VSCode or even vim. Everyone I talk to says they just do print debugging. It's easier to 'reason about your code' in FP, but I do NOT want to go back to a time where I coded without breakpoints. I use F# because of its first party tooling support
it does have a debugger with breakpoints, which even supports time-travel debugging (except on windows obviously), but i've never used it. it even has first-party ide integration: https://ocaml.org/manual/5.2/debugger.html#s:inf-debugger i use debuggers a lot when i'm programming in assembly, and from time to time when i'm programming in c or c++, but in ocaml i've never needed one. it's not that i've never had bugs…
1. I am developing on windows so that's an issue for me and
2. I don't use emacs, I use VScode and I've not been able to get the experimental debugger working for the VScode plugin.
It's not that the debugger is purely for fixing bugs; I use it as an active part of development. I want to be able to freeze the program and inspect values as they are running. I may know what the types or state of the program are just by viewing the code, but I want to be able to inspect the actual data for myself as the program is running.
> debug logging shows you the whole history of your program's execution rather than just a single point in time
breakpoints also provide stack traces, so they provide a kind of history as well. I'd rather inspect and interact with a program than dig through thousands of lines of logs
> breakpoint debugging requires a lot of manual labor, painstakingly operating the machine to navigate the execution to the state that has the problem
I see things the opposite as you: print debugging is tedious and requires restarting the program from the beginning whenever you make a change to the source, unless you are constructing your program piecemeal with the repl, which I consider to be extremely tedious as well. To me, a debugger with breakpoints is a far more efficient way to code than print debugging.
I think there is a cultural difference in software engineering between people who use debuggers and people who don't. John Carmack once pointed out that people who come from the game dev and Windows/PC world use debuggers while people from the linux and web dev world tend not to. It seems to be a matter of preference/taste, and I think FP programmers seem to have a distaste for debuggers and graphical debugging/development environments
Earlier quoted context omitted.
The one thing parser generators do is that they ensure that the language you implement actually matches the grammar you wrote. That’s still an important assurance to have.
I've created many programming languages. All the ones I finished and were useful did not have grammars that "I wrote".
I wonder why there is not the same book for c++... mmmmh... I really wonder... (irony).
Earlier quoted context omitted.
How come you made this about computer’s performance :)
because computer performance is the topic of https://news.ycombinator.com/item?id=41255695 , https://news.ycombinator.com/item?id=41255365 , and https://news.ycombinator.com/item?id=41255195 , the three levels of parent comments in the thread, one of which was by you
Main post is about a C compiler, post I responded is saying
> When your computer was anemic, and could barely do the tasks required for it
which I could only interpret as a machine that can run a single process at a time, so not really about gpus or what.
Earlier quoted context omitted.
Correctness is already a must, how did you arrive to this?
if only the gcc and llvm maintainers, and c standard authors, agreed with you