5 ms·

> For example, dynamically typed languages like Python (or Ruby, Lisp, etc.) are easy and pleasant to write. They avoid the difficulty of convincing a compiler

by ken 7y ago

> For example, dynamically typed languages like Python (or Ruby, Lisp, etc.) are easy and pleasant to write. They avoid the difficulty of convincing a compiler that you’ve written your code correctly, but they’re harder for a new team member to comprehend: you’re trading fluent writing for more laborious reading. I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read and write. For one thing, there's simply a lot less of it. Lisp isn't more productive just because it's easier to "convince a compiler that you've written your code correctly". After all, if you haven't written it correctly, the user will notice right away, too! > Short functions, methods, and classes are quick to read, but must either be built of many lower-level functions or themselves comprise parts of larger compositions in order to accomplish anything. You’re trading away locality in favor of concision. That's how languages work. You used the word "concision" rather than spelling out what it means in tiny words, and count on us readers to know it, or look it up. That's usually a win, especially if we have a standard set of words. Again, this is where higher-level languages win big. You can encode higher-level concepts. I can write MAP or FILTER and people know what they mean. Or if my language doesn't have those, I can write them. Just because you can explain something with lots of tiny words does not necessarily make it easy for anyone to understand: https://www.muppetlabs.com/~breadbox/txt/al.html https://www.muppetlabs.com/~breadbox/txt/al.html

camgunz 7y ago
> ...concision Wrapping up important concepts under good names is clearly a good idea. But on the other end of the spectrum, factoring out a single line from 2 methods and giving it a bad name does far more harm than good. Probably 90% of DRY I come across is this bad kind, I would guess because refactoring for better semantic clarity takes much more effort than just factoring out the common stuff under a different name. I think this downside doesn't get nearly enough airtime as it should.
tabtab 7y ago
Re: "Lisp isn't more productive just because..." Whether Lisp or functional programming is "more productive" in general or just in the hands of a few is a controversial topic. Example debates: https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?GreatLispWar https://wiki.c2.com/?GreatLispWar I personally find functional harder to debug and haven't got past that bottleneck yet. Yes, maybe I'm "doing it wrong", but can't find "right". Somebody else once told me, "functional makes it easier to express what you want but imperative (traditional programming) makes it easier to figure out what's actually happening". That rings very very true for me. In terms of productivity, it looks the second is trumping the first. In another forum, the "solution" was "just don't make bugs". Doh! Even if true for an individual, it may not scale to a bigger team.
- zmmmmm 7y ago
  One of the reasons I hover in the space of semi-functonal languages like Groovy and Scala. Because as much as I love concisely expressing a piece of complex logic as a composition of reduces, folds, maps etc., being able to easily and naturally break out of that to execute a piece of imperative code in the middle of it is still regularly a life saver to me and often an order of magnitude clearer than the pure functional solution to a reader.
  - tabtab 7y ago
    I lot of the time it seems programmers are just avoiding using SQL to do query-centric processing (slicing and dicing lists). Aside from performance problems, another downside is that one reinvents query language idioms in each programming language. It increases the learning curve and is anti-standardization.
- ken 7y ago
  Do you mean the first question literally? My salary has never been well correlated with my productivity. Figuratively, in the sense of "if Lisp allows you to be so concise, why aren't your programs small?", I can report that in every case where I ported a program to or from Lisp, the Lisp version was significantly shorter than the non-Lisp implementation. So I'd say, "it is". As for whether I'm just an amazing programmer, I don't think so. (I don't think I've ever been accused of that!) I know a company here that uses Clojure and most new hires have to learn it on the job. From what I've heard, nobody has a problem with it. I find C (and imperative languages in general) harder to write and debug. Am I "doing it wrong"? I've found C hard to work with since around 1990 when I first tried to learn it.
  - tabtab 7y ago
    Re: "My salary has never been well correlated with my productivity." I'm thinking more from the owner's perspective. If they hired a bunch of Lisp programmers, then they'd produce more software with fewer programmers (if the productivity claims were correct). They'd then get rich and expand, and other companies would take notice and copy. Re: "I know a company here that uses Clojure and most new hires have to learn it on the job. From what I've heard, nobody has a problem with it." There seem to be niches were it works out well, but it has stayed niches since the invention of Lisp. After 50+ years of not catching on in the mainstream, you have to wonder about real-world market fit. Re: "I find C (and imperative languages in general) harder to write and debug." C is a relatively low-level language, mostly designed for hardware speed instead of programmer speed. Thus, it's not the best specimen of imperative languages to compare with. But in general such seems to be subjective: people give widely varying anecdotes. Those who like Lisp dialects gravitate toward them and those who don't go elsewhere.
thomascgalvin 7y ago
> I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read and write. For one thing, there's simply a lot less of it. High level code shifts the burned of understanding the type system from the author and the compiler to the reader. Yes, there is more text to read in a strongly, strictly typed language, but that extra syntax conveys a lot of important information quickly and cheaply, and this is information that the reader will need to know. The difference between: cat( first, second ){ ... } And cat( first: LogEntry, second: LogEntry): void { ... } Is immense. In the later case, I know exactly what this function wants me to provide, what contracts the arguments must honor, and I know something about what the function intends to do with those arguments; it's void, so there are probably side-effects. In the first case, I have to figure that out by reading the body of the method. The signature could tell me all of this, but it doesn't. > After all, if you haven't written it correctly, the user will notice right away, too! My users are not paid well enough to debug my code for me.
- sooheon 7y ago
  What's wrong with: (cat-logs [& entries] ...) If we care about human understanding of the contract, types are no better than names. reverse :: [a] -> [a] (reverse [xs] ...)
  - asdfasdfasdfa 7y ago
    Names can and do lie, types are checked by the compiler. Also in you example, is an entry a string? a dict? its own class? who knows.
  - zmmmmm 7y ago
    > If we care about human understanding of the contract, types are no better than names. That depends on your familiarity with the code though. Yes if you are deeply familiar with the code you probably know what data type an "entry" is. But come to it cold and trying to reverse engineer code like that in the middle of a complex system to understand it is frightening (at least, in my experience).
- 7y ago

by ken 7y ago

camgunz 7y ago

> ...concision Wrapping up important concepts under good names is clearly a good idea. But on the other end of the spectrum, factoring out a single line from 2 methods and giving it a bad name does far more harm than good. Probably 90% of DRY I come across is this bad kind, I would guess because refactoring for better semantic clarity takes much more effort than just factoring out the common stuff under a different name. I think this downside doesn't get nearly enough airtime as it should.

tabtab 7y ago

Re: "Lisp isn't more productive just because..." Whether Lisp or functional programming is "more productive" in general or just in the hands of a few is a controversial topic. Example debates: https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich https://wiki.c2.com/?GreatLispWar https://wiki.c2.com/?GreatLispWar I personally find functional harder to debug and haven't got past that bottleneck yet. Yes, maybe I'm "doing it wrong", but can't find "right". Somebody else once told me, "functional makes it easier to express what you want but imperative (traditional programming) makes it easier to figure out what's actually happening". That rings very very true for me. In terms of productivity, it looks the second is trumping the first. In another forum, the "solution" was "just don't make bugs". Doh! Even if true for an individual, it may not scale to a bigger team.

zmmmmm 7y ago
One of the reasons I hover in the space of semi-functonal languages like Groovy and Scala. Because as much as I love concisely expressing a piece of complex logic as a composition of reduces, folds, maps etc., being able to easily and naturally break out of that to execute a piece of imperative code in the middle of it is still regularly a life saver to me and often an order of magnitude clearer than the pure functional solution to a reader.
- tabtab 7y ago
  I lot of the time it seems programmers are just avoiding using SQL to do query-centric processing (slicing and dicing lists). Aside from performance problems, another downside is that one reinvents query language idioms in each programming language. It increases the learning curve and is anti-standardization.
ken 7y ago
Do you mean the first question literally? My salary has never been well correlated with my productivity. Figuratively, in the sense of "if Lisp allows you to be so concise, why aren't your programs small?", I can report that in every case where I ported a program to or from Lisp, the Lisp version was significantly shorter than the non-Lisp implementation. So I'd say, "it is". As for whether I'm just an amazing programmer, I don't think so. (I don't think I've ever been accused of that!) I know a company here that uses Clojure and most new hires have to learn it on the job. From what I've heard, nobody has a problem with it. I find C (and imperative languages in general) harder to write and debug. Am I "doing it wrong"? I've found C hard to work with since around 1990 when I first tried to learn it.
- tabtab 7y ago
  Re: "My salary has never been well correlated with my productivity." I'm thinking more from the owner's perspective. If they hired a bunch of Lisp programmers, then they'd produce more software with fewer programmers (if the productivity claims were correct). They'd then get rich and expand, and other companies would take notice and copy. Re: "I know a company here that uses Clojure and most new hires have to learn it on the job. From what I've heard, nobody has a problem with it." There seem to be niches were it works out well, but it has stayed niches since the invention of Lisp. After 50+ years of not catching on in the mainstream, you have to wonder about real-world market fit. Re: "I find C (and imperative languages in general) harder to write and debug." C is a relatively low-level language, mostly designed for hardware speed instead of programmer speed. Thus, it's not the best specimen of imperative languages to compare with. But in general such seems to be subjective: people give widely varying anecdotes. Those who like Lisp dialects gravitate toward them and those who don't go elsewhere.

thomascgalvin 7y ago

> I feel like this misses the point of high-level languages. In my experience, higher-level code is easier to read and write. For one thing, there's simply a lot less of it. High level code shifts the burned of understanding the type system from the author and the compiler to the reader. Yes, there is more text to read in a strongly, strictly typed language, but that extra syntax conveys a lot of important information quickly and cheaply, and this is information that the reader will need to know. The difference between: cat( first, second ){ ... } And cat( first: LogEntry, second: LogEntry): void { ... } Is immense. In the later case, I know exactly what this function wants me to provide, what contracts the arguments must honor, and I know something about what the function intends to do with those arguments; it's void, so there are probably side-effects. In the first case, I have to figure that out by reading the body of the method. The signature could tell me all of this, but it doesn't. > After all, if you haven't written it correctly, the user will notice right away, too! My users are not paid well enough to debug my code for me.

sooheon 7y ago
What's wrong with: (cat-logs [& entries] ...) If we care about human understanding of the contract, types are no better than names. reverse :: [a] -> [a] (reverse [xs] ...)
- asdfasdfasdfa 7y ago
  Names can and do lie, types are checked by the compiler. Also in you example, is an entry a string? a dict? its own class? who knows.
- zmmmmm 7y ago
  > If we care about human understanding of the contract, types are no better than names. That depends on your familiarity with the code though. Yes if you are deeply familiar with the code you probably know what data type an "entry" is. But come to it cold and trying to reverse engineer code like that in the middle of a complex system to understand it is frightening (at least, in my experience).
7y ago