IT/Software career thread: Invert binary trees for dollars.

TFW your life would be much easier if you could pass by reference in Java

MFW I write in C and don't care

Noodle's FW he realizes his language has no convenience

Tenks_sl said:

TFW your life would be much easier if you could pass by reference in Java

Click to expand...

Java 8 has method references. I know it's not precisely the same thing but you take what you can get. Android can get it if you work with retrolambda. Which you kind of have to if you work in Rx cause... boilerplate hooooo!

Tenks_sl said:

Noodle's FW he realizes his language has no convenience

Click to expand...

C really doesn't have any convenience in any sense of the word

I think I figured it out but I wonder if anyone has a better idea:

Requirement. I need to reorder fields in an XML document. There can be some special cases of grouping. This is a whitelist. So I can have a[buv][cuv]d. The brackets mean this "group" should be moved as a consecutive group. So occurrences of fields buv/cuv should be moved as a group. The bracket also implies it doesn't require all the fields so bv and bu should be treated as a group as well and it also implies u and v are valid fields.

Now it didn't sound that difficult at first until I actually wrote it all. There are more requirements for the spec but this is the one that is causing my engineering headaches. So what I did was I'd consume the valid fields string and convert them into a stack of classes to modify a DOM XML object. So in this case I'd end up with a 2xSingleFieldMatcher (a,d), 2xBracketFieldMatcher (buv,cuv.) The problem now arises when the buv BacketFieldMatcher gets called it sucks in all occurrences of "u" and "v." So if the following fields look like this in the XML:

buvcuv --> buvuvc is the output. This obviously isn't correct because it should output buvcuv because there is a stronger match later in the stack. I've resorted to having basically two DOM objects I work with inside of each method's match interface and then also a "tentative" Map of things where its like "I would consume these if no one else wants it." So the interface is basically:

It seems to work and it works alright but it got ugly fast. It was much simpler when everything was working in silos and no one had to care about other crap. So now if one of the interfaces gets a "strong" match it modifies it inside the destination Node. If it gets a "tentative" match it modifies/updates the Map which will then be inspected after all the stack has ran to see if there is anything left hanging on the "tentative" mapping. But now whenever something adds to the destination Node it has to make sure to update the Map incase someone previously has put a waiver claim on that node. I just don't really care for how it turned out and I'm not above scrapping it.

Example xml:

Noodlemod_sl said:

C really doesn't have any convenience in any sense of the word

Click to expand...

Yea but at least they dont jackhammer design paradigms up our butthole.

I've been reading my design patterns books, should I ever cross over into the world of OOP professionally. I teter between appreciation and disillusionment.

In the meantime i lend guidance to my brother who is working on his masters in Comp Sci, without a background in it.

He hates working in his Data Structures class, which is taught in Java.

He loves his Digital Logic class, which is in a psuedo Assembly.

I believe this is because the executing logic is obscured by so many layers, and importance so heavily placed on the organization of code, that he has a lot of difficulty understanding what the code actually does, leading him to search for the solution online, and not understanding. Where as, there is nothing expressed, but the exact thing with which you are doing at such a low level. Of course if he actually had to maintain a massive assembler code base, his opinion would likely fluctuate.

I probably speak from a place of bias, but having took my Data Structures in Ansi C, and C++ (with emphasis on C), I think its a better language to start with. Or maybe Python/glue/scripting language.

Of course im trying to fight my bias, or at least rationalize it, which is why I bought my books om OOP design.

Until firmware goes to OOP languages, I'll not read up on that stuff.

Some firmware does use C++ but it's really more of a bastardized form of C++ that is really just C with classes (my old bosses words, not mine). Doesn't really utilize what C++ has to offer

Saw a back and forth conversation in a thread between someone who'd been around the block a few times and a "younger" dev. Started because the older guy had penned an article about how the current hotness in Android (Rx) isn't really bringing anything new to the table. Very heavy in the "I walked 5 miles to school in 5 foot snow drifts" rhetoric. Younger guy took the stance that it may not be "new" in terms of the approach but that it doesn't matter as long as it serves a purpose and makes the platform better in the process. Reminded me a lot of something you hear in writing a lot. There are no new ideas, only new ways to present the story.

moontayle_sl said:

Saw a back and forth conversation in a thread between someone who'd been around the block a few times and a "younger" dev. Started because the older guy had penned an article about how the current hotness in Android (Rx) isn't really bringing anything new to the table. Very heavy in the "I walked 5 miles to school in 5 foot snow drifts" rhetoric. Younger guy took the stance that it may not be "new" in terms of the approach but that it doesn't matter as long as it serves a purpose and makes the platform better in the process. Reminded me a lot of something you hear in writing a lot. There are no new ideas, only new ways to present the story.

Click to expand...

Sounds like Containers. This is technology which Sun invented years before they became the new hotness.

I'm still on team OOP

OOP gets a back wrap because people will see things like Enterprise FizzBuzz and use that as a claim why OOP is bad because it leads to massive abstraction and over engineering for common problems. Then they'll point to problems which could have been solved by OOP and say that even when OOP is appropriate developers don't use it. I think the issue is actual good OOP software is difficult to architect and many people just start by writing code without really fully thinking out what their software should look like. I think when used properly OOP solutions can be elegant, easy to use, easy to extend and easy to read and follow. When used improperly you'll get a bastardized half OOP half procedural solution that gains all the burden of OOP and none of the benefit. But that by itself is not an inditement against OOP.

lendarios_sl said:

OOP, inheritance, overloading is just easy to use.
On an interview a non CS person, who was versed on procedural, gave the following answer.
"I don't see a problem with having a method signature been "
vs
I recomemded, not hiring.

Click to expand...

I'd be more concerned about the improper casing.

Honestly overloading is nice but not always that necessary. Very few times do you get a variable that you can operate on and dispatch without knowing what type it is. Since you already know what type you are working with it isn't a big deal to dispatch it to an overloaded method or a specifically named method. I really only make heavy use of overloading in languages which aren't strongly typed.

His method works and is proper. Yours would be something like

But obviously that code sucks. The actual code for Lend's would probably be more like:

That way you effectively only write the code once. But again you can accomplish that with specifically named method as well.