1. 3

    I’m serving as Tech Lead on a project for the first time, and this comparison resonated with me!

    1. 1

      TLDR: “three times faster” doesn’t mean what you think it means

      1. 4

        Counterpoint: I, another front-end developer who’s exhausted by the complicated tech stack at $dayjob, put together a JS-only side project that doesn’t use SCSS or TypeScript or other bells-and-whistles. I found that the power of JS within the client itself is plenty powerful for many things which were previously handled by a backend (caveat: it’s not doing any Real Number-Crunching).

        1. 3

          Why calculate something once at build time when you can waste user cpu cycles doing it every time somebody looks at the site?

          1. 2

            I’m not sure what’s your point. Autogenerated CSS will force the client to waste CPU cycles reading through dozens auto-prefixed settings it doesn’t need and hasn’t needed in a decade. In any case I’m still to see CSS have any real performance impact.

        1. 10

          I feel like a jerk saying this… but why do we think software should be “done”? We don’t seem to harbor the same illusion about other business practices. If something in our environment renders any other business practice ineffective or obsolete, we alter the practice and for the most part don’t whine about how onerous that is.

          Maybe the problem is that we’re looking at software as if it were a thing instead of a codified and automated set of processes and procedures. We should stop that, because that expectation is making it harder for us to allocate our resources and react to changes in our environment.

          I don’t think I”m being a jerk or a curmudgeon right now, but I would concede the point if someone told me I sound like one.

          1. 5

            If something in our environment renders any other business practice ineffective or obsolete, we alter the practice and for the most part don’t whine about how onerous that is.

            This is incorrect–examples being SAP, the MPAA/RIAA and abuse of copyright, or the use of DUNS numbers, or any of another dozen things. Whining is in fact so common that there is an entire industry for it: lobbying.

            but why do we think software should be “done”?

            Because a program is ultimately math, and math shouldn’t change. Software is ultimately an artifact made of information, and as such should still be usable well after the artificers have passed–provided we still can decode the information.

            1. 5

              Whining is in fact so common that there is an entire industry for it: lobbying.

              Good point. I feel like the kind of whining I hear about software is qualitatively different in a way that I have a hard time describing right now, but you’re exactly right here.

              Because a program is ultimately math, and math shouldn’t change.

              Eehhhhh… I’d argue vigorously that a program is ultimately applied math. While the math itself shouldn’t change, the application (and the wisdom of said application) differs greatly depending on the environment. It lets us use math to automate the application of business rules, often at much lower cost or larger scale than we could without its assistance. Automating the application of the math lets us screw up faster and bigger if an assumption underlying the correctness of that application turns out to be wrong.

              Maybe it’s that error amplification alongside the notion that math shouldn’t change, that makes the need to maintain software so surprising for so many.

              1. 8

                Because a program is ultimately math, and math shouldn’t change

                This has to be the dumbest thing I’ve read in a long time. Programs are not math, they are instructions. Maths exist to describe how reality works. Programs exist for the exact opposite purpose, which is to effect change in reality.

                1. 2

                  I would suggest friendlysock means something like a program is f(x), and always returns the same output for some parameters x. To me, at least, software development is about deriving the correct function for some set of parameters, which is a definite point of completeness.

                  1. 2

                    This is only true for pure functional programming languages, which are themselves emulated on Von Neumann architecture with an “instruction set” that has all kinds of side effects. So in a practical sense, Computer Software and Math are not the same thing, and we have yet to build a true functional machine.

                    1. 2

                      That’s not the case. Surely you can think of how any program, for identical inputs (including environment etc) returns the same (correct) output each time

                      1. 4

                        For any inter-networked system, saying something like “assume completely identical inputs, including the environment” feels quite a bit like saying “assume a frictionless and massless pulley.”

                        I’m not dismissing the usefulness of making either assumption as a reasoning tool, but both require assuming something you know to be untrue, and betting that the discrepancy doesn’t matter to your problem.

                        1. 2

                          This makes sense to me if one considers these as additional program inputs:

                          • the current date/time
                          • the version of the database driver
                          • the number of users simultaneously using the system
                          • the time zone which the current user is in
                          • the current user’s internal ID, or name, or settings, or browser cookies, or…
                          • etc
                2. 2

                  I see what you mean, but other feats of engineering are “done” at some point, and go into a much lower-maintenance mode. Once a bridge is built, it is monitored for repairs, but the construction company doesn’t sit on the bridge and constantly “iterate” on its design.

                  1. 4

                    I think part of the problem here is how different software engineering is from other engineering disciplines. The vast bulk of software products aren’t built with the same kind of rigor that goes into building a bridge. There are elements of mathematics and the like, but once business and legal requirements get involved the discipline starts to have too much in common with things like law. The target moves a lot faster than the transition from e.g. bridges for horse-drawn carts to bridges for large trucks. On top of that, it gets a lot harder to develop the kinds of techniques, tests, and so on that enable designing a bridge without having to derive everything from first principles.

                    I’m not an engineer though, so happy to be corrected. I could just be romanticizing the world of civil engineering etc.

                    1. 4

                      Software engineering is really not that unique. There are some things we have that are different, like incredibly fast feedback loops and a lack of physical uncertainty, but overall we share a lot more in common with other engineering disciplines than we have that’s different.

                      1. 1

                        I’ll trust you on that, then. I think the lack of rigor is true, but maybe there’s no good, principled reason why software engineering hasn’t caught up in that regard.

                    2. 4

                      Chemical engineers are constantly tweaking their process flows. Chemical engineering is never done.

                      1. 2

                        Not only that, but when it comes time to re-paint, you don’t have to rebuild the entire bridge because the company that built the coffee pots in the engineering room went out of business.

                        1. 5

                          On the other hand, when you get a new piece of equipment for the oil rig that’s too tall for the floor, you have to raise a small section of the ceiling by one foot, and then everything on the floor above has to be reconfigured around that, and then you have to live with the oil rig having a raised section of the floor forever.

                          Source: an oil and gas engineer I interviewed

                        2. 2

                          but other feats of engineering are “done” at some point, and go into a much lower-maintenance mode. Once a bridge is built, it is monitored for repairs, but the construction company doesn’t sit on the bridge and constantly “iterate” on its design.

                          A bridge is also vastly less complex, with much simpler requirements, and operates on much simpler and better-understood engineering principles.

                          And bridges can run in to trouble too if requirements change; quite a few bridges were built with just cars in mind, and retrofitting them with pedestrian/bike lanes doesn’t always work all that well.

                          Also maintenance costs may be higher than you’d expect; the Clifton bridge in Bristol for example, completed in 1864, costs about £1 million/year in maintenance, which excludes £8 million in various structural repairs that need to be done.

                          1. 1

                            A bridge is also vastly less complex, with much simpler requirements, and operates on much simpler and better-understood engineering principles.

                            Bridges are much more complicated than you think.

                      1. 2

                        I’m in the process of learning emacs after using vim for roughly 15 years; give or take a couple of years. These articles are really helpful.

                        I’ve been going through his .emacs as well on GitHub. Just like with vim, I wouldn’t recommend just copying everything he did, but I’ve found some nice bits here and there.

                        1. 2

                          Any advice for vimmers looking to be a little more comfortable in Emacs? I tried Spacemacs for a little while but got frustrated debugging my own setup / configuration and went back…

                          1. 4

                            I’m probably not the right person to ask this question, but I will give you my advice anyway.

                            Some caveats
                            First, my vim-fu is pretty weak if I’m honest. I know I’ve been using it for over a decade, but even still I’m not super efficient and I know I do a lot of things poorly. Habits die hard though; especially the bad ones. Second, this is my second attempt to learn emacs. The first failed because I wasn’t serious. This attempt is going much better so far, but I’m only a couple of weeks into it.

                            My advice (in no particular order)

                            • Use vanilla emacs. I know there are a bunch of different pre-made emacs out there. They’re shiny and promise lots of great things. I’m not going to say those are bad, they’re not, but they also prevent you, IMO, from learning a lot of basics.
                            • It’s okay to look at other people’s configurations, but don’t blindly copy. If you don’t know what it does, forget it. My general rule of thumb is if I can’t write a comment explaining what it is and/or how it works, I don’t borrow it. I made this mistake with vim years ago, and while it didn’t hinder me, it very much didn’t help me.
                            • I’m not the kind of guy who reads tech books. They just don’t hold my interest 9 times out of 10. I am fighting that as hard as I can with emacs and it’s paying off for me. So far I’m really enjoying Mastering Emacs. I would be curious if anyone else has recommendations here.
                            • My biggest problem so far is movement. After all this time hjkl is pretty hardwired into my hands. So learning how to efficiently move around has been a real struggle. I highly recommend you take the time to really get used to this though. This is the number 1 thing you need to learn bar none.
                            • If you don’t already know it, learn, or at least get comfortable reading, emacs lisp. I don’t know it, but the more I use emacs, and the more comfortable I get reading it, the easier learning the rest of emacs has been.
                            • Resist the urge to go back to vim. You’ll never truly learn emacs if you don’t use it. If you keep vim around as a crutch you’ve already failed IMO.
                            1. 3

                              Use vanilla emacs.

                              Absolutely seconded 100%. Do not start off by installing a lot of different packages and reading too many config setups. It will take you in the wrong direction.

                              I’ve been using Emacs for nearly 25 years and about 10 years ago I set about re-learning it because I realized I didn’t use it very effectively. What worked well for me was ignoring nearly all the extensions and getting to know the builtin functionality. I avoid installing packages as much as I can. That said, Emacs is deficient in three main categories to me: project navigation (an unbelievable oversight, really), completion interface (the default is absolutely awful), and help UX.

                              Emacs seems to be moving to use project as the default project interface, so you may want to install that. It’s not bad, even for large projects. As for completion, there is ido (inteactive do) that comes with Emacs and is okay, but the other choices are helm and ivy. My personal preference is for helm, but you may want to try ido first.

                              You should install which-key. It’s just too useful, even for veterans. You may also want use-package, although I do not use it so I can’t say how complicated it is to setup. It seems to be quite popular, though.

                              After that, limit yourself to a colour theme that you like and any language major modes you need.

                              The rest of your advice is all good, too.

                        1. 14

                          Given the same task, two developers often come up with solutions that differ in an order of magnitude in size, complexity, dependency count and resource consumption.

                          I have witnessed that over and over.

                          1. 4

                            I code for approximately an hour a day after my kids have gone to bed. (I’m a manager these days, so my job doesn’t involve day-to-day coding.) During that time I can be shockingly productive, cranking out a solid chunk of performant, safe, well-factored code in an amount of time that would have been an extended coffee break back in my “code-slinging” days.

                            So, have I discovered the Nirvana of 10x-ness? Could I jump back in to coding and be massively more effective than I was in my 20s or the portion of my 30s where I still considered myself a professional software developer?

                            No, and no. I’ve just found a comfortable niche where the problem domain, freedom to choose the tools I want, and lack of 50 competing demands on my time let me go head-down and code and consider only that time when I measure my production.

                            In my experience there’s a very strong correlation between “10x coders” and people who are given the space to work, control over their tools, and trust to architect systems as they choose.

                            Whether they earn that because of demonstrated, sustained performance or learn to do it after thrashing around in the deep end for a few years is kind of a chicken-and-egg problem, but studies and surveys (sorry to not have links handy, I’m typing this on my phone) show consistently that developers are happiest and feel most effective when offered those freedoms.

                            1. 3

                              In what kind of setting do two developers have to produce the exact same thing at the same time, without talking to eachother about it? And is it always the case that developer A produces something that’s objectively 10x better than developer B, or are the roles sometimes reversed. For instance, does it depend on experience in a certain niche?

                              1. 4

                                That happens all the time when discussing the scope of new projects.

                                A recent example I have in mind is, the employer wants a place to collect and analyze data that is being generated by their product.

                                • Developer A’s proposal was to build a full data warehouse with SMT, CMT, ETL, Timeseries DB, …
                                • Developer B’s proposal was to ingest the data into an S3 bucket in a regular format, and then plug whatever DB we need when we need it.

                                Without judging which proposal is the most appropriate, which varies on the context. It’s quite obvious to me that the first proposal is at least 10x bigger.

                                1. 2

                                  One example are test-work situations. Multiple developers who are considered for longer term projects do the same small project.

                                  I did not say objectively better. But 10x difference in size, complexity, dependency count and resource consumption. Personally, I think this leads to even more then 10x slower progress when the code evolves. But opinions on this differ widely.

                                  1. 2

                                    But 10x difference in size, complexity, dependency count and resource consumption.

                                    I would probably call that objectively better. But maybe that’s my own biased thinking.

                                    For instance, did the developers know that optimizing for these things was a goal? Did the other developers produce something in shorter time? Were they equally experienced?

                                    1. 2

                                      did the developers know that optimizing for these things was a goal

                                      No, because development is a tradeoff between so many goals that stating something like “size is important” would lead to absurd constructs. In my experience, every developer has their style and you cannot change it much. For example a dev who prefers to think in “business objects” over “sql queries” will struggle if you force them to change that type of thinking. Even if their approach creates code that needs ten million times more resources.

                                      Did the other developers produce something in shorter time?

                                      I would say usually coding time is shorter for the smaller, leaner, less resource hungry solutions with less dependencies.

                                      Were they equally experienced?

                                      In my experience there is a strong correlation betwen experience and the type of solutions a developer comes up with. And the time they need to implement them. More experienced developers tend to come up with leaner solutions and need less time to implement them.

                                      1. 2

                                        I would like to think that my style has some flexibility to it, though I’ve definitely landed on the SQL queries side of that divide in the past.

                                        Of course, everyone struggles with a new way of thinking at first. Which is why, for me at least, I seek out new ways of thinking, so I can get the struggle done with.

                                        1. 2

                                          In my experience there is a strong correlation betwen experience and the type of solutions a developer comes up with. And the time they need to implement them.

                                          This would seem to fit well with other types of jobs. I think the myth is that there are people who are “magically” 10x better somehow, which makes very little sense to me.

                                          1. 5

                                            It’s not that they’re magically better. There are practices you can follow that get you those results, but people just don’t seem interested in following them:

                                            • Understand the business reasoning behind the project…look for ways of exploiting that knowledge to minimize the amount of work done.
                                            • Less code is always easier to debug…or if you can’t debug, throw out and replace.
                                            • Clearly defined project goals and constraints and milestones make development fast and visible.
                                            • Throwaway prototypes are faster than big projects and teach you more–and may be good enough for the business.
                                            • Understanding, deeply, the tools you use and the basic principles of computer science and engineering help you prune solution spaces a lot better.
                                            • Identify whether or not the framework/third-party app is actually delivering value over just implementing a smaller bespoke solution yourself. Color picker? Almost certainly. Database extension? Probably. Container orchestration for a static blog? Probably not.
                                            • Pseudocode and stepwise refinement of the solution to a problem. If you can’t explain something with bullet points, you don’t understand it, and if you don’t understand it, you’re slow.

                                            There are more I think, but that’s a start.

                                            Somewhat grumpily: there may not be 10x software engineers, but there sure as hell are 10x embedded AWS salesfolk.

                                            1. 2

                                              I think your third point is the most important one. Perhaps a 10x developer is gifted at recognizing the business priorities even when the Product folks don’t see how much size/complexity matters?

                                          2. 1

                                            I would say usually coding time is shorter for the smaller, leaner, less resource hungry solutions with less dependencies

                                            I’m not sure I agree, here. Maybe if you take “coding time” (as opposed to “dev time”) very strictly, but even then…

                                            My anecdata includes a bunch of hackathon projects that, when polished up for production, amounted to far less code. Reducing duplication, refining design for smaller code, replacing bespoke with off-the-shelf libraries, etc, all benefit from taking time.

                                    1. 5

                                      AOL keyword: Duhem-Quine

                                      1. 1

                                        Thanks for this!

                                      1. 3

                                        What languages do you know now? Are there any you don’t know that you are particularly interested in learning?

                                        Any idea what kind of application you want to get started with? You could start building web backends, or CLI apps, or GUI apps. From the project list you wrote, it sounds like you’re more interested in CLI apps. Or at least things that don’t need to bother with high-level web and GUI interfaces. I don’t know what you’ve done so far, but small CLI helper apps are a decent place to start for learning new languages and frameworks.

                                        1. 2

                                          I know JS, python, some ruby. A long time ago I had a lot of experience writing C. I’m very interested in Rust, moderately interested in Go, and I’m also thinking about just diving back into C.

                                          Thanks for the ideas! Yeah perhaps a CLI would be a good start. I was thinking about writing something with a terminal dashboard. That just sounds like a lot of fun. Thats part of the reason why the htop clone seems like a great direction. Make some system calls to get information and just display it.

                                          1. 2

                                            Look into Elixir or Erlang if you’re interested in distributed systems!

                                        1. 8

                                          This is interesting, because it also comes down to how the reviewer reviews code. If the reviewer just looks at the changes in a PR as a whole, a lot of the value in careful commits becomes about the historical record than ease of reviewing. Still valuable, but there’s something to be said for learning to review code.

                                          1. 4

                                            That was one of my motivations to write this in the first place. Now I can just send a link to the ones on my team.

                                            I agree that how we write history is important on its own merits. You commit once, but it will be read a lot more. Both during review, but also as part of later debugging.

                                            1. 4

                                              It’s something I try and stick to even if it takes a bit of time. git add -p <filename> is invaluable for this too.

                                              When I see people reviewing things as a giant chunk of code, I feel that sometimes it comes from a history of commits not being very useful. When commits are more noise than signal, I don’t blame people for not looking at them.

                                              Another thing is familiarity with rebasing. I think there’s a lot of talk about rebasing being difficult, which means people don’t attempt it because they’re scared to lose work, which is entirely reasonable, but we need to talk more about recovery techniques like the reflog, etc.

                                              1. 3

                                                git add -p <filename> is invaluable for this too.

                                                Magit makes it painless.

                                                1. 2

                                                  The simplest being to make a test branch on which to test. If all goes well, you can reset you branch to the test branch’s commit and proceed from there.

                                                  I don’t know if people understand the lightness and ease of branches, but it’s simpler than cherry-picking from reflog.

                                                  Git is excellent in how hard it is to truly fsck up, and people should learn these techniques and not consider them magic tricks.

                                                2. 1

                                                  Your motivation resonates with me; I’ve been writing something partially for my coworkers about my thoughts on commits and reviews, plus explaining some of my workflows… Part one is here: https://medium.com/p/c0966a562b10

                                              1. 1

                                                What’s front end engineering? Where is the line between design and engineering?

                                                1. 1

                                                  I don’t design anything, and I also don’t work on backend systems*. If your job involves e.g. turning mockups and API calls into a feature in a browser, I’d say you’re doing frontend engineering.

                                                  * … for the most part

                                                  1. 1

                                                    oh right, so you’re talking the specific layer between a UI/UX/graphic design person who is not doing any coding, and the immediate next layer of a front end programmer who is not doing any design, but taking ready-for-web graphics and doing lots of front-end-framework, javascript, etc. stuff to connect to the first layer of business logic?

                                                1. 7

                                                  Erlang making this hard is the biggest reason I didn’t continue to learn Erlang. I don’t understand how the “just crash” philosophy and actually returning useful error messages are supposed to intersect. I have just assumed since Erlang was made for telecom infrastructure, where I assume it’s reasonable to drop bad input rather than return errors, it just doesn’t have an ergonomic way to return errors. At least based on my experience with switches and routers, which tend to drop bad packets with only a few exceptions.

                                                  I’d be happy to learn I’m wrong though.

                                                  On the flip side, Swift guard statements make this pattern delightfully easy. In particular, I like that you can do a guard let and the assignment will occur in the outer scope, as opposed to if let which makes the binding local to the body to the if.

                                                  For example:

                                                  guard let value = possiblyReturnsNil() else {
                                                      // handle error
                                                  doSomething(value) // valid

                                                  Notice the else after the guarded expression, that hints how the scoping works. So guard let isn’t quite the same as what you might expect unless let / if not let to be. Aces.

                                                  1. 5

                                                    The way you tackle these things in Erlang is by tagging the return values. If you really, really need to return early, you can always erlang:throw/1, which does pretty much what return does in javascript.

                                                    Admittedly, you can end up with multiply-indented case statements in Erlang, too, but there are ways of dealing with that (depending on your style) that don’t involve non-local returns.

                                                    1. 2

                                                      I’m familiar with return tagging. The nested case statements are what bother me. I appreciate the link but that strategy is so over the top and verbose that I absolutely don’t want to do anything like it for generalized input guarding. Throw might be what I want but it seems wrong, maybe because of how I’m used to using exceptions in other languages, maybe not. Like what if your caller doesn’t expect you to throw, and it isn’t your code? You’d have to wrap everything in a catching function. It feels like way more work than it should be just to have access to early returns.

                                                      1. 5

                                                        I use the following construct in my code:

                                                        -spec fold(t(A,B), [fun((A) -> t(A,B))]) -> t(A,B).
                                                        fold(R, []) when ?is_result(R) -> R;
                                                        fold({error,E}, _) -> {error, E};
                                                        fold({ok, V0}, [Fun|Rest]) -> fold(Fun(V0), Rest);
                                                        fold(Other, []) -> error({badarg, Other});
                                                        fold(_, Other) -> error({badarg, Other}).

                                                        If you squint, it’s an early-exit chain of >>= (monadic binds) on the squintly-typed Either type.

                                                        Then, you can use the following pattern:

                                                        squinty_either:fold({ok, InitVal}, 
                                                        [fun(V) -> {ok, x(V)} end,  %% x is total and pure
                                                        fun(V) -> 
                                                          case some_pred(V) of   %% case statement inlined, should be sep. fun.
                                                            true -> {ok, z(V)};
                                                            false -> {error, {V, not_valid}}
                                                        fun(V) -> ... ]

                                                        Any fun that returns {error, E} will cause the entire chain to exit with that tuple. OTOH, returns of {ok, V} will pass on the bare V to the next element in the chain. This means you only code for the relevant path. You can then deconstruct the values in function heads to further reduce case-yness.

                                                        Regarding the ‘unknown code crashing your process’ problem: yes, I hear you. There is no foolproof solution to this: sometimes you do have to explicitly try-catch, sometimes your running process doesn’t care and can just crash, because the supervision tree is built in such a way that it doesn’t matter.

                                                        1. 2

                                                          I like this pattern overall, but I still wish it was more ergonomic. I believe the |> operator in Elixir exists to essentially do this?

                                                          1. 2

                                                            Yeah, ergonomics isn’t Erlang’s strong suit. I does help if all your functions have a uniform return type, so you can get by with just referencing them:

                                                            fold({ok, N}, [ fun add_one/1, fun add_two/1, fun reject_odd_numbers/1 ]).

                                                            where all the above functions are :: number() -> {ok, number() | {error, any()}

                                                            In Elixir, the |> operator solves half of the issue (chaining), and the with syntax solves the other part of the issue (logic/dispatch based on previous return value). Yet, there is no succinct way of combining them, i.e. implementing something like Haskell’s >>=.

                                                            *edited example function name

                                                            1. 2

                                                              The fold strategy reminds me of pipeline from Joyent’s vasync library. Node has a callback-based runtime that totally eradicates anything resembling a call stack whenever you have to do IO, so using a library that attaches context to function calls makes sense. Dynamically executing functions just to get a syntax you like seems silly though. What about generating macro code into a header?

                                                              1. 1

                                                                It’s been done: https://github.com/rabbitmq/erlando The issue with marco- and parse-transform-based Erlang libraries is that they don’t ‘stick’ in the ecosystem. My guess is that developers are too used to 1:1 mapping of code to bytecode (for reasons of debuggability). Also, parse transforms can be brittle/untestable. Basho’s lager is pretty much the only parse_transform that I’ve seen embraced extensively in the wild.

                                                                From a different angle, there’s nothing dramatically silly about dynamically executing functions in Erlang. There are tons of places all around OTP that do this: see the {Mod,Fun,Args} interfaces to Supervisors and gen_servers, dynamic callbacks in gen_event, mnesia transactions, etc. fun(Blah) -> expressions even get compiled to ‘named’ functions during lambda lifting, and they are very efficient, unless of course huge environment captures are involved. Erlang is in fact very introspective and dynamic – I’d go as far as to say that it is almost a lisp, at heart. I’m certain Robert Virding played no small part in making it so.

                                                                1. 1

                                                                  From a different angle, there’s nothing dramatically silly about dynamically executing functions in Erlang.

                                                                  Yes that’s true. I was thinking about it purely from force of habit—I normally use C++. I just traced a performance issue in some code using std::function down to an allocation in libstdc++ that only happens if the function is a lambda with captures. 8 bytes made all the difference. So you can see what I’m used to thinking about. ¯\_(ツ)_/¯

                                                        2. 4

                                                          The nested case statements are what bother me.

                                                          I’ve generally addressed this with two solutions: 1) toss the nested handling into a function call 2) case on a tuple that has everything that can be evaluated in it and case on the dot product of options. 2 obviously only works if you nested cases don’t depend on each other.

                                                          1. 3

                                                            Elixir addresses nested cases with the with macro.

                                                            1. 2

                                                              I should give Elixir a spin, given how much I love Ruby.

                                                            2. 1

                                                              I’ve done the nested handling as function calls. It annoys me because it splits up all the code in a Node.js kind of way. But it’s decently ergonomic as the function names end up as comments for the early exit condition, and I think early exit conditions should be commented unless they’re really truly obvious.

                                                              I haven’t heard of doing a single case over all the inputs before. That’s a fantastic idea! My first thought is I usually order my checks and returns to avoid writing out the Cartesian product of their conditions in if/else statements, so this strategy could be cumbersome. But pattern matching, wildcard _ in particular, should provide opportunities to merge cases. I’ll definitely have to try it out!

                                                              Thinking about it also makes me curious how aggressively Erlang can optimize pattern matching. For example, suppose you have 4 independent options, one of which is expensive to compute, and there is only one valid case. If you just case over all 4 options anyway, will the expensive one only be computed in some cases? Or will all options be fully evaluated and bound before the pattern matching starts? Can Erlang detect some functions have no side effect? Of course you can manually optimize this pretty easily, but I’m still interested in seeing what Erlang can do there.

                                                      1. 1

                                                        Is there a reason one cannot parse a JS string into a simple-ish JavaScript AST object, and vice versa? It seems like if the parser were written in a simple / reasonable way, one could also extend it with a macro system.

                                                        1. 1

                                                          I don’t have any experience with them, but implementations of ASTs for JavaScript exist… https://astexplorer.net/ http://jointjs.com/demos/javascript-ast … also macros! http://sweetjs.org/

                                                        1. 1

                                                          I’ve been alternately impressed and frustrated by Chrome’s ability to set breakpoints in CoffeeScript and/or JSX… Here’s hoping they’ll improve breakpoint setting as well!

                                                          1. 3

                                                            … but the one thing I keep coming back to, that I believe has enduring value in almost all situations, is the audition project:

                                                            The most significant shift we’ve made is requiring every final candidate to work with us for three to eight weeks on a contract basis.

                                                            I don’t doubt it’s effectiveness at generating a realistic work sample, but I can’t imagine ageeing to a multi-week project as part of an interview. Even if I were between jobs, just one of these projects would uncomfortably limit my time for generating competing offers. Maybe I’m an outlier, but I have the feeling this would really shrink the application pool, retraining those who are more desperate or star-struck.

                                                            1. 1

                                                              Shrinking the application pool may be acceptable or even desirable, if they’re telling themselves that they’re eliminating the not-best applicants…

                                                            1. 15

                                                              I would love for this to be an urban fantasy animated film. Google is the villain, building up its wage-fixing cartel, when it is beset by teams of magical unicorns who smash in and rescue the hostage engineers.

                                                              “Muah ha ha, you’ll need Steve Jobs' personal permission to leave my castle! *crash* No! Guards, guards! Curse you, unicorns!”

                                                              1. 4

                                                                and Google is run by literal giants!