Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Dessert Rose
May 17, 2004

awoken in control of a lucid deep dream...
I used to be the opposite, never wanting to subclass anything if I could find some way to do what I wanted using just vanilla Cocoa objects.

It's not that bad by itself, but I was spending hours trying to find ways around subclassing something and overriding a single method.

Adbot
ADBOT LOVES YOU

No Safe Word
Feb 26, 2005

Janin posted:

The problem with C++ is that something like 90% of it is actively harmful to writing working code. Sure, it works fine if you take away exceptions, overloading, templates, multiple inheritance, <iostream>, and write your own string type. But at that point, it's easier to just use C so you don't have to deal with the generally low quality of C++ compilers.

This is the horror.

ctz
Feb 6, 2003

No Safe Word posted:

This is the horror.

Thanks for the insightful post.

Exceptions are very difficult to use and /massively/ increase the cyclic complexity of all code which uses them, even if the code in question doesn't throw or catch an exception. An awful lot of C++ is non-obviously exception unsafe, including specifications produced by the C++ standards committee, and boost.

Overloading is good conceptually, but C++ implements it in an over-complex and gratuitously painful way. Compare over.match with the corresponding text in ECMA-334.

Templates are best used as a type-aware preprocessor. Template meta-programming is not much more than a party trick. I've never seen it as a non-trivial part of a real-world program. But that doesn't stop C++ compilers having to become ridiculously complex to support it :)

Witness how long it has taken clang to get basic parts of a C++ compiler working, the slow uptake of C++0x features in mainstream compilers, and the lovely quality of gcc and commercial UNIX C++ compilers.

<iostream> is a total abortion. Not only does it favour the implicit over the explicit in its design, it also has a worthless error handling system and pulls in a shed-load of code even if you just wanted to print 'hello, world'.

C++ taken as a whole is a horrible language. It's only saving grace is its roots in C, and the ability to avoid paying for the lovely parts nobody sane ever uses.

TOO SCSI FOR MY CAT
Oct 12, 2008

this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

ctz posted:

Overloading is good conceptually, but C++ implements it in an over-complex and gratuitously painful way. Compare over.match with the corresponding text in ECMA-334.

My personal grudge against overloading is that it makes writing bindings a tremendous pain in the rear end. The easiest way to bind a C++ library is to write a C API for it, and then bind that.

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh

ctz posted:

Witness how long it has taken clang to get basic parts of a C++ compiler working, the slow uptake of C++0x features in mainstream compilers, and the lovely quality of gcc and commercial UNIX C++ compilers.

You mean the standard that hasn't even been finalized yet and has most of its key features already implemented in production compilers? Oh yeah.

I'm not even going to bother addressing your other points except to agree that iostreams is poo poo, but who the gently caress uses iostreams?

Flobbster
Feb 17, 2005

"Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"
C++0x should have just deprecated iostreams, issued a public apology for misusing the shift operators in a misguided attempt to circlejerk about how cool operator overloading was at the time, and then provided in the new standard a type-safe printf using variadic templates where arguments are converted to strings by using some sort of printf_formatter functor template that can be specialized by the user for custom types.

I kind of want to implement this now instead of doing the work I'm supposed to be doing.

ColdPie
Jun 9, 2006

Flobbster posted:

C++0x should have just deprecated iostreams, issued a public apology for misusing the shift operators in a misguided attempt to circlejerk about how cool operator overloading was at the time, and then provided in the new standard a type-safe printf using variadic templates where arguments are converted to strings by using some sort of printf_formatter functor template that can be specialized by the user for custom types.

I kind of want to implement this now instead of doing the work I'm supposed to be doing.

This and enum classes would by themselves be enough for a new standard.

Painless
Jan 9, 2005

Turn ons: frogs, small mammals, piles of compost
Turn offs: large birds, pitchforks
See you at the beach!
Also remove exceptions, dynamic_cast and typeid and add restrict from C99, I don't care how much the standard committee :qq:s about how hard it is to define
The language would be almost usable and most C users would have no more excuses
and then remove virtual because class-based polymorphism is an abomination

Avenging Dentist
Oct 1, 2005

oh my god is that a circular saw that does not go in my mouth aaaaagh

Painless posted:

Also remove exceptions, dynamic_cast and typeid and add restrict from C99, I don't care how much the standard committee :qq:s about how hard it is to define
The language would be almost usable and most C users would have no more excuses
and then remove virtual because class-based polymorphism is an abomination

Pretty sure the only one :qq:ing is you

shrughes
Oct 11, 2008

(call/cc call/cc)
Speaking of coding horrors, I created one today:

code:
char *replaceEntities(char *to, const char *from, size_t n) {
	const char *end = from + n;
	const char *r = from;
	char *w = to;
		
	while (r < end) {
		char x = *r++;
		if (x == '&') {
			if (r < end) {
				const char *tmp = r;
				char y = *tmp;
				if (y == '#') {
					// decimal code or hex code?  Meh, we're assuming decimal code.
					
					tmp++;
					const char *tmptmp = tmp;
					int num = readNonNegativeNumber(&tmptmp, end);
					if (tmp < tmptmp && tmptmp < end && *tmptmp == ';' && num < 256) {
						r = tmptmp + 1;
						*w++ = num;
					} else {
						*w++ = x;
					}					
				} else {
					// Only do the common entities...
					if (eatThroughString(&tmp, end, "lt;")) {
						r = tmp;
						*w++ = '<';
					} else if (eatThroughString(&tmp, end, "gt;")) {
						r = tmp;
						*w++ = '>';
					} else if (eatThroughString(&tmp, end, "quot;")) {
						r = tmp;
						*w++ = '"';
					} else if (eatThroughString(&tmp, end, "apos;")) {
						r = tmp;
						*w++ = '\'';
					} else if (eatThroughString(&tmp, end, "amp;")) {
						r = tmp;
						*w++ = '&';
					} else {
						*w++ = x;
					}
				}
			} else {
				*w++ = x;	
			}
		} else {
			*w++ = x;
		}
	}
	return w;
}


// hilarious
NSString *initEntityString(NSString *allocedString, const char *beg, const char *end) {
	size_t n = end - beg;
	char *buf = malloc(n);
	char *bufEnd = replaceEntities(buf, beg, n);
	return [allocedString initWithBytesNoCopy:buf length:bufEnd-buf encoding:NSUTF8StringEncoding freeWhenDone:YES];
}
It works as specified :colbert:

1337JiveTurkey
Feb 17, 2005

Toady posted:

On a somewhat related note, why are many new coders full of distrust and want to roll things on their own? No matter how much you tell them it's a bad idea, they will not listen to you. They'll even be polite about it, but you'll never convince them otherwise.

We teach new coders how to write programs that open a file, read a character stream from them, parse it and then write it to another file. We don't teach them how to do the same task with an ESB and data binding API. When I graduated from college, I didn't really trust the libraries and frameworks I now consider indispensable because I didn't understand them but I did understand the Unix model and I did understand how to parse character streams. It took experience before I could really appreciate the level of abstraction that they operated at, and I gained some of that experience by reinventing the wheel on occasion.

Dessert Rose
May 17, 2004

awoken in control of a lucid deep dream...

1337JiveTurkey posted:

We teach new coders how to write programs that open a file, read a character stream from them, parse it and then write it to another file. We don't teach them how to do the same task with an ESB and data binding API. When I graduated from college, I didn't really trust the libraries and frameworks I now consider indispensable because I didn't understand them but I did understand the Unix model and I did understand how to parse character streams. It took experience before I could really appreciate the level of abstraction that they operated at, and I gained some of that experience by reinventing the wheel on occasion.

My favorite method of learning a new codebase is still "holy poo poo all this code sucks let's rewrite this method" followed by "hey this code isn't actually so bad because it has to do ...."

Lather rinse repeat until you've pretty much rewritten and then undone the change for every method.

Jonnty
Aug 2, 2007

The enemy has become a flaming star!

Ryouga Inverse posted:

My favorite method of learning a new codebase is still "holy poo poo all this code sucks let's rewrite this method" followed by "hey this code isn't actually so bad because it has to do ...."

Lather rinse repeat until you've pretty much rewritten and then undone the change for every method.

I do this with my own code. "Hey, this bit's silly, why didn't I use <library function>!? Oh, but wait, I have to check for...and, ah yes, it doesn't work when...ok, now I remember why."

jonjonaug
Mar 26, 2010

by Lowtax

Janin posted:

The problem with C++ is that something like 90% of it is actively harmful to writing working code. Sure, it works fine if you take away exceptions, overloading, templates, multiple inheritance, <iostream>, and write your own string type. But at that point, it's easier to just use C so you don't have to deal with the generally low quality of C++ compilers.

I get all of this except the last part. What's wrong with <string>?

shrughes
Oct 11, 2008

(call/cc call/cc)

jonjonaug posted:

I get all of this except the last part. What's wrong with <string>?

It deep-copies, it's mutable, it's a sequence of bytes with no encoding, it's made out of some kind of basic_string miasma, it's expensive to concatenate, it's inconvenient in the standard library to convert stuff to or from them, with nothing like String.Format or other good things, and it's written in C++, and it's pretty much like the rest of the STL, which is unbragable.

BattleMaster
Aug 14, 2000

Janin posted:

The problem with C++ is that something like 90% of it is actively harmful to writing working code. Sure, it works fine if you take away exceptions, overloading, templates, multiple inheritance, <iostream>, and write your own string type. But at that point, it's easier to just use C so you don't have to deal with the generally low quality of C++ compilers.

To be totally honest I think that templates make up 99% of the stuff people bitch about.

Toady
Jan 12, 2009

Flobbster posted:

The second one is just foolish, but I can understand the first and the third points. When I made the switch to OS X a few years ago, coming from a Windows development background it took me a little bit of time to really understand how Interface Builder worked differently from, say, the Windows dialog resource editor (:gonk:) or the Windows Forms editor.

The third point might come from that same mindset, where on Windows, almost everything is customized by subclassing and overriding methods. The delegation pattern that OS X makes so much use of is almost nonexistent there, so it's a big mental shift when you first get started.

Now if these are programmers with years of OS X experience wanting to do these things, gently caress 'em.

I'm saying that these new developers know they didn't have to do things manually, but they insist on doing them out of a distrust of the system and a fear of things that seem magical. The common reason I hear is that they want to do everything themselves "to learn," but it doesn't help them learn at all. Avoiding IBOutlets, for example, is just silly and cumbersome.

As for the third point, it's a single method call to set a double-click action for a table view. :)

1337JiveTurkey posted:

We teach new coders how to write programs that open a file, read a character stream from them, parse it and then write it to another file. We don't teach them how to do the same task with an ESB and data binding API. When I graduated from college, I didn't really trust the libraries and frameworks I now consider indispensable because I didn't understand them but I did understand the Unix model and I did understand how to parse character streams. It took experience before I could really appreciate the level of abstraction that they operated at, and I gained some of that experience by reinventing the wheel on occasion.

There's a big difference between that and what I'm talking about, which is avoiding fundamental things like NIB files because IBOutlets (which are just pointers) just don't seem as cool and hardcore as writing out a bunch of pointless setup code that's equivalent to 10 seconds spent in Interface Builder. It's emotion-based programming.

Toady fucked around with this message at 02:06 on Apr 15, 2010

ErIog
Jul 11, 2001

:nsacloud:
I'm not sure there's any distrust. I just think it's human nature. They want to do something. They think they an accomplish it using stuff they already know rather than learning something new. They think learning that something new is going to take way more time than doing it with what they already know, but they don't realize they're going about it completely the wrong way. So they get a bunch of hours down a path they have to throw away before they realize they should have just done some reading in the first place.

Fecotourist
Nov 1, 2008

Ryouga Inverse posted:

My favorite method of learning a new codebase is still "holy poo poo all this code sucks let's rewrite this method" followed by "hey this code isn't actually so bad because it has to do ...."

Lather rinse repeat until you've pretty much rewritten and then undone the change for every method.

If the code works at all, chances are it's in some kind of local minimum, so changing any one thing at a time doesn't help. Replacing a dumb thing with something smart doesn't work if it has to work within a whole interconnected system of dumb.

evensevenone
May 12, 2001
Glass is a solid.

ErIog posted:

I'm not sure there's any distrust. I just think it's human nature. They want to do something. They think they an accomplish it using stuff they already know rather than learning something new. They think learning that something new is going to take way more time than doing it with what they already know, but they don't realize they're going about it completely the wrong way. So they get a bunch of hours down a path they have to throw away before they realize they should have just done some reading in the first place.

Also, if you started programming in the 90s like a lot of middle-aged developers that never really went anywhere, you probably went to school at a time when none of the standard libraries actually worked, and you've spend the last 15 years having idiots tell you to adopt new buzzwords. And you can get away with an awful lot being a 95% procedural C++ programmer that only gets into OO as a way to keep their functions organized.

BattleMaster
Aug 14, 2000

evensevenone posted:

And you can get away with an awful lot being a 95% procedural C++ programmer that only gets into OO as a way to keep their functions organized.

Probably because most C++ features are syntactic sugar for things you can do in C easily enough

Brain Candy
May 18, 2006

BattleMaster posted:

Probably because most C++ features are syntactic sugar for things you can do in C easily enough

It's almost like syntactic sugar is the only thing that differentiates Turning complete languages! :v:

raminasi
Jan 25, 2005

a last drink with no ice

Brain Candy posted:

It's almost like syntactic sugar is the only thing that differentiates Turning complete languages! :v:

I hope this is just a typo!

ShoulderDaemon
Oct 9, 2003
support goon fund
Taco Defender

GrumpyDoctor posted:

I hope this is just a typo!

Haskell can make 2 complete turns.

Brain Candy
May 18, 2006

The extra n is for emphasis. Or something.

abiogenesis
Feb 4, 2009
I'm not sure how to feel about this, I'll listen to your input.

I sent an email to a professor regarding a programming practice she wants us to do:

My email posted:

How do you feel about writing it this way:

code:
/* main */

name = scan.nextln();
room = scan.nextInt();
hotel.register(name, room); // makes intuitive sense

/* Bates.java */

public void register(String name, int room) {
    /* do things */
}
instead of this:

code:
/* main */

hotel.register(scan);

/* Bates.java */

public void register(Scanner scan) {
    /* have to pass the Scanner from main
     * read from the keyboard
     * AND do everything else in here
     * while making it near impossible for other people to implement your class
     */
}
because passing Scanner objects to methods just makes me :(

and she responded with this:

quote:

Makes intuitive sense but not object -oriented sense. Everything about
registering a guest should be in register. This program could be used by
another driver program, be inherited and enhanced. You don't want to
leave part of the functionality behind when you use it someplace else.

She wants us to pass the keyboard scanner to every method we use that takes input instead of getting the input in the main part of the program and then passing it to the method. She does the same things in terms of passing the scanner to a method in a completely different class.

She says it makes the method more functional but to me focusing on taking in the data you want to use allows it to be more generalizable, easy to use, and clear as to what the method actually does.

Please tell me I'm not the horror :(

evensevenone
May 12, 2001
Glass is a solid.
If you do it your way, main has to be changed if the hotel.register is changed to require new fields.

Lonely Wolf
Jan 20, 2003

Will hawk false idols for heaps and heaps of dough.
If you do it her way every such method that takes the scanner has to be changed if the format of the input is changed, instead of just the drivers.

Jonnty
Aug 2, 2007

The enemy has become a flaming star!

abiogenesis posted:


She says it makes the method more functional but to me focusing on taking in the data you want to use allows it to be more generalizable, easy to use, and clear as to what the method actually does.


You're right, or at least more right than her. I also enjoy that, while I know she's using 'functional' differently, in programming terms she's quite wrong :P

Sprawl
Nov 21, 2005


I'm a huge retarded sperglord who can't spell, but Starfleet Dental would still take me and I love them for it!
Both of those ways are dumb because then you have to change too much should you need to make a change. You should just make an custom generic and be passing that.

Nippashish
Nov 2, 2005

Let me see you dance!

abiogenesis posted:

She wants us to pass the keyboard scanner to every method we use that takes input instead of getting the input in the main part of the program and then passing it to the method. She does the same things in terms of passing the scanner to a method in a completely different class.

FWIW if there's some possibility you'd want to register someone where the information doesn't come from a scanner I'd have a register(Scanner) and register(name, room) method. The Scanner version would just extract the name and room and then call the second version. Putting the code to pull things out of the Scanner inside of the object that will be using them makes perfect sense.

Dessert Rose
May 17, 2004

awoken in control of a lucid deep dream...

Nippashish posted:

FWIW if there's some possibility you'd want to register someone where the information doesn't come from a scanner I'd have a register(Scanner) and register(name, room) method. The Scanner version would just extract the name and room and then call the second version. Putting the code to pull things out of the Scanner inside of the object that will be using them makes perfect sense.

yeah, this design makes the most sense to me, you don't want to be doing the input part in main either - she's right that the object should encapsulate all of the code that registers a guest, but wrong in how it should be divided among methods, basically

npe
Oct 15, 2004
Clearly there needs to be an IRegistrationInputSource which requires methods getName and getRoom. The Register class should be able to take an object that implements this and use it to obtain the information. A ScannerInputSource class can then be implemented that manages the use of the scanner, but future implementations can be developed and the correct one can be chosen at runtime.

:suicide:

Dr Monkeysee
Oct 11, 2002

just a fox like a hundred thousand others
Nap Ghost
Having the hotel accept the scanner and process keyboard input seems like the text-book example of giving an object too many responsibilities. The concept of "registering a guest" is independent from "parsing user input" and in the real world I certainly wouldn't expect a hotel API to encompass input processing.

Sounds like she's emphasizing the encapsulation side of OOP too much because hey you've got to process the input somewhere and you've got this hotel object so why not hide everything behind a single call.

Ryouga Inverse posted:

yeah, this design makes the most sense to me, you don't want to be doing the input part in main either - she's right that the object should encapsulate all of the code that registers a guest, but wrong in how it should be divided among methods, basically

Given that this is a school assignment and not some reusable module, main is a perfectly reasonable place to process input. It makes more sense than shoving it into hotel.

Dr Monkeysee fucked around with this message at 20:53 on Apr 15, 2010

crazyfish
Sep 19, 2002

npe posted:

Clearly there needs to be an IRegistrationInputSource which requires methods getName and getRoom. The Register class should be able to take an object that implements this and use it to obtain the information. A ScannerInputSource class can then be implemented that manages the use of the scanner, but future implementations can be developed and the correct one can be chosen at runtime.

:suicide:

http://en.wikipedia.org/wiki/Provider_model

Of course, this is a school assignment, not production code that needs to be maintained.

Dessert Rose
May 17, 2004

awoken in control of a lucid deep dream...

Monkeyseesaw posted:

Given that this is a school assignment and not some reusable module, main is a perfectly reasonable place to process input. It makes more sense than shoving it into hotel.

If you think that "because it's a school assignment" is a good reason to stick a bunch of business logic in main, then I don't know what to tell you. Nothing important goes in main.

Why doesn't it make sense to put code that can get input from a stream and parse it into a registration in the object that does the registration? It's certainly better than putting it in main. I can think of a ton of overengineered solutions to the problem (the IRegistrationProvider design is actually okay, just way too much for this) but the easiest one is just to have a method that can take the input stream and parse the registration info out of it.

You could also make a Registration (or Guest) object that takes a Scanner in its constructor and build the object there, then have your register method take one of those. Also probably too much design for this.

The parse code needs to go somewhere in your object model. Think about where it needs to go, don't just punt and say "it's a school assignment; gently caress it, I'll do it in main." It's homework, which means that even though the exercise may be trivial, the point is to learn the best way to do it, not to hack something together that technically fills the assignment's requirements.

trex eaterofcadrs
Jun 17, 2005
My lack of understanding is only exceeded by my lack of concern.
It's not really business logic so much as an implementation detail.

_aaron
Jul 24, 2007
The underscore is silent.
A Hotel object should not be dependent on where the registration data comes from, it just needs to know what's required for registration to happen (which is a name and room number, as shown in 'your' method signature).

But yeah, there's a difference between production level code and a school assignment. In reality, some other object would be getting user input and structuring it in such a way that it makes sense for the Hotel object. I would say that doing the input processing in main (or some other method that is NOT part of the Hotel object) would be preferred here.

pokeyman
Nov 26, 2006

That elephant ate my entire platoon.
From the Ask General Programming Questions thread:

Nippashish posted:

In Java | and & are the non-short-circuiting versions of || and &&.

*is given counterexample of 1 && 2 and 1 & 2*

Nippashish posted:

They're also bitwise operators when the operands are integral types. Maybe you should try them with boolean operands.

Adbot
ADBOT LOVES YOU

king_kilr
May 25, 2007
Not a coding horror the way everything else in this thread is, but a friend of mine hates writing functions. I have no idea why, or what caused him to think this way, but he does. He often asks me things like, "Can I do this without writing an extra function?", and I don't get it. Luckily he's still a student, maybe they can beat it out of him.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply