Earlier quoted context omitted.
Perhaps not a satisfactory response but when I start drifting towards thinking FP is fundamentally not as performant as _whatever_else_, I remember that Jane Street uses OCaml basically from top to bottom, and they certainly can't be too slow... Some black magic going on there.
Is the kind of HFT that Jane Street does that reliant on extremely low latency? A lot of HFT firms operate on the timescale of seconds, minutes, or even hours, not milliseconds.
Why Isn't Functional Programming the Norm? [video]
371–380 of 417 posts
Re: Why Isn't Functional Programming the Norm? [video]
#372Earlier quoted context omitted.
I don't know, because I'm not qualified for it. I had to pass a course on FP, but frankly, I wouldn't be able to do anything with it in practice, let alone teach it. My only personal experiences with it were negative. If it had been Haskell that was the entry level programming course, then I probably would never have learned to program.
Okay, so given this answer here's what I would do: 1) I wouldn't make it the entry level course. It's clearly a paradigm that's used by a minority of people, so it doesn't make sense to start educating students with it. 2) I mandate that all students take it, maybe in their 3rd year. We're going to mandate it because there are tangible benefits (which we've assumed for the sake of this argument). They're going to fin…
Re: Why Isn't Functional Programming the Norm? [video]
#373Earlier quoted context omitted.
None, including C, which makes it nothing special. Any compiled language can call into Assembly. The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release. As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVis…
> None, including C, which makes it nothing special. Any compiled language can call into Assembly. I wish you joy and entertainment interfacing your managed data structures with assembly code. Yesterday I was forced to look into COM for the first time. There was some kind of callback that I was interested in, and it had basically two arrays as arguments, only in a super abstract from. I'm not lying, it was 30 lines o…
C is not a special snowflake.
Re: Why Isn't Functional Programming the Norm? [video]
#374Earlier quoted context omitted.
C doesn't tick any box regarding: - vector execution units - out of order execution - delay slots - L1 and L2 explicit cache access - MMU access - register windows - gpgpu All of that is given access by Assembly opcodes, not C specific language features. And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language…
> And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences. In the meantime, did you find a memory leak in my code? https://news.ycombinator.com/item?id=21275440 Not that I want to vehemently disagree with your security statements, but I think I'd love to have a little bit more "show" and less "tell". That also applies to showing practicality of managed lan…
Regarding show, don't tell.
The 21st century React Native for Windows is written on top of COM/C++,
https://github.com/microsoft/react-native-windows
https://www.youtube.com/watch?v=IUMWFExtDSg
We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/, and it gets regularly featured on the German press, https://www.dotnetpro.de/delphi-959606.html.
Re: Why Isn't Functional Programming the Norm? [video]
#375Earlier quoted context omitted.
> And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences. In the meantime, did you find a memory leak in my code? https://news.ycombinator.com/item?id=21275440 Not that I want to vehemently disagree with your security statements, but I think I'd love to have a little bit more "show" and less "tell". That also applies to showing practicality of managed lan…
It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? Regarding show, don't tell. The 21st century React Native for Windows is written on top of COM/C++, https://github.com/microsoft/react-native-windows https://www.youtube.com/watch?v=IUMWFExtDSg We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/ , and it gets regularly featured…
I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine.
> The 21st century React Native for Windows is written on top of COM/C++
From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of stuff that has COM buried underneath. That doesn't mean that COM is a necessity to do this React stuff, and not even that it's a good design from a developer's perspective.
You give zero ideas what's a good idea about COM. Just buzzwords and links to stuff and more stuff, with no relation obvious to me.
If you actually have to go through the whole COM boilerplate and the abominations to build a project with COM, just to connect to a service, because some people thought it wasn't necessary to provide a simple API (connect()/disconnect()/read_next_event()) then the whole thing isn't so funny anymore.
Re: Why Isn't Functional Programming the Norm? [video]
#376Earlier quoted context omitted.
Yes, the pickup truck has its uses, but when we talk about high-level vs low-level programming, are we debating about the sedan or the pickup truck?
well as always when discussing functional programming people are not discussing the merits of functional programming but rather the merits of basically throwing away objective programming in favor of functional programming. That is ofcourse complete nonsense but modern computer science politics like all modern politics only deals in absolutes
Re: Why Isn't Functional Programming the Norm? [video]
#377Earlier quoted context omitted.
To be fair, most of the set of optimization parameters enabled for the various for -Ox, including x=fast, is usually documented. At least in GCC though, there are a few optimizations included in the various -O flags that have no corresponding fine grained flag (usually because they affect optimization pass ordering or tuning parameters).
Yes they are documented, though the documentation is really something like "-fawesome-optimization, enabled by default on -O3" and the "-fawesome-optimization" has documentation like "enables awesome optimization" without explaining much more than that. And even then pretty much every project out there uses "-Ofast" instead of whatever "-Ofast" enables without caring about what it does or how its behavior will change…
Re: Why Isn't Functional Programming the Norm? [video]
#378Earlier quoted context omitted.
It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? Regarding show, don't tell. The 21st century React Native for Windows is written on top of COM/C++, https://github.com/microsoft/react-native-windows https://www.youtube.com/watch?v=IUMWFExtDSg We are having a Delphi conference in upcoming weeks, https://entwickler-konferenz.de/ , and it gets regularly featured…
> It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine. > The 21st century React Native for Windows is written on top of COM/C++ From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of s…
I really don't know what kind of COM you have been writing, because COM from VCL, MFC, ATL, UWP, Delphi, .NET surely doesn't fulfill that description.
As for what COM is good for,
"Component Software: Beyond Object-Oriented Programming"
https://www.amazon.com/Component-Software-Object-Oriented-Pr...
Re: Why Isn't Functional Programming the Norm? [video]
#379Earlier quoted context omitted.
> It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know? I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine. > The 21st century React Native for Windows is written on top of COM/C++ From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of s…
ReactNative for Windows uses WinUI and XAML Islands, which is UWP, aka COM. I really don't know what kind of COM you have been writing, because COM from VCL, MFC, ATL, UWP, Delphi, .NET surely doesn't fulfill that description. As for what COM is good for, "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/Component-Software-Object-Oriented-Pr...
As for other languages, I haven't touched COM at all but the idea of making GUIDs for stuff and registering components in the operating system doesn't seem a good default approach to me. Pretty sure it's more reliable to link object files together by default, so you can control and change what you get without the bureaucracy of versioning, etc.
> ReactNative for Windows uses WinUI and XAML Islands, which is UWP, aka COM.
Is the fact that COM is buried under this pile more than an unfortunate implementation detail?
Re: Why Isn't Functional Programming the Norm? [video]
#380OOP was designed to prioritize encapsulation at the expense of referential transparency. Functional programming was designed to prioritize referential transparency at the expense of encapsulation. You cannot have referential transparency and encapsulation at the same time. In order to prevent mutations (which is a requirement of FP), a module cannot hold any state internally; this necessarily means that the state mus…
Encapsulation is desirable because it limits the possibility space of what can operate on a set of data. Referential transparency is desirable because pure programs are much easier to reason about. If I understand what youre saying, it seems youre saying referential transparency and encapsulation are at odds and encapsulation is more valuable, but I disagree. Hiding state maybe keeps things tidy and enforces that you…