GLFW 3.3 Is Released - <AUTHOR> https://www.glfw.org/Version-3.3-released.html <comment><USER2> For those who wonder what GLFW is... if you want to play with OpenGL or Vulkan, make a graphics demo, or make a game, GLFW is a library that frees you from having to deal with the nuances of Win32/X11/etc, wrangles keyboard inputs and other things across platforms.

It is similar to LibSDL, but is more lightweight and GPU-centric. GLFW is designed more with greenfield projects in mind, whereas LibSDL was designed from the beginning to help with porting existing code. (They are both excellent libraries.)

<comment><USER3> So, it's sort of like GLUT was? (is?) I only messed around with 3D rendering a little back in the very early 2000's, but from what I remember, GLUT made everything much easier.

<comment><USER4> Yes, it's kind of like GLUT, although it covers fewer functionalities. It focuses only on abstracting the OS specific parts like keyboard/mouse input and window/graphics context creation. GLUT also offered things like rendering fonts, teapots and additional functionalities.

</comment></comment></comment><comment><USER5> Very excited for this release! GLFW is part of the foundation for a UI framework we're building called Revery [1] and there are several features in 3.3 that will be useful for us - transparent framebuffers, headless backend via OSMesa (important for CI / automation), and high-DPI improvements.

GLFW takes a lot of the pain out of cross-platform GPU development, and I've found the API simple and intuitive to work with. For those looking to play with it - the LearnOpenGL tutorial series [2] is excellent, and uses GLFW for managing a window and getting an OpenGL context.

Thank you maintainers for your work on it!

\- [1] Revery: [https://github.com/revery- ui/revery](https://github.com/revery-ui/revery)

\- [2] LearnOpenGL: [https://learnopengl.com/Getting-started/Creating-a- window](https://learnopengl.com/Getting-started/Creating-a-window)

<comment><USER6> Sadly Mesa's software renderers seem to have topped out at OpenGL 3.3[1] :(

[1]: [https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30](https://mesamatrix.net/#Version_OpenGL3.3-GLSL3.30)

<comment><USER5> Ah, that's too bad! I've been hunting for ways to get better integration tests on CI for Revery.

Would like to have image-based verification for certain classes of tests, and we use Azure CI pipelines - seems their VMs don't have hardware support at all for OpenGL (on any platform).

<comment><USER6> Eh, 3.3 Core is still pretty darn capable. 4.0+ mostly just added tessellation/compute shaders & quality-of-life and/or AZDO[1]-style features.

[1]: [https://en.wikipedia.org/wiki/Glossary_of_computer_graphics#...](https://en.wikipedia.org/wiki/Glossary_of_computer_graphics#azdo)

</comment></comment></comment></comment><comment><USER7> Nice to see this is still in development. I wrote GLWF bindings for two languages and it was pretty easy to grok. It's also absolutely essential if you want to have an UI in a language without support for GUIs (like golang). Just use the OpenGL backend for the immediate mode UI lib of your choice (dear-imgui, nuklear, ...) and GLFW for the window setup and you're golden.

</comment><comment><USER8> Excellent! I've been using GLFW_TRANSPARENT_FRAMEBUFFER for over a year, but kept having to do builds out of Git to get support. It will be nice when this new library trickles into Linux distros over the next year.

</comment><comment><USER9> "GLFW is an Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan development on the desktop. It provides a simple API for creating windows, contexts and surfaces, receiving input and events."

</comment><comment><USER10> As a nice complement to GLFW, there's also bgfx which can be configured to use GLFW:

[https://github.com/bkaradzic/bgfx](https://github.com/bkaradzic/bgfx)

</comment><comment><USER11> Can somebody explain what are the advantages of glfw over freeglut? (other than the non-issue of "being" old)

I am using freeglut for casual opengl code, and I see no problem with it. Is there anything that I am missing?

<comment><USER12> Back when I was doing a lot with this stuff, GLUT was effectively dead. Stuff like MacOS HiDPI surfaces wasn't doable without going well outside of what GLUT wanted to help you with. GLFW has been under active development over that time period, unifying baseline OpenGL, OpenGL ES, and Vulkan stuff to build upon.

<comment><USER11> Indeed, GLUT is not in active development (I would not say that it is "effectively dead" but rather that it "crystallized into a perfect form", but I digress). However, I was asking about "freeglut", which is a different thing, which is actively developed: last commit on 2019-03-26 dropped some unnecessary dependencies, for example.

<comment><USER13> I remember GLUT having some pretty significant deficiencies last time I looked at it. I guess FreeGLUT has added support for stuff like Unicode, high-DPI displays, etc... in the intervening years?

<comment><USER11> I just use freeglut to open a window and throw opengl into it, in a more or less portable way. The "gui" and "font" parts of freeglut are not really very useful (and they are missing in glfw anyway). Thus, unicode and high-dpi issues should be of no concern: as long as you can draw to your window and receive user input, what else do you need? What do you mean exactly by high- dpi "support"?

<comment><USER12> You have to explicitly opt into a Retina display context on MacOS in order to get a window into which you can render at high DPI (2x the physical dimensions). You cannot mimic this with transform matrices; the render target will be rasterized at low-DPI and interpolated.

So, yes, high-DPI issues very much exist, and GLFW does the right thing.

</comment></comment></comment></comment></comment></comment><comment><USER14> Dynamic loading of backends, i.e. supporting X11 and Wayland with the same build (PR #1338) didn't make it :(

</comment><comment><USER15> Finally, I was waiting for this release, they fixed an annoying click event bug on Linux.

Hard to know why this bug had to wait so long for a fix. Where are the delays coming from?</comment>


Autopilot was active when a Tesla crashed into a truck, killing driver - <AUTHOR> https://arstechnica.com/cars/2019/05/feds-autopilot-was-active-during-deadly-march-tesla-crash/ <comment><USER2> >"...our data shows that, when used properly by an attentive driver who is prepared to take control at all times, drivers supported by Autopilot are safer than those operating without assistance."

This is the key phrase. Tesla is all in on marketing "Autopilot" as a fully autonomous driving agent when it's not. It's an advanced lane-keep assist system combined with dynamic adaptive cruise control. No more advanced than GM Super Cruise or Honda Sensing. The lies from their marketing department and Musk himself are causing these deaths, not the technology. If they were responsible in representing what the system really is, people would actually be more attentive to the fact that they are still driving a car, and not blindly trust their lives to a level 2 system. Honda and GM do this, and have yet to see any fatalities.

<comment> frosted-flakes >> "...who is prepared to take control at all times..."

I honestly don't see the point of "autopilot" if I have to be prepared to take control at all times. It's not like it's any less work than actually driving manually (the hard part is maintaining focus, not twiddling a steering wheel back and forth). In reality, I don't think people who use it are _actually_ prepared to take control at all times. Hence the accidents.

> It's an advanced lane-keep assist system combined with dynamic adaptive > cruise control.

Can these features be activated independently in Tesla vehicles?

I like the idea of adaptive cruise control (ACC), but I don't think I'd like it if my car steered for me. That seems reasonable, and many cars do have ACC without lane-assist, but what about the other way around? What if I want to control the gas pedal, but have the car keep itself in the lane? Like if I'm eating a sandwich and need to take my other hand off the wheel for a few seconds, but I'm not prepared to put it into full auto mode.

<comment><USER3> It is WAY less work than actually driving. You maintain your alertness, but it takes away much of the physical load of driving. It might even preserve your alertness.

It's the BEST THING EVER in bumper-to-bumper traffic.

Also you can steer yourself and let it maintain the distance to the car in front of you by turning on only Traffic Aware Cruise Control.

That said, you should be alert while you use it. If you're a text-while-you- drive person, the only positive thing I can say is it protects other people from you.

</comment></comment></comment><comment><USER4> These crossing-the-T accidents are difficult to avoid manually but radar might have helped. The article's claim that "Radar systems lack the angular resolution to distinguish a truck crossing the road from a large street sign suspended over the road, so they tend to simply ignore stationary objects" is spurious because signs don't typically move across one's straight-ahead line of travel. Edited to add that a doppler-only radar would fail, perhaps they meant that, or one with awful vertical resolution, but a radar exploiting a static return as in the Bosch adaptive cruise in my ancient chariot has enough horizontal angular discrimination to usually succeed at distinguishing the car in my lane of travel from vehicles in adjacent lanes subtending less than 10-15 degrees off of my heading.

It's not clear what time of day we're talking about but if it was in the afternoon on a clear day the truck, south of the Telsa, traveling from w->e, possibly was in or near sun glare and given poor roadside maintenance, obscured by all of the foliage along both roadways.

</comment><comment><USER5> The overarching tone of the article is "Tesla isn't doing a very good job with its autopilot and could have prevented this". I wonder if there's any data about how many Tesla's get in crashes versus other cars. I'd suspect that given that only 2 people have died in over 1 billion miles driven in autopilot that Tesla's are safer than other cars.

<comment><USER6> I feel like that's absolutely irrelevant. If you trusts a device with your life, it shouldn't kill you under any circumstances other than actual malfunction.

I like to bring up an example of a radiotherapy machines here - a machine that treats you with radiation cannot have a state in which it kills the patient, even if the chance of that happening is 1 out of a million. In that scenario it doesn't matter that a manually operated machine would kill more people on average - an automatic one should kill absolute zero.

Or maybe for another example - plane autopilot has saved countless lives. But any time one fails, every single plane of that type is removed from service until the issue is found and fixed.

I feel like at the moment the approach these companies take is "well yes the autopilot can make mistakes, but it's still safer than manual driving so it's fine, yeah?". No tesla, it's absolutely not fine on any possible layer. Tesla should be disabling autopilot on every single Model S and Model 3 sold until the issue is found and fixed.

<comment><USER7> That's a staunch overreaction. You're correct in saying that you can equate Tesla's auto-steer and adaptive cruise control to the autopilot in an airplane, however what you fail to account for is that in an airplane operating on autopilot, the pilots are still required by law to be attentive and paying full attention to the system. This is very similar to how Tesla portrays current-generation of autopilot. Sure, their marketing team does state that all cars are _capable_ of self-driving (i.e. they have the required hardware bar HW3 processor), but they never state that current generation cars _are_ self-driving _currently_. It's on consumers to understand this difference and pay full attention while driving. My mom was a flight attendant on a major U.S. airline until a few years ago, and it wasn't uncommon at all to hear of a an autopilot system malfunctioning ever-so-slightly in that it steers slightly off-course due to a miscalibrated sensor but, since the pilots are actively paying attention, this error never puts the lives of those onboard the plane in-danger. I would say that Tesla's software should be held to the same standard, in that the operator is required and absolutely needs to pay full attention to the system, but there is no need for Tesla to "disabl[e] autopilot on every single Model S and Model 3 sold until the issue is found and fixed"

<comment><USER6> If anything, it's underreaction - not only Tesla should disable the autopilot on all their models temporarily, there should be heavy fines for both allowing it on the roads in this state and for calling it autopilot in the first place.

>>It's on consumers to understand this difference and pay full attention while driving.

Then this is a crazy assumption to be making. Like literally crazy. Pilots are trained over and over again to pay attention - and they still fall asleep during flights. With cars, even engineers who are employed and paid(!!!) to pay attention have fallen asleep while testing level 3 autonomy[0]. Expecting a regular customer to both understand the difference and pay attention is wishful thinking. The lowest bar for this technology that we should be aiming for is "the vehicle should never under any circumstances fail to observe and react to a stationary object in front of itself". Simple as that. If Tesla's autopilot cannot meet this bar it shouldn't be on the road, no matter how many times safer on average it is than a regular driver.

[0] [https://www.thedrive.com/tech/7730/ford-engineers-are- fallin...](https://www.thedrive.com/tech/7730/ford-engineers-are-falling- asleep-while-monitoring-self-driving-cars)

</comment></comment></comment></comment><comment><USER8> It feels like we are getting further away from autonomous vehicles, rather than closer.

<comment><USER9> Autonomous vehicles had an investment / media hype and it's now on its last legs.

We still might have them some day -- but the vision sold throughout the 2010s of us having them anytime soon is bogus, like other such fads before it (fuel cells, VR, AR, and tons of other things besides).

</comment></comment><comment><USER10> >it's still worth asking whether lidar could have prevented the crash that killed Jeremy Banner.

Lidar doesn't automatically make a car safer without the software written to accompany its use. Its a very trite summation on a very complicated and cost conscious subject. The same sentence could be equally re-written:

>it's still worth asking whether _paying more attention to the road, while using a system you are supposed to_ could have prevented the crash that killed Jeremy Banner.

And it's more to the subject.

<comment><USER11> This discussion is in the context of relying upon an automated driving system. Depth perception is a key requirement of a self driving car. When these conversations mention lidar, the implication its s information is fused with oper sensors to produce a coherent mapping of the environment.

The technical limitation of every Tesla vehichle thus far is their inability to reliably understand the proper depth of objects.

People have died as a result of their design flaws. That is the ultimate cost in making an automated car.</comment></comment>


Show HN: A showcase of the best designs 2017 - <AUTHOR> https://klart.co/one-year-of-design <comment><USER2> Doesn't seem to work well on iOS.

<comment><AUTHOR> Hey! Any specific issue? It should work by clicking instead of hovering to show larger images :).</comment></comment>


I Chose Dropbox Despite All the Privacy Scandals - <AUTHOR> https://hulry.com/dropbox-vs-others/ <comment><USER2> Are you nuts?? Say bye bye to your files in less than 6mos!

Never store anything sensitive or anything at ALL online, got it?!

Use external encrypted drives!! Learn for some reason.

<comment><AUTHOR> By sensitive stuff, what sort of files are you talking about?

<comment><USER3> Sensitive stuff comes in all kinds: Political, financial, social, work- related, etc.

If you wouldn't want the people living two doors away from you knowing that information, it's "sensitive".

</comment></comment></comment><comment><USER4> nice folks at [https://mega.nz/](https://mega.nz/) give you 50 gigs of top dog cloud storage</comment>


Blit – The first Unix graphical multi-programming terminal (1982) [video] - <AUTHOR> https://www.youtube.com/watch?v=emh22gT5e9k <comment><USER2> I notice that on the Blit, new windows are created by "sweeping", i.e., dragging with the mouse from one corner of where the new window will go to the opposite corner. To this day, that is how new windows are created on the Plan 9 operating system.

(Specifically, you indicate using a command on a menu that you wish to create a new window. Instead of a new window appearing, like it would on any other OS, the cursor changes shape. The shape change is your cue that you can now "sweep", and the new window is created where you sweep, i.e., in such a location and with such dimensions that your sweep is a diagonal of the new window.)

And here is an opportunity to point out my pet hypothesis as to why no one uses Plan 9: namely, the refusal by the leaders of the Plan 9 project to adapt to what later became standard ways of doing things.

Although the Blit preceded the Mac, the Mac became orders of magnitude more widely used. And when Microsoft created an operating system with a GUI, they made opening a new window work like it does on the Mac. Once hundreds of millions of computer users had become used to the way one makes a new window on a Mac, Plan 9 should have changed to the Mac way. This is just basic _hospitality_. If you run a hotel and the controls for the hot and cold water work differently than the way they work in 99% of the homes of your guests, you hire plumbers to change the controls to work the way your guests expect them to work.

For some reason, the Plan 9 folks, and Rob Pike in particular, never saw the need for being hospitable (maybe because the way _his_ software let the user create windows was invented _first_ , damn it!)

Emacs has a bit of the same problem (inhospitableness, e.g., having unusual names for things, e.g., calling windows frames and calling panes windows), but Plan 9 is the most inhospitable software I've ever encountered.

Deleting text by highlighting an extent of text (e.g., by dragging the mouse), then hitting backspace is another example where Plan 9 behaves differently than every other OS I know about. (Particularly, it causes the highlighted extent to be deleted, like other OSes do, but then also deletes one additional character, which is unusual behavior that a user has to learn -- and then unlearn every time he or she switches back to a "hospitable" OS.)

In contrast, the designers of Gnome and KDE, for all their faults (e.g., being too eager to re-invent things) understood and practiced basic hospitality towards the user.

<comment><USER3> Setting aside the misdirected sense of entitlement, the primary problem with your post is the assumption that every piece of software is required by some unwritten contract to fulfil several goals, to wit:

\- it must look like whatever you're already using

\- it must aspire to the maximum possible user base

\- it must adapt to latest technological fashions

while these are extremely valid requirements for a commercial product, plan 9 is very much not one. it is a research operating system, and no new knowledge would be gleaned by re-re-reimplementing PARC products.

your definition of "hospitality" seems to involve the willing acceptance of UI trends that some people regard to be disgusting garbage. why is it not sufficient to let people who prefer plan 9's interface use it? why do you make the assumption that user acquisition was in any way an intended result of this operating system's development?

flip your hypothesis over. why has nobody written an interface for plan 9 that meets your expectations? the answers to this question may help you understand why nobody who uses plan 9 cares that it doesn't work like an apple product from 1984.

<comment><USER2> >while these are extremely valid requirements for a commercial product, plan 9 is very much not one. it is a research operating system

People on this site have advocated using Plan 9 as an ordinary operating system, e.g., for work and for communication over the internet.

Readers like me have listened to these advocates, causing us to waste our time installing and exploring Plan 9.

I just want to warn people.

<comment><USER3> Plan 9 performs work and enables communication over the internet. It is possible that installing _any_ operating system other than the ones you currently use would be a waste of your time, in case they require you to learn them.

</comment></comment></comment></comment><comment><USER4> I used a Blit successor (AT&T 5620 nee DMD) in the 1985ish time frame. It was attached to an AT&T 3B2 host running SVr3 and later SVr4. It was a very cool, minimal, useful and very Unixy way of doing things. The "window manager" software was called "Layers", and allowed a lot of application processing to happen on the terminal. Layers windows behaved (mostly) just like ttys multiplexed back to the host. There was a pretty decent cross development environment for creating little apps, including a C compiler and debugger. There were the normal doodads like a graphical clock, drawing program (pic?), calculator. There was also a pretty neat mouse-enables editor called 'jim' and I seem to remember a sort of troff previewer. Pretty much the coolest thing I'd ever used up until I got a Sun 3/160 in '86 or so running SunOS 3.x and OpenWindows. Game over.

<comment><USER5> Pretty much the same story for me. When I first joined the Labs, I got a 5630 (the successor to the 5620), also called the 630 MTG. At the time, it was an impressive piece of equipment that was a huge improvement over a regular tty.

I found the video to be somewhat lacking in interesting technical details -- there really were a lot of neat things going on in the background to make it all happen.

Readers waxing nostalgic might enjoy Rob Pike's paper describing the 5620. It provides an in-depth look at what was going on behind the scenes.

[http://doc.cat-v.org/bell_labs/blit/](http://doc.cat-v.org/bell_labs/blit/)

Of course, I subsequently got a Sun 3/60 and never looked back. But it was fun while it lasted.

<comment><USER4> Interesting...I've never heard the 630 called a 5630. Very cool. I actually played a little with a 730X (successor to 630 with ethernet and an X server in ROM) back in the dark ages. Layers was pretty rotted by then and it was a terrible XTerm, especially WRT to the hotrods NCD was cranking out. Kinda sad.

Yet another Tech Taking Over The World^TM that didn't. I've got some bubble memory and a Symbolics around here someplace.</comment></comment></comment>


Show HN: Simple Next.js Boilerplate with TypeScript - <AUTHOR> https://github.com/BrunoBernardino/nextjs-boilerplate-simple <comment><AUTHOR> I've been enjoying working with Next.js [1] in the last couple of years, and especially with a serverless architecture, deploying to Vercel [2].

I've got most of my projects working in this setup now, and so as I was starting to work on a couple of things more recently, I decided to pick one that I've had in production for a few months without issues, strip it to the bare essentials, and update all dependencies.

It's in GitHub at [https://github.com/BrunoBernardino/nextjs-boilerplate- simple](https://github.com/BrunoBernardino/nextjs-boilerplate-simple) .

If people find these useful, I'll start a collection and release some with basic stuff like connecting to MongoDB, sending emails via Mailgun, passwordless user login, and more.

Let me know what would you like seeing!

I hope you enjoy it.

Thank you for your attention and kindness. I really appreciate it!

[1] [https://nextjs.org](https://nextjs.org)

[2] [https://vercel.com](https://vercel.com)

<comment><USER2> thanks!

<comment><AUTHOR> You're welcome! Any ideas for other things you'd like to see in another boilerplate?

<comment><USER2> I guess I might like an elasticsearch example, and the passwordless login.

<comment><AUTHOR> Hey Bryan, I just got up an elasticsearch boilerplate, but haven't published it yet. Do you want to take a look first and let me know if that's useful?

[https://github.com/BrunoBernardino/nextjs-boilerplate- faunad...](https://github.com/BrunoBernardino/nextjs-boilerplate-faunadb- elasticsearch)

FaunaDB was another thing I was asked about, so I did both together, which seemed fitting, as you can't really use FaunaDB for fuzzy searching.

<comment><USER2> Thanks, looks useful. Sorry didn't see this earlier.</comment></comment></comment></comment></comment></comment>


Professor Frisby's Mostly Adequate Guide to Functional Programming (2015) - <AUTHOR> https://mostly-adequate.gitbooks.io/mostly-adequate-guide/ <comment><USER2> Great book. I'd also recommend his free video course on Egghead. It's rather quirky, which is something that I very much enjoyed: [https://egghead.io/courses/professor-frisby-introduces- compo...](https://egghead.io/courses/professor-frisby-introduces-composable- functional-javascript)

<comment> zupa-hu ahahah, this is incredibly entertaining :D

(Skip to 0:30 in the first video, it's full of this kind of "context".)

</comment></comment><comment><USER3> Dr. Booleans guide is excellent. Another nice intro to functional programming using JavaScript is Kyle Simpsons functional lite:[https://github.com/getify/Functional-Light- JS/blob/master/RE...](https://github.com/getify/Functional-Light- JS/blob/master/README.md)

Kyle wrote the You Don't Know JS series. This book is just as good.

</comment><comment><USER4> Good read. He annotates his function with Hindley-Milner type signatures (specified in comments). I really prefer this to, say, jsdoc. Anyone know if there's a jsdoc-like tool that understands these comments? That'd be pretty swank.

<comment><USER5> I'm not sure what "Hindley-Milner type signatures" means. Obviously it is intended to refer to Haskell-style type signatures. Hindley-Milner, though, usually refers to a system of type inference which is independent of syntax.

As I understand it, the author is using Hindley-Milner as if was the name of a syntax, like Backus-Naur form. But this is something I've never heard, and I wonder if the credit for the Haskell type signature style belongs just as much to Rod Burstall or David Turner, in other words I'm inclined to believe that it is something conventional that evolved over years.

</comment></comment><comment><USER6> The Fantasy Land spec and related libraries like Sanctuary and Fluture deserve a mention here, even if only as a next step after reading this guide.

It helps bridge the gap between looking at all of this from the more math/Haskell perspective and how it's implemented in javascript, without sacrificing definitions (as much as possible).

</comment><comment><USER7> Really enjoyed this book. Once you get currying, and using curried functions to pipe/compose, everything clicks into place. I found the examples of using Nothing/Maybe monads for error handling pretty neat as well - is that a common pattern, because I don't remember native support for those types when I briefly dabbled in elixir.

Also is his explanation of monads as 'functors that can flatten' a simplification for the purposes of teaching, or is that more or less what they are?

<comment><USER8> There's really multiple definitions of "functional" right now, and the type of "functional" being discussed here, Erlang isn't, and I don't think Elixir particularly is either.

This is not a criticism of any kind; this is a point about _definitions_. There are definitions of functional where Erlang is functional, and IIRC Elixir can be said to support it.

(And there are definitions of "functional" where almost every language in current use is "functional". There's even some so weak that C is "functional" because it has "function pointers", though this one is now out-of-date and not currently being used by anyone. But, yes, there was once a time in which C would have been considered "unusually strong" in its "functional programming" support, because other contemporary languages didn't even have function pointers.)

"Also is his explanation of monads as 'functors that can flatten' a simplification for the purposes of teaching, or is that more or less what they are?"

A little of both. Technically it is correct, but the "flattening" in question applies to many things that most programmers wouldn't consider "flattening". For instance, consider monadic IO as Haskell uses. There is a way in which you can consider the execution of an IO value as "flattening" it, and it corresponds to the mathematical term, but it's not what most people have in mind. There's more to "flattening" than "simplifying data structures in some manner"; it doesn't even always involve what we'd traditionally think of as data structures at all, such as, again, IO.

Personally I think it is an actively unhelpful metaphor for these reasons, as it is very prone to leading to false understanding, but YMMV.

<comment><USER9> > There's really multiple definitions of "functional" right now

It would be very helpful to see an explanation of this spectrum you describe for someone who is not really familiar with the definitions. I would love to read an explanation of the various "functional" paradigms as they diverge from "conventional" (ie. C) programming languages.

<comment><USER8> The weakest definition of functional is that functions are a first-class object that can be passed around. This is the one that C conforms to in that old sense. This is a dead definition because almost everything in modern use conforms to this definition, and definitions are only useful to the extent they create distinct categories. Because almost every modern language has this, it can be difficult to imagine a language in which this is not true. But, yes, once upon a time, languages did not in general have a data type that could contain a function that you could call. (This is before my time, but I caught the tail end of these arguments.)

This was also one of the reasons that assembly programmers were always banging on about the power of assembly back in the day. Nowadays the only remnant of that argument is the claim that you can write _more optimal_ assembly than the compiler. But back in the day, assembly programmers enjoyed the ability to have a pointer to a function and jump to it and/or call it (it's a bit fuzzier in assembler) and people using high-level languages were definitely getting a "weaker" experience. Today we expect our high level languages to also provide us significant power advantages over assembler. (Of course you can do anything in assembler, but not as concisely necessarily.)

When I got into computing, the definition of "functional" that excluded C included having "closures". This is a function pointer + an environment for the function to run in. C only has the function pointer; you don't get an environment. It is more convenient than nothing, but vastly less useful than a full closure. (You can do them manually, but they become problematic fast.)

Stepping up from there, you got languages that generally permitted an imperative style of programming, but "preferred" what we would today call a functional style, when you use map, filter, and such to perform operations. These languages loved them some linked lists; linked lists everywhere. With their own special names like "cons lists". They also tended to be garbage collected, which for a while was a "functional programming" thing, but is now also simply an accepted thing that a language may be, regardless of how "functional" it is.

This definition is still in some usage today, though some improvement in understanding the structure of the relevant of code ("iteration" as a concept you can abstract, rather than accidentally conflating "a linked list" with "the thing you can iterate on") and the fact that hardware is getting ever- more grumpy about non-locality has erased the linked list obsession. You can either have a "functional language" like Lisp, or you can program in a "functional style" in a multi-paradigm language like Javascript. In the latter case, you can do a lot of work with the functional paradigm, but technically you always end back up at structured programming with some flavor of OO, which is the dominant language paradigm. (Languages can be multi-paradigm, but there is always a dominant paradigm, one that when the paradigms conflict, is the winner. And my personal default definition of OO includes Javascript, considering the prototype system a detail relative to the fact you still have "collections of data with associated methods".) People who say that "Javascript is a functional language" mean this definition.

Finally, there's the Haskell definition. Here, immutability is the default, and possibly the only option. Type systems are very strong, able to express types like "a block of code that does not do any IO" that other languages can not express, or can only do very laboriously. You get "functor" and "monad" and such being not just demonstrated on a one-off basis, but being the foundational abstractions of libraries and entire applications. People argue over how much category theory you have to know to practically use these languages. F#, O'Caml, and Haskell live here. Haskell is as far as you can currently go in this direction and get a language usable for practical tasks, work that you can build a business on.

(As an interesting side bar, I think Erlang made an error here, although a perfectly understandable one. When it was written, one of the reasons immutability was favored at the academic level was that it helped write multi- core code. At the time, only big industry and academia had multi-core systems. But you only really need _isolation between threads_. Immutability is one way to achieve this, but you can also make it so that it is impossible to communicate "references" between processes/threads, so everything is a copy. Within an Erlang process there's no reason not to allow one to "assign" to existing variables. But at the time, "access control" and "immutable" were sort of conflated together. Rust is the first big language that seems to be levering those concepts apart in a really systematic way.)

However, the spectrum keeps going from here. Past Haskell there are functional languages that get _really_ mathematical, and are focused on proving code, creating even more elaborate type systems such as dependent types ("this function takes a string whose length is a prime number", to give a silly example), and constraining the abstractions even further for things like total functional programming, which is one of the most interesting possible ways to limit programming so that it is not Turing Complete, _but_ can still do real work. Here you can get such exotica as ways of using the type system to separate out what code is total, and what is not, in various principled ways. One of the common "I've been in this industry for 20 years and it sucks and here's what we all need to do to fix it" posts is to extol the virtues of one or more of these things. However, while there has been some interesting progress on many of these fronts in the past couple of decades, they remain impractical.

<comment><USER10> Excellent exposition of the current landscape and of the notion that there is no single definition of FP.

I'd like to add that type-systems are not a defining feature of functional programming because you can have type-systems in what are considered "non functional" languages as well.

Immutability it jives with functional but is really an orthogonal feature as well.

So what is left? I would say is the ability to create closures because that clearly MAKES IT EASY TO CREATE FUNCTIONS without having to separately type the separate source-code of every individual function. Closures make that easy. Closures make it easy to "calculate with functions" because it becomes so easy to create new functions.

<comment><USER8> Yeah, I kinda think the Haskell branch ought to have its own term, because of the number of things that are involved that don't relate to "functions" per se, but it's not my call. "Pure functional" sort of works, but I would mean something more like "Pure _and_ functional", that is, two separate adjectives, not one where "pure" is modifying "functional". A pure, non-functional language is certainly possible. "Pure imperative" is a bit hard to conceive (Rust probably as close as you can get), but an SQL database set to a high transaction isolation level can be seen as a pure non-functional language. (And I say "can" because it can also be argued against. But it's at least debatable.)

<comment><USER11> > Yeah, I kinda think the Haskell branch ought to have its own term, because > of the number of things that are involved that don't relate to "functions" > per se, but it's not my call. "Pure functional" sort of works, but I would > mean something more like "Pure and functional", that is, two separate > adjectives, not one where "pure" is modifying "functional".

"Pure functional" programming is functional programming wherein the functions are pure functions, that is: (1) the result of the function is completely determined by the identity of the function and its arguments, and not any other external state, and (2) the function produces no side effects that would impact calls to the same or other functions. (On a _language_ level, only the first is really necessary, because if everything is composed of functions and all functions results are independent of external state, any side effects would necessarily not be observable within the language; but functional purity can be discussed with regard to constructs within a language where purity is not required at the language level.)

> A pure, non-functional language is certainly possible.

You can have referential transparency in a language whose central structure is determined by a paradigm other than the functional (e.g., referential transparency is just as much a key feature in the logic programming paradigm as the functional paradigm, and pure logic programming is already used to describe logic programming with strict referential transparency in the same way pure functional programming refers to functional programming where with strict referential transparency.)

> "Pure imperative" is a bit hard to conceive (Rust probably as close as you > can get),

Rust is basically an ML-family functional language that moved off in a different direction than the one toward purity; it's closer to impure functional than pure anything.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> For my fellow italians, I wrote a free "Introduction to functional programming" PDF, check out [https://github.com/gcanti/functional- programming](https://github.com/gcanti/functional-programming)

<comment><USER13> Is there an English translation?

</comment></comment><comment><USER14> Great book for an intro to FP if you're a JS developer. I have a talk about it a few years ago aimed at complete newcomers to FP: [http://blog.tomduncalf.com/posts/functional-programming- fund...](http://blog.tomduncalf.com/posts/functional-programming-fundamentals- talk/)

</comment><comment><USER15> This is excellent. But man, I don't think I can ever go back to not feeling like there's a huge pedagogical gap between the local maxima the functional programming explanations engineers are typically exposed to, and the much higher (though probably still not a global maxima) point that pure mathematicians have been adapted into. I just wish we'd embrace the geometric (topological, differential geometrical) threads that a lot of these concepts (like lifts etc) are connected to, instead of being arbitrarily tied to a pedagogy textured by the sociological context that coding originated from (i.e. heavily influenced by logicians etc).

<comment><USER16> What's an example of a coding problem which would benefit from all that abstraction?

<comment><USER15> While I sympathize with your sentiment – and share the mindset during my day job – I believe that this type of "what practical applications does this have"-thinking is making us short-sighted and preventing us from being able to move past our current local maxima, to cross the adaptive valley[1].

I'm not expecting the whole engineering field to start exploring the question of what pure mathematics (and not some watered down _for-engineers_ version) can do to fundamentally transform the the way programmers think and talk about what it is they do. But the fact that there are almost zero people from the geometric side of pure mathematics (though again, there are plenty of logicians) working together with everyday programmers, that's what I wish I saw more of every time I see one of these explanations of functional programming that seem almost always to be pedagogically colored by logicians hands.

[1] [https://www.edge.org/response- detail/23879](https://www.edge.org/response-detail/23879)

<comment><USER16> Cross the valley, sure, but what points to the valley right now? Useful abstractions arise out of concrete issues with present approaches. What are some of the concrete issues in software development which this abstraction could help with?

</comment></comment></comment></comment><comment><USER17> Fogus wrote a whole book on functional programming in Javascript, which I recommend if you liked this.

</comment><comment><USER18> This may be a character flaw, but I found this book's style of teaching by mocking random snippets found in the wild really, really entertaining.

<comment><USER19> You should see the videos he made for Egghead.io! Stop motion hedgehog! I know some people complained, but Egghead backed his unconventional teaching methods which is pretty cool.

\- [https://egghead.io/instructors/brian- lonsdorf](https://egghead.io/instructors/brian-lonsdorf)

\- [https://www.youtube.com/watch?v=h_tkIpwbsxY](https://www.youtube.com/watch?v=h_tkIpwbsxY)

I'm pretty sure he's the only person to make this topic so approachable. I'm glad he's into having fun with it. Quite refreshing!

</comment></comment><comment><USER20> Robert Harper's 'Programming in Standard ML' free pdf off his CMU page is the best intro I've found to really understand FP, goes into details and reasons, like the pattern matching material. Very concisely written and SML is like Scheme, easy to learn syntax perfect for teaching.

</comment><comment><USER21> When I started looking into Functional Programming, Professor Frisby's book was instrumental in my learning the concepts and applying them to a language I already know & code in.

</comment><comment><USER22> Great book, really enjoyed. For people who wanna learn more about Functional Programming (Haskell,Purescript) from 101 to building product, I recommend this resources:

FP Resources:[https://github.com/functionalflow/brains/projects/9](https://github.com/functionalflow/brains/projects/9)

</comment><comment><USER23> Excellent read for a beginner like me who wanted to learn functional programming with an already familiar language.

</comment><comment><USER24> Why does he factor out the zero valued flock of birds variable?

That seems extremely dishonest. The reason why we name variables, is so that they can hold different values. There is no guarantee that every run of the script will have the same initial variables. If it was, you might as well just type in the result.

</comment><comment><USER25> I wish I knew enough compsci to know why functional programming is useful. I read about half the book, and while interesting from a learning perspective I don't know where I can apply it.

Context: self-taught programmer in the data science/statistical modeling world.

<comment><USER26> Since I've started applying FP (I'm not very strict about it) I've been finding ways to reuse code more which lets me reduce my test footprint and increase the reliability of my code. I've also found it's easier to isolate my business logic without scoping it too strictly to an object or implementation, allowing me to think largely in coding to interfaces or contacts. This is totally doable with strict OO, but honestly I'm pretty lousy at that in practice. So FP has helped me with that too.

I lean towards organizing my applications into very dumb objects which are supported by FP-style business logic. At a glance you can infer what's going on quite easily due to the idiomatic use of the objects, but the object orientation mostly ends there. My business logic is organized into isolated modules that are as pure as I can manage without being a nut about it. The objects recruit or are operated on by that logic, so their implementation is very light and clean as a result. Like I mentioned, tests for this kind of code are really nice. They tend to be concise.

It's not perfect, but I feel like it's a way FP has greatly improved my code and what I deliver to my team in general. It's an attempt to merge the benefits of two paradigms, I suppose.

</comment></comment><comment><USER27> Excellent book. Although it says 2015 in the title it's still actively being worked on.

</comment><comment><USER28> Since the FP crowd is here, why is loading a program into memory, writing a register, or calling a function not seen as a side effect, but writing to disk is seen as a side effect? Or have I got it wrong?

<comment><USER29> I'm not really part of the FP crowd, but I'll take a stab at it. Note well, however, that what I say here could well be wrong.

On one level, there is no such thing as FP. All there is, is assembly-language (or binary) instructions being executed in a CPU that has access to some memory. (Almost) every instruction creates some kind of side effect (including changing the flags).

But nobody wants to program at that level, so we build abstractions on top of it. All higher-level languages create an abstraction. Even C creates an abstract machine, even though it's very close to the hardware. If the abstraction doesn't leak, you can just think about the abstraction, and ignore what's going on at the level(s) below it.

FP creates an abstraction that's at a higher level than many other abstractions. Within that abstraction, (almost) all you have are functions and values. Memory and registers are below that level. The changes to the call stack when you call a function are below that level. Those things are therefore not seen as side effects, because they are below the level of abstraction you're working at.

But disk is not. Therefore writing to disk is seen as a side effect, and those other things are not.

</comment></comment><comment><USER30> This book is very good. If you like Javascript and want to further your understanding of functional programming, then I would highly recommend it.

</comment><comment><USER31> Thanks.

</comment><comment><USER32> I spent about 30 minutes reading, but I didnt understand why this has 140 points and is the top thread.

Can anyone explain?

<comment><USER33> Functional programming (FP) is an important paradigm with many practical benefits, such as preventing bugs, improving parallelization, etc.

JavaScript is a language in which one can apply the FP paradigm, with some (considerable) effort. This book explains both the underlying FP paradigm and how to apply it in JS.

Other languages (e.g. Haskell, Scala, F#) are designed for the FP paradigm and make it much easier to apply. But the paradigm itself is the same for all of them, as it arises from fundamental mathematical laws.

<comment> lloyd-christmas > with some (considerable) effort

disclaimer: I haven't read the book and am not sure if this is mentioned anywhere.

What helped me when thinking about functional design in javascript was realizing that all js functions actually only have one parameter, an array of arguments used by the caller:

        function add(x, y) {
            return x + y;
        }

is effectively syntactic sugar for

        function add() {
            const x = arguments[0];
            const y = arguments[1];
            return x + y;
        }

`add(1,2,3,4)` ignores 3 and 4 instead of being an error. While seemingly obvious that these two functions would have different definitions: `add1(1)(2)` and `add2(1,2)`, thinking about it in types helped me process it when thinking out how they are actually written:

        add1 :: [Number] -> [Number] -> Number
        add2 :: [Number, Number] -> Number

<comment><USER33> Yes. This is the essence of currying.

</comment></comment></comment></comment><comment><USER34> Actually the course on Egghead is terrible. The voice that is used to comment on the video is very badly recorded and I have no idea why they chose that voice for a serious video for adults.

Edit: Also fine to not have my opinion on this, but a lot of people shared my opinion, check the Egghead comment section. I would've loved to watch that video, with a more professional voice and walkthrough.

<comment><USER35> What's with this modern internet culture of calling everything "terrible" or "garbage" because it has some defects, even subjective ones?

I've watched this gradual change in the users of my own forum I started over 10 years ago. People with no skin in the game think so highly of their opinion that they use it to discredit and dismiss something as terrible garbage.

Seems related to the rise of self-entitlement culture: In this case, a free video series is terrible because you didn't like the voice.

<comment><USER34> In my opinion it's more related to the fact, that people are actually creating very good content, so if somebody pushes something that is way under that value, you recognize and move away from it. I've watched tutorials on functional programming that took themselves seriously and used a normal, human voice to bring their point across and sorry, I consider those a lot better than this.

<comment><USER35> But notice that you didn't link to any nor provide anything beyond "Actually the course on Egghead is terrible" when someone else added value to the world by linking to the free video courses.

Imagine if your approach, instead of knee-jerk negativity and dismissal, was to enumerate those videos you thought were better if your intention was actually to communicate that you've seen better ones. That would've been a great contribution.

</comment></comment></comment></comment><comment><USER36> > _We have all the features we need to mimic a language like Scala or Haskell > with the help of a tiny library or two._

Seems misleading at best, as you mimic only some parts of functional programming. For example, for-loops are not used but neither are recursion and tail calls mentioned.

> _[T]yped functional languages will, without a doubt, be the best place to > code in the style presented by this book. JavaScript will be our means of > learning a paradigm, where you apply it is up to you._

Surprising how they teach the typed functional programming paradigm in a language which does not support you in it. Going from JavaScript to Haskell, wouldn't PureScript be a better stepping stone than this? Consider tail call elimination or all the support that type checking gives you to get the type nestings right, especially when you are a beginner and may have issues even with String being [Char] (unlike JavaScript) let alone Monads etc.

 _(EDIT: In case you didn 't check the contents of the book: Yes, this is a book that teaches Monads, type classes, pointfree style, Hindley-Milner(!) etc., not a form of FP that would be natural in JS.)_

<comment><USER33> It seems like a good book, but I think this is fair criticism. It skips some of the basic FP concepts that you mentioned, and is surprisingly heavy on more advanced topics (e.g. category theory, which I personally enjoy).

Most of the book isn't really a beginner's guide. A more accurate title might be "JavaScript for Haskell Programmers".</comment></comment>


Bounden on Android delayed, needs help - <AUTHOR> http://gameovenstudios.com/bounden-on-android-delayed/ <comment><USER2> This is probably going to sound like a stupid question, but have you calibrated the compasses on those devices? Besides the one that's wildly fluctuating, all the other ones are displaying pretty regular behaviour for an electronic compass that hasn't been calibrated. They are very sensitive (the Earth's magnetic field is quite weak after all) and the extra metal of all the devices next to each other could also affect their output.

Here's a link explaining this from one manufacturer of electronic compasses (and the biggest one, so there's a very good chance your smartphone has an AKM compass - I know mine does): [http://www.s3sensor.com/en/s3/calibration/](http://www.s3sensor.com/en/s3/calibration/)

<comment><USER3> Device proximity and calibration could absolutely be an issue in that video.

In regard to their solution (having to whitelist devices based on user feedback), I feel it's going to be a long, uphill battle. It's been tried before via a device knowledgebase and open-source analyzer app [1], but unfortunately, Android is just too ubiquitous for this to be feasible long- term (without direct AOSP support).

My suggestion: the devs should create a free, trial version of the game that takes advantage of all of the hardware it requires. If it checks out, offer the sale.

[1] [https://code.google.com/p/android- analyzer/](https://code.google.com/p/android-analyzer/)

</comment></comment><comment><USER4> Whitelist away! As an Android supporter the best way to force the environment you want is to target the environment you want. Once people see certain devices do not support the features they need they'll choose ones that do, and that encourages others to add it as well etc etc.

Your Vine does a great job showing the problem and its clear that you have done your part to try to make it work.

Best of luck!

<comment><USER5> An alternative to whitelisting would be a generous refund policy [beyond the standard window]. I've paid for more than a few apps that said "This might not work on your phone because of XYZ. If it doesn't we'll give you a refund."

</comment></comment><comment><USER6> This is a very good reason why, as much as I want to, I can't support Android. As a developer it's a complete pain in the ass to support. The webcam/media codecs are very similar to this and there are many other types of apps like this. Google really needs to step and figure out a way to fix this issue if it wants to challenge iOS's position as a favored dev environment.

<comment> X-Cubed How are these problems any different from developing for PCs?

<comment><USER6> Because, Microsoft and even linux have hardware abstractions that mostly conform to a spec. The spec in Android is complete crap and largely ignored by the hardware vendors. In Windows and linux you get the complete OS from the OS owner (MS, or ubuntu or red hat etc...) and each driver has to match the spec exactly or the driver will fail, with Android you are getting custom forks of the OS. Each one is customized to the hardware and has a different behavior.

In short it's MUCH easier to support different hardware in the PC world because the OS vendors have standardized the specs and in Android it's very wild west, each hardware vendor is supplying their own version of Android which is mostly the same but has subtle but key differences.

</comment></comment></comment><comment><AUTHOR> In the interest of total disclosure, this is not my project and I am not in any way involved with Bounden. I just found it interesting and passed it along.

I hope that's not bad form; if it is, I'm genuinely sorry for the error.

<comment><USER7> It's not bad form to post a link to someone else's content. On the contrary, on Reddit, posting only self-promotional links is considered spammy, though I'm not sure what people would say about it here.

</comment></comment><comment><USER8> Even Google can't cope with this on phones that they themselves (or rather their Motorola subsidiary) have manufactured. Ingress has really annoying known issues with getting the user's heading from the compass on some devices, including some Motorola ones.

<comment><USER9> That tends to be Ingress in general... unless one of the updates in the past few months has changed the landscape, I stopped trying to use the compass orientated maps in my N5 and N7 a long while ago.

That's a minute gripe though for an otherwise really engaging game.

</comment></comment><comment><USER10> Try to avoid a whitelist. It will drive you nuts maintaining it. Specify app requirements as tightly as possible, in terms of which hardware capabilities are required, and blacklist devices known not to work. If you catch all the popular broken devices, your rate of irritated customers should be very low.

This will, initially, require the same level of testing effort as making a whitelist, but will be much easier to maintain.

You _may_ want to have the first thing in the product be a validation test and/or calibration. But you risk confusing your customers.

</comment><comment><USER11> The answer is to say "no, fuck you, iOS only, bitches". Apple made DAMN sure that their platform is of consistently good quality. If Google can't make that same guarantee, why in the hell should you develop for their platform?

<comment><USER12> Because you're losing out on 80% of the mobile market.

<comment><USER11> Most of which are rinky-dink dumbphone replacements that see few, if any, app purchases.

If you're developing a mobile app, iOS is still where you'll find the majority of your audience, and it's less of a money sink when it comes to development and QA.</comment></comment></comment>


Julian Assange will be granted asylum, says official - <AUTHOR> http://www.guardian.co.uk/world/2012/aug/14/julian-assange-asylum-ecuador-wikileaks

<comment><USER2> It would seem unlikely that the UK government will grant him the safe pass that they refer to.

Asylum is meant to be used for political charges and while there is a suggestion that there are political motives around what is happening to Assange the charges against him are criminal ones. That means that on paper this is an abuse of the asylum process (and one which as a result actually damages it) so it's possible or even probable that the UK government will decline to grant him passage to Ecuador which leaves him exactly where he is now - in the embassy in London with no way to get out.

One thing I don't understand is the idea that the US want him in Sweden so they can extradite him to the US from there. Why not just extradite him from the UK? The UK has a very favourable extradition policy, the government are supportive of the US and likely to be more sympathetic than Sweden. It just makes no sense to me. Yes things can get tied up in the UK courts but I doubt that's different to Sweden.

</comment><comment><AUTHOR> NYT is reporting a denial - [http://www.nytimes.com/2012/08/15/world/americas/president-o...](http://www.nytimes.com/2012/08/15/world/americas/president- of-ecuador-denies-granting-asylum-to-julian-assange.html)

</comment><comment><USER3> Why is his mother referred to as "Ms Assange"?

<comment><AUTHOR> it's not so unusual in the uk / europe. maybe she prefers it to mrs.

and the guardian isn't the kind of paper that will go out of its way to force a woman's marital status down her throat...

<comment><USER3> OK I guess I was wrong but I was pretty sure she had remarried after divorcing "Mr." Assange.</comment></comment></comment>


Ask HN: In what creative ways are you using Makefiles? - <AUTHOR> <comment><USER3> My favorite use was during my PhD. My thesis could be regenerated from the source data, through to creating plots with gnuplot/GRI and finally assembled from the Latex and eps files into the final pdf.

It was quite simple really, but really powerful to be able to tweak/replace a dataset hit make, and have a fully updated version of my thesis ready to go.

<comment><USER4> Please could it be possible to view a snippet - just to get an idea of how you do this. Cheers!

<comment><USER5> I do something similar, here's my Makefile -- I have scripts that build figures in a separate directory, /figures. I'm sure it could be terser, but it does the job for me.

        texfiles = acronyms.tex analytical_mecs_procedure.tex analytical_mecs.tex \
                   anderson_old.tex background.tex chaincap.tex \
                   conclusions.tex cvici.tex gold_chain_test.tex introduction.tex \
                   main.tex mcci_manual.tex methods.tex moljunc.tex \
                   tb_sum_test.tex times_procedure.tex tm_mcci_workflow.tex tmo.tex \
                   vici_intro.tex

        # dynamically generated figures

        all: main.pdf

        main.pdf: $(texfiles) figures/junction_occupations.pdf figures/overlaps_barplot.pdf \
                              figures/transmission_comparison.pdf \
                              figures/wigner_distributions.pdf
            pdflatex main.tex && bibtex main && pdflatex main.tex && pdflatex main.tex

        figures/junction_occupations.pdf: figures/junction_occupations.hs
            ghc --make figures/junction_occupations.hs
            figures/junction_occupations -w 800 -h 400 -o figures/junction_occupations.svg
            inkscape -D -A figures/junction_occupations.pdf figures/junction_occupations.svg

        figures/overlaps_barplot.pdf: figures/overlaps_barplot.py
            python figures/overlaps_barplot.py

        figures/transmission_comparison.pdf: figures/transmission_comparison.py
            python figures/transmission_comparison.py

        figures/wigner_distributions.pdf: figures/wigner_distributions.py
            python figures/transmission_comparison.py

        clean:
            rm *.log *.aux *.blg *.bbl *.dvi main.pdf

<comment><USER6> I noticed that you have some file dependencies not encoded in the targets. Also, you might like reading up on Automatic Variables ($@, $^, $<, etc). Anyway, just for fun I tried rewriting your script in a way that should Just Work a little better.

        texfiles    = $(wildcard *.tex)

        figures_ink = figures/junction_occupations.pdf
        figures_py  = figures/overlaps_barplot.pdf        \
                      figures/transmission_comparison.pdf \
                      figures/wigner_distributions.pdf
        figures     = $(figures_ink) $(figures_py)

        main.pdf: main.tex $(texfiles) $(figures)
            pdflatex $<
            bibtex $(<:*.tex=*)
            pdflatex $<
            pdflatex $<

        figures/junction_occupations: %: %.hs
            ghc --make $^

        figures/junction_occupations.svg: figures/junction_occupations
            $< -w 800 -h 400 -o $@

        $(figures_ink): %.pdf: %.svg
            inkscape -D -A $@ $^

        $(figures_py): %.pdf: %.py
            python $^

        clean:
            rm *.log *.aux *.blg *.bbl *.dvi main.pdf

</comment></comment></comment></comment><comment><USER7> I use Makefile as a wrapper for build / test bash commands. For example I often define these targets:

\- make test : run the entire test suite on local environment

\- make ci : run the whole test suite (using docker compose so this can easily be executed by any CI server without having to install anything other than docker and docker-compose) and generate code coverage report, use linter tools to check code standards

\- make install-deps : installs dependencies for current project

\- make update-deps : will check if there is a newer version of dependencies available and install it

\- make fmt : formats the code (replace spaces for tabs or vice-versa, remove additional whitespaces from beginning/end of files etc)

\- make build : would compile and build a binary for current platform, I would also defined platform specific sub commands like make build-linux or make build-windows

<comment><USER8> are you me?

</comment></comment><comment><USER9> Teradata contributes the Facebook open-source project Presto. Presto uses Docker to run tests against Presto. Since the tests require Hadoop to do much of anything useful, we install Hadoop in docker containers.

And we run tests on 3 flavors of Hadoop (HDP, CDH, and IOP), each of which is broken down into a flavor-base image with most of the packages installed, and various other images derived from that, which means we have a dependency chain that looks like:

base-image -> base-image-with-java -> flavor-base => several other images.

Enter make, to make sure that all of these get rebuilt in the correct order and that at the end, you have a consistent set of images.

[https://github.com/Teradata/docker- images](https://github.com/Teradata/docker-images)

But wait, there's more. Docker LABEL information is contained in a layer. Our LABEL data currently includes the git hash of the repo. Which means any time you commit, the LABEL data on base-with-java changes, and invalidates everything downstream. This is terrible, because downloading the hadoop packages can take a while. So I have a WIP branch that builds the images from an unlabelled layer.

[https://github.com/ebd2/docker-images/tree/from- unlabelled](https://github.com/ebd2/docker-images/tree/from-unlabelled)

As an added bonus, there's a graph target that automatically creates an image of the dependency graph of the images using graphviz.

Arguably, all of the above is a pretty serious misuse of both docker and make :-)

I can answer complaints about the sins I've committed with make, but the sins we've committed with Docker are (mostly) not my doing.

</comment><comment><USER10> I wanted to download a few hundreds of files, but the server was enabling only 4 simultaneous connections.

I did a makefile like

        file1:
            wget http://example.com/file1

        file2:
            wget http://example.com/file2

        file3:
            wget http://example.com/file3

And used make -j4 to download all of them, but only 4 parallel tasks at once. It starts another download when one finishes

<comment><USER11> Check out aria2 next time.

[https://aria2.github.io/](https://aria2.github.io/)

</comment></comment><comment><USER12> I once implemented FizzBuzz in Make: [https://www.reddit.com/r/programming/comments/412kqz/a_criti...](https://www.reddit.com/r/programming/comments/412kqz/a_critique_of_how_to_c_in_2016/cyzxqlx/?context=2)

Even though Make does not have built-in support for arithmetic (as far as I know), it's possible to implement it by way of string manipulation.

I don't recommend ever doing this in production code, but it was a fun challenge!

<comment><USER13> Did you get the job?

<comment><USER12> No, I just made it for fun. Someone else in the thread said they'd be impressed by a proper implementation in Make, so I took a stab at it.

I do wonder what the response would be like if I actually wrote something like this in a real job interview though...

Would the interviewer like my comment style? Would they be impressed that I have the technical skills needed to actually pull it off? Or, would they be so horrified by it that they'd refuse to ever let me touch any of their code? :)

</comment></comment></comment><comment><USER14> Not particularly creative, but I'm using it to generate this blog:

[http://www.oilshell.org/blog/](http://www.oilshell.org/blog/) (Makefile not available)

and build a Python program into a single file (stripped-down Python interpreter + embedded bytecode):

[https://github.com/oilshell/oil/blob/master/Makefile](https://github.com/oilshell/oil/blob/master/Makefile)

Although generally I prefer shell to Make. I just use Make for the graph, while shell has most of the logic. Although honestly Make is pretty poor at specifying a build graph.

<comment><USER15> What are make's weaknesses in specifying build graphs (as someone that hasn't used a lot of make, but might be soonish)

<comment><USER16> 1\. You can only specify that a recipe creates multiple output files (for instance, an output file and a separate index file) if it has wildcards. 2\. Temporary file handling is completely broken. You can declare a file to be temporary, so that make deletes it after all the jobs that use it have finished. However, make randomly deletes the files at other times (like for instance if a command fails), and fails to delete the files at other times. 3\. There is a complete inability to specify resource handling - for instance, I want to mark that this recipe is single-threaded, but that one uses all available CPU cores, and have make schedule an appropriate number of jobs. 4\. If you want to have crash-recovery, then you need to make your recipes generate the output files under a different name and then do an atomic move- into-place afterwards. Manually. On every single recipe.

These reasons (and others) are why I gave up on make for bioinformatics processing and wrote a replacement. I'll release and publish it at some point.

<comment><USER6> I know make can seem a little baroque, but this is just wrong.

1\. Multiple targets for a single recipe:

        file.a file.b file.c: dep.foo dep.bar
            ...

This says that the recipe makes all of file.a, file.b and file.c in one go.

2\. Make definitely doesn't _randomly_ delete files. It deletes implicit targets.

Make by default knows how to build a lot of standard things like object files for c programs, yacc and bison stuff, etc. These are called implicit targets. These are considered intermediate files to be deleted. You can override the defaults or add your own implicit targets by using pattern matching like this:

        %.foo: %.bar
            ...

If you want to use pattern matching for _non-implicit_ targets so they don't get deleted, you can do that too:

        a.foo b.foo c.foo: %.foo: %.bar
            ...

The list before the first colon says which targets the pattern-matched rule applies to and shouldn't contain wildcards. These targets won't get deleted.

3\. This seems like a misunderstanding of make's basic role. Make just spawns shells when running a recipe; like bash, it shouldn't need to know how many threads you're using to run an arbitrary command. If you want make to build targets in parallel whenever possible, look at the `-j` option. If you want a certain build recipe to run multi-threaded, use the proper tool for the recipe.

4\. Not sure what you mean by crash recovery, but considering the above, I'm pretty sure you might just be fighting make unnecessarily.

Honestly, try reading the info manual. It's kind of massive and daunting, but the intro material is really accessible, and taken in pieces, you can easily learn to become friends with this venerable tool.

<comment><USER16> 1\. That doesn't do what you think it does. From the manual: "A rule with multiple targets is equivalent to writing many rules, each with one target, and all identical aside from that." It does not mean one rule that creates multiple targets. To achieve that, you need to use wildcards. For some reason, when using wildcards, the syntax is interpreted differently.

2\. If I create a rule to create an intermediate file "b" from original file "a", then another rule to create file "c" that I want to keep from "b", but there is an error running the command that creates "c", then make will happily delete the intermediate "b" (which in my case took 27 hours to create) although it knows the final "c" wasn't created properly. This means that when I rerun make (having fixed the problem), that 27 hour process needs to be run again, which is a waste of my time.

3\. I want to say "make -j 64" on my 64-thread server, and not have 64 64-thread processes start. But I also _do_ want 64 single-threaded processes to run when possible.

4\. By crash recovery, I mean that by default a process will start creating the target file. If someone yanks the power, that target file will be present, with a recent modified time, but incomplete. Make will assume the file was created fine, so when I rerun make it will try to perform the next step, which may take 10 hours to fail. I want make to notice that the command did not successfully complete, and restart it from scratch.

<comment><USER17> For #2, you can mark intermediates worth keeping with .PRECIOUS.

[https://www.gnu.org/software/make/manual/html_node/Special-T...](https://www.gnu.org/software/make/manual/html_node/Special- Targets.html)

For #3, I think you may be misreading ps; on Linux, ps will show you threads as if they are processes when they are not.

<comment><USER16> For #2, .PRECIOUS doesn't help me. From the make manual: "Also, if the target is an intermediate file, it will not be deleted after it is no longer needed, as is normally done." This means that my intermediate files will _never_ be deleted by make, even when everything that is built from them has been completed.

For #3, no I think I know how to read ps. I don't want 64 64-thread processes running on my 64-thread server, because that is hell for an OS scheduler, and makes things run slower, not faster.

<comment><USER17> For #2, you could always make a dependency that removes your intermediates for you after your final use. You can't be mad at make because it deletes intermediates and because it doesn't delete intermediates. Make isn't psychic.

For #3, I didn't mean to come across as pedantic. I haven't encountered what you're describing, but I have personally been surprised by how Linux does process accounting, so I apologize; I just figured you were being bitten by the same thing.

I like make a lot, but I don't use it for everything, because sometimes there simply are better tools for the task, and I hope you were able to figure out a solution.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> I've used it when I was doing a pentest - searching a network for leaks of information. I wrote dozens of shell scripts that scanned the network for _.html files, then extracted URL 's from them, downloaded all of the files referenced in them, and searched those files (_.doc, *.pdf, etc.) for metadata that contained sensitive information. This involved eliminating redundant URL's and files, using scripts to extract information which was piped into other scripts, and a dozen different ways of extracting metadata from from various file types. I wrote a lot of scripts that where long, single-use and complicated, and I used a Makefile to document and save these so I could re-do them if there was an update, or make variations of them if I had a new ideas.

</comment><comment><USER19> I use Makefiles for two components of my research:

\- Compilation of papers I am writing (in LaTeX). The Makefile processes the .tex and .bib files, and produces a final pdf. Fairly simple makefile

\- Creation of initial conditions for galaxy merger simulations. This I obtained from a collaborator. We do idealized galaxy merger simulations and my collaborator has developed a scheme to create galaxies with multiple dynamical components (dark matter halos, stellar disks, stellar spheroids, etc.) very near equilibrium. We have makefiles that generate galaxy models, place those galaxies on initial orbits, and then numerically evolve the system.

</comment><comment><USER20> To set up my dotfiles, although I'm not in enough of a routine for it to be truly useful.

        tmux:
        	ln -s $(CURDIR)/.tmux.conf $(HOME)/.tmux.conf
        	tmux source-file ~/.tmux.conf

        reload-tmux:
        	tmux source-file ~/.tmux.conf

        gitconfig:
        	ln -s $(CURDIR)/.gitconfig $(HOME)/.gitconfig

cd ~/configs then make whatever. ~/configs itself is a git repository.

<comment><USER21> You should check out Stow, its an already established project that does what you need.

<comment><USER20> What advantage does Stow give me over my current solution? I've always got git and make installed (but I'm not averse to adding something else).

<comment><USER22> One advantage would be not having to write "ln -s ..." for every file you want to link. Stow handles file trees as well.

</comment></comment></comment></comment><comment><USER23> Not exactly creative but KISS. I use only Makefile for a C project that compiles on both Linux, BSD and Mac OS.

Point being that autoconf is often overkill for smaller C projects.

<comment><USER24> Have you made a cross-build system that compiles to all three on a single machine, or that works when run on each of the three? I've been working on a system based on gcc, MinGW64, and osxcross, but if that fails I'll use docker with crossbuild.

<comment><USER25> The Stockfish Makefile is probably the best example of this I've seen. It also does some advanced stuff I'm not sure I understand yet. Profiling, setting flags for CPU instructions and making profile builds, all with support for different C++ compilers. Pretty neat stuff from one of the best chess engines.

[https://github.com/official- stockfish/Stockfish/blob/master/...](https://github.com/official- stockfish/Stockfish/blob/master/src/Makefile)

</comment></comment></comment><comment> git-pull This is a bit late, but in the book _The Tao of tmux_ , I delve into how I use Makefile's to create cross-platform file watchers that can trigger unit tests. [https://leanpub.com/the-tao-of-tmux/read#file- watching](https://leanpub.com/the-tao-of-tmux/read#file-watching)

I use Makefile's regularly on open source and personal profiles (e.g. [https://github.com/tony/tmuxp/blob/master/Makefile](https://github.com/tony/tmuxp/blob/master/Makefile)). Feel free to take and use that code, it's available under the BSD license.

The creativity comes in when dealing with cross-platform compatibility: Not all file listing commands are implemented the same. ls(1) doesn't work the same across all shell systems, and find on BSD accepts different arguments than GNU's find. So to collect a list of files to watch, we use POSIX find and store it in a Make variable.

Then, there's a need to get a cross platform file watcher. This is tricky since file events work differently across operating systems. So we bring in entr(1) ([http://entrproject.org/](http://entrproject.org/)). This works across Linux, BSD's and macOS and packaged across linux distros, ports, and homebrew.

Another random tip: For recursive Make calls, use $(MAKE). This will assure that non-GNU Make systems can work with your scripts. See here: [https://github.com/liuxinyu95/AlgoXY/pull/16](https://github.com/liuxinyu95/AlgoXY/pull/16)

</comment><comment><USER26> Not something I have personal experience with, but I have heard a story about a Makefile-operated tokamak at the local university. Apparently, the operator would do something like "make shot PARA=X PARB=Y ..." and it would control the tokamak and produce the output data using a bunch of shell scripts.

</comment><comment><USER27> I have "make Makefiles", which uses BSD make logic to create portable POSIX- compliant Makefiles.

</comment><comment><USER28> I once used make to jury-rig a fairly complex set of backup jobs for a customer on a very short notice. Jobs were grouped and each group was allowed to run a certain number of jobs in parallel, and some jobs had a non-overlap constraint. The problem was well beyond regular time-based scheduling, so I made a script to generate recursive makefiles for each group that started backups via a command-line utility, and a master makefile to invoke them with group-specific parallelism via -j.

File outputs were progress logs of the backups that got renamed after the backup, so if any jobs failed in the backup window, you could easily inspect them and rerun the failed jobs just by rerunning the make command.

Fun times. Handling filenames with spaces was an absolute pain, though.

</comment><comment><USER29> Miki: Makefile Wiki [https://github.com/a3n/miki](https://github.com/a3n/miki)

A personal wiki and resource catalog. The only thing delivered is the makefile, which uses existing tools, and a small convenience script to run it.

</comment><comment><USER30> Until recently we used them at Snowplow for orchestrating data processing pipelines, per this blog post:

[https://snowplowanalytics.com/blog/2015/10/13/orchestrating-...](https://snowplowanalytics.com/blog/2015/10/13/orchestrating- batch-processing-pipelines-with-cron-and-make/)

We gradually swapped them out in favour of our own DAG-runner written in Rust, called Factotum:

[https://github.com/snowplow/factotum](https://github.com/snowplow/factotum)

</comment><comment><USER31> I use it to setup my programming environment. One Makefile per project, semi- transferable to other pcs. It contains

        * a source code download,
        * copying IDE project files not included in the source,
        * creating a build folders for multiple builds (debug/release/converage/benchmark, clang & gcc),
        * building and installing a specific branch,
        * copying to a remote server for benchmark tests.

</comment><comment><USER32> Lisp in make [0] is probably the most creative project I've seen. For myself, in some tightly controlled environments I've resorted to it to create a template language, as something like pandoc was forbidden. It was awful, but worked.

[0] [https://github.com/kanaka/mal/tree/master/make](https://github.com/kanaka/mal/tree/master/make)

</comment><comment><USER33> I use makefile as the library package dependency [1], maybe like what package.json was in node environment.

The idea is if you want to use the library, you just include the makefile inside your project makefile, define a TARGET values and you will automatically have tasks for build, debug, etc.

The key is a hack on .SECONDEXPANSION pragma of GNU make, which means it's only work in GNU/Linux environment.

[1] [https://GitHub.com/shuLhan/libvos](https://GitHub.com/shuLhan/libvos)

Edit: ah, turn out I write some documentation about it here: [http://kilabit.info/projects/libvos/doc/index.html](http://kilabit.info/projects/libvos/doc/index.html)

</comment><comment><USER34> I don't use it, but your question made me think of one: I would like to see it (mis)used as a way to bring up an operating system.

It probably will require quite a few changes, but if the _/ proc_ file system exposed running processes by name, and contained a file for each port that something listened to, one _could_ run make on that 'directory' with a makefile that describes the dependencies between components of the system.

Useful? Unlikely, as the makefile would have to describe all hardware and their dependencies, and it is quite unlikely nowadays that that is even possible (although, come to think of it, a true hacker with too much time in hand and a bit of a masochistic tendencies could probably use autotools to creative use)

<comment><USER35> You may appreciate [https://github.com/Andy753421/mkinit](https://github.com/Andy753421/mkinit) though it is written in mk (from Plan 9) rather than Make.

<comment><USER34> Yes, I do. Thanks.

</comment></comment></comment><comment><USER36> I'm developing flight software at work on various Linux pc's that have support drivers installed for some PCIe cards. If I want to code on these PC's it's either sit inside a freezing clean room or "ssh -X" into a PC to bring up a editor. This sucks, so I have a makefile to rake in certain specifics of my flight software build with additional compile time switches for flexibility to build natively on my own computer. This allows me to essentially ignore installed drivers/libs and work comfortably in my own environment until I require the actual PC in the cleanroom to run my build.

</comment><comment><USER37> I'm using ruby's rake in almost every project, even when it's not ruby otherwise.

It has much of the same functionality, but I already know (and love) ruby, whereas make comes with its own syntax that isn't useful anywhere else.

You can easily create workflows, and get parallelism and caching of intermediate results for free. Even if you're not using ruby and/or rails, it's almost no work to still throw together the data model and use it for data administration as well (although the file-based semantics unfortunately do not extend to the database, something I've been meaning to try to implement).

Lately, I've been using it for machine learning data pipelines: spidering, image resizing, backups, data cleanup etc.

<comment><USER38> > It has much of the same functionality

You could use both to accomplish the same thing, sure. But their concepts are quite different.

Rake works on tasks, which you define (or import from some gem).

Make works with file targets more than tasks. You define how it can make a certain (type of) file and it does the job.

Personally I mostly use Make if I want to generate files from something else. Otherwise I find small scripts easier than Rake or equivalent.

<comment><USER39> Actually, Rake has both. You can define file targets using "file", but I found that for smaller projects it just becomes a more verbose make.

<comment><USER38> True, Rake also has file tasks. There still are tasks and not much like file targets in Make.

<comment><USER40> i think Rake is one of the various newer re-implementations of make that more or less miss the point of what is good about make.

make is pretty neat if you think about it as a framework to help you compute/derive values from other values. each value happens to be stored in the filesystem as a file.

in contrast, many of the newer build-tool make replacements seem to miss the whole value of values and either push or force you in a direction of doing actions with side effects.

</comment></comment></comment></comment></comment><comment><USER41> Not mine but here's a Lisp interpreter written in Make: [https://github.com/kanaka/mal/tree/master/make](https://github.com/kanaka/mal/tree/master/make)

</comment><comment><USER42> I have a makefile I use for all of my AVR projects. It has targets to build, program, erase, and bring up a screen on ttyS0 and maybe more. I add targets whenever I realize I'm doing anything repetitive with the development workflow.

</comment><comment><USER43> I haven't, but one of the cool uses that I've seen lately is how OpenResty's folks are using it for their own website, they convert markdown -> html, then with metadata to TSV, finally loading it into a postgres db. They then use OpenResty to interface with the DB etc. But all the documentation is originally authored in markdown files.

Makefile: [https://github.com/openresty/openresty.org/blob/master/v2/Ma...](https://github.com/openresty/openresty.org/blob/master/v2/Makefile)

</comment><comment><USER44> I use Ansible for deployment and Ansible Vault for storing encrypted config files in the repo. Of course, it's always a bit of a nightmare scenario that you accidentally commit unencrypted files, right?

Well, I have "make encrypt" and "make decrypt" commands that will iterate over the files in an ".encrypted-files" file. Decrypt will also add a pre-commit hook that will reject any commit with a warning.

This is tons easier than trying to remember the ansible-vault commands, and I never have to worry about trying to remember how to permanently delete a commit from GitHub.

</comment><comment><USER45> To generate 100 Terabytes of data in parallel ... on Hadoop

[https://github.com/hortonworks/hive- testbench/blob/hive14/tp...](https://github.com/hortonworks/hive- testbench/blob/hive14/tpcds-setup.sh#L116)

The shell script generates a Makefile and the Makefile runs the hadoop commands, so that the parallel dep handling is entirely handed off to Make.

This make it super easy to run 2 parallel workloads at all times - <USER2> xargs -P 2, this is much more friendly towards complex before/after deps and failure handling.

</comment><comment><USER46> I used a Makefile for managing a large number of SSL certificates, private keys and trust stores. This was for an app that needed certs for IIS, Java, Apache and they all expect certificates to be presented in different formats.

Using a Makefile allowed someone to quickly drop in new keys/certs and have all of the output formats built in a single command. Converting and packaging a single certificate requires one or more intermediate commands and Makefile is setup to directly handle this type of workflow.

</comment><comment><USER47> I guess it depends what you consider creative?

I use one to build my company's Debian Vagrant boxes: [https://app.vagrantup.com/koalephant](https://app.vagrantup.com/koalephant)

I use one to build a PHP library into a .phar archive and upload it to BitBucket

My static-ish site generator can create a self-updating Makefile: [https://news.ycombinator.com/item?id=14836706](https://news.ycombinator.com/item?id=14836706)

I use them as a standard part of most project setup

</comment><comment><USER48> I'm creating a config.inc makefile during make to store config settings, analog to the config.h [https://github.com/perl11/potion/blob/master/config.mak#L275](https://github.com/perl11/potion/blob/master/config.mak#L275)

Instead of bloated autotools I also call a config.sh from make to fill some config.inc or config.h values, which even works fine for cross-compiling.

</comment><comment><USER49> We use Makefile "libraries" to reduce the amount of boilerplate each of our microservices have to contain. This then allows us to change our testing practices in bulk throughout all our repos.

[https://github.com/Clever/dev- handbook/tree/master/make](https://github.com/Clever/dev- handbook/tree/master/make)

</comment><comment><USER50> The main question to ask if you really need to use make. If you do, there practically no limit of what you can do with it these days, including deployment to different servers, starting containers/dedicated instances etc. But unless you are already using make or are forced to, it's better to check one of newer build systems. I personally like CMake (it actually generates Makefiles).

</comment><comment><USER51> I have a makefile that sets up a brand new computer with the software I need. It means I can be up and running on a new machine in a few minutes.

</comment><comment><USER52> [https://erlang.mk/](https://erlang.mk/) \- need I say more? :)

</comment><comment><USER53> One "creative" use is project setup. Sometimes, less technical colleagues need to run our application, and explaining git and recursive submodules takes a lot of time, so I usually create a Makefile with a "setup" target that checks out submodules and generates some required files to run the project.

</comment><comment><USER54> I use Makefiles that run "git push $branch" and then call a Jenkins API to start a build/deploy of that $branch. This way I never have to leave vim; I use the fugitive plugin for vim to "git add" and "git commit", then run ":make".

</comment><comment><USER55> i use it to solve dependency graphs for me in my program language of choice, at the moment this involves setting up containers and container networking but i throw it at anything graph based

make seems to be easier to install/get running than the myriad of non packaged, github only projects i have found.

<comment><USER55> Have also seen a Full Certificate authority implemented using a makefile that was one of the easiest i have ever used

i am also currently using it with rsync to implement a poormans dropbox on a vps host with a systemd timer unit to clean files after 30 days for sharing files with customers, a simple wrapper script dumps it in the right folder, invokes make and causes rsync to run. the makefile also haandles setup of the account like ssh-add (with restricted commands), key generation and config options (via include files)

</comment></comment><comment><USER56> I use it to generate my latex CV. In my case I have multiple target countries, so I have pseudo-i18n with pseudo-l10n, and different values like page size, addresses, phone numbers, and then I just make for the target country like make us or make ja.

</comment><comment><USER17> I used it to make a blog once.

[http://old.storytotell.org/blog/2009/07/13/how-to-manage- a-w...](http://old.storytotell.org/blog/2009/07/13/how-to-manage-a-website- destructively.html)

</comment><comment><USER57> I use makefile to gen my static website. Also my CV, latex and make works well together.

</comment><comment><USER58> I've used Makefiles to determine what order to run batch jobs in so that dependencies can be met. Instead of describing what order to run things in, you describe what depends on what.

It's pretty cool, but not ideal.

</comment><comment><USER59> Nowadays I mostly use Tup. If I use make it is usually for when I'm working with other people on LaTeX documents, and often times it's enough to just call rubber from make x)

</comment><comment><USER60> I use it to run Verilog testbenches and start a Riscv simulator.

</comment><comment><USER61> I use make as a poor man's substitute for rsync (well, local rsync. Like cp -r), when I need to add some filtering in between.

</comment><comment><USER62> I use it to build all my Go micro services, run test suite, compile SaSS, minify css, minify js

</comment><comment><USER63> I use make to pre-compile markdown into HTML for a static website.

<comment><USER64> I use redo to build the menus for a GOPHER site. It's the same principle. Make changes; run redo; menus get updated automatically. I also use it to rebuild the indexes for package repositories after making changes.

See gopher://jdebp.info/1/Repository/freebsd/ under "how this site is built" and gopher://jdebp.info/1/Repository/debian/dists/ .

See also gopher://jdebp.info/h/Softwares/djbwares/guide/gopherd.html .

</comment></comment><comment><USER65> I use make to make things</comment>