Reality or WTF?
-
@Zenith said in Reality or WTF?:
@boomzilla said in Reality or WTF?:
We used to regenerate everything when we were first building the application but we haven't done that for over a decade. I'm not sure what "regenerating" classes means, but I've never used ADO. We just update the classes in code (including annotations for stuff like field size).
The two places I worked that used Entity, in 2015, had to lock TFS and regenerate every single object class after a change to the database. It took hours to run whatever they did and, when it was over, you lost all of your customization. For some people, that's the meager handful of attributes it allowed you to define. For others, that's the real business rules that said meager handful of attributes provided didn't cover. Absolute nightmare.
I have no idea what "Entity" is but it sounds awful. What sort of changes did it automate that you couldn't have just made yourself?
It's not that people can't do all that stuff by hand, but if you don't need to, why would you?
Don't be so sure about that first part.
I'm sure about it as far as I am concerned.
As for why you'd want to....do you want a list?
- The number of database-derived objects in a properly designed system is really small. In that case, it's like paying somebody to clip your toenails. You saved 30 seconds on the clipping and lost 30 minutes driving, waiting in line, making small talk with the professional clipper, and being rung up at the register.
- The number of database-derived objects in a properly designed system is really small. Once you hide the "pain" of setting them up, you open the door for that number, and the complexity of the database, to fucking explode. Good luck navigating, troubleshooting, or refactoring that once the problems start (and they will, believe me).
You've already lost me. What's a "database-derived object?" Do you just mean objects that you load from the database? If so then we've worked on very different systems. I can't even imagine what such a thing would be. Where do you get your data if not from the database?
Are you putting your data in something other than a database? I seriously can't comprehend what you're saying here.
- You lose the ability to actually optimize code. Maybe I don't need all 50 columns off a
table. Maybe I don't need the boilerplate.
I do this all the time. As I said, I have a ton of native queries where that's what I need.
- Sometimes you don't need another dependency that throws up word salad when it doesn't want to work. Sometimes you don't need the dependencies it's dependent on either. Sometimes you don't want pulled along the update treadmill.
Sure, if that's where your ORM is going, that's a problem. I haven't had that issue with Hibernate. We've upgraded a few times over the years and had plenty of upgrade headaches but I don't remember any from Hibernate.
- Sometimes you need to do something the library won't let you do ("you don't need..."). Sometimes you know better than some nebulous "community" of "experts" whose credentials are basically being the right color to pass a Google interview. When every idea is summarily shot down because "library/service something something dark side," what you're really being told is that you're never good enough, What if everybody thought that way? Where would any progress or differentiation come from? How the hell are you supposed to learn anything if your job is plugging half-baked black-box shit together all of the time? At that point, you're not even a developer anymore.
Mismanagement shooting down good ideas is not a library problem and they probably would do it with or without the ORM if that's what floats their boats.
It's not that you can't use a library/service, It's the insane tunnel vision that forces the library/service to the exclusion of all else.
So...don't do that? That's your problem not the library's.
-
@boomzilla said in Reality or WTF?:
I have no idea what "Entity" is but it sounds awful. What sort of changes did it automate that you couldn't have just made yourself?
It's an ORM used by developers that hate ADO because it's "too hard." Like Dapper or Hibernate or anything else on this list.
I'm sure about it as far as I am concerned.
Lucky you. I miss working with people above the level of "framework cobbler."
You've already lost me. What's a "database-derived object?" Do you just mean objects that you load from the database? If so then we've worked on very different systems. I can't even imagine what such a thing would be. Where do you get your data if not from the database?
A database-derived object is an object backed by a database record. The database has a Users table with columns Name, Height, Weight, The code has a User object with fields Name, Weight, Height. The ORM saves five whole minutes by magicking up a select statement and transferring columns to fields.
Are you putting your data in something other than a database? I seriously can't comprehend what you're saying here.
No. What I'm saying is a Mickey Mouse system that manages registration data shouldn't have 3000 tables with data duplicated all over it. It does because nobody has to really do the work and see what's happening. They just create another class/table, push a button, and then one day your system is "suddenly" 900 lbs and has to be airlifted out through a hole cut in the roof.
- Sometimes you don't need another dependency that throws up word salad when it doesn't want to work. Sometimes you don't need the dependencies it's dependent on either. Sometimes you don't want pulled along the update treadmill.
Sure, if that's where your ORM is going, that's a problem. I haven't had that issue with Hibernate. We've upgraded a few times over the years and had plenty of upgrade headaches but I don't remember any from Hibernate.
Entity has a setting where it won't let you save an object twice in the same load context. Create/update object, do something else, update a relevant field, crash. Throws up this wall of text that doesn't even say what the problem is. Really bad management wouldn't acknowledge the problem, wouldn't do anything about it (TFS was locked), and wouldn't tolerate workarounds. Just keep hauling me into "counselling sessions" when I was tired of being harped at about a completely farcical deadline. Same sort of garbage "thinking" happened with WebForms. Oh, the FormView's so easy, just do this and this and this and this and "FormView does not support AJAX" but use AJAX anyway or else.
So the next job, they were also using an ORM (suspect Entity but not sure) a dozen layers down under an app that only worked in Chrome. A fresh pull from TFS built but wouldn't execute. Don't recall the error it popped up but it was a smaller bowl of word salad. Of course, the only person left on the project is remote and tells me to figure it out. Because he wants me to use this project that won't load to unit test a UI change. Oh I figured something out alright, I figured out where I didn't want to work.
- Sometimes you need to do something the library won't let you do ("you don't need..."). Sometimes you know better than some nebulous "community" of "experts" whose credentials are basically being the right color to pass a Google interview. When every idea is summarily shot down because "library/service something something dark side," what you're really being told is that you're never good enough, What if everybody thought that way? Where would any progress or differentiation come from? How the hell are you supposed to learn anything if your job is plugging half-baked black-box shit together all of the time? At that point, you're not even a developer anymore.
Mismanagement shooting down good ideas is not a library problem and they probably would do it with or without the ORM if that's what floats their boats.
The library mentality enables it though. As long as there's the false hope of a silver bullet out there somewhere, or, worse, a silver bullet they've already paid for, you're stuck between a rock and a hard place. You're right back to being the miller's daughter expected to spin straw into gold. If I hadn't experienced it so many times, I'd have trouble believing it too. There's a real problem with functionally illiterate people insisting on controlling exactly how the work is done and blaming everyone but themselves when it turns out the only way it can turn out.
It's not that you can't use a library/service, It's the insane tunnel vision that forces the library/service to the exclusion of all else.
So...don't do that? That's your problem not the library's.
Au contraire. Not employed as a developer anymore, not forced to play stupid about development practices anymore.
-
@Zenith said in Reality or WTF?:
@boomzilla said in Reality or WTF?:
You've already lost me. What's a "database-derived object?" Do you just mean objects that you load from the database? If so then we've worked on very different systems. I can't even imagine what such a thing would be. Where do you get your data if not from the database?
A database-derived object is an object backed by a database record. The database has a Users table with columns Name, Height, Weight, The code has a User object with fields Name, Weight, Height. The ORM saves five whole minutes by magicking up a select statement and transferring columns to fields.
Are you putting your data in something other than a database? I seriously can't comprehend what you're saying here.
No. What I'm saying is a Mickey Mouse system that manages registration data shouldn't have 3000 tables with data duplicated all over it. It does because nobody has to really do the work and see what's happening. They just create another class/table, push a button, and then one day your system is "suddenly" 900 lbs and has to be airlifted out through a hole cut in the roof.
Um, OK, but that's nothing like what you originally said.
- Sometimes you need to do something the library won't let you do ("you don't need..."). Sometimes you know better than some nebulous "community" of "experts" whose credentials are basically being the right color to pass a Google interview. When every idea is summarily shot down because "library/service something something dark side," what you're really being told is that you're never good enough, What if everybody thought that way? Where would any progress or differentiation come from? How the hell are you supposed to learn anything if your job is plugging half-baked black-box shit together all of the time? At that point, you're not even a developer anymore.
Mismanagement shooting down good ideas is not a library problem and they probably would do it with or without the ORM if that's what floats their boats.
The library mentality enables it though.
OK, people who aren't management making dumb decisions then. The point is that you're not talking about a technical problem.It's not that you can't use a library/service, It's the insane tunnel vision that forces the library/service to the exclusion of all else.
So...don't do that? That's your problem not the library's.
Au contraire. Not employed as a developer anymore, not forced to play stupid about development practices anymore.
I'm just saying...most of your rant actually had nothing to do with ORMs and everything to do with dumb people doing dumb things. Which is a fine thing to rant about, but you misrepresented it as a rant about ORMs.
-
@Zenith said in Reality or WTF?:
The two places I worked that used Entity, in 2015, had to lock TFS and regenerate every single object class after a change to the database. It took hours to run whatever they did and, when it was over, you lost all of your customization. For some people, that's the meager handful of attributes it allowed you to define. For others, that's the real business rules that said meager handful of attributes provided didn't cover. Absolute nightmare.
I've used Entity Framework and Hibernate quite a bit, and in both I had the option of manually updating my code to add a var or reflect whatever change was made in the DB.
-
@hungrier Also, if you lose customization in your DB entities, you're the kind of stupid that modifies auto-generated code. There's a fucking good reason why all Entity Framework objects are declared as partial classes.
-
@boomzilla said in Reality or WTF?:
Um, OK, but that's nothing like what you originally said.
That's exactly what I said. If you think creating objects and tables is as easy as pushing a button, you don't think about the costs because you think they're free. They're not. They have all sorts of costs that you don't see,
I'm just saying...most of your rant actually had nothing to do with ORMs and everything to do with dumb people doing dumb things. Which is a fine thing to rant about, but you misrepresented it as a rant about ORMs.
An ORM is an abstraction that takes database knowledge out of the equation of developing database applications. This allows you to hire cheaper and less capable developers that go on to commit untold volumes of WTFs that a developer with some understanding of the mechanics wouldn't have. After they've piled WTF on top of WTF on top of WTF and it finally comes crashing down, they're completely and utterly lost.
I've seen it. I used to have to have this conversation regularly:
I am having problem is slow again.
X needs to change to Y because Z.
I am not wanting to being doing that.
Then I don't know what to tell you.
The team isn't communicating! Especially !
Let's have more meetings where I don't listen to anybody and just bark!
Call Microsoft support and spend three days coming to the same conclusion and we'll ignore it from them too.@hungrier said in Reality or WTF?:
I've used Entity Framework and Hibernate quite a bit, and in both I had the option of manually updating my code to add a var or reflect whatever change was made in the DB.
Unfortunately, I did not. I had somebody with the force commit mentality and a tool that enabled them create work downstream through its abuse. In an ADO project you don't have to worry about it to the same level.
@Mingan said in Reality or WTF?:
@hungrier Also, if you lose customization in your DB entities, you're the kind of stupid that modifies auto-generated code. There's a fucking good reason why all Entity Framework objects are declared as partial classes.
And when you need to modify something that's auto-generated? I understand partial classes just fine but I rarely have a need for them.
-
@Zenith said in Reality or WTF?:
I've seen it. I used to have to have this conversation regularly:
No one disputes that stupid people exist. But I'm not going to throw out perfectly good tools because some idiots misuse them.
-
@boomzilla And, again, I never said that you had to quit using an ORM. I said that ADO isn't difficult, that I've personally seen way more time wasted than saved by Entity, and spelled out my reasoning in a list. No force in the universe is going to coerce me into piling on dependency layers that I don't need.
-
People harp on java, but the tooling and frameworks are pretty good, like JPA and providers like Hibernate.
I have none of the problems at all described here with those.
I've also been around long enough to have seen what dumb devs produce with raw SQL, and it's not an improvement.
When manglement gets in the way of getting stuff done as described, I either just move on to another gig or ignore them and do the needful.
-
@Carnage Java is a lot better than some other things. I would rather use Java for a big application than Rust. The reason people harp on Java is because it's still got a ton of failures, like the fact that 'just use this third-party library' is an extremely common refrain (hell you even mention them!), or that there aren't any value types / extension methods /
lambdas/ reified generics /local variable type inference/ other useful things. C# is a language in which you can do absolutely everything you can do in Java, not to a 'Ruby is superior because Ruby' degree but to a 'literally just start writing Java and the compiler errors will be all you need for now' degree.
Also, re: the language is crap, Kotlin's existence combined with .NET Core means that Java post 1.5 is just completely dead as a language, and there's no reason not to use Kotlin if you're shackled to the JVM and there's no reason not to use C# if you're not.
-
@pie_flavor said in Reality or WTF?:
@Carnage Java is a lot better than some other things. I would rather use Java for a big application than Rust. The reason people harp on Java is because it's still got a ton of failures, like the fact that 'just use this third-party library' is an extremely common refrain (hell you even mention them!), or that there aren't any value types / extension methods /
lambdas/ reified generics /local variable type inference/ other useful things. C# is a language in which you can do absolutely everything you can do in Java, not to a 'Ruby is superior because Ruby' degree but to a 'literally just start writing Java and the compiler errors will be all you need for now' degree.
Also, re: the language is crap, Kotlin's existence combined with .NET Core means that Java post 1.5 is just completely dead as a language, and there's no reason not to use Kotlin if you're shackled to the JVM and there's no reason not to use C# if you're not.I mostly do JavaEE, and JPA is a standard thing in that bit of the field. Also, every single platform I've used you get "Use this library!". It's just how software development works, unless you're on a bad platform or a very rare field.
With regards to Java being dead, I see you haven't been out and about in the field much. Now I do wildly prefer Kotlin to Java, but Java is in no way, form or shape dead, or dying. Which is evident in that they keep adding the stuff you say it doesn't have. Value types is coming soon (in language design terms) apart from the things you struck out. I do not think we'll ever get proper extension functions, for the same reason we do not have proper lambdas in Java.
Like all software, languages are flawed, all programming languages in existence are flawed. Java is as well. It's just no more flawed than anything else.As far as Kotlin goes, ever since Google endorsed it, I think it's been doomed to fail.
-
@Carnage Kotlin doomed to fail? It's got first class support in Android; that's backing enough.
I say Java is dead as a language because Kotlin is a superior drop-in replacement (and even side-by-side) JVM language, and .NET Core is a superior platform with C# being superior even to Kotlin. There is simply no reason to use Java anymore, unless for some reason you actually like the new module system, and like it more than you dislike the language/platform's shortcomings.
Value types are not coming to Java. There's record types in a new JEP that you may have confused them with, but there's no C#-style structs. Project Valhalla is about specializing generics for existing value types, not writing your own. Also, Java does in fact have proper lambdas - you may be confusing them for proper function types.
It's not a 'use this library' problem. It's a 'we didn't bother' problem. C# has EF, ASP.NET, WPF, etc., all made by Microsoft.
-
@pie_flavor when you graduate college and enter real life, you'll notice that objective qualities have very little to do with language popularity. Java will stay in top 10 for at least another decade.
-
@pie_flavor said in Reality or WTF?:
Value types are not coming to Java. There's record types in a new JEP that you may have confused them with, but there's no C#-style structs. Project Valhalla is about specializing generics for existing value types, not writing your own. Also, Java does in fact have proper lambdas - you may be confusing them for proper function types.
Value types are coming to Java, in a future release. According to the keynote, it will be possible to specify an arbitrary class as a value type.
See under "project valhalla".
Oracle Code One Java Keynote Outlines the Future of Java
Provides update on recent Java developments, previews future innovation
As for Kotlin being doomed to fail, just look at every language Google had a go at. Google kills software. And I do really like Kotlin, but how good a language is has fuck all to do with how well it will survive.
And Android is not a solid base for the future: https://en.wikipedia.org/wiki/Google_Fuchsia
-
@Gąska not for any significant reason, though. Kotlin is different in that since it has total compatibility with Java, you can stop writing Java and start writing Kotlin and there will be no integration difficulties. You could migrate the entire codebase or you could do absolutely nothing with it and it'd still be just as easy to use Kotlin. Compare to every other 'this is the hot new language' where there's significant migration or re-defining involved.
-
@Carnage said in Reality or WTF?:
And Android is not a solid base for the future: https://en.wikipedia.org/wiki/Google_Fuchsia
It's in incredibly pre-alpha. My point was that since Kotlin's backed by such a giant company for such a giant platform, that should signify that it's ready for production.
As for Kotlin being doomed to fail, just look at every language Google had a go at. Google kills software.
Google doesn't have any creative control over Kotlin. Same as they didn't have any over Java, which Google didn't kill either.
Value types are coming to Java, in a future release.
TIL. Still, that's such an incredibly Java way to do it. Each individual object can be locked, meaning that the value-type-ness is use-site, not semantic, and results in complete immutability not to mention the fact that library functions returning locked objects means this breaks existing code (including some of mine! I have a line somewhere that uses the identity hash code of an Integer). At runtime, no less, since the type system has no support for this. In fact the value types themselves are an implementation detail, and the real proposal is just about this permanent immutability. When I said value type I meant value type.
-
@pie_flavor said in Reality or WTF?:
Google doesn't have any creative control over Kotlin. Same as they didn't have any over Java, which Google didn't kill either.
The difference between Java and Kotlin in that regard is that Java was already everywhere. Android used Java because it was ubiquitous already. Android is a rather minor blip compared to what Java normally is used for. Kotlin is nowhere, and Android is the main point. Android is also targeted by a never ending stream of transpilers and framworks to code once and build everywhere. Flutter being one of them. I do really like Kotlin, and I want it to succeed and replace Java as the language for the JVM, but I really do not see it happening.
If Jetbrains get Kotlin Native, Kotlin JS and Kotlin Java on equal footing, and properly working seamlessly with different compilation targets, then Kotlin will have a pretty good chance I think.It's in incredibly pre-alpha. My point was that since Kotlin's backed by such a giant company for such a giant platform, that should signify that it's ready for production.
somethimeYeah, alpha never really stopped google though. And Google are planning to throw Android away, so depending on Android as your base of existance (for Kotlin) is a bad move.
-
-
@pie_flavor said in Reality or WTF?:
@Carnage said in Reality or WTF?:
Google are planning to throw Android away
Sauce?
Plenty of guesswork in lot's of media. But it seems rather plausible, depending on the outcome of the pissing contest currently going on on the inside.
Google wants more footprint to gather precious precious data, and foist ads in peoples faces. Making Fuchsia run on IoT, phones, computers and everything else seems in line with their general MO. It's coming. And fuchsia is already running on the Pixel.
-
@Carnage Android already runs on IoT and phones. ChromeOS runs on computers and regular Chrome does too. Fuchsia runs on the Pixelbook, not the Pixel. IOW, it's a total and complete asspull.
-
@Zenith said in Reality or WTF?:
And when you need to modify something that's auto-generated?
I can't see any use case where you'd want to do that.
