http://www.perlmonks.org?node_id=946913


in reply to Re^3: What language should I learn?
in thread What language should I learn?

ADO.Net itself was a big step ... in the wrong direction

I will disagree with that,it is valuable when you want to be in control of your SQL and data access and bindings,while I generally don't like ORM's like EF

I don't understand what do you mean by your "generics might be good for most occasions but they cannot do math"
check Math on Generics with C#’s dynamic keyword

See? WinForms are gone, WPF is gone, but the language under the UI may still be C#.
On the other hand are gone VB6, IronRuby,IronPython,Mono?,Silverlight?,while COM+ is resurected from the dead!History has a habit of repeating itself.And there is a strong push towards C++ as a mainstream language for the win platform

Replies are listed 'Best First'.
Re^5: What language should I learn?
by Jenda (Abbot) on Jan 08, 2012 at 21:23 UTC

    OK so you'd want something like Clean-style classes. Something like

    public T Foo<T>(Whatever<T> param) where T : (+), (-), (*), (/) { ... }
    Oh wait ... in Clean this is possible because the +, -, * and / operators are defined as "overloaded", in C# there'd need to be an interface including the four operators and the types that support those operators would have to implement the interface. Then:

    // in Clean foo:: a a a -> a | Arith a foo x y z = x + y * z // in C# public T foo<T>(T x, T y, T z) where T : IArith { return x + y * z; }

    A bit more talkative, but as I said ... it's not a problem with the generics per se, but rather with the lack of support for them in the old libraries.

    Update: Regarding the ADO.Net as a step in the wrong direction remark: I understand your sentiment regarding the ability to finetune the SQL and have access to the lower levels. The way ADO.Net took though, compared to the old ADO was IMnsHO wrong. While with the old ADO your queries returner recordsets, that could (based on the settings) be taken either as a pipe or navigated freely, with the new ADO.Net you ended up with tons of classes, tables, datasets, datarows, readers, ... It really looked like they expect you to load half of your database to memory and then god know what ... maybe run queries against the local data ... No, I did not like ADO.Net at all.

    Now you can treat Entity Framework as just an ORM and let it generate all the SQL based on LINQ queries and hope for the best. Or you can tweak the code generation template and use stored procedures returning exactly what you need exactly how you need, have them propagated all the way to C# in a type safe manner and even have the properties of the returned result rows inherit attributes (even custom ones) you assigned to columns of the tables. Now I do use LINQ and I do let EF generate my SQL ... whereever I'm not yet sure what properties will I need or if the query is simple enough or changes often or I don't care about the speed. If I do care, I define a stored proc, import it into the EF mapping file, tweak the results' attributes if needed and off I go.

    There are things I still hate about C#, but it kinda feels I'm going back to the functional languages I used to like at the university. Shame I don't have time to learn F# at the time. Even if I did not end up using it.

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.