Recent comments in /f/programming

Moonside OP wrote

Reply to comment by musou in My Modest Rant on how Everything About Learning Coding Stuff is Garbage by Moonside

I can't avoid making up a conspiracy theory that QuickCheck library presently exists as an advert for QuviQ AB and this perhaps goes even further for the Erlang version. Good enough to become somewhat well-known and whet your appetite and then when you get serious, you need to bring consults in.

I was only testing simple mathematical properties (semigroup/monoid/group/Abelian group laws and involutivity) where generator specificity doesn't matter that much. The properties are so general that if a fault was discovered, it would taint a function for all inputs, even accidentally correct.

The one upshot of the whole shebang was that I got to reimplement some stuff as groups and I could just feel the power rushing through my veins ad hoc 'negation' functions into invert ones. Actually now I looked more into the docs and noticed that Haskell also has Abelian groups as a type class and I added them too to my types.

(It would be really nice if there was something that could automatize writing tests for common typeclasses. I have two types that have instances of semigroups, monoids, groups and Abelian groups and doing tests like I did means that testing their properties and a direct consequence of one took 14 tests which is kind of gross when you could write generic code.)

for what little its worth ive had an easier time using stack with haskell instead of cabal, but only because the book i was learning from used it. but googling for solutions to haskell problems has gotten more difficult now that there's two competing toolchains

I tried out Stack because there's some Emacs tooling around that, but the tooling was quite brittle which soured me a bit on that. There seems to be some amount of Stack related drama in the Haskell community and some people I've learned from have a strong distaste for Stack in favor of Cabal. I'm not in a place to know enough to switch and the problem wasn't really Cabal related. Rather it was, in the small, that the solution involved Template Haskell and sequencing IO actions both of which I haven't done before and, in the large, that no-one has bothered to write documentation or a tutorial on the bird's eye view of things. Or what a best practices could be, I'm not Haskell literate to just see what popular packages are doing.

2

musou wrote

Reply to My Modest Rant on how Everything About Learning Coding Stuff is Garbage by Moonside

yeesh that sounds like no fun at all. i tried using the erlang version of that quickcheck library for property based testing in elixir and also found it hard to use effectively. the docs weren't great and i couldn't always figure out how to make the generators specific enough. i just stick with type annotations and unit tests and that's usually good enough for the kind of thing i do.

for what little its worth ive had an easier time using stack with haskell instead of cabal, but only because the book i was learning from used it. but googling for solutions to haskell problems has gotten more difficult now that there's two competing toolchains

1

hollyhoppet OP wrote (edited )

Reply to comment by emma in the real reason i haven't merged the latest postmill master branch into jstpst yet by hollyhoppet

Yeah, having the heroku stuff in postmill main would be nice but I'm not comfortable with that until a way to handle the ephemeral file system is in as well. There's a reason we don't have thumbnails here lol. That's kind of lower in priority though for me compared to trying to get an archive together for the old thefempire.org posts.

Also maybe there's a way to do scripts in heroku aside from composer.json but I haven't figured it out. I write Java services and did ios before that so user facing web stuff is not a strength of mine.

4

Moonside wrote

Reply to comment by musou in the real reason i haven't merged the latest postmill master branch into jstpst yet by hollyhoppet

I think that interfaces can be many and that's perhaps not the issue, even if the command line interface is clunky and more tuned to the particularities of Linus brain folds than anything else. Magit in Emacs is pretty great and I like it and there's no shortage of other GUIs for Git. But I feel like the basic model could be more, say, principled or elegant. I find it somewhat ludicrous that this book is 456 pages long.

This isn't just Git either, I really feel that a lot of utility software for coding has tons of usability issues and quite often it's not like the innards are any better.

4

emma wrote

Reply to comment by hollyhoppet in the real reason i haven't merged the latest postmill master branch into jstpst yet by hollyhoppet

The heroku stuff I'm sure can be added upstream in some fashion. I'm a bit surprised composer.json was used for running commands instead of making an entirely new script.

Will remove the favicon/apple-touch-icon later so there'll be no conflicts there. Blame Symfony 4 for the directory renaming, it broke in all kinds of subtle ways when I tried using the old directory structure, lol.

3

musou wrote

Reply to "In this short post I’m going to attempt to convince you that current network (Internet) latencies are here to stay, because they are already within a fairly small factor of what is possible under known physics" by mm_

like many people, the first program i ever made for fun was on a texas instruments calculator. trying to fit the whole thing in the available space, and getting it to run at tolerable speeds, was just as big of a puzzle as getting the program to work like i wanted.

i think for the majority of the history of computing, we've had to pay way more attention to efficiency, and overcoming the limitations of hardware, than most everyday programmers have to deal with today. and as we start bumping up against physical limitations like this, the skills and techniques required to optimize programs for space and execution speed will start to become more important to the majority of programmers again.

3