5 ms·

I think this is true for just learning the language alone. But for the type of productivity the grandparent post is talking about the language ecosystem can be

• throwaway34241 8y ago
  And for a specific example of the sort of ecosystem stuff I am talking about, to save/load some local data on iOS you have some API options: Core Data SQLite NSArchiver NSKeyedArchiver NSUserDefaults JSON Property lists Protocol buffers stdio NSData memory-mapped files Realm This is without getting into anything too obscure. This list is probably also out of date.
• klibertp 8y ago
  > But for the type of productivity the grandparent post is talking about the language ecosystem can be a bigger challenge, at least for me. My claim was that: > learning a new language - and yes, in-depth, including idioms, stdlib, some external libraries, maybe some framework (if needed), and also some facts about the implementation and its inner workings[1] - takes a week at most I also tried to define "learning in-depth" in another post: > To me, 'knowing in depth' (as a language user) means that no matter the question, you know where to [quickly] search for the answers. There's no need to remember the answers themselves, although it kind of happens naturally with repetition anyway. > On the other hand, it's also important to know which questions are not worth answering. [ie. what to ignore while learning] And I stand by it: I believe that there's no need to memorize too many details to be productive, you just need to be able to quickly and accurately find the relevant details, no matter which details are they. Various docs indexes and viewers, your IDE features, cheatsheets printed on a wall - all of that can help you if you forget a bit of syntax or a signature of a function. There's nothing, other than just reading a book or two, to help you if you don't understand a crucial concept in a language or the architecture of the library/framework. Also, all these concepts are reused all over the place. For example: "Io is a purely-object-oriented language with prototypal inheritance which allows objects to have many parents." Each word here has a meaning, and that meaning is (well, mostly) standard across most programming languages. With this description, if you know all the words, you just learned 3/4 of all there is to Io OO. Another example: "Dylan is a purely-object-oriented language which is class-based, allows multiple inheritance, and also decouples methods from classes by relying on generic functions, which use multiple dispatch - similar to CLOS." This one is longer, but it's still a single sentence, which conveys most (or if you're familiar with CLOS - all) of the characteristics of Dylan's object system. Sure, there are obviously more features in Dylan that you need to know before you start coding... but they are all defined with a single sentence. It takes half an hour to go through them all, and - again, if you know the exact meaning of each word - at this point you know more about the language than a beginner programmer would learn in a year or two. > I mean knowing many of the exact APIs by heart I was like this in the past, so I know what you're talking about. Unfortunately, my epilepsy makes my memory reset significantly from time to time - I can't do it, or at least not for long. It caused a loss of productivity for a bit, but it went back up when I started using well-configured tools. This is why my definitions of "knowing in-depth" above are what they are - I live them, for better or worse. > (without much looking things up) even if it involved working with images, network requests, JSON, file IO, string processing, dates/scheduling, collections, serialization, menus, windows, controls, input, drawing, sound, etc. Yes, that's what tends to happen with repetition - unless your memory is impaired in some way - you just remember things. There's nothing else than repetition that can get you to that point, which also means you "only" need repetition to get there. In other words, it happens naturally with time, provided you consistently work with the given tech stack, and that you use it for the various things you mention. But again: good tooling makes the rote memorization mostly unnecessary, and I really don't see many benefits of keeping all the idiosyncrasies of the whole stack in your head. It's completely different story if you code in Notepad without Internet access, though. Further, all the things you mention are implemented in all general-purpose languages. Moreover, most implementations look really similar. In almost all languages "network requests" are built upon sockets - an OS-level mechanism. Images are more tricky because of decoding/encoding (which is handled almost everywhere by simply linking to libjpeg & co.), but after that they're 3-dimensional int array/vector/list/what-have-you (yes, there are other representations - and yes, they are all implemented across most PLs and have very similar characteristics everywhere). "file IO", too, is based upon OS-provided streams, or a crippled reimplementation thereof. It's the same everywhere. "collections" are almost language-agnostic: the names and interfaces may (slightly) differ, but the underlying data structures are the same everywhere. "input", "windows", "controls", "drawing" are event-based everywhere, and almost all languages have bindings to all the GUI frameworks. You can write GTK+ app in Python just as well as in OCaml or C# (even though GTK itself is C (I think?)) - and you'll get the same names and signatures, even. You'll see for yourself in the decades to come - you're likely to switch the stack at least a few times by the time you retire. You'll see that most divisions in programming are illusions and - quite simply - matters of taste/personal preference, while in reality the differences between the popular languages, stacks, framework and systems are miniscule. > Another big thing was when there are multiple ways do the same thing, having done it both ways and having direct experience of why one choice will likely be more effective in general or for a particular project. This can apply to choosing libraries/frameworks or app architectural decisions. These are mostly language-neutral - the exact same considerations apply when deciding on library/framework or approach in every single language. > I noticed I missed this level of familiarity quite a lot when I switched to a different ecosystem later. Maybe this is worse for native UI development because of the large API surfaces. But I found needing to consult the documentation again to be a lot slower. It could be because of lack of proper helpers in your editor etc., but either way: if you stick with the new stack, you'll learn it naturally with time. You'll forget some of the previous stack (although I'm frequently surprised how I can recall specific quirks in technologies from 20 years ago.), which is also natural. Memory just seems to work this way. It'll take a few months to remember all the relevant details - less if the new tech is similar to something you already know.
  • throwaway34241 8y ago
    I'm not really disagreeing that it's possible to be productive without memorizing all that (and I've since moved on to other technologies myself). Also I'm not a vim holdout, I use JetBrains IDEs with all the bells and whistles and use refactoring and keyboard shortcuts etc. But I feel like I was substantially more productive after spending a (relatively) long time on the same stack. So I'm just providing another individual data point that probably more closely matches dxbydt's experience. Those sort of details I learned from extended use weren't really important for understanding things conceptually. But of course actually implementing something involves going through all the minor details and making lots of small choices. Being able to just breeze through that was really nice. To use your example of a network request: on iOS it may be true the API is built on top of sockets or kqueue or whatever (I believe they've moved to user-space networking now but I don't really keep up). But you could use the toolkit APIs blocking on a background thread, or integrated with the main event loop with a delegate object, or on the event loop with a callback block. There's trade-offs to different ways of doing it (especially on a team project): some ways are more verbose, some introduce more thread-safety risk, using blocks everywhere may increase the chance that someone generates a memory leak through cyclic references, processing large requests could be more performant on older phones on a background thread, some patterns make it easy to cancel the request, etc. I don't really miss iOS development. But I do miss the ability to go through all those details/trade-offs as quickly, and I kind of want stick with one thing long enough to develop that again. Especially because as you observe many of the underlying concepts are the same anyway (especially among the popular languages that are the practical choices for most projects because of ecosystem/tooling concerns). To extend dxbydt's analogy I'd rather focus on the dish (problem-domain) than the cooking instruments.
    • klibertp 8y ago
      > But I feel like I was substantially more productive after spending a (relatively) long time on the same stack. That's obvious, although the "substantially" part is a bit vague. But it's still obviously true - you will be slower if you need to check the docs often, it's a given. But: > I kind of want stick with one thing long enough to develop that again. It should take just a few months at most. You'll get there much faster than you (I assume, sorry if I'm wrong) expect. :-) Or is it that you're already many months after the switch, and you still feel that you're checking the docs very often and it slows you down? Maybe there's something wrong with the docs, then? Otherwise, you should probably try learning in a more structured manner, like reading a book or doing MOOC. > But you could use the toolkit APIs blocking on a background thread, or integrated with the main event loop with a delegate object, or on the event loop with a callback block. Exactly the same options are present in every general-purpose language. There are quirks, like Python and threading or JS and event-loop, but you get the choice of blocking/non-blocking, and later if the non-blocking is based on threads and synchronization or on an event loop (or coroutines, green threads, CSP, Actors, etc.) The only thing that changes is nomenclature, which for some reason language developers like to reinvent all the time. > some ways are more verbose, some introduce more thread-safety risk, using blocks everywhere may increase the chance that someone generates a memory leak through cyclic references, processing large requests could be more performant on older phones on a background thread, some patterns make it easy to cancel the request, etc. Ok, some of these are indeed specific to a given platform and have no direct equivalent in (as many) other languages and platforms. Yes, you need to learn those - as there's no equivalent in other languages and stacks, you have no choice but to learn, no previous knowledge will help you with them. However, these tend to be higher-level concerns, where understanding the concept is still more important than memorizing all the relevant details. You write: "some ways are more verbose", which is obviously true, but IMO it's more important here to understand what "verbosity" is, what trade-offs it presents, and what is the "correct" level of verbosity for the task. Knowing this, finding the solution with the right amount of verbosity is as simple as opening a bunch of libraries' GitHub pages and quickly glancing on the code examples there. --- All in all, I'm not disagreeing with you at all. You're right that remembering a lot of details makes you faster. You're right that there are considerations unique to the stack of language. What I'm saying is it's not hard to remember all the essential details: you only need spaced repetition, which happens naturally as you work. Further, while unique features for a lang or stack exist, they are very rare, and it's not hard to learn them (exactly because they're so different than the rest, which makes them stand out). All the other - non-unique - features and consideration form a large pool of concepts which are frequently reused across many (or most, depending on the feature) languages and stacks. Internalizing this pool of concepts lets you effortlessly switch stacks and languages; and while you're right that the productivity will drop after the switch, I assert that with a bit of effort it'll get back to normal levels after a short time - just a few months (for the real mastery it would take longer, of course, but that's true always and for every kind of work). Anyway - thanks for the discussion, I enjoyed it very much, thank you. I hope it wasn't too boring on your side :-)