Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

nebby: Dec 21, 2000; resident mog

tef posted:

See, where you might use "result" I would use bln_flg_tst_cnd_args_x.

My god. I haven't been in here in weeks, and the first thread I open you guys are still making fun of me... I'm.. speechless.

For the record, say what you will about "bln_flg_tst_cnd_args_x", but I still think calling a return value "ret" or "result" is the goddamn stupidest idea I saw posted in all of those trainwrecks of threads I started.

Edit: And just for fun, I thought I'd post some of my own code since you guys find my style of naming a Coding Horror!

It's a little functional library I built for Java yesterday since I'm writing Android apps and Java is soooo verbose:

code:

public class F {
  public static <S, T> List<T> map(List<S> in, Cl<S, T> cl) {
    List<T> rg = new ArrayList<T>();
		
    for (int i = 0; i < in.size(); i++) {
      rg.add(cl.r(in.get(i)));
    }
		
    return rg;
  }
	
  public static <T> List<T> select(List<T> rg, final Clp<T> cl) {
    final List<T> rgSelect = new ArrayList<T>();
		
    each(rg, new Clv<T>() { public void r(T t) {
      if (cl.r(t)) { rgSelect.add(t); }
    }});
		
    return rgSelect;
  }
}

Cl<S,T> indicates a Java closure (which is just a anonymous class meeting one of the interfaces below) mapping from type S to T.. Clp<T> is a predicate closure (T => boolean), Clv<T> is (T => void) and Clvv is double void closure (void => void).

So

code:

public interface Cl<S, T> {
  T r(S in); 
}

public interface Clp<T> {
  public boolean r(T obj);
}

public interface Clv<T> {
  void r(T in); 
}

public interface Clvv {
  void r(); 
}

Here's an example, this takes a list of nodes that point to time blocks (tblk's) and selects the subset of nodes in that list that have the node for the learning period (nodeLrg) as their parent's parent. For sample, we might have 4 learning periods and have a set of time blocks to work with, and we want to just select those falling under period 2.

code:

List<Node> rgNodeTblkForLrg = F.select(rgNodeTblk, new Clp<Node>() { public boolean r(Node node) {
  return node.getParentNode().getParentNode() == nodeLrg;
}});

Bring on the hate, but I'd love to see your examples of functional constructs in java that don't read like a goddamn essay.

nebby fucked around with this message at 06:54 on Mar 29, 2008

# ¿ Mar 29, 2008 06:26

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 10:36

nebby: Dec 21, 2000; resident mog

rotor posted:

When it comes to mocking inane bullshit, we've got pretty long attention spans.

Yeah. One thing I think I've come to conclude is that one small thing that would go a long way towards a middle ground between my (supposedly crazy) viewpoints and the "gently caress it do whatever you want and use 'common sense'" viewpoint is a convention to use noun-adjective instead of adjective-noun in variable names and return type-verb in method names (or, at the very least, be consistent.)

I've been digging into some 3rd party code and sometimes it's the "RunningActivity" and other times it's the "ActivityToRun". Sometimes it's "RedColor" and sometimes it's "ColorRed". Is "CountApples" a function pointer to something that counts apples and returns nothing, or a variable containing a number of apples/a function that gets the count of apples?

# ¿ Mar 29, 2008 07:00

nebby: Dec 21, 2000; resident mog

zootm posted:

If you're using a variable to build the result of a function, result seems a pretty natural name for the variable. Because it contains the result.

The reason that this is a bad name, IMHO, is because the concept of a "result" is one in the domain of programming languages, not a concept in the domain you are writing the code for. It's about as meaningless as "x" or "i", which I also think are bad. (In my case above I use i, but only because the stuff being built there is completely detached from any domain, it's just some basic language enhancements.)

For example, if you are writing a method called countOfApplesInBasket() that returns a count of apples, if I see the line "result += 1;" I have to look at context to determine wtf result is. In this case, it's a count of apples. It's much nicer to just call it something like "countApples", it doesn't require context and gives the variable a much more meaningful name. The "but you can always look at context" defense is what I got a lot of in my old threads but it's entirely missing the point because the overall goal of naming itself is to minimize the amount of unnecessary cross referencing of context by the programmer.

The fact that it is the value being returned (and the fact that the concept of "return values" exists in my language) shouldn't impact the name of my variables in a method written against a certain domain like apple counting. I'd argue that the vast majority of the time there is a better name than "result" or "x" or "i".

And yeah, I realize "Runnable" and "Predicate" (and in .NET "Action") exist but my main issue is that when you are talking about something as fundamental as closures (or 'functors' as you put it, but Java anonymous inner classes pseudo-capture final variables and this variables so I think they are closures) that every extra bit of verbiage hurts and learning a few acronyms basically gets the ugly syntax out of the way so you can avoid reading it altogether (The terms 'Predicate' and 'Action' and 'Runnable' aren't necessary in non-lovely languages, they're just implicit in the syntax, so it's hard to argue they add some value to describing what is going on in this case.) You'll note I just throw all the anonymous inner class declaration crap on the end of the line even though that's not canonical Java formatting.

And yeah, I like Scala from what I've read so far, but time constraints are keeping me from trying to get my Android app running on Scala (which actually works, supposedly.) I'll do it eventually though

Edit: Here's the same code with 'common sense' applied. It's probably more intuitive to most of the readers of this forum, but it feels like a sack of molasses to me, it turns what should be a one-liner in any sane language into an abomination.

code:

List<Node> timeBlockNodesForPeriod = FunctionalUtil.select(timeBlockNodes, 
  new Predicate<Node>() { 
    public boolean predicate(Node node) {
      return node.getParentNode().getParentNode() == nodeForCurrentPeriod;
    }
  }
});

nebby fucked around with this message at 17:55 on Mar 29, 2008

# ¿ Mar 29, 2008 17:39

nebby: Dec 21, 2000; resident mog

Z-Bo posted:

I think you are completely missing why your blog posts were so epic and are seared into our brains: You were mentored by Charles Simonyi, and yet completely misrepresent his position on intentional programming.

I don't see how I can be misrepresenting them when the lead dev at Simonyi's company (who is a real wizard, IMHO) told me my blog put forward the best argument he had ever read for Hungarian (assumingly apart from those written by Charles.)

quote:

You appear to think it is Nebby versus the World.

On this topic in this forum it probably is me vs. everyone else, more or less. I don't recall anyone even slightly agreeing with me, and hey, check out my awesome avatar which I've held on to

That's not saying anything about any other topic in any other forum or audience -- when I sent some of the posts to other 'converts' not on SA they agreed with what I was saying and rolled their eyes at some of the replies that were made

You're forgetting that I explicitly said in all my posts I intentionally post on subjects that are controversial in order to spice things up. I don't think that I'd be contributing much if I posted another "how do I implement this data structure" or "how awesome is Ruby on Rails" thread.

# ¿ Mar 29, 2008 20:21

nebby: Dec 21, 2000; resident mog

Bonus posted:

Although I disagree that i is a bad name, because it's almost exclusively used for loop counters and has become a sort of a standard for them.

Yeah, I mean, I catch myself using "i" when I know better. The problem is, I see it as a bad habit when most see it as acceptable. When you are writing a loop, you can quickly get into trouble if you have nested loops and have i, j, or even k being used. Additionally, and more importantly, using "i" is ignoring an opportunity to introduce a good name into the code. You're looping over it for a reason, so you should usually opt to provide hints as to why you're doing so in the name. If you are looping over a list of apples that need to be put into another bucket, instead of "i", you could use "iAppleForBucket" and not worry about confusing it with another loop variable and potentially remove a comment saying "// We loop over the apples for the bucket" !

nebby fucked around with this message at 20:46 on Mar 29, 2008

# ¿ Mar 29, 2008 20:44

nebby: Dec 21, 2000; resident mog

rotor posted:

a DSL for every project, as though that was a good thing .

This isn't a revolutionary idea:

http://en.wikipedia.org/wiki/Domain-driven_design
http://en.wikipedia.org/wiki/Language-oriented_programming

I've worked on a number of software projects and in every case, regardless if we liked it or not, we developed a DSL around what it was we were building in our day to day communication. The choice wasn't if we had a DSL, of course we did, we were building something, but in what words we chose to use.

nebby fucked around with this message at 21:26 on Mar 29, 2008

# ¿ Mar 29, 2008 21:23

nebby: Dec 21, 2000; resident mog

tef posted:

Now, what we are actually storing is a hash which uses student names as keys (strings) pointing to percentages (ints). This leads to the obvious naming scheme

Missed the point again chief, this would be something like mpNameSpct - a map (mp) from a name (a string containing a human readable name for display) and a Spct (a float containing a percentage that pertains to a particular kind of score.) Spct would be used throughout the code everywhere to talk about this particular quantity. If context wasn't obvious enough this was involving students, you'd call it mpNameSpctStudent. (And here you think I said context doesn't matter.) Do you still not get it? This is the opposite of encoding implementation.

"Score" is a lovely name for pretty much anything because every time I've written code involving scores there is more than one type of score. Passing these around becomes cumbersome and confusing to follow. For example, "public score" and "private score" and "human friendly score" and "score before we've added in bonus points" and so on. Sure I can look at 'context', but its funny because this exact case came up in the past for me, and deciphering what particular type of score was being calculated required going through lots of other methods for enough context to be sure. The places where this wasn't necessary was when the name was consistent like "publicScoreBeforeBonusPoints", which is precise and helped me a lot when it was used consistently, but is a mouthful. For all but the simplest projects, this dynamic happens with many different domain objects/quantities.

Now, the name mpNameSpct does encode implementation in part of the name, namely, "mp", which says it is a map (like a Hashtable or Dictionary.) You'd say this is bad, though. But look closely, because you've actually encoded that facet of implementation in your name, albeit less precisely, by making it plural. "StudentScores". By making it plural you've indicated it is some data structure that contains things. Not much beyond that. I'd argue that including the 'implementation' detail that it's a map and not a indexable list or something that's iterable at the cost of two characters at the beginning instead of one or two at the end is worth it, relevant, and not 'redundant'. The fact that English doesn't have a worthwhile suffix for describing "map vs. list" just shows how poorly English maps onto programming language variables. Now, Java interfaces get a nice mapping from English, the suffix "-able", but 'map vs. list' loses out.

You again forgot the main point of my post re: System vs Apps is that you fall back on encoding native type information when there is nothing else worthwhile to encode. For example, almost all booleans have an "f" prefix, because they are generally just used as a flag to check something. They're a goddamn boolean. Just because I use "f" for my boolean flag prefix all the time doesn't mean I am using "Systems Hungarian" because the rest of my code uses tags that encode far more than implementation (and much more than "Score".) This is less because "f" is useful and more because if we didn't put *some* tag at the beginning our names would appear inconsistent.

And again, the argument about context is missing the point. I have never said context isn't important, somehow you think context magically disappears if I am using Hungarian naming. Context is still just as useful and key to understanding an algorithm. But the goal is to optimize naming so you minimize the need for context. If this wasn't a worthwhile goal than we would name everything by typing random keys on the keyboard instead of trying to come up with something consistent and that makes sense. Just because my definition of "makes sense" grates against your bias towards English doesn't mean it's inferior on its own.

You also claim that the information encoded is "redundant". If you say "Score" and I say "Spct" which designates a specific domain specific type of score, I don't think it's redundant, but necessary, since there is no other place to directly encode that information other than in the amorphous context or comments of the method it is being used in.

I'm not a troll -- the points are subtle and your own self reflection of what you think that I am trying to get across reveals how they've flown over your head. I've read good arguments against this approach before, and yours is not one of them.

Edit: FYI

code:

class AppleBasket
    cApple = 0
    def addToBasket(basket)
        basket.cApple++
    def takeFromBasket(basket)
        basket.cApple--
    def cAppleInBasket(basket)
        return basket.cApple;

nebby fucked around with this message at 18:24 on Mar 30, 2008

# ¿ Mar 30, 2008 18:02

nebby: Dec 21, 2000; resident mog

Victor posted:

nebby, what if the programmers with whom you work just suck at giving proper context? Also, you repeatedly forget to note that this is much more important for dynamic languages, as things are less clear there. Have you looked into coding for the military, using ADA? It gets fairly close to your approach, but has compiler-enforced type safety. You can only get speed if you divide distance by time (or integrate acceleration by time, etc.).

Maybe I missed it, but I do not remember you ever explaining why your desire for Hungarian whatever is in the distinct minority of programmers. Does your approach really allow you to code more quickly and more accurately than other people, on average? (Take into account learning curve here!) To what extent are the problems you encounter, unique to your problem domain, or at least a very, very small fraction of programming?

The more I think about this, the more you must address the above if you want to stop digging/get out of the hole you've dug. Right now, you're some weird freak in most of our minds. I'm cutting you more slack than most, because I have very little respect for experience and track record, if I cannot understand the why behind the experience and track record. However, most people do, and you, my friend, have demonstrated zero.

Thanks for the sane voice. Sorry this is a derail, but I figured I should respond.

quote:

nebby, what if the programmers with whom you work just suck at giving proper context?

Could be. I know some of the code I've worked on recently (it was in Ruby) had a tendency to have lots of deeply nested data structures floating around with simple variable names. It took a debugger and manual tracing through the code to decipher the contents. Consistent naming and a lookup dictionary (like that prescribed by Hungarian) would have helped immensely.

However, I've also spent a lot of time digging through rails and other open source gems recently, and the problems there are patently obvious. Here's a tiny example. Yesterday I had to drill through some of Rails's template processing code. They pass variables with the name "template" around all over the place. My intuition totally fails me here -- this could contain the filename of the template, the name of the template, the HTML contents of the template, a parsed AST of the template, or a object of type Template (or something else.) The only way I can know is if I dig through all the dynamic crazy metaprogramming stuff, through methods that I have to figure out not based upon static binding but dynamic binding or method_missing calls, or get to a breakpoint in a debugger, or dig through unit tests. Wouldn't it be nicer if they just had a consistent understanding that "template" should always be a variable pointing to a Template object, and "htmlTemplate" and "astTemplate" and "fpthTemplate" and so on for the others? Of course, sometimes they'll say "template_file_name" or "template_contents" but its by no means a hard and fast rule, and it's generally not their fault because their approach in general does not encourage precision and typing those names out is just annoying.

Note that this problem still happens in static programming languages, replace "template" with "score" for an int variable and consider there may be many different types of scores, and the same problem comes through.

quote:

Have you looked into coding for the military, using ADA? It gets fairly close to your approach, but has compiler-enforced type safety.

I haven't looked into ADA much, but I know that a common argument in favor of Hungarian is that it is analogous to military acronyms or aviation acronyms. Instead of having to say a whole mouthful of poo poo when you want to talk about something precise you end up just saying a bunch of acronyms that sound like gibberish to an outsider. The reason it has evolved this way is because it was the best approach to providing precision in a realm where it was incredibly important and where just inventing new buzzwords quickly broke down since so many new terms were being used regularly.

quote:

Maybe I missed it, but I do not remember you ever explaining why your desire for Hungarian whatever is in the distinct minority of programmers.

I have, I think you missed it. Here it goes again. First, there is an aversion to reading it, because it usually lacks pronounceable words and appears as total gibberish to the untrained eye. It is painful to adapt to, on par with learning a new keyboard layout (something I've gone though

) .. much harder than learning a new programming language.

I think this is just another example of the classic case of intuitivity vs. efficiency. Most people, when they first start using something, do not even think about efficiency. If the system is intuitive, they pick it up quickly and stick to it, no matter how inefficient it is to use once they are experts. If you look at CAD systems they are notoriously unintuitive, and require years to get good at. But their user interfaces are incredibly efficient. This is an example where the tradeoff was recognized and a sacrifice was made in intuitivity for efficiency. At first glance, AutoCAD is totally impenetrable and if you just put a layman in front of it he will reject it for something that is more intuitive and matches what he is used to. But the pro can't live without it.

I see the push towards English naming as a consequence of this natural human desire for intuitivity. When you see a new piece of code, it is much easier for you to digest the overall algorithm if the names appear intuitive. However, if this is a body of code you need to become intimitely familiar with, in my experience, Hungarianized code is much easier to become efficient at working with, since there is less ambiguitiy once you penetrate the style of naming. Even once I became used to the overall concept of Hungarian, a new body of code with unrecognizable tags would seem menacing at first. But, provided the programmers involved were disciplined, after the initial pain of understanding what the hell was going on was passed (intuitivity was about zero) then I became a total domain expert for that body of code.

Additionally, Hungairian makes it painfully obvious what you do and don't understand. This was because you are not tricked into thinking you understand something because of it 'reading nicely'. You are forced to actually step through code mentally and truly grok what was happening. If you see an unrecognized tag, it signals "oh poo poo this is a big concept I haven't seen before", vs if you see a class called "Email" you think "eh, whatever, its some kind of email". These unfounded assumptions are dangerous and cause lots of bugs. It's all to easy to look at code examples in rails and ruby and miss the subtlety, simply because its easy to read.

Second, it has a bad reputation because of Systems Hungarian's prevalence in Win32 programming. Systems Hungarian is a total poison and it would be hard to think of a naming style that provides less value other than random characters.

quote:

Does your approach really allow you to code more quickly and more accurately than other people, on average? (Take into account learning curve here!) To what extent are the problems you encounter, unique to your problem domain, or at least a very, very small fraction of programming?

Well, I can't really point to empirical evidence, so I don't know how I can truly be convincing. What I will say, though, is that you do get a few clear benefits from Hungarian that are totally lacking in other approaches that probably lead to efficiency gains.

First, for writing code. You no longer "think of a name" for a variable. I can't stress this enough. I know from almost everyones perspective this seems trivial, but the amount of "numApples" vs "countOfApples" vs "appleCount" vs "applesInBasket" and so on I think really contributes to a lot of unnecessary noise both in reading and writing code.

When working on a team, each programmer often has their own unique style of naming. I'm sure you've all seen this. Some guy always has "retval" for the return value. Some guy always says "listOfApples" and the next guy says "apples" and the next guy says "listToReturn". Having everyone automatically agree that a list of apples is going to be "rgApple" makes it so your brain barely even registers the word, you just read it as you read this sentence and don't have to look at context to understand what I mean by the words I use.

I firmly think that the majority of creativity in programming should be spent on designing system architecture, data schema optimization, user interface design and other tasks that directly impact the success or failure of a given project. In my own personal experience, in projects where we were not using Hungarian, a disproportionate amount of creative energy was spent on coming up with names that best mapped the purpose of a type onto an English real-world equivalent. All this effort, pining over if we should call something the "EmailDispatch" or the "EmailSender", and so on. Again, it seems trivial, but totally removing this creative burden once we decided a name was really not that important was very liberating. On small projects, this is no big deal. But when you start building huge class libraries you end up getting lots of "English collisions" and end up twisting the language in directions it was never meant to go. A simple reporting framework explodes into having things called ExtendedSearchSiteReportsEmailReport (a real example.)

Edit: Oh, and before someone says "namespaces" here, let me remind you that namespaces are a compiler hack for binding names to classes and not meant to reduce ambiguity in the name itself.

quote:

To what extent are the problems you encounter, unique to your problem domain, or at least a very, very small fraction of programming?

I've worked on two projects with Hungarian, one was for ISC as you guys probably all know now, and one is my own. So, I can't really make an argument for or against its success on those projects in terms of it being universal. I will say that I am working on educational software, particularly within scheduling, and not having to come up with fancy names for all the different actors involved in a schedule is incredibly nice. If I had to, my code would be riddled with "TimeBlockCategory" "TimeBlock" "LearningGroup" "LearningSession" and all these things which really end up having no real English equivalent. I've found that writing parsers for schedule data has been incredibly easy since the code is incredibly dense for these parsers but I never find myself grasping at straws for a good name. Hungarian provides a mental framework for me to come up with patterns of names that might be very domain specific but end up being consistent. I am fairly confident that other developers will be able to understand *all* the parsers I write, despite the fact that upon first glance they look intimidating, since its just a matter of understanding the language.

That said, I draw a lot of my conclusions not based upon the projects I've been using Hungarian with, but the contrast against the projects I've worked on without it over the years. I remember distinctly arguing over what we should call things and tracing through code trying to find enough context to understand what exactly was being stored in a quantity. Knowing the type of a variable through IntelliSense is often not enough to get at the crux of its role in an algorithm, so the applicability of this to static languages is still very useful. (Though I'll grant it's been even more profound for me in Ruby.)

nebby fucked around with this message at 20:32 on Mar 30, 2008

# ¿ Mar 30, 2008 20:01

nebby: Dec 21, 2000; resident mog

Z-Bo posted:

This is why I think you are missing the point of Intentional Programming.

I've said it before: Hungarian notation is a suboptimal solution to the larger problem of encoding programmer intent in a name. And that, having to name variables and write code, is a suboptimal solution to the larger problem of providing programmers and domain experts with the best means of describing their problems in a way that a computer can solve them.

You're right, index variables are unnecessary mathematically, but in some languages (which I deemed "sane", a misnomer perhaps) we are forced to use them. When we are forced to use them, the question of naming comes into play. When the question of naming comes into play, we are forced into coming up with one that usually matches /^[A-Z][0-9A-Z]*/i that's less than some maximum length. It's this set of constraints that Hungarian is designed (again, forced) to work within. Think of it as an incredibly 'projected' view of the ideal solution to a specific subproblem onto the lovely tools and languages we have forced upon us today.

quote:

You are using an appeal to authority to back up your point.

No, it's not an appeal to authority when you say I am misrepresenting someone when someone working directly with that person says I am representing them accurately. You weren't questioning the content of my argument, you were questioning my 'representation of Simonyi's view' without giving me specific of why you felt I was doing so. So, all I could do is tell you that people who have an intimate understanding of this view don't agree.

As far as the specifics, I mean, basically it was like "good job on that post I think you hit the points on Hungarian better than anyone has written before" or something like that? If you have any other specific things you think I am not making sense about then you have to admit I've been more than willing to try and refute them, don't go painting me like I am some question dodging illogical person.

# ¿ Mar 30, 2008 20:48

nebby: Dec 21, 2000; resident mog

Z-Bo posted:

This interface doesn't make any sense. Why would you add a basket to a basket?

The most important parameter to explicitly model in this problem is that you clearly care about ownership and not membership. These baskets are not the same thing as mathematical sets, so you cannot therefore model them as sets: you cannot use membership as a status. One basket must clearly own all of the apples in its basket. Forget the fact you have the "c" in there. Your model is dumb. You have bigger problems than whether to use Hungarian notation or not!

What the gently caress are you talking about? This was someone elses example and I just renamed all the constants in his example to be consistent with how I would name them in the same model. The fact you are assuming anything about baskets, apples, and so on, (they're 'not the same thing as ... sets', we care about 'ownership' not 'membership') is really confusing.

Again, your bias towards English is making you assume something about what I mean when I say "addToBasket(basket)". In his example, he (bizarrely) passed in a reference to a basket to add one to the count. I'm assuming in this bizzaro example this fake language we are programming in those are static methods, otherwise passing in a basket would make no sense. In Hungarian, its "<returnType><verb><parameters>" so I am not returning anything, I am addingTo, and I am passing it a basket. Implicit is the fact that the verb "addTo" will increase the count of apples ("cApple") on the specified basket.

If I was going to pass an apple into the basket to add to it, it would be "addApple(apple)".

Oh poo poo. I just typed this reply up, and realized the reason we are both confused in the first place is because his naming sucked in the original example. In his 'unenlightened programmer' he passed in a variable called "s", which I guess he meant to be an Apple not a Basket. But then in his 'enlightened' example, he passed in something called "applebasketself" which I assumed was the basket he wanted to increment the count of apples on. He actually confused himself by his own lovely naming, unless I am missing something.

Double oh poo poo. Ok, so that was a reference that is supposed to be self, and we're in Python. Now I get it. I think instead of him confusing himself, he confused Z-Bo, who thought we were passing in Apples instead of it being the self variable. With this in mind, I would have named my methods "add" and "take" since we would not include the Basket in the name since it's an implicit parameter (self).

I think the important thing to take away from this is that all this confusion stems from bad and ambiguous names. If he called his first parameter "self", it would have been fine since we all understand what that means. Also, consider these three method names: "add", "addApple", "addToBasket". With Hungarian, I can tell you exactly what the inputs and outputs of these are, and while I can't tell you *exactly* what they do, I will be much less confused than if there were no rules for me to think of when I saw these methods.

nebby fucked around with this message at 21:19 on Mar 30, 2008

# ¿ Mar 30, 2008 20:56

nebby: Dec 21, 2000; resident mog

Ok, my g/f just came over and said she saw "the penis man" (my avatar) and so that means I'm slacking off and posting and I should stop. She's right, and I am, so back to your regularly scheduled programming (Z-Bo you get the last word

)

# ¿ Mar 30, 2008 21:10

nebby: Dec 21, 2000; resident mog

rotor posted:

Nebby, do you have any kind of studies that show this to be any kind of significant problem at all? Honestly, the entire argument reeks of brace-style, tabs-vs-spaces nonsense, except everyone seems to be taking it seriously, which baffles me.

No, how could I? The whole thing has been largely ignored and discarded by the programming community, who would study it? It had its hayday when it was in the win32 API, as Systems, and got totally discredited and labelled as a "bad idea." Honestly, it's not a huge issue to me these days, I just am often amazed at the reaction I get when it comes up and the logical fallacies otherwise smart people start throwing out there, so it's something I get sucked into in threads like this. I can switch away from it somewhat easily, but it can be painful. It's kind of like the pain I get when I realize I know I am not writing enough unit tests

I mean, think about it. Many people in this forum think I'm some crazy person, a troll, a kook, a crackpot, throw personal insults and so on because of a variable naming convention I promote when I write computer programs. It's ridiculous. I certainly don't think about anyone here in that way, regardless of whatever they might post in a thread!

# ¿ Mar 30, 2008 23:31

nebby: Dec 21, 2000; resident mog

rotor posted:

If you have a bunch of 'otherwise smart people' who routinely tell you you're crazy whenever you bring this up, you should probably take a step back and consider whether:

My last job everyone hated the idea of Hungarian for the first two months, told me I was crazy. By the 4th month one or two were actually actively pro-Hungarian, about half saw the merits and agreed, and everyone I think agreed that their initial impression at least was off. The DBA thought it was retarded, though

So, initial reactions for something like this are not indicative of how people feel once they've put it into practice. Beyond that, just talking about it on a forum isn't really effective at convincing people, so it's kind of stupid for me to be doing so. It's really a 'do it and see how you feel in a few months' type of thing. It's like switching OS'es, from automatic to stick, languages, like anything really, where at first you're like "man this sucks" but eventually its no big deal. For example, I loving loathed ActiveRecord when I first used it, and still think it pretty much sucks, but don't spend afternoons writing tirades on it anymore.

quote:

Well, it's a software forum. We kind of take software seriously here. I don't really care what you're like as a human being, but so far all your opinions on writing software I've seen are ... well, they're crazy. As for the personal insults, I dunno man, welcome to SA I guess.

Er, go ahead and name some of my other opinions you find crazy! I've posted in threads on TDD, rails, OOP, design patterns, web services, C#, SQL, and other random poo poo here and I don't think anyone has been like "hey its that crazy guy!" since my posts are more in line with 'sanity' and until I had the dude with the crotch over to the left there nobody even knew who I was.

As for SA, yeah, well, I've been here forever so I know how it goes. It's still dumb though, but I guess programmers are known for crucifying each other over editor choices and such.

nebby fucked around with this message at 23:54 on Mar 30, 2008

# ¿ Mar 30, 2008 23:52

nebby: Dec 21, 2000; resident mog

If we had editors that let you have rich symbology, colors, icons, tables, and flow diagrams instead just a static grid of ascii text of course this whole argument we just had would be moot since naming would take a backseat. Fortress doesn't count because you have to run the whole thing through LaTeX, and it's read only.

nebby fucked around with this message at 22:39 on Mar 31, 2008

# ¿ Mar 31, 2008 22:37

nebby: Dec 21, 2000; resident mog

Bonus posted:

I never found the appeal of those keyboards because I rarely look at my keyboard and when I need to do stuff quickly I rely on vim's command mode or just on keyboard shortcuts in general while in other applications.

I think the appeal is that this type of thing will greatly reduce the learning curve for having much more modal UI's. Vim is successful because of its modal-ness and it's commitment to efficiency (as you could probably imagine I am a Vim addict) .. it would be pretty sweet if when I entered a different mode my keyboard quickly changed to identify new commands I might not have learned yet.

I think the amount of modal complexity can probably go up quite a bit if the keyboard helped hold the hand of the programmer until they could run on their own. This type of interface would bring about intuitivity without a loss of efficiency, which is great.

What makes this type of thing applicable to higher level domain language based programming is when you can have a UI with a many customizable modes and have it not be a total roadblock to productivity. Right now, you cannot just open up Vim and start using it. With this type of input device (or one similar) you can totally switch between relevant domains and start cranking stuff out relatively easily without up-front memorization. So, if you wanted to start writing code using logic operators, and then switch to a mode that lets you input electrical diagrams, and then switch to a mode optimized for database schema manipulation, you could have the mode reflected on the keyboard and not rely upon memorizing unintuitive commands. Again, I point to CAD/3d modelling apps as inspiration for this approach. Of course, once you spend a few hours in "database schema manipulation mode" you'd have the muscle memory down, just like you do in Vim.

One thing I think would be really interesting would be the introduction of a kanji-like symbology so the density of information in code could go way up since the cardinality of characters would be much, much higher.

# ¿ Apr 1, 2008 00:33

nebby: Dec 21, 2000; resident mog

Ryouga Inverse posted:

Do you ever stop masturbating to thoughts of how steeper learning curves could be added to programming?

Well, this is a thread dedicated to what happens when the clueless write code, so barriers to entry might be a good thing

Kidding, the kanji thing is just mental masturbation, so you've got me there. That said, the goal of domain specific programming is meant to reduce the barrier to entry by letting domain experts specify the problem using languages they already are familiar with, and decrease the amount of code overall by employing generative programming techniques so there is less work involved. Use the fluffy English readable ambiguous languages high up enough so they are fun and easy to read for humans, and at the bottom you get the dense high learning curve languages that do the actual work on the wavelengths that wizard programmers can be maximally effective.

Fundamentally, the idea is you can have it both ways, but currently the paradigm locks you into a single language with a one type of notation and a single level of abstraction, so it's going to be a while before we see this take hold (if ever.)

And now, a Coding Horror.

Rails' association proxies:

code:

module ActiveRecord
  module Associations
    class AssociationProxy #:nodoc:
      attr_reader :reflection
      alias_method :proxy_respond_to?, :respond_to?
      alias_method :proxy_extend, :extend
      delegate :to_param, :to => :proxy_target
      instance_methods.each { |m| undef_method m unless m =~ /(^__|^nil\?$|^send$|proxy_)/ }

      def initialize(owner, reflection)
        @owner, @reflection = owner, reflection
        Array(reflection.options[:extend]).each { |ext| proxy_extend(ext) }
        reset
      end

      def respond_to?(symbol, include_priv = false)
        proxy_respond_to?(symbol, include_priv) || (load_target && @target.respond_to?(symbol, include_priv))
      end

      # Explicitly proxy === because the instance method removal above
      # doesn't catch it.
      def ===(other)
        load_target
        other === @target
      end

      # More code
    end
  end
end

Rails' association proxies look like an Array, walk like an Array, and talk like an Array, and even *say* they are Array's. But alas, it is not an Array. At the top there, it's basically undefining all the methods (except a few hand picked ones) and then redefining them below. When I saw this a few months ago I thought I had seen everything when it comes to Ruby magic, but this took the cake in terms of the debugger basically lying to me about what the heck was going on. Now that I know what was happening, it makes sense, but there are those few special moments where you feel like a magical fairy has taken over your computer, because what it is doing is not possibly logical, and tracking this behavior down was definitely one of them.

# ¿ Apr 1, 2008 02:44

nebby: Dec 21, 2000; resident mog

tef posted:

I believe you are looking for APL.

Sweet. I didn't know something like this existed that far back in computing, it's got issues because it seems to have many degrees of freedom (not sure about that), but it looks pretty ingenious to me considering the time it was invented. Despite your quote of Dijkstra, it doesn't appear APL is considered a universally discarded idea. I'd argue the existence of Fortress is evidence of it's validity.

Being able to key in code in the language using plain ASCII or unicode key chords is just a matter of modality, which is what I was talking about. You could project APL in plain text mode for enhanced intuitivity and input, and re-project it as unicode when it was time to dig through code you've already understood. As long as this re-projection is quick and painless, it's a great approach. Fortress fails on this account because it sees the reprojection as a separate offline process altogether, though I suppose tools can get better. A bigger problem though is that Fortress doesn't let you mix domain languages (it's domain is higher mathematics, really) but that's an altogether different problem than the one APL and Fortress are trying to solve with symbology.

# ¿ Apr 1, 2008 17:06

nebby: Dec 21, 2000; resident mog

tef posted:

I think you're looking for katahdin.

This is neat, but depressing at the same time. The motivation is great, but the emphasis on parsing being focus of the problem shows how the current paradigm is broken. We need to be editing higher level data structures when programming (ASTs) so that parsing from linear ASCII sequences becomes an additional feature added to a language, not something we need to do anything productive, and we can focus on designing a language that is correctly expressive. This is part of the issue with Fortress, I saw Guy Steele's talk on that at OOPSLA 06 and a huge chunk of his talk was dedicated to how parsing Fortress works, which is depressing in the same way this is.

# ¿ Apr 1, 2008 17:40

nebby: Dec 21, 2000; resident mog

the talent deficit posted:

So then, in the javascript, I find an eyeframe that's loading this (except it goes on for about six pages):

I mean, clearly this is generated code .. not really a Coding Horror depending on how it was generated. (That's not to say it isn't a bastardization of how to build a website appropriately.) For example, OpenLaszlo will generate javascript like this when targetting DHTML (but will use much shorter, sane names like __lz0 to __lz9)

# ¿ Apr 2, 2008 06:13

nebby: Dec 21, 2000; resident mog

Ha ha. It's obviously even more advanced than Hungarian, it's the elusive md5(rand()) notation.

# ¿ Apr 2, 2008 06:38

nebby: Dec 21, 2000; resident mog

pokeyman posted:

(Did I miss anything?)

He used a While loop instead of a For loop to iterate over a String.

His input variable is named "str" and his aggregating one is named "newstring", if I try to put myself in his position, he probably said to himself, "ok, I'll name the input variable string and the output variable newstring. That makes sense. Oh, god drat it, I can't name a variable string because its one of those special colored in words. I guess I'll just call it str." Surely he did this after having the same mental exercise happen that resulted in Uppercase -> Upercase.

# ¿ Apr 2, 2008 08:09

nebby: Dec 21, 2000; resident mog

For what it's worth, the "IsNullOrEmpty" phrase is pretty cumbersome, I much prefer Ruby's "blank?" which implies it is either null or empty (this applies to both arrays and strings.)

# ¿ Apr 7, 2008 19:45

nebby: Dec 21, 2000; resident mog

Personally I would probably fork off an ec2 instance for each choice and pass the choice in as a boot parameter so it can be save to disk. You could then query each of the machines in parallel via a rest interface to quickly determine the set of choices.

# ¿ Apr 24, 2008 16:52

nebby: Dec 21, 2000; resident mog

mantaworks posted:

Sorry, ya gotta explain this one. (Yes, I know who that is, the wispy mustache gives it away.)

# ¿ Apr 26, 2008 01:06

nebby: Dec 21, 2000; resident mog

hexadecimal posted:

Isn't it possible to break md5 relatively easily nowadays?

No, but its days are numbered.

(There have been a few exploits surrounding it but you can't just 'crack md5')

# ¿ Jan 10, 2009 08:17

nebby: Dec 21, 2000; resident mog

hexadecimal posted:

I recall reading a paper on how to generate strings, or documents that generate a given md5 hash.

I'll admit I'm naive here, but I think the weakness of MD5 is a little more constrained than that at this point. Maybe someone who knows more about it can chime in, but I thought the general state of MD5 is "if you're using it today it's not quite an open door yet, but you should think about migrating" not "oh poo poo everyone who has MD5 hashes in their database is hosed!"

Edit: Not sure, but I think it's basically "we can find two colliding documents" not so much "give us a document, we'll find a colliding one for it." You can use the former to exploit systems, but I think if you use salts and so on you're still theoretically in decent shape right now with MD5. But generally speaking it's probably a matter of time until someone comes up with a generic solution. And yes, I wikipedia'ed it!

nebby fucked around with this message at 08:40 on Jan 10, 2009

# ¿ Jan 10, 2009 08:36

Adbot: ADBOT LOVES YOU

# ¿ Apr 28, 2024 10:36

nebby: Dec 21, 2000; resident mog

Ithaqua posted:

Who's going to know how to deploy your software better than the guy who's writing it? Who's going to know about the environments that run the software better than the guy who's setting them up?

I know this is from a page ago, but I wanted to also point out this is also true when it comes to managing the testing infrastructure. My employer hired a dedicated team to manage the unit testing framework, integration testing framework, CI server, etc. They did do some good things, but they regularly broke poo poo that halted everyone's work. If they were involved in developing the mainline product, it would have been (nearly) impossible for them to ship broken tools. But since their only 'product' was the testing stuff, they often were self-absorbed in the latest TDD/BDD trend, adding the latest framework of the month, and spending time building poo poo nobody needed, breaking stuff in the process.

# ¿ May 2, 2014 03:14

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!