Every time I talk to someone who's learning to program I tell them: "Setting up your development environment will be a nightmare. I have been doing this for twenty years and it's STILL a nightmare for me every time I do it. You are not alone."
Docker is reasonably good here... except you have to install Docker, and learn to use Docker Compose, and learn enough of the abstractions that you can fix it when something breaks.
https://glitch.com/ is by far the best step forward I've seen on this problem, but it's relatively limited in terms of what you can accomplish with it.
Simon -- since you're the cocreator of Django, you might get a kick out of this: From loading up a Django environment to adding and rendering the first view takes less than a minute: https://gifs.amasad.repl.co/django.gif
Before starting this company I was a founding engineer on the React Native team where I focused speed of setting up and taking the drudgery out of cross-platform mobile dev. And before that I was a founding engineer at Codecademy where we were attacking the same problem from an education angle.
With Repl.it, however, we're determined to simultaneously solve the "getting started" problem while scaling the environment to allow real work. It's incredibly challenging but we've made great progress. If anyone is interested in working with us, collaborating, or if you're simply passionate about this problem and want to chat then I'd love to hear from you: amjad@repl.it
Certainly the plan. Just a matter of priorities and time. I'm curious, what's so attractive about self hosted version?
I'll take a deeper look.
Check out our community as well, lots of hackers, especially young ones, sharing and collaborating on code: https://repl.it/talk
You could trivially create a new environment to test out someones PR or work on a feature branch, etc. If you use hosted environments, then you could connect from any client. If you only have a web browser, then you could work from VSCode in the browser (it's all JS+HTML anyway).
Others could join your hosted environment for peer-programming Google Docs style.
On hosted environments, normally long builds could be done very quickly and smart caching on the backend could share incremental compilation state between your teammates and you.
We're pretty close to this already with VSCode Remote Containers[0], Visual Studio Online[1] and VSCode Live Share[2].
(Disclosure: I work at MSFT but not on these technologies.)
[0] https://code.visualstudio.com/docs/remote/containers
We tried to make it as seamless and as low configuration as possible. Our "run on repl.it" badge is currently growing exponentially on GitHub.
I like docker, but it's too resource heavy on a Mac. I need it running directly and not in a VM.
So a simple nix file, and nix-shell shebangs[1] has been life changing. Throw in --pure and now you really know the environment works everywhere.
My repos all have a shell.nix with every dependency. Just call nix-shell and it works in Linux and OSX. Anywhere.
You can even bundle it into a docker image and use nix in there too. For production, etc.
Documentation and tutorials are lacking, but if you put in some time, I've found nothing comparable.
Version it in, pin the Nix channel[2], and you can come back a year later in a brand new machine and start where you left off.
[1] https://gist.github.com/travisbhartwell/f972aab227306edfcfea
[2] Highly counterintuitive: if you don't pin a Nix channel, it's a moving target and dependencies may go missing, be updated, etc.
It’s pretty difficult to understand and use though.
But once you do, you can build abstractions to improve that UX. But it would be nice if vanilla Nix was easier.
I was impressed by the low latency (at least as of a few months ago). If you make a web app right, it can be faster than a resource-hogging local IDE!
I don't use it myself every day because I've already been using vim/screen/bash for 15+ years. Those are my lightweight REPLs.
But if I were advising someone to code, and they wanted to skip the dev env, I would probably try repl.it. They also have impressive concurrent editing facilities in any language.
----
I also think the question is malformed, because I would hesitate to say there's any "single problem" in software development. It's all death by a thousand paper cuts.
The "dev env" problem is real, but it's really a problem with 100+ different tools. It's an architecture/ecosystem problem.
repl.it has some creative solutions to these problems, though it's still a ton of work. I think they are doing great but it's not going to solve all problems.
For example, another popular dev env is for data science or machine learning researchers. RStudio is doing some good stuff there, and there's Google colab, etc.
Software development is very big diverse and it's hard to imagine one solution cutting across all of it.
With the Universal Package Manager (https://github.com/replit/upm) we're trying to encode the best practices in package management behind a single easy-to-use interface. One of the most fun features is that you can `import` or `require` a package and we'll just guess what you want to do, install the dependencies for you, generate a spec and lock file.
With prybar (https://github.com/replit/prybar) we're trying to create a universal interactive programming experience that behaves roughly the same for every language.
And, to be open-sourced soon, our window-tiling manager and workspace (https://repl.it/blog/ide), we're trying to build a framework that makes it so easy to build complex, plugin-based environments, such as IDEs, very easy to build.
We also leverage a lot of awesome open-source projects and standards, like the Language Server Protocol by VSCode/Microsoft, that abstract over language features and makes it easy to provide an amazing experience across languages.
Edit: if it's been a few months since you tried Repl.it, give it another try, we've made a lot of progress since then. Multiplayer is now out of beta, we have Git integration, and we've done a lot to make it faster and more reliable.
In a nutshell: your repo contains a file (or directory) with everything needed to set up a containerized run environment for the project. VSCode adds its own server daemon, and your IDE runs half inside the container, half on the host machine. Once it's set up, everyone on the project (who has vscode) instantly has a one click clean, working development environment, including all the niceness you expect from local development (debugger, test integration, etc). It is fucking magical.
Detail: https://www.hanselman.com/blog/VisualStudioCodeRemoteDevelop...
1) install windows 10 2) install visual studio
And I’m good to go. I’ve seen my friends from the uni setting up elaborate arch/vim contraptions and I’m kinda glad I don’t have to.
npm & git's local directory awareness is a lifesver
rvm / nvm are great when the shell integration is turned on, direnv is wonderful
gap seems to be with native packages -- there isn't one of these for brew / apt-get, and language-level package managers fail on these deps a lot
inability to map local hostnames to docker is also a problem -- that would make it easier to manage multiple environments at once
Codesandbox had better UX than Glitch, at least for my taste.
pacman -S qtcreator clang qt5 cmake ninja git hotspot heaptrack
I can start pissing apps 10 minutes after a clean install of my system... what do you guys do that make it so hard ?!Easily 30% of my company's total engineering effort is just treading water, migrating from a deprecated platform to another one that will be deprecated by the time the migration is complete. Typically because the original team's standard 18-month tenure has elapsed and the new guy was under-leveled at hiring so he needs impact for promotion.
It's a great disservice to our field that people so deep in the stack are so comfortable changing their minds all the time. The Python 2.7 thing feels like the Library of Alexandria. Burning down mountains of perfectly good working code just because we can.
Backwards compatibility is tragically underrated.
1) Tension between abstraction and optimization. To put it shortly, abstraction is about ignoring the details, optimization is about fine-tuning the details; you can't do both at the same time. Which is why different programming languages make different kinds of compromise. You could make a beautiful language or framework with elegant abstractions, then look at the performance and cry. Or optimize for performance, and then cry while reading and debugging the code.
2) Tension between mathematical elegance and the cost of hiring people who are great at math. Some developers care about having the code elegant from mathematical perspective, but the companies optimize for having a product to sell, as cheaply as possible, which involves a lot of cutting corners. A product full of bugs can still make you millions of dollars. And what's the point of having a mathematical proof of correctness of your current code, when the business requirements are going to change tomorrow anyway.
For people interested by this rebol inspired language https://www.red-lang.org/p/about.html?m=1
This happend because our foundations are shaking, and is requiere to put on top some sanity. But nothing can work because: This industry not let go of the old and bad (C, C++, JS, Bash, etc) and refuse to do a significant change.
Too much change is bad.
Too little change is bad.
Have both things at odds in a fierce battle is worse.
Earlier in this thread I wrote about data being the top priority [1], the raw material, that we rarely give data the primary focus it deserves and instead focus too much on the processing side. More concretely: dashboards showing instrumented processing clusters give a biased view that does not focus on what matters at the end of the day. What we also need are dashboards showing data flowing between sinks and sources, data quantity, data quality, etc. Sure resource utilization and efficiency matters, but only after we can validate we still have the right output, and that input is of proper quality. If output contains garbage, is it bad processing or is it garbage from the input? And if something is wrong with processing, do we know the impact downstream? In other words instrumentation should include data sensors, not just processing sensors: data counters, validation points, invariants, etc. Because at the end of the day, when the power goes off, do you know what's left to recover? Do you prefer your customers telling you about an unfulfilled order or do you rather want it to be detected earlier? If you get audited for GDPR, do you have a map of your sensitive data? In terms of security, is it about protecting clusters and containers, or is it about protecting the data? Once you get the data side right many things become simpler, but if you get it wrong, as we often do, we create a world of problems. Giving data its proper place in our engineering practices will certainly change our industry for the better and bring it closer to "reality" with less danger of veering into the virtual for the sake of it.
In a world where software is increasingly involved in human activities this would have a great impact. However I don't think we should stop there, as I believe this is part of a larger trend I'm concerned about: the idea that, not just in software development but in most human endeavors, we're increasingly favoring spending time in virtual/man-made spaces and activities, at the expense of the real world, the place and time we're at, nature and the environment. As if we want to escape the physical conditions we're in: whether it's our body, our environment, society, the work we do, etc. When one can't see a way to influence the real world a tendency would be to start operating in a virtual one where we get the illusion to have an effect, make some money, be an expert, etc. Oh and let's not forget this desire to put as much tech between us and the real world, as if we don't want to experience it directly, it's too icky, and instead need devices to offer an indirect perception: wearable tech, navigation by GPS, remote controlling tractors in vast industrialized agricultural fields, etc.
A friend working in a supermarket chain told me this story: he often advised a younger manager to consider better maintenance procedures of their A/C system, but to no effect. Now that my friend is retiring soon this younger manager is proposing to make an excel chart to track energy consumption in order to optimize setpoints, and asks my friend for his approval. Really? Approve perception to be limited to an excel chart? Isn't that the same as leaving the windows open and wanting to change the setpoint?
The web is the "single top-priority" software platform, but it's in big, big trouble.
On mobile, users spend less than 7% of their time on the web. https://vimeo.com/364402896 All of the rest of their time is in native apps, where big corporations decide what you are and aren't allowed to do.
As a result, the money is going to native apps. The ad money is going there, the dev time is going there, and the mobile-web developer ecosystem is in peril.
The biggest reason people use native apps instead of mobile web apps is performance. Developers design web apps for fast desktop CPUs on fast WiFi data connections, and test their sites on top-of-the-line smartphones costing 5x-10x as much as the cheap smartphones people actually carry around.
Web developers have to solve this performance problem the way we've always solved our problems: with a new framework. ;-)
But specifically we need a framework designed to generate HTML with no JS at all, and designed to run in a Service Worker, which is a little web server that runs directly on the user's phone.
This style of app is often called a "Progressive Web App," and there are plenty of frameworks that support PWAs, but they generate PWAs on top of a single-page app framework that downloads megabytes of JavaScript running on the main thread. PWA is an afterthought for most frameworks, but we need it to be the centerpiece of the design.
And the web isn't controlled by big corporations? You literally just linked to a website on the web owned by a big publicly-traded corporation.
I am in favor of using the web over apps but mostly because it has less tracking features. A more high-performance, bare metal implementation of the web would most likely give more stuff for websites to fingerprint you with. You want WASM, but WASM makes the web just as bad as apps in that respect. WASM is going to make it impossible to hide ads (because it will be painted without the DOM) or to block tracking or otherwise malicious code (because it will be heavily obfuscated).
This is true, but what's the alternative? That just seems like a necessary trade-off. Native code will always be easier to obfuscate. It seems backwards to think that we should keep things far more inefficient and consume more cycles and electricity and place things behind more layers of indirection and make web use slower for users just so that it's harder to hide malware. This reminds me of the argument that we shouldn't make cryptography too strong because then it could be used by criminals in a way that even intelligence and law enforcement agencies can't pierce.
There's already a ton of tracking going on, and typically already with heavy obfuscation. The obfuscation doesn't seem to make a difference in terms of practical solutions either way, since the detection and blocking is generally based on origins and IP addresses rather than static (or even dynamic) analysis. And a lot of ad blocking does the same, and should still work for WASM.
For cases where the ads are served directly by the origin and are painted without a DOM, more clever mitigations will be needed, but I don't doubt that people will come up with solutions.
So, yes, the cat-and-mouse game is going to become easier for ad/tracking companies and harder for anti-ad/tracking developers, but it's going to be a big challenge for both parties, just like it is now, and the anti-ad/tracking side is still going to have a lot of success.
However, the real reason that the ad money (and engineering effort) is going to apps is that app platforms do not protect privacy at the same level that the open web does. There's so much more tracking available on mobile platforms than there is on the open web.
My one issue with PWA's is iOS doesn't support all the features.
https://github.com/zeit/next.js/issues/5054
Gatsby has a no-JS plugin https://www.gatsbyjs.org/packages/gatsby-plugin-no-javascrip... but that also disables the PWA. The Gatsby team doesn't seem to be interested in no-JS mode. https://www.gatsbyjs.org/blog/2020-01-30-why-gatsby-is-bette...
Why?
No amount of processing power matters if you don't have the data.
Everyone in the industry focuses too much on the processing side: objects, functions, containers, VMs, k8s, etc. but nobody really gives proper attention to data, its provenance, where it stays and where it goes, etc. I'm not saying engineers don't think about these things, they obviously have to think about it at some point. It's just that data is always accessory to the story. It's like processing is the cool kid and data is the stinky one nobody wants to approach unless you have to. Look at the 12 factor principles for example, where is data in there? How easy is it to take data from one place/cloud/database to another? Data is the raw material, it needs to be the primary concern in programming languages and architectures, not objects or functions, containers or whatever, those come after, not first.
As for 12 factor principles, it was first touted by a PaaS provider. The whole idea is that they take care of the nitty gritty, while you can focus on the exciting (and technically easier) parts of software systems.
However when I look at the accidental complexity we have created on the processing side, I wonder if it does not surpass the essential complexity of dealing with data.
In other words: maybe we have yet to create the proper concepts and tools to deal with data, all this time the industry created a tower of babel (and of overspent $$$) with our languages, frameworks, containers, etc.
Every website and app and network service seems to be reinventing the wheel here, and end up creating little silos of trust data, whereas in principle it should be possible to receive a (locally) consistent answer to the question of "Is this person in good standing with the other humans they interact with?" whether that person is sending you an email, or writing a software library you are downloading, or creating an account on your website, or selling you goods on Ebay, or offering you a lift through a ride sharing app.
This reminds me of how social security numbers weren't originally intended to be used as unique identification, but the demand for some form of identification was so strong that organisations ended up hackily using it anyway.[1]
It's scary to let internet companies have your actual DNA (though that didn't stop 23andme customers), so there could be an layer in between (a nonprofit? machine with a hardware security module?) that does the DNA sequencing and returns a digital signature to authenticate you.
The obvious downside is that it would work too well. Banning becomes much more serious of a thing when it's lifelong and potentially could affect your descendants. I hope I'm not giving anyone any ideas because this is horrible.
The best you can do is have just one central reference store of trust/reputation. China's social credit score is a working implementation of this. I don't think the West will ever be ready for that though, so you're going to have to deal with the fragmentation.
[1] The innovation was requiring a computationally difficult problem to be solved to participate in the network and using hash functions to prevent tampering. This made any participant (miner) in the Bitcoin network a dumb cog in the machine that could be replaced by another. The people aren't special; the computational work is special.
'Sovrin utilizes a “public permissioned” distributed ledger design (Fig 4). The easiest analogy is to the global ATM network: anyone can use an ATM (public), but only those who’ve been given special permission can add a new ATM to the ATM network (permissioned). With the Sovrin Identity Network, it is the Sovrin Foundation that grants permission for “nodes” (akin to ATMs in the metaphor) to join the network.'
https://sovrin.org/wp-content/uploads/2018/03/The-Inevitable...
----
...
Claim: Most sites are mostly static content. For example, AirBNB or Grubhub. Those sites could be way faster than they are now if they were architected differently. Only when you check out do you need anything resembling an “app”. The browsing and searching is better done with a “document” model IMO.
Ditto for YouTube... I think it used to be more a document model, but now it’s more like an app. And it’s gotten a lot slower, which I don’t think is a coincidence. Netflix is a more obvious example – it’s crazy slow.
To address the OP: for Sourcehut/Github, I would say everything except the PR review system could use the document model. Navigating code and adding comments is arguably an app.
On the other hand, there are things that are and should be apps: Google Maps, Docs, Sheets.
edit: Yeah now that I check, YouTube does the infinite scroll thing, which is slow and annoying IMO (e.g. breaks bookmarking). Ditto for AirBNB.
https://lobste.rs/s/jmmr3w/interview_with_drew_devault#c_wuc...
context: https://lobste.rs/s/jmmr3w/interview_with_drew_devault
I haven't used sourcehut much but the UI is going in the right direction IMO. It looks nice and is functional, at 5% of the weight and 20x the speed of similar sites.
Touch capabilities can be a nice addition to many types of desktop productivity software without detracting from what's already there. Companies reworking desktop applications to look and feel like mobile apps (with all of the related pros and cons) is what causes productivity to suffer rather than anything inherent in the paradigm.
This is basically what I mean by mixing paradigms, and it's getting more and more common in operating systems as well, with Windows as clear leader.
As for touch input, I personally think it's of little use on the desktop. I've already got a mouse, which when properly configured is a pixel-precision input device. I simply cannot do the things I do with a mouse on a touchpad, let alone a touchscreen.
There are several other crimes as well, big and small, mainly in Windows but also on Linux/BSD (especially in Gnome, where the worst decisions made seem to perpetuate into other FOSS DE:s). Apple is still keeping things relatively sane, even though they've slipped somewhat of late.
Most of the time the users haven't taken enough time to understand their own problems and have trouble articulating them in a way that's meaningful for a product manager or developer. And on the opposite side of that product managers and developers often do not develop sufficient domain experience to understand the problems users are trying to express.
This is why the absolute best software is built by people who are developing for themselves. You know when it's not solving your problem and you fix it because you know nobody else will.
That seems nuts to me. I'm not sure how you fix it without being Amazon/Google. People moan about Terraform too before that gets mentioned.
I'd really like to understand more about what the pain points are here. In contrast to your experience I spend almost no time deploying code. We commit, tests run, we click a button and the deployment is updated in our kubernetes cluster. We did have to put a fair bit of work into our gitlab pipelines and the tooling that patches config into our kubernetes manifests and depoys them to the right place (let's say 2 person months all-in), but the payoff in the end was pretty significant. We're a fairly small company so if we could afford to put the time in to build the foundation for painless deployment I wonder what prevents larger orgs from doing this work? Is it access to the right skills? Difficulty prioritizing non-revenue tasks?
We've still got a lot to build, but the goal is zero config deployment for any app/service.
Nothing radical. Just a managed service provider that would build and maintain the CI/CD pipeline for them.
https://github.com/frankmcsherry/differential-dataflow
Lots of very active CS research in this area though.
Martin Kleppman's articles and research is a great place to start for anyone interested: https://martin.kleppmann.com/2015/02/11/database-inside-out-...
Far too often when I want to learn something new I either find there is not much documentation or find that there is a large mass of documentation that probably has everything I need but is so disorganized that I can't figure out how to approach it.
Another documentation problem, especially with open source projects, is that development and documentation are often loosely coupled, if at all. The people doing documentation usually don't have the resources to keep up with development, and so even if there is good well organized comprehensive documentation it is usually obsolete.
Would love to chat with you further! Shoot me an email over if you're interested at li.eric00@gmail.com
Something like Ubuntu Edge for those who remember it, but with more local storage -- TBs maybe -- more connectivity out of the box.
I realize now it’ll probably never happen, since the companies making the phones are the same companies that make computers.
They also did a Linux on DeX. You could boot Ubuntu on your Samsung phone and display it via HDMI. They stopped supporting it around Android 10 though, presumably nobody ever used it.
Not sure why this doesn't exist for Apple/Android. It seems so obvious that they're must be Some critical flaw I'm overlooking
I want to be able to plug APIs together, process user input, have persistence and identity, without writing so much boilerplate.
Think about what Excel did to productivity, and multiply that by 3x or more. That's what no code could do as the 60% solution for a 200x larger labor pool (more like 80% solution for anyone who can't access engineering talent). It would also make its creators obscenely rich. With the amount of processing power that we have, the time for no code is now.
By the way, there's a large chance that Big Tech incumbents won't be the ones to create the no-code holy grail. They have institutional handcuffs that will make that difficult.
How? If you want a language to be adopted and become standard, it would have to be free and open-source. You don't get "obscenely" rich from that.
This is a good example of those problems that could relatively easily be solved with a proper public-goods funding mechanism, but very difficultly without.
Abstracting away infrastructure just means it will become increasingly centralized as a commodity and less likely/harder to create independent services.
Look at n2n or userbase, they’re open source and can be self hosted.
Other nocode tools can follow suit, and can be federated.
I agree with the other comment that this can have the same effect as the one Excel had during the past decades (there are companies running completely on Excel).
At the moment though, the tools feel too limited.
Being able to update libraries, tools etc. automatically and without friction. Right now upgrading is so tedious, error prone and painful that most places just keep using ancient versions that are not only lacking bug fixes and newer features but are a huge attack surface.
It's a human coordination and cooperation problem on a global scale.
Offer different versions.
Sandbox programs at the OS level to mitigate old (or new) vulns.
WASM is a great advance over what came before in many ways, but still has some room for improvement. These are all problems with known good solutions, but there is no holistic platform that integrates these smoothly. It's largely a hodge podge of various programming languages, configuration systems, build systems, scripts, etc. Look elsewhere in this thread for people complaining about how difficult it still is to setup a development environment. Embedded programming is typically even worse, though it's improved dramatically since the rise of Arduino.
It needn't be this way though. A well designed programming language can be used for configuration, scripting and more. Racket is a good example on the dynamically typed side, and F# is a good example for a statically typed language along these lines.
I suppose if you were gonzo about it you could format the first track with sectors all numbered zero, and eliminate rotational latency. You'd save 80 ms (on average) that way.
Didn't seem worthwhile at the time :-)
But I'm not an OS expert, maybe it is possible.
At least get typeahead working properly again. Various places have borken this, especially Facebook, but back on vt3270 systems experienced operators could just hammer a bunch of data into forms as fast as they could type. Can't usually do that with web apps.
I've used a Tempest arcade machine with near-zero latency, and it was a very weird and pleasant experience.
10ms response is a bit on the fast side. Aside from pros doing sports or music, we (humans) don’t register most kinds responses that fast. Plus a 60hz display is 16ms anyway. These days browsers, editors, and OSes really do usually try to meet this goal for the most common workflows, though there are plenty of demonstrable exceptions. It’s a good goal, I agree with it, but maybe 100ms would be a more reasonable worst-case response time?
But for worst case in general, not bad.
This problem is best solved with an effective, reliable sleep/wake mechanism, not a fast boot mechanism.
I am willing to go out on a limb and say that as much as 25% of software engineering time worldwide is wasted due to poor documentation.
It's an asymmetric problem too. If someone benevolently funds a team of engineers for a couple of months to write great docs (with detailed examples) for top 500 libraries, frameworks, APIs. They could increase global productivity of software engineers by %25 percent.
And I know there are lots of html / web based things you can run on desktop but they are even more complex, for me at least.
User interface responsiveness.
The Web being based on standards that leak users' data left and right.
Thus, on a longer term, you might want to identify the cycles and look into opportunities beyond the current phase in these cycles, and whether there are under-utilized ideas there.
For instance, for unix-style command line operation, we have the idea of piping data between applications and combining multiple applications to perform a job.
These applications communicate through very simple protocol, the text file format, where one line means one thing. Thus, if we want to combine more complex applications, such as operations on image files, each needs to implement their own processing for various file formats etc.
My idea would be to try to increase the abstraction level of operating system from files to something more generic.
For example, what kind of things I could script more easily if the operating system would allow me to read source code tokens/statements/packages in any language? Or images as an abstraction regardless of their file type?
Cookie-cutter developers using open source they don't understand to implement mission critical infrastructure for companies that don't understand the internet. Its a recipe for disaster.
[0]: See also: https://link.springer.com/chapter/10.1007%2F3-540-48753-0_16
Google died when they stopped being well informed librarians and started being aggressive salespeople. It's time for a new search engine to step in specifically catered to the curious.
In theory: Prove that one-way functions don't exist, or explicitly construct one. Similarly, prove that P!=NP, or similarly settle the question.
1) Why unguessable? That sounds like something one would naively use to keep secrets, but encryption is the right tool for that. Apart from that, it sounds like nodes participating in the network would inherently have to see names in order to process requests...
Would something like 256 or 512 bit hashes suffice? You can try to guess or enumerate, but the chances of finding anything are slim.
2) What problems of networked data storage would this end? I see lots of problems, such as discoverability, bandwidth, latency, retention, scaling, censorship, etc. Which of these are solved by globality of the netwokr? Which of these are solved by unguessable addresses?
3) How does this end copyright? AIUI copyright is a social problem, not an engineering problem. If you want to work around it, you would need (at least) strong anonymity and censorship resistance. Freenet is the only thing (that I know of) that comes close, and while it has engineering problems, the main issue with any such project is a people problem: you need huge adoption, otherwise it is impossible to resist deanonymization and offer sufficient bandwidth & storage, etc.
You are also right that we don't yet have a satisfactory proof that any of this can happen. It does indeed seem like participants in the network must, as a condition of routing, be forced to handle bundles of data to which they do not have keys, and while mixnets are real, mixnets do not completely solve the problem.
Yes, if we get concrete, the typical way of building unguessable names for data is to do something like take a Merkle tree hash, and then use that as a basis for several "exported" names which are made from further hashes.
2) This would form the basis for a data commons. Existing commons are actually centralized platforms supported by small specialized entities, leading to lots of extra details that nobody is incentivized to get right. By contrast, if there were a single namespace that existed beyond corporate or state control, where participation is platform, then people are incentivized to pay their own way on discoverability (using existing social graphs), bandwidth, latency (using existing compute hosts), retention, scaling, and censorship (using low cost of publication plus low cost of maintenance).
The global/universal nature of the network ensures that, if you can reach it, then it can reach you, and you are connected. IP gives us a hint of this; the typical connection comes with an IP address, and that address can be globally routed. For a real example today, look at how Bittorrent is diverging from the need for trackers.
Finally, it's worth pointing out that decentralized designs might be able to shard computational work or otherwise balance resources. Bittorrent famously was designed to go faster as more peers contribute more spare bandwidth, to the point where the early days of Bittorrent were marked by the protocol chewing up and choking residential ISP connections.
3) Copyright is a social solution to a technical problem in most media. The problem is that publication isn't instantaneous and uniform; there is a delay of time while a published work is copied around the world, and that delay introduces opportunity for pirates to make bootlegs and undercut official releases. On the modern Web, though, this is silly. If one wants to make a simultaneous publication to all paying customers, then one can sell customized encrypted copies at each point of sale, and release a master key which decrypts them all, a day later. The entire window of opportunity for pirates can be shrunken to mere milliseconds, which is impossibly small for pirates to make a profit.
Since we don't really need copyright in order to prevent piracy, then it makes sense to raise the eyebrow and look more cynically at such an intrusive and artificial right. In particular, the proposed namespace grants massive power to publishing artists first.
Having to check out the branch, install dependencies, build the code and run it only to then go back to the UI to see the changes and comments is very time consuming and being able to test suggested changes instantly would save me a ton of time.
I would gladly pay for this.
I haven't used Collaborator in a while, but I wonder how much it has improved in ten years.
It sounds like you're thinking of a code review tool + CI/CD pipeline, right, @inglor? e.g., 1. suggest a change in the UI or backend in the code review tool 2. run CI/CD and deploy to test environment 3. refer to this new environment in the the code review tool
Am I on the right track?
There is still room for Domain Specific languages like sql, html and such but for imperative programming there are way too many options all filling almost the same need with just slight variation. Even with the rise of all types of VMs and cross compilers we are still porting mountains of code to another language just because the execution environment was slightly different. The gap between embedded and web is also too big, for embedded you are stuck with prehistoric c++ with dangerous syntax, hour-long build times and days of figuring out how to correctly compile and link that shared library. vs web where your only options are dynamic languages where both safety, predictability and performance are a joke. I also realize safety and performance vs productivity often contradicts each other but not as much as often argued, there has to be a better middle ground than what we are stuck with today.
In isolation, this should be an achievable task, especially if dropping any legacy compatibility. What might be difficult is is people want legacy compatibility and proven in use, so adaptation-rate will turn this into "there are now 15 competing standards" and a "peace on earth"-type problem.
A large and increasing amount of human-made energy goes to computation, yet only a tiny proportion of software is written with energy efficiency in mind. Most programmers don't even have the tools to answer how much power their programs consume.
At a start, no compute benchmark that measures wall duration should ever be taken seriously if it doesn't also include energy consumption.
Java applets came 20 years too early - potentially had the power to do everything we do with the web today but 10x faster and more cleanly.
The web remains one place where you lack the freedom to easily use whatever language you like - WASM will end the era of JS if they do it right.
The JS ecosystem is extremely wild and turbulent - even something as simple as "I need this project to be built exactly as it was in August 2017" is almost impossible with the npm world.
Meanwhile native apps compiled in 1985 still run, and can even build today with minimal fuss.
Lets be honest - how many of you use JS because there was no other option? Its not a terrible language - in fact I like JS/ES7 more than python, but it's still one of the pillars of chaos in the world of programming
It exists, and is called VirtualBox. It just doesn't run inside the browser though, but you can run a browser in it.
I am working on this problem. Let me know if you are interested, I would like to hear your opinion. My Keybase is in my profile or I email you.
If you could solve this problem, you could convince management why engineers need offices, for one.
We should not be rewriting and adopting a slightly better but incompatible version of make every five years, or waffling between SQL and NoSQL, or churning back and forth between slightly different versions of MVC paradigms. Or going from tables to div-tables to flow layouts to css-grid.
I can think of 2 ripe opportunities, that I reference often.
1. Comments integrated with code as associated records that can overlap, which provides context, not merely inlined comments. The state of understanding code is horrendously inefficient by design.
2. Put a more type safe language on the browser with concurrency primitives. Promises are a hack improvement and Python is too rigid in ideology to make it eventially compatible.
We have some legacy code at my work which is basically in "do not touch or it'll break" mode. Last year a senior developer who used to maintain it retired. Before he left, he copied the code into a PDF and annotated the PDF with his thoughts and advice. He didn't want to risk breaking the code on his last week by adding the comments directly to the code.
1) computers handle bits and bytes, not information. If computers can be made to create, search, update and delete pieces of information, instead of bits and bytes, 90% of code would go away and life would be much easier for all of us.
2) programming is done wrongly and poorly: we write a program to do a specific job, without any proofs, with serial control flow, we compile it, we setup an environment for it, etc. Instead, we should write hierarchies of programs, each level of hierarchy should have its own proofs (i.e. the specifications should be part of our programs), control flow should be event based, programs should be running as soon as we write them in a live test environment etc.
In other words, forget files, processes, handles, databases, source files, bits, bytes, the command line, UIs etc. All these provide some level of abstraction that doesn't really scale to what we actually need. We need another level of abstraction: the piece of information.
Which should eventually include a piece of code that communicates with the outside world via events, and that code would be composed of other pieces of information, would be fully creatable, searchable, updatable and deletable just like any other sort of piece of information.
And UIs should be creatable, searchable, updatable and deletable pieces of information as well.
And a global communication language would replace all command line interfaces, UIs, and programming languages: we shall talk to our UIs with this language, and the UIs shall talk to us by using that language as well, using graphical representation when needed.
Someone upthread said "nocode", and I think that's more on the money. Most people will never be "programmers" as we understand the term, but they could still benefit from a narrowing of the gap between what Excel can do and what (say) Python can.
An old hobby project of mine[1] had a go at this by letting spreadsheet users write functions in the spreadsheet itself, in exactly the same way they already used the spreadsheet to calculate things. Basically, if you just used the spreadsheet as a calculator, it would automatically define reusable functions out of those calculations. I think something like that would push Excel's power and usability forward for your average person, because it wouldn't make them reliant on programmers to implement the things they want.
There are too many un-opinionated choices today, so people waste too much time on choices for the various pieces. The whole ecosystem is very fragmented.
A relatively sane, top-to-bottom framework that isn't the fastest, or "best", but "good enough"...would be welcome. Maybe Golang or Rust or Node will progress to having their own "Rails"?
Not trivial but maybe automated by some meta-meta-build tool?
I could start a new project with Spring Boot and Ember.js, provision a Debian box with Postgres and nginx, and deploy all of it within an hour because I know these tools. But I too paid the learning price my first go round.
Cannot tell you how much time I spend fighting solved-since-1980 RDBMS problems at the application layer. But we really are too big for single-master (pushed it to its breaking point and a little beyond).
Web design seems to be unifying around progressive web design principles and too many devs spend way too much time recreating the same variations of CRUD apps.
If any new web feature could be distilled to a metacode base and then restructured from there we could maybe find a way to escape this nightmarish hydra of web technologies.
https://twitter.com/geoffreylitt/status/1224094967922073600?...
There’s a paper about it coming soon that gets more into some of the things you mentioned.
2. Tools to help making parallel programming easier, without massive impacts on efficiency. Future CPUs are offering more performance primarily through more cores and wider vector instructions. Currently to use these efficiently is often very hard.
3. A replacement for C/C++. Rust is promising, you could contribute there, or to Zig, or come up with something better.
4. large scale, high quality studies into the efficacy of various programming ideas, languages, methodologies, etc. (Does dynamic typing increasing or decrease productivity, or under what domains does it do one or the other, does functional programming reduce error rates, by how much, and at what performance cost? etc
2. OpenMP is easy to use, just put #pragma statements
3. Rust is the leader here. It's doing very well.
4. I have read a few studies like this. The takeaway was that it took about the same time to write a program in every language studied (it included Haskell and FP langs). Language/paradigm also did not have much of an effect on correctness and bugs.
In a perfect world, I'd like to run an analyzer on my CRUD app's source code, and have it list the 37 vulnerabilities I overlooked.
Probably not a candidate for "most" but maybe worth mentioning: pgp
There's also lots of non-technical debt; indeed not even any of the above are purely technical, at the least getting solutions adopted likely requires a lot more than just serious hacking.
Surely there are existing projects, or at least communities, that have formed around taking on what participants thought/think of the most importance piece of technical debt, at least that they were/are equipped to take on; perhaps [non-]reproducible builds, shotgun parsers (langsec)?
I'd, instead, follow the Alan Kay idea of antecipating 10 years in the future with some new hardware that allows a new computing platform and then see how I can capitalize in it in some kind of pure way (removing as much technicalities as possible, like Self, LISP or Smalltalk did).
For inspiration on what form it could take, I'd take a look at all Sci-Fi I can but pay special attention to Bret Victor's: Humane Representation of Thought https://vimeo.com/115154289
Specify a problem statement and let the computer figure out a way to implement it but take this idea and apply it to SaaS Applications. Here's how a domain model looks like, go figure out a database-backed API application implementation for me.
Because this affects cognitive health and productivity of just about every tech employee, it truly is the biggest problem and is no overstatement at all that we would cure more diseases, feed more hungry people, develop better policies for people in need, or even just satisfy consumer demands more profitably, if the scourge of open-plan offices finally goes away.
Very few other problems faced by engineering workers are so vast and systemic as open-plan offices, with such far reaching value if it is solved.
https://testing.googleblog.com/2007/01/introducing-testing-o...
There's nothing out there for this.
I'm talking about things like sign-up workflows, password recovery, two-factor authentication, role-based access control, search, approvals by manager, integration with BI tools etc.
There are application development frameworks that solve some of these problems for you, but they tend to be so heavy-weight and/or impose so many restrictions on you that they hardly seem worth using.
The root of the problem is that data denormalization is broken [0]. The fix is doable in theory, yet not done yet, and not talked about enough.
[0] https://medium.com/@lironshapira/data-denormalization-is-bro...
Right now there is no differentiation between actual engineers who write original code and button pressers that either live in configuration hell or that mindlessly need design patterns to tell them what to do.
Programming is the act of writing instructions and yet so many developers can neither communicate in writing nor plan a series on instructions.
In other words: solve the Data Model Coupling problem programmatically. Applied to an RDBMS, one could imagine a graph with weighted edges representing coupling between database tables and dynamically reverse-engineering joins into DB-isolated API calls.
I think collectively we need more thought on how to design declarative systems that are tangible inspectable debuggable in the same way following procedural code is
Disclaimer: I haven't used either language, just learned about Raku recently from this[2] excellent FOSDEM talk.
Compile times are fast if you are willing to tradeoff performance. But you can decide whether you whether or not you want a long compile fast program, a short compile slow program, or an interactive compiler.
The example I can give is StandardML. You have SML/NJ and MLTon as two possible compilation options among other. SML/NJ has an interactive mode. MLTon compiles for longer but results in faster programs. (And it's also Hindley-Milner)
Just going to the "it should be interpretable" route without there being any option for whole-program optimization at compile time results in unnecessary bloats in performance which by all means we can avoid now as development hardware has become faster.
Beyond immediately reducing bugs, I think widespread use of this sort of language designed with a good type system from first principles would allow many more programmers to write programs with some provable security guarantees.
Once you get to a point where you can demonstrate that 'doing it faster' is not an option, everyone gets better for it.
Right now, all you get is bypassable CI pipelines, crappy in-IDE tools that sometimes work, and very costly static analysers that usually don't work and are more designed to please the clipboard warriors.
Emphasis on exchanging information between 2 unknown programs.
So much programming plumbing (parsing text etc.) to do just that.
So many hours wasted chasing API documentation to figure out how to call an incantation.
So many software features hidden away and inacessible unless used through a UI maze.
So much code sitting there unused and undiscoverable.
(That and the 800lb gorilla in the room: programmers are fashion-driven to the point of absurdity.)
Except, thinking about it, I don't think it fits your description because it can't be solved by the methods you describe. We are "complexity junkies". Most of us haven't hit rock bottom, don't see a problem, or are well-paid to feed our habit.
We have tools and concepts that would do the trick, but we ignore them.
Consider Elm lang. Takes all the complexity out of writing web apps, has a history of zero bugs in the code it generates, doesn't get traction because...?
- - - -
Dr. Margaret Hamilton (of Apollo 11 fame, who coined the phrase "software engineering") developed a system of software construction she called "Higher-Order Software" that eliminates the sources of most programming bugs. Sadly, it was critically panned and has languished in obscurity for decades. See "System Design from Provably Correct Constructs" for more info.
- - - -
Graydon Hoare gave a talk on the history of compilers[1] and he doesn't mention Prolog once. Is it possible he doesn't know about the research into logic programming and compilers?
E.g. "Parsing and Compiling Using Prolog" Jacques Cohen and Tim Hickey ACM Transactions on Programming Languages and Systems 9(2):125-163 · April 1987 DOI: 10.1145/22719.22946 · Source: DBLP https://www.researchgate.net/publication/220404296_Parsing_a...
1. Introduction
2. Parsing
2.1 Bottom-Up
2.2 Top-Down
2.3 Recursive Descent
3. Syntax-Directed Translation
4. M-Grammars and DCGs
5. Grammar Properties
6. Lexical Scanners And Parser Generation
7. Code Generation
7.1 Generating Code from Polish
7.2 Generating Code from Trees
7.3 A Machine-Independent Algorithm for Code Generation
7.4 Code Generation from a Labelled Tree
8. Optimizations
8.1 Compile-Time Evaluation
8.2 Peephole Optimization
9. Using Proposed Extension
10. Final Remarks
That's from 1987.Long story short, if you want to write a compiler it's easier and faster to learn Prolog and write it in that than to learn to write a compiler in whatever lower-level language you might already know.
[1] https://thenewstack.io/rust-creator-graydon-hoare-recounts-t...
On a certain level of abstraction, there is really no right or wrong, just different. And it becomes a matter of taste.
That and the limitations of the human brain. We cannot remember a billion assembly instructions, so we have to abstract, and create layers of abstractions in order to get to human level of tangibility. Only problem is that the more layers we pile on the more complex the stack becomes, and it get even more difficult to comprehend, so we get an exponential explosion of complexity. And the only thing limiting the complexity is hardware performance. So if computers keep getting faster we will be doomed.
Already solved, but not used.
2. False advertising, overhype.
Related to 1)
I truly miss many immersive Flash experiences on the web.
In my opinion there are two big angles here. One is memory safety, which is the primary cause of remotely exploitable vulnerabilities these days (see https://twitter.com/LazyFishBarrel for some stats). Any evidence-based approach that reliably reduces memory unsafety bugs is productive - whether that's "rewrite it in Rust," "rewrite it in Go," "rewrite it in Python," "rewrite it in Java," "write really good C static analysis tools," etc.
The other is getting software updates into people's hands for a reasonable price. If you buy a cheap Android phone, you're buying an insecure Android phone. There are few options for a cheap iOS phone, especially one that's still receiving security updates.
See https://googleprojectzero.blogspot.com/2019/11/bad-binder-an... for a good analysis of a combination of these two problems, specifically weaponized in the wild by NSO Group. One part is that it's a use-after-free. The other part is that it was fixed in Linux, and it didn't make it into Linux for two years.
If I had a large team of serious hackers at my disposal to solve problems for the world, I would work with some of them to fix the highest-risk code written in memory-unsafe languages and get the fixes upstream, and I would work with the rest of them to fix the various process problems that make it hard for Android vendors to upgrade to new versions of Linux and other components continually.
(Note that both of these problems are really best solved by a team that can continue working on the problem indefinitely, not a strike team that delivers a thing and then declares the job done.)
As it stands, both beginners and experts have difficulties understanding exactly what their own programs are doing as well as what programs written by other people are doing. We encode complex algorithms in static, abstract text descriptions that are hard for humans to understand and reason about. We have to imagine the behavior in our heads from these illegible descriptions. The behavior and internal workings of their programs are invisible.
Not to mention that when trying to modify other's programs there is often a huge communication problem, trying to construct a mental model of what the program does is a tedious and often impossible endeavor because of missing context. Just think, how is it even possible to make "write-only code", code that was understood when written but is now completely unintelligible. To me, that should be impossible. Or think about how open source software is open in that its code is available, but closed in terms of being easily understood — there's the formidable cognitive challenge of understanding the program well enough to be able to modify it to one's ends. For most people, this is a significant and unreasonable effort.
What to do about all this? To me, the answer is redesign programming so that it is primarily about communicating behavior to humans. A couple things I've made toward that end:
* Legible Mathematics, an essay about the UI design of understandable arithmetic:
http://glench.com/LegibleMathematics/ * FuzzySet: interactive documentation of a JS library, which has helped fix real bugs:
http://glench.github.io/fuzzyset.js/ui/ * Flowsheets V2: a prototype programming environment where you see real data as you program instead of imagining it in your head:
https://www.youtube.com/watch?v=y1Ca5czOY7Q * REPLugger: a live REPL + debugger designed for getting immediate feedback when working in large programs:
https://www.youtube.com/watch?v=F8p5bj01UWk * Marilyn Maloney: an interactive explanation of a program designed so that even children could easily understand how it works:
http://glench.com/MarilynMaloney/In general, I think it's a neat research direction to redesign many concrete programs by hand in the most understandable way possible (using custom graphics, interactivity, game design mechanics — all the best things we have for helping someone understand things through media), and then use those experiments to work backward toward programming languages/environments.
In the end, programming is essentially only limited by human understanding, so that's the most significant engineering program out there.
One example: lots of software devs have no training and/or interest in security, and employers have no way to vet that.
Another: there is no way for users to trust SaaS security. I have no idea whether (as a random example) Atlassian has a great security culture or a terrible one. We just trust people who seem trustworthy, usually due to their polished marketing.