greghendershott

Racket provides delimited continuations. The page you linked to is criticizing undelimited continuations -- including quoting Matthias Felleisen -- and contains a link to the following:

http://okmij.org/ftp/continuations/undelimited.html#delim-vs...

I agree. Not just lots of companies. Most companies die. ("Hustle" or no.)

However I think that's actually a point in favor of starting small: If you're going to fail? At least fail fast. While you have time to "pivot", or wind down, or whatever makes sense to try instead.

If you're onto something, you can usually tell at a small scale. Sure, sometimes there are network effects and exponential growth. But not hockey sticks. (Source: My own opinion and anecdata.)

This reminds me of what Richard Branson supposedly said: If you want to be a millionaire, start with a billion dollars and launch a new airline.

(To be fair, airlines pay humans... as employees... unionized.)

I understand the rationale for spending $2 of marketing/whatever to buy $1 of sales. Grab market share. Step 3, profit like it's 1999. We'll see.

Although the "death of distance" hasn't happened as fast as expected/hoped, maybe it's too soon to give up on it.

Trying to kill distance might be crazy. But is it crazier than trying to cram even more jobs, people, and housing into a tiny % of the available area?

Geographical income inequality exists. Maybe it always will, and maybe we can't make it much better. But why should we try to make it even worse?

Seems to me this equation has a couple "V" variables -- VR and VC -- to which small adjustments might make a large difference.

Some people ignore these. Or rent a truck and take their usual route.

It's almost that time of year in Boston when many people move c. Sep 1. Some get "Storrowed":

http://realestate.boston.com/news/2015/08/28/your-guide-to-a...

Exactly. I actually used Quicken in my startup's early days. Naively. And fortuitously. Even after we switched to real accounting software, I would focus first and mostly on the cash flow statement and similar metrics.

Many things might someday be cash -- an invoiced sale, an A/R balance, an investment term sheet. Or they might not. Meanwhile they're only promises or futures -- worth nothing if the company abends due to a SIGKILL. A small business is very much an exercise in blocking I/O. :)

Maybe they're reluctant to pick "the" how, too soon.

If you're in a field from the early days, you probably have more of a pioneer or explorer mentality. Later come settlers, who pick areas for utility. Even later come residents, born and raised there, most of whom don't really question what is given.

This probably seems weird and frustrating to the explorers -- why settle so soon? Yes it seems comfortable and convenient, here, but there is so much left to explore.

That's how I understand Alan Kay. He doesn't want to sell us some snazzy next big thing. He wants more of us to spend more time imagining and trying new things.

I feel badly for the person who didn't realize you were sarcastic, passionately defended the idea that git != github, and got down-voted as their congratulations.

The division -- between predicates for attribute values vs. specs for maps/seqs -- is interesting because AFAICT Datomic schemas ~= the former, while leaving the latter to your app? (Although I guess :db.cardinality/many straddles that line.)

Prior to an IPO or acquisition, valuations have approximately the precision and accuracy of agile estimates chosen from a drop-down list populated with values from an echo chamber inhabited by....

Interesting you should mention that, as today I just watched Gerald Jay Sussman's NYCLisp talk, in which he discusses it starting at 29:00.

https://vimeo.com/151465912

It's probably wise to enjoy "business biographies" as lying somewhere on the floor closer to the fiction aisle than the non-fiction.

Most stories are pitched by PR firms (or the other side of the same coin, attempted take-downs). Either way, they're ready-fire-aim -- finding facts to fit a conclusion.

First and foremost they are stories -- written by someone attempting, under deadline, to fit messy, complicated reality into a simple, entertaining narrative to hold your eyeballs.

Think of them as professional fan (or anti-fan) fiction.

Even long-form articles and books that interview many people, while admirable efforts, present a pretty small slice of reality.

use-package is wonderful, as is bind-key (also by John, and a dependency of use-package).

Together they reduce the "psychic weight" of trying, using, and configuring packages.

They make your init.el a portable artifact of reproducible research. :)

Cool. Mine's in Racket:

https://github.com/greghendershott/frog#frog

> (because there are so few of them and everyone needs their own)

A million monkeys.... :)

Exactly.

There's a spectrum of evaluation strategies from eager to lazy. Programs may mix various flavors.

Lazy evaluation combined with memoization is a sexy and elegant approach to some problems, as are dynamic web sites. On the other hand, whenever possible to do so, it's hard to beat the speed and simplicity of handing over a precomputed answer like "42".

A (very loose) analogy:

Static generation of HTML is roughly like using Lisp macros to evaluate some things before runtime (at "expand time" or "compile time").

The resulting transformed code could be a simple literal like "<html> ... </html>". Or the code might need further evaluation at runtime -- which is roughly like the precomputed HTML containing JavaScript to do things at runtime.

My most unrewarding educational experiences felt like I was being fire hosed solutions to problems I didn't have. This is a big challenge in the early stages of learning any subject.

Interestingly, experienced software developers benefit from barely-learning about many solutions to problems they don't have, yet. What I mean is a style of skimming stuff like API documentation. You don't really learn it. You can't recall details. But you can recognize its applicability. Someday a problem tickles your memory, and you know roughly where to go looking for the details. And of course then you're really motivated to learn it, for real. You have an immediate need.

I'm not going to take the inter-generational warfare bait :). But I agree with what I think is your main point.

My natural tendency is to want consensus. I think that's worth attempting within a reasonable time-frame. But after some discussion, eventually a decision needs to be made.

Many decisions are reversible at a very small cost. Sometimes making the wrong decision, soon, then correcting it, soon, wastes no more time and resources than not deciding at all. Sometimes it's even preferable for morale.

Having everyone row together in the wrong direction, then change course, isn't ideal. But at least everyone is rowing in the same direction and feels like a real team. Often that's better than sitting in middle of the ocean, oars in the water, debating and going nowhere.

But as with most advice I offer unsolicited, I'm going to waffle and say, "it depends on the situation". :)

I'd suggest Racket, a descendant of Scheme.

- It is really easy to download, install, and be coding in 5 minutes.

- There's a nice GUI IDE, if that's your cup of tea. (Also I maintain racket-mode for Emacs.)

- It is "batteries included" (maybe not compared to Python (!), but definitely compared to most Schemes).

- You can write everything from command-line programs that launch quickly, to GUI apps, to web apps.

And particularly why I mention it here:

- You can explore many approaches mentioned in the OP: functional, gradual typing, object-oriented, lazy evaluation, datalog, and more. (Ultimately, Racket is "a programming-language programming language". Although you can ignore that level of abstraction and simply use it as a very nice lisp.)

Yes. I'd say that every success is due to a combination of determination, skill, timing, privilege, and luck. (You could say that most of these are really variations on "luck".)

Naturally, people tend to emphasize only some of these factors, depending on their own experiences, current agenda, and what kind of story they need or want to tell at the time. Each of these stories is the truth, but not the whole truth.

[Is this fatalistic? I don't think so. Just because most factors aren't under your direct control, doesn't mean you can't be determined and keep trying. Also you could insert here some aphorism like, "it's the journey not the destination". If you're having any fun and even a modest amount of success, you're quite fortunate. You could do worse. Some billions of people probably are doing worse. You may as well be appreciative and thankful, while you keep pushing forward.]

> Your thinking will be better off if you just don't think of the term "lifestyle" business. It's a pejorative used to manipulate you into wasting your life in service to someone else's narrative.

Exactly. I've only ever heard this from someone seeking transaction fees. As in, "Not there's anything wrong with running a lifestyle business." While their body language suggests everything is wrong with that.

I've heard a similar idea expressed using more colorful language:

"Often you hear people say they have a 'bucket list'. Well I also have a 'fuck it' list. The older I get, the longer it grows."

52Kards on YouTube has many free tutorials at beginner, intermediate, and advanced levels:

https://www.youtube.com/user/DecksAndContests/featured

Although I just dabble I think they're mostly very good. They're definitely easier to grasp than the books I remember as a kid.

Recently he's moved to doing non-free material:

http://52kards.com/

In my limited experience YouTube has almost everything. Search for, I don't know, "table faro shuffle", and you'll find a few meh results and one gem. (Table faro shuffles are arguably what Ricky Jay is doing at the start of this classic, if you don't believe it's just a camera edit: https://www.youtube.com/watch?v=UWvRorX0KhQ )

Yes, this seems to be the root of most of the problems described by OP and some comment threads here. In old school print ads, the publisher decides what is appropriate advertising for their readers. This needs to be possible for web site publishers, too. With status quo ad networks, AFAICT it's not possible.

It seems that ad networks are a necessary evil to match many small advertisers with many small web sites. (No revolutionary "disintermediation" here; quite the opposite.) The question with distributors is, which end do they feel they work for? Today's ad networks view advertisers as the customer to serve. Instead, although I don't know if it's economically viable, it seems like we need ad networks who view the web site publisher as a client to serve. And who give publishers the tools to accept only ads they deem appropriate in terms of content as well as ad tech.

While checking the Traffic stats for one of my projects on GitHub today, I discovered inbounds from the following site:

http://www.staticgen.com/

It's interesting to see just how many static blog generators there are. :) Also, if you prefer you can probably find one written in $FAVORITE_PROGRAMMING_LANGUAGE.

You politely and clearly explained why you're unconvinced a repo would benefit you. You got a couple replies pointing out some advantages, which maybe you hadn't considered or at least some other people might not have known about.

Result? Nice discussion. Opportunity for folks to learn something new.

And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.

The all-in-one-page version is http://www.greghendershott.com/fear-of-macros/all.html

Also, the source is https://github.com/greghendershott/fear-of-macros

Often there's some tension between individual career development and what makes sense for the project and company.

Ideally, managers create opportunities for people to exercise the former in a sandbox (e.g. some variation of "20% time"), without YAGNI-ing up the project.

Sorry did I say sandbox? I meant container.

> That said, can somebody implement hygienic macros in JavaScript.

Although I haven't used it hands-on, http://sweetjs.org/ looks impressive.

For example recently sweet.js apparently implemented some cutting-edge Racket macro developments before Racket officially did. :) https://github.com/mozilla/sweet.js/pull/461

Although I haven't read this book, I read its ToC. Apparently it seeks to introduce you to the Emacs way of doing things. And guess what? Near the end, it emphasizes how to use Emacs' self-documention: https://www.masteringemacs.org/book/look-inside/table-of-con...

I'm embarrassed to say how long I used Emacs knowing about C-h f -- but not noticing and using C-h i to read the full documentation from inside Emacs. I wish I'd appreciated that from the start.

At this point I've read the full Info doc at least once through, some sections multiple times. It's impressively good, especially for getting a crisper understanding of topics you only sort of understand. It's one of Emacs best features.

But I can totally see the value of a good introduction book, and wish I'd had one when I was starting out. So although I don't know how good this book is, I don't think a book is pointless.

I agree the not-yet-abandoned Google apps can be quite superb.

Provided you run them using the proprietary {AOL,Prodigy,CompuServe,MSN} client app.

a.k.a. Chrome.