schwurb

Just yesterday in the students room I whiteness the awe-inducing effect and joy of discovery that a proficient use of Vim has on someone who has never seen something like this before ;)

I think you got a point that some emacs users might severly underestimate the power of limited choices and pre-configured workflows. However, as in understood Blub, this is strictly about power of expression. I think emacs is at the top of the foodchain here, at least I don't know a text editor that would be extensible with such easy as emacs.

Same with the LISPs (which Blub is about btw) - Some LISP programs become unmantainable for people that did not write it, but without a doubt, LISP is one of, if not the most expressive language there is.

> Looked at emacs the other day but I need to read a lot of manuals and tutorials and practice to get to grips with it)

My recommendation: Go with spacemacs. It is perfect for people who just want to use the goodness of emacs without it weird edges and spending hours on configuration. One day I might switch to emacs, but for the coming time I am perfectly happy with using a pre-configured emacs. The time I don't spent working, I'd rather read more papers and do non-compsci-stuff.

Homer was wrong in his assumption. If there however does exist a button, and it works, and there is no danger associated with ignorance about its internals, then there is nothing wrong with using the button. After all, someone put it there.

> If you don't want to know how your tools work, I question one's competence or desire to do this job.

I in turn question one's competence when, instead of getting the job done, hours upon hours are spent on irrelevant parts of configuration or getting some ideal solution to work where something less elegant would perfectly suffice. Unfortunately, the folks insisting on 'mastering' ones tools tend to often be in that category.

As an analogy: I don't care if the craftsmen that fixes my house uses his hammer holding it upside down. I only care that my house is properly fixed and stays so. How that was achieved, I could not care less about.

Also Naughty Dogs of Jak & Dexter and Crash Bandicoot fame - mostly due to Andy Gavin: https://en.wikipedia.org/wiki/Andy_Gavin

Isn't the lack of a stateful REPL a feature in Haskell? Don't get my wrong, I love image/state-based developing (having working knowledge with SmallTalk and just getting into emacs). But I think it is quite haskelly to introduce functions that create the state rather than create the state interactively yourself. This should be good for mocking and tests also. Yes, this is more work than in most other practical languages, but this is Haskell for you ;)

> had to keep reminders and schedules just not to miss renewals until I synchronised their renewal schedules to batch (manual) renewing them.

Another use case for the app I am developing! The basic idea: You can enter an item (i.e. "MyOwnShop Cert") into the list. From that time on, it will be tracked how much time passed since the item was entered or renewed (by clicking the renew button). The item with the longest time since entering/renewing is at the top of the list.

Compared to schedules and reminders it has the advantage that the item is not out of our mind once the reminder or schedule pasts. It just sits there dutifully and its timer keeps increasing.

I use it for keeping up with middle-term contacts ("Wow, I have not written Carl for 3 weeks?") and health-related issues. Logging in stuff that easily spoils would be another use case. And, apparently, cert renewals :)

I leave it to that someone else to have to resolve the cognitive dissonance. One concrete benefit might be not doing in my 50ies due to stress-related health issues.

And I would happily live in a poorer society with better ethics any day (given some minimum threshold of live quality).

I appreciate the advice in general; but don't worry - Learning stuff in odd order was never a problem for me and also while I love to learn systems and languages starting from the edge cases and broken corners,the code that I write reflects none of my love for curiosities ;)

Not reading this now, but will totally reading it when I want to learn about macros. All the stuff that Alexis is doing is always mind-expanding and well-explained!

In-between coding there is more human interaction and the craft of coding itself became more social on an abstract level (code should be more communicative and all).

But I would still say it is far from really social jobs - after school, I worked at a home for elderly people, and everyday left me exhausted. After work as a programmer, my social batteries feel much more charged.

One could make programming an extremely social endeavour though, i.e. by constant pair programming (two of Googles best Software Engineers are doing this).

This is where these two issues beautifully tie together: Saving the environment is important - consuming less is a way to do say - with less paying consumers, adds become less valuable - less incentive to violate privacy.

I had a gut feeling you could ;) Interesting.

Also sorry if I came of as rude, did not mean to!

> You understand the crux of a language by being expert at it not by "me too" novice at it.

Let's not pretend "knowing" a language well is akin to a 10-year-journey like some arcane samurai art.

If you

- could build an interpreter for a minimal version of the language

- can expand most syntactic sugar into more minimal constructs of the language

- can reason about the language in usual PL terms (call-by-value/call-by-name, pure/not-pure, strictly/dynamically typed, ...)

- know the 5-10 most important milestones in the history of that language

- know the standard libraries so that you don't repeat code that is written there,

then what use is there to master a language further? If someone is experienced in language learning, the above can be accomplished for nearly any language in idk, a year? At that point of mastery, it makes much sense to learn another way of thinking instead of memorizing the official language specification verbatim.

A programmer with 3 completely different paradigms to think in will be much more effective than one with just one paradigm to think in. Time is much better spent learning new paradigm than to gain that last bit of mastery.

In my eyes, you neglect the opportunity cost of "using one tool for everything": You end up with a solution that is much harder to mantain, since the wheel will have been re-inventend many times over and sprinkled with bugs along the way. Given a problem of fixed complexity, at some point costs will rise when fewer tools are used.

In summary: There is a "too much" and a "too few" when it comes to the number of tools used in a project. Where in that spectrum the OP is falling, we can't possibly know without knowing more details. Maybe the cost could have been smaller, maybe they hit an optimum and costs couldn't have been reduced by fewer tools (or more tools).

> That will depend on what the GP has done with SQL.

I am sure they built their UI with SQL - as opposed for example simply doing some queries, or some joined procedures at best.

> Also, JQuery implies in Javascript.

With uttermost likelyhood, they did not only dynamic changes of some html-documents there, but also their backend and crypthography.

Enough with the snark... ("Language" is such a fuzzy term anyways. You could go as far as to label any interaction with a computer as one - there will always be a protocol according to which the interaction happens.)

> There should be plenty of people capable of taking the codebase, but it's not a trivial single language case. The upside is that good developers will be overrepresented when compared to the population that knows one of Python or Javascript.

I still stand by my point. As far as the cost of polyglotism is concerned, that is a one-general-purpose-language-codebase and the rest being DSLs (apparently R too). There are other codebases where there are really 2+ languages. I.e. some functional lang on top, some performance critical code hand-written in C, some logical programming language to do some constraint programming. Each of those 3 takes quite a lot experience.

> cron, Makefile, bash, sed

For a programmer with a minimal amount of linux experience, it likely takes a week to catch up to what the codebase is doing with these.

> regex

There are good tools to destructure regex.

> python sql jq query

I consider those as "given" or "learnable good enough in a week"

> nginx conf

Don't know this.

Overall, "knowing all these languages" seems overblown in the choice of words for me. Java, Python, Prolog and Clojure? Hell yeah that would take quite a developer to replace! But the above? There is 1 proper general-purpose language in there, the rest are well-known tools with great examples online.

I always think of Emacs (never used it tho) as a Smalltalk system without images and with Lisp instead of Smalltalk as the underlying language.

Every visible and invisible think is inspectable and changable at runtime, yup - pretty cool and I loved it for programming! Not sure whether I want to get on the emacs train tho. I have problems mantaining efficiency either way already... And I favor tools that work without set-up. Then again I am still young enough that learning investments pay off by a huge margin... tough.

How would you compare Perl to Haskell (i.e. in terms of mindexpansion) and APL (i.e. in terms of learning how think tersely)?

What does the effect of harassment on males have to do with whether males are more likely to be harassers?

Please point out where I am (completely!) wrong.

I have formally dealt with approximation algorithms before and I skimmed the wikipedia article, yet I did not find anything that contradicts me. Note the in the section on hardness, P and NP (obviously) appear as bounds of solutions. Where is the contradiction?

Further, all this (approximation algos and P/NP algos) are discrete, complete algorithms. ML is a completely different story, as one is never certain whether some optimum is global or local. Hence, ML is a heuristic, while Djikstras shortest path algorithm is a series of steps with a success guarantee (with provable worst runtime behavior).

ML is all about finding approximate solutions. Categorizing problem as NP-complete only makes sense when talking about exact solutions.

First of, all the best to you!

Regarding your point: That does not sound like an issue inherent to startups, but more like an issue of bad prioritizing. Why does an start-up have to be all-or-nothing? Robert Graham advocates this way of going in, but there are plenty successfull examples of people keeping it low out there too.

Yes, stress is a killer, and startups are often more stressfull than other jobs - but most of the effects of stress depend on how on is dealing with it. And that can be trained.

> Take care of yourself first, you are competing with others that are in tip-top shape.

Competing is a two-way street. If one has enough money banked up and enough motivation, why shouldn't they go forth and found? Chronically ill persons are usually able to do things, and if that thing happens to be a startup, why not?

> There must be an "other" -- something to conflict or compete with -- in some sense.

Absolutely with you. My suggestion: Climate change. Why would you need hostile aliens when our environment itself turns against us?

I am currently building my first mobile app on Flutter and quite happy I choose that technology! Developing in AndroidStudio + Flutter does not feel like the chore I remember developing android apps to be.

Great insight! To add to this: To counteract, one needs to implement some kind of synchronization device, which has bring plenty of other problems. It would be exiting if nature would choose a more snychronized approach if it had the choice.

> If you struggle to prep food for cooking, you're going to be slower and probably less effective than the master chef who doesn't even have to think about how to dice.

This analogy is not good in that prepping is a major part of the complete task. To fix the analogy, consider the same scenario, but prepping now takes only 2 minutes per complete meal and can be cut down to 30 seconds given years of training.

> I believe the Kay-official answer to the question "what is Kay oop?" is "you just don't get it." Which for me has always raised a flag.

There are at least two problems at work here:

1. The words that Alan Key is (rightly) using are overloaded, since other languages adopted the OO term, but interpreted them differently. This adds to miscommunication: The words sound familiar, but their meaning might be subtly or drastically different.

2. The advantages of OO as thought by Alan Key are hard to convey if not by hands-on experience. Debugging and developing programs in Smalltalk is really fun and effective, but I had to write my thesis in a Smalltalk company first to appreciate it.

This is an instance of the "blob problem" as termed by Paul Graham. Many Non-Lispers have a hard time appreciating the benefits of powerful metaprogramming, and reading articles about it won't change that. They might peak interest, but one has to play around some time with those concepts to gain a feel for what benefits and limits are.