|
Dessert Rose posted:Don't ever look into EF. That is a convoluted bag of suck. EF meaning Entity Framework? It really doesn't take hours. What version are you thinking of? It's gotten more streamlined since 4.0, but even 4.0 was easy if you use the Wizard. In fact I would consider it the go to choice for quick and dirty CRUD applications driven by humans (it's less suited to read-heavy server apps). What specific issues are you thinking of?
|
#
¿
Oct 2, 2013 21:52
|
|
|
|
| # ¿ Apr 28, 2024 02:44 |
|
|
You might be dealing with a high-latency/low bandwidth link where you need to tweak a configuration value to get you or your client back in the market *right now*. Cutting a new version and deploying out takes time. That's an appropriate reason. The real horror is not immediately then merging the change back into source control so that your changes are re-releasable. And it's perfectly reasonable for developers to have access to and indeed troubleshoot and fix problems in production when you're geared towards minimising downtime.
|
|
#
¿
Jul 9, 2014 23:04
|
|
|
Powerful Two-Hander posted:Are all java developers poo poo at anything and everything involving databases or is it just the ones I deal with? Talking about SQL Server here mostly, but if you're using parameterised queries, then executing text queries rather than stored procs doesn't typically incur repeated execution plan compilation overhead or anything like that. Additionally it means you can roll out bug fixes to your queries without having to co-ordinate with the DBAs for production databases, and versioning/rollback is easier. Also stored procs for reading data are horrible, at least in SQL Server. If the drat thing dumps out 1000 rows, and you need to dig through it, I guess you're pasting the result set into Excel then or something. At least with views or table valued user-defined functions you can filter if you're trying to debug prod issues. I personally only ever go for stored procs if 1) infosec and auditing requirement or 2) execution plan analysis shows it's better for some reason.
|
|
#
¿
Dec 5, 2014 22:58
|
|
|
ChickenWing posted:
I see a fair amount of null != value checks in Microsoft's .NET Reference Source (e.g. StringBuilder.cs) and it always slightly bugs me.
|
|
#
¿
Jun 18, 2015 15:02
|
|
|
Soricidus posted:Seriously gently caress every language designer who has ever included null after this was invented I'm possibly missing some subtlety above, but null is useful in imperative based programming languages where you don't know what the value of a variable to be assigned will be yet, and it doesn't have a sensible default value. It also fulfills the useful requirement of failing hard and fast when one arises unexpectedly - it means you've got a logic error or a failure to respect the interface of a method call. I think most .NET programmers wouldn't mind as much if the null reference exception just listed the variable name somehow (or if the runtime was able to infer the type the object was meant to be). e: I guess you're encoding that it can return a unit in the signature of the method, which could be useful - but isn't unit in danger of becoming a bucket type like null then? i.e. It's undefined, or the method does something under the covers. Milotic fucked around with this message at 10:27 on Jul 5, 2015 |
|
#
¿
Jul 5, 2015 10:23
|
|
|
|
| # ¿ Apr 28, 2024 02:44 |
|
|
Dessert Rose posted:Not initializing the variable is a perfectly acceptable option here. Your compiler should be able to work out if the variable is definitively initialized before use in all execution paths. Within a method yes, but some times you really do need to return a null. e.g. A method that returns information on something in the real world - what's the address of this person. Oh it's not been added yet. quote:Wouldn't it be better if the compiler could catch that you weren't respecting the interface of a method call? Yes, but it would likely not cover every edge case and possibly bloat compile times. quote:If it's encoded in the signature of the method and I have to unwrap it explicitly (like returning a Maybe or an Either) then it's obvious from the caller side that I have to handle both cases. I definitely agree that returning a Maybe or Either forces you to handle it, but that can cause issues as well: 1) You use a 'railway orientated' approach and it ends up bubbling to the top anyway. Depending on the language, you have difficulty tracking it back to the place where it wrong. This is especially a problem in deeply nested systems. I've done something like this in systems built in C# which should avoid throwing exceptions, so they return an Attempt<T> object instead, and sometimes you do wish you had a stack trace at the point it first went wrong. 2) It forces you to make a decision there and then about what to do in order to get the program to compile, which you might not be able to make at the time. Or you might make the wrong one. Some systems benefit from crashing hard and fast when they run into edge cases like this. I have to admit, of all the problems with C# (it's a great language but the .NET framework is bit wonky in places especially 1.0 apis), I don't personally rate null reference exceptions as that big of a problem. It's highly likely my experience has been coloured by the types of problems I've had to work on though. I've done a lot of work on build, test and monitoring systems in secure environments, so everything is terrible in a different way. It would be interesting to see what falls out in terms of quirks and painpoints when you do start having ADTs and pattern matching in languages meant for LOB apps, where stuff is often a bit woolly, and you get edge cases for certain customers, accounts, geographic regions, time zones, whatever. (This is my chief concern with functional programming in particular - if you're trading 40 stock exchanges, they all differ in weird ways and at different points. Sometimes you just need to hack stuff). I'd be quite happy with null staying in the language, but with language support for code contracts. Though even then that can lead to fun and games with polymorphism - inputs valid for one implementation aren't for another, but they all use the same interface since interfaces being injected in can be more descriptive than a general function call. (Func is great, but abused it can be as meaningless as Tuple<X,Y> vs a properly named class).
|
|
#
¿
Jul 5, 2015 11:49
|
|