OneK

New programming jargon you coined? - Stack Overflow

Different kinds of bug reports:

Smug Report - a bug submitted by a user who thinks he knows a lot more about the system's design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.

Drug Report - a report so utterly incomprehensible that whoever submitted it must have been smoking crack. The lesser version is a chug report, where the submitter is thought to have had one too many.

Shrug Report - a bug report with no error message or repro steps and only a vague description of the problem. Usually contains the phrase "doesn't work."

via stackoverflow.com

Pega and "Signs that you're a bad programmer - Software Engineering Tips"

1. Inability to reason about code

  1. The presence of "voodoo code", or code that has no effect on the goal of the program but is diligently maintained anyway (such as initializing variables that are never used, calling functions that are irrelevant to the goal, producing output that is not used, etc.)
  2. Executing idempotent functions multiple times (eg: calling the save() function multiple times "just to be sure")
  3. Fixing bugs by writing code that overwrites the result of the faulty code
  4. "Yo-Yo code" that converts a value into a different representation, then converts it back to where it started (eg: converting a decimal into a string and then back into a decimal, or padding a string and then trimming it)
  5. "Bulldozer code" that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)
via yacoset.com

Pega makes doing all the above nearly required because of inconsistent libraries and reference frameworks that are not-editable. This makes the entire PRPC application stack hard to reason with.

1. The built in Pega code is opaque enough that if you don't copy something that exists and works, it is not terribly likely that your new code will.

1. If you want to change something in an inherited framework (broken/missing feature), you are essentially copying and pasting to your layer and tweaking small bits. The stuff you don't touch might as well be voodoo.

3. Error handling is hard so many inherited pieces of code do not do it properly.

4. Work -> Data -> Int -> Data -> Work for integration

4. Also, date processing. enough said

5. Big activities/flow are hard to read, so split them into smaller ones that only could ever be used from one place. The fix is to not write big activities, but since most projects are against other peoples code, this is not an option and refactoring is hard!


To the credit of Pega, the other bad practices are not encouraged quite as much. So to all of this, I say, "it's not my fault!"

 

my implementation of findall/3

I need to actually test this with an interpreter. I think this should work OK though. HoldNext contains the tail of a list we are building by tacking on Binding with each successful run of Code. Then we rebind whats in HoldNext to be the new tail. Finally, if Code fails, we set the var in HoldNext to [] to terminate the list.

The use of nb_setarg/3 is very important to save us from backtracking unwinding our difference list. Without testing this, my only question is if Binding needs to be term_copied before tacking it onto the difference list.

findall(Bindings, Code, ListOut) :-
   HoldNext=hold(ListOut), %store the tail of the difference list here
   (  Code,
      arg(1, HoldNext, Nxt), %var containing the hole to write to
      Nxt=[Bindings|NewNxt],
      nb_setarg(1,HoldNext, NewNxt),
      fail
   ;  arg(1, HoldNext, Nxt),
      Nxt=[]
   ).

how to monkey patch builtin python objects

magcius comments on Why do Windows functions all begin with a pointless MOV EDI, EDI instruction?

[–]magcius 29 points30 points 16 hours ago

Sure you can! Try it at home:

import ctypes

grab_raw = ctypes.pythonapi._PyObject_GetDictPtr
grab_raw.restype = ctypes.POINTER(ctypes.py_object)
grab_raw.argtypes = [ctypes.py_object]

def better_setattr(obj, name, val):
    obj_dict = grab_raw(obj).contents.value
    obj_dict[name] = val

better_setattr(object, "a", 3)
print object.a
via reddit.com

don't try this in real code

foldl in prolog (2)

Here’s another shot of foldl in prolog. this one is a little cleaner than the last version.

foldl(Gen, Pred, In=Init, Out) :-
    H=hold(Init),
    (   Gen,
        H=hold(CurVal),
        In=CurVal,
        Pred,
        nb_setarg(1, H, Out),
        fail
    ;   H=hold(Out)
    ).

here are the same samples provided before

?- foldl(member(Loc, [1,5,9]), append(In,[Loc,space],Out),
        In=[], Out).
Out = [1, space, 5, space, 9, space].

?- foldl(range(1,3,L), Out is In+L, In=0, Out).
Out = 6.