ms013

I do almost all of my development work in WSL since moving off of macOS earlier this year. Works fine for my workflow: ocaml compiler/toolchain, anaconda python, gcc, X11 server on the Windows side for GUI apps, (g)vim, etc. I don’t do any .NET work - just regular Unix development. I bounce to the Windows side to run things that require direct hardware access (eg, CUDA), or running things like Mathematica or OneNote with the stylus.

I miss some things from the Mac: it was the hardware that drove to try new things. I’m growing to like the new environment. I’ve run Linux on my laptops on and off forever (mid-90s onward), and generally get irritated with them for one reason or another and look back at the Mac or Windows alternatives.

That comment about academia is not universally true at all. Grad students frequently get first author status on papers they do the bulk of the work on. The typical abuse that is more commonplace is the inclusion of advisors as last authors on papers that they didn’t contribute to at all (other than writing the proposal that won the funding that supported it). That’s why journals began adopting a requirement that the contribution of each author be made clear in the paper (usually a section near the end).

Where does it fall relative to Scala?

Ocaml is a perfectly good modern day language. Our entire codebase at work is built on it and we’re pretty satisfied.

Exactly. I've always bounced between OSes over my career. Switching between them is not that hard at all - just need to mentally page in the key modifiers, shell commands, and other little idioms and pretty quickly I'm running along working.

In my experience I've found inflexibility with respect to OS to be a warning sign that usually means someone isn't going to work well long term as a flexible, open-minded team member. Signs of that at interview time usually push me pretty quickly in a 'no' direction.

Re: macs. Yes. MacOS releases up to 1999 lacked features common in other systems, like full preemptive multitasking and memory protection. Windows NT had that in the mid 90s, and various Unix flavors had it for decades. I liked the UI on the macs vs windows95/98/NT or Linux/Solaris, but the stability of macs was a joke. Everyone was pretty happy when they cleaned up NeXTSTEP and turned it into the basis for OSX - that was a very smart move.

It can be sluggish at times (SB2 13”, maxed out specs), usually on boot when a bunch of background tasks are starting up. I haven’t run Linux on its own on this specific machine, so I don’t have a good comparison. It is tangibly slower than my 15” MBP 2017 when running some compute intensive tasks for work, but that is likely due to differences at the hardware level and not OS. I also have encountered some slowness at the filesystem level, which occasionally annoys me when I’m doing tasks that hit the FS very frequently.

It isn’t perfect, but it’s good enough that I don’t notice the warts too frequently. I’m not very fickle though: at this point in my career, I’ve come to the conclusion that all systems suck in their own special ways.

It would be publicly visible on github, such that the community can see the dispute and the response (or lack thereof) from the other project. While it won’t necessarily fix the problem, it is more visible.

I just dug around in the rush GitHub, and was surprised to find no pull requests by the author of Lerna trying to rectify the missing copyright ("Hey guys, you forgot to keep my copyright in there since this is a fork of Lerna, so here's a pull request"), or any issues raised ("The copyright of my MIT-licensed project is missing. What's up with that?").

The only instances of lerna being mentioned are people who use or work on rush mentioning differences between the two projects.

Assuming the lerna author is accurate, why just the angry blog post? If I had contacted MS and raised the issue via email, and nothing happened, I would have started raising issues on the project GitHub and making pull requests to rectify the situation. Not only could that actually work to resolve the issue, but the discussion would be public.

I lived through the 90s too. It's been 20+ years since the peak of the Microsoft that gave them the reputation you're reflecting.

If "I lived through the 90s" was how I measured technology and companies, I'd sure as hell not be using Apple products - their technology was pretty terrible then, and the company was incoherent. Would any rational person say that the terrible tech and incoherence then translates to how one would accept what they produce in 2018? Some companies change, some don't (see: oracle). It seems a healthier approach is to measure the behavior and state of a company in the present.

I use it daily for all of my development work (Ocaml, Python, LaTeX, vim, emacs, and a host of other tools, including X11 apps). It is the single biggest reason I was able to ditch my 2017 MacBook Pro a year ago for a Surface Book 2 after ~20 years of mac laptops and Lenovos running linux. I couldn't work with the terrible clacky keyboard they introduced - it didn't malfunction for me, I just loathed how it felt and sounded. Occasional friction when bouncing between apps on the Linux side and the Windows side sharing files, but as long as I work in /mnt/c/Users/USERNAME/ from the Linux side it isn't too bad.

I don't buy the "I've used OSX for so long I can't possibly adapt my workflow to Windows" argument. It took me a few days to get used to the new idioms, but it wasn't that bad. Then again, I've been pretty OS agnostic for my career - Irix, SunOS/Solaris, Linux, OSX, and now Windows+WSL. Other than the part of my career when I was doing systems research and had to care about OS-specific details (e.g., writing Linux kernel modules), I haven't really found it hard to adapt to new environments and be happily productive.

I don’t have a good answer to the framework question, but I do have an opinion about cross-platform. Why make cross-platform a priority over efficiency and user experience? I bounce between Mac and Windows daily, and my least favorite apps are those that try to run on both. They are often resource hogs and provide a UI experience that feels worse than native apps. Electron apps have the least bad UI experience, but are resource hogs. One app I use for work, Mendeley, uses Qt for its UI I believe, and it’s garbage on both platforms- so I use the web interface instead. Give me a good native app instead of a suboptimal cross platform one.

I often think the issue isn’t cross platform though: it’s that there is a cohort of developers who know a toolchain (JS+web), and use frameworks that let them live in that instead of investing the time and effort to learn how to write an app well using a toolchain not built for those focused on web/browser models of programming.

I came to a similar realization a few years ago. I followed a number of people who were/are widely followed in parts of the FP community that are generally caustic, but I assumed their popularity implied that they had something useful to say. I eventually unfollowed/muted/blocked many of them because I reached a point where I realized I'm not dumb, I actually do know the domain pretty well, and I'm well regarded in that community, yet I think these people are just spewing hot air (either aggressively negative, confrontational, or self-promoting). To be honest, I don't think I've missed anything of any consequence since my block/mute/unfollow-fest. It does disappoint me when I look and see that some of these toxic personalities are still widely followed and still spewing the same garbage, even though I can't see any tangible contribution that they've made.

There are many who are good at making noise and opining, and even talking about wonderful "tech" that they are working on, but most of the "brilliant jerks" ultimately produce nothing of value and contribute nothing to the ecosystem.

Responded to someone else earlier about this. Used solvers for problems that end up requiring solutions to problems like minimum set cover or schedule optimization problems. Basically, problems where a naïve or brute force approach will take forever to run and you need to use a real solver to attack it. These usually are data problems that end up looking like what would traditionally be considered under the umbrella of operations research.

Graphs show up all over the place. Social media: who is connected, which people interact. Cybersecurity: which computers/programs/users interact with which other computers/programs/users. Retail analytics: which products are bought with which other products; which products are more important in a graph than others.

Basically, any problem where you can establish relations between elements can be treated as a graph. I've used graphs for image analysis before too: pixels are vertices, edges represent neighborhood relations - especially useful when you make nonlocal connections (e.g., nonlocal means; graph-cut methods for segmentation; etc...)

I've worked with them in three of the above contexts: cybersecurity (my current projects), retail analytics, and image analysis. I've avoided social network stuff - never cared for that area much.

I know R and have used it in the past. I just don’t like the language. I keep RStudio around though because on rare occasions I do look around in it to see if it has something I need. So rarely though that I forgot to list it...

One data problem boiled down to being an instance of the set cover problem (https://en.m.wikipedia.org/wiki/Set_cover_problem). Pretty easy to pose as an integer constraint problem, and Z3 solved it in about 20 minutes for me.

Mathematics. Which branch of math is domain dependent. Stats come up everywhere. Graphs do too. In addition to baseline math, you really need to understand the problem domain and goals of the analysis.

Languages and libraries are just tools: knowing APIs doesn’t tell you at all how to solve a problem. They just give you things to throw at a problem. You need to know a few tools, but to be honest, they’re easy and you can go surprisingly far with few and relatively simple ones. Knowing how, when, and where to apply them is the hard part: and that often boils down to understanding the mathematics and domain you are working in.

And don’t over use viz. Pictures do effectively communicate, but often people visualize without understanding. The result is pretty pictures that eventually people realize communicate little effective domain insight. You’d be surprised that sometimes simple and ugly pictures communicate more insight than beautiful ones do.

My arsenal of tools: python, scipy/matplotlib, Mathematica, Matlab, various specialized solvers (eg, CPLEX, Z3). Mathematical arsenal: stats, probability, calculus, Fourier analysis, graph theory, PDEs, combinatorics.

(Context: Been doing data work for decades, before it got its recent “data science” name.)

I use Regus currently. I think it’s fine: coming from an open office plan at my last company, the fact I can visually and audibly tune out people via a door and walls is awesome. I hated being forced to live in headphones land. My only complaint about the regus space is the length of the lease: I’ve considered wework to move to once my year is up in a couple months so I can go to a month to month plan. Unsure if I want to go back to a noisier/visually cluttered environment though...

I have to agree - same gripes for me. This MacBook is my 8th Apple laptop going back to sometime in the late 90s (my first was a pre-PowerPC PowerBook), and it's the first one where I really and truly have regretted the purchase. I've usually had a second laptop during that time (ThinkPad usually, Surface lately), and I've rarely had more nice things to say about the non-Apple machine until now.

Also, the main selling point of Macs for me since 2001 when I made the big switch to an Apple-dominant hardware ecosystem was having a Unix-based system that had a reasonable desktop environment. Lately, the Windows Subsystem for Linux has been making me question if MacOS and the corresponding hardware is worth the headache.

Why is an "SV-based disrupter" at all necessary? That's an absurd and bizarre question. Just pay them - you say you read it often, yet you don't pay. Say you read 6 articles there per year - that works out to a whole $4/article, or equivalent to one fancy coffee every two months. To defer instead to some "SV-based disrupter" to act as the person who will pay for it on your behalf seems exceptionally lazy on your part. Just pay for the things you benefit from. Constantly using services while hoping someone else will pay for them is why we can't have nice things that last.

(And yes, I pay for it - I like the print version that shows up every so often, in addition to the articles I read online).

Pantex still exists. The facilities discussed in the article replace Rocky Flats, which was shut down in the 90s.

Nobody is arguing that not to be true. The issue is arguing that NVIDIA foresaw their systems being relevant to AI/DL/ML: they simply were lucky. They opened their architecture to HPC people, concerned largely with fluid dynamics, finite element methods, nbody methods, and so on. To claim that they had any insight into the emergence of ML as a core application of their silicon is simply a laughable revision of history: as we were talking about in an ancestor of this thread.

Exactly! Plus, even before CUDA existed, people in numerical computing had already noticed that GPUs were ideal hardware for certain classes of problems and were doing awkward things like embedding numerical calculations as shaders and other tricks to use the graphics APIs as a way to encode computations. I recall colleagues who worked on those pre-CUDA systems meeting some resistance from NVIDIA in terms of opening up the low-level APIs that would make the hardware more directly accessible, versus the encodings that they needed to go through to use graphics primitives for the work.

NVIDIA got lucky by having the right kind of hardware, and created CUDA not due to some insight into the AI world, but based on the needs of scientific computing. Just look at their early papers on CUDA (E.g., Luebke's 2008 paper "CUDA: SCALABLE PARALLEL PROGRAMMING FOR HIGH-PERFORMANCE SCIENTIFIC COMPUTING") - AI was nowhere to be seen. They were focused on traditional high performance computing problems.

It's been a pretty slow, sad unraveling of LANL (and to some degree the other two DP labs). The latest stories are pretty predictable given the transition from UC to LANS about a decade ago (I left the lab after the transition, since it was a morale mess - I really enjoyed my time there for about a decade before the change though). Things were already bad before that - the whole change of management from UC was in part due to a string of safety and security issues. Interestingly, I believe the issues that are currently being reported about have roots that trace all the way back to the last facility for doing that sort of work that got shut down up near Denver (Rocky Flats). The issues today are hardly new or novel - there has been some serious rotting going on within the NW complex since the Cold War began to wind down almost 30 years ago.

I'm not sure why this would be impressive. That's how science has always worked, and scientists very often get excited when new data increases the likelihood that some previously held idea is false. In fact, more often than not what irritates scientists is when experiments increase support for existing theories since that usually means that other theories are less likely to hold (e.g., LHC and supersymmetry theories). That results in people who had invested long periods of time into work that the data now says is bogus having mild existential crises - "damnit nature - now what?".

It says something unfortunate about the current perception of science if people think scientists getting excited about new data contradicting theories is something noteworthy.

The same reasons people migrated to Python in the late 90s from matlab, Fortran and C++: Python addressed pain points in those languages and ecosystems. Julia addresses deficiencies in Python the language. Unfortunately, it lacks the ecosystem: until it gets the rich library set that Python has, we're stuck with Python since ecosystem is arguably more important for practical traction than the base language.

I cofounded a company recently that is using code transformation and optimization methods to accelerate data analytics code on special purpose hardware. Our compilation toolchain is all ocaml, and the language that is compiled/transformed/optimized is Python. Prior to this venture, I did similar work - code analysis and transformation, but in that case largely around high performance computing for scientific applications. That tooling was mostly ocaml/Haskell, but not production focused - it was mostly research code.

I assume you were just not interested in passing the state around to the functions that needed it, and preferred the fact that the state monad hides that plumbing for you via bind and return. It's worth noting that there exist Ocaml libraries that provide the same operators and even similar do notation syntax that desugars to bind/return operators (via PPX).

Ocaml does tend to be more verbose than Haskell - it's just the nature of the language syntax. E.g., in Ocaml, one says (fun x -> x+1) vs (\x -> x+1). Similarly, ocaml is cursed by the excessive "in"'s that accompany let bindings. "Let .. in let .. in let ...". That can get annoying.

Interestingly, I had the opposite experience with a commercial compiler project. Haskell's syntactic cleverness (monadic syntax, combinator libraries, etc..) eventually got in the way - it became very difficult to understand what a single line of code actually meant since one had to mentally unpack layers of type abstractions. Migrating to ocaml, the verbosity eventually was more tolerable than the opacity of the equivalent Haskell code once the compiler got sufficiently complex.

My experience may vary from yours. I've been doing Haskell/Ocaml in production for many years, so the pain points I've adapted to are likely different than one working on toy compilers or weekend projects. And no, category theory exposure is not and never has been necessary for understanding Haskell or FP unless one is a PL researcher (and even then, only a subset of PL researchers are concerned with those areas). And one can be quite productive and prolific in Haskell without a deep understanding of monads and monad transformers - the blogosphere has given you the wrong impression if you believe otherwise.

In production code we tend to use ocamlyacc or menhir. There is nothing about ocaml/ML that prohibits the use of the kind of parser generators one would expect in any other language.