that steve yegge story is...anti-climatic. you mean bezos pointed out he left off data mining and machine learning in a presentation about generalist engineers? what vast and yet cutting insight! ugh.
that story just reeks of the blind idolization that goes on with these people. you see it in musk devotees as well. yes, these people are smart, successful, and driven. but they aren't literal incarnations of comic-esque super geniuses or intellectual gods. they are people who's primary power is their drive.
how about just respecting their drive and intelligence rather than putting it on a pedestal? think originally and don't be some dumb slave that bows down to supposed super intelligence. question whether those people really have the capability to understand a certain novel idea, because they may not. they got to where they are because they followed a path and followed it HARD, meaning there are maybe paths they didn't have time to consider.
Well, this story was posted in 2011 and although Yegge doesn't specify a date, I think it's safe to assume that the story took place years before the blog was posted as Yegge had by then already moved on to Google.
So this means that Bezos was thinking about data mining and machine learning in a presentation about generalist engineers at least 1/2 decade before this became common place.
that still doesn't really hold up. i mean amazon was dealing with massive data a lot sooner than most. it's a pretty natural instinct to think those (not all that young) fields are important. and generally the story makes no sense. yegge acted like it was an obvious thing, immediately saying oh yea i forgot that. how is that alien-level genius at play? bezos may be smart, but yegge's exposition does nothing to demonstrate that. it's hard to believe yegge got famous as a writer.
i didn't reduce anything, there is nothing unfounded (i used this because you said canard but then changed it to banality) about applying "drive and intelligence" to bezos, and yegge didn't present any particulars to even throw out. i am sure there are a lot of interesting particulars about bezos, but yegge's article didn't present any. do you have any you'd like to share?
Hear hear. Bill Gates is trying to kill malaria. He doesn't care about having the biggest number next to his name when he dies. He wants to be the guy who's known for killing hunger in Africa.
Frankly, I'd love if Bill Gates had nearly zero at his death.
How amazing would it be for a man with that much wealth to set some aside for his children, whatever he thinks establishes their life and his duty to them, and then make it his goal to have nothing by the time he dies.
Set up foundations to kill hunger, diseases, etc. But as death approaches and the years drag on, really ramp up the giving.
"Bill Gates: Net worth $0" would make an amazing headstone for a man who spent the latter part of his life giving.
I thought about that a while back and I'm sure he'll setup some fund somewhere for them in case something happens to as a secret safety net. With their names and education alone they should be pretty well off, though.
I would give my children way more that 0.01% of my wealth if I was in his shoes. I would raise them to be respectable stewards of my wealth so they can grow the wealth and continue giving to charity long after I'm gone instead of ending everything within one generation.
True, perhaps that's the "best" way to do it - but I think I'd leave that up to my children. If they wanted to live the charitable life, work for the people so to say, then by all means.
But by default, I'd not want to put that burden on my children. In a perfect world (for me), I'd give them enough that enable them to do whatever they want, selfishly. I don't mean selfishly in the negative sense.. but from my perspective I'm giving them a gift. I want them to have a life without fear, worry, or struggle. If they wanted to live their entire life relaxed and on the beach, so be it - that's my gift to them.
If, instead, they wanted to manage billions of dollars, focusing on making money to give money like a non-profit, then great! But that's not a "gift" I'd give anyone, more of a job, from my perspective.
This is actually a shame if Bezos doesn't do anything good or interesting with it. Seeing piles of money go back into the money making game is sad compared to what a pile of money does in the hands of a Gates or Musk.
Thanks I forgot about that. Now I can use cognitive dissonance to believe I am helping space flight progress and continue to feel good about my prime subscription!
I think it's fantastic. So many logos have gone from an old-timey and colorful scheme to something simple and monochromatic. I'd be very happy to see such a revival.
For some reason, when I started my software engineering career I got it into my head that I needed to learn as much as I could about programming languages.
I learned ruby, perl5, python, lisp, forth, ml, ocaml, scheme, haskell, r, c#, java, lua, c++, factor, idris, asm, erlang, prolog, rust, d. But that wasn't quite enough because haskell and idris kept on talking about complicated type theory stuff. So I also learned lambda calculus, type theory, set theory, domain theory, topology, category theory, information theory, sub-structural logic.
What I'm trying to say is that I'm not afraid of learning new things. Even if they seem hard or esoteric.
When I heard that perl6 was ready, I took a look. I like the idea of a lot of what is present in the language (hey look, a grammar engine, that's neat). But ultimately, I decided that it was too much stuff that I would have to learn. Maybe that's just a perception problem on my part, but I have to think that they have some sort of problem if someone like me feels overwhelmed by all of the things that you have to grok in order to understand the language.
Perl 6 is designed to be a large, feature rich language that can be learned and used incrementally. The intent is that, like users of natural languages, Perl 6 practitioners gain fluency and nuance in their expression over time.
So, if you want to learn Perl6, don't worry about writing "baby talk" Perl 6. Write something that works and solves your problem. Later on you may learn that there are multiple other ways to express the same ideas you wrote already. Maybe one of them better expresses the heart of your algorithm, then you update your code.
Now, you may think, how the heck am I going to maintain code written by a bunch of people at different phases of learning Perl6?
The Perl community has responded to this challenge by putting a huge amount of work into writing excellent documentation. Perl6 docs are readily searchable and carefully indexed. It's a big, new language with lots to write about, so the docs are not yet complete, but they are already fantastic and keep getting better.
So, please, just pick a problem to solve and jump on in. The water's fine.
Also, errors are mostly pretty good and getting better. I think a big and overlooked part of learning a new language is the quality of the errors the language provides. Some do this better than others, and some get it right in the core language but by the time you've stacked up enough libraries and extensions to get things done nicely, the errors aren't so good anymore because they talk about things at a lower level than you're thinking of them (Perl 5 can fall prey to this latter problem, even though the core language has pretty good errors these days).
Perpetual intermediates exist in every field, many of them with far more nuance than any mere programming language has to offer. The way to extract productivity from these people is the same in software development as it is in any endeavor: leadership.
Good leaders identify and propagate conventions that can keep their teams functioning in a complex millieu.
You can't get rid of the irreducible complexity of any system. You can only move it around.
In my experience, if you use an expressive language well, you can fit the code to the problem domain in a way that better communicates the underlying approach you have taken to solving the problem.
Relying on strict, small languages, like Java, means that you gain a consistency of syntax by sacrificing flexibility.
I've seen monstrous turds written in many languages, the problem in all these cases was poor or absent leadership.
That's understandable; if you look at the slides and see all of the integrated features in one big blast, you're going to think "holy moly this was not meant for mortal men".
In a way that's correct, because ultimately Perl6 is designed as the ultimate "kitchen sink" language; it has all the little features you could think of already baked in, which will include a lot of features you won't use.
The main reason for this stems from the overarching design philosophy; "There is more than one way to do something". The language ultimately tries to be as flexible as possible, going so far as to support modification the the core grammar, the object system, etc.
This is meant to make the developer as comfortable as possible, but it can lead the common case of perl-itis, also known as "write-once, read-nonce" code.
Another way to look at it is that it's designed to be a great "babytalk" language, the idea that everyone should be able to relatively easily learn enough of the language to easily get done what they need to easily get done. I'm not saying it's there yet -- doc is critical -- but that's part of the idea.
Conversely, whereas the P5 motto was TIMTOWTDI, the P6 motto is closer to TIMTOWTDIBSCINABTE, so there's usually relatively few idiomatic ways to do something.
Think of it as incorporating many of the features in all of the languages you mentioned above, but in one language that is designed to grow. The language can easily be enhanced both officially and by the end user. So not too many new concepts for you, just a different syntax.
With all due respect, you didn't "learn" these languages. You got a superficial understanding of these languages. It's like someone who learns to say "hello, name is John, what is your name" in 17 human languages saying they learned 17 languages.
Being able to write "hello world" in all these languages doesn't mean you "learned" it.
> So basically you're saying that it is a preferred solution to teach kids math poorly, let them develop insecurity and aversion towards it and then spent a lot of money to let them overcome it than just do it right in the first place?
Yeah, I know that's not what you mean, but you're missing a point.
If you knew it's not what they meant then why did you start off saying that's what they meant? If you thought they were missing the point why didn't you just say that?
I really like type systems. I think that if you take the time to learn about type theory, then you are more likely to create better solutions (both with code and in life in general).
However, it isn't free. Type theory is a kind of math that most people have very little exposure to, so there's going to be a lot of work in order to start becoming proficient.
Additionally, there's more than one type of type theory. Are you using a system F like system? Are you going to have sub-typing? Is it going to be structural sub-typing? Maybe you want row polymorphism. Is there going to be a kind system? What about higher order poly kinds? Dependent typing? Intensional or extensional?
Additionally, there's more than one type of implementation of these type systems. Ocaml functors ... is it a generative or applicative functor? Haskell ... are you using gadts, functional dependencies, or type families?
In the end I think that type systems will eventually be able to get you a completely typed experience that feels exactly like a completely dynamic experience, but with compile and design time checks that always make you feel good about the experience. However, I don't think we are quite there yet and I don't think you can expect everyone to be able to take the time to get sufficiently familiar with an arbitrary type system in order to be productive with it.
I'm not sure, but I remember seeing some research into using it for Haskell stream fusion (can't find the video, sorry).
I believe that the basic idea was that not all rewrites end up being equally fast ( a * b * c can be fused into ab * c, but maybe a * bc is faster). Trying all the combinations is an option in theory, but you get a combinatorial explosion so you normally dont get far in practice. Enter machine learning. I'm not sure how successful they were, but I imagine that the same sort of thing could be applied to SIMD.
If you're an explorer and you live in a small valley, then you will slowly begin to believe yourself a better explorer as time goes on. But one day you will get to the edge of the valley and look out onto a vast landscape and believe that you have become a worse explorer.
Checkout the volume of N-balls [1]. As the number of dimensions in a "sphere" become higher the "volume" of the sphere becomes smaller when you compare it to a hypercube of the same dimensional count. This is another way to saying that as the number of dimensions increases the closer the "halfway" point of the volume of the N-ball gets to the edge of the N-ball.
Programming (and software engineering by extension) involves a lot of orthogonal issues. We can imagine this so be a really high dimensional space. My theory is that whenever you're in situation that can be represented by a high dimensional space you will learn a bit of knowledge and think you know something. Then you'll learn a bit more and discover there's more to learn. The more you learn the farther the horizon moves away. It will feel like you're getting worse. Just like finding out you live in a valley.
What's really happening though is that your increase in skill is allowing you to realize how small your world was all along. Keep learning and trying and you'll get better. It will however, take a while.
>We can imagine this so be a really high dimensional space. My theory is that whenever you're in situation that can be represented by a high dimensional space you will learn a bit of knowledge and think you know something. Then you'll learn a bit more and discover there's more to learn. The more you learn the farther the horizon moves away. It will feel like you're getting worse.
That is all true but I don't think the n-dimensions analogy applies to the particular essay the author wrote.
He didn't look back on his accumulation of learning and suddenly notice that it was smaller part of a larger knowledge space. (E.g., programmer stumbles across "monads" and suddenly he realizes that's just the tip of the iceberg in a never-ending horizon of category theory.)
Instead, his essay is lamenting the all-too-common "joy vs drudgery" in projects. It's a similar sentiment that aspiring writers who don't finish their "great novel" have. He then grades himself on his lack of motivation (words like "lazy") to stay on top of programming tasks that are not pure intellectual fun. On his idiosyncratic standard of "programming competence", he wonders if he is a "worse programmer".
Of course, he can choose whatever "success metrics" he wishes to apply to his personal projects but some of us might think that staying on top of documentation (that nobody will read) or adding features to Lily (that a large population of programmers haven't adopted) can bring undue self-criticism.
If we are to plow ahead into boring unpleasant tasks, there usually has to be a compelling motivation -- e.g. we think the personal project is the basis of a great business startup... or the code is part of a PhD paper due next Friday, etc.
Maybe there's a simpler explanation: FOSS projects can easily turn into unpaid work, and devs tend to burn out.
Projects that start as fun programming exercises eventually take on all the aspects of a full-time job with "customer" support, project planning, maintenance, bug fixing, and so on.
It can become very draining, and if the project isn't unusually popular or high profile and/or there's no other dev support and/or the team isn't solid and mutually supportive it can be understandably difficult to stay motivated.
One of the insidious things about FOSS is the way that devs can make themselves feel as if they ought to be doing all of these things, sometimes in addition to a full-time job.
The problem isn't that they're not up to the task, it's that the expectation isn't very realistic.
Then don't do it. If no one is paying you, you owe no one anything. You have no obligation. Walk away. Our society and economy have lots and lots of money. If the way system works can't justify paying you for your work, then you should not be doing that work. At least that's the way I see it. At this point FOSS is big business, if you are not getting paid, then you should not be bothering with it.
Get someone with money to pay you for it or don't do it. The end.
I think I get part of the N-ball analogy, but I'm trying to piece together the rest...
So it seems like one problem/feature with high dimensional spaces is that you have more regions which are orthogonal to one other. So, it's possible to have quite a bit of motion, which to a human mind might give the impression that one is doing quite a lot—but then you might discover a new way of turning around and find that space extends in another direction, too, at which point you realize you covered a smaller fraction of the available space than you previously believed.
What I don't get is how the volume of an N-ball with fixed radius going to zero as N goes to infinity plays into the analogy. When you say, "when you compare it to a hypercube of the same dimensional count," I don't get what in the programming analogy would link to the N-ball rather than the high dimensional hypercube. I also get the algebraic justification for this property of N-balls, but I still have no real geometric intuition for why it would be the case.
Could you clarify what's meant by, "as the number of dimensions increases the closer the 'halfway' point of the volume of the N-ball gets to the edge of the N-ball"? Not sure what's meant by 'halfway' point here, or edge of the N-ball. My guess is that you're talking about distribution of volume, like if you have a tapered cup that gets small at the bottom, most of the volume will be at the top.
Checkout the generic formula for any number of dimensions [1]. The function in the denominator is a factorial (except extended to work on decimals instead of just integers). The functions in the numerator are exponents.
Factorials grow much faster than exponents, so with an N-Ball we expect the "volume" to be small if we were to compare it to the corresponding hypercube when the dimension and when the diameter / length are all equal. After all we're comparing approximately diameter * R ^ D / D! and length * R ^ D. So if you put an N-Ball into a hypercube with length = diameter, what you'll discover is that the N-Ball is tiny when compared to the hypercube. Which means we have the weird and counter intuitive conclusion that all the "volume" of a hypercube is in the corners. Try calculating the volumes yourself using a high dimension like 100. Even better plug the whole thing into a script so you can generate a table and see the effect get progressively worse as you increase the dimension count.
There is also a similar effect on the N-Ball itself. Imagine drawing a smaller circle inside of a circle where their centers are the same such that the inner circle contains exactly half of the area of the outer circle. Now imagine doing this in a sphere. Now a 4D sphere. Now a 5D sphere. What you'll find is that as you increase the dimension count, the radius of the inner circle will get longer and longer. Which means that half of the "volume" of an N-Ball slowly moves closer and closer to the outer edge of the N-Ball as you increase dimensions.
Here's the punch line. Imagine that the N-Ball represents all there is to know about a topic. You begin in the center of the N-Ball and in order to learn more you have to walk to the outer edge of the N-Ball. Also imagine that you're only able to see what's right in front of your face. In the beginning at the center there is very little volume to look at. It will appear to be easy to understand what's going on. But as you walk to the edge of the N-Ball, the amount of volume that you're able to see increases. When you get right to the edge of a very high dimension N-Ball you will notice that you only know half of what is available to know.
Simple topics are N-Balls with low dimensions. It's easy to "walk" your way to knowing half of everything there is to know. Complex topics are N-Balls with high dimensions. Programming (and by extension software engineering) is really high dimensional. The more you learn the more you notice there is to learn. When you walk to the edge of what seems possible you find yourself swimming in a sea that dwarfs you. But in the beginning it looks like there isn't really all that much going on.
I've been thinking a little more about how the space of software engineering knowledge might be structured though, and one thing I'm betting is that it wouldn't be an N-ball, but instead some complex sponge looking thing (because the extent of software engineering knowledge isn't equidistant in all directions/aspects). Ordinarily I'd think the N-ball would be fine to use as an idealization, but since the hypercube behaves so differently, I bet the idealization would end up changing the character of the situation.
I'm also trying to consider what the analogy of a plane would be in software engineering knowledge. Let's say it's on two dimensions: X and Y; and let's say X is knowledge relating to text editor usage, and Y is knowledge about unit testing. It seems like the XY plane is mostly full of empty space, since most facts (single points) from either field are unrelated to the other. So, if we have a pure text editor fact X=5,Y=0 —what legitimate fact might exist at X=5,Y=1? It would have to be some single, constant piece of text editor knowledge which meaningfully combines with a unit testing fact. There may be some points in this plane on the line X=5 which are valid, but since all unit testing facts don't have a meaningful connection to text editing, there will be gaps.
Additionally, it seems like the way you'd navigate the space would be different than walking a single contiguous path. Some of our knowledge is map-like and can help give at least sketchy knowledge of the boundaries of the field without walking to them step by step. And some facts are dependent on knowing other first so that you have 'pass through' in a particular order, but a lot of the facts about a single subject are still unordered, so you would be doing a lot of teleporting.
Just for amusement, here's another idea for an alternate way of spatially structuring knowledge: each general principle is some high dimensional object of its own; each axis corresponds to a parameter to the general principle. So you have a general structures like: ProgrammingLanguage(syntax, semantics, runtime, standard_library) —each of the parameters is a different axis, and you always get a meaningful ProgrammingLanguage back if you change to a different position on some axis (seems like this structure is recursive though since each of the parameters could be a general principle itself, so I guess these objects are nested?).
When you learn things you are jumping around between these non-intersecting objects (which are even in differently structured spaces) without realizing, until you inductively discover these general principles/categories. Additionally, the speed with which you move around inside an object increases dramatically once you acquire knowledge of its general structure (since learning new facts which are just different instantiations of already known general facts is easier for us).
I wonder if there is some kind of 'meta-space' that would be useful for describing the relationships between all these objects which exist in spaces of different dimensions. Also not sure about the geometric significance of the 'general principle objects' being recursive...
Edit: seems like the recursive/nested 'sub-objects' would just be lower dimensional slices of the whole higher dimensional 'general principle object'...
Yeah, I like the way you're going. I haven't spent much time thinking about how to fit in software engineering, but I did try to think about how to structure programming issues (which is probably the first step if you want to eventually get to a software engineering).
It's missing a conclusion / wrapping it all up (which hopefully I can get to soonish), but is otherwise mostly done. [I should probably augment it with motivations and examples.] I'm not sure that this is the definitive answer, but more like this is my attempt to structure some of the things I've been encountering.
EDIT: Sorry about the length. I'm not sure there's a good way to shorten these sorts of ideas.
Interesting! I'm on "Problem Analysis: High Dimensional Spaces" so far. I'll probably just leave a comment there if I end up with something to say since we'll probably drift too far off topic if continuing here ;)
Edit: I finished but couldn't find a way of leaving a comment on your blog. I thought it was an interesting read—but yep, definitely needs that conclusion! Hard to say much without that. Is your goal to use the ideas to create a new metric for how difficult a code base is to work with?
In the paper, ability is positively correlated with perceived ability. So we would need some other effect to explain people saying they got worse over time, or people's perceived ability decreasing over a time period in which their ability improved.
To use your analogy, when I start exploring outside the valley, I think to myself - "wow, a year ago I only knew this valley. Now I'm getting to know this new area! I've come a long way and I feel great I've made progress!".
I tend to focus on the fact I am constantly expanding my knowledge, instead of worrying about all the stuff I don't know yet.
I still consider myself a generalist, however. I can't say I'm an expert in any one area. Maybe that's why I feel the way I do.
This certainly applies to programming but I've felt it too in my Aerospace career. I used to feel like the smartest guy, I always knew how to do things or learnt them really fast, and I couldn't imagine where the horizon was. Now, the more I see, the further I feel the horizon is, and it's pretty frustrating as it makes me feel less intelligent.
Your comparison helped me to see things a bit clearer and to be a bit more motivated.
It's not always that way though. We often suffer as if we have unique problems, but through house repairs (got a nice long chat with a couple GCs) and extracurriculars, I find that a lot of my problems look a good bit like other people's problems. I think the surface area thing is overblown.
There are always stories about innovators who simply apply established solutions from problem space A to problem space B and everyone is amazed. The surface area problem certainly exists for the entire domain of human knowledge, but domains pretty much exist to wrangle problems that are manageable in the first place, even if it makes you myopic in the process.
I get frustrated in interviews because everyone is just so convinced that the latest utility module is so new and unique and it's really just a retread of five other things. It might have some interesting semantics that change how you use it, but even that isn't always the case.
Plus ça change, plus c'est la même chose.
I've just started telling people that 'how' ages faster than 'why'.
It is more like traversing a tree. The more you learn (the deeper you go) the more branches you can explore which leads to the conclusion that the more you know the more you realize how much you still don't know.
I spent a couple years figuring out a certain problem. When I was done, it took me six months to be able to write up a blog series about it. I don't think autism has anything to do with it. Some problems are really hard to communicate.
I'm 30% through writing a 10-20K word blog series about something that I've been working on for the last 6-8 years. I've probably written ~5K words already on blogs unrelated to my series where I'm kicking around the ideas that went into my project. Finally, the project probably isn't that interesting unless you've encountered a very specific type of problem before. Which means I probably should put in another 5-10K words to market it.
Sometimes it's not about confidence. Sometimes it's about complex social dynamics and how people react to suddenly being thrown into the deep end of a domain that's completely new to them.
"Tell me about a technical challenge that won't make me feel inadequate or be difficult to follow. Don't make it too simple though because then I'll think you're an idiot."
Apparently washing your hands also causes you to be more lenient.
So AI probably shouldn't be used for sentencing, but that's more to do with all the stakeholders being clueless about the technology. The people asking for it, paying for it, using it, and building it (hey I can just throw some packages together in R right?) don't know what they're doing and are using it to significantly impact the lives of others.
On the other hand, pretending an arbitrary Judge / Jury / sentencing guidelines also don't form a dynamic system with not well understood effects that's equivalent to random AI in terms of output doesn't exactly help anyone either.
At the end of the day you need people who are honorable who you can trust to do the right thing (as much as it sounds like a saturday morning cartoon).
Joel on Software Story about Bill Gates: https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
Bonus Bill Gates Pancake Problem story: http://www.npr.org/templates/story/story.php?storyId=9223678...