8 ms·

50 years ago, these people were quite common. There were only mathematicians and engineers, but programmers didn't exist yet. The good: Excel, Dataflow Diagram

by j-pb 5y ago

50 years ago, these people were quite common. There were only mathematicians and engineers, but programmers didn't exist yet. The good: Excel, Dataflow Diagrams (commonly found in game, music and arts), SQL, Declarative Dataflow Paradigms in general. Mutablity is counterintuitively counterintuitive if you don't have a model of the underlying execution system. The weird: Prolog, APL, languages done by mathematicians and logicians The ugly: SPSS, R, two languages done by statisticians, and they are absolutely abhorrent, and often missused. If we reinvented programming today my guess is that it would be a lot less text driven and a lot more data oriented.

cube00 5y ago
The ugly: SAS
- mothsonasloth 5y ago
  Siebel CRM
clircle 5y ago
Despite constantly reading on this website that R is bad or wrong, I somehow manage to get all of my data work done quicker and with fewer headaches than excel, sas, or Python.
- qqqwwweeerrr 5y ago
  I hear the complaint that R is a terrible language mainly from professional programmers. I'm sure it is poorly designed from a computer science perspective, but there is no programming language out there which makes it so easy to run any model under the sun as does R.
  - Someone 5y ago
    I think that’s not a feature of the language, but of its libraries. R is popular for similar reasons why it’s so hard to replace python. In Python’s case, the language isn’t bad, but the implementation is horrible for performance. It sits on the back of lots of fast C/Fortran/whatever code, and polished the (relative) turd a lot, making the end result quite usable, but the “sitting on top of part” also makes it hard to improve the performance of the implementation. For both R and python the end result is good, but they still are local optima in the space of what is possible.
    - wcerfgba 5y ago
      I've had the opposite experience. My preferred programming style is functional. My current gig has been in Clojure, and I couldn't ask for a better product programming language. I find Python code very difficult to write in a functional way (even the official howto is littered with for loops [1]), but in R I can feel an underlying lispiness, and the pipe operator `%>%` from magittr is really nice: whereas in Clojure there is `->`, `->>` and `as->` for thread-first, thread-last, and named threading respectively, in R with `%>%` I get thread-first as the default and I can override it by placing `.` wherever I want in the downstream function calls. [1] https://docs.python.org/3/howto/functional.html https://docs.python.org/3/howto/functional.html
- rich_sasha 5y ago
  From memory, R is quite slow, and has syntax I found really ugly. Dots as part of names (my.variable), $ for member access, operators wrapped in % for pointwise operations, eg %*% for pointwise multiplication. These probably shouldn’t matter but did for me. FWIW the statistical offering was fantastic.
hugh-avherald 5y ago
I'm struggling to think of an aesthetic reason why SQL would be "good" yet R, "ugly".
- k_sze 5y ago
  I don’t know R but SQL is definitely ugly. There is no world in which listing the columns before the tables in a SELECT statement is a good idea. It makes intellisense/autocomplete awkward.
- JackMorgan 5y ago
  R has a lot of surprises built in and is fairly inconsistent. That makes it harder to fully learn (always have to pull up docs for everything). Also it means every so often I'll forget some weird edge case of a function and get a totally wrong result. For a certain class of work, this is fine: if you use it every day and are confident catching errata you'll learn all the weirdnesses. Many professional programmers work in a half dozen languages a week, so one that is significantly harder to learn will feel frustrating. For me it'll be actually slower to get the same result as other tools since I have to relearn its unique way of working.
- j-pb 5y ago
  SQL made relational programming possible, when computer were too slow to do declarative programming. The modern aproach would be something more highlevel/declarative like Datalog, but given the context SQL made a good tradeoff in terms of programmer control and declarativity. R is ugly because it encourages users to use it wrong. For loops are slow as a snail, but are what everybody uses and teaches, while the proper/fast way to wrangle data, with higher order functions like map, is hidden behind idiosyncratic names and obscure APIs. Even the creator of R considered making it a language instead of the scheme library that it started iut as, as a mistake.
  - Someone 5y ago
    I think something like QBE (https://en.wikipedia.org/wiki/Query_by_Example https://en.wikipedia.org/wiki/Query_by_Example; about as old as SQL) is the way to let non-programmers write queries.
ModernMech 5y ago
50 years ago was 1971. There were lots of programmers and programming languages in 1971. By then we had Fortran, Algol, Cobol, Logo, Basic, Simula, Lisp, Snobol, B, APL… I could go on.
lokedhs 5y ago
I'm of the age that I also consider 50 years ago to be the dawn of computing. Turns out it's closer to 75. :-) It has been said that non-programmers used to catch on to APL quite quickly back in the day. Faster than regular programming languages in fact. The designers, Ken Iverson, didn't even design the language to be run on computers but rather as a mathematical notation. Someone else mentioned Excel, and that is an example of data-oriented programming. It actually hides the code and displays the data, which is why most programmers hate it. It's not the data that is important when doing development, but the code. Array oriented languages like APL and R allows you to work with data like Excel, but you work with the code, not the numbers. I'd argue that once you learn more about programming, one tends to want to work with the code rather than just looking at data.
- j-pb 5y ago
  > one tends to want to work with the code rather than just looking at data I've observed the opposite trend. The more senior people get the more they care about the data and less about the code. Programming = Datastructures + Algorithms But it's the Data-structures/-models that dictate the algorithms and it's the domain and data therein that dictates the model. Most companies could survive their code being lost. None would survive loosing all their customer data. Functional programming is all about data, react is about data, machine learning is about data, google and facebook are about data. Code is an incidental means to an end, in 90% of all cases, except flight software and games maybe, but even there the trend is towards data driven ECS-Systems and "collect all data for a timestep, and execute your flight control program to compute all actuator outputs in one go"-approaches. And observability is one of THE hot topics in the biz right now.
- Someone 5y ago
  > It has been said that non-programmers used to catch on to APL quite quickly back in the day Thompson and Ritchie also said their secretaries happily wrote troff. Do people get pampered too much today or are we severely underestimating them?
  - Jtsummers 5y ago

by j-pb 5y ago

cube00 5y ago

The ugly: SAS

mothsonasloth 5y ago
Siebel CRM

clircle 5y ago

Despite constantly reading on this website that R is bad or wrong, I somehow manage to get all of my data work done quicker and with fewer headaches than excel, sas, or Python.

qqqwwweeerrr 5y ago
I hear the complaint that R is a terrible language mainly from professional programmers. I'm sure it is poorly designed from a computer science perspective, but there is no programming language out there which makes it so easy to run any model under the sun as does R.
- Someone 5y ago
  I think that’s not a feature of the language, but of its libraries. R is popular for similar reasons why it’s so hard to replace python. In Python’s case, the language isn’t bad, but the implementation is horrible for performance. It sits on the back of lots of fast C/Fortran/whatever code, and polished the (relative) turd a lot, making the end result quite usable, but the “sitting on top of part” also makes it hard to improve the performance of the implementation. For both R and python the end result is good, but they still are local optima in the space of what is possible.
  - wcerfgba 5y ago
    I've had the opposite experience. My preferred programming style is functional. My current gig has been in Clojure, and I couldn't ask for a better product programming language. I find Python code very difficult to write in a functional way (even the official howto is littered with for loops [1]), but in R I can feel an underlying lispiness, and the pipe operator `%>%` from magittr is really nice: whereas in Clojure there is `->`, `->>` and `as->` for thread-first, thread-last, and named threading respectively, in R with `%>%` I get thread-first as the default and I can override it by placing `.` wherever I want in the downstream function calls. [1] https://docs.python.org/3/howto/functional.html https://docs.python.org/3/howto/functional.html
rich_sasha 5y ago
From memory, R is quite slow, and has syntax I found really ugly. Dots as part of names (my.variable), $ for member access, operators wrapped in % for pointwise operations, eg %*% for pointwise multiplication. These probably shouldn’t matter but did for me. FWIW the statistical offering was fantastic.

hugh-avherald 5y ago

I'm struggling to think of an aesthetic reason why SQL would be "good" yet R, "ugly".

k_sze 5y ago
I don’t know R but SQL is definitely ugly. There is no world in which listing the columns before the tables in a SELECT statement is a good idea. It makes intellisense/autocomplete awkward.
JackMorgan 5y ago
R has a lot of surprises built in and is fairly inconsistent. That makes it harder to fully learn (always have to pull up docs for everything). Also it means every so often I'll forget some weird edge case of a function and get a totally wrong result. For a certain class of work, this is fine: if you use it every day and are confident catching errata you'll learn all the weirdnesses. Many professional programmers work in a half dozen languages a week, so one that is significantly harder to learn will feel frustrating. For me it'll be actually slower to get the same result as other tools since I have to relearn its unique way of working.
j-pb 5y ago
SQL made relational programming possible, when computer were too slow to do declarative programming. The modern aproach would be something more highlevel/declarative like Datalog, but given the context SQL made a good tradeoff in terms of programmer control and declarativity. R is ugly because it encourages users to use it wrong. For loops are slow as a snail, but are what everybody uses and teaches, while the proper/fast way to wrangle data, with higher order functions like map, is hidden behind idiosyncratic names and obscure APIs. Even the creator of R considered making it a language instead of the scheme library that it started iut as, as a mistake.
- Someone 5y ago
  I think something like QBE (https://en.wikipedia.org/wiki/Query_by_Example https://en.wikipedia.org/wiki/Query_by_Example; about as old as SQL) is the way to let non-programmers write queries.

ModernMech 5y ago

50 years ago was 1971. There were lots of programmers and programming languages in 1971. By then we had Fortran, Algol, Cobol, Logo, Basic, Simula, Lisp, Snobol, B, APL… I could go on.

lokedhs 5y ago

I'm of the age that I also consider 50 years ago to be the dawn of computing. Turns out it's closer to 75. :-) It has been said that non-programmers used to catch on to APL quite quickly back in the day. Faster than regular programming languages in fact. The designers, Ken Iverson, didn't even design the language to be run on computers but rather as a mathematical notation. Someone else mentioned Excel, and that is an example of data-oriented programming. It actually hides the code and displays the data, which is why most programmers hate it. It's not the data that is important when doing development, but the code. Array oriented languages like APL and R allows you to work with data like Excel, but you work with the code, not the numbers. I'd argue that once you learn more about programming, one tends to want to work with the code rather than just looking at data.

j-pb 5y ago
> one tends to want to work with the code rather than just looking at data I've observed the opposite trend. The more senior people get the more they care about the data and less about the code. Programming = Datastructures + Algorithms But it's the Data-structures/-models that dictate the algorithms and it's the domain and data therein that dictates the model. Most companies could survive their code being lost. None would survive loosing all their customer data. Functional programming is all about data, react is about data, machine learning is about data, google and facebook are about data. Code is an incidental means to an end, in 90% of all cases, except flight software and games maybe, but even there the trend is towards data driven ECS-Systems and "collect all data for a timestep, and execute your flight control program to compute all actuator outputs in one go"-approaches. And observability is one of THE hot topics in the biz right now.
Someone 5y ago
> It has been said that non-programmers used to catch on to APL quite quickly back in the day Thompson and Ritchie also said their secretaries happily wrote troff. Do people get pampered too much today or are we severely underestimating them?
- Jtsummers 5y ago