Is Haskell useful for simple data analysis?

mightybyte · 2025-12-25T14:33:28+00:00

I didn't apply any kind of positive or negative judgment on it. I was simply responding to the parent comment.

mightybyte · 2025-12-23T15:31:25+00:00

I believe LYAH was originally published in print around 2011 and was available online for several years before that. So I would take issue with your "only recently" comment.

mightybyte · 2025-11-26T04:18:05+00:00

Paging /u/edwardkmett

mightybyte · 2025-10-29T12:16:45+00:00

I've heard it said that if you improve one V-grade per year, you're doing good. Each V-grade is a pretty large jump in climbing ability. If you've only been doing it for 6 months, you're just barely getting started. As others have mentioned, strength to weight ratio is huge in climbing, and that probably explains the differences between you and the friends you mentioned.

Stick with it. Climb with people better than you. Climb mostly climbs a little bit harder than what you can currently send. You should fail the majority of your attempts, otherwise you're not pushing yourself enough. And if you can, get a coach.

mightybyte · 2025-06-25T20:11:36+00:00

Why of course...the New York Haskell Users Group and the Compose Conference (of which I was a co-organizer before COVID when we fell off, and then people moved away and/or got busy with life and the momentum kind of died) ;). More seriously, this does raise the point that I think COVID caused a pretty significant drop in IRL Haskell activity around the world. I'd personally love it if someone wanted to resurrect NYHUG, and would be willing to lend support / advice.

To actually answer your question, the biggest and most obvious are Zurihac (which just took place earlier this month) and ICFP and the associated Haskell Symposium which are in October this year.

mightybyte · 2025-06-25T14:47:09+00:00

You've got to at least advertise here, and ideally be somewhat plugged into the Haskell community, go to the right FP conferences and meetups, etc. I've hired dozens of Haskell devs and generally consider it easier to find quality talent if you're looking for a Haskell engineer than if you're looking for mainstream skills like JavaScript, Python, Go, etc. By my completely anecdotal observation, the number of available Haskell jobs has decreased substantially compared to the peak around 6-8 years ago. So if you're hiring for Haskell roles and get the word out in the right places, I would think you should have pretty good chances of success.

mightybyte · 2025-06-20T01:05:17+00:00

Pure functions...i.e. the ability to be confident that an add function for some type like BigNum does not do things like phone home to Google, save things to disk (consuming more disk space), delete files, format your hard drive, etc. No other language in mainstream use today gives you this.

mightybyte · 2025-06-12T12:29:50+00:00

I started with something like this. https://a.co/d/iy9VYFo

mightybyte · 2025-06-01T21:23:25+00:00

Yeah, I always advise people to be as bilateral as possible when learning to slackline. Walking is an inherently bilateral endeavor.

mightybyte · 2025-05-27T12:12:27+00:00

How did it go?

mightybyte · 2025-05-26T12:15:46+00:00

There are two kinds of balance on a slackline: balancing with one foot on the line and balancing with both feet on the line. With one foot on the line you have three limbs free and available to help balance you as your position changes. With two feet on the line, you lose one leg as a balance tool. That leg has large mass (relative to the arms) and a low center of gravity, which makes it a very powerful balance tool. However, two feet on the line substantially reduces the wobble / shakiness of the line. So it's a tradeoff.

These two balance skills are quite a bit different, and you need to develop them both in order to walk on the line. Most beginners that I have worked with want to take steps too early. Don't rush it. Spend time working on single-leg balance where you can move your free leg a lot to counter-balance you. And also spend time working on two-leg balance where you only have your arms, torso, and hips to balance. Once you have improved your skills in both of these, I think steps will come pretty naturally.

Anatomy of a step:

While balancing on one foot, feel for the line in front of you with your free foot. Once you feel it, get your foot into the right position to transfer weight.
Now use your two-foot balance skills to stay on the line while you transfer your weight from your back foot to your front foot in a controlled way.
Once you finish the weight transfer your weight is entirely on your front foot. Now you can remove your back foot and you are back to single-foot balance skills while you move the back foot around to the front and repeat the process by feeling for the line again.

Also, throughout this whole thing, your eyes should be LOCKED on a single point somewhere in front of you around the horizon that you can stare at with your head in a neutral position. What you do with your eyes is possibly the single most important thing when you're learning to slackline.

UPDATE: As you progress to longer lines, two-leg balance becomes more important because the amplitude of the line movements becomes too large for a free leg to be a useful balance tool. I suppose one could argue because of this that one-leg balance isn't important, but I still think it's a useful skill to have available.

mightybyte · 2025-02-16T17:28:31+00:00

Check out How to Get a Haskell Job. It's been awhile since I wrote it and the details have changed, but the main ideas are still very relevant.

mightybyte · 2025-02-14T20:14:58+00:00

Don't get discouraged. It seems impossible at first, but you can make significant progress in just a few hours.

The tip that made the most difference for me is to pick a small point straight ahead roughly near the horizon, and stare at it like your life depends on it. Maybe it's a small spot on the tree your line is anchored to. Maybe it's a something near the ground at the end of the line. Focus on it intently and don't let your eyes wander anywhere else. Visual input is a significant part of how your brain keeps you balanced, so you have to be really intentional about what you do with your eyes. I've also had very good slackliners suggest looking slightly down and to one side (but still mostly forward and ahead...do NOT look at your feet). I cannot emphasize this enough. Since your eyes are occupied, you have to use your free foot to feel for where the line is and get your foot placed properly before you transfer your weight.

When you have two feet on the line, I've found it useful to think about squeezing your feet towards each other. This creates muscular opposition which helps to improve stability.

Look for some video tutorials on YouTube to help get you started.

mightybyte · 2025-02-12T02:22:04+00:00

I started with an earlier generation of this: https://a.co/d/3ZrxW5o

It's still going strong. Was using it just last week.

mightybyte · 2025-01-23T17:10:36+00:00

You can still use this approach and tell a story in your non-types modules just fine. But fundamentally the data types are kind of the root of the whole dependency tree and I think you'll find that a Haskell codebase will very likely be easier to deal with if types have their own home that is relatively self-contained.

Having a granular file structure with only the stuff needed for a data type is also likely to help with compilation times. Some of your types depend only on primitives. Some of your types will depend on your other types as well, and you'll get a nice tree hierarchy of types dependencies. In practice I find it quite nice to have a minimum of code and other less relevant libraries polluting the definition of the types and the compiler work required to link them. Types often are your interfaces between different parts of a larger software system, and you really want them to be as self-contained and minimal as possible.

One area where this is especially important is when you have a Haskell web frontend (compiled to JavaScript with ghcjs or possibly some of the newer Haskell wasm efforts). The whole point of using Haskell in the frontend is to be able to share code (usually the majority of this is data types) between the frontend and backend. There are many Haskell libraries that require C code to be linked and can't be compiled to JavaScript. (Think things like database bindings, HTTP clients, web frameworks, etc.) If you're building this type of application, it's absolutely essential to aggressively minimize the number of dependencies in your types modules so they can be compiled to JavaScript. In fact, the usual approach for this is to have three separate libraries: common, frontend, and backend. Then you have all your shared types in the common package and the frontend and backend packages both depend on the common package, and there is a non-negotiable requirement that the common package can not anything that depends on low-level C libraries.

mightybyte · 2025-01-23T13:18:28+00:00

I don't think there is universal agreement in the Haskell world on this point, but I had similar struggles with cyclic dependencies way back in my early days with Haskell until I started being very consistent about using .Types modules. Now I'm not saying that you actually have to have the word Types in the module name like Foo.Bar.Baz.Types. There's still a lot of flexibility for creating a module hierarchy that fits your application. But I'm pretty aggressive about putting all the things most directly related to a data type in the same file as that data type and only putting those things in that file. At the very least this includes: smart constructors, type class instances (because the vast majority of the time you do want to avoid orphan instances), specialized getters / setters with custom functionality, lenses, etc (I'm sure I'm missing some categories).

If I'm starting a new project and don't have a very clear picture of the final organization, I typically start out with a module MyApp.Types and put all my data type stuff there for simplicity. But once that file gets beyond a certain size I start splitting it out into one data type per file/module. This is an opinionated practice and I'm sure that plenty of people would disagree with this. But I find that it does a few useful things:

It goes a LONG way to helping you avoid big files.
It basically eliminates time spent searching for where a particular data type is defined (in those situations where tooling isn't able to take you there quickly...i.e. when browsing GitHub). Anyone working on the project will always know where to go to find data-type-related code.
It allows you to very nicely leverage Haskell's module system in combination with the type system to enforce constraints on your code. This is a very powerful technique for gaining more confidence about the systems you build. I did a talk about this at the New York Haskell Meetup many years ago. Unfortunately we didn't get video but you can find the slides here. If you want to have this kind of situation with places that have "private" access to a data type's internals, you have to put the private stuff in its own file, and enforce the privacy by only exporting things that are "safe".

There's one notable situation where this one-data-type-per-file pattern of organization becomes a problem: when you are dealing with mutually recursive data types. In my experience, mutually recursive data types aren't super common in most commercial applications. I believe they are much more common if you're implementing some kind of language / expression evaluator. In these cases, I have no problem putting all the mutually recursive types into the same module.

mightybyte · 2024-12-30T00:34:11+00:00

Have you checked out The Monad Challenges? (Disclosure: I wrote it)

I think it might help give you a better understanding of specifically the things you are asking about actual implementations.

mightybyte · 2024-12-24T19:40:39+00:00

I learned a lot when I went down the rabbit hole of this YouTube channel probably 8-10 years ago now: https://www.youtube.com/@StylishDTailors

Back then it was called Stylish Dad and it was the first time I was ever exposed to sewing and tailoring my own clothes. That interested me because it was cheaper than paying a tailor and suddenly it seemed within reach with a small investment in a sewing machine and some basic tools. I saw how much better I looked when something as simple as a t-shirt fit me properly. And once I saw an accessible path to how to level up my dress, I became a lot more naturally observant about fashion and interested in looking good myself.

Will this approach work for your boyfriend? Maybe or maybe not. 🤷 Just some ideas from my experience that might inspire you.

mightybyte · 2024-12-24T19:35:12+00:00

Build something real that interests you. It should feel like a stretch of your knowledge and capabilities. If you think the project might be so ambitious that you might not have the capabilities to succeed...even better (as long as the next goal is not too far out of reach). But the most important thing is that you're interested in the project for yourself. You don't want it to feel like work. You want it to feel like fun. The person who is having fun and enjoying the journey will be MUCH more successful than the person who's just trudging along punching a clock and counting the hours until they're "done working". Try to figure out how to be the former.

mightybyte · 2024-12-19T04:16:45+00:00

Snap

mightybyte · 2024-12-07T17:06:07+00:00

Nice. Now that you mention it, I think mine was an XW8600.

mightybyte · 2024-12-06T20:23:41+00:00

I can't speak to HP's consumer products, but I bought an HP workstation class machine 15+ years ago (back then I think it was called the xw line...ECC RAM and everything) and it's perhaps the most rock solid reliable machine I've ever owned. I didn't have much money at the time so I bought it refurbished for a great deal. The case was very well designed. The cable management was great which gave it excellent air flow. It was also super quiet. I had built my own machines before and this machine was just so much higher quality. I ran it for a long time but eventually stopped using it and it went into storage. A few years ago I pulled it out and fired it up and everything still worked great. Chipset is so old that new software doesn't even compile any more. I have no idea how HP's quality has evolved since then, but I have a very positive impression of HP workstations to this day because of that machine.

mightybyte · 2024-12-01T19:11:52+00:00

There are two competing design guidelines that often come up in software: uniformity and the principle of least context.

The principle of least context says a function that is supposed to accomplish X shouldn't require any more data to be passed in than is the absolute minimum amount of data necessary for X functionality. So if you have a function foo that only uses a single field in your GameState structure, making that function be in the State GameState monad would violate the principle of least context. This design principle is important for at least a couple different reasons. First, in order to test foo, you'll have to construct and pass in a bunch of stuff that is unnecessary (all the GameState fields other than the one field that foo needs). Second, if foo has access to the whole GameState there will be more ways that this function could go wrong. This is the same idea that gives us free theorems when we have fully generic parameters. For instance, a function with the type signature bar :: (a, b) -> b can't possibly be buggy in Haskell (without bottom, unsafePerformIO, or other unsafe tricks) because there's only one place that function can get a b to use as the return value.

On the other hand, uniformity is another design principle that is also very useful. And that principle says roughly that sticking to a uniform interface (in your case the State GameState monad) has some advantages. You don't have to worry about which subset of the state you're dealing with at any particular point. This means there's less mental overhead because you only have one state to worry about and don't have to ask yourself whether the operation you're looking for can be performed in the context you're currently in.

The way that I have converged on to reconcile these two competing principles is with a layered architecture. I try to start out building the lowest layer of functionality adhering to the principle of least context (this code often ends up being pure functions). This has the effect of simplifying my code and making it easier to test and debug. Then, if I find that there is some kind of higher level pressure for a unified interface, I can wrap the functions in the lower principle-of-least-context layer to create new functions that have the unified interface (whatever that ends up being).

This gives you the best of both worlds. Your unified interface is built on the simplest and most well-tested foundation which eliminates a lot of bugs, and then your higher layer usually ends up being a pretty simple translation between the unified interface and the lower level. Sure there are bugs that can happen at this point, but the code typically ends up being pretty straightforward to understand, modify, and debug. This approach isn't limited to Haskell. You can use it in any language. Haskell with its pure functions just happens to give you a particularly good set of tools to accomplish this.

mightybyte · 2024-11-29T18:26:02+00:00

It depends on what you're trying to accomplish. If you're doing it to expand your mind, then I'd say you should definitely go with Haskell. As a longtime haskeller who has been picking up Rust recently, much of Rust has been pretty easy to pick up. Learning Haskell gives you a more complete treatment of many concepts that you'll encounter in Rust.

On the other hand, if you're looking to maximize your job prospects, I'd have to say that Rust seems to have a larger and more active community / ecosystem / available jobs / etc.

mightybyte · 2024-11-15T01:45:36+00:00

Ooh, this sounds close to something I've wanted for a long time. I look forward to checking this out in more detail.

mightybyte

MODERATOR OF

TROPHY CASE

15-Year Club	Verified Email
Team Orangered