Linked by Thom Holwerda on Mon 3rd Sep 2012 20:46 UTC, submitted by MOS6510
General Development I like this one: "By definition, a program is an entity that is run by the computer. It talks directly to the CPU and the OS. Code that does not talk directly to the CPU and the OS, but is instead run by some other program that does talk directly to the CPU and the OS, is not a program; it's a script." Here's the other eleven.
Order by: Score:
Scripts
by panzi on Mon 3rd Sep 2012 21:20 UTC
panzi
Member since:
2006-01-22

So if you run any OS in an VM (not paravirtualized) it suddenly becomes a script?

Reply Score: 6

RE: Scripts
by c0m47053 on Mon 3rd Sep 2012 21:28 UTC in reply to "Scripts"
c0m47053 Member since:
2011-05-12

Lots of these opinions are "controversial" because they are a load of hogwash.

I don't think there was any effort to actually filter out rubbish answers.

I think you could say that it is only programming if you don't use a compiler (or even assembler), and be equally (in)valid.

Reply Score: 8

RE[2]: Scripts
by Vanders on Mon 3rd Sep 2012 21:36 UTC in reply to "RE: Scripts"
Vanders Member since:
2005-07-06

Lots of these opinions are "controversial" because they are a load of hogwash.

Hogwash and/or gibberish. For example:

If a method has a second line of code, it is a code smell. Refactor.

What does that even mean?

Having come from a coding background where you were required to know the hardware, and where this is still a vital requirements in my industry, I view high level languages as simply assembling someone else's work.


So I assume this guy programs by waving a magnetised needle over the platter. Hey, wouldn't want to be using somebodies else's work now!

Reply Score: 5

RE[3]: Scripts
by Soulbender on Mon 3rd Sep 2012 23:34 UTC in reply to "RE[2]: Scripts"
Soulbender Member since:
2005-08-18

What does that even mean?


It means the guy who said that can't code to save his life.

Reply Score: 6

RE[4]: Scripts
by sparkyERTW on Tue 4th Sep 2012 13:30 UTC in reply to "RE[3]: Scripts"
sparkyERTW Member since:
2010-06-09

"What does that even mean?


It means the guy who said that can't code to save his life.
"

Notice he was also the guy that came up with "If you have to use the scroll bar to see all of your class, your class is too big." I hope I never have to work with that guy's code.

UPDATE: Oh dear god... that guy used to be on Microsoft's C# team.

Edited 2012-09-04 13:32 UTC

Reply Score: 2

RE[5]: Scripts
by zlynx on Tue 4th Sep 2012 20:14 UTC in reply to "RE[4]: Scripts"
zlynx Member since:
2005-07-20


Notice he was also the guy that came up with "If you have to use the scroll bar to see all of your class, your class is too big."


I can agree with that, if you are using a 30" monitor and a smallish font.

Reply Score: 2

RE[5]: Scripts
by lucas_maximus on Tue 4th Sep 2012 21:07 UTC in reply to "RE[4]: Scripts"
lucas_maximus Member since:
2009-08-18

TBH I think it is a trite way of saying

"Make sure you aren't putting any unnecessary shit in there."

I see a lot of massive classes where some things could have been broken down better via inheritance.

Reply Score: 3

RE[6]: Scripts
by Soulbender on Tue 4th Sep 2012 23:51 UTC in reply to "RE[5]: Scripts"
Soulbender Member since:
2005-08-18

"Make sure you aren't putting any unnecessary shit in there."


I would hope that's not controversial.

I see a lot of massive classes where some things could have been broken down better via inheritance.


Ah but don't you know? OOP is evil incarnate.

Reply Score: 3

RE[7]: Scripts
by lucas_maximus on Wed 5th Sep 2012 00:37 UTC in reply to "RE[6]: Scripts"
lucas_maximus Member since:
2009-08-18

I always love sweeping statements when it comes to programming languages (except for PHP that does deserve a lot of hate IMHO).

Reply Score: 3

not controversial at all, just plain stupid.
by sergio on Mon 3rd Sep 2012 22:30 UTC in reply to "Scripts"
sergio Member since:
2005-07-06

x86 assembler is scripting too.

Because It's not native at all. All x86 machine code is translated internally to microcode and that microcode is the native language of today CPUs.

x86 instruction set is just a compatibility layer. So all what We write are scripts.

Reply Score: 9

RE: Scripts
by butters on Tue 4th Sep 2012 01:41 UTC in reply to "Scripts"
butters Member since:
2005-07-08

There are significant downsides to treating the hardware instruction set as a stable programming interface. Logic processors have been stuck on the Von Neumann architecture since the dawn of time because we use static optimizing compilers to target a particular hardware instruction set, and in the case of x86, it's not even a particularly convenient instruction set to implement in hardware.

Contrast this with the evolution of graphics processors, which support high-level programming interfaces via runtime interpreters plugged into the kernel device driver system which target unstable hardware architectures.

Over time, the hardware interface moved up the stack as certain operations, such as vertex shading, were factored out of the drivers and implemented in hardware. The programming model didn't change much, but the hardware changed radically.

Modern graphics processors understand compound data types like pixels, vertices, polygons, textures, and frames. Modern processors are remarkably good at integer arithmetic and boolean logic, but they don't understand the generalized sorted mapping type which dominates the architecture of most software systems.

Everything from C and UNIX filesystems to Ruby and Cassandra are based on sorted maps. At some point in the development or runtime process, each reference is translated into a key on a sorted map, which is then translated into an address in a flat linear array.

If not for statically compiled native machine code, the hardware would have evolved closer to the structured programming models that have prevailed since ALGOL, and modern processors would implement an instruction set closer to lua than x86.

Reply Score: 6

RE: Scripts
by phoudoin on Tue 4th Sep 2012 12:22 UTC in reply to "Scripts"
phoudoin Member since:
2006-06-09

Well, he didn't said that the CPU or the OS can't be virtual and guest, respectively, but only that the program should be *directly* talking to the CPU and the OS. By such definition, a program whose instructions are *directly* talking to a virtual CPU and an guest OS is still a program, not a script...

Anyway, less controversial than pseudo-elitism IMHO.

Reply Score: 3

RE: Scripts
by JuEeHa on Wed 5th Sep 2012 16:17 UTC in reply to "Scripts"
JuEeHa Member since:
2012-04-24

Also is any program using a I/O library (ie. not talking to OS directly) a script?

Reply Score: 1

Copy/Pasting
by panzi on Mon 3rd Sep 2012 21:25 UTC
panzi
Member since:
2006-01-22

"4. Copy/Pasting is not an antipattern, it fact it helps with not making more bugs"

I think what he/she means is that side effects are bad.

Reply Score: 3

RE: Copy/Pasting
by Laurence on Mon 3rd Sep 2012 22:39 UTC in reply to "Copy/Pasting"
Laurence Member since:
2007-03-26

"4. Copy/Pasting is not an antipattern, it fact it helps with not making more bugs"

I think what he/she means is that side effects are bad.

I actually kind of agree with their point. I just think they made their point terribly.

It does make a lot of sense to reuse existing code, not just because it's quicker that writing entire methods from scratch, but because (hopefully) you've already tested that code as well.

Obviously there needs to be a balance though, eg if you're having to kludge together code just to make it possible to paste source from another project, then you really should have been writing that code afresh instead of cutting corners.

But on the whole, programming is as much about reusing existing tools to fix new problems as it is about writing new tools too.

[edit]

--------------------------------------------------

10. Classes should fit on the screen. (+22/-7) by Jay Bazuzi

If you have to use the scroll bar to see all of your class, your class is too big.

Code folding and miniature fonts are cheating.


hahahaha one of my old college lecturers actually used to teach this.

Edited 2012-09-03 22:48 UTC

Reply Score: 5

Comment by Soulbender
by Soulbender on Mon 3rd Sep 2012 22:43 UTC
Soulbender
Member since:
2005-08-18

2. If it's not native, it's not really programming


Wow, second item and the bullshit-o-meter is already peaking. This is just stupid elitism.

The "While" construct should be removed from all programming languages


Yeah, because making things artificially difficult is awesome. What language has "Repeat" anyway? Does he mean "for"?

Developing on .NET is not programming. Its just stitching together other people's code.


I'm nor a fan of nor do I program in .net but this is just more elitist nonsense.

The use of try/catch exception handling is worse than the use of simple return codes and associated common messaging structures to ferry useful error messages.


And the stupidity just goes on and on. We don't have to code the same way we did in the 80's anymore. Not every language is C. It's called progress.

Object Oriented Programming is absolutely the worst thing that's ever happened to the field of software engineering.


More elitist nonsense.

Making invisible characters syntactically significant in python was a bad idea


Yes, readable code is a very bad idea. Or not. Brackets are apparently awesome though.

Classes should fit on the screen.

Because everyone's screen is the same size. So if I have a wide monitor standing on the side it's perfectly ok to have a class that's really long?


This whole thing is just some C programmer(s) that got butthurt.

Edited 2012-09-03 22:48 UTC

Reply Score: 6

RE: Comment by Soulbender
by satsujinka on Tue 4th Sep 2012 01:04 UTC in reply to "Comment by Soulbender"
satsujinka Member since:
2010-03-11

Yes, we are living in the future, so stop using exceptions and use maybes/tuples/multiple return values. Or really anything that doesn't turn your execution order into spaghetti.

Also the OOP opinion was actually very reasonable. The author was lamenting the simple fact that OO is too vague. It's hard to have rationale, scientific discussions about something when the proponents of it can't even agree what they're talking about.

Reply Score: 2

RE[2]: Comment by Soulbender
by Soulbender on Tue 4th Sep 2012 04:12 UTC in reply to "RE: Comment by Soulbender"
Soulbender Member since:
2005-08-18

Or really anything that doesn't turn your execution order into spaghetti.


Good thing that is impossible to do with return values, eh?

The author was lamenting the simple fact that OO is too vague.


Seriously, what does it matter? As long as the OO model in the language you use makes sense and you know when to use and when not to.

Reply Score: 3

RE[3]: Comment by Soulbender
by satsujinka on Tue 4th Sep 2012 06:24 UTC in reply to "RE[2]: Comment by Soulbender"
satsujinka Member since:
2010-03-11

None of the things I mentioned do it by default (you have to make the decision to have spaghetti code.) try/catch/finally does it by default. That's the whole reason you people use it.

The definition of OO matters when we want to have serious discussions about it. It's sort of hard to judge the merits of something that lacks a solid definition.

Reply Score: 1

RE[4]: Comment by Soulbender
by Soulbender on Tue 4th Sep 2012 07:51 UTC in reply to "RE[3]: Comment by Soulbender"
Soulbender Member since:
2005-08-18

That's the whole reason you people use it.


"you people"?

Reply Score: 3

RE[4]: Comment by Soulbender
by Soulbender on Tue 4th Sep 2012 07:57 UTC in reply to "RE[3]: Comment by Soulbender"
Soulbender Member since:
2005-08-18

try/catch/finally does it by default


Try/catch does not automatically create spaghetti code any more than return values and message structures.

Reply Score: 4

RE[5]: Comment by Soulbender
by kwan_e on Tue 4th Sep 2012 08:14 UTC in reply to "RE[4]: Comment by Soulbender"
kwan_e Member since:
2007-02-18

"try/catch/finally does it by default


Try/catch does not automatically create spaghetti code any more than return values and message structures.
"

Most try/catch (in Java especially) are for exceptions that normally people don't care enough about anyway, and so they catch them where needed and ignore.

So in terms of ignoring errors, they're not different. I'd prefer exceptions though if I do want to handle errors.

Reply Score: 3

RE[6]: Comment by Soulbender
by JAlexoid on Tue 4th Sep 2012 13:29 UTC in reply to "RE[5]: Comment by Soulbender"
JAlexoid Member since:
2009-05-19

Using try/catch for normal control flow is the worst idea ever.

Reply Score: 2

RE[2]: Comment by Soulbender
by sherriffwoody on Tue 4th Sep 2012 07:56 UTC in reply to "RE: Comment by Soulbender"
sherriffwoody Member since:
2012-05-25

As some new to code. I'd like an explanation or a link to one, sounds interesting..

Reply Score: 2

RE[3]: Comment by Soulbender
by satsujinka on Tue 4th Sep 2012 16:58 UTC in reply to "RE[2]: Comment by Soulbender"
satsujinka Member since:
2010-03-11

About what? Error handling? OO being a poorly defined concept that no two people agree on? (well, that's an exaggeration, I'm sure you can find two people who agree; the point is simply that there's a lot of dispute even between proponents.)

Reply Score: 1

RE: Comment by Soulbender
by sergio on Tue 4th Sep 2012 02:01 UTC in reply to "Comment by Soulbender"
sergio Member since:
2005-07-06

"2. If it's not native, it's not really programming


Wow, second item and the bullshit-o-meter is already peaking. This is just stupid elitism.
"

Pseudo-elitism.

Any interpreted functional language like LISP or Haskell is way harder and sophisticated than most native procedural language like C or even ASM.

Reply Score: 4

...
by Hiev on Mon 3rd Sep 2012 23:22 UTC
Hiev
Member since:
2005-09-27

What language has "Repeat" anyway?

Pascal.

Oh and in C that would be the do..while cycle.

Edited 2012-09-03 23:28 UTC

Reply Score: 4

RE: ...
by Soulbender on Mon 3rd Sep 2012 23:28 UTC in reply to "..."
Soulbender Member since:
2005-08-18

Oh right, I had forgot about. Been a long time since I used Pascal.
I certainly wouldn't say that is a better language construct than "while" though.

Oh and in C that would be the do..while cycle.


Nah, that has the evil word "while" in it. We can't have that ;)

Edited 2012-09-03 23:29 UTC

Reply Score: 4

RE[2]: ...
by Hiev on Mon 3rd Sep 2012 23:30 UTC in reply to "RE: ..."
Hiev Member since:
2005-09-27

And is not the same, do..while(repeat) will execute the cycle at least once, the while cycle may not get to be executed at all, obviously the guy making such statement is clueless.

Reply Score: 3

RE[3]: ...
by Soulbender on Mon 3rd Sep 2012 23:40 UTC in reply to "RE[2]: ..."
Soulbender Member since:
2005-08-18

Yeah, the guy is obviously clueless or trolling to be controversial.

From stackoverflow:

One common mistake new programmers make with While is they assume that the code will break as soon as the tested condition flags false.


That's a common mistake? If that's the kind of people he works with I'm afraid of what kind of software they would create.

Reply Score: 4

RE[4]: ...
by Laurence on Mon 3rd Sep 2012 23:59 UTC in reply to "RE[3]: ..."
Laurence Member since:
2007-03-26

Yeah, the guy is obviously clueless or trolling to be controversial.

To be honest, I thought that was the whole point of the Stack Overflow thread and the reason for the Bill The Lizard follow up too.

Nobody said those opinions had to be valid; only that they had to be controversial.

Reply Score: 2

RE[5]: ...
by Soulbender on Tue 4th Sep 2012 00:16 UTC in reply to "RE[4]: ..."
Soulbender Member since:
2005-08-18

Well, you can be controversial and make a good point (like 2 of those suggestions) or you can be completely in the wrong and controversial for the sake of being controversial.

Reply Score: 2

RE[5]: ...
by Vanders on Tue 4th Sep 2012 13:11 UTC in reply to "RE[4]: ..."
Vanders Member since:
2005-07-06

Nobody said those opinions had to be valid; only that they had to be controversial.


That doesn't make any sense either. If you don't need to make sense just for the sake of being controversial, then how about these?

1. Everyone should always write code using two toes of their choice but only from their left foot.
2. No function should ever be more than 82 lines of code, except on a Tuesday when they should be no more than 81 and 83 lines long.
3. Every single programmer should learn COBOL. No exceptions.
4. Always name your variables as anagrams of the word "hexaphene"
5. Never compile your code after dark.
6. The letter 'y' should be banned from use in Java.

Reply Score: 3

RE[6]: ...
by Laurence on Tue 4th Sep 2012 13:26 UTC in reply to "RE[5]: ..."
Laurence Member since:
2007-03-26


That doesn't make any sense either. If you don't need to make sense just for the sake of being controversial, then how about these?

1. Everyone should always write code using two toes of their choice but only from their left foot.
2. No function should ever be more than 82 lines of code, except on a Tuesday when they should be no more than 81 and 83 lines long.
3. Every single programmer should learn COBOL. No exceptions.
4. Always name your variables as anagrams of the word "hexaphene"
5. Never compile your code after dark.
6. The letter 'y' should be banned from use in Java.

To be fair, you might have valid point with #5. ;-)

Reply Score: 3

C++
by kwan_e on Tue 4th Sep 2012 00:46 UTC
kwan_e
Member since:
2007-02-18

9. C (or C++) should be the first programming language (+24/-5) by hansen j

The first language should NOT be the easy one, it should be one that sets up the student's mind and prepare it for serious computer science.
C is perfect for that, it forces students to think about memory and all the low level stuff, and at the same time they can learn how to structure their code (it has functions!)


As a C++ apologist, I strongly disagree. I didn't start out on C/C++ and I sure as hell bet that all C/C++ proponents started out on simpler languages, even if they refuse to remember or acknowledge the first time they dabbled.

I started out on BASIC, Q and Casio, and through it learned how to structure complex programs even if the language doesn't seemingly allow it. Then I was forced to learn Pascal during high school because the teacher didn't know C. Of course, also learnt a bit of javascript along the way since making dynamic webpages were the thing to do.

By this idiot's logic, people should start with assembler. Assembler for modern architectures have a lot of structured programming extensions too. But pedagogy is not the same as bragging rights. The real issue with pedagogy in any language, programming or human, is how to express ideas succintly and concisely.

C++ has the added advantage that it really sucks ;) thus the students will understand why people had to come up with Java and C#.


I admit that it was learning Java at university (course standard, if not requirement) and then Python (self taught) that I understood many important programming and design principles. But those principles were what drew me BACK to C++. Once you read the stuff by Stroustrup and Sutter, they open your eyes to what C++'s proper usage is and how to choose which features not to use for which problems.

I think all the people who hate C++ are simply reacting out of fear. Early in their experience, they came across a problem they couldn't fix right away. Rather than facing their fears, they just reacted and cower for safety with garbage collection and inheritance and factories up the yin-yang.

In my experience neither Java or C# solves any problems in C++. They just have better IDEs and graphical debuggers, but that's about it.

Reply Score: 3

RE: C++
by satsujinka on Tue 4th Sep 2012 01:13 UTC in reply to "C++"
satsujinka Member since:
2010-03-11

I'm a C proponent who started in C++...

Personally, my (biggest) issue with C++ is that it's simply too large of a language. If you get 10 people who say they know C++ chances are good that the only overlap is going to be the subset of C++ that is C.

C++ also reinvents a bunch of things from C (such as I/O) and it's debatable whether it actually improved them.

tl;dr. C++'s flexibility is both its strength and its weakness. It allows you to do all sorts of crazy things, but at the end of the day they're still crazy.

Reply Score: 5

RE[2]: C++
by kwan_e on Tue 4th Sep 2012 01:49 UTC in reply to "RE: C++"
kwan_e Member since:
2007-02-18

Personally, my (biggest) issue with C++ is that it's simply too large of a language. If you get 10 people who say they know C++ chances are good that the only overlap is going to be the subset of C++ that is C.


Yes, but the people who are really proficient with C++ will use the STL, which has no overlap with C, because C simply does not have the facility.

The biggest issue with C++ are people who come from it from the C perspective and don't use the language features that promote safety. The easiest thing, first of all, is to use vectors and strings rather than arrays. The next easiest is to use RAII rather than dynamic allocation.

C++ also reinvents a bunch of things from C (such as I/O) and it's debatable whether it actually improved them.


I wouldn't call it reinvention. They just OO'd some of the tedious bits.

tl;dr. C++'s flexibility is both its strength and its weakness. It allows you to do all sorts of crazy things, but at the end of the day they're still crazy.


I haven't had to do a crazy thing in C++ at all. Have a look at Qt. Aside from the MOC (which translates to standard C++ anyway), there is nothing crazy with Qt.

Reply Score: 5

RE[3]: C++
by satsujinka on Tue 4th Sep 2012 07:11 UTC in reply to "RE[2]: C++"
satsujinka Member since:
2010-03-11

Except the STL is almost entirely duplicate functionality. list and map are the only new containers. Everything else is either a duplicate or a minor change away from being a duplicate.

Vectors don't really make life easier. And RAII is only useful if you're doing OO.

The C I/O functions work at least as well as C++'s, even on objects.

Honestly, I think Qt is crazy, but most GUI programming is.

Reply Score: 0

RE[4]: C++
by kwan_e on Tue 4th Sep 2012 08:09 UTC in reply to "RE[3]: C++"
kwan_e Member since:
2007-02-18

Except the STL is almost entirely duplicate functionality. list and map are the only new containers. Everything else is either a duplicate or a minor change away from being a duplicate.


Set, queue, deque, unordered (hash), heap. If by "minor change" you mean lack of manual memory management, then yeah. But I would call that an improvement.

Bunch of standard algorithms. Smart pointers. Concurrency.

Let's not forget that C++ allows things like Boost to happen.

Vectors don't really make life easier. And RAII is only useful if you're doing OO.


So you like having to explicitly allocate and deallocate memory? Even with C99 variable length arrays, you can't easily push or pop or insert or delete items or resize without the possibility of introducing bugs. Then you also have to manually keep track of the length of the array in case you don't use the whole thing.

The C I/O functions work at least as well as C++'s, even on objects.


And?

Honestly, I think Qt is crazy, but most GUI programming is.


Then in no way can you say anything about C++. C++ is designed for complicated things, like GUI programming for example.

Reply Score: 4

RE[5]: C++
by satsujinka on Tue 4th Sep 2012 17:36 UTC in reply to "RE[4]: C++"
satsujinka Member since:
2010-03-11

All those containers are duplicates of other containers in the STL. Also, Boost is a nightmare, not a benefit.

If you can't manage an array, then you have no right to be talking about "complicated things." Arrays are not difficult things to work with. Push, pop, insert, and delete are all straight forward functions (that C should have defined, but I digress.) Keeping track of the length is also not difficult (and can be managed by the push/pop/insert/delete functions.)

GUI programming is not crazy because it's complicated, it simply isn't complicated. It's tedious. But more to the point, the current style of GUI programming is crazy because it ignores good coding conventions )such as reduction of coupling.) This is practically a requirement of most GUI frameworks, because they insist on ignoring the fact that they're dealing with a reactive system. Instead of making themselves reactive, they use the event model (which only poorly emulates the desired properties, because it requires explicit handling of events.)

Reply Score: 1

RE[6]: C++
by kwan_e on Tue 4th Sep 2012 23:31 UTC in reply to "RE[5]: C++"
kwan_e Member since:
2007-02-18

All those containers are duplicates of other containers in the STL. Also, Boost is a nightmare, not a benefit.


Only because it's obvious you have no idea how to code C++ properly.

If you can't manage an array, then you have no right to be talking about "complicated things." Arrays are not difficult things to work with. Push, pop, insert, and delete are all straight forward functions (that C should have defined, but I digress.) Keeping track of the length is also not difficult (and can be managed by the push/pop/insert/delete functions.)


And yet the number one security defect continues to be caused by buffer overruns and other low level array management. It's not about difficulty, it's about SAFETY.

If you're more concerned about bragging rights rather than doing the Right Thing, you have no right to be programming for a job at all. Why the hell should people waste time writing the same array management stuff over and over again, introducing bugs (even the best of us still do), when we already have a library that does it.

Reply Score: 4

RE[7]: C++
by satsujinka on Wed 5th Sep 2012 05:40 UTC in reply to "RE[6]: C++"
satsujinka Member since:
2010-03-11

Sets, queues, and stacks are all lists. They have slight restrictions, but that's the very definition of "minimal change." Boost is quite commonly regarded as a major example of terrible software (by the non-C++ using community.)

It is about difficulty, because I've already enumerated how to use arrays safely. Pointing out that lots of developers have bad habits is simply a red herring. I've already mentioned that I wish array manipulation had been included in the stdlib, but you can find/make a library for it as well. The only reason that buffer overflows are still so common is that many developers have NIH syndrome (or are simply ignorant about what's available to them, a problem that C++ doesn't solve.)

Reply Score: 1

RE[3]: C++
by JAlexoid on Tue 4th Sep 2012 13:30 UTC in reply to "RE[2]: C++"
JAlexoid Member since:
2009-05-19

Yes, but the people who are really proficient with C++ will use the STL, which has no overlap with C, because C simply does not have the facility.

Lets agree on one thing - proficient and intelligent people will use the best available tools and abuse their strengths. This is language independent.
A proficient and intelligent person will take a turd and make diamonds out of the carbon it it.

Problem with C++ is that it's so wide that finding a group of people that think the same way about C++ is virtually impossible.

I haven't had to do a crazy thing in C++ at all. Have a look at Qt. Aside from the MOC (which translates to standard C++ anyway), there is nothing crazy with Qt.

He said allows, it doesn't mean that everyone is doing crazy things. Though C++ developers tend to veer off quite often into crazy stuff.

Reply Score: 2

RE[4]: C++
by kwan_e on Tue 4th Sep 2012 14:47 UTC in reply to "RE[3]: C++"
kwan_e Member since:
2007-02-18

Problem with C++ is that it's so wide that finding a group of people that think the same way about C++ is virtually impossible.


I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.

Conversely, I think you highlighted the best thing about C++ and is certainly one of the design goals Stroustrup had in mind. It allows the programmers to choose the style that fits a problem best.

I would hope that a person using C++ to write a webserver would have a completely different idea of how to use it to a person who uses C++ to write a game, or a realtime controller, or a stock exchange, or a highly parallel physics simulator, or a compiler.

Reply Score: 3

RE[5]: C++
by satsujinka on Tue 4th Sep 2012 17:10 UTC in reply to "RE[4]: C++"
satsujinka Member since:
2010-03-11

A better solution is to group styles into different languages.

That way you have clear definitions of what features to expect. If you have two devs who say "I know X", it means you can be reasonably sure that they can check each other's work.

Additionally, say we have a section of code that should be pure (functional.) We can do that in C++, but there's no guarantee that someone won't come by and make it impure. If we instead require a pure language, then this issue never comes up. The restrictions of each language give you guarantees about the characteristics of the code, making it easier to reason about.

If you have every feature available all the time, then the code quickly and easily becomes more complicated than it has any right to be. You have to manually restrain yourself with C++; you simply don't have to do that with simpler languages.

Now, I'll admit that cross-talk between languages is currently kind of a pain. Most languages really only interface well with C... and even then not necessarily well. So maybe it makes sense to use C++, for now, but that doesn't mean that C++ isn't an issue.

Reply Score: 2

RE[5]: C++
by JAlexoid on Tue 4th Sep 2012 23:11 UTC in reply to "RE[4]: C++"
JAlexoid Member since:
2009-05-19

I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.


I think I already expressed this from a perspective of a person that has to hire developers to develop and maintain a codebase.
When you are a lone star programmer - C++ is great.
When you have to work with a large group of people - then it becomes a problem.

And no, there are not two ways of doing things in C++, there are thousands. In short - too many to be good for assembling and maintaining a team.

Reply Score: 2

RE[6]: C++
by kwan_e on Tue 4th Sep 2012 23:35 UTC in reply to "RE[5]: C++"
kwan_e Member since:
2007-02-18

"I fail to see why this is a problem. The multi-style nature of C++ is better than trying to cram every problem into an OO or functional or message passing style.


I think I already expressed this from a perspective of a person that has to hire developers to develop and maintain a codebase.
When you are a lone star programmer - C++ is great.
When you have to work with a large group of people - then it becomes a problem.
"

And that's the fault of the language is it?

And no, there are not two ways of doing things in C++, there are thousands. In short - too many to be good for assembling and maintaining a team.


As another person pointed out, there is a large overlap between C++ and C. So in practice, most people actually do have similar ideas about C++.

You're confusing design with code. Programmers will always have different ideas about what DESIGN to use, whatever language it's implemented in.

Compared to languages like Python and Lisp and Java, C++ is no worse off in the different language facilities that people think of using.

Reply Score: 2

RE[7]: C++
by JAlexoid on Wed 5th Sep 2012 02:07 UTC in reply to "RE[6]: C++"
JAlexoid Member since:
2009-05-19

And that's the fault of the language is it?

A problem doesn't mean fault. (See hardware drivers for FOSS OS'es)
Also, you're being defensive.

Reply Score: 3

OOPs
by kwan_e on Tue 4th Sep 2012 00:56 UTC
kwan_e
Member since:
2007-02-18

8. Object Oriented Programming is absolutely the worst thing that's ever happened to the field of software engineering. (+34/-14) by Breton

The primary problem with OOP is the total lack of a rigorous definition that everyone can agree on. This easily leads to implementations that have logical holes in them, or language like Java that adhere to this bizarre religious dogma about what OOP means, while forcing the programmer into doing all these contortions and "design patterns" just to work around the limitations of a particular OOP system.


Lack of rigorous definition is not a problem with OO. It is the fact that the real world does not play nice with neat concepts and principles. The real world does what it wants and you have to adapt.

OO is just one of many ways to adapt. Design patterns are another. OO and design patterns are almost orthogonal to each other, and are orthogonal to other concerns like performance or parallelism.

The design patterns a lot of Java frameworks go for is not because of getting around the limitations of its OO implementation, but because a few zealots spread the meme that everything needed a design pattern for every little thing. Java just happened to be co-opted for it because, in a way, it was designed with design patterns in mind.

Reply Score: 4

RE: OOPs
by satsujinka on Tue 4th Sep 2012 01:23 UTC in reply to "OOPs"
satsujinka Member since:
2010-03-11

There's an oft ignored fact that design patterns are really just missing features. Each and every single GoF design pattern is just a language feature. For example, the Command pattern is completely pointless if you have first class functions. Composite and Decorator are just recursive unions (of differing multiplicity.) Adapter, Bridge, and Facade are just use cases for composition.

I can do this all day, I did a semester project on cross-language implementation comparisons using design patterns as a goal.

I should probably mention that all languages have "design patterns," it's completely insane to include every single possible feature in a language (such that you'd have a feature for every macro-structure you can concieve of.)

Reply Score: 1

RE: OOPs
by ndrw on Tue 4th Sep 2012 01:49 UTC in reply to "OOPs"
ndrw Member since:
2009-06-30

I remember being utterly confused after reading books on OOP back in '90s. Authors often bundled other concepts with OOP, making it almost impossible to figure out what all the fuss is about.

In particular, OOP has nothing to do with:
- types or access modifiers - that's encapsulation,
- inheritance/mixins - that's code reuse,
- any particular coding style - that's plumbing,
- patterns - that's cooking recipes.
They are all useful techniques, it's just they have nothing to do with OOP.

Object oriented programming is really about having a bunch of objects (separable entities "living their own lives") communicating with each other. It's really as simple as that, yet very few OO programs or frameworks fit this definition.

For example, in another post I mentioned Kay's "setters are evil" rule. Why? For the same reason any mutation is evil. Calling a setter means taking control out of a target object and placing it in the calling one. So the target object is no longer a separate entity and becomes just a dumb storage of fields others may fiddle with - a data structure. This puts the calling object in business of coordinating changes and ensuring consistency of the target object state, which requires a lot more knowledge than just the API.

Reply Score: 6

RE[2]: OOPs
by kwan_e on Tue 4th Sep 2012 02:08 UTC in reply to "RE: OOPs"
kwan_e Member since:
2007-02-18

One of the worst confusion is that UML and OO are interchangeable. It makes it way too easy to over-design a solution to any problem.

Reply Score: 3

RE[3]: OOPs
by lucas_maximus on Tue 4th Sep 2012 20:59 UTC in reply to "RE[2]: OOPs"
lucas_maximus Member since:
2009-08-18

The only UML diagram I think any one uses regularly is the UML class diagram. That is where the confusion lies.

I haven't really used UML except for class diagrams since university.

We were told not to use Flow Diagrams at University, but they are pretty good for non-developers to see a high level flow of logic and developers can just follow it through in a debugger if need be (Our codebase is very bad).

Edited 2012-09-04 20:59 UTC

Reply Score: 2

RE[4]: OOPs
by kwan_e on Wed 5th Sep 2012 07:24 UTC in reply to "RE[3]: OOPs"
kwan_e Member since:
2007-02-18

The only UML diagram I think any one uses regularly is the UML class diagram. That is where the confusion lies.

I haven't really used UML except for class diagrams since university.

We were told not to use Flow Diagrams at University, but they are pretty good for non-developers to see a high level flow of logic and developers can just follow it through in a debugger if need be (Our codebase is very bad).


Strangely, I think UML class diagrams are perhaps the most useless UML diagram. They're pain to make, class design changes all the time, and thus they're a pain to update.

Regarding flow diagrams, I find UML sequence diagrams to be a better replacement.

For me, the trick with UML and any diagramming language is not to go into any detail. Anything more than a brief outline is even more ridiculous to maintain and keep accurate than code itself.

Reply Score: 3

RE[5]: OOPs
by lucas_maximus on Wed 5th Sep 2012 12:44 UTC in reply to "RE[4]: OOPs"
lucas_maximus Member since:
2009-08-18

Strangely, I think UML class diagrams are perhaps the most useless UML diagram. They're pain to make, class design changes all the time, and thus they're a pain to update.


The IDE can be be configured to provide a set.

I don't use them for large projects with several thousand files, I used them as documentation for a particular component or set of components.

They don't necessarily have to be totally up-2-date. As long as I see how the classes fit together it is better than "Find All References" in VS and trying to fit it all together in my head.

Regarding flow diagrams, I find UML sequence diagrams to be a better replacement.


For non-technical people such as Project Managers or a Higher a flow diagram is quite easy to understand.

For me, the trick with UML and any diagramming language is not to go into any detail. Anything more than a brief outline is even more ridiculous to maintain and keep accurate than code itself.


I mostly work with .NET and Front End Web Tech. I find UML mostly redundant for what I do unless it is specifying either class diagrams or part of the ORM for the Data Access Layer.

Reply Score: 3

My favorites
by ndrw on Tue 4th Sep 2012 01:01 UTC
ndrw
Member since:
2009-06-30

Not particularly controversial but not widely adopted either:

Programs must be written for people to read, and only incidentally for machines to execute.
Harold Abelson

[...] when you have an setter on an object you turned it back into a data structure.
Alan Kay


Any sweeping rules should at most be treated as guidelines. What ultimately matters is the result, not the process.

Reply Score: 3

Popcorn anyone?
by bitwelder on Tue 4th Sep 2012 06:56 UTC
bitwelder
Member since:
2010-04-27

My suggestion: post it to /. and go get a big bowl of popcorn ;)

Reply Score: 8

jido
Member since:
2006-03-06

I agree that exceptions are often ignored when they should be handled with an intelligible error message.

But I disagree that using error structures is a solution. Firstly it is not reasonable to rely on tooling to verify that all error values are tested. Second it is just awkward to return an error structure with each function.

At least, the stack trace printed by a logged exception can be used by developers to locate the issue. Not great, but much better than continuing with erroneous data (in the case of an ignored error value)

I don't think singletons should be used. If you think you need one, use a function which returns an unique object- at least you have the option to generate more of this object if needed, while if you use a real singleton this is not possible.

Reply Score: 1