321–330 of 418 posts
Almost no one nowadays possess these skills. I we have is node_modules crap and J2EE-like design bullshit.
This like saying that poetry is just words and commas.
But he is just a kid, I know. ;)
Earlier quoted context omitted.
>and you have to read it all to find out what it does. Which isn't a problem, because as long as its all loops'n branches, the code is easy to understand.
Hard disagree. For loops do not have guarantees about in-place mutation; that’s why they require a full read. Anything that starts with a map/filter is guaranteed to only apply to the thing that it is assigned to. That’s more than worth its weight in grey hairs. EDIT: “full read” includes “everywhere else this array is used, which can have far-reaching consequences if it was passed into the containing function by ref…
Another wide-spread syntax feature is for-loops over collections like `for item in list`, again being extremely easy to read and not requiring any assignments. So, accidental in-place mutation is not an issue in practice. But, in-place mutation can be very useful to express logic in an easy to understand way.
Coincidentally my main language does not have any of these features, and in-place mutation is like 0.1% of all my problems. (And notably, memory management is These are all just theoretic problems, what really matters is developer experience. You can write terrible bug-ridden convoluted code in any language, ESPECIALLY with many filters and lambdas and callbacks.
The issue with the functional style is that it becomes harder to see the control flow and run-time characteristics. I'm sure functional style is great to express set operations (like DB queries) but IME they tend to optimize for source code brevity and pessimize for runtime performance.
Earlier quoted context omitted.
> you eventually "give up", and clock your 9–5 writing if+for making a fine living, but erroneously pass that off as a mature This comment sure indicates to me where you most likely are on the curve. In all seriousness, I think this is considerably off the mark. After enough experience you realize that expressivity and convenience are antipatterns and don't actually simplify things but are harbingers of complexity, b…
> Saying it is all ifs and for-loops is completely true. Everything else, all the abstractions and high level features, are just sugar. You could just as well say that ifs and for loops are just sugar for gotos and all programming is just gotos. The reason ifs and for loops are used instead of gotos is that they are very useful abstractions that are easy to reason about and save the programmer lots of mental effort.…
Earlier quoted context omitted.
Programming alone vs programming in a team are very, very different occupations. A lot of what applies to one doesn’t apply to the other. I’m still painfully learning this, after all these years.
Could you elaborate please?
In the first kind, all relevant developers have deep expertise in the system, or build towards having deep expertise. There's an expectation that flexible abstractions will be used, not abused, unless it's one of those scenarios where the use outweighs the abuse. The abstractions are tomato cages, and they're there to support the system as it grows, provide some structure, but not to strangle it.
In the second kind, the default expectation is that a developer will have little to no familiarity with the system, they will be isolated from it as much as possible, and they will be given such a tightly constrained sandbox that they can't break anything outside it. You will write your little plugin, or whatever, get in and out, and you're done.
These can both be useful kinds of systems/codebases in orgs of any size. The first kind of codebase can enable an experienced team to move really fast and be extremely productive. The second kind of system can help lots of different teams of different skill levels jump in and leverage your system with little required knowledge, and thus be productive that way. So there's really no way to say one of these patterns is good or bad.
But in general if you churn in and out a bunch of replaceable cog code monkeys, probably low-paid, the second kind of system just ends up working better. Giant "enterprise" software shops like parent poster aluded to typically end up in this kind of high turnover scenario after enough finance/MBA people have been brought in, hence their bad rap.
That first reply is so funny to me because it hits too close to home https://twitter.com/nice_byte/status/1466940940229046273 The more I do this, the more I gravitate towards the simple things.
New developers write simple but shortsighted code. It gets the job done, but it will be painful to work with in the future. Intermediate developers, bitten by their past mistakes, decide to future proof their work. But they don’t just look one or two steps ahead, rather they try to look five steps ahead and identity problems that do not and may never exist. Consequently, they over-engineer, over-abstract, and over-co…
Watching this right now and all I can think about is Microsoft Bob.
Earlier quoted context omitted.
I started off writing a lot of 68000 machine code. I was always amazed what you could accomplish with a lot of loops and branches. I never lost that sense that at whatever higher level I was at later on, it was all loops and branches.
Ultimately all the interesting stuff happens in loops and branches, the rest is just organization.
Its something like the sage uncovers the boiler, points at it and announces: Look! It is a beautiful marvel of technology! Why would you want to cover it up? Look! You might learn something!
Earlier quoted context omitted.
Reminds me of biological metabolic systems. All loops and branches…
Stephen Wolfram thinks the entire universe is built from simple rules https://en.wikipedia.org/wiki/A_New_Kind_of_Science
Rule 110 is known to be Turing-complete. https://en.wikipedia.org/wiki/Rule_110
I have a feeling that Rule 90 is the most efficient algorithm: the Sierpiński Triangle, self-sacrifice, infinite recursion to a perfect pattern. I'm not mathematically talented enough to prove that though.
https://mathworld.wolfram.com/Rule90.html
Please come to chat about A New Kind of Science on Facebook! A couple of weeks ago I noticed that the page didn't exist, so created it. Hopefully Wolfram doesn't mind. We stand on the shoulders of giants.
https://www.facebook.com/A-New-Kind-of-Science-1004052657757...
Earlier quoted context omitted.
I started off writing a lot of 68000 machine code. I was always amazed what you could accomplish with a lot of loops and branches. I never lost that sense that at whatever higher level I was at later on, it was all loops and branches.
Have you seen this? https://news.ycombinator.com/item?id=25788317 Seems like we lose a lot of good technology and progress for random reasons, like the “ram” of society is finite.
Sounds like the 2 hard things in Computer Science returning! Cache invalidation, naming things, and off-by-one errors. [1]
* "Knowledge is ephemeral": Cache invalidation
* "tower of abstraction": naming things, indirection [2]
Recommendations:
* "Reduce complexity, reduce dependencies": minimise entropy, maximise connectedness
* Learn: welcome newcomers; recurse to the next generation
[1] https://martinfowler.com/bliki/TwoHardThings.html
[2] All problems in computer science can be solved by another level of indirection" "...except for the problem of too many layers of indirection."
Earlier quoted context omitted.
Despite being a joke, I know it's the "Ha Ha Only Serious" [0] sort. I can't help but think this is severely biased by the trends of "enterprise software," where you eventually "give up", and clock your 9–5 writing if+for making a fine living, but erroneously pass that off as a mature, Jedi-like way of thinking about programming, like the meme suggests. (And, consequently, you spend no less time debugging hairy, nest…
> you eventually "give up", and clock your 9–5 writing if+for making a fine living, but erroneously pass that off as a mature This comment sure indicates to me where you most likely are on the curve. In all seriousness, I think this is considerably off the mark. After enough experience you realize that expressivity and convenience are antipatterns and don't actually simplify things but are harbingers of complexity, b…
Suggesting that experience leads to jettisoning expressivity is at odds with my direct observations of experienced software engineers working in large teams. The more experience, the _better_ the engineer gets at picking the right level of abstraction to write code that can be maintained by others. Picking a single point on the abstraction spectrum (just above goto but not below it!) is far too rigid for the diversity of tasks that software engineers need to solve.