D is not a language that requires GC for its basic functionality. It is built into the language, yes, but it is not required and can be turned off - either in whole or in part. In other words, you can write a program that has no GC, and you can also write a program that only uses GC in some classes or even some fields of a class.
C is really awesome for some things, but modern languages allow people to "get stuff done quickly", much quicker than in C. The C language syntax is a little quirky - for example, the extern keyword means completely different things in different contexts. There's no need for a -> operator; the . operator should be overloaded (this one is a matter of opinion, of course). Finally, garbage collection: writing programs and not worrying about memory and ownership is an awesome thing.
Also, the C preprocessor is an awful programming language concept - more specifically, textual macros are. (See the D language for reasons why, and how to get around them... in a nut shell, you can use static constants, functions, etc., to do what macros do)
First we got told that writing person.name = "John" is bad. Bad, bad, bad. I never understood why. Sure, getters and setters are very useful, beans and all, and it can take away some trouble, but if you really need a function that does more than change the value of field x, why call it setX()?
Anyway, that's the current practice: getX() and setX(), and sometimes they don't get x, or set x, but just pretend.
I also used to think making accessor methods was an unnecessary burden when writing code. But time and time again, I have ended up having to refactor the public properties into getters and setters. Not every time, mind you, but it's caused enough problems to make it worth my while to use accessor methods every time now. It's "wisdom" and "experience" and I really can't give you a good explanation of why. I know that it's been useful to be able to add contracts to setters, such as "throw an exception if this isn't a valid state". Thinking about it now, I probably would say that setters are much more useful than getters... but in Java there's no way to make a class's field public for reading and private for writing.
Note that I'm only speaking for Java - with C# properties, it's probably the same or similar.
It's a huge difference. If a language compiles to Java source code instead of byte code, then developers can use it with other Java source code more easily. If it only compiles to byte code, then it can only be used as a library, and you can't debug it as easily by stepping through the source code.
You sound a little biased there. You apparently enjoy the fact that C# development allows development on some target platforms - Windows, Xbox, etc. C# doesn't work on non-Windows machines. People have tried to make it (i.e. Mono), but you can't run many C# apps on Mono.
Your comment belongs in another discussion about the merits of spanking when raising children.
This discussion is about child abuse and about a judge who makes judgements on cases involving child abuse and domestic violence. If you watch the video, you'll understand. The man is sadistic and is taking pleasure in beating a child. Even if you think physical violence is appropriate when raising children, if the person applying the violence enjoys it then it's not okay.
So what you're saying is that Apple should spend time and money to allow development of iOS mobile devices, so that people don't have to buy their other products? I admit it does suck for someone who just wants to mess around, but it's a minor trifling to businesses. The fact that Apple hasn't and yet apps are still made in great numbers goes to show that they don't need to.
Companies who want people to use their products will make the tools for free, in order to spread them as much as possible. Apple doesn't have to - the people already come to them. Off topic, but interestingly enough, the fact that RIM didn't make its app development tools free and more easily accessible is thought to be one of the chief reasons RIM was worth $80 billion 2 years ago and only $10 billion today, because there weren't enough people making apps for Blackberries.
Well other people were obviously confused. And I'm not talking about your most recent post being confusing, I'm referring to the earlier ones. Anyways, have a nice day.
In any case, no one could write a complete bug-free string class in 15 minutes which implements everything common to string classes, unless you've got it completely memorized and you type as fast as possible.
Straw man argument. If all I need is a string class that can allocate, free, append, copy and replace strings, I don't need a string class that "implements everything common to string classes.
That wasn't a straw man argument, that WAS the argument. Those things you mentioned are the common string functions, not the kitchen sink of string functions. And you're absolutely incorrect, you're wrong as wrong can be.
There's two things that you're wrong about. First of all, the fact of the matter is that if you write custom code to be compiled, the compiler will have to compile it, then link it. Existing libraries don't have to be compiled, just linked. You said that it is faster build times for custom classes, and that's absolutely incorrect - it's slower.
Second, you stated that writing your own string classes leads to less debugging and maintenance and is only 15 minutes. This is also patently incorrect. If one writes their own code they have to debug it and maintain it - string libraries are already thoroughly debugged. 15 minutes is a comical number at best, and dangerous to a project at worse, for writing, testing, and debugging a string class. You literally would have to have it already memorized to implement everything (which you may very well have done, considering you've done it for so many decades) in order to type the methods that quickly, and then you would still need to test them.
You are also saying that it's better to implement your own strings because they need to do less than the library. That is an opinion that I won't bother continuing the conversation with, because honestly it depends on the situation. Finally, you're going off on an old person's rant about coding difficulty and your anecdotes on assembler. Completely unrelated to the conversation.
Just because you can't justify it doesn't mean that there are no cases where it's justified.
I didn't say anything about a case that wasn't justified (in fact I mentioned that sometimes it may be necessary depending on the situation). What I said was you are patently incorrect about faster build times, less bugs/time/maintenance about using existing libraries, and the 15 minute estimate.
How is one supposed to know, before buying a computer, that years later he'll want to get into iOS application development?
That's an awfully stupid question. How is one supposed to know anything before it happens years later? What if I bought an iPhone and years later I want to do Android development? Should iPhones be forced to support Android development? RIM, WIndows Mobile, etc.?
This is what you said: "First, you only have to have ONE person in your org write that custom string class that does exactly what you want, no unpredictable side effects, no bloat. That 15 minutes pays itself back almost immediately, both in easier debugging (less code to debug) and quicker compile times"
You may be older than me, but I'm smart enough to know better than re-implementing string classes when you already have some that are already proven to be bug free - it's a bad idea. It is not a 15 minute process, and yes there can be unpredictable side effects and bloat. You've insinuated that you could do it in 15 minutes, but apparently you've been doing it for decades. In any case, no one could write a complete bug-free string class in 15 minutes which implements everything common to string classes, unless you've got it completely memorized and you type as fast as possible.
Regardless of the opinion of whether or not it's a good idea, it's no opinion on this matter: extra code which is compiled and not linked leads to slower compile times.
When you've been re-implementing the same basic classes for a couple of decades (custom strings, stacks, queues, linked lists, etc), doing it one more time, again customized to your current needs, is really no big deal.
HA! It took you 20+ years to debug your code!;)
Also, we're not talking c here, but c++
Yeah I know, we were talking classes. C can mean C/C++.
If people can't implement (or are afraid to implement) the basic classes that are everywhere, how much can you trust any class they DO implement?
This is where you're waaaaay off. Whereas you seem to think people should implement basic classes that are everywhere, it is exactly the opposite: nobody in your organization should be re-writing the basic classes that are everywhere. They're already everywhere. It's a waste of time... you are going to have to debug and maintain code that you didn't have to before. It's a straw man's argument to claim it's a matter of trust or capability of that they can't write these classes.
Yes, according to Wikipedia, modern digital fonts and rendering are supposed to automatically create more space. But I sure don't see that on my browser.
First, you only have to have ONE person in your org write that custom string class that does exactly what you want, no unpredictable side effects, no bloat.
That 15 minutes pays itself back almost immediately, both in easier debugging (less code to debug) and quicker compile times,
As a person who's dealt with customized string classes, I can assure you that it's not 15 minutes, and it does not make less code to debug. If we're talking C here, it would make LARGER compile times (as you may or may not know, an existing string library would not need to be compiled, only linked, which is much quicker than compilation). Also, by definition, writing your own string class (or any of your own code for that matter) means more debugging - one doesn't need to debug an existing string library.
I don't think that's true. Exaggerations of partial truths are exaggerations, not lies. They could be also termed "misconceptions" or "be deceiving", but I don't think exaggerations of truths constitutes a lie.
I understand the theory behind what you're saying. I also agree that everything would be totally fucked... but just for a while.
I don't think we'd revert to the dark ages of science and technology - I think we'd just be severely hampered for about a hundred years or so. I feel like enough knowledgeable people and enough books, etc., would survive. Really, it depends on randomness, of how much the knowledgeable people and information survives - the more, the better.
The reason I think this is because if such an armageddon ever happened, I would make it my remaining life's goal to perpetuate the knowledge that I know. I may not be able to build a computer, but I remember enough theories to write it down (such as how a NAND gate would work, how an OS would work, how compilers and software work, and maybe even other topics such as the scientific theory, etc.). I believe others could fill in the blanks eventually.
However, on the contrary, I think that it is equally valid to say that RMS doesn't "get" how the world works. I personally think that is a big part of the picture (A. understanding the way the world works and B. disagreeing and wanting to change it), and likely the reason why there are so many people here on Slashdot (i.e. in the world) who are making fun of him.
tl;dr The percentage of code in a common Linux "distro" is about 3% Linux code and about 25% Gnu code. So, that part makes sense. I do feel for the guy: to him, someone else stole his glory.
Re:First post? I brought up breakfast once
on
The RMS Tour Rider
·
· Score: 1
That is incorrect.
If you ate the same amount of calories in one meal for breakfast instead of the same amount of calories spread out over the day, you would lose weight. Google metabolism.
You can kiss technology goodbye, except for whatever remnants that can work without power.
Yes, technically, humans have the capability to survive much better than our prehistoric ancestors, IF we reduce our population to maybe 300M worldwide, and invest in massive amounts of stored food and complex protective shelters for EVERYONE.
Totally disagree. Technology would still remain. If 95% of the population died, we would still know how to make TVs and computers. We may not be able to produce them at the same level, but knowledge would not disappear - we have ways to store knowledge well beyond "oral tradition". You would be surprised how quickly we would be able to keep the internet alive, albeit missing some things like regular updates on Slashdot.
If the market has fixed rules enforcing contracts, protecting private property, and prohibiting fraud, it doesn't matter if resources end up in relatively few hands. Those few hands earned them by serving others, thereby getting others to buy their stuff. If those parties quit producing things consumers want, they will slowly (but surely) lose their command of resources.
The problem of the free market in education is the same with healthcare: the market will most efficiently find the best way to maximize monetary profits. It will not most efficiently find the best way to provide healthcare (which is a loss to be best), or to provide education (which is a distraction to research).
If the higher education system was purely based around making a computer scientist the best potential employee in successful companies, the free market would do splendidly. The problem with the free market approach is that the university system is much more than producing skilled workers - this has never been the goal of universities for thousands of years (albeit sometimes it was a goal in certain situations). IT Tech is a higher education corporation meant to produce a certain class of hopefully well skilled workers for certain positions; if it doesn't, it will (theoretically) fail in the free market. Georgia Tech and MIT are not the same such institutions like IT Tech. In a free market, the success of true universities relies on the benevolence, wisdom, and altruism of those who want to make the world a better place (or some facet of existence such as, oh, dam construction). So the free market isn't going to help the true university system - in the true theoretical free market, it would be up to people like Bill Gates to eradicate malaria, and if there's no one who altruistically wants to eradicate tuberculosis, then oh well.
Slashdot Mirror
D is not a language that requires GC for its basic functionality. It is built into the language, yes, but it is not required and can be turned off - either in whole or in part. In other words, you can write a program that has no GC, and you can also write a program that only uses GC in some classes or even some fields of a class.
Check out the D programming language. It also is what C would look like, had it been invented today. https://www.google.com/search?q=d+programming+language
C is really awesome for some things, but modern languages allow people to "get stuff done quickly", much quicker than in C. The C language syntax is a little quirky - for example, the extern keyword means completely different things in different contexts. There's no need for a -> operator; the . operator should be overloaded (this one is a matter of opinion, of course). Finally, garbage collection: writing programs and not worrying about memory and ownership is an awesome thing.
Also, the C preprocessor is an awful programming language concept - more specifically, textual macros are. (See the D language for reasons why, and how to get around them... in a nut shell, you can use static constants, functions, etc., to do what macros do)
First we got told that writing person.name = "John" is bad. Bad, bad, bad. I never understood why. Sure, getters and setters are very useful, beans and all, and it can take away some trouble, but if you really need a function that does more than change the value of field x, why call it setX()?
Anyway, that's the current practice: getX() and setX(), and sometimes they don't get x, or set x, but just pretend.
I also used to think making accessor methods was an unnecessary burden when writing code. But time and time again, I have ended up having to refactor the public properties into getters and setters. Not every time, mind you, but it's caused enough problems to make it worth my while to use accessor methods every time now. It's "wisdom" and "experience" and I really can't give you a good explanation of why. I know that it's been useful to be able to add contracts to setters, such as "throw an exception if this isn't a valid state". Thinking about it now, I probably would say that setters are much more useful than getters... but in Java there's no way to make a class's field public for reading and private for writing.
Note that I'm only speaking for Java - with C# properties, it's probably the same or similar.
It's a huge difference. If a language compiles to Java source code instead of byte code, then developers can use it with other Java source code more easily. If it only compiles to byte code, then it can only be used as a library, and you can't debug it as easily by stepping through the source code.
You sound a little biased there. You apparently enjoy the fact that C# development allows development on some target platforms - Windows, Xbox, etc. C# doesn't work on non-Windows machines. People have tried to make it (i.e. Mono), but you can't run many C# apps on Mono.
Your comment belongs in another discussion about the merits of spanking when raising children.
This discussion is about child abuse and about a judge who makes judgements on cases involving child abuse and domestic violence. If you watch the video, you'll understand. The man is sadistic and is taking pleasure in beating a child. Even if you think physical violence is appropriate when raising children, if the person applying the violence enjoys it then it's not okay.
So what you're saying is that Apple should spend time and money to allow development of iOS mobile devices, so that people don't have to buy their other products? I admit it does suck for someone who just wants to mess around, but it's a minor trifling to businesses. The fact that Apple hasn't and yet apps are still made in great numbers goes to show that they don't need to.
Companies who want people to use their products will make the tools for free, in order to spread them as much as possible. Apple doesn't have to - the people already come to them. Off topic, but interestingly enough, the fact that RIM didn't make its app development tools free and more easily accessible is thought to be one of the chief reasons RIM was worth $80 billion 2 years ago and only $10 billion today, because there weren't enough people making apps for Blackberries.
Well other people were obviously confused. And I'm not talking about your most recent post being confusing, I'm referring to the earlier ones. Anyways, have a nice day.
Straw man argument. If all I need is a string class that can allocate, free, append, copy and replace strings, I don't need a string class that "implements everything common to string classes.
That wasn't a straw man argument, that WAS the argument. Those things you mentioned are the common string functions, not the kitchen sink of string functions. And you're absolutely incorrect, you're wrong as wrong can be.
There's two things that you're wrong about. First of all, the fact of the matter is that if you write custom code to be compiled, the compiler will have to compile it, then link it. Existing libraries don't have to be compiled, just linked. You said that it is faster build times for custom classes, and that's absolutely incorrect - it's slower.
Second, you stated that writing your own string classes leads to less debugging and maintenance and is only 15 minutes. This is also patently incorrect. If one writes their own code they have to debug it and maintain it - string libraries are already thoroughly debugged. 15 minutes is a comical number at best, and dangerous to a project at worse, for writing, testing, and debugging a string class. You literally would have to have it already memorized to implement everything (which you may very well have done, considering you've done it for so many decades) in order to type the methods that quickly, and then you would still need to test them.
You are also saying that it's better to implement your own strings because they need to do less than the library. That is an opinion that I won't bother continuing the conversation with, because honestly it depends on the situation. Finally, you're going off on an old person's rant about coding difficulty and your anecdotes on assembler. Completely unrelated to the conversation.
Just because you can't justify it doesn't mean that there are no cases where it's justified.
I didn't say anything about a case that wasn't justified (in fact I mentioned that sometimes it may be necessary depending on the situation). What I said was you are patently incorrect about faster build times, less bugs/time/maintenance about using existing libraries, and the 15 minute estimate.
How is one supposed to know, before buying a computer, that years later he'll want to get into iOS application development?
That's an awfully stupid question. How is one supposed to know anything before it happens years later? What if I bought an iPhone and years later I want to do Android development? Should iPhones be forced to support Android development? RIM, WIndows Mobile, etc.?
This is what you said: "First, you only have to have ONE person in your org write that custom string class that does exactly what you want, no unpredictable side effects, no bloat. That 15 minutes pays itself back almost immediately, both in easier debugging (less code to debug) and quicker compile times"
You may be older than me, but I'm smart enough to know better than re-implementing string classes when you already have some that are already proven to be bug free - it's a bad idea. It is not a 15 minute process, and yes there can be unpredictable side effects and bloat. You've insinuated that you could do it in 15 minutes, but apparently you've been doing it for decades. In any case, no one could write a complete bug-free string class in 15 minutes which implements everything common to string classes, unless you've got it completely memorized and you type as fast as possible.
Regardless of the opinion of whether or not it's a good idea, it's no opinion on this matter: extra code which is compiled and not linked leads to slower compile times.
When you've been re-implementing the same basic classes for a couple of decades (custom strings, stacks, queues, linked lists, etc), doing it one more time, again customized to your current needs, is really no big deal.
HA! It took you 20+ years to debug your code! ;)
Also, we're not talking c here, but c++
Yeah I know, we were talking classes. C can mean C/C++.
If people can't implement (or are afraid to implement) the basic classes that are everywhere, how much can you trust any class they DO implement?
This is where you're waaaaay off. Whereas you seem to think people should implement basic classes that are everywhere, it is exactly the opposite: nobody in your organization should be re-writing the basic classes that are everywhere. They're already everywhere. It's a waste of time... you are going to have to debug and maintain code that you didn't have to before. It's a straw man's argument to claim it's a matter of trust or capability of that they can't write these classes.
Yes, according to Wikipedia, modern digital fonts and rendering are supposed to automatically create more space. But I sure don't see that on my browser.
Agreed, but you were confusing in your posts about what you meant and what you were trying to get at.
First, you only have to have ONE person in your org write that custom string class that does exactly what you want, no unpredictable side effects, no bloat.
That 15 minutes pays itself back almost immediately, both in easier debugging (less code to debug) and quicker compile times,
As a person who's dealt with customized string classes, I can assure you that it's not 15 minutes, and it does not make less code to debug. If we're talking C here, it would make LARGER compile times (as you may or may not know, an existing string library would not need to be compiled, only linked, which is much quicker than compilation). Also, by definition, writing your own string class (or any of your own code for that matter) means more debugging - one doesn't need to debug an existing string library.
Exaggerations of partial truths are still lies.
I don't think that's true. Exaggerations of partial truths are exaggerations, not lies. They could be also termed "misconceptions" or "be deceiving", but I don't think exaggerations of truths constitutes a lie.
Unless they do, then the really can. The problem is the overlap between pot smokers and slackers.
Its easier to quit smoking pot than it is to stop drinking soda.
So... you're saying that caffeine is not addictive as well?
The poster clearly wrote that caffeine is more addictive than marijuana, not that caffeine isn't addictive.
I understand the theory behind what you're saying. I also agree that everything would be totally fucked... but just for a while.
I don't think we'd revert to the dark ages of science and technology - I think we'd just be severely hampered for about a hundred years or so. I feel like enough knowledgeable people and enough books, etc., would survive. Really, it depends on randomness, of how much the knowledgeable people and information survives - the more, the better.
The reason I think this is because if such an armageddon ever happened, I would make it my remaining life's goal to perpetuate the knowledge that I know. I may not be able to build a computer, but I remember enough theories to write it down (such as how a NAND gate would work, how an OS would work, how compilers and software work, and maybe even other topics such as the scientific theory, etc.). I believe others could fill in the blanks eventually.
Who decides these rules? I like two spaces between sentences. I think it looks better, and flows better.
This is an awesome point.
However, on the contrary, I think that it is equally valid to say that RMS doesn't "get" how the world works. I personally think that is a big part of the picture (A. understanding the way the world works and B. disagreeing and wanting to change it), and likely the reason why there are so many people here on Slashdot (i.e. in the world) who are making fun of him.
but what does it all have to do with Linux?
He explains his version here: http://www.gnu.org/gnu/linux-and-gnu.html
tl;dr The percentage of code in a common Linux "distro" is about 3% Linux code and about 25% Gnu code. So, that part makes sense. I do feel for the guy: to him, someone else stole his glory.
That is incorrect.
If you ate the same amount of calories in one meal for breakfast instead of the same amount of calories spread out over the day, you would lose weight. Google metabolism.
You can kiss technology goodbye, except for whatever remnants that can work without power.
Yes, technically, humans have the capability to survive much better than our prehistoric ancestors, IF we reduce our population to maybe 300M worldwide, and invest in massive amounts of stored food and complex protective shelters for EVERYONE.
Totally disagree. Technology would still remain. If 95% of the population died, we would still know how to make TVs and computers. We may not be able to produce them at the same level, but knowledge would not disappear - we have ways to store knowledge well beyond "oral tradition". You would be surprised how quickly we would be able to keep the internet alive, albeit missing some things like regular updates on Slashdot.
LOL! :)
If the market has fixed rules enforcing contracts, protecting private property, and prohibiting fraud, it doesn't matter if resources end up in relatively few hands. Those few hands earned them by serving others, thereby getting others to buy their stuff. If those parties quit producing things consumers want, they will slowly (but surely) lose their command of resources.
The problem of the free market in education is the same with healthcare: the market will most efficiently find the best way to maximize monetary profits. It will not most efficiently find the best way to provide healthcare (which is a loss to be best), or to provide education (which is a distraction to research).
If the higher education system was purely based around making a computer scientist the best potential employee in successful companies, the free market would do splendidly. The problem with the free market approach is that the university system is much more than producing skilled workers - this has never been the goal of universities for thousands of years (albeit sometimes it was a goal in certain situations). IT Tech is a higher education corporation meant to produce a certain class of hopefully well skilled workers for certain positions; if it doesn't, it will (theoretically) fail in the free market. Georgia Tech and MIT are not the same such institutions like IT Tech. In a free market, the success of true universities relies on the benevolence, wisdom, and altruism of those who want to make the world a better place (or some facet of existence such as, oh, dam construction). So the free market isn't going to help the true university system - in the true theoretical free market, it would be up to people like Bill Gates to eradicate malaria, and if there's no one who altruistically wants to eradicate tuberculosis, then oh well.