151–160 of 333 posts
Earlier quoted context omitted.
> without being prone to floating off into abstraction orbit What do you mean by this?
"Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"
Earlier quoted context omitted.
Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.
I found it rather annoying that you cannot organise your code to be readable from top-to-bottom in a file, going from the big picture to finer details. Which, I think is much easier for humans.
I'm not particularly attached to order of definitions within a module, but I definitely like the linear ordering of modules. Without the compiler enforcing that you always end up with cross dependencies between modules, which I think makes it much harder for humans to read the code.
I've had similar conversations about variable shadowing. I find it natural and it bothers me when I can't do it, especially in functional languages, but I have a friend who really doesn't like it and finds it jarring. I think his dislike stems from having learned Erlang before any language that has shadowing, because in Erlang when you reuse a variable name it'll be checking for equality with the value you're "assigning" it to.
(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.
Also, you correctly anticipated that Swift would become mainstream long before F#, which happened. Of course hindsight is 20/20, but this wasn't that obvious back in 2015. Your reasoning was sound.
Earlier quoted context omitted.
You are the first person I have heard mention the desire to transition from C# to Rust. Usually, it is C++ to Rust, or Java to C#. if the tooling would be on par I am betting person, and I say: "It never will be." It is easy to overlook the importance of better developer tooling. It directly translates into higher developer productivity. Every time I am forced to use a language with worse developer tooling, I am remi…
Agreed, I think people are sleeping on the relative disparities in tooling between langs, and it will only get worse. I feel this daily as a Clojure programmer. I've been playing with Copilot, and it's astonishing how much worse Copilot is at generating Clojure code, than say, Js. The difference is probably due to training volume, and if AI-assisted coding is worth it at all, the benefits will primarily accrue to the…
Earlier quoted context omitted.
There is much naïveté among the strongly typed herd. Is exactly the reverse also true? Let me try: "There is much naïveté among the weakly typed herd." For every person who thinks Python or Ruby can be used for everything, there is another person who thinks the same for C++ or Rust. Also, the example that you gave is incredibly specific: When tasked to create glue code translating between two opposing type systems, w…
I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use. I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small t…
I am surprised that you are using Python for data transformation. Isn't it too slow for huge data sets? (If you are using C/C++ libraries like Pandas/NumPy, then ignore this question.) When I have huge amounts of data, I always want to use something like C/C++/Rust/C#/Java do the heavy lifting because it is so much faster than Python.
Earlier quoted context omitted.
You realize every single thing that dynamically-typed languages can do with data types, statically-typed languages can do too? Except when it matters, they can also choose to do things dynamically-typed languages can't. Lots of people assume static typing means creating domain types for the semantics of every single thing, and then complain that those types contain far more information than they need. Well, stop doin…
Reminds me of https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... . Always a fun revisit.
Earlier quoted context omitted.
You could have out of order function declarations.
Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.
In codebases that allow out of order definitions, things get wild real quick.
This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.) I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in. If I had to pick a language that pre…
I think F# programmers lack that gamut because they get comfortable in the eager execution type safe world and stay there with no particular reason to learn dynamic programming techniques. There is also the effect that it allows less advanced functional programmers to be productive so that in randomly sampling currently active functional programmers the F# programmer is less likely to be advanced. Scala developers we…
One would expect that by now, out-of-process COM would be supported across all OS extension points, instead it is still pretty much in-process COM, with the related .NET restrictions.
Then there is the whole issue that since Longhorn, most OS APIs are based on COM (or WinRT), not always with .NET bindings, and even VB 6 had better ways to use COM than .NET on its current state (.NET Core lost COM tooling).
Earlier quoted context omitted.
Every system if allowed to become too complex. No single paradigm of programming is perfect for all cases. OO is one way to structure and model a system. No matter what language you use will end up with some form of a struct, a set of values that belong together Then you will have list of some structs and trees of some structs You will almost certainly have to create list/collections/groupings of structs. Because tho…
Just like every language is able to be slow/non-performant -- but OO in this case would be Python in a web context; it doesn't invalidate that a good amount of OO codebases in the wild devolve into incomprehensible black boxes, where no one has any idea what anything does or how to make meaningful changes that fulfill the intent of (compare that to iterative programming, where you can atleast read it) A list: I give…
This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.) I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in. If I had to pick a language that pre…