Obvious and possible software innovations
scottlocklin.wordpress.com
Obvious and possible software innovations
1–10 of 157 posts
Re: Obvious and possible software innovations
#2“He would be hailed as a Jobs-like technical innovator if he had some of his slaves do this, and he would be remembered with gratitude, rather than as the sperdo who dumped his wife for sexorz with lip filler Cthulhu.”
Misogyny is really cool! Thanks Scott Locklin!
Re: Obvious and possible software innovations
#3Rust is not an interpreted language, but it does attempt to satisfy the first point. The bindgen and cxx crates will attempt to generate the API from a C/C++ header file.
Re: Obvious and possible software innovations
#41. Some modern PLs and frameworks are making ffi easier, without requiring writing manual wrappers, or using a code generators. I can't recall project names now, but they do exist. But yes, they're not widely used or supported.
2. BEAM (Erlang VM) has several native mechanisms to communicate with the outside world (both in-process and out-of-process). In-process ones: linked-in drivers (.so/DLL), NIFs (.so/DLL, like JNI), dirty schedulers. Out-of-process: ports (external executables), C-Nodes/JInterface (an Erlang cluster node interface can be written in any programming language, not just C or Java). See [1].
3. Morphing into a Single Image System OS would be ideal evolution for the cloud vendors. I don't think Mainframe or Heroku-style PaaS are good directions, though. I have many ideas in this field, but they need to be fleshed out first.
--
[1] https://www.slideshare.net/nivertech/erlang-on-osv-49278675#...
Re: Obvious and possible software innovations
#5> Cloud providers should admit they’re basically mainframes and write an operating system instead of the ad-hoc collection of horse shit they foist on developers.
Oh I like this one so much. I love the era and idea of the mainframe. I caught the tail end of it in college. Our research professors would send their statistics jobs over to the mainframe and get the dot matrix printouts back showing what treatments showed significance. Maybe I watched Tron too much too. I just love the idea of one big central computer doing all the processing.
Re: Obvious and possible software innovations
#61. Some modern PLs and frameworks are making ffi easier, without requiring writing manual wrappers, or using a code generators. I can't recall project names now, but they do exist. But yes, they're not widely used or supported. 2. BEAM (Erlang VM) has several native mechanisms to communicate with the outside world (both in-process and out-of-process). In-process ones: linked-in drivers (.so/DLL), NIFs (.so/DLL, like…
Do elaborate on (3)?
Re: Obvious and possible software innovations
#7> Really, they should all run like Heroku and you’d never notice they were there.
right that sounds like a great business idea because then your cloud service company you're building will be easier to commoditize! Can't believe that Bezos guy didn't think of it.
Re: Obvious and possible software innovations
#8Feels like a list of stuff where he massively underestimates the complexity of the fields he's talking about.
Drag and drop UIs have, as he indentified, been tried. They were a leaky abstraction where incremental functionality was difficult to implement.
Re: Obvious and possible software innovations
#9I actually really dislike this whole post. There’s a really condescending tone lurking just beneath the surface for most of it. It’s also extremely hand-wavy about the problems, their causes, AND possible solutions. Also, so whiny. At this point I don’t care if he even has any good ideas because he’s made me so mad just by his writing style.
Re: Obvious and possible software innovations
#10> have all the functions described in it turned into reasonably safe FFIed function calls
Many langs get close with the ease of importing C headers (Go, Rust, etc), but once you ask for reasonably safe FFI'd calls, you're asking a bit too much since ownership goes out the window. Otherwise, if you mean turned into acceptably-unsafe FFI'd function calls, agree just about every lang with C interfacing built in should have that.
> It’s fascinating to me that people find it easier to write a pile of React and HTML on top of electron rather than dragging and dropping native widgets for a framework like we did in the old days.
Ok, on my mark, you write a reasonably complex native GUI for the 5 common platforms (and including the wiring, not just drag-drop) and I'll write a reasonably complex GUI w/ web tech. Once you see the difference in time to market, not to mention reduced maintenance cost, it'll be less fascinating.
Other than those points, I somewhat agree w/ the others, or rather don't strongly disagree (the condescending tone notwithstanding).