8 ms·

I'm excited to see another option appear in text editing, and excited that it's written in Haskell, one of my favorite languages. But, why would I choose it ove

I'm excited to see another option appear in text editing, and excited that it's written in Haskell, one of my favorite languages. But, why would I choose it over another text editor? The ability to customize it is neat, but editors like emacs can be customized to one's heart's content, and indeed can suffer from this (why did my editor suddenly become slow? why is my syntax highlighting or indentation not working correctly? who knows, it's the interaction of one of the 50 packages I have installed...). Of course, you as the author are under no obligation save to write whatever you want, but speaking personally, I would love to see some sort of demonstration of how the editor works, and/or the case made selling me on why I should choose it over other options.

rcthompson 10y ago
I will say this for Emacs, though: while bad interactions between packages do happen, they're surprisingly rare given the number and variety of packages that are available.
- mpweiher 10y ago
  That seems to be generally the case for the horrors of dynamic typing: rampant in the imagination, surprisingly rare in the real world. http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html http://blog.metaobject.com/2014/06/the-safyness-of-static-ty...
  - progman 10y ago
    This confirms my own experience. I discovered that programs written in (or use) dynamic languages like Lisp are surprisingly reliable (Emacs in particular). Type safety won't protect us from broken software. Quote: "The most common bugs caught by static typing are also the least critical sort of bug." Source: http://www.drmaciver.com/2016/10/static-typing-will-not-save-us-from-broken-software/ http://www.drmaciver.com/2016/10/static-typing-will-not-save... Static typing helps a lot to catch basic type errors but it is surely not the "Messiah" of code safety. In big systems the good old way of testing still seems to be the best practical way. Haskell's claim "If it runs then it's likely correct" is a deception because no compiler can catch logical errors. This was also Ada's problem in the Ariane disaster, although Ada has probably the strongest type system beside Haskell. You need special verification tools like FramaC, and even those tools don't catch all errors. Haskell's safety is even more questionable in face of the underlying libraries which are written in C. Finally, the still unresolved Cabal hell speaks for itself. Stack works only because it is an isolated repository where the maintainers have to take a lot of attention to make sure that new code doesn't break other code.
    - mpweiher 10y ago
      > Static typing helps a lot to catch basic type errors > but it is surely not the "Messiah" of code safety. I've been wondering why that is, and one reason I can think of is that testing verifies values. This also implicitly verifies the types of those values.
      - codygman 10y ago
        The type system can verify values as well, but can do so more exhaustively than you can practically test.
    - dllthomas 10y ago
      > Haskell's claim "If it runs then it's likely correct" is a deception This is missing some context. If we generate random functions until we find one that compiles, of course it's not "likely correct". But that's not what people are doing - they are setting out to write correct code. If the types they use exclude functions that are almost correct, then it's likely when they actually hit something that compiles it will also be something that's correct. All of that said, it's true that the claim is sometimes made more strongly than it deserves to be. > because no compiler can catch logical errors. Not without my help. But I can certainly write my code such that the compiler will catch certain logical errors I'm likely to make. I have a pile of examples, but not the time to elaborate - I'll add them later.
      - btam 10y ago
        > I have a pile of examples, but not the time to elaborate - I'll add them later. Please don't forget to share, this sounds very interesting to me as a novice.
        dllthomas 10y ago
        Added as a reply to my earlier comment :)
      - dllthomas 10y ago
  - saosebastiao 10y ago
    Of course in production software type errors are rare. They're generally the first errors that pop up during debugging or testing. Which means the primary benefit of a basic static type system is speeding up the feedback loop of finding all your type errors, and reducing the need for testing. The funny thing about that blog post is that the top 25 bugs "don't look like" type errors to the author, but almost all of them are type errors given some type system and type definition...and not just theoretical, but by existing languages and usages. Buffer overflow, for example, isn't a "type error" according to C, but it is according to Rust. As type systems become stronger and more advanced, more errors become type errors, which means you'll only recognize them as type errors if you use languages and constructs that make them type errors.
    - mpweiher 10y ago
      > Of course in production software type errors are rare. Not according to static-typing fundamentalists. > They're generally the first errors that pop up during debugging or testing. Exactly, and dynamic languages tend to be highly interactive, whereas most languages with highly evolved static type systems tend to have very slow compilers. So the idea that the compiler for that language gives you useful feedback before your dynamic system gives you feedback from actually running the code is at best dubious. > ...but almost all of them are type errors I think you are confusing type errors with modeling errors, but that's very common.
      - uglycoyote 10y ago
        Hi... Static typing fundamentalist here. > So the idea that the compiler for that language gives you useful feedback before your dynamic system gives you feedback from actually running the code is at best dubious. It depends highly on how long it takes to run the code. I work on large pieces of software both static and dynamic which can take a long time to restart and test after changing the code. (far longer than the turnaround time for a static-language change-and-recompile turnaround). In the dynamic systems it frequently takes all day to make what should be a simple change because the turnaround time to test for simple errors is so lengthy and it requires multiple tries just to get it to "compile" (I use this word in a loose sense since there's no compiler but I say "compile" meaning types are correct, I'm calling functions that actually exist, accessing data members that actually exist, free of usages of undefined variables etc.). Not only does it take far longer to purge all of the errors from the newly written code in dynamic languages but I also find that when working with dynamic code that I didn't write myself, the lack of explorability (either manually or IDE-driven) hinders understanding of the code and therefore writing new code involves much more guesswork, which means I write far more incorrect code in the dynamic language. Once the code gets to the point where it is "production ready" it's usually free of these sort of errors -- whether it is written in a dynamic or static language. Otherwise, it would fail and by definition would not meet the label of "production ready". So I would tend to agree with the grandparent's statement that "in production software type errors are rare". The type of software that I work on though tends to be in house software that's a bit more bleeding edge -- it's constantly being adapted to be used in new situations, needing to be changed, and never quite meeting the label "production ready" in that it's not something that QA would approve of and we would ship to other users. For this kind of software, I would say that the parts written in dynamic languages have far more latent type errors than the static code. These a little landmines that don't occur in the everyday use of the software but users step on all the time when they hit edge cases that no coder had enough imagination to test for. In my own experience, writing code in a dynamic language can be faster than in a static language, but this usually falls apart around the point where the code gets to the point of being more than will fit on one monitor screen, or more than will fit in one person's head at any time. That's the point where in the dynamic language you start having to guess things, and in the static language the computer helps you avoid the guesswork. I would disagree with your point about slow compilers, because for smallish codebases static compilers are practically instantaneous anyhow, and for large ones the cost of compilation in still much smaller than the cost of one testing iteration of the application.
lomnakkus 10y ago
As you note E-lisp is very hard to write correctly when everything has to work together, but even just the dynamic typing and dynamic scope often gets in the way of correctness. It's only through Herculean effort on the part of the maintainers that these things even work -- it's pretty instructive to look at the issue trackers for some of the larger e-lisp projects, e.g. magit. It remains to be seen whether this editor can change that, but if the API/Plugin boundaries are strongly typed, I'd be reasonably optimistic that it's at least plausible that it could :).
- barrkel 10y ago
  Dynamic scoping and typing is what makes Emacs easier to extend, rather than harder. It's not unusual for users to fix bugs and performance problems in Emacs packages with some choice redefinitions, global or scoped. A typed API on the other hand will prescribe interactions between extensions. It's still possible with the right design to make things flexible - eg getting extensions to describe their logic in the form of data that can be modified by other extensions - but I think the axis will be between Emacs style flexibility vs rigidity of extension.
  - progman 10y ago
    Interestingly, Emacs is probably the most reliable editor ever. I had not a single crash in 25+ years in daily use in Linux!
  - lomnakkus 10y ago
    > Dynamic scoping and typing is what makes Emacs easier to extend, rather than harder. I think that's what this new editor is trying to test. I'm certainly not convinced that that's true. :) > It's not unusual for users to fix bugs and performance problems in Emacs packages with some choice redefinitions, global or scoped. Maybe those bugs shouldn't have existed in the first place? I'm don't want to be fixing bugs in my editor -- I just want it work properly. While outright crashes (as in SEGV) have been rare, there have been loads of times emacs has just gone into an infinite loop, times where functions get the wrong type (or number of) arguments and you just get some weird "argp" (or whatever) error message in the status bar. I don't think I'm an anomaly -- especially since I use very few extensions (at least AFAICT compared to what some real power-users do). > A typed API on the other hand will prescribe interactions between extensions. It's still possible with the right design to make things flexible - eg getting extensions to describe their logic in the form of data that can be modified by other extensions - but I think the axis will be between Emacs style flexibility vs rigidity of extension. The thing is: The API exists has some restrictions whether one formalizes them or not -- the difference is that in one case you'll just get weird/buggy behavior whereas in the other you'll get a compilation error. If it's possible to formalize something "generic enough" is an interesting question.

rcthompson 10y ago

I will say this for Emacs, though: while bad interactions between packages do happen, they're surprisingly rare given the number and variety of packages that are available.

mpweiher 10y ago
That seems to be generally the case for the horrors of dynamic typing: rampant in the imagination, surprisingly rare in the real world. http://blog.metaobject.com/2014/06/the-safyness-of-static-typing.html http://blog.metaobject.com/2014/06/the-safyness-of-static-ty...
- progman 10y ago
  This confirms my own experience. I discovered that programs written in (or use) dynamic languages like Lisp are surprisingly reliable (Emacs in particular). Type safety won't protect us from broken software. Quote: "The most common bugs caught by static typing are also the least critical sort of bug." Source: http://www.drmaciver.com/2016/10/static-typing-will-not-save-us-from-broken-software/ http://www.drmaciver.com/2016/10/static-typing-will-not-save... Static typing helps a lot to catch basic type errors but it is surely not the "Messiah" of code safety. In big systems the good old way of testing still seems to be the best practical way. Haskell's claim "If it runs then it's likely correct" is a deception because no compiler can catch logical errors. This was also Ada's problem in the Ariane disaster, although Ada has probably the strongest type system beside Haskell. You need special verification tools like FramaC, and even those tools don't catch all errors. Haskell's safety is even more questionable in face of the underlying libraries which are written in C. Finally, the still unresolved Cabal hell speaks for itself. Stack works only because it is an isolated repository where the maintainers have to take a lot of attention to make sure that new code doesn't break other code.
  - mpweiher 10y ago
    > Static typing helps a lot to catch basic type errors > but it is surely not the "Messiah" of code safety. I've been wondering why that is, and one reason I can think of is that testing verifies values. This also implicitly verifies the types of those values.
    - codygman 10y ago
      The type system can verify values as well, but can do so more exhaustively than you can practically test.
  - dllthomas 10y ago
    > Haskell's claim "If it runs then it's likely correct" is a deception This is missing some context. If we generate random functions until we find one that compiles, of course it's not "likely correct". But that's not what people are doing - they are setting out to write correct code. If the types they use exclude functions that are almost correct, then it's likely when they actually hit something that compiles it will also be something that's correct. All of that said, it's true that the claim is sometimes made more strongly than it deserves to be. > because no compiler can catch logical errors. Not without my help. But I can certainly write my code such that the compiler will catch certain logical errors I'm likely to make. I have a pile of examples, but not the time to elaborate - I'll add them later.
    - btam 10y ago
      > I have a pile of examples, but not the time to elaborate - I'll add them later. Please don't forget to share, this sounds very interesting to me as a novice.
      - dllthomas 10y ago
        Added as a reply to my earlier comment :)
    - dllthomas 10y ago
- saosebastiao 10y ago
  Of course in production software type errors are rare. They're generally the first errors that pop up during debugging or testing. Which means the primary benefit of a basic static type system is speeding up the feedback loop of finding all your type errors, and reducing the need for testing. The funny thing about that blog post is that the top 25 bugs "don't look like" type errors to the author, but almost all of them are type errors given some type system and type definition...and not just theoretical, but by existing languages and usages. Buffer overflow, for example, isn't a "type error" according to C, but it is according to Rust. As type systems become stronger and more advanced, more errors become type errors, which means you'll only recognize them as type errors if you use languages and constructs that make them type errors.
  - mpweiher 10y ago
    > Of course in production software type errors are rare. Not according to static-typing fundamentalists. > They're generally the first errors that pop up during debugging or testing. Exactly, and dynamic languages tend to be highly interactive, whereas most languages with highly evolved static type systems tend to have very slow compilers. So the idea that the compiler for that language gives you useful feedback before your dynamic system gives you feedback from actually running the code is at best dubious. > ...but almost all of them are type errors I think you are confusing type errors with modeling errors, but that's very common.
    - uglycoyote 10y ago
      Hi... Static typing fundamentalist here. > So the idea that the compiler for that language gives you useful feedback before your dynamic system gives you feedback from actually running the code is at best dubious. It depends highly on how long it takes to run the code. I work on large pieces of software both static and dynamic which can take a long time to restart and test after changing the code. (far longer than the turnaround time for a static-language change-and-recompile turnaround). In the dynamic systems it frequently takes all day to make what should be a simple change because the turnaround time to test for simple errors is so lengthy and it requires multiple tries just to get it to "compile" (I use this word in a loose sense since there's no compiler but I say "compile" meaning types are correct, I'm calling functions that actually exist, accessing data members that actually exist, free of usages of undefined variables etc.). Not only does it take far longer to purge all of the errors from the newly written code in dynamic languages but I also find that when working with dynamic code that I didn't write myself, the lack of explorability (either manually or IDE-driven) hinders understanding of the code and therefore writing new code involves much more guesswork, which means I write far more incorrect code in the dynamic language. Once the code gets to the point where it is "production ready" it's usually free of these sort of errors -- whether it is written in a dynamic or static language. Otherwise, it would fail and by definition would not meet the label of "production ready". So I would tend to agree with the grandparent's statement that "in production software type errors are rare". The type of software that I work on though tends to be in house software that's a bit more bleeding edge -- it's constantly being adapted to be used in new situations, needing to be changed, and never quite meeting the label "production ready" in that it's not something that QA would approve of and we would ship to other users. For this kind of software, I would say that the parts written in dynamic languages have far more latent type errors than the static code. These a little landmines that don't occur in the everyday use of the software but users step on all the time when they hit edge cases that no coder had enough imagination to test for. In my own experience, writing code in a dynamic language can be faster than in a static language, but this usually falls apart around the point where the code gets to the point of being more than will fit on one monitor screen, or more than will fit in one person's head at any time. That's the point where in the dynamic language you start having to guess things, and in the static language the computer helps you avoid the guesswork. I would disagree with your point about slow compilers, because for smallish codebases static compilers are practically instantaneous anyhow, and for large ones the cost of compilation in still much smaller than the cost of one testing iteration of the application.

lomnakkus 10y ago

As you note E-lisp is very hard to write correctly when everything has to work together, but even just the dynamic typing and dynamic scope often gets in the way of correctness. It's only through Herculean effort on the part of the maintainers that these things even work -- it's pretty instructive to look at the issue trackers for some of the larger e-lisp projects, e.g. magit. It remains to be seen whether this editor can change that, but if the API/Plugin boundaries are strongly typed, I'd be reasonably optimistic that it's at least plausible that it could :).

barrkel 10y ago
Dynamic scoping and typing is what makes Emacs easier to extend, rather than harder. It's not unusual for users to fix bugs and performance problems in Emacs packages with some choice redefinitions, global or scoped. A typed API on the other hand will prescribe interactions between extensions. It's still possible with the right design to make things flexible - eg getting extensions to describe their logic in the form of data that can be modified by other extensions - but I think the axis will be between Emacs style flexibility vs rigidity of extension.
- progman 10y ago
  Interestingly, Emacs is probably the most reliable editor ever. I had not a single crash in 25+ years in daily use in Linux!
- lomnakkus 10y ago
  > Dynamic scoping and typing is what makes Emacs easier to extend, rather than harder. I think that's what this new editor is trying to test. I'm certainly not convinced that that's true. :) > It's not unusual for users to fix bugs and performance problems in Emacs packages with some choice redefinitions, global or scoped. Maybe those bugs shouldn't have existed in the first place? I'm don't want to be fixing bugs in my editor -- I just want it work properly. While outright crashes (as in SEGV) have been rare, there have been loads of times emacs has just gone into an infinite loop, times where functions get the wrong type (or number of) arguments and you just get some weird "argp" (or whatever) error message in the status bar. I don't think I'm an anomaly -- especially since I use very few extensions (at least AFAICT compared to what some real power-users do). > A typed API on the other hand will prescribe interactions between extensions. It's still possible with the right design to make things flexible - eg getting extensions to describe their logic in the form of data that can be modified by other extensions - but I think the axis will be between Emacs style flexibility vs rigidity of extension. The thing is: The API exists has some restrictions whether one formalizes them or not -- the difference is that in one case you'll just get weird/buggy behavior whereas in the other you'll get a compilation error. If it's possible to formalize something "generic enough" is an interesting question.