Saturated Fat Controversy

[Mermaid]

This thread confuses me.

[The Grand Nudger]

To be expected. OP is determinedly confused.

[FlatAssembler]

There is a reason why a less efficient 6 transistor structure MIGHT be chosen. Go learn stuff.

One of the first things we were told in our Digital Electronics classes was that AND, OR, NOT and XOR were considered basic ("osnovni") gates because they are implemented with 6 transistors, except for NOT which is implemented with 2 transistors. And, frankly, I am not interested in going much deeper than that, it's quite unlikely I'll have to do something that low-level.

Or shitty amateurish websites apparently.

That's not really the same thing. If you mess something up with UX, you will probably not immediately notice that, because UX is a softer part of computer science. Making a compiler or a PacMan game playable on smartphones is a more rigorous part of computer science: what you want to accomplish is quite well-defined and you can't reject it because you subjectively don't like the way it looks. Fine, maybe you can say you don't like GCC and that you like TCC more because GCC does many optimisations which slow down the compilation and that don't make the Assembly it produces significantly faster (hardly any programmer would agree with you, but it's not outright false), but you can't deny that GCC works just because you don't like something about it. And you can't deny that my compiler works, since there is evidence that it works (it can compile QuickSort written in my own programming language). Is it low-quality? Sure it is, the Assembly it produces is a few times slower than one produced by GCC for an equivalent C code, and the compiler itself runs slowly (running on top of the Duktape framework). But, frankly, I don't think you know enough about that to even evaluate those statements. Show me a compiler you've made, and then we can talk about your criticism of my compiler. Otherwise, you have no credibility.

[The Grand Nudger]

Coding is your safe space, huh? The place you scurry off to whenever you feel like you just might have made an ass of yourself. It's cool bro, we all have them.

lol

[LastPoet]

Coding is your safe space, huh?  The place you scurry off to whenever you feel like you just might have made an ass of yourself.  It's cool bro, we all have them.

lol

That's the thing really, he is not even good at that.

---

There is a reason why a less efficient 6 transistor structure MIGHT be chosen. Go learn stuff.

One of the first things we were told in our Digital Electronics classes was that AND, OR, NOT and XOR were considered basic ("osnovni") gates because they are implemented with 6 transistors, except for NOT which is implemented with 2 transistors. And, frankly, I am not interested in going much deeper than that, it's quite unlikely I'll have to do something that low-level.

You can make OR and AND gates with just 2 diods. A NOT gate only needs 1 transistor. Hence you can make a NAND gate with 2 diods and a transistor However, modern architecture uses more transistors simply because it provides faster gate response to keep it in sync with the CLK.

At any rate your prowess or lack of in CS lends you no credibility regarding the topic at hand. Just because you made an half arsed compiler, doesn't make you a biologist. You should know that.

[Abaddon_ire]

There is a reason why a less efficient 6 transistor structure MIGHT be chosen. Go learn stuff.

One of the first things we were told in our Digital Electronics classes was that AND, OR, NOT and XOR were considered basic ("osnovni") gates because they are implemented with 6 transistors, except for NOT which is implemented with 2 transistors. And, frankly, I am not interested in going much deeper than that, it's quite unlikely I'll have to do something that low-level.

Or shitty amateurish websites apparently.

That's not really the same thing. If you mess something up with UX, you will probably not immediately notice that, because UX is a softer part of computer science. Making a compiler or a PacMan game playable on smartphones is a more rigorous part of computer science: what you want to accomplish is quite well-defined and you can't reject it because you subjectively don't like the way it looks. Fine, maybe you can say you don't like GCC and that you like TCC more because GCC does many optimisations which slow down the compilation and that don't make the Assembly it produces significantly faster (hardly any programmer would agree with you, but it's not outright false), but you can't deny that GCC works just because you don't like something about it. And you can't deny that my compiler works, since there is evidence that it works (it can compile QuickSort written in my own programming language). Is it low-quality? Sure it is, the Assembly it produces is a few times slower than one produced by GCC for an equivalent C code, and the compiler itself runs slowly (running on top of the Duktape framework). But, frankly, I don't think you know enough about that to even evaluate those statements. Show me a compiler you've made, and then we can talk about your criticism of my compiler. Otherwise, you have no credibility.

When one can write machine code directly in native binary on multiple platforms, one learns that compilers are for the weak.

[GrandizerII]

One of the first things we were told in our Digital Electronics classes was that AND, OR, NOT and XOR were considered basic ("osnovni") gates because they are implemented with 6 transistors, except for NOT which is implemented with 2 transistors. And, frankly, I am not interested in going much deeper than that, it's quite unlikely I'll have to do something that low-level.
That's not really the same thing. If you mess something up with UX, you will probably not immediately notice that, because UX is a softer part of computer science. Making a compiler or a PacMan game playable on smartphones is a more rigorous part of computer science: what you want to accomplish is quite well-defined and you can't reject it because you subjectively don't like the way it looks. Fine, maybe you can say you don't like GCC and that you like TCC more because GCC does many optimisations which slow down the compilation and that don't make the Assembly it produces significantly faster (hardly any programmer would agree with you, but it's not outright false), but you can't deny that GCC works just because you don't like something about it. And you can't deny that my compiler works, since there is evidence that it works (it can compile QuickSort written in my own programming language). Is it low-quality? Sure it is, the Assembly it produces is a few times slower than one produced by GCC for an equivalent C code, and the compiler itself runs slowly (running on top of the Duktape framework). But, frankly, I don't think you know enough about that to even evaluate those statements. Show me a compiler you've made, and then we can talk about your criticism of my compiler. Otherwise, you have no credibility.

When one can write machine code directly in native binary on multiple platforms, one learns that compilers are for the weak.

Do you still do this manually? Sounds like a lot of effort to do. That's like someone still doing trig tables manually to this day.

[FlatAssembler]

When one can write machine code directly in native binary on multiple platforms, one learns that compilers are for the weak.

Do you still do this manually? Sounds like a lot of effort to do. That's like someone still doing trig tables manually to this day.

It's not just about time. It's perhaps even more about the fact that programs written in Assembly (or, even worse, machine code) tend to be very buggy. If a Haskell program compiles, it probably works. If an Assembly program compiles, chances are, it crashes before even starting to do what it's supposed to. And Abaddon_ire claims that he or she is writing encryption software in Assembly and machine code. Well, chances are, if he or she is really doing that, those programs are very insecure both because they are buggy and because they are almost impossible to review by cryptography experts. Abaddon_ire has given me every reason to think he or she doesn't know what he or she is talking about. Why would a program that can translate 200 lines of code into Assembly, implementing QuickSort or the Permutations algorithm, be "not a compiler in any shape or form"? OK, maybe I went too far when I said you should show me a compiler you made or contributed to gain credibility to claim my compiler is worthless. But claiming that you are making encryption software in Assembly and machine code certainly isn't helping your credibility.

---

One of the first things we were told in our Digital Electronics classes was that AND, OR, NOT and XOR were considered basic ("osnovni") gates because they are implemented with 6 transistors, except for NOT which is implemented with 2 transistors. And, frankly, I am not interested in going much deeper than that, it's quite unlikely I'll have to do something that low-level.
That's not really the same thing. If you mess something up with UX, you will probably not immediately notice that, because UX is a softer part of computer science. Making a compiler or a PacMan game playable on smartphones is a more rigorous part of computer science: what you want to accomplish is quite well-defined and you can't reject it because you subjectively don't like the way it looks. Fine, maybe you can say you don't like GCC and that you like TCC more because GCC does many optimisations which slow down the compilation and that don't make the Assembly it produces significantly faster (hardly any programmer would agree with you, but it's not outright false), but you can't deny that GCC works just because you don't like something about it. And you can't deny that my compiler works, since there is evidence that it works (it can compile QuickSort written in my own programming language). Is it low-quality? Sure it is, the Assembly it produces is a few times slower than one produced by GCC for an equivalent C code, and the compiler itself runs slowly (running on top of the Duktape framework). But, frankly, I don't think you know enough about that to even evaluate those statements. Show me a compiler you've made, and then we can talk about your criticism of my compiler. Otherwise, you have no credibility.

When one can write machine code directly in native binary on multiple platforms, one learns that compilers are for the weak.

I think that writing some program in Assembly or machine code takes almost entirely different set of skills than writing a compiler. To write some program in Assembly or machine code, you most likely don't need to know anything about tokenizing, anything about parsing or anything about representing trees in memory and writing algorithms to convert ASTs into Assembly code (a naive left-child-right-child-parent algorithm leads to stack overflow even for relatively short expressions), and so on.

---

To give you some context about why that "I can write programs in Assembly, so of course I could make a good compiler." sounds silly, I was able to write a 800-lines-long program in Assembly back when I was 14.

---

Coding is your safe space, huh? The place you scurry off to whenever you feel like you just might have made an ass of yourself. It's cool bro, we all have them.

lol

Well, you claimed I have probably never done any substantial amount of research by myself. And, since you know something about computer science, you can see I have if I show you the compiler I've made. If you know something about linguistics, I can also bring up my alternative interpretation of what the names of places in Croatia mean.

[Abaddon_ire]

Do you still do this manually? Sounds like a lot of effort to do. That's like someone still doing trig tables manually to this day.

It's not just about time. It's perhaps even more about the fact that programs written in Assembly (or, even worse, machine code) tend to be very buggy. If a Haskell program compiles, it probably works. If an Assembly program compiles, chances are, it crashes before even starting to do what it's supposed to. And Abaddon_ire claims that he or she is writing encryption software in Assembly and machine code. Well, chances are, if he or she is really doing that, those programs are very insecure both because they are buggy and because they are almost impossible to review by cryptography experts. Abaddon_ire has given me every reason to think he or she doesn't know what he or she is talking about. Why would a program that can translate 200 lines of code into Assembly, implementing QuickSort or the Permutations algorithm, be "not a compiler in any shape or form"? OK, maybe I went too far when I said you should show me a compiler you made or contributed to gain credibility to claim my compiler is worthless. But claiming that you are making encryption software in Assembly and machine code certainly isn't helping your credibility.

---

When one can write machine code directly in native binary on multiple platforms, one learns that compilers are for the weak.

I think that writing some program in Assembly or machine code takes almost entirely different set of skills than writing a compiler. To write some program in Assembly or machine code, you most likely don't need to know anything about tokenizing, anything about parsing or anything about representing trees in memory and writing algorithms to convert ASTs into Assembly code (a naive left-child-right-child-parent algorithm leads to stack overflow even for relatively short expressions), and so on.

---

To give you some context about why that "I can write programs in Assembly, so of course I could make a good compiler." sounds silly, I was able to write a 800-lines-long program in Assembly back when I was 14.

---

Coding is your safe space, huh?  The place you scurry off to whenever you feel like you just might have made an ass of yourself.  It's cool bro, we all have them.

lol

Well, you claimed I have probably never done any substantial amount of research by myself. And, since you know something about computer science, you can see I have if I show you the compiler I've made. If you know something about linguistics, I can also bring up my alternative interpretation of what the names of places in Croatia mean.

For fucks sake. Writing one's own compiler is a noob first year assignment. Grow up.

Your big mistake was revealing your naive attempt at a website. That told everyone that you are clueless.

When you have written software that transacts millions in secure encrypted CC interchanges get back to me.

You are hung up on the stupid notion that machine code is of neccessity more prone to bugs. That is false. If you had a foggiest clue about any of it, you would understand why that is, but you don't. That fact reveals even more.

[FlatAssembler]

Writing one's own compiler is a noob first year assignment.

It just isn't. The hardest part of the first year of studying computer science here at the FERIT University of Osijek is probably understanding the methods of manually solving the three-phase electrical networks and the stuff such as Millman's Theorem and the Norton's Theorem. The hardest part of programming is probably understanding the basic string manipulation in C, or as some students who failed programming complain that linked lists were hard to understand.

Your big mistake was revealing your naive attempt at a website. That told everyone that you are clueless.

After I had been studying programming by myself for 5 years, my attempt at making a website can hardly be called "naive" and "clueless".

When you have written software that transacts millions in secure encrypted CC interchanges get back to me.

Then give us some explanation of how it works.

You are hung up on the stupid notion that machine code is of neccessity more prone to bugs.

It's the most basic common sense. I know from experience that, when I program something in Assembly, I spend way more time debugging than actually coding. And programming in machine code is even worse, since it's like Assembly, but it also gives you a chance to accidentally insert an illegal instruction. Or to reference a wrong variable without noticing that when reviewing the code, which a symbolic Assembler won't allow you to. And if there are so many bugs which prevent an Assembly language (or, even worse, a machine language) program from even appearing to work properly, how many bugs are there that need to be fixed until it actually works properly?
And there are statistics that show that, of higher-level languages, C programs tend to be the most buggy, and C is, compared to other high-level languages, quite close to Assembly in many ways. JavaScript programs are, if I am not mistaken, around 3 times less buggy, and there are so many bugs in JavaScript programs because the developing tools for it tend not to even issue warnings for what would be a syntax error in other languages. PHP programs also tend to be buggy, though not as much as JavaScript programs. C++ programs tend to be way less buggy, and Haskell and SmallTalk programs even less.