Do I Really Need a Programming Language?

http://ayudasystems.tumblr.com/post/71327185334/do-i-really-need-a-programming-language

by momo-reina • 13 years ago

150 142 13 years ago

ayudasystems.tumblr.com

chattoraj• 13 years ago

pg wrote about this years ago.

If you understand how compilers work, what's really going on is not so much that Lisp has a strange syntax as that Lisp has no syntax. You write programs in the parse trees that get generated within the compiler when other languages are parsed.

source: http://www.paulgraham.com/avg.html

jesstaa• 13 years ago

It's as if lisp was originally designed to be an intermediate language for computer generated parse trees....and not a language for people to read.

vog• 13 years ago

If you say "S-expressions" instead of "LISP", this is perfectly true! The syntax of S-expressions was only meant to be used for LISP data structures, while programming was meant to happen in another syntax called "M-expressions" [1], which was to be converted to S-expressions by the compiler. However, the programmers liked to use S-expressions directly, so M-expressions were never actually implemented.

In that sense, the LISP syntax (S-expressions) were ideed designed as an intermediate language, not to be used by programmers directly (except for plain data structures).

[1] https://en.wikipedia.org/wiki/M-expression

goldenkey9• 13 years ago

It's not as if..it is truly the case. That's why only nutters use LISP for large projects. Who really wants to wrap every S-Expression in parenthesis? Talk about painstaking and what an eye-sore. If only M-Expressions caught on, LISP could be decent. But really, it's just making you write your program as a data structure because that makes it easier for the compiler to process.

So...

Ruby: good for developers, bad for the JIT compiler (slow)

LISP: awful for developers, good for the compiler -> machine (fast)

Is the tradeoff worth it? Not at all. Most LISP intros start by convincing you that you'll eventually get used to your code looking like a sack of parenthesis. No thanks, I shouldn't need to get used to staring at overburdened verbosity for the compilers' sake - build something better. Wait..we have other languages that are fast and look nice. And many even process into a well-formed AST. Okay, thank heavens.

velis_vel3• 13 years ago

Yes, and he's still wrong. You don't write 'directly in parse trees', you write in text that gets converted to parse trees. The conversion is very simple, to be sure, but it still exists.

Chattered2• 13 years ago

When writing an S-expression of Lisp code, you're just one quote symbol off writing the list literal that evaluates to the code's parse tree. Modulo whitespace, the parse-tree prints as code.

That's what we mean when we say you write directly in parse-trees. You're writing the string representation of those parse-trees.

barrkel• 13 years ago

Now show the same tree for a ruby block, a Java inner class, a C# lambda and how they're all the same.

Except they're not.

Only the simplest ASTs are directly translatable. Language semantics differ wildly when you get into higher level constructs. Not even Lisp is able to help you, as that just changes the problem from one of syntactic representation into one of library implementation.

theaeolist2• 13 years ago

That's for syntax. Also, for semantics, how do you translate C's pointer arithmetic in Java?

jdiez17• 13 years ago

All programming languages deal with pointers at some point or another, so it's just a matter of finding the GCD.

At least that's what I think this is about, and Lisp is a good GCD.

gsg3• 13 years ago

Language semantics differ, full stop. Say you have x = 2147483647:

    x + 1 => -2147483648 (Java)
    x + 1 => Undefined behaviour (C, assuming int32_t and various things about the implementation)
    (1+ x) => 2147483648.0 (Emacs Lisp)
    (1+ x) => 2147483648 (Common Lisp)
    x + 1 => x + 1 (Prolog, using some interpretive license)

andrewflnr4• 13 years ago

That's not really a critique of the author's main point, I think. Of course you can't directly translate between semantically different features, but the OP's point was about semantically identical programs, and how different syntaxes distract from that.

That said, I think it's possible to invent a language in which all the things you mention can be expressed and at least compared. I'll do my best to do it myself if no one beats me to it. Any language with closures is close. Java inner classes and (AFAIK) C# lambdas practically are clsoures. If the only thing ruby blocks add is that returns and similar statements affect the block-creating function, that can be simulated with exceptions.

wtracy• 13 years ago

Well, you could edit machine code directly, or do the next best thing and write in assembler:

    cmp eax, 100
    jle LESSTHAN
    mv 10, edx
    ret
  LESSTHAN:
    mv 5, edx
    ret

I doubt that's what the author had in mind, though.

sheetjs• 13 years ago

I'm surprised the author didn't write a shorter C example:

    return price > 100 ? 10 : 5;

pmiller2• 13 years ago

That produces a different AST than the if/else because it's an expression. :)

yohanatan• 13 years ago

Actually LLVM assembly might be a better choice these days.

waps• 13 years ago

A real programmer would write :

83 f8 64 7e 06 ba 0a 00 00 00 c3 ba 05 00 00 00 c3

Or even :

10000011 11111000 01100100 01111110 00000110 10111010 00001010 00000000 00000000 00000000 11000011 10111010 00000101 00000000 00000000 00000000 11000011

I'd do better still, but I lost my butterfly somewhere.

sklivvz19713• 13 years ago

A real programmer would hand assemble a LISP interpreter and then pass it the LISP source. Come on.

tikhonj2• 13 years ago

The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?" Any given Lisp is still a programming language--it has some syntax and it has semantics. But it does have a much simpler grammar than any language (save Forth).

The grammars exist because programs are made to be read by people, not just computers. A more heterogeneous notation can make for more concise code that's easier to scan and easier to read.

Of course, this is not to say that Lisp is unreadable. I actually rather like reading and writing (paredit is awesome) Lisp code. But, after quite a bit of Racket, I've found that I still heavily prefer having infix operators and a bit more syntax. At the same time, I also often want less noise--ie no parentheses. I want all this so that I can quickly scan and comfortably read my code. That's why we need grammars.

nabla9• 13 years ago

I also often want less noise--ie no parentheses.

You have not reached Lisp enlightenment yet.

Because you use Emacs, you can get shortcut to enlightenment by choosing color for parentheses that almost hides them to the background.

goldenkey9• 13 years ago

I prefer rainbow parenthesis based on nesting depth.

jballanc• 13 years ago

You could also use a Scheme that has implemented SRFI 49: http://srfi.schemers.org/srfi-49/srfi-49.html

(I think the fact that SRFI 49 is not more popular might say something, though...)

catnaroek10• 13 years ago

You have not reached Lisp enlightenment yet.

I want a semantically sane language. What do I care what code Lisp macros can autogenerate if nobody can make sure it makes any damn sense?

raverbashing• 13 years ago

But it does have a much simpler grammar than any language (save Forth).

And that's why I prefer Forth syntax

But yes, you're always going to have a grammar. Albeit simple, you need a tokenizer/parser for lisp and forth. It's simple, but it is there.

Computers don't know what 2.345 or "blah" means, we still need a way of inputting this in a friendly way.

draegtun2• 13 years ago

Another language with a simple grammar and partially inspired by Forth & Lisp is Rebol...

  $ rebol
  
  >> price: 99
  == 99
  
  >> either price > 100 [10] [5]
  == 5

  >> ;;; and even more interesting is...
  
  >> ten: [10]
  == [10]
  
  >> five: [5]
  == [5]
  
  >> either price > 100 ten five 
  == 5

JackMorgan5• 13 years ago

If you code in C, C++, C#, JS, or Java, there is a good chance your code has just as many curly brackets and parentheses as the equivalent code in lisp. The biggest differences being they are more irregular in location and there are more newlines separating your closing delimiters. Check this insightful comment out. https://news.ycombinator.com/item?id=6960546

If you code in Ruby, Python, or Coffeescript, yeah, lisp has more parens, no doubt. That is the price of its regularity. Lisp could throw all that out the window, but you'd lose the easy macros.

Edit: added the link

bad_user• 13 years ago

I think a more helpful question would be "in what instances do I need syntax?". Could you build a type-system like Haskell has for LISP? Would it be usable?

In terms of syntax, I think there's a divide between the needs of static type-systems, versus dynamic ones. LISP is at its core a dynamic language. It makes sense to treat code as being data that can be manipulated. Getting rid of all that syntax gives you great power in terms of what you can do. And personally I find Clojure code to be much saner than code written in Ruby or Python, but that's another discussion.

However, the other side of the coin are Haskell or Miranda (its predecessor) or languages in the ML family or Scala. These languages go to great length to achieve much of LISP's expressiveness, while ensuring a great amount of static type-enforcement. Haskell is especially notable because Haskell is lazy and has many goodies, such as type-classes or rank-2 types. People say that when a piece of Haskell code successfully compiles it is usually correct. LISP can't do this, even though there have been experiments with pluggable type-systems.

For an excellent rant on the choice of Scheme for SICP (and not Miranda, Haskell's predecessor), checkout: http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.p...

So IMHO, syntax helps if you want static type-safety, because the language and the type-system exposed need to be expressive. Whether static type-safety is useful or not, it's a matter of debate, being highly dependent on the problem domain. One could argue that static type-safety is very useful if the shape of the data you're manipulating is well defined and doesn't change much, otherwise you're better off with a dynamic language, but that's another discussion.

catnaroek10• 13 years ago

In terms of syntax, I think there's a divide between the needs of static type-systems, versus dynamic ones.

Type systems fall squarely in the "semantics, not syntax" department.

colomon2• 13 years ago

"People say that when a piece of Haskell code successfully compiles it is usually correct."

Every time I see this claim, I wonder what the heck people are working on that is so simple that getting the types right is all it takes to get the code right? Is it just that enough of my work is math or parsing, both of which typically have an infinite number of ways to get things wrong but with the correct types?

Or is the idea really the other way around -- if your program is sufficiently complex, you'll never get it to actually pass Haskell's type checks?

Edited to add, I love the article you linked to so far. :)

tokenrove• 13 years ago

People say that when a piece of Haskell code successfully compiles it is usually correct. LISP can't do this, even though there have been experiments with pluggable type-systems.

Why can't Lisp do this? In the Common Lisp world, there's some pretty aggressive, though still optional, static type checking. There's also Qi, Shen, Typed Racket, et cetera. The question is orthogonal to the question of syntax.

catnaroek10• 13 years ago

The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?"

A more useful question is the following: "is a simple grammar the be-all and end-all of programming language design?". I think the answer is "no". Ceteris paribus, a simpler grammar is of course to be preferred to a complex grammar. But, ultimately, people write programs for what they do (so that they can be useful) and for what they mean (so that they can be maintainable), not for how they look like. So a simple semantics takes precedence over a simple syntax.

Of course, this is not to say that Lisp is unreadable. I actually rather like reading and writing (paredit is awesome) Lisp code. But, after quite a bit of Racket, I've found that I still heavily prefer having infix operators and a bit more syntax.

That is precisely what languages like Haskell (and to a lesser extent ML) give you: a typed lambda calculus (semantic simplicity) with infix operators (syntactic eye candy) for convenience. The type system reduces the universe of valid programs to those that typecheck, so you do not have to worry about stuff like the meaning of 2 + "potato".

brudgers5• 13 years ago

Racket is typed, and as strongly typed as Haskell and ML. I think what you were getting at is that Haskell and ML are statically typed whereas Racket is dynamically typed by default. However, #lang typed/racket allows full access to static type checking.

brudgers5• 13 years ago

Racket lets you use infix operators if you want:

     (5 . * . 3)  ; 15
     (5 . > . 3)  ; #t

As a bonus, you even get more verbose syntax as in other languages, because Racket, being a Lisp will let you write code any old which way so long as there is a macro available to parse it.

kroger4• 13 years ago

There are many infix macros for Common Lisp. This one [1], for instance, allows you to write:

#I( x^^2 + y^^2 )

And, naturally, you can macroexpand the macro.

[1] ftp://ftp.cs.cmu.edu/user/ai/lang/lisp/code/syntax/infix/infix.cl

danneu• 13 years ago

    > I actually rather like...
    > I've found that I still heavily prefer...
    > I also often want...
    > I want all this so that I can...

    ...

    > That's why we need grammars.

Well, that was a twist ending.

6d0debc071• 13 years ago

A more heterogeneous notation can make for more concise code that's easier to scan and easier to read. [...] I want all this so that I can quickly scan and comfortably read my code.

I actually find those harder to read. Generally, because I can indent Lisp code however the heck I like, I have a pretty good idea what's going on just from looking at the structure of the code and reading a few words here and there.

It's a fairly common experience for me in other languages to be scanning back and forth across a line searching for that $%^$£%£ operator rather than (in the rare event I get really lost in a Lisp file) just going, "Highlight the next s-expression up, ah that's what's going on." Or "You know what? Indent my code for me in a different way."

I wonder whether there's a divide between people who understand code initially by looking at the structure and people who understand code initially by looking at the operators in terms of who likes Lisp :/

ww520• 13 years ago

For simple business rules and logic, I found it useful to just use a table or mini-spreadsheet to represent them. It has strict structure and it's simple to understand and fill in. Business users love them.

nostrademons• 13 years ago

This is why everyone should study compilers and machine architecture in college.

Anyway, it's interesting that he chose to label what he ended up with as "Lisp". I would've stopped at assembly, eg. in LLVM IR:

  %result = icmp gt i8 %price, 100
  br i1 %result, label %Discount1, label %Discount2
  Discount1:
    ret i8 10
  Discount2:
    ret i8 5

The key idea here is that underneath everything you tell the computer to do is boolean logic and transistor circuits. Yes, even Lisp S-exprs; it's not really correct to say "Lisp has no syntax", it has a very simple syntax that is trivially parseable. Even LLVM assembly is a translation layer, as is LLVM itself; underneath it on my computer is an i86 processor, and underneath it in my phone is an ARM-architecture Snapdragon.

Once you understand that, you realize that all of these languages and frameworks and libraries and databases are just tools, and they exist for your convenience. They're there to let computers handle things that humans are really bad at. For example, memorizing memory layouts really sucks; let a computer map out your structs onto memory. Managing heap memory really sucks; let a garbage collector do it. Managing register allocation really sucks; let a compiler do it. Managing syntax kind of sucks; let a parser slap something more friendly on top of it, or don't and use Lisp. Managing vtables kind of sucks; let C++ or Java hide it behind a class, or don't and continue to use C.

Once you've gotten into this mindset, you're free from the religious wars that surround technologies, because you realize it's all just tools that compile down to machine code at the end. And you understand when a tool might be useful, and when you could just as easily implement it yourself, and when it once was useful but has since ceased to be.

chongli• 13 years ago

Once you've gotten into this mindset, you're free from the religious wars that surround technologies

That seems all fine and well, but you're ignoring the elephant in the room: compatibility. You aren't free to choose your tools as you please if compatibility is one of your requirements. This little bit of impurity combines with network effects to create big problems. Compatibility along with all its attendant problems is the single most valid reason for engaging in a religious war over technology.

tikhonj2• 13 years ago

That's one philosophy. Your code exists to be run by your computer.

Personally, I take a different one: the computer exists to run my code. LLVM, x86, ARM... all just implementation details. Sometimes they're unavoidable, but c'est la vie.

Ultimately, what I care about is semantics. I care about what my program means--the logic it represents. After all, that's the whole point, the end goal. The fact that it's running on a physical computer is just a detail, albeit an important one.

A programming language is more about shaping my thoughts and forming my logic than actually running. Choosing a programming language is incredibly important--it affects what I can say, how I can say it and even how I think. And that's the most important part.

millstone• 13 years ago

The end goal of the web browser in which I'm typing this is not to represent some piece of abstract logic, but to drive the physical hardware: to change the color of pixels on my screen, to sense and react to my input. Attempt to distill it to some piece of logic or mathematics, and you end up with something useless, an absurdity.

The original task was "apply a seasonal rebate to our products," but none of the programs actually accomplished this feat. They contained some logic which might be useful in such a program, but none of them applied anything. Logic on its own is sterile.

ZoFreX• 13 years ago

You reminded me of this:

What is a program? Several answers are possible. We can view the program as what turns the general-purpose computer into a special-purpose symbol manipulator, and does so without the need to change a single wire (This was an enormous improvement over machines with problem-dependent wiring panels.) I prefer to describe it the other way round: the program is an abstract symbol manipulator, which can be turned into a concrete one by supplying a computer to it. After all, it is no longer the purpose of programs to instruct our machines; these days, it is the purpose of machines to execute our programs.

EWD1036

shurcooL• 13 years ago

This is so, but why are our language A <-> language B translation tools so bad, that people end up having to manually convert code from one language to another (e.g. if some code exists in language A, but you need its functionality in language B)?

etherealG• 13 years ago

because some of the essence of what you wanted to express is lost when you compile. it's not a one to one mapping.

otherwise we would just compile and decompile into each form. intermediates like lvm come close to trying to do this i think? not sure if they allow going back to the original form from the IL though.

oh, and lastly, think of trying to express a feature in 1 high level language with another that doesn't support that feature. it's quite hard to gain expression when it's not idiomatic in that language.

kind of similar to spoken language actually. some concepts in some languages form as single words or phrases that never really translate well to other spoken languages because the place that other language formed never had that concept.

userbinator3• 13 years ago

Compilers have gotten better, but in comparison to a human, they are still not particularly good at the edge cases. Things like instruction selection and register allocation in particular, sometimes I wish I had the time to write my own more intelligent algorithms for them.

sklivvz19713• 13 years ago

I agree.

The point of a programming language is making complex stuff readable. One can certainly hand-assemble and write software as a series of byte values and I have done so in the past because of necessity. It's very boring and difficult.

In this respect, I don't find Lisp readable or intuitive at all, but that's just me, I'm probably not smart enough:-)

m0skit0• 13 years ago

It's not about being smart or not, it's simply getting used to it. Probably chinese doesn't seem readable or intuitive to you, but a chinese also don't find english readable or intuitive.

Someone• 13 years ago

"This is why everyone should study compilers and machine architecture in college."

Everyone? For starters, I would exclude those studying law, medicine, most of the 'soft' sciences, and probably chemistry and physics, too.

Yes, most of these might be better of having some knowledge of programming, but I doubt they really need to know what a parse tree is. Hand-waving "3+2x6" is three plus (two times six), just as in normal life" probably is sufficient for most of them. Even math majors need not know about compilers and machine architecture.

That leaves a tiny fragment of 'everyone in college': just the computer science students and, to a lesser degree, the software engineering ones. I would present the latter to parse trees, but I would not go in any depth there. Really, for most people doing software engineering, compilers can be black boxes.

girvo• 13 years ago

I'm working on a toy programming language at the moment, and I was considering using a LISP dialect of some sort as the IR to be compiled down to. Is this a dumb idea? I had the same sort of epiphany that the OP had, but then I think LLVM IR is a better choice. The only reason I like the LISP-as-IR idea, is that if a programmer wants to get deep and optimise, the tooling can work with lisp instead, which allows for some neat tricks I have in mind.

jaggederest• 13 years ago

You're basically reontologizing the history of Lisp, which is that it was originally S-expressions that were the intermediary language for M-expressions, which were the human representation.

They never quite got around to making M-expressions though, people found working in S-expressions to be pretty fine.

Dylan is sort of a compromise around this area though:

http://en.wikipedia.org/wiki/Dylan_(programming_language)#Sy...

ericHosick• 13 years ago

We've been working on a programming language that is based on composition. This basically leads to a hybrid data structure (not necessarily tree-structured).

Here is an example (write out 1 2 4 8 16 32 on different lines):

   Application (
     using Library ( name "Vision.Console" )
     action ForEach (
       items 1 2 4 8 16 32
       action WriteLine ( text CurrentItem () )
     )
   )

Parts are upper case and properties are lower case. Each Part is a class 1 contained within a given framework.

dschiptsov• 13 years ago

Nice way to discover the if special form. Now its time for short-circuiting.)

sgt101• 13 years ago

No one thinking that a contractor might have to maintain it in 5 years time? No?

Ahhh the fundamentals!

DevKoala• 13 years ago

My exact thought. Moreover, there might be other architectural reasons why he was asked to implement the logic at the higher level. I can see what he is getting at, but not his motives.

forgottenpaswrd• 13 years ago

Oh man, so many people in the world need a better boss...

Without him, they will spend most of their lives on mindless debates sucking their creative energy like a vampire blood.

byuu• 13 years ago

Sure, and when you write an expression more complex than a single ternary, you start to see why Lisp is so uncommon in real-world usage.

It has a wonderful technical elegance, but the humans that have to write code tend to not think in the same sense. After four or five brace levels it gets very challenging to keep track of everything.

patricius• 13 years ago

I think that can be said also of most mainstream languages, i.e., that more complex expressions are less comprehensible. The same applies to increasing levels of nesting. Lisp's syntax is so different that it just looks less comprehensible than any language you're more familiar with.

carlob2• 13 years ago

The overly eager optimizer in me was thinking:

    (price > 100) * 5 + 5;

yay! no branching!

delinka• 13 years ago

Iff in your language of choice a Boolean is always converted to a 1 or 0. In C, at least, that's not necessarily the case.

That said, I'm always looking for the least branchy way of doing things.

dbaupp• 13 years ago

I was under the impression that the C standard does mandate that comparisons give 1 and 0 for true and false. (Other nonzero things are considered true, but a plain comparison won't return them.)

praptak• 13 years ago

Does it compile to a piece of code without any conditional jumps?

gsg3• 13 years ago

It's not uncommon for machines to have a branchless idiom for generating the value of a condition. For instance, in x86:

    cmp price, 100
    setg reg
    movzx reg, reg
    lea reg, [reg + reg*4 + 5]

Evgeniuz• 13 years ago

(((price - 100) / abs(price - 100)) * 25 + 75) / 10

Here you go, simple integer math, no programming necessary :) That said, this isn't optimisation, multiplication and division aren't intrinsically better than branching.

jonsen• 13 years ago

  if (price == 100){ ...

carlob2• 13 years ago

x/abs(x) is really sign, which is something you can implement using bitwise oprations.

Your solution fails when price == 100 as sibling pointed out.

mikro2nd• 13 years ago

To quote Guy Steele, "All programming languages evolve until they become Lisp."

(iirc)

sebastianconcpt• 13 years ago

Didn't knew that one. Heh, it's good!

juliangamble• 13 years ago

This is a fascinating quote. It seems to be a combination of either:

* Greenspun's 10th rule of programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp." http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming

* James Gosling quoting Guy Steele: "Lisp is a Black Hole: if you try to design something that's not Lisp, but like Lisp, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp". http://web.archive.org/web/20091201072950/http://blogs.sun.c...

Morgawr• 13 years ago

http://www.youtube.com/watch?v=_ahvzDzKdB0

This video is relevant. Amazing talk.

Cort3z• 13 years ago

Of course you don't care that much about which language to choose when you just want to do a simple if statement. However when you want to do more complex stuff, like answering a request on port 80 and compile a document that you send back over port 80, making sure to encrypt it properly so that no third party will get a hold of it, then it would be beneficial with some sort of programming language.

The question should really be, why does the IT department care if he uses C or Basic? And more over, why did he try to make it in C in the first place if he knows the IT department prefer Basic? This is a case of unprofessional behaviour by the author, not whether or not you need a language to express an if statement. At that point he could just as well have written this is x86. Who needs maintainability anyway?

wildgift• 13 years ago

Here's the code in either C or C#:

return ( (price > 100) ? 10 : 5);

Computer languages are for people. It should really be more like this:

    #
    # Description of what this does.
    #
    PRICE-THRESHOLD = 100
    LOWER-PRICE = 5
    UPPER-PRICE = 10

    IF PRICE > PRICE-THRESHOLD RETURN UPPER-PRICE
    ELSE RETURN LOWER-PRICE

Alternatively, use Excel:

    =IF( (price > 100), 10, 5 )

Excel is cryptic, but a lot of finance people understand it.

J_Darnley• 13 years ago

With C it can be more like what you want. Stop using ?: if you don't like it.

    if (price > 100)
        return 10;
    else
        return 5;

Replace with more named variables if you want.

the_af• 13 years ago

I'm going to guess wildgift was being sarcastic. COBOL syntax is so needlessly verbose it interferes with the understanding of the actual formula. I contend that

    return price > 100 ? 10 : 5;

is way more readable.

nkoren• 13 years ago

That code works in C, C#, and JavaScript.

weatherlight• 13 years ago

ruby too!

thomasfedb• 13 years ago

If you expressing what you want the computer to do, and it understands you, you are - by definition - using a language.

xixixao• 13 years ago

Among other things, the C parser will look for curly braces, and the VB.NET parser will look for the eye soring Then keyword.

Here I would pick up the article and write this:

No matter which language I start with, the end result is always the same. So maybe I could simply write out what is important for me:

  if price > 100
    10
  else
    5

And then I realized I was coding in CoffeeScript.

collyw• 13 years ago

Someone influential (was it Joel) said that code gets read a lot more often than it gets written.

I am not used to Lisp or VB.net but I do find the first two examples a lot more readable.

(Seasoned Lispers, does reading Lisp get easier to read over time? As readable as an imperative language?)

goldenkey9• 13 years ago

It's a sack of parenthesis anyway you slice it. Of course staring at anything, including parenthesis, gets easier the more often you torture yourself. Just like talking with a lisp, you get used to it...hence they call the language LISP; painfully charming.

dylandrop2• 13 years ago

Alright, that's one anecdote. But take a look at this one.

In Python:

a = 3 * 4 + 5

In Lisp:

(setf a (+ 5 (* 3 4)))

Now maybe it's just me, but balancing all those parentheses and thinking in prefix notation gets a little hairy, especially if we introduce more math into a program (think graphics or ML).

lispm3• 13 years ago

    3   7
    - + -
    4   8

Can't write that in Python. Looks like Python does not support even basic math notation.

Lisp does not even attempt to do that.

We have to write

    (+ (/ 3 4)
       (/ 7 8))

    (+ 3/7 7/8)

Let's say we want to write a slightly more complicated expression in Python:

               2 2 +-+    3+-+3+-------+2   3+-+2 3+-------+
           - 2b x \|3 log(\|a \|b x + a   + \|a   \|b x + a + a)
         + 
             2 2 +-+    3+-+2 3+-------+
           4b x \|3 log(\|a   \|b x + a - a)
         + 
                      +-+3+-+2 3+-------+    +-+
            2 2     2\|3 \|a   \|b x + a + a\|3                  +-+3+-+3+-------+2
         12b x atan(----------------------------) + (12b x - 9a)\|3 \|a \|b x + a
                                 3a
      /
            2 2 +-+3+-+
         18a x \|3 \|a

Not possible. It does not know basic math format for roots, exponents, ... Lisp also does not know it.

Balancing parentheses in Lisp is usually done with the help of an editor...

dylandrop2• 13 years ago

For the first part, it's still more intuitive (at least for me personally) to write

a = 3/4 + 5/8

than

(setf a (+ (/ 3 4) (/ 7 8)))

and the primary problem that I have with the parentheses not closing them, but logically seeing how expressions link together. Even if you can click on an end paren and see the expression it closes off (as you can in most IDEs) it would be easier just to not have the extra parentheses there in the first place, so as to avoid the confusion.

It's really hard for me to even tell what you're trying to write for the second part -- in Python or Lisp.

Do I Really Need a Programming Language?

Related Stories