The memes are great on that subreddit, when the March crash happened and people were posting gifs of 'Order 66' being executed from Star Wars... priceless
3,224 karma · joined June 17, 2015
Keyboard layout 0.09% Qwerty
I would think if continually layering over the top of existing ideas was somehow better, then evolution would have gone that route instead.
2. Good luck trying to optimise this (just merging all behaviours together at the end does not equal optimisation).
3. You're just pushing the problem elsewhere - now I need to understand all behaviours from a black box, then wrap them, all while dealing with all the other wrappers people have already put in place. Imagine dealing with that complexity.
'Good' developers is a subjective term, what is a good developer to you? Someone who can work without types? Wtf?
Anyway, I'll keep being productive with typed languages. You do you I guess.
Compile times? By a small amount sure, but with the incremental compilation we're talking maybe a few tens of seconds max. Any longer and you need to look at improving your build dependencies for better parallelism, and upgrading your hardware.
Development time? Types reduce mental overhead and abstraction for the developer, speeding up development.
Run time? Variables with types that stay static execute faster in JS engines.
Types keep code maintainable, and protect against any accidentally implicit conversions (rife in JS). Types still exist whether you define them or not, so being explicit gives the maintainer of your code much less mental overhead when working with your code. Knowing the contract that a function follows allows them to skip over any assumptions and know exactly what the code is meant to do. Break the contract, get a compile time error.
Anyone can write code, writing maintainable code is the real challenge. In my own 20 years experience this is always what separates the wheat from the chaff.
My original inspiration was that English language is spoken sequentially, but ends up in a graph database (i.e. the brain's neural network). So you'd write code like a thesis, and the hooks you specify would allow the splicer to form the code graph.
In theory it seemed like it would be useful, so I built Pacman with it and, well, it didn't really work in practice! Things ended up being more abstract in the end, and I'd be mentally juggling where hooks were created and what the final code would look like. Even showing the code output to the right wasn't that helpful, as the way the code was spliced together put things in not the most readable order.
Additionally how to split up the code wasn't the most obvious, i.e. when should a hook be added? It often felt I'd only know after writing the code in full. At which point it just felt like extra work. I'd often find myself to be inserting code all over the place to get something working, and so the refactoring needed at the end became overwhelming. Ultimately these reasons lead me to abandon the idea.
It seems new ideas truly are difficult to inject..
Your example of caching is almost basic programming, maintainable code also caches values after calculation for use elsewhere. You don't not cache the results of a database query and pass it around, that's just spaghetti.
In reality you have to break out your design into components that can later be rewritten one at a time in order to eek out performance. Easier said then done, but at a high level this first means keeping your big areas (UI, database queries, File IO, networking) separate, and work out the infrastructure from there.
The serious tone of this article made me double check if this was April 1st when I read this paragraph. The stolen data is shoe sizes? MD5 hashing for passwords isn't ideal, especially combined with email addresses - that could lead to some email accounts being accessed if people use the same password for everything. The article seems to not really give much attention to this though, not clear if the author even realises this is the main problem.
I agree this would be nice, but think of this problem more deeply and you quickly run into major issues. The biggest one being that your compiler now has a large scale optimisation step to do completely automatically, better than a human.
In order to make this work, you'd effectively have to build everything out of composable components, which you then can switch on/off with some sort of layering system. The problem here is how do you come to a decision on what those composable units look like? You don't know what you don't know - i.e. what those future layers you append are going to need to turn off or on.
And coming back to optimisation - once you know the features you are combining together in an algorithm, only then do you know the data structures that fit the problem. Optimisation isn't a forward process when you turn parts off and end up with an efficient system. Optimisation requires a high level view, a low level view, an understanding of context, of memory requirements, of language capabilities, even leaps of logic.
For the last part when I mean is that whilst a compiler may be able to reorganize something in the form a*b=c (and even then knowing when to do this is a book on it's own), it can't know that if I, for example, disable a feature that adds nested nodes to a tree structure, that it could rewrite functions to no longer require recursion and instead treat them like serial lists.
You could rewrite the methods yourself and add them to your new layer, but you also will inevitably end up not fitting the previous composable structure.
I think the deeper problem is related more to the tying of syntax to structure, as structure is ultimately your application's performance profile. Untying these two though could lead to a way forward for the append style paradigm.