5 ms·

It not "appears", it is generic. As generic as it could be. This particular line is also a generator comprehension which produces a lazy sequence. Run-time er

by lngnmn 10y ago

It not "appears", it is generic. As generic as it could be. This particular line is also a generator comprehension which produces a lazy sequence. Run-time errors and so-called null-propagation are well-known issues and once code passed unit tests it is no less trustworthy in principle than statically-typed one. In the first run, yes, there is a chance of a run-time error. The dynamic languages, notably Lisps, Erlang, Python and Ruby are proved to be superior for quick prototyping and so-called exploratory programming, which has been popularized by pg, along with bottom-up design and the layered-DSLs architecture, in the OnLisp book. Another classic example is Norvig's Design Patterns in Dynamic Languages which basically ridiculed the whole thing. There are distinct cultures around MIT Scheme and Common Lisp, Smalltalk and now Python which emphasize expressiveness, minimalism and readability. Such an erudite like you should know this.

coldtea 10y ago
>It not "appears", it is generic. As generic as it could be Only in the sense that accepting arguments that it shouldn't accept and it'll crash with, is part of the general description of the filtering operation -- which is not. If you prefer, it's "more generic" than it should be. It's not a generic description of the "filter" operation, but a generic description of the "process_input_and_produce_output" operation. >The dynamic languages, notably Lisps, Erlang, Python and Ruby are proved to be superior for quick prototyping and so-called exploratory programming Where is that proof published? And what methodology did it follow? Since, you know, we are computer SCIENTISTS and all...
- lngnmn 10y ago
  > what methodology did it follow? http://erlang.org/download/armstrong_thesis_2003.pdf http://norvig.com/java-lisp.html http://arclanguage.org/ http://old.ycombinator.com/viaweb/ Yes, 'proved' was a too strong claim. A few exceptionally good systems has been produced, notably Symbolics CL, Smalltalk, Erlang and Clojure, which after removing all the hype and snowflakery, is a remarkable thing.
- rdtsc 10y ago
  > are proved to be superior for quick prototyping and so-called exploratory programming Not OP and I don't have proof but I always reach for Python for exploratory programming or a quick "let's try and see what happens". Not sure if types are part of it or not, maybe it is just terseness -- the code is closer to pseudo-code. I hope one day to learn Rust enough to internalize the type and borrowing system so that I can crank things out just as fast (and hey'd be more reliable and faster out of the door) but I am not there yet. > Only in the sense that accepting arguments that it shouldn't accept and it'll crash with Now on that point I think it is not just types. Types are a part of it. C has types and systems written in it crash and segfault all the time. Likewise C++ and so on. Maybe Rust is one new-comer where types and lifetimes would make a difference in practice. However since OP mentioned Erlang, I'd would it is possible to write more reliable systems in Erlang (Elixir as well perhaps) than in C++ or Java or other such typed systems. I have seen it work in practice, and Ericsson's customers have seen systems work for years with 99.9999999% reliability. Now Erlang has optional types (the more annotations you add the more benefit you get from), but in practice isolated heaps, built-in distribution, solid error logging and reporting, sane concurrency model make a lot more difference.
  - cormacrelf 10y ago
    Back when I was good at Haskell, I would actually use it for exploratory stuff. At the time I think it mostly came down to which standard library I knew better. Python has a huge stdlib, but I actually find prototyping difficult as I don't have my head in the game in terms of what function on X can I use for this purpose, what's the syntax for that again. Python has quite a lot of syntax / language-specific things to know when you think about it. And I've always found the docs hard to decipher. When prototyping I think I actually want: 1. Little language-specific knowledge you have to learn and remember when you know a lot of other languages. A lot of this is about API consistency. You should be able to recognise a pattern in how the API is organised, and just go from there. Python still doesn't do list.sort(), it's still sorted(list). WHY???? This shit gets in the way every time. 2. Really REALLY good documentation. This is incredibly important. I should go from googling what I want to do or looking up a method to a concise description and an officially maintained usage example in under 10 seconds. Rust is nailing it most of the time here. 3. Types. Trust me to say that, but autocomplete is one hell of a drug, and so is using it to break out of the write-compile-test loop WAY earlier, usually during the write phase. 4. Not necessarily a big standard library, but at least a very good, frictionless package/dependencies system. Rust is getting better at this, the community is even thinking about 'blessed' packages.
to3m 10y ago
No, in principle is exactly when it's a lot less trustworthy than the statically-typed one. Because in principle you could execute some code (untested; data-driven; "is_testing?function(x){return true;}:1.5"; etc.) that passes a non-function instead of a function, and this code would be considered valid (until it goes pop at runtime). But a language that checked this property statically would give an error before execution even started.
- lngnmn 10y ago
  > But a language that checked this property statically would give an error before execution even started. Like C or C++ does. But you are right - I shouldn't use 'in principle'. It was rather a decorative idiom here, because it is true only for simple functions like map or filter or whatever you take from a standard prelude. What I mean is that we are not talking about run-time in this context. Yes, one could pass by reference (or even by value) some crap at run-time, but this is a quite different problem. Machine code has this problem too.
  - coldtea 10y ago
    >Like C or C++ does. C is more dynamic than typed. Types are very loosely enforced there and carry little information with them.

by lngnmn 10y ago

coldtea 10y ago

>It not "appears", it is generic. As generic as it could be Only in the sense that accepting arguments that it shouldn't accept and it'll crash with, is part of the general description of the filtering operation -- which is not. If you prefer, it's "more generic" than it should be. It's not a generic description of the "filter" operation, but a generic description of the "process_input_and_produce_output" operation. >The dynamic languages, notably Lisps, Erlang, Python and Ruby are proved to be superior for quick prototyping and so-called exploratory programming Where is that proof published? And what methodology did it follow? Since, you know, we are computer SCIENTISTS and all...

lngnmn 10y ago
> what methodology did it follow? http://erlang.org/download/armstrong_thesis_2003.pdf http://norvig.com/java-lisp.html http://arclanguage.org/ http://old.ycombinator.com/viaweb/ Yes, 'proved' was a too strong claim. A few exceptionally good systems has been produced, notably Symbolics CL, Smalltalk, Erlang and Clojure, which after removing all the hype and snowflakery, is a remarkable thing.
rdtsc 10y ago
> are proved to be superior for quick prototyping and so-called exploratory programming Not OP and I don't have proof but I always reach for Python for exploratory programming or a quick "let's try and see what happens". Not sure if types are part of it or not, maybe it is just terseness -- the code is closer to pseudo-code. I hope one day to learn Rust enough to internalize the type and borrowing system so that I can crank things out just as fast (and hey'd be more reliable and faster out of the door) but I am not there yet. > Only in the sense that accepting arguments that it shouldn't accept and it'll crash with Now on that point I think it is not just types. Types are a part of it. C has types and systems written in it crash and segfault all the time. Likewise C++ and so on. Maybe Rust is one new-comer where types and lifetimes would make a difference in practice. However since OP mentioned Erlang, I'd would it is possible to write more reliable systems in Erlang (Elixir as well perhaps) than in C++ or Java or other such typed systems. I have seen it work in practice, and Ericsson's customers have seen systems work for years with 99.9999999% reliability. Now Erlang has optional types (the more annotations you add the more benefit you get from), but in practice isolated heaps, built-in distribution, solid error logging and reporting, sane concurrency model make a lot more difference.
- cormacrelf 10y ago
  Back when I was good at Haskell, I would actually use it for exploratory stuff. At the time I think it mostly came down to which standard library I knew better. Python has a huge stdlib, but I actually find prototyping difficult as I don't have my head in the game in terms of what function on X can I use for this purpose, what's the syntax for that again. Python has quite a lot of syntax / language-specific things to know when you think about it. And I've always found the docs hard to decipher. When prototyping I think I actually want: 1. Little language-specific knowledge you have to learn and remember when you know a lot of other languages. A lot of this is about API consistency. You should be able to recognise a pattern in how the API is organised, and just go from there. Python still doesn't do list.sort(), it's still sorted(list). WHY???? This shit gets in the way every time. 2. Really REALLY good documentation. This is incredibly important. I should go from googling what I want to do or looking up a method to a concise description and an officially maintained usage example in under 10 seconds. Rust is nailing it most of the time here. 3. Types. Trust me to say that, but autocomplete is one hell of a drug, and so is using it to break out of the write-compile-test loop WAY earlier, usually during the write phase. 4. Not necessarily a big standard library, but at least a very good, frictionless package/dependencies system. Rust is getting better at this, the community is even thinking about 'blessed' packages.

to3m 10y ago

No, in principle is exactly when it's a lot less trustworthy than the statically-typed one. Because in principle you could execute some code (untested; data-driven; "is_testing?function(x){return true;}:1.5"; etc.) that passes a non-function instead of a function, and this code would be considered valid (until it goes pop at runtime). But a language that checked this property statically would give an error before execution even started.

lngnmn 10y ago
> But a language that checked this property statically would give an error before execution even started. Like C or C++ does. But you are right - I shouldn't use 'in principle'. It was rather a decorative idiom here, because it is true only for simple functions like map or filter or whatever you take from a standard prelude. What I mean is that we are not talking about run-time in this context. Yes, one could pass by reference (or even by value) some crap at run-time, but this is a quite different problem. Machine code has this problem too.
- coldtea 10y ago
  >Like C or C++ does. C is more dynamic than typed. Types are very loosely enforced there and carry little information with them.