4 ms·
I think it's not so much the lack of good research being done, but the lack of real world application of that research. And furthermore the real applicable rese
by tinco 5y ago
I think it's not so much the lack of good research being done, but the lack of real world application of that research. And furthermore the real applicable research wasn't really theoretical research but more lessons learned by engineers in the industry.
It's crazy to me that researchers prefer to be published over having world renowned software to their name. You could figure out the fanciest database research, but there was a period where every fancy new NoSQL database was based on BerkeleyDB despite all that, bolstering the reputation of the University of Berkeley.
Despite all the research into garbage collectors nearly every new programming language I've seen uses either BoehmGC (from 1994) or simply gives up on the idea and uses reference counting.
Imagine if university groups would band together to produce really state of the art production quality reference software. They could use them as base for their research, bolster their reputation by having them be great, and even draw funding from big companies looking to hire the PhD's produced by the efforts.
Instead we have got all these half finished demonstration software that no one industry would touch with a ten foot pole.
It took just a few people to develop the first versions of rust, a research based programming language that in my opinion has been the biggest shock to the industry in decades (if you disregard machine learning).
- amelius 5y agoPeople should code in Haskell more, and we would have massive amounts of reusable code. All the problems stem from premature optimization, and rush to market.
- unmole 5y agoYeah. Won't have any software problems if there isn't a software industry to begin with.
- coldtea 5y ago>and we would have massive amounts of reusable code Haskell even has problems coming up with a single string / text interface. It's not some magic bullet for code reuse, any more "everybody would write Java and we would have had massive amounts of reusable jar libs".
- amelius 5y agoBut at least we'd have referential transparency.
- ParetoOptimal 5y ago> Haskell even has problems coming up with a single string / text interface. That's orthogonal to the claim that if everyone used Haskell we'd have better code reuse. > It's not some magic bullet for code reuse Not a magic bullet, but makes code reuse much easier than any other lanugage. That can be attributed to a focus on sound abstractions, referential transparency, and laziness[0] mean that code is much easier to reuse. 0: Yes, laziness helps composition and code reuse!
- native_samples 5y agoWell, in fairness, the industry has got quite far with "everyone writes JARs". There are a heck of a lot of them out there. And now with Truffle you can mix JARs, Python packages, Ruby packages, JS packages ..
- ferdowsi 5y agoAcademia trying to "Make Haskell Happen" is a clear indication of how disconnected it is from the practice of software engineering. Haskell is not going to happen.
- ParetoOptimal 5y agoMy current Haskell job and previous Haskell jobs disagree. Also I'm not academia since I don't even have a bachelors degree and am a professional Haskell developer.
- unicornmama 5y agoYour problems are my opportunities.
- amelius 5y agoYou enjoy wading through other people's rushed code?
- unicornmama 5y agoI enjoy watching production blow up while I munch on salty popcorn. Then I come along with my master plan and solutions that management just begs to throw resources into. Then I move onto the next blow up. It’s much more lucrative to be a firewoman when there’s idiots pouring gasoline and throwing matches everywhere.
- oconnor663 5y agoAre there any prominent examples of a library in Haskell being called from an application that's not written in Haskell?
- ParetoOptimal 5y agoI wonder if Pandoc gets used as a shared library much... I think it's usually shelled out to honestly.
- coldtea 5y ago>It's crazy to me that researchers prefer to be published over having world renowned software to their name. You could figure out the fanciest database research, but there was a period where every fancy new NoSQL database was based on BerkeleyDB despite all that, bolstering the reputation of the University of Berkeley. Unless the BerkeleyDB was written based on novel research, it didn't move the state of the art forward, it was just a good, used, embeded database. In which case, your statement can be rewritten as: "It's crazy to me that researchers prefer to be known for their research over being known as developers of popular programs". Doing research is the reason they went to an academic career, if they wanted to be developers, they'd just have gone and be developers. So, why not strike two birds with one stone, and make high quality widely used software that's ALSO state of the art research based? Well, because creating "high quality widely used software" is a different process, and needs different resources, dedication, and even skills, than doing research. To showcase some novel research in practice is much much faster, easier, and cheaper to create "half finished demonstration software", that to create a mature, final, implementation that people can use. So, either they slow their research considerably, and spent most of the time doing software development work - which besides slowing down the pace of research will also count against them in their academic field, they opt to focus on research and just do simple implementation that are not production ready and aren't meant to be. Seen in this light, it's not a "crazy" choice, it's an essential tradeoff.
- adminprof 5y agoIt seems like it's just that the goals are different. Computer science researchers could also make the opposite case, "The underwhelming impact of software development on producing state-of-the-art computer science discoveries."
- eslaught 5y agoThere are some points in the middle, but it's rare. I work on one of these [1]. We've been building the system for over ten years, and are starting to see some truly killer apps being built on top of it [2, 3]. While it has some great benefits once you arrive, the upfront costs are enormous. You need to find a funding source (or sources) that will pay for this product while you're building it. Also, in order for the research payoff to be worth it, you need both the product itself, and subsequent innovations it enables, to be research-worthy. Not all areas of research can support this. On top of it all, even when you do this, you'll still spend years of effort in activities that are essentially not research. You're basically responsible for all of your own customer support, sales, marketing, etc.---like a startup, but without the financial upside if you succeed. Yes there is recognition and so on, but the payoffs aren't as dramatic. Most people aren't ready to commit to this path. Keep in mind that you can't build this in 5 years either. So a single generation of PhD students can't get it done. The only reason we were successful is because the key staff on the project stuck around for 5+ years after our PhDs because we all believed in doing the work. Given all that, I don't hold it against people at all who just want to build prototypes and then move on to the next thing. It's way less risky and higher reward relative to the costs. [1]: https://legion.stanford.edu/ https://legion.stanford.edu/ [2]: https://flexflow.ai/ https://flexflow.ai/ [3]: https://developer.nvidia.com/cunumeric https://developer.nvidia.com/cunumeric
- toast0 5y ago> It's crazy to me that researchers prefer to be published over having world renowned software to their name. If you went into research, you have occupational incentives to publish papers, but not to publish software. As someone who went into applied software, there's a lot of published research that's so disconnected from reality, that it couldn't possibly be useful for anything but publication stats for the named researchers. On the other hand, every once in a while, there's a gem that's useful. My personal favorite is network research where everything was done with models of TCP that aren't at all similar to actual TCP stacks, production or research.
- matthewdgreen 5y agoIf you went into research you did so because you want to solve new problems. With no disrespect to software engineering, most (production) software engineering involves solving old problems over and over again on a daily basis, with genuinely new problems tossed in only from time to time. This is even more the case when you’re maintaining a codebase that’s widely used. There is nothing wrong with solving old problems: that describes most useful human work. It’s just that finding and solving new problems is a very specialized kind of work, and it’s very hard to do that specialist work if you aren’t spending most of your time on it. You need to keep up with the literature and fight to stay at the forefront of your field and you can’t do that as a 20% time position. A good analogy here is like the interplay between a general contractor and a licensed electrician. The contractor could do their own wiring in between framing and drywall (and take the necessary tests and certifications to learn the code), but it usually makes more sense to have specialized contractors come in for that work. Unfortunately the problem described by this article is that the software developers (contractors) aren’t using the output of the researchers. Insofar as this is true it should be addressed. However the answer probably is not to have the specialized researchers do more general software development, which will just make everyone less efficient.
- mjw1007 5y agoThe history of PostgreSQL's SERIALIZABLE isolation level implementation is one example of this going well. As far as I remember, the story went something like this, about ten years ago: - organisation employing a PostgreSQL developer asks "can we have SERIALIZABLE that actually does what it says?" - developer says "nobody has that, it's a hard research problem" - developer looks for recent academic research and finds someone with a proposal that might be efficient enough to be practical - developer contacts the researcher - developer and researcher implement the proposal in PostgreSQL - it turns out the design is in fact practical - PostgreSQL gets a useful feature, researcher gets a paper with the developer as co-author Looks like this is the paper: https://pmg.csail.mit.edu/pubs/ports12__serial_snaps_isolat_postg-abstract.html https://pmg.csail.mit.edu/pubs/ports12__serial_snaps_isolat_...
- lumost 5y agoSoftware collaborations tend to end poorly in Academia from my experience. This is due to most of the day to day boring software work being viewed as "less than" the sexy publishable research. What this means is that academic software projects become spaghetti code messes that no one wants to touch at warp speed.
- jart 5y ago> Despite all the research into garbage collectors nearly every new programming language I've seen uses either BoehmGC (from 1994) or simply gives up on the idea and uses reference counting. Have you ever seen a garbage collector that uses the NSA instruction? https://github.com/jart/cosmopolitan/tree/master/tool/plinko https://github.com/jart/cosmopolitan/tree/master/tool/plinko
- glouwbug 5y agoIsn’t reference counting the obvious implementation? A garbage collector would only free cyclical references
- imtringued 5y agoIt would be more obvious to have a basic toolkit to let everyone build their own GC with LLVM. From my experience with building my own GC. There are only two challenges. Stack unwinding to obtain root references and then the GC strategy (generational GC, mark and sweep, etc). For most people, reimplementing the latter is a waste of their time.
- tinco 5y agoIt's only the obvious solution in the sense that it's not really a solution but it comes close enough that memory often doesn't leak fast enough for it to matter for short running programs. A drop in garbage collector (like Boehm) makes your toy language instantly production ready. Basically code generation and garbage collection are the two things that make language implementation tedious. That's why so many languages are on top of Java or .Net. Implementing a language on those platforms is almost trivial because it solves both code generation and garbage collection.
- makecheck 5y agoAlso, how do you reproduce even the demo software from a paper that’s been out for a year (an eternity in software maintenance time?). Git repo might be gone, some dependency broken, or maybe they used some system that isn’t around anymore.
- chrisseaton 5y ago> Despite all the research into garbage collectors nearly every new programming language I've seen uses either BoehmGC (from 1994) or simply gives up on the idea and uses reference counting. What new language implementations are using Boehm?
- tinco 5y agoTo be fair I hadn't verified it was still true when I wrote the message, and I'll admit all I've seen recently is reference counted languages. It was definitely true when I was exploring C garbage collector options for my projects but that's almost ten years ago. I just checked the wiki and it seems Crystal uses Boehm. You use Java's GC right? Or is there something custom in there now?
- chrisseaton 5y agoI don’t think many new languages emit C or try to use a conservative GC, because they’re both pretty poor options.
- native_samples 5y agoQuite a few "new" languages target the JVM and thus use JVM GCs, which are all state of the art. E.g. Kotlin, Clojure, Scala. And of course then there are the new implementations of other languages, like what Chris works on (Ruby), which also run on the JVM. Most new languages are either high level languages and running on the JVM, or they're attempts to compete with C/C++ like Rust, Swift, Zig etc and thus don't use GC at all. I don't think many people use Boehm anymore.