|
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. |
re: sluggaslamoo -- I guess we just live on different planets. I don't even understand your position. If you have the luxury of working on a project where efficiency is of no importance to you, that's nice; I work on programs running on the desktops of people who work for much bigger companies than mine, and they aren't going to upgrade their hardware because I'm incompetent. They'll buy someone else's software that doesn't suck. The fact that our software is not slow and awful is a huge selling point, and careless work makes it pretty easy to move from "OK" territory to "slow and awful" territory.
I have no idea what you do in which you do not care about the performance of the methods you call and the data structures you consume. It's bizarre to hear you say "I don't care how Array.BinarySearch performs." I care, because a binary search versus a linear search is the difference between running a big report in one second versus a hundred seconds. A constant time indexer versus a linear time indexer is the difference between correlating some couple million data in five seconds and doing it overnight. I like to communicate that difference to people reading my code in whatever way is most clear, and implementing IList makes it clear that the indexer is relatively fast.
If you don't want to make your types semantically meaningful beyond "here is a list of methods, now go read the documentation and see what it does" I don't see the point of using a big statically-typed language in the first place.
I find your position to be that of writing unclear code and then relying on a bunch of external documentation (comments, design documents?) to clarify it. I would prefer to just not write unclear code.
|
Canada9720 Posts
On July 16 2010 23:54 sluggaslamoo wrote:Actionscript is just plain awful, made worse by their crappy libraries. I used to use it for browser games until JOGL came out, and now I have full hardware acceleration on the browser with a high performance VM. (Actionscript was way too slow) Show nested quote +On July 16 2010 09:27 SoLaR[i.C] wrote:
Anybody have a suggestion for a FORTRAN compiler? GFORTRAN http://gcc.gnu.org/fortran/IMO anything from the GCC collection is very good quality, and free! LOL Zed! http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtmlRe-up, just to add to the C++ bashing bandwagon :D. (IMO the worst designed language of all time, repeated inheritance ftl)
that interview is funny, but there's no way it's real 
|
^ Its obviously satire, but its being ridiculed that way for a reason.
re: catamorphist
We're only on different planets because one of us hasn't studied programming enough . People who don't understand basic concepts, often find it very difficult to come to terms with more advanced concepts. Like the fact that it seems you think encapsulation leads to unclear code.
If you can grasp the incredibly simple concept of abstraction, you would realise that what I said leads to easy to manage, clean, understandable, flexible and scalable code. Even the time it would take to actually optimise your code, would be much much faster, because you are not locked into a concrete class. Making abstractions is a way of documenting the code, you should aim to make your code so simple that it doesn't require somebody nagging you all the time to find out what it does. The biggest reason is encapsulation, but again, if you don't understand abstraction, it will take forever for me to explain encapsulation.
Also I don't know any client based program that could possibly be that slow, again, if the potential exists, its just badly designed. A relational database engine could filter through 10,000 items in no time at all, what your saying is that your program depends solely on an indexing algorithm (on memory) could mean the difference between 5 seconds or overnight.
Bad program design, leads you to having 1 million items in an array on a desktop computer. If I had that much stuff stuck in memory I would uninstall the program immediately. Also I'm not saying the original programmer shouldn't care about what he does to his code, its others that shouldn't care. I don't want YOU, changing MY search algorithm.
Performance is probably the most important in game development, yet I've seen pre-optimised game engines that run as slow as crap (and are a nightmare to make changes to), others that properly adhere to coding principles and aren't pre-optimised, and run very smoothly.
|
I don't know what to say to you; you aren't addressing my point, which is that lists, naming conventions, and other language choices can be used to communicate performance-related and usage-related meaning, and that interfaces like IList and ISet, names like BinarySearch, choices in API design patterns, and language features like properties in C# facilitate that; and that it's silly to waste that meaning if you're using a big statically-typed language.
I apologize that you do not "know" the software I work on. I was hoping you could take my word for it, instead of telling me that it must be badly-designed.
I work on an ERP-sort-of program that is backed by a SQL database, but has a carefully-indexed disk cache on the client workstations for reporting purposes, consisting of frequently used historical and slow-changing data. Reports work on real-time data and are frequently over tens or hundreds of millions of sales history instances (an "instance" being something like a sale or purchase of a product to someone at some price point), not ten thousand, and users often want to take quite a few megabytes of data and filter it, sort it, group it, export it, or run forecasting algorithms on it, all on the client-side. They do not want to go get a cup of coffee while the computer is thinking about it, either.
In fact, they want to put the disk cache on their tablets and phones (we have mobile applications which serve mostly to record data, but also need some access to general information while offline), and do reports there, without having to be connected directly to SQL.
Of about a million and a quarter total lines of C#, I would say that performance is noticably important in the majority of our non-UI code. It's not like ten lines in an inner loop in one place. I don't think this is an unusual use case for software.
EDIT: Re-reading -- Like the fact that it seems you think encapsulation leads to unclear code. What? Are you reading my posts?
|
|
|
No, you aren't addressing my point and you aren't reading my posts [properly]. I was the one that made the point, you tried to argue against it.
Also please don't use an example that doesn't back up your point. You used Array.BinarySearch and then proceded to give an example of 1,000,000 items. Of course I would ridicule that using my point about program design, in that you wouldn't have 1,000,000 items in memory, let alone an array.
Basically, my advice was about using interfaces to encapsulate and de-couple your code, making it easier to change (thus easier to optimise). Accessing concrete classes are a really bad way to communicate design choices, it gives little return and comes with big consequences, and you can still do this for the most part with interfaces.
Just realise that you are disagreeing with some of the best programmers in the world. The inventor of Java ("I'd leave out classes"), the "Gang of Four" (the makers of Design Patterns, one the most famous OOP books in the world), etc.
Erich Gamma (1 of the Gang of Four)
http://www.artima.com/lejava/articles/designprinciples.html
I do have experience with SAP and Enterprise Java, I know what you mean, but it has nothing to do with what I'm saying. Also then to your point about desktop users not caring about hardware, ERPs are a client-server system, with most if not all of the processing done on the server (especially database searches). They are also designed for businesses prepared to invest a large sum of money into re-engineering their business. So my scaling hardware is cheap point stands.
^ As for your EDIT:
On July 17 2010 01:14 catamorphist wrote:I find your position to be that of writing unclear code and then relying on a bunch of external documentation (comments, design documents?) to clarify it. I would prefer to just not write unclear code.
Then how did you come up with this? All I'm getting is that you think encapsulation (which is what I'm advocating) leads to unclear code. What I got was that you think its unclear because I am, for example, only letting someone access an IList rather than a LinkedList, thus hiding the concrete class and making the code extremely flexible (and IMO simpler). Therefore I concluded that that you thought that encapsulation leads to unclear code.
There is no other point in my original debate, its just accessing interfaces over concrete classes. That's it, but then you brought in other examples and points, so I argued against those too. I think I will now only debate the point I made with my original post because its simply getting too complicated.
Please look at my original post again, and if you want, you can re-start the debate. Although until you fully understand some basic programming concepts, you probably won't be able to understand what I'm saying. (Unless I write a huge article about it) 
Sorry Ill try not to edit this time, its just that I always forget a lot of things I wanted to say before I post.
|
Are you two sure that you actually disagree with each other? I doubt it somehow...
Try to understand each other, not to find things that could be interpreted as something you disagree with...
|
On July 17 2010 03:17 sluggaslamoo wrote:You used Array.BinarySearch and then proceded to give an example of 1,000,000 items.
Of course I would ridicule that using my point about program design, in that you wouldn't have 1,000,000 items in memory, let alone an array.
That has almost nothing to do with what I said and nothing to do with anything important. I used Array.BinarySearch as an example of a method whose name indicates a performance detail. Please ctrl-F "Array.BinarySearch" in this thread.
I do have experience with SAP and Enterprise Java, I know what you mean, but it has nothing to do with what I'm saying. Also then to your point about desktop users not caring about hardware, ERPs are a client-server system, with most if not all of the processing done on the server (especially database searches). They are also designed for businesses prepared to invest a large sum of money into re-engineering their business. So my scaling hardware is cheap point stands.
My last post was not hypothetical! I am literally sitting here in my office writing code today to do what I described in the last post on the client. We run on people's workstations that they already own, and our customers would not be happy if we suggested that everyone buy expensive hardware. Please do not tell me my business; I don't want to debate it with you, I just want to indicate that there is a lot of code where performance usually matters.
All I'm getting is that you think encapsulation (which is what I'm advocating) leads to unclear code. What I got was that you think its unclear because I am, for example, only letting someone access an IList rather than a LinkedList, thus hiding the concrete class and making the code extremely flexible (and IMO simpler). Therefore I concluded that that you thought that encapsulation leads to unclear code.
I apologize, if you thought that was my point, we are arguing about nothing. My point has nothing to do with returning a concrete implementation versus an interface. My position pertinent to that example is that it's not really appropriate for a LinkedList to implement IList, since it can't provide random access in the way that a consumer of IList would expect. Please read this, my original post, which describes the point that I have tried to make in every subsequent post. Here, I will copy and paste it.
"I think that a valuable piece of information communicated by your return type (or your parameter type) is what "kind" of thing you are returning, in a general sense. If I am returning an IList, which implements an indexer, that really implies that the indexer is going to be constant time, because that's the example set by all the other IList implementations. Similarly, if you have an ISet, you expect Contains to be at least better than linear. I don't think there's anything wrong with having conventions like that, and it helps communicate things that you would have to put in a comment otherwise."
http://www.teamliquid.net/forum/viewmessage.php?topic_id=134491¤tpage=10#198
Maybe we are just agreeing very loudly. I don't know. I certainly didn't think that what I said was particularly controversial.
|
Maybe we are just agreeing very loudly.
I banana grinned.
Anyway, speaking of arguments...
I'm doing software design at an internship (simple ASP.NET w/ C# stuff) doing some stuff that's getting added or altered on the company Intranet (be afraid). Anyway, other intern I work with writes code about on the level of someone still in highschool.
I'm almost afraid to ask, but somehow I think dealing with people like this is going to be commonplace throughout my career?
|
Well, I can suggest the following things to ameliorate your suffering:
- You can try to educate the fellow, but be careful to separate the things you just don't like about his code from the things that are objectively bad. It's only fair to debate him on the stuff you can really make a case for.
- If you find concrete problems with his code that have real consequences (besides just being ugly and hard to maintain), then you should make sure your boss is aware, and if you fix the problems, try to take the opportunity to leave the code a little better than you found it.
- Just try to let him work on his bits and you work on yours as much as possible.
Other than that, you just have to do the best you can with what you've got. If you have to work with this guy's code all the time, if he is truly awful and not improving, and if you don't have the freedom to improve it at all, then I feel for you. That sucks. Most jobs are better than that, though.
|
Yeah our work is pretty much handcuffed together. Internships only for another month, so I'm not worried about this specific situation (although it is quite frustrating). I think the bigger problem is he just doesn't care that much -- wants to be a sysadmin instead of doing coding.
|
Good evening. So, I'm on a quest to learn .NET (C# specifically, maybe some of the basics for ASP if time permits) within say a year's time. I've played around with it, done some project Euler tasks and so on, so I'm fairly comfy with the syntax and the basics. Thus, my question is; What now? What do I need to be familiar with to be a competent coder, and to work in a professional environment. I'm going to make it a habit to write very clear, readable, well-commented code, but what I'm looking for is which areas of the languages do I need to be most familiar with? Please rate in order of importance what I need to know, so I can better delegate my time. Also, I love this thread, it's my replacement for the NSFW pics thread. 
|
LINQ and Entities are both things I had to learn when I started working a month or so ago.
|
Hi, another "please tell me what I should learn" post, if anyone's interested in helping me out. Thanks!
I'm an EE grad student who mostly uses C (and MATLAB) for research-related simulation and numerical computation. The only other language I know at any level above zero is Perl, which I just use for rudimentary data parsing. With C I have had exposure to some intermediate (I think) concepts like pointers, memory management, signal/interrupt catching, process forking, stream operations, etc. Are there any interesting books I should read or other languages to learn to round out my skillset or understanding? My area of study is wireless communications, if that gives you any ideas.
|
On July 17 2010 08:05 Adeny wrote:Good evening. So, I'm on a quest to learn .NET (C# specifically, maybe some of the basics for ASP if time permits) within say a year's time. I've played around with it, done some project Euler tasks and so on, so I'm fairly comfy with the syntax and the basics. Thus, my question is; What now? What do I need to be familiar with to be a competent coder, and to work in a professional environment. I'm going to make it a habit to write very clear, readable, well-commented code, but what I'm looking for is which areas of the languages do I need to be most familiar with? Please rate in order of importance what I need to know, so I can better delegate my time. Also, I love this thread, it's my replacement for the NSFW pics thread.
I am not so familiar with what this would entail for the .NET chain of languages, but you'll want to read up on major coding paradigms for your languages. You also want to start reading and adhering to style guides so that your code becomes very clean. Begin reading the source code for some major projects to get an idea of what flies.
|
Myrmidon, I'd say it depends on what you want to use programming for. You mentioned you studied wireless communication, do you only want to use programming for your studies?
If you want to get into wireless security, for example, you should learn Linux for sure. BackTrack 4 has the majority of tools you'll need.
If you're looking for a career in programming, I'd say go for C++ and learn OOP that way, should be easiest from a C background, as the languages are similar in most areas, and you'll only really have to re-learn formalities, like no default-int and so on, the compiler will catch most of it. Then when you're familiar with OOP, you can pick up must modern languages quickl.y
|
On July 17 2010 03:40 catamorphist wrote:+ Show Spoiler +On July 17 2010 03:17 sluggaslamoo wrote:You used Array.BinarySearch and then proceded to give an example of 1,000,000 items.
Of course I would ridicule that using my point about program design, in that you wouldn't have 1,000,000 items in memory, let alone an array. That has almost nothing to do with what I said and nothing to do with anything important. I used Array.BinarySearch as an example of a method whose name indicates a performance detail. Please ctrl-F "Array.BinarySearch" in this thread. I do have experience with SAP and Enterprise Java, I know what you mean, but it has nothing to do with what I'm saying. Also then to your point about desktop users not caring about hardware, ERPs are a client-server system, with most if not all of the processing done on the server (especially database searches). They are also designed for businesses prepared to invest a large sum of money into re-engineering their business. So my scaling hardware is cheap point stands. My last post was not hypothetical! I am literally sitting here in my office writing code today to do what I described in the last post on the client. We run on people's workstations that they already own, and our customers would not be happy if we suggested that everyone buy expensive hardware. Please do not tell me my business; I don't want to debate it with you, I just want to indicate that there is a lot of code where performance usually matters. All I'm getting is that you think encapsulation (which is what I'm advocating) leads to unclear code. What I got was that you think its unclear because I am, for example, only letting someone access an IList rather than a LinkedList, thus hiding the concrete class and making the code extremely flexible (and IMO simpler). Therefore I concluded that that you thought that encapsulation leads to unclear code. I apologize, if you thought that was my point, we are arguing about nothing. My point has nothing to do with returning a concrete implementation versus an interface. My position pertinent to that example is that it's not really appropriate for a LinkedList to implement IList, since it can't provide random access in the way that a consumer of IList would expect. Please read this, my original post, which describes the point that I have tried to make in every subsequent post. Here, I will copy and paste it. "I think that a valuable piece of information communicated by your return type (or your parameter type) is what "kind" of thing you are returning, in a general sense. If I am returning an IList, which implements an indexer, that really implies that the indexer is going to be constant time, because that's the example set by all the other IList implementations. Similarly, if you have an ISet, you expect Contains to be at least better than linear. I don't think there's anything wrong with having conventions like that, and it helps communicate things that you would have to put in a comment otherwise." http://www.teamliquid.net/forum/viewmessage.php?topic_id=134491¤tpage=10#198Maybe we are just agreeing very loudly. I don't know. I certainly didn't think that what I said was particularly controversial.
Watching this..discussion...develop is amusing though I think catamorphist makes an interesting point. For Array.BinarySearch you expect O(log n) and for the array to be already sorted.
|
On July 18 2010 20:37 Adeny wrote:
Myrmidon, I'd say it depends on what you want to use programming for. You mentioned you studied wireless communication, do you only want to use programming for your studies?
If you want to get into wireless security, for example, you should learn Linux for sure. BackTrack 4 has the majority of tools you'll need.
If you're looking for a career in programming, I'd say go for C++ and learn OOP that way, should be easiest from a C background, as the languages are similar in most areas, and you'll only really have to re-learn formalities, like no default-int and so on, the compiler will catch most of it. Then when you're familiar with OOP, you can pick up must modern languages quickl.y
Good questions. I would use programming for my studies but potentially also for future employment. I'm not planning a career in programming, but I can easily imagine working on projects that require embedded systems programming or involve programming as a facet of a larger system.
Wireless/network security is one big area I'm not interested in at all, so I'm glad you mentioned it. I operate at layer 1 with some forays and interactions with layers 2-3.
Is there a "Camel Book" equivalent for C++ or other recommended text/reading?
|
On July 18 2010 23:23 Myrmidon wrote:Show nested quote +On July 18 2010 20:37 Adeny wrote:
Myrmidon, I'd say it depends on what you want to use programming for. You mentioned you studied wireless communication, do you only want to use programming for your studies?
If you want to get into wireless security, for example, you should learn Linux for sure. BackTrack 4 has the majority of tools you'll need.
If you're looking for a career in programming, I'd say go for C++ and learn OOP that way, should be easiest from a C background, as the languages are similar in most areas, and you'll only really have to re-learn formalities, like no default-int and so on, the compiler will catch most of it. Then when you're familiar with OOP, you can pick up must modern languages quickl.y Good questions. I would use programming for my studies but potentially also for future employment. I'm not planning a career in programming, but I can easily imagine working on projects that require embedded systems programming or involve programming as a facet of a larger system. Wireless/network security is one big area I'm not interested in at all, so I'm glad you mentioned it. I operate at layer 1 with some forays and interactions with layers 2-3. Is there a "Camel Book" equivalent for C++ or other recommended text/reading?
I don't really know this "Camel Book", but it sounds like it would be fairly similar to "The C++ Programming Language". It's easy to read, starts with the basics, covers pretty much the whole language and the STL, introduces into OOP and has a decent amount of information on the more complex aspects of the language. Tbh, I haven't read any other books on C++, but I was quite satisfied with it. I still use it fairly regularly.
|
On July 17 2010 08:05 Adeny wrote:Good evening. So, I'm on a quest to learn .NET (C# specifically, maybe some of the basics for ASP if time permits) within say a year's time. I've played around with it, done some project Euler tasks and so on, so I'm fairly comfy with the syntax and the basics. Thus, my question is; What now? What do I need to be familiar with to be a competent coder, and to work in a professional environment. I'm going to make it a habit to write very clear, readable, well-commented code, but what I'm looking for is which areas of the languages do I need to be most familiar with? Please rate in order of importance what I need to know, so I can better delegate my time. Also, I love this thread, it's my replacement for the NSFW pics thread.
Some different things relating to C# and Microsoft technologies that pop up in my head:
- Check out WPF and Silverlight while you're at it -> learn XAML and the Model-View-View-Model design pattern (google it; similar to Model-View-Controller).
- Take a look at the Entity Framework.
- Take a, long, look at LINQ. If you're coming from a Java background, you'll probably see LINQ as the most compelling reason to program in C# instead.
|
|
|
|
|
|
EPT
