Programming mini-rants thread



  • Post little annoyances that you need to get off your chest, whether about websites, applications, operating systems, programming, programmers, whatever, as long as it is about computers and their misuse

    My inaugural rant is: why don't RDBMS designers and users actually understand relational database theory? Specifically, why don't they get

    • That tables are just a representation of a relvar, not the relvar itself and *certainly not the relation a relvar instantiates,
    • that attributes are an unordered set of domains within a relation's tuple,
    • that the order in which the relvars is added to the relation does not constitute an implicit index,
    • that a candidate key is any guaranteed-unique combination of relation attributes,
    • that no subset of relation attributes not guaranteed to be unique should be allowed to be used as a key or index,
    • that a relation defines a uniquely-constrained domain, such that two relations in the same table with the same primitive implementation are not of the same type in terms of strong typing,
    • that Relational domains are not fixed, concrete types, but purely-abstract sets that could be any collection of values that fit the set constraint (which could damn well be 'valid phone numbers in a given area code that are actually assigned at the time it is added', 'every integer except 1, 17, and 23', 'PNGs depicting portraits of the US Presidents', or even 'valid phone numbers in a given area code that are actually assigned at the time this view was generated', and the system should have a way for the DBA to define those constraints in a meaningful manner that can be applied automatically) , and nothing else,
    • that non-key values within a relvar should not affect the relational database's relational constraints in any way, and
    • that treating NULL as either truthy or falsey is a bad idea?

    It is as if the SQL team were working from a copy of Codd's book imported from Bizzaro World, and everyone else since then has just nodded and said, "sounds great!"


  • Winner of the 2016 Presidential Election

    @ScholRLEA said in Programming mini-rants thread:

    that treating NULL as either truthy or falsey is a bad idea

    Name and shame.



  • @ScholRLEA said in Programming mini-rants thread:

    that treating NULL as either truthy or falsey is a bad idea?

    It's obviously meant to represent FILE_NOT_FOUND



  • @asdf said in Programming mini-rants thread:

    @ScholRLEA said in Programming mini-rants thread:

    that treating NULL as either truthy or falsey is a bad idea

    Name and shame.

    Ah... oh, crap. I think I fucked up with that one, because while I have this recollection of seeing it somewhere (early versions of Sqlite, perhaps?) I can't pin down where, and now I am not sure if that is an accurate memory or not. In any case, it is more of a language (query and/or host) issue, unless the implementors really fucked up because it could screw up the joins in some cases if they did.

    Chalk it up to shoulder aliens, I guess.


  • Discourse touched me in a no-no place

    @ScholRLEA said in Programming mini-rants thread:

    That tables are just a representation of a relvar, not the relvar itself and *certainly not the relation a relvar instantiates,

    1. Tables are a way to generate a relation through providing the instances of the tuples that satisfy the relation. Tables themselves need a unique identifier per row in order to allow the table to be managed (otherwise it isn't necessarily possible to identify a particular row). That's not to say that you should pay attention to it when constructing queries that use the relation that the table induces.

    2. Anyone relying on an order they didn't ask for (whether explicitly or by configured default) is an idiot.

    3. You can INDEX ALL THE THINGS COLUMNS! but it gets expensive. In practice, you don't.

    4. I'm guessing you find ORMs annoying. That's perfectly OK. ;)



  • @ScholRLEA said in Programming mini-rants thread:

    That tables are just a representation of a relvar, not the relvar itself and *certainly not the relation a relvar instantiates

    I don't think I understand that at all.


  • Winner of the 2016 Presidential Election

    @dkf said in Programming mini-rants thread:

    I'm guessing you find ORMs annoying. That's perfectly OK.

    Some ORMs are worse than others. I still like working with SQLAlchemy



  • More like the programming medium-size rants thread.



  • @ScholRLEA said in Programming mini-rants thread:

    PNGs depicting portraits of the US Presidents

    Can you express this constraint in a formal way, please? 😉


  • kills Dumbledore

    Overly permissive programming languages. If I'm passing a string into a method that wants a Date, just dno't compile. I don't want a runtime error weeks after deployment because the string and locale settings didn't match, I want to be alerted so I can explicitly handle the places where strings go in


  • Discourse touched me in a no-no place

    @anonymous234 said in Programming mini-rants thread:

    @ScholRLEA said in Programming mini-rants thread:

    PNGs depicting portraits of the US Presidents

    Can you express this constraint in a formal way, please? 😉

    They're kind of green and also have pictures of numbers and $ symbols. Will that do?



  • @dkf can you send me the samples to analyze them?



  • @dkf Ah, clever, making use of the the built-in identification systems they have.


  • And then the murders began.

    Why is there no Comparable<T> class in the .NET Framework, akin to Comparer<T>?

    Given all the crap you're "supposed" to implement along with IComparable<T> (all of the various comparison operators, Equals(), GetHashCode()), it seems like there should be a helper to do most of that repetitive work for you .

    This library looks like it does what I want, but this feels like something that should be in the framework. (Especially when Microsoft's code analysis rules yell about skipping the other pieces.)



  • @dkf said in Programming mini-rants thread:

    @anonymous234 said in Programming mini-rants thread:

    @ScholRLEA said in Programming mini-rants thread:

    PNGs depicting portraits of the US Presidents

    Can you express this constraint in a formal way, please? 😉

    They're kind of green and also have pictures of numbers and $ symbols. Will that do?

    I'm not sure what you're talking about. The ones in my possession don't have $ symbols on them.


  • Winner of the 2016 Presidential Election

    @ScholRLEA said in Programming mini-rants thread:

    that no subset of relation attributes not guaranteed to be unique should be allowed to be used as a key or index,

    I might be misreading your intent here, but I don't think indexes should be included there - those are an implementation detail dealing with optimizations, not something required for relational theory (AFAIK). So depending on your queries, it may make sense to use indexes on non-unique attributes. But again, I may be misunderstanding what you meant there.

    (Technically I suppose one could say the same about the implementation of keys - they're pointers, an implementation detail. Shouldn't it be possible to create a relational DB that uses something more like references than pointers?)


  • Winner of the 2016 Presidential Election

    @Unperverted-Vixen said in Programming mini-rants thread:

    Why is there no Comparable<T> class in the .NET Framework, akin to Comparer<T>?

    Given all the crap you're "supposed" to implement along with IComparable<T> (all of the various comparison operators, Equals(), GetHashCode()), it seems like there should be a helper to do most of that repetitive work for you .

    This library looks like it does what I want, but this feels like something that should be in the framework. (Especially when Microsoft's code analysis rules yell about skipping the other pieces.)

    Eric Lippert basically said it was a mistake of the "we shouldn't have done it that way" sort:

    #9: Too much equality

    Suppose you want to implement a value type for some sort of exotic arithmetic—rational numbers, for example. Odds are good that a user will want to compare two rationals for equality and inequality. But how? Oh, that's easy. Just implement the following:

    • User-defined >, <, >=, <=, ==, and != operators
    • Override of the Equals(object) method
    • That method will box the struct, so you'll also want an Equals(MyStruct) method, which can be used to implement this:
    • IEquatable<MyStruct>.Equals(MyStruct)
      <li>You'd better implement this as well:</li>
      
      IComparable<MyStruct>.CompareTo(MyStruct)
      <li>For extra bonus points, you could implement the non-generic <tt>IComparable.CompareTo</tt> method, though in this day and age I probably wouldn't</li>
      

    I count nine (or ten) methods above, all of which must be kept consistent with each other; it would be bizarre if x.Equals(y) were true but x == y or x >= y were false. That seems like a bug.

    The developer has to implement nine methods consistently, yet the output of just one of those methods—the generic CompareTo—is sufficient to deduce the values of the other eight methods. The burden on the developer is many times larger than it needs to be!

    Moreover, for reference types it's easy to end up comparing reference equality accidentally when you intended to compare value equality, and get the wrong result.

    The whole thing is unnecessarily complicated. The language design could have been something like "If you implement a CompareTo method, you get all the operators for free."

    The moral: Too much flexibility makes code verbose and creates opportunities for bugs. Take the opportunity to stamp out, eliminate, and eschew unnecessary repetitive redundancy in the design.



  • @Unperverted-Vixen said in Programming mini-rants thread:

    Given all the crap you're "supposed" to implement along with IComparable<T> (all of the various comparison operators, Equals(), GetHashCode()), it seems like there should be a helper to do most of that repetitive work for you .

    ... how?

    I guess you could reflect the templated class, do something like convert it to JSON, then run a hash on that JSON. But that'd be pretty fucking slow.

    Is implementing .Equals() and .GetHashCode() really such a burden? It would never even occur to me to "automate" those, and I'm a lazy piece of shit when it comes to coding.


  • Winner of the 2016 Presidential Election

    @Unperverted-Vixen said in Programming mini-rants thread:

    IComparable<T>

    Wait, MSDN says IComparable<T> only requires defining CompareTo<T>():

    It requires that implementing types define a single method, CompareTo(T), that indicates whether the position of the current instance in the sort order is before, after, or the same as a second object of the same type.

    Did you mean IEquatable<T>?

    If you implement IEquatable<T>, you should also override the base class implementations of Object.Equals(Object) and GetHashCode so that their behavior is consistent with that of the IEquatable<T>.Equals method. If you do override Object.Equals(Object), your overridden implementation is also called in calls to the static Equals(System.Object, System.Object) method on your class. In addition, you should overload the op_Equality and op_Inequality operators. This ensures that all tests for equality return consistent results.

    Nevermind...

    If you implement IComparable<T>, you should overload the op_GreaterThan, op_GreaterThanOrEqual, op_LessThan, and op_LessThanOrEqual operators to return values that are consistent with CompareTo. In addition, you should also implement IEquatable<T>. See the IEquatable<T> article for complete information.


  • Winner of the 2016 Presidential Election

    @blakeyrat said in Programming mini-rants thread:

    @Unperverted-Vixen said in Programming mini-rants thread:

    Given all the crap you're "supposed" to implement along with IComparable<T> (all of the various comparison operators, Equals(), GetHashCode()), it seems like there should be a helper to do most of that repetitive work for you .

    ... how?

    I guess you could reflect the templated class, do something like convert it to JSON, then run a hash on that JSON. But that'd be pretty fucking slow.

    Is implementing .Equals() and .GetHashCode() really such a burden? It would never even occur to me to "automate" those, and I'm a lazy piece of shit when it comes to coding.

    If you only implement CompareTo<T>() (and maybe GetHashCode() depending on how you're comparing), you could automatically derive Equals<T>(), ==, <, <=, >=, >, and != through calling CompareTo<T>().



  • @Dreikin A lot of classes have no reasonable concept of "greater than" or "less than". Only "equal" or "not equal". That's why those are two different interfaces.

    If I have a list of, say, school teacher addresses, which one is "greater than" another? It's ridiculous to even think that way.


  • And then the murders began.

    @blakeyrat said in Programming mini-rants thread:

    ... how?

    By calling .CompareTo()?

    Is implementing .Equals() and .GetHashCode() really such a burden? It would never even occur to me to "automate" those, and I'm a lazy piece of shit when it comes to coding.

    Needing to override .GetHashCode() I have no problem with. If it was just .Equals() I probably would have sucked it up. But having to code .Equals(), and the six comparison operators (==, !=, <, <=, >, >=), all of which are just going to call my custom .CompareTo(), is a lot of boilerplate.

    (And yes, I know it's not "having to" in the sense of "I'll get a compile error if I don't" - well, depends on how you have your static code analysis tools set up, I guess. :) But as @Dreikin quoted from the docs, you're supposed to.)



  • @Unperverted-Vixen said in Programming mini-rants thread:

    By calling .CompareTo()?

    I preempted your post.

    .CompareTo() requires the data to have a logical ordering. A TON of classes do not. Virtually every class I've ever written in my last job working with healthcare data does not.


  • And then the murders began.

    @blakeyrat If there's no ordering, then why are you implementing IComparable<T> on the class to start with?



  • @Unperverted-Vixen You... wouldn't? What's your point?


  • Winner of the 2016 Presidential Election

    @blakeyrat said in Programming mini-rants thread:

    @Unperverted-Vixen You... wouldn't? What's your point?

    The original complaint was about all the boilerplate you have to do when using IComparable<T> - IEquatable<T> stuff was only mentioned in relation to that context.


  • And then the murders began.

    @blakeyrat That my rant was specifically about all the additional stuff you need to implement to do IComparable<T> "right", versus the framework doing the parts of it that are copy/paste for you.

    If you're not implementing IComparable<T>, then nothing I said is relevant to your class.



  • @Dreikin said in Programming mini-rants thread:

    The original complaint was about all the boilerplate you have to do when using IComparable<T> - IEquatable<T> stuff was only mentioned in relation to that context.

    Oh. Ok.

    I guess I lost the thread. Whatever.

    I thought you guys were trying to argue that if you implement IComparable you shouldn't need to also implement IEquatable, and I was just pointing out they're different concepts entirely.


  • FoxDev

    @Unperverted-Vixen said in Programming mini-rants thread:

    Needing to override .GetHashCode() I have no problem with. If it was just .Equals() I probably would have sucked it up. But having to code .Equals(), and the six comparison operators (==, !=, <, <=, >, >=), all of which are just going to call my custom .CompareTo(), is a lot of boilerplate.

    And it takes about two minutes to write it. Hardly a chore.


  • And then the murders began.

    @RaceProUK said in Programming mini-rants thread:

    And it takes about two minutes to write it. Hardly a chore.

    Not hard. Just tedious. Hence resurrecting the mini-rants thread rather than making this its own thing. :wambulance:


  • FoxDev

    @Unperverted-Vixen Pfft. I've occasionally spent longer than that naming a variable properly.


  • And then the murders began.

    @RaceProUK You mean I'm not supposed to declare all of them as object x;?


  • Winner of the 2016 Presidential Election

    @Unperverted-Vixen said in Programming mini-rants thread:

    @RaceProUK You mean I'm not supposed to declare all of them as object x;?

    Iterator variables are supposed to be i, j, and k, remember? We went over this like 50 times!



  • @Dreikin said in Programming mini-rants thread:

    Technically I suppose one could say the same about the implementation of keys - they're pointers, an implementation detail. Shouldn't it be possible to create a relational DB that uses something more like references than pointers?

    I'm not sure what you mean by this. Aren't foreign keys in one table a column or set of columns that share the same values as the primary key of another table? In what way are those pointers, and how could they be changed to be "more like references"?


  • Winner of the 2016 Presidential Election

    @djls45 said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    Technically I suppose one could say the same about the implementation of keys - they're pointers, an implementation detail. Shouldn't it be possible to create a relational DB that uses something more like references than pointers?

    I'm not sure what you mean by this. Aren't foreign keys in one table a column or set of columns that share the same values as the primary key of another table? In what way are those pointers, and how could they be changed to be "more like references"?

    Think like C++ (I know, bear with me).

    Each table is basically an array of objects, with their PK as their index. Each object may itself hold pointers to other objects, in this table or others. Let us imagine we have two simple tables:

    Customers:

    | PK | Name | Address |
    

    Orders:

    | PK (Order Number) | Customer | Total |
    

    To get from an order to it's corresponding customer's name, you basically do this:

    Order->Customer.Name
    

    To make it more reference-like, the DB could hide the pointers, so instead of having to dereference each order's customer you could just go directly to it:

    Order.Customer.Name
    

    Without ever having access to the key (the pointer).


  • Winner of the 2016 Presidential Election

    @Dreikin said in Programming mini-rants thread:

    @djls45 said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    Technically I suppose one could say the same about the implementation of keys - they're pointers, an implementation detail. Shouldn't it be possible to create a relational DB that uses something more like references than pointers?

    I'm not sure what you mean by this. Aren't foreign keys in one table a column or set of columns that share the same values as the primary key of another table? In what way are those pointers, and how could they be changed to be "more like references"?

    Think like C++ (I know, bear with me).

    Each table is basically an array of objects, with their PK as their index. Each object may itself hold pointers to other objects, in this table or others. Let us imagine we have two simple tables:

    Customers:

    | PK | Name | Address |
    

    Orders:

    | PK (Order Number) | Customer | Total |
    

    To get from an order to it's corresponding customer's name, you basically do this:

    Order->Customer.Name
    

    To make it more reference-like, the DB could hide the pointers, so instead of having to dereference each order's customer you could just go directly to it:

    Order.Customer.Name
    

    Without ever having access to the key (the pointer).

    To put it in more SQLish terms - instead of

    select Customers.name
    from Customers join Orders on Customers.PK = Orders.Customer
    where Orders.Total > 100
    

    you would do something like

    select Customer.Name
    from Orders
    where Orders.Total > 100
    


  • @Dreikin Doesn't that basically embed the Customer object within the Order, though? That breaks the purpose of having relationships. I think that's what non-relational databases do, isn't it?

    With your example, though, how would you distinguish which Customer to join if there can be more than one attached to the order? It's a bit contrived to fit with your example, but I can imagine someone buying a gift for their nephew off of his wishlist, but having to ship it to the nephew's parents to keep it secret.


  • Winner of the 2016 Presidential Election

    @djls45 said in Programming mini-rants thread:

    @Dreikin Doesn't that basically embed the Customer object within the Order, though? That breaks the purpose of having relationships. I think that's what non-relational databases do, isn't it?

    Not necessarily. I mean, it could be implemented that way, I suppose, but that's not what I'm talking about. The references are managed for you, as compared to pointers which you have to manage yourself.

    With your example, though, how would you distinguish which Customer to join if there can be more than one attached to the order? It's a bit contrived to fit with your example, but I can imagine someone buying a gift for their nephew off of his wishlist, but having to ship it to the nephew's parents to keep it secret.

    Just like in regular SQL, this isn't the proper layout for that possibility. You'd either want more fields (each of which can itself link to a Customer) or an N-to-N type model.

    To be clear, the reference doesn't exist because "Customer" looks like "Customer", but because in the database design it was specified that the Customer field of Orders references rows of the Customers table, much like how you already specify FK relationships in SQL.



  • @Dreikin said in Programming mini-rants thread:

    To be clear, the reference doesn't exist because "Customer" looks like "Customer", but because in the database design it was specified that the Customer field of Orders references rows of the Customers table, much like how you already specify FK relationships in SQL.

    Ah, ok. I see now. I missed the missing "s" in your example. Customer (no "s") is a column/FK in Orders that references the Customers table (with an "s"). That would be a nifty shortcut, though I think I'd still want the option to manually specify the joins, e.g. to do custom filtering with KVA constructs, unless you have a way to multiply-join a table with a FK relationship.


  • Banned

    @blakeyrat said in Programming mini-rants thread:

    I thought you guys were trying to argue that if you implement IComparable you shouldn't need to also implement IEquatable, and I was just pointing out they're different concepts entirely.

    But it would be awesome if you could do the equivalent of the following Rust code in C#, wouldn't it?

    impl<T1, T2> IEquatable<T2> for T1 where T1: IComparable<T2> {
        fn equals(&self, &T2: other) -> bool {
            self.compare_to(other) == 0
        }
    }
    

    Put that in standard library and no one has to write it ever again.

    Side note - in actual Rust, there's Eq interface that you can automatically implement for your type by just adding #[derive(Eq)] attribute to your struct (as long as all members also implement Eq) - it works like you'd expect, checking equality of each member; if you don't want that, you can always implement it manually. Implementing Eq is also how you overload == and != operators. Same with Ord and comparison operators. Of course, there's a huge asterisk all over this paragraph.


  • Winner of the 2016 Presidential Election

    @djls45 said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    To be clear, the reference doesn't exist because "Customer" looks like "Customer", but because in the database design it was specified that the Customer field of Orders references rows of the Customers table, much like how you already specify FK relationships in SQL.

    Ah, ok. I see now. I missed the missing "s" in your example. Customer (no "s") is a column/FK in Orders that references the Customers table (with an "s"). That would be a nifty shortcut, though I think I'd still want the option to manually specify the joins, e.g. to do custom filtering with KVA constructs, unless you have a way to multiply-join a table with a FK relationship.

    From my perspective, the SQL model is holding back relational database interaction and design. Foremost by only directly/easily modeling one type of relation (tables), but also by things like requiring this type of manual pointer management. It's like having to use C for everything - no C# or Go or Javascript or Lisp or anything else.

    So maybe that's something that could be improved likewise.


  • Discourse touched me in a no-no place

    @Dreikin said in Programming mini-rants thread:

    Foremost by only directly/easily modeling one type of relation (tables), but also by things like requiring this type of manual pointer management.

    Which other sorts of relations would you want?


  • kills Dumbledore

    @Dreikin said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    @djls45 said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    Technically I suppose one could say the same about the implementation of keys - they're pointers, an implementation detail. Shouldn't it be possible to create a relational DB that uses something more like references than pointers?

    I'm not sure what you mean by this. Aren't foreign keys in one table a column or set of columns that share the same values as the primary key of another table? In what way are those pointers, and how could they be changed to be "more like references"?

    Think like C++ (I know, bear with me).

    Each table is basically an array of objects, with their PK as their index. Each object may itself hold pointers to other objects, in this table or others. Let us imagine we have two simple tables:

    Customers:

    | PK | Name | Address |
    

    Orders:

    | PK (Order Number) | Customer | Total |
    

    To get from an order to it's corresponding customer's name, you basically do this:

    Order->Customer.Name
    

    To make it more reference-like, the DB could hide the pointers, so instead of having to dereference each order's customer you could just go directly to it:

    Order.Customer.Name
    

    Without ever having access to the key (the pointer).

    To put it in more SQLish terms - instead of

    select Customers.name
    from Customers join Orders on Customers.PK = Orders.Customer
    where Orders.Total > 100
    

    you would do something like

    select Customer.Name
    from Orders
    where Orders.Total > 100
    

    Isn't that basically what Entity Framework and, to a lesser extent, LINQ to SQL do? Especially if you use the query LINQ syntax.

    In EF code first, you'd create the customer class, create the order class with public Customer customer {get; set; } and then could use query syntax to do

    var bigSpenders = from o in orders
                      where o.Total > 100
                      select o.Customer.Name;
    

  • Winner of the 2016 Presidential Election

    @Jaloopa said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    @djls45 said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    Technically I suppose one could say the same about the implementation of keys - they're pointers, an implementation detail. Shouldn't it be possible to create a relational DB that uses something more like references than pointers?

    I'm not sure what you mean by this. Aren't foreign keys in one table a column or set of columns that share the same values as the primary key of another table? In what way are those pointers, and how could they be changed to be "more like references"?

    Think like C++ (I know, bear with me).

    Each table is basically an array of objects, with their PK as their index. Each object may itself hold pointers to other objects, in this table or others. Let us imagine we have two simple tables:

    Customers:

    | PK | Name | Address |
    

    Orders:

    | PK (Order Number) | Customer | Total |
    

    To get from an order to it's corresponding customer's name, you basically do this:

    Order->Customer.Name
    

    To make it more reference-like, the DB could hide the pointers, so instead of having to dereference each order's customer you could just go directly to it:

    Order.Customer.Name
    

    Without ever having access to the key (the pointer).

    To put it in more SQLish terms - instead of

    select Customers.name
    from Customers join Orders on Customers.PK = Orders.Customer
    where Orders.Total > 100
    

    you would do something like

    select Customer.Name
    from Orders
    where Orders.Total > 100
    

    Isn't that basically what Entity Framework and, to a lesser extent, LINQ to SQL do? Especially if you use the query LINQ syntax.

    In EF code first, you'd create the customer class, create the order class with public Customer customer {get; set; } and then could use query syntax to do

    var bigSpenders = from o in orders
                      where o.Total > 100
                      select o.Customer.Name;
    

    Yep, pretty much.


  • Winner of the 2016 Presidential Election

    @dkf said in Programming mini-rants thread:

    @Dreikin said in Programming mini-rants thread:

    Foremost by only directly/easily modeling one type of relation (tables), but also by things like requiring this type of manual pointer management.

    Which other sorts of relations would you want?

    Trees and graphs, in my case.


  • ♿ (Parody)

    @Dreikin said in Programming mini-rants thread:

    To get from an order to it's corresponding customer's name, you basically do this:

    Order->Customer.Name
    

    To make it more reference-like, the DB could hide the pointers, so instead of having to dereference each order's customer you could just go directly to it:

    Sounds similar to a natural join. But with SQL's syntax, not some object oriented sort of thing.


  • Winner of the 2016 Presidential Election

    @Jaloopa said in Programming mini-rants thread:

    Isn't that basically what Entity Framework and, to a lesser extent, LINQ to SQL do? Especially if you use the query LINQ syntax.

    Yup, sounds like what @Dreikin wants is exactly what good ORMs already do.


  • Winner of the 2016 Presidential Election

    @Dreikin said in Programming mini-rants thread:

    Trees and graphs, in my case.

    So, basically graphs, since the former is a subset of the latter. Sounds like you want a graph database or graph processing engine, and not an RDBMS.


  • Discourse touched me in a no-no place

    Python, why do you have to be so annoying? 🍊


    When one wants to get a slice of the last few values of a list or numpy array, you do:

    sublist = original[ -num_elems_to_pic : ]
    

    This works fine except when the number of elements to pick off the end is zero, when it gives you (a copy of) everything because -0 is equal to 0. Also, numpy 1.13 no longer tolerates mismatches in input length when doing a broadcasting array assignment.


  • Discourse touched me in a no-no place

    @dkf Also, the combination of these made all our integration tests go pop. Yay. :(


Log in to reply