7 ms·

FWIW I agree that something feels wrong and repetitive, but I don't think Eve addressed my problem at all. A big part of my pain, and the pain I've observed in

by chubot 9y ago

FWIW I agree that something feels wrong and repetitive, but I don't think Eve addressed my problem at all. A big part of my pain, and the pain I've observed in 15 years of industry, is programming language silos. Too much time is spent on "How do I do X in language Y?" rather than just "How do I do X?" For example, people want a web socket server, or a syntax highlighting library, in pure Python, or Go, or JavaScript, etc. It's repetitive and drastically increases the amount of code that has to be maintained, and reduces the overall quality of each solution (e.g. think e-mail parsers, video codecs, spam filters, information retrieval libraries, etc.). There's this tendency of languages to want to be the be-all end-all, i.e. to pretend that they are at the center of the universe. Instead, they should focus on interoperating with other languages (as in the Unix philosophy). Some languages want to be their own operating system, but empirically that doesn't work. The JVM had this explicit goal of "making Windows irrelevant", but instead it ended up as just another process on a Unix system!!! (Something like Mirage in OCaml is an extreme example of this, although I think it's a pretty interesting project.) This only really comes up after you become at least an "intermediate programmer". When I started, I wanted everything to be in my favorite language so it would be easy for me to understand and modify. But now I realize that it's more efficient to be able to reuse the best tool for the job PERIOD, not the best tool for the job in language X. Microsoft actually had some degree of success with this with COM. You can do a surprising amount of automation from JavaScript or Visual BASIC in much the same way. But IMO the "language cacophony" situation is worse on the server side, even though to some extent the problem is easier because you have more computing resources. In this regard, Eve actually makes things worse! I say that every new language makes things locally better, but globally worse. Because you never have a system in just one language. If you think you do, then your view fo the system is too narrow. I'm chipping away at the edges of this problem with http://www.oilshell.org/ http://www.oilshell.org/, but honestly it's not close... I chose to replicate the Unix shell first -- a big success story, though one with many flaws -- and then maybe many years from now, extend it with a form of integration tighter than bytes over pipes.

seanmcdirmid 9y ago
As a counterpoint, this "being interoperable with everything" mindset is predominant. Everyone has an interop story, some languages are all about interop (Lua, before Python). The worse case scenario shows up in Verner Vinge's scifi as the programmer archeologist (see https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky), that all the code that could have been written has been written, and programmers of the future will be more like archeologists sniffing it out. In that future, there is no room for green fields, which I find to be very depressing.
- bri3d 9y ago
  Shouldn't line of business software naturally trend from being a creative pursuit to a standard engineering or trade, where defined systems are applied to a semi-novel problem using known patterns and rules? Rediscovering the whole thing every time is certainly inefficient. I think there will always be room for green fields, though. Even in very old fields scientists and inventors still discover new approaches and solve new problems on a daily basis. Yes, this will move to the fringes, but is that a bad thing? I'd rather spend 10% of my time on research and reimplementation and 90% on a Fun New Problem/Approach rather than 90% of my time reinventing the wheel and 10% of my time on new stuff.
  - seanmcdirmid 9y ago
    I'm pretty sure ML eventually eats the programming cake, though it might not be in our lifetimes. Definitely by the time we have developed FTL travel. We have reached a very pronounced local maxima with our current programming practices and ecosystems. Reinvention can get us out of that, though is more likely to fail than not.
    - actsasbuffoon 9y ago
      Strongly agreed. I've had a fairly long career and worked in dozens of languages. Languages like Crystal (staticly typed, but with strong type inference that makes them feel like a dynamic language) feel like they're from 10 years in the future. Using languages from the ML-family (OCaml, F#, Haskell, Purescript, Elm, Idris, Agda) makes me feel like I've gone 25 years into the future and been set down in front of a computer. Especially watching Idris write my program for me just based on the type signatures. That blows my mind every time it works (which it often does).
- chubot 9y ago
  Well, you can take it too far for sure, but I don't think we're even close. I disagree with most of what you wrote: - There will still be green fields because there are new problems to solve. New languages (and new platforms) are justified for new problems. For example, you will have languages for machine learning, for quantum computing, for computing with security, etc. Microsoft has an interesting P state machine language which adds something new. I would love to free up some of my brain real estate learn those new domains / languages, rather than doing the same thing over and over again in different languages. Although as I understand Eve was a Datalog, and I think that adds something "new". Although making that Datalog interoperate may have been more successful than building a cohesive platform around it (but perhaps contrary to their goals). - "the being interoperable mindset if predominant". I don't agree, e.g. every language has its own package ecosystem. They interoperate (poorly) with C, but not any other language really. The JVM ecosystem is more or less completely distinct than the Go one, although they cover a similar problem space. Likewise for say Rust and Go. - Python's interop story is not great; it is littered with implementation details, There are 10+ wrappers like SWIG, CFFI, ctypes, CLIF, etc. on top of the Python/C API because it's so prickly. Alternative implementations like PyPy don't get much adoption; there is version lock-in with Python 2 vs. 3. Python 2 vs. 3 is a great example of where beginners get stuck in mind-numbing detail and complexity. - Lua was designed with good C interop, but not that's about it too. If anything, it's the exception that proves the rule. It's not a very popular language either, at least 10x less popular than Python, Ruby, JS, etc. So if you agree that much of programming is doing the same thing over and over again in different languages, then it follows that adding new languages doesn't help that. It might help beginners, but it doesn't make things better for working programmers, who write most of the code in the world. I understand that for beginners, you want a coherent experience. Beginners can't learn two languages at once -- that's a very good argument. But I do think there is an economic problem with trying to make a single "cohesive platform" to solve all those problems. Beginners can imagine something that is logically 10 or 20 lines, that will take you 100K lines, 1M, or 10M lines of code to implement on the back end. I think that is the problem Eve ran into -- it's simply too much work to try to interpret extremely high level programs at the level of the user's intention. For example I just wrote a 20-line piece of JavaScript on Google App Scripts, embedded in a spreadsheet, that sends e-mails. It was a surprisingly good experience -- I had low expectations. But I bet there's at least 1M lines of code in the background to make this all work (probably more, having worked at Google), and there's a whole team of SREs, etc. Some of the code in there is 10-15 years old, etc. It's a huge job. In other words, I think Eve was a full-fledged platform, and platforms have problems getting off the ground without a billion dollars. Even if your platform is backed by a big company, it might be hard to gain traction. Google App Engine provided a lot of value and a nice experience, enough that Snapchat was built on it, but I think it faltered in the limited availability of runtimes (it couldn't run PHP for a long time, etc.) In other words it didn't interoperate with the rest of the world enough, and I imagine Eve interoperated even less.
nickpsecurity 9y ago
Definitely more interoperability to get best tool for the job and leverage ecosystems. I'm with you on that. On this... "they should focus on interoperating with other languages (as in the Unix philosophy)." Maybe instead follow the OpenVMS philosophy where they standardized the calling conventions to support multi-language development. http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#intro_32 http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#int... Microsoft's CLR followed that path in the VM space. Got similarly good results. Tools like Racket and mbase do with DSL's where they share underlying LISP-like language to avoid problems with DSL's own weaknesses.
- chubot 9y ago
  Yup I mentioned Microsoft COM (which Mozilla's defunct XPCOM was modelled after). Shared libraries and binary interfaces, rather than C header files. Come to think of it I'd like to see a postmortem on XPCOM. Chrome uses apparently uses more of a build time tool to generate interfaces in both C++ and JavaScript.
- pjmlp 9y ago
  Actually on Windows we have come full circle as those CLR ideas, which were originally thought for COM Runtime, have been brought back into COM as UWP. IBM mainframes also follow the multi-language environment philosophy.
cmontella 9y ago
It was important for us to treat Eve (at least initially) as the whole world, because part of our task was understanding the implications of building programs in this different fashion. Datalog applications have a rich design space for tooling, and after 3 years poking around in the space we barely scratched the surface. The interoperability between a datalog world and the current state of things is another great research question, and one we made some good progress on this front with v0.4, but there was still much left to do in the end.
- actsasbuffoon 9y ago
  Has there been any discussion about open-sourcing Eve? It's a shame to see the project abandoned without at least making it available for other people to try to maintain. It may not find the right set of maintainers, but if the project shuts down without putting the code out there, it will definitely die in darkness.
  - dragonwriter 9y ago
    > Has there been any discussion about open-sourcing Eve? Eve was always open-source and on github, though I'm not sure all the experiments and demos are. https://github.com/witheve https://github.com/witheve
    - cmontella 9y ago
      Experiments are collected here: https://github.com/witheve/eve-experiments https://github.com/witheve/eve-experiments The way it's broken out in this repo corresponds closely to how this blog is presented. Earlier prototypes like Aurora aren't included here though.
hennsen 9y ago
> A big part of my pain, and the pain I've observed in 15 years of industry, is programming language silos. Too much time is spent on "How do I do X in language Y?" rather than just "How do I do X?" Basically it’s right nit to make everything a nail just because you‘ve got a hammer. But also, if you only got a hammer and no/limited ways to get another tool, the question is very well „how can i build a table with just nails“ even though i know with screws it might be easier. If you have a limited amount of developers with limited pre-existing knowledge in languages it’s not so unwise to look for solutions inside the language range of your team. If only one person knows the language one of your components is made in, the risk of becoming unable to maintain that thing is pretty high. Also, If you have only one developer, it’s pretty wise to try to limit the use of languages to those he is very proficient in - and that might be one or two, maybe three - and avoid context switching for syntax and core library functionality.

by chubot 9y ago

seanmcdirmid 9y ago

As a counterpoint, this "being interoperable with everything" mindset is predominant. Everyone has an interop story, some languages are all about interop (Lua, before Python). The worse case scenario shows up in Verner Vinge's scifi as the programmer archeologist (see https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky), that all the code that could have been written has been written, and programmers of the future will be more like archeologists sniffing it out. In that future, there is no room for green fields, which I find to be very depressing.

bri3d 9y ago
Shouldn't line of business software naturally trend from being a creative pursuit to a standard engineering or trade, where defined systems are applied to a semi-novel problem using known patterns and rules? Rediscovering the whole thing every time is certainly inefficient. I think there will always be room for green fields, though. Even in very old fields scientists and inventors still discover new approaches and solve new problems on a daily basis. Yes, this will move to the fringes, but is that a bad thing? I'd rather spend 10% of my time on research and reimplementation and 90% on a Fun New Problem/Approach rather than 90% of my time reinventing the wheel and 10% of my time on new stuff.
- seanmcdirmid 9y ago
  I'm pretty sure ML eventually eats the programming cake, though it might not be in our lifetimes. Definitely by the time we have developed FTL travel. We have reached a very pronounced local maxima with our current programming practices and ecosystems. Reinvention can get us out of that, though is more likely to fail than not.
  - actsasbuffoon 9y ago
    Strongly agreed. I've had a fairly long career and worked in dozens of languages. Languages like Crystal (staticly typed, but with strong type inference that makes them feel like a dynamic language) feel like they're from 10 years in the future. Using languages from the ML-family (OCaml, F#, Haskell, Purescript, Elm, Idris, Agda) makes me feel like I've gone 25 years into the future and been set down in front of a computer. Especially watching Idris write my program for me just based on the type signatures. That blows my mind every time it works (which it often does).
chubot 9y ago
Well, you can take it too far for sure, but I don't think we're even close. I disagree with most of what you wrote: - There will still be green fields because there are new problems to solve. New languages (and new platforms) are justified for new problems. For example, you will have languages for machine learning, for quantum computing, for computing with security, etc. Microsoft has an interesting P state machine language which adds something new. I would love to free up some of my brain real estate learn those new domains / languages, rather than doing the same thing over and over again in different languages. Although as I understand Eve was a Datalog, and I think that adds something "new". Although making that Datalog interoperate may have been more successful than building a cohesive platform around it (but perhaps contrary to their goals). - "the being interoperable mindset if predominant". I don't agree, e.g. every language has its own package ecosystem. They interoperate (poorly) with C, but not any other language really. The JVM ecosystem is more or less completely distinct than the Go one, although they cover a similar problem space. Likewise for say Rust and Go. - Python's interop story is not great; it is littered with implementation details, There are 10+ wrappers like SWIG, CFFI, ctypes, CLIF, etc. on top of the Python/C API because it's so prickly. Alternative implementations like PyPy don't get much adoption; there is version lock-in with Python 2 vs. 3. Python 2 vs. 3 is a great example of where beginners get stuck in mind-numbing detail and complexity. - Lua was designed with good C interop, but not that's about it too. If anything, it's the exception that proves the rule. It's not a very popular language either, at least 10x less popular than Python, Ruby, JS, etc. So if you agree that much of programming is doing the same thing over and over again in different languages, then it follows that adding new languages doesn't help that. It might help beginners, but it doesn't make things better for working programmers, who write most of the code in the world. I understand that for beginners, you want a coherent experience. Beginners can't learn two languages at once -- that's a very good argument. But I do think there is an economic problem with trying to make a single "cohesive platform" to solve all those problems. Beginners can imagine something that is logically 10 or 20 lines, that will take you 100K lines, 1M, or 10M lines of code to implement on the back end. I think that is the problem Eve ran into -- it's simply too much work to try to interpret extremely high level programs at the level of the user's intention. For example I just wrote a 20-line piece of JavaScript on Google App Scripts, embedded in a spreadsheet, that sends e-mails. It was a surprisingly good experience -- I had low expectations. But I bet there's at least 1M lines of code in the background to make this all work (probably more, having worked at Google), and there's a whole team of SREs, etc. Some of the code in there is 10-15 years old, etc. It's a huge job. In other words, I think Eve was a full-fledged platform, and platforms have problems getting off the ground without a billion dollars. Even if your platform is backed by a big company, it might be hard to gain traction. Google App Engine provided a lot of value and a nice experience, enough that Snapchat was built on it, but I think it faltered in the limited availability of runtimes (it couldn't run PHP for a long time, etc.) In other words it didn't interoperate with the rest of the world enough, and I imagine Eve interoperated even less.

nickpsecurity 9y ago

Definitely more interoperability to get best tool for the job and leverage ecosystems. I'm with you on that. On this... "they should focus on interoperating with other languages (as in the Unix philosophy)." Maybe instead follow the OpenVMS philosophy where they standardized the calling conventions to support multi-language development. http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#intro_32 http://h41379.www4.hpe.com/doc/82final/5973/5973pro.html#int... Microsoft's CLR followed that path in the VM space. Got similarly good results. Tools like Racket and mbase do with DSL's where they share underlying LISP-like language to avoid problems with DSL's own weaknesses.

chubot 9y ago
Yup I mentioned Microsoft COM (which Mozilla's defunct XPCOM was modelled after). Shared libraries and binary interfaces, rather than C header files. Come to think of it I'd like to see a postmortem on XPCOM. Chrome uses apparently uses more of a build time tool to generate interfaces in both C++ and JavaScript.
pjmlp 9y ago
Actually on Windows we have come full circle as those CLR ideas, which were originally thought for COM Runtime, have been brought back into COM as UWP. IBM mainframes also follow the multi-language environment philosophy.

cmontella 9y ago

It was important for us to treat Eve (at least initially) as the whole world, because part of our task was understanding the implications of building programs in this different fashion. Datalog applications have a rich design space for tooling, and after 3 years poking around in the space we barely scratched the surface. The interoperability between a datalog world and the current state of things is another great research question, and one we made some good progress on this front with v0.4, but there was still much left to do in the end.

actsasbuffoon 9y ago
Has there been any discussion about open-sourcing Eve? It's a shame to see the project abandoned without at least making it available for other people to try to maintain. It may not find the right set of maintainers, but if the project shuts down without putting the code out there, it will definitely die in darkness.
- dragonwriter 9y ago
  > Has there been any discussion about open-sourcing Eve? Eve was always open-source and on github, though I'm not sure all the experiments and demos are. https://github.com/witheve https://github.com/witheve
  - cmontella 9y ago
    Experiments are collected here: https://github.com/witheve/eve-experiments https://github.com/witheve/eve-experiments The way it's broken out in this repo corresponds closely to how this blog is presented. Earlier prototypes like Aurora aren't included here though.

hennsen 9y ago

> A big part of my pain, and the pain I've observed in 15 years of industry, is programming language silos. Too much time is spent on "How do I do X in language Y?" rather than just "How do I do X?" Basically it’s right nit to make everything a nail just because you‘ve got a hammer. But also, if you only got a hammer and no/limited ways to get another tool, the question is very well „how can i build a table with just nails“ even though i know with screws it might be easier. If you have a limited amount of developers with limited pre-existing knowledge in languages it’s not so unwise to look for solutions inside the language range of your team. If only one person knows the language one of your components is made in, the risk of becoming unable to maintain that thing is pretty high. Also, If you have only one developer, it’s pretty wise to try to limit the use of languages to those he is very proficient in - and that might be one or two, maybe three - and avoid context switching for syntax and core library functionality.