|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On March 22 2013 02:48 Kambing wrote:Show nested quote +On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic?
Now that you mention it, both!
|
On March 22 2013 02:53 aurum510 wrote:Show nested quote +On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both!
What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services.
(*To be fair, I don't like OOP either.)
|
On March 22 2013 02:41 Kambing wrote:Show nested quote +On March 22 2013 01:53 ddengster wrote:On March 22 2013 01:26 CecilSunkure wrote:On March 22 2013 01:14 Tobberoth wrote:On March 21 2013 09:04 darkness wrote:What makes C++ so famous for game development? You don't have to describe in details. Thanks.  I've heard tons of reasons, some of them make sense, others do not. The most classic argument is that higher level languages like C# are too slow. This argument is quite weak, careful benchmarking shows that the difference is quite small nowadays, wellwritten C++ code and wellwritten C# code will often perform very very similarly. The best reason I've heard has to do with the fact that DirectX etc is quite hard to work with effectively from higher level languages. Other than that, C++ offers a lot of flexibility which can be nice for doing larger scale optimizations. Two words ruin C#: garbage collection. garbage collection(GC) with respect to bad performance or? In my opinion, GC is still borderline ok; it frees lazy programmers from the burden of doing memory management, as long as they don't get hit with related bugs. The reason you'd use C# is reflection and widgets for game developer tools. More specifically, stop-the-world GC (can) ruin the soft real-time requirements of a video game (in general, any computationally intensive interactive simulation). Note that computers are powerful enough and runtime technology advanced enough this is only true of games that are pushing the boundaries of what current technology can afford. Beyond this point, you are making an engineering trade-off between the convenience of GC, the performance hit and behavior of GC on your program, and manpower optimizing your program around these constraints. And yes, C# (and other higher-level languages) serve very well in the space of creating supporting tools for games development such as level editors, assets managers, etc.
Well the biggest thing is the lack of control. If you could just control when the GC ran it wouldn't be a big deal.
|
On March 22 2013 04:03 CecilSunkure wrote:Show nested quote +On March 22 2013 02:41 Kambing wrote:On March 22 2013 01:53 ddengster wrote:On March 22 2013 01:26 CecilSunkure wrote:On March 22 2013 01:14 Tobberoth wrote:On March 21 2013 09:04 darkness wrote:What makes C++ so famous for game development? You don't have to describe in details. Thanks. I've heard tons of reasons, some of them make sense, others do not. The most classic argument is that higher level languages like C# are too slow. This argument is quite weak, careful benchmarking shows that the difference is quite small nowadays, wellwritten C++ code and wellwritten C# code will often perform very very similarly. The best reason I've heard has to do with the fact that DirectX etc is quite hard to work with effectively from higher level languages. Other than that, C++ offers a lot of flexibility which can be nice for doing larger scale optimizations. Two words ruin C#: garbage collection. garbage collection(GC) with respect to bad performance or? In my opinion, GC is still borderline ok; it frees lazy programmers from the burden of doing memory management, as long as they don't get hit with related bugs. The reason you'd use C# is reflection and widgets for game developer tools. More specifically, stop-the-world GC (can) ruin the soft real-time requirements of a video game (in general, any computationally intensive interactive simulation). Note that computers are powerful enough and runtime technology advanced enough this is only true of games that are pushing the boundaries of what current technology can afford. Beyond this point, you are making an engineering trade-off between the convenience of GC, the performance hit and behavior of GC on your program, and manpower optimizing your program around these constraints. And yes, C# (and other higher-level languages) serve very well in the space of creating supporting tools for games development such as level editors, assets managers, etc. Well the biggest thing is the lack of control. If you could just control when the GC ran it wouldn't be a big deal.
Yeah, control goes into the real-time requirement which is really the problem with GC in the cases that people think of. You can control the GC to some degree, e.g., GC.collect() to force collections. With this and some careful organization of your program, you can ensure that allocations occur only when your program can tolerate the latency. However, this requires careful consideration of the program's memory footprint and still doesn't work in all cases.
|
On March 22 2013 01:00 AmericanUmlaut wrote:Show nested quote +On March 21 2013 22:03 mcc wrote:On March 21 2013 06:17 Kambing wrote:On March 21 2013 06:02 obesechicken13 wrote:Do any of you have any experience with regression testing? What should it include? Wikipedia hints that regression testing may just be a small set of tests for things that have broken in the past. But what I've always done is I've run through every single feature in the test suite. What is the best practice here? edit: f*** nvm http://www.testingeducation.org/k04/RegressionExamples.htmGeneral functional regression: We retest the product broadly, including areas that worked before, to see whether more recent changes have destabilized working code. (This is the typical scope of automated regression testing.) Many companies have the following process: for every bug fix made to the product, a test is introduced into a test suite to ensure that the bug is never reintroduced. This test suite, made from prior bug fixes, is called a regression test suite. That seems very narrow view of regression testing. Regression testing as we used it was supposed to make sure that new changes to the system do not introduce bugs in parts of the system that were not supposed to be affected by those changes. Basically they exist to discover side-effect bugs of new changes and also errors in analysis of the new changes. In the case of project I worked on it was a set of tests that covered all critical functions of the system. Using just tests based on previous bugs does not seem to address the issue. That is a fairly common way of building a regression test library, though. It has a certain compelling logic to it, too: It guarantees you'll only ever have to fix a particular problem once, and it guarantees you'll invest test-writing time in components in direct proportion to their propensity to develop bugs.
I am not saying it is bad, I just think it is somewhat incomplete. It is definitely good part of regression tests. But as Kambing pointed out later it somewhat comes down to terminology.
|
On March 22 2013 04:03 CecilSunkure wrote:Show nested quote +On March 22 2013 02:41 Kambing wrote:On March 22 2013 01:53 ddengster wrote:On March 22 2013 01:26 CecilSunkure wrote:On March 22 2013 01:14 Tobberoth wrote:On March 21 2013 09:04 darkness wrote:What makes C++ so famous for game development? You don't have to describe in details. Thanks. I've heard tons of reasons, some of them make sense, others do not. The most classic argument is that higher level languages like C# are too slow. This argument is quite weak, careful benchmarking shows that the difference is quite small nowadays, wellwritten C++ code and wellwritten C# code will often perform very very similarly. The best reason I've heard has to do with the fact that DirectX etc is quite hard to work with effectively from higher level languages. Other than that, C++ offers a lot of flexibility which can be nice for doing larger scale optimizations. Two words ruin C#: garbage collection. garbage collection(GC) with respect to bad performance or? In my opinion, GC is still borderline ok; it frees lazy programmers from the burden of doing memory management, as long as they don't get hit with related bugs. The reason you'd use C# is reflection and widgets for game developer tools. More specifically, stop-the-world GC (can) ruin the soft real-time requirements of a video game (in general, any computationally intensive interactive simulation). Note that computers are powerful enough and runtime technology advanced enough this is only true of games that are pushing the boundaries of what current technology can afford. Beyond this point, you are making an engineering trade-off between the convenience of GC, the performance hit and behavior of GC on your program, and manpower optimizing your program around these constraints. And yes, C# (and other higher-level languages) serve very well in the space of creating supporting tools for games development such as level editors, assets managers, etc. Well the biggest thing is the lack of control. If you could just control when the GC ran it wouldn't be a big deal.
So D is the way to go
|
On March 22 2013 03:31 Kambing wrote:Show nested quote +On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.)
The context was meant that C# should not be used to make games (or anything that requires performance as a significant concern). Dynamic dispatch requires a lot of overhead during run-time. C++ uses only static dispatch unless specified with the virtual keyword.
|
On March 22 2013 03:31 Kambing wrote:Show nested quote +On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.)
Could you explain this dynamic dispatch thing being the backbone?
|
On March 22 2013 12:47 aurum510 wrote:Show nested quote +On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) The context was meant that C# should not be used to make games (or anything that requires performance as a significant concern). Dynamic dispatch requires a lot of overhead during run-time. C++ uses only static dispatch unless specified with the virtual keyword.
For most people who want to make indie games, why not use C#? It lets you focus on building your games story, as compared to optimizing a bunch of C++ code. I can't imagine most indie game developers are writing games that are breakneck performance. You make a tradeoff between time to finish game and performance when choosing C++ over another language imo.
edit: realize now that this was in reference to someone asking why was C++ famous for game dev. I just get tired of people going around telling someone who asks 'How do I make a game' to dive into C++, when imho they're better off starting in another language, making some games, and running into the limitations of the language themselves.
On March 22 2013 12:56 CecilSunkure wrote:Show nested quote +On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) Could you explain this dynamic dispatch thing being the backbone?
How else do you have polymorphism?
|
On March 22 2013 13:24 teamamerica wrote:
How else do you have polymorphism?
Oh lol, I was actually thinking of double dispatch. Sorry got confused.
|
On March 22 2013 13:24 teamamerica wrote:Show nested quote +On March 22 2013 12:47 aurum510 wrote:On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) The context was meant that C# should not be used to make games (or anything that requires performance as a significant concern). Dynamic dispatch requires a lot of overhead during run-time. C++ uses only static dispatch unless specified with the virtual keyword. For most people who want to make indie games, why not use C#? It lets you focus on building your games story, as compared to optimizing a bunch of C++ code. I can't imagine most indie game developers are writing games that are breakneck performance. You make a tradeoff between time to finish game and performance when choosing C++ over another language imo. edit: realize now that this was in reference to someone asking why was C++ famous for game dev. I just get tired of people going around telling someone who asks 'How do I make a game' to dive into C++, when imho they're better off starting in another language, making some games, and running into the limitations of the language themselves. Show nested quote +On March 22 2013 12:56 CecilSunkure wrote:On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) Could you explain this dynamic dispatch thing being the backbone? How else do you have polymorphism?
there is static polymorphism.
|
On March 22 2013 12:56 CecilSunkure wrote:Show nested quote +On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) Could you explain this dynamic dispatch thing being the backbone?
Dynamic dispatch --- method overriding --- is typically considered the "heart" of OOP because it is the most unique and essential feature of the language paradigm. Other features of OOP can be easily emulated in other language paradigms e.g., classes as records, inheritance as (explicit) record subtyping, or are not essential, e.g., the lack of classes in prototype-based programming languages such as Javascript. However, the mechanism of dynamic dispatch are both non-trivial and present in every OO language.
|
On March 22 2013 12:47 aurum510 wrote:Show nested quote +On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) The context was meant that C# should not be used to make games (or anything that requires performance as a significant concern). Dynamic dispatch requires a lot of overhead during run-time. C++ uses only static dispatch unless specified with the virtual keyword.
C# is perfectly fine for many games that someone would like to make. For Crisis, Farcry, etc., it is likely not appropriate but that is only a tiny subset of games out there.
Dynamic dispatch does require a non-trivial performance penalty (the cost of a pointer indirection), but that isn't necessarily a prohibitive cost. And in fact, C# does the "right" thing like C++ and only has opt-in dynamic dispatch via the overrides keyword.
Besides (stop-the-world) garbage collection ruining soft real-time guarantees, the primary performance benefit that C++ provides is explicit memory layout (rather than management). In Java (and to a lesser extent, C#), you do not have direct control over how objects are laid out in memory, for example contiguously or via indirect pointers or on the stack vs. on the heap. These sorts of considerations in C++, when properly tuned, can lead to significant performance gains over higher-level languages.
|
On March 22 2013 20:53 nunez wrote:Show nested quote +On March 22 2013 13:24 teamamerica wrote:On March 22 2013 12:47 aurum510 wrote:On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) The context was meant that C# should not be used to make games (or anything that requires performance as a significant concern). Dynamic dispatch requires a lot of overhead during run-time. C++ uses only static dispatch unless specified with the virtual keyword. For most people who want to make indie games, why not use C#? It lets you focus on building your games story, as compared to optimizing a bunch of C++ code. I can't imagine most indie game developers are writing games that are breakneck performance. You make a tradeoff between time to finish game and performance when choosing C++ over another language imo. edit: realize now that this was in reference to someone asking why was C++ famous for game dev. I just get tired of people going around telling someone who asks 'How do I make a game' to dive into C++, when imho they're better off starting in another language, making some games, and running into the limitations of the language themselves. On March 22 2013 12:56 CecilSunkure wrote:On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) Could you explain this dynamic dispatch thing being the backbone? How else do you have polymorphism? there is static polymorphism.
Yes! This is what makes C++ very useful for performance. You can still use OOP, but there are no run-time checks. It's very important.
[Edit]: To be fair, C# has similar abilities for only using dynamic dispatch when told to do so.
|
On March 22 2013 22:11 Kambing wrote:Show nested quote +On March 22 2013 12:47 aurum510 wrote:On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) The context was meant that C# should not be used to make games (or anything that requires performance as a significant concern). Dynamic dispatch requires a lot of overhead during run-time. C++ uses only static dispatch unless specified with the virtual keyword. C# is perfectly fine for many games that someone would like to make. For Crisis, Farcry, etc., it is likely not appropriate but that is only a tiny subset of games out there. Dynamic dispatch does require a non-trivial performance penalty (the cost of a pointer indirection), but that isn't necessarily a prohibitive cost. And in fact, C# does the "right" thing like C++ and only has opt-in dynamic dispatch via the overrides keyword. Besides (stop-the-world) garbage collection ruining soft real-time guarantees, the primary performance benefit that C++ provides is explicit memory layout (rather than management). In Java (and to a lesser extent, C#), you do not have direct control over how objects are laid out in memory, for example contiguously or via indirect pointers or on the stack vs. on the heap. These sorts of considerations in C++, when properly tuned, can lead to significant performance gains over higher-level languages.
I meant more the necessary runtime checks to look up the method in the vtable (while still technically O(1), it's not nice to look something up in a hashtable, as it requires some calculations to get the hash).
But it's true that it's not very bad, as you say (specifically for games, and less for systems where performance is crucial).
|
On March 22 2013 22:31 aurum510 wrote:Show nested quote +On March 22 2013 22:11 Kambing wrote:On March 22 2013 12:47 aurum510 wrote:On March 22 2013 03:31 Kambing wrote:On March 22 2013 02:53 aurum510 wrote:On March 22 2013 02:48 Kambing wrote:On March 22 2013 02:44 aurum510 wrote:
Two more words ruin C#: dynamic binding Eh, dynamic dispatch? Or type dynamic? Now that you mention it, both! What's wrong with them? Dynamic dispatch is the backbone of object-oriented programming. If dynamic dispatch ruins C#, then you surely don't like OOP*. Type dynamic is an interoperability feature with dynamically-typed languages and only has an effect on your programs if you opt into its services. (*To be fair, I don't like OOP either.) The context was meant that C# should not be used to make games (or anything that requires performance as a significant concern). Dynamic dispatch requires a lot of overhead during run-time. C++ uses only static dispatch unless specified with the virtual keyword. C# is perfectly fine for many games that someone would like to make. For Crisis, Farcry, etc., it is likely not appropriate but that is only a tiny subset of games out there. Dynamic dispatch does require a non-trivial performance penalty (the cost of a pointer indirection), but that isn't necessarily a prohibitive cost. And in fact, C# does the "right" thing like C++ and only has opt-in dynamic dispatch via the overrides keyword. Besides (stop-the-world) garbage collection ruining soft real-time guarantees, the primary performance benefit that C++ provides is explicit memory layout (rather than management). In Java (and to a lesser extent, C#), you do not have direct control over how objects are laid out in memory, for example contiguously or via indirect pointers or on the stack vs. on the heap. These sorts of considerations in C++, when properly tuned, can lead to significant performance gains over higher-level languages. I meant more the necessary runtime checks to look up the method in the vtable (while still technically O(1), it's not nice to look something up in a hashtable, as it requires some calculations to get the hash). But it's true that it's not very bad, as you say (specifically for games, and less for systems where performance is crucial).
Yeah, my pointer indirection comment is about the runtime cost of method lookup. No hashing is required for a vtable in a (traditional, receiver-based) OO language as the name of function you want to lookup at runtime is known at compile time. This amounts to compiling the method invocation down into a lookup of the vtable at the particular offset that contains the method you want.
(In the case of reflection, you do need some more complicated lookup scheme like a dictionary as you need to essentially perform the "hashing" of the function name-to-vtable entry computation at runtime.)
|
Man. I just had a very weird experienced. I'm new to programming and I was doing this exercise on Euler and as I got stuck I sat back and looked at my code. Then it hit me. My variable names actually have meaning as in, they have meaning in the English language. When I program they lose all the meaning they had beforehand, the variable names will have become a number or a string. I can have a variable named: "Hello" and during my programming my brain doesn't register its meaning as "Hello" because it has become something entirely different. Made me question meaning, my life and everything for a moment. Then I got mad because my code wouldn't work.
|
On March 23 2013 06:09 Recognizable wrote:
Man. I just had a very weird experienced. I'm new to programming and I was doing this exercise on Euler and as I got stuck I sat back and looked at my code. Then it hit me. My variable names actually have meaning as in, they have meaning in the English language. When I program they lose all the meaning they had beforehand, the variable names will have become a number or a string. I can have a variable named: "Hello" and during my programming my brain doesn't register its meaning as "Hello" because it has become something entirely different. Made me question meaning, my life and everything for a moment. Then I got mad because my code wouldn't work.
Just wait until you learn a functional language.
|
On March 23 2013 06:11 heishe wrote:Show nested quote +On March 23 2013 06:09 Recognizable wrote:
Man. I just had a very weird experienced. I'm new to programming and I was doing this exercise on Euler and as I got stuck I sat back and looked at my code. Then it hit me. My variable names actually have meaning as in, they have meaning in the English language. When I program they lose all the meaning they had beforehand, the variable names will have become a number or a string. I can have a variable named: "Hello" and during my programming my brain doesn't register its meaning as "Hello" because it has become something entirely different. Made me question meaning, my life and everything for a moment. Then I got mad because my code wouldn't work. Just wait until you learn a functional language.
I'd skip them and start directly with OO
|
On March 23 2013 06:09 Recognizable wrote:
Man. I just had a very weird experienced. I'm new to programming and I was doing this exercise on Euler and as I got stuck I sat back and looked at my code. Then it hit me. My variable names actually have meaning as in, they have meaning in the English language. When I program they lose all the meaning they had beforehand, the variable names will have become a number or a string. I can have a variable named: "Hello" and during my programming my brain doesn't register its meaning as "Hello" because it has become something entirely different. Made me question meaning, my life and everything for a moment. Then I got mad because my code wouldn't work.
String Float = new String("true");
|
|
|
|
|
|
EPT
