7 ms·

My view of this is: all of us who have written a lot of code feel intuitively there is something wrong with how coding is done. It feels like we are repeating t

by jng 9y ago

My view of this is: all of us who have written a lot of code feel intuitively there is something wrong with how coding is done. It feels like we are repeating too much work every time, reinventing the wheel for the umpteenth time. It feels like the tools and notations we have are missing something fundamental and thus forcing extra menial work that is not essentially necessary. Eve was one of the multiple attempts at converting that intuition in actual knowledge and in an actual product. They weren't able to do it, same as Intentional Software and others before them, but they explored uncharted territory using that intuition, and that is an interesting exploration. Kudos to them for trying. And hopefully someone will find the underlying core concepts we're missing to make that leap into future programming!

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).
seanmcdirmid 9y ago
Did intentional software officially fail? It feels like they are still going and have some kind of product.
- borplk 9y ago
  They sold to Microsoft. My guess is Microsoft is going to kill it.
nextos 9y ago
I love some of the work Alan Kay and others are doing at http://vpri.org/ http://vpri.org/. His work on STEPS is trying to produce a whole working environment in 20 KLOC through heavy use of DSLs. I hate programming silos. I think the world would be a much better place with good platforms, where libraries can interop easily and everything feels so integrated. Emacs is a watered-down reminiscence of this approach.
- undecidabot 9y ago
  Just to clarify, the STEPS Project has ended (Oct 2012). HN had a discussion on their final report not too long ago: https://news.ycombinator.com/item?id=11686325 https://news.ycombinator.com/item?id=11686325
runT1ME 9y ago
I honestly don’t feel this way most of the time when doing pure FP. There are a few tools I wish were better but my code reuse is astounding, the refactor-ability is high, and it is easy to jump into unfamiliar code bases. Just mho from the experiences I’ve had.
- cmontella 9y ago
  I think that's because FP does a number of things right, like immutability, which leads to better composability of programs. These two aspects were what gave Eve a lot of its nice properties.
borplk 9y ago
One of the biggest problems is the flat one-dimensional aspect of text files. Overly-graphical solutions are clunky and not concise enough. However overly-flat environments like a plain text file also comes with huge problems. What I have wanted forever is a smart environment that looks similar to a text editor but under the hood it's more of a structure editor (wayyy easier said than done). Two main problems with text is, 1. parsing 2. inability to easily associate metadata with parts of the program without visual/syntax clutter I'll expand on each point, Parsing: parsing implies syntax and language structure and it causes inflexibility. the problem domain is infinite but we have only so many characters to work with. this creates some blessed first class concepts like "strings" and puts everything else at a disadvantage. A smart structure editor can bypass the parsing problem. It comes at the cost of some fluidity in the authoring process because effectively you would have to say what you are about to place somewhere before placing it. So instead of typing "string" you would have to somehow say "here comes a string", then provide its value. The problem with this is the fast text-based editing and typing that we are used to becomes difficult and clunky. Metadata: This is a big topic. But to give a summary, this gives us a way to have information present that doesn't get in the way. For example consider an assignment 'name := "John"'. When we are stuck in a flat environment if you want to make that assignment a "const" now you have to turn that into 'const name := "John"'. In many cases there are lots of attributes and extra information that you would like to attach to a piece of the program. You don't necessarily want to invent words and keywords and language rules for them. You also don't necessarily want to always see all of them. If we could easily attach metadata to the pieces of the program it would obviate the need for many language complexities as many things could be turned into metadata key values. So if you wanted to make a name binding constant you could set "is mutable := no" on that part. Once you have the ability to associate arbitrary and not arbitrary metadata to any piece of the program it opens up so many opportunities.
mhomde 9y ago
I think one of the main problems is that we still describe too much of "How" we want to do something, rather than "What we want to do", ie too many implementation details are specified. Programming languages over time have moved towards higher layers of abstraction, from punch cards, to assembler, to c, to c++, to java/c# etc etc. We haven't done the next leap yet and come up with a mainstream descriptive language that allows us to abstract away things like threading, tasks and optimizations. If programming was even more about declaring intent a lot of work could be simplified I think. We could also put more intelligence into the interpreters/compilers and even adapt execution for different scenarios
lmm 9y ago
I see all these efforts to recreate programming with a new way of doing it as foolishness; it's the "let's rewrite the system from the ground up" fallacy writ large. Want to see some really interesting "visual" functionality that you can actually use to write useful apps? Take a look at the things IntelliJ is doing with Scala: https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-plugin-2018-1-inline-hints-better-structure-view-improved-refactoring-and-greater-usability/ https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-p... . Today one programs in a way that makes extensive use of the GUI, to the point that the code is difficult to work with in a plain text editor, but everything's been put on as a progressive enhancement starting from thinks that were known working and addressing the concrete pain points.
- tormeh 9y ago
  Ok, I'm impressed. If there ever was a good argument for using an IDE over a text editor, this is it.

by jng 9y ago

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).

seanmcdirmid 9y ago

Did intentional software officially fail? It feels like they are still going and have some kind of product.

borplk 9y ago
They sold to Microsoft. My guess is Microsoft is going to kill it.

nextos 9y ago

I love some of the work Alan Kay and others are doing at http://vpri.org/ http://vpri.org/. His work on STEPS is trying to produce a whole working environment in 20 KLOC through heavy use of DSLs. I hate programming silos. I think the world would be a much better place with good platforms, where libraries can interop easily and everything feels so integrated. Emacs is a watered-down reminiscence of this approach.

undecidabot 9y ago
Just to clarify, the STEPS Project has ended (Oct 2012). HN had a discussion on their final report not too long ago: https://news.ycombinator.com/item?id=11686325 https://news.ycombinator.com/item?id=11686325

runT1ME 9y ago

I honestly don’t feel this way most of the time when doing pure FP. There are a few tools I wish were better but my code reuse is astounding, the refactor-ability is high, and it is easy to jump into unfamiliar code bases. Just mho from the experiences I’ve had.

cmontella 9y ago
I think that's because FP does a number of things right, like immutability, which leads to better composability of programs. These two aspects were what gave Eve a lot of its nice properties.

borplk 9y ago

One of the biggest problems is the flat one-dimensional aspect of text files. Overly-graphical solutions are clunky and not concise enough. However overly-flat environments like a plain text file also comes with huge problems. What I have wanted forever is a smart environment that looks similar to a text editor but under the hood it's more of a structure editor (wayyy easier said than done). Two main problems with text is, 1. parsing 2. inability to easily associate metadata with parts of the program without visual/syntax clutter I'll expand on each point, Parsing: parsing implies syntax and language structure and it causes inflexibility. the problem domain is infinite but we have only so many characters to work with. this creates some blessed first class concepts like "strings" and puts everything else at a disadvantage. A smart structure editor can bypass the parsing problem. It comes at the cost of some fluidity in the authoring process because effectively you would have to say what you are about to place somewhere before placing it. So instead of typing "string" you would have to somehow say "here comes a string", then provide its value. The problem with this is the fast text-based editing and typing that we are used to becomes difficult and clunky. Metadata: This is a big topic. But to give a summary, this gives us a way to have information present that doesn't get in the way. For example consider an assignment 'name := "John"'. When we are stuck in a flat environment if you want to make that assignment a "const" now you have to turn that into 'const name := "John"'. In many cases there are lots of attributes and extra information that you would like to attach to a piece of the program. You don't necessarily want to invent words and keywords and language rules for them. You also don't necessarily want to always see all of them. If we could easily attach metadata to the pieces of the program it would obviate the need for many language complexities as many things could be turned into metadata key values. So if you wanted to make a name binding constant you could set "is mutable := no" on that part. Once you have the ability to associate arbitrary and not arbitrary metadata to any piece of the program it opens up so many opportunities.

mhomde 9y ago

I think one of the main problems is that we still describe too much of "How" we want to do something, rather than "What we want to do", ie too many implementation details are specified. Programming languages over time have moved towards higher layers of abstraction, from punch cards, to assembler, to c, to c++, to java/c# etc etc. We haven't done the next leap yet and come up with a mainstream descriptive language that allows us to abstract away things like threading, tasks and optimizations. If programming was even more about declaring intent a lot of work could be simplified I think. We could also put more intelligence into the interpreters/compilers and even adapt execution for different scenarios

lmm 9y ago

I see all these efforts to recreate programming with a new way of doing it as foolishness; it's the "let's rewrite the system from the ground up" fallacy writ large. Want to see some really interesting "visual" functionality that you can actually use to write useful apps? Take a look at the things IntelliJ is doing with Scala: https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-plugin-2018-1-inline-hints-better-structure-view-improved-refactoring-and-greater-usability/ https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-p... . Today one programs in a way that makes extensive use of the GUI, to the point that the code is difficult to work with in a plain text editor, but everything's been put on as a progressive enhancement starting from thinks that were known working and addressing the concrete pain points.

tormeh 9y ago
Ok, I'm impressed. If there ever was a good argument for using an IDE over a text editor, this is it.