4 ms·

They specifically said runtime errors. Elm is designed in such a way that runtime errors do not occur. Obviously logic errors etc. are still possible.

goto11 5y ago
So what happens if you divide by 0 in Elm?
- carnitine 5y ago
  For integer division, you get 0 as a result. For floats, it is the Infinity value used by standard implementations. The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).
- cies 5y ago
  You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular. Maybe time to study some of that "hipster stuff". I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).
  - goto11 5y ago
    I'm not knocking Elm at all, I think it is a very interesting language. I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away. A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite. If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.
    - carnitine 5y ago
      It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.
      - goto11 5y ago
        No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug. Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data. JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN. Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there. Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity). But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt. Bottom line: Converting runtime exceptions to logical errors is a very bad trade. I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway. I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.

goto11 5y ago

So what happens if you divide by 0 in Elm?

carnitine 5y ago
For integer division, you get 0 as a result. For floats, it is the Infinity value used by standard implementations. The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).
cies 5y ago
You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular. Maybe time to study some of that "hipster stuff". I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).
- goto11 5y ago
  I'm not knocking Elm at all, I think it is a very interesting language. I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away. A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite. If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.
  - carnitine 5y ago
    It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.
    - goto11 5y ago
      No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug. Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data. JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN. Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there. Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity). But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt. Bottom line: Converting runtime exceptions to logical errors is a very bad trade. I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway. I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.