They're doing the same thing with C#. The amount crap they have added to that language over the years is mind boggling - yet, we still don't have sum types which is the one thing that every C# developer I have worked with _really_ wants.
I have mixed views on this. We’ve gotten a lot of good with the bad. I think “C#, the Good Parts” would be a much thicker book than “JavaScript, the Good Parts”
Maybe, it's not my favourite language, but it seems basically fine. A new version drops, my five, ten year old code largely still just works and maybe there are improvements I have a use for in new code.
Some of the remaining warts are because it is wedded to the .NET CLR, so if the CLR says you can't do that then, too bad C# can't do that. It would not be practical to do anything about those.
We're discussing Windows and all its ad-ware/invasive changes, and someone brings up C# without giving a real explanation or examples.
The last few C# versions brought primary constructors, collection expressions, records(!), tons of Span<T> improvements/support, etc. I just flicked through the list, and nothing that stuck out to me as being bloated.
The main bloat C# has is older stuff that you really shouldn't be using anymore (e.g. ArrayList, dynamic, Thread, delegate keyword, etc).
> We're discussing Windows and all its ad-ware/invasive changes, and someone brings up C#
I brought up C# because the article discusses a Microsoft Windows design philosophy that I feel is also reflected in their approach to C#. It’s a Microsoft thing.
I agree with you that the examples you mention were great additions to the language! But I still think the C# design team has some seriously screwed up priorities. My theory is that this one year cycle they are on is hampering their ability to make changes (like sum types) that require more than a year of work.
See the links I listed above. None of those features solved a language problem as large as the lack of sum types. It baffles me that they even spent time on them before providing a feature that is in such high demand (and has been for more than a decade).
I understand that you shouldn’t always give users what they ask for - but this is something that has picked up steam in other languages because it’s actually useful and makes code bases easier to maintain.
I've used C# since 2008 for business software and high performance computing. I've not missed sum types at all. Most of what was added is something I see a lot of value in. I don't like that it, by design, obsoletes some older parts of the language, but that's about it.
I'm now using C# on linux almost exclusively. No complaints from me!
It's anything but a small language, but I wouldn't consider the stuff they're adding crap. They're useful features, but yes, this does have a price and makes the language larger.
There is value in a language with minimal syntax like Go, but it's not the only choice. C# is a pretty nice language overall, even with all the warts. But every language people actually use does have ugly stuff somewhere.
Presumably, you use a function like this to represent your sum type containing the value "avalue":
(readA, readB) => readA(avalue)
The problem I have is that when you create this function you have to reify the return type Z. You can't use this value in arbitrary contexts where the accessors need to return different types.
You want to return different types depending on the branch?
I mean you could return a sum type if you really need to.
Formally a sum type is just something that turns a pair of functions to Z into a single function from the sum type to Z. In fact it shouldn't do more than that.
No, in any particular use of the value both branches return the same type Z.
But when I want to use the value in two different places I don't want Z to be the same in both places.
That's where I'm stuck. When I instantiate the function that represents a value of the sum type I need to choose a return type Z, which is locked in for every use of the value.
I think I understand the idea. I don't see how to make it work in C#.
Yep, this is exactly the approach we take. It works ok-ish, but it’s far from elegant. In our case ‘read’ is ‘Switch’. I think it’s a fairly common pattern in C# these days.
Yes, very clunky. One of the big issues with this approach is that switch expressions still require a default branch because there’s no way in C# to express a completely closed set. This makes future changes to the set (sum type) hazardous.
> Kodak aims to conjure up cash by ceasing payments for its retirement pension plan.
I assume this means payments to retirees. It's a good reminder that (if you can help it) you should not rely 100% on any external source (including the government) for your retirement income.
> According to the company, the plan’s liabilities to qualifying participants would be satisfied through a combination of lump sum distributions and an annuity purchased from an insurance company to cover existing obligations. Kodak, like many corporate pension plans, is in a funding surplus; it has significantly more assets than liabilities owed to plan beneficiaries and participants.
> Kodak retirees would receive an annuity from an insurance company. Current employees, as well as former employees who haven’t yet reached retirement, would be given an option to either receive a lump sum of their balance, or an annuity once they retire. Plan participants wouldn’t see a change in the value of the benefits that have been promised to them, executives said.
> Kodak expects to put a new retirement plan in place for current employees if it terminates the pension. The company hasn’t yet determined whether it would provide a defined-benefit or defined-contribution plan, such as a 401(k). The company would need to have a new plan designed and in place within about a year, executives said.
The money in the pension fund, at least up to an amount needed to satisfy current liabilities, is the property of employees and Kodak has no right to it. It is the surplus that was taken back by Kodak last year, and future payments are the ones that are ceasing. Per WSJ above another retirement plan system will be setup for current employees.
ICE vehicle fires take about 1000 gallons, and the average fire hydrant puts out about 500-1000 gallons per minute. Structural fire engines carry about 1000 gallons and the heavy duty nozzles and ground monitors/deck guns put out 500-1000gpm. This is a LOT of water for a vehicle.
More like 300-400 gallons for your average urban engine. That's enough (with not much to spare) to knock down your average ICE car fire, but it's really there to allow the crew to get to work while they ship a hydrant.
I had the same thought, how many gallons is a diesel semi truck fire?
The part that concerns me is once electric cars are more ubiquitous, say 50% of cars on the road. How will we handle a pileup, where there could be five cars that all need the same level of fire department effort? Could there be some domino effect?
I read the fire sheets for other tesla cars and they say 8k gallons to suppress a battery fire. However, the Semi's sheet does not give a qty estimate.
That's low for an electric vehicle fire. An average car takes 500-1000 gallons. Teslas can take up to 30000-40000 gallons. Fwiw, most fire trucks only carry up to like 3000 gallons.
Most "Fire trucks" - I'm assuming you mean Engines - carry 500-1000 gallons, usually more on the 500 size. A "Water Tender" generally around 2000 gallons.
Software engineer, or IFSAC Apparatus Operator engineer? On the west coast we absolutely refer to our pumping apparatuses as fire engines; when Engine 813 is dispatched from our station to a call we bring the whole vehicle and not just the engine block!
