Zeiss Axio Imager research grade upright light microscope with DIC, phase contrast, and fluorescence. It's easy to use without training if you've had at least a high school or college bio course with a real microscope. It's stable and sturdy, the lenses rotate into position with a lovely stop, the stage moves steadily, the lenses are fantastic. All the microscopy perks are there, but just the way the basics are assembled into an instrument make it a gem, from focusing the eyepieces, to focusing the image, centering the stage, aligning the beam in the optical axis, inserting prisms or filters. It reminds me of my 40 year old Husqvarna sewing machine, built solid and heavy and designed to be used with controls to be handled.
In geosciences, still many. Some leading ones: carbon sequestration, mineral resources (mining and associated environmental and political risks), origin of moon, earthquake prediction, age and Earth conditions of origin of life, magnetic reversals, mechanisms and speed of recovery from mass extinctions.
In all of these, earth scientist are likely to work across diverse size (diatom to outcrop to mountain range to solar system) and time (the lifetime of an organism, a species, an ecosystem, a biome) scales gathering data to create models. What do past carbon isotope ratios tell us, what's the size of the atmosphere. X-ray crystallography, surface area of a large copper deposit.
Geologists' datasets may be small for creating complex models, and they often are looking at unique processes, so they frequently write their own programs.
Maybe my first program in Pascal, my first programming course.
The school had never taught programming before (yeah, I'm that old), and it was a business teacher who didn't know how to program or use a Mac, and the incomplete syllabus was for a class from another school that used a Honeywell and punch cards.
The first Pascal program was to write a calculator that allowed a user to input arithmetic problems in words and get the correct answer.
>five plus seventeen
22
>two hundred fifty six divided by three
85 r 1
The professor hadn't taught us strings and the textbook Pascal was different from the Mac.
However, the school required me to maintain minimum credits to stay in a welding program I needed for a raise at work, so that by the time I realized how bad the class was, it was too late to drop.
I welded all day at school, programmed for 1-2 hours, went to class, then worked on the program all night at libraries at the UW. One of the UW students complained to a librarian about my smell from the welding; he knew I was junior college scum.
It seems ridiculous today, but it took me a week to pull it together. I sometimes cried from the frustration. I wrote everything out longhand on yellow legal pads at the UW libraries, welded 8 hours, then computer lab, and class, bus back to the UW. I was struggling in my arc welding class, too. I couldn't get the feel of striking an arc, and the men helped each other, but initially refused to help the only woman in the class.
My first solution was clumsy, but I got all the components to run, figured out reading strings, input/output, handling spelling errors. The text had a rigorous theoretical description of top down programming, and after I got the syntax and op system nailed, I used that to write an elegant and robust algorithm. I didn't realize until years later what I was doing, writing an algorithm.
Then late one night, library almost closing, I had it! Next day I entered the hand written program into a Mac at school, and it ran perfectly.
It was the solving, not the problem that was hard, and I bet most here can't imagine all the missing components I had to find for myself, but the lack of tools, prior knowledge, and information made solving it almost impossible. Today, I could Google all the help I needed for a zero-to-program in two hours, but I'd never feel the level of victory as I did that afternoon when all my classmates entered arithmetic problems into my calculator and got answers.
This is a big issue with gigwork, major underpayment for services leading to non-livable wages for workers. This is about the level, too, pennies for dollars.
I just learned about the law change, and I think it's driven in part by the low wages of Uber drivers and a recent lawsuit there.
Great, you built a unicorn on the broken backs of low wage earners, structured the unicorn to avoid your share of infrastructure taxes (social security, workmans comp, road use taxes), but could you have done it with a less destructive wage structure? Probably. The laws have to catch up.
My comment was more of a mockery of the type of gigs you find on upwork. I have and currently outsource dev work for livable wages usually running into thousands of dollars.
It's a bit in response to a change in California laws. California has always more strictly enforced employment regulations, especially with regards to contractor classifications.
This is a badly written article, journalists should have a little science background.
"... the bats .... were carriers of a rabid and highly contagious virus."
Yes, it is a rabid virus...
"A person usually has some time before it is necessary to get the post-exposure prophylaxis vaccination."
A friend had to handle a bat in her cabin, and she was not told she had "some time" before the shots. If you've been exposed get your butt to the ER.
"An estimated 40,000
people in the US who might not be up-to-date on vaccinations
get preventive treatment for rabies after a bite or scratch from a dog or cat."
Statistically 100% of peeps aren't up to date on rabies vaccines. Vets, bat researchers, and bat house zookeepers may be up-to-date, but no one else is.
Rabies shots costs thousands of dollars, btw. Tricare, for military dependents, doesn't charge a copay for rabies post-exposure injections. My friend's insurance had something like $4000 copayment.
I assume you mean in the US. Really? I had no clue. They are like $5 in Eastern Europe.
Edit: I am referring to the post-exposure shots.
Edit 2: All of this reads like a bad joke - if our numbers are representative, rabies treatment is 20-2000x the cost of other countries in the US. Would be interesting to see someone play devil's advocate on this.
Oh! I got rabies shots in 2014 after being bitten by a dog.
The course of treatment is injections 0day, 3day, 7day, and 14day. I went to the emergency room to get these injections, at the recommendation of my primary doctor.
Unfortunately I don't have the bills anymore, but the total cost was a bit over $20,000, which insurance adjusted down to about $500/visit.
Basically, it would have bankrupted me if I didn't have insurance. Yes, the US healthcare system is really this broken.
Yep, my family had to do the same ER visit for our treatments. Immune globulin is a blood product and I was told it is atypical for any medical center outside of a hospital to have it available. Having to go the ER added a not insignificant amount to our total bill, but we did only have to pay for a single visit to the ER - our followups, we just walked in and a nurse would give us the shot.
On the somewhat funny side, it's weird walking into an ER and being greeted by first name and a wave . . .
Hah yeah, it was kind of funny that by the 4th shot, the ER docs and police there knew me as "the rabies guy".
I also was told that the immune globulin is a bit complicated because it needs to be prepared specifically for the person's weight. So unlike off the shelf vaccines, it requires an on duty pharmacist to actually do something before they can give it to you, which I'm sure adds to the cost.
I got the post-exposure series with rabies vaccine and immune globulin shots earlier this year. The total insurance charge was around $20,000 for me as well. $15,000 for the immune globulin and $5,000 for ER/Vaccine/etc. My out of pocket cost was below a few thousand after insurance, but it was expensive nonetheless.
With those kind of costs, you're probably going to hit the out-of-pocket maximum even if your insurance covers 80% or whatever which is going to be a few thousand dollars for most people. (But might be more with a cheaper high deductible plan.)
Yes, post-exposure costs in the US for human rabies immune globulin (antibodies isolated from the blood of a vaccinated person) in the United States is roughly a $10,000 to $15,000 expense per person (dosage is based on body weight). The vaccine cost is much less, well under $1,000 total per person.
I know these costs from direct experience. I also know that insurance coverage for this cost varies widely as well.
My entire family had a nighttime (meaning the family members were in bed asleep) exposure to an untested bat. Following the U.S. Center for Disease Control and local health department guidelines, plus the advice of infectious disease MD specialists, we had to receive both the immune globulin and rabies vaccine. These costs were not covered expenses under my (otherwise pretty solid) medical insurance plan - we wound up having to pay approximately 30% of the total cost.
In the end, I felt fortunate that at least our insurance kicked in to cover 70% of the costs and that we were in a financial position that allowed us to pay the low five-figure out-of-pocket expense for our treatment without undue hardship.
I'm actually debating keeping our vaccinations up-to-date going forward - I think the booster vaccine, while still uncovered by my medical insurance plan, is relatively low cost and incidences of rabid animal encounters seems to be steadily rising in my home state.
> I'm actually debating keeping our vaccinations up-to-date going forward - I think the booster vaccine, while still uncovered by my medical insurance plan, is relatively low cost and incidences of rabid animal encounters seems to be steadily rising in my home state.
You can get a rabies titer to see if you need the vaccine booster.
Hum, not. Is obligatory for dogs (it was like 50€ or so), but children aren't vaccinated from rabies normally in Spain at the school.
Rabies is endemic in Ceuta and Melilla in any case. I don't know if people in those places are systematically vaccinated but would be a surprise to me.
I took my wife/daughter/myself to the ER to figure out if we should get it since it is the only place that carries the vaccine near us. We ended up not getting it and still walked out with a $3000 bill.
Pre-exposure rabies vaccination is generally not included with statuatory health insurance in Germany. Still, the insurance carrier often covers it if the vaccination is indicated for a country you travel to. The three shots cost about 200-300 Euros combined, IIRC.
> A friend had to handle a bat in her cabin, and she was not told she had "some time" before the shots. If you've been exposed get your butt to the ER.
The article doesn't claim otherwise. Rabies can usually be treated successfully days or weeks after the initial bite. Obviously you should get the shots ASAP regardless; it's more likely to take hold with every day that passes.
> Statistically 100% of peeps aren't up to date on rabies vaccines. Vets, bat researchers, and bat house zookeepers may be up-to-date, but no one else is.
Again, the article doesn't say otherwise. It doesn't say "40,000 people aren't vaccinated," it says "40,000 people (who aren't vaccinated) get rabies shots after a dog/cat bite."
The article does specifically say "a person usually has some time," which is why I put it in quotes. There's no value to the article downgrading an urgent medical situation, and the author lists herself only as a journalist. The standard of care is urgent, ERs are equipped to give the shots. This is USA.
"An estimated 40,000 people in the United States who might not be up-to-date on vaccinations," again, I used quotes specifically because that is how it is worded, "people who might not be up-to-date on vaccinations," as it is less usual for someone to be up to date on rabies vaccinations.
The science was badly worded, as if it was copied without understanding the context, and this is a legitimate concern when the press misstates medical advice. The number is probably from the CDC information page,
"Every year, about 40,000 people receive a rabies prevention treatment called post-exposure prophylaxis (PEP) because they had contact with potentially rabid animal."
CDC also doesn't say dog/cat bite or scratch, just potentially rabid animal, mostly dogs or cats.
I read the article, notices her carelessness, checked sources. There are more errors. It's badly done.
This article is about vertebrates, though. The headline is distinctly incorrect, whatever else is happening to flying insect biomass, or even plants, the article is a survey of vertebrate decline. Vertebrates are one subphyllum of the chordates, not even the most diverse phyllum of animals. Even children know snails are animals but not vertebrates, so how does a journalist miss this.
I thought it would be a down with Lisp article, but it was like my experience with the language, omg, how cool. From that ancient introduction to Lisp all I learned was that Lisp was as close to perfection and beauty as I would get in a programming language.
Serious question: what is it about the "beauty" of Lisp that the HN community seems to like so much? To me, how Lisp looks is its worst quality--the number of parentheses is just mind boggling. I want to understand why it is so loved.
Presumably, this is because you've looked at Lisp code, but you probably haven't understood Lisp.
Criticizing it on the basis of parenthesis would be roughly equivalent to criticizing someone talking about the beauty of mathematics on the basis of the color of the piece of chalk they're using. It's true that it's criticism about aesthetics, but it's not criticism about the aesthetics that the mathematician was talking about.
Once you've understood in what sense people mean that Lisp is beautiful, you can disagree, but this disagreement will not concern parentheses.
As an aside: I have a similarly shallow aesthetic aversion to JS syntax for the same reason. When I encounter a 12-line ragged cascade of curly brackets, square brackets and parentheses, sprinkled with semicolons, I wonder how that can be considered OK.
Aside 2: with Lisp, you edit programs structurally, meaning that their position is essentially managed for you. This is what people refer to when they mean that "the brackets disappear after a while." You're not focusing on them; they're handled by something else.
In my editor, I have the closing brackets faded nearly into the background, which reflects how concerned I am about their existence.
>When I encounter a 12-line ragged cascade of curly brackets, square brackets and parentheses, sprinkled with semicolons, I wonder how that can be considered OK.
It's considered OK because the extra syntax carries semantic weight, and the semicolons disambiguate intent for the interpreter (because while semicolons are optional in javascript, leaving them out can lead to errors.)
And as someone just beginning to play around with (Arc) Lisp, I still can appreciate both paradigms. Neither is objectively wrong.
> It's considered OK because the extra syntax carries semantic weight, and the semicolons disambiguate intent for the interpreter (because while semicolons are optional in javascript, leaving them out can lead to errors.)
Which is a very roundabout way of saying that JavaScript has a very complicated grammar. Is it necessary? No, it isn't. People use and love languages with much simpler grammars, such as FORTH (reverse Polish notation), APL (monadic and dyadic algebraic notation), and Lisp (fully parenthesized Polish notation).
> Presumably, this is because you've looked at Lisp code, but you probably haven't understood Lisp.
I'm not sure this is a great presumption. Someone can be familiar with lisps, understand the design choices involved, even deeply appretiate the beauty of the resulting language, while still prefering languages with a more flexible syntax
> This is what people refer to when they mean that "the brackets disappear after a while." You're not focusing on them; they're handled by something else.
This is exactly the problem. Lisps surrender the issue of syntax completely to the interpreter/compiler, which makes it easy for a machine to parse, but harder for a human. I personally prefer syntax to be designed for humans to read and write, because its going to be translated to something different to be executed anyway.
Now, the simplicity of the lisp syntax is of course intimately connected to the homoiconicity of the language and the extremely powerful macros, so I do understand the value of it and the tradeoffs involved. (Although I find it slightly ironic how it's venerated, given that the original lisp actually had two syntaxes, M-expressions for the human to manipulate and S-expressions for the machine to manipulate).
I personally prefer to do my "meta-programming" in the type-system and have flexible syntax to express functions in different ways relevant to the uses of the language. That can be Elm with it's simple type system and elegant operators for application (|> and <|) and composition (>> and <<) which indicate direction, or it can be Agda with it's unicode syntax and custom mixfix operators, where you can define a if-then-else as a function as "if_then_else_ : (b : Bool) -> (x : a) -> (y : a) -> a" and call it "if <b> then <x> else <y>". I find that the way these languages use operators, reduces the need for parenthesis and allows you to express what your code is doing, whether it's a pipeline of functions or some imperative-like steps being done in order. The result is a syntax that I find clearer.
I am however, well aware that a lot of people dislike Haskell's use of operators and that these languages are a minority in terms of usage indicating that my preference might not be common, but I don't necessarily presume that it's because they don't understand Haskell.
> which makes it easy for a machine to parse, but harder for a human.
That is a naive fallacy. What is harder for the machine is harder for the human.
By and large, humans rely on formatting cues, especially indentation, to parse programs. Human eyes can be fooled fooled by bad indentation:
/* C */
if (foo)
bar();
cleanup();
if (outer)
if (inner)
foo();
else
bar();
If you want to compare human versus machine parsing, then you need to write all the code samples on a single line with no breaks (if the programming language allows that). All optional whitespaces that can be written as a single space should so be written. This way, the humans are actually parsing the same tokens as the machine and not relying on cues that aren't part of the language.
> I personally prefer syntax to be designed for humans to read and write
There is no such thing in existence. People who design syntax simply use their whims, rather than any cognitive science that brings in any measure of objectivity. Those whims are shaped by what those people have used before.
The concept behind Python is actually the closest to getting it right: it recognizes that people really grok indentation rather than phrase structure, and so it codifies that indentation as the phrase structure.
> Languages are a minority in terms of usage indicating that my preference might not be common
That's another fallacy. The vast majority of all programming and other computing languages that have ever been invented are not used at all, or used by a vast minority. In that vast majority, we can find the full gamut of what has been done with syntax, semantics and everything else. Popularity and lack thereof isn't trivially driven by cosmetics.
Machine and assembly languages are just another example of input that is easy to parse for human and machine.
(Machine programs are hard to understand, but in this area we don't have an easy human to machine comparison: machines generally don't understand programs. The advantage of machine language is that it doesn't have to be understood in order to be efficiently executed.)
> Lisps surrender the issue of syntax completely to the interpreter/compiler
It doesn't. It just works differently and looks different because Lisp syntax is defined on top of s-expressions. Lisp syntax is provided by built-in syntax for function calls, a bunch of special operators (let, progn, block, catch, quote, function, flet, if, ...) and a zillion macros. Each macro provides syntax - from primitive examples to complex syntax (the LOOP syntax is an example). The syntax is user-extensible by defining macros.
The level of s-expressions is a syntax for data. This syntax can be changed by readtables and readermacros.
> I'm not sure this is a great presumption. Someone can be familiar with lisps, understand the design choices involved, even deeply appretiate the beauty of the resulting language, while still prefering languages with a more flexible syntax
Yes, you can, but re-read the original comment: the implication was "how can it be beautiful with all those parentheses?" It seems clear that two different aspects of beauty were conflated.
> …what is it about the "beauty" of Lisp that the HN community seems to like so much? … the number of parentheses is just mind boggling. I want to understand why it is so loved.
Also, I would love to hear which language(s) has a more flexible syntax than Lisp, seeing as expressiveness is one of Lisp's strong points.
> Lisps surrender the issue of syntax completely to the interpreter/compiler, which makes it easy for a machine to parse, but harder for a human.
What does "surrender the issue of syntax" mean?
In any case, citation needed for this one. "Easy" and "hard" are very strongly dependent on familiarity. This human finds them easy enough to parse.
> I find that the way these languages use operators, reduces the need for parenthesis and allows you to express what your code is doing, whether it's a pipeline of functions or some imperative-like steps being done in order.
Reducing parentheses is not really a strong selling point for someone familiar with Lisp, because Lisp programmers don't really work with parentheses like in other languages (again, they're managed).
It's not that they're liked for their own sake, but they enable many advantages (such as homoiconicity, structural editing, easy, selective evaluation of expressions at any level of nesting, and so on).
That being said, in Clojure, I often prefer to pipe functions like you mentioned when it seems like the expression would end up unnecessarily nested otherwise:
> Also, I would love to hear which language(s) has a more flexible syntax than Lisp, seeing as expressiveness is one of Lisp's strong points.
I'm thinking about ML-like languages such as Elm, Haskell and Agda (to give a spectrum of examples with varying degrees of complexity in terms of language features).
> Lisps surrender the issue of syntax completely
I think I am referring to the same thing as you are when you say that they're not used like other languages, and that they are managed.
>This human finds them easy enough to parse
Easy enough is good, but I think we can do better!
> It's not that they're liked for their own sake, but they enable many advantages.
I think this is what I was trying to get at. :)
FWIW, I like lips a lot, and consider them far better than most mainstream languages.
There aren't actually more parens in a Lisp program than a program written in a C-like syntax (which is really an algol-like syntax). They just stand out more for two reasons:
1. There is less punctuation in general, so the parens are more obvious. Instead of f(x, y, z) you write (f x y z). Without the commas, the parens stand out because that's all that is left.
2. There is only one kind of parens in Lisp whereas C-like languages use at least three: (), [], and {}, so that makes any particular kind of paren less prominent.
I believe it's purely seeing lines that end with )))))))) that leads the OP's observation ("To me, how Lisp looks is its worst quality--the number of parentheses is just mind boggling"). You don't get that in a C-like syntax. In practice you don't read each individual closing paren to understand the code so it doesn't matter. But it sure looks "scary."
1. Other languages have operators which can be written without brackets, x + y vs (+ x y).
2. Precedence rules allow ex. polynomial expressions to be written without brackets, 2 * x + y vs (+ (* 2 x) y).
3. Algol-like let-bindings or monadic-do-style variable-bindings that inject bindings into the containing block (as opposed to Lisp-style let-blocks where the new scope typically corresponds to a new block) use fewer brackets and keep nesting depth smaller.
# 2 sets of brackets
fun foo(x, y, z) {
let w = x + y;
let u = w + 2*z;
let v = w - 2*z;
u * v
}
# 13 sets of brackets
(fun foo (x y z)
(let ((w (+ x y))
(u (+ w (* 2 z)))
(v (- w (* 2 z))))
(* u v)))
> There is less punctuation in general, so the parens are more obvious. Instead of f(x, y, z) you write (f x y z). Without the commas, the parens stand out because that's all that is left.
3. Lisps optimize tail calls, leading to easier and more efficient recursion. This does tend to increase depth of code.
4. The lisp punctuation style closes all levels on a single line, where most C code guidelines close one level per line. This leads to a "thick" chunk of close parens that students of lisp find harder to read at first.
1. You write everything as a List. So there is syntax, but not exactly.
2. The data is also list, and your program is also a list.
3. Algorithm are basically List Manipulation(Stacks, Queues, Trees, Adjacency lists). So its easy to write complex algorithms in Lisp.
4. Tail call recursion. This part amplifies 3. further.
5. Functional programming features.
6. REPL. I mean like a real REPL.
7. Macros.
1 - 7 helps you to express problems and their solutions with code which represents exactly that. The boiler plate and other assisting code is largely non existent.
Another reason is if a thing has been there around for the longest, more people have thought about it. Both quality and quantity of literature of it are higher than others.
> Another reason is if a thing has been there around for the longest, more people have thought about it. Both quality and quantity of literature of it are higher than others.
Being older doesn’t necessarily mean either quantity or quality of literature will be greater. MUMPS has been around for much longer than Go, for example.
I would like to make the controversial claim that homoiconicity counts against adoption; the single representation carries little structural information and the meaning of a symbol is highly dependent on its containing context. Whereas the ALGOL-derived languages use different types of bracket or other means to indicate visually what the semantics are.
Ironically modern Javascript often replicates the bracket pileup, just with "})" instead. Python does away with it by having "nonindented newline" as an invisible semantic character that closes any number of scopes.
> the meaning of a symbol is highly dependent on its containing context
That being a problem is pretty much solved by not writing 1000 line top-level expressions with thirty nesting levels.
People who actually write Lisp are engaging their imagination for the program itself. Thus their imagination is too busy to come up with scary reasons how things could go wrong that would spook them out of continuing.
Hmm. I've been thinking for a while now that Lisp (and also FP) matches how some peoples' minds work, and doesn't match how other peoples' minds work. For those who match Lisp and/or FP, it's like a revelation, and it's very freeing. For others, not so much - it's a new way of programming, and you can do it that way, but why would you want to?
You said:
> ... the single representation carries little structural information and the meaning of a symbol is highly dependent on its containing context.
That makes me wonder if the difference is abstract vs. concrete thinking - those who by nature prefer abstract thinking will find Lisp more natural, and those who prefer concrete thinking will find it clumsy and unsettling.
Choosing the "right" programming language is not just finding the right language for the task (though it is that). It's also finding the right language that fits our minds - and our minds are not identical.
I think it can be learned - but one needs to have an open mind. If one has learned how a specific program look like in something like PASCAL and then later learns Lisp, there are a bunch of concepts which need to be adjusted...
I started with BASIC, various Assembler variants, PASCAL, UCSD PASCAL, MODULA 2, ... and then learned Lisp variants and Scheme - and also learned basics of some other languages like ObjectPascal, SAIL, Prolog, Postscript, Smalltalk, ...
I'll also add that its powerful and easily deployable macro facilities due to its homoiconicity hurts adoption as well. Macros and dsls can make for increased productivity /decreased loc for individuals and small teams, but the same features can be not so good for large teams and communities, as each program may tack on more and more macros to keep in mind before fully understanding the code being read. I find it easier to read through even a lengthy file of c code using the same old familiar primitives, ymmv.
That's not how code reading works. There are at least two levels of code reading: understanding WHAT the program does and understanding HOW it works.
Most of the time a Lisp programmer wants to read WHAT the program does and that in a very descriptive notation.
Any Lisp has a lot of macros. The base Common Lisp language is full of macros. Any defining operator - functions, macros, variables, classes, structures, methods, ... - is already a macro.
For example a structure - a record - is defined like this:
It's easy to see that it defines a structure type called SHIP with 5 slots. Each slot has a default value and named options.
A programmer will NEVER need to see what the expansion looks like. The code the macro generates is twenty times larger than the source code. What the programmer actually needs is a documentation of what effects the macro has: defining a type, defining accessors for the slot, defining a type constraint for the slots, making one slot read only, ... This is better read from the documentation of this macro operator, instead of trying to see it from reading low-level operator code implementing them.
Every programmer will be happy to read this macro form - no one wants to see the expanded code, how structures are actually defined in terms of low-level operators.
Thus MACROS increase the readability of programs a lot - independent of the team size. Really no one would want to define a structure type by manually creating all the definitions for it (a type, an allocation function, slot accessors, type predicate, compile time effects, ...).
What they can make more difficult is some maintenance tasks - where bugs appear on a meta-level where programs transform code.
I use simple loop constructs like the above all the time; it's especially useful for collecting. But elaborate loop constructs in their full glory are impossible to understand and IMHO should be banned from use on any software engineering team.
Seen pretty elaborate loop constructs in large Common Lisp code bases I was working on, and my conclusion is that the only thing that should be banned is lack of willingness to spend 30 minutes at some point learning the loop syntax. Seriously, after you write few loops on your own e.g. collecting over several hash tables in parallel, you won't have much problem anymore.
I still feel current generation of programmers has a learning phobia.
Pretty sure Dick wrote LOOP. There was an ai working paper on the subject by him iirc too. Teitelman had left mit by the time I got there, though I later got to deal with DWIM (which seems to have infected web browsers and npm etc :-( ) at PARC. one great titlemanism was the addition of ] to Interlisp.
The beauty of lisp-like languages isn't in the visual appearance of the code as text (the parenthesis and layout), but in the structure of the code as trees, the uniformity, and the homoiconicity.
There's also a historical componenent in all of this. Modern languages have adopted many features from the old Lisps that were quite unique back then. The same is true with the ML language family: between the two, ML and Lisp seeded a new generation of languages that are, on average, much more powerful than the languages in common use in the 1970s and 80s. (Smalltalk deserves a special mention, but it came later.)
I'm still fond of Lisp, but languages like Python, D, Nim (and increasingly, Rust) offer a lot of the Lisp affordances that I really valued -- in particular, easy compile-time metaprogramming. The biggest missing bits are Lisp's deeply integrated REPL-driven programming, and the use of program images -- which have many drawbacks but also some benefits.
IMO, everyone should write and maintain a medium-sized program in a modern Lisp (SBCL, CCL) at least once, just to get an appreciation for how different the programming / debugging experience is. So many well-integrated tools at your disposal, even at runtime.
- Different from what you are used to does not mean worse.
- Structural simplicity. Instead of having a huge mess of syntax to keep track of, it has only a very small number of constructs. Simplicity is beautiful.
I guess "ycombinator" (a LISP idiom/macro) as subdomain, and the fact that the site code was originally written in LISP, attracts lots of LISPers. I'm personally not a big fan of LISP, much less of the frequent hijacking of threads to degenerate into discussions about sexprs supremacy and other holier-than-though topics.
To be fair you can do that in most modern languages.
(I don't know lisp) but sometimes this approach just makes the code really difficult to understand afterwards. Does Lisp have something that makes it easier or better?
You can, but it's like picking your nose with boxing gloves on[1] - it's really clumsy. In Lisp, it's natural and easy. It's maybe the same in result, but it's really different in ease of use.
[1] Credit where due - I stole that phrase from my friend Michael Pavlinch.
One could argue that it's made "natural and easy" by making Lisp itself much more difficult to write. So, in other languages, the macro authors pay the tax, but their users do not. In Lisp, everyone pays the tax. This is, perhaps, why writing macros is far more common in Lisp than in other languages with them - if you pay the tax either way, you might as well fully utilize what it buys you. Whereas in another language, you weigh the benefit that a macro will give you, against the tax you will pay if and only if you write a macro.
Most "other" languages don't have Lisp-like macros, so I'm not sure what you are talking about here.
I don't think Lisp is much more difficult to like, on the contrary, out of all the languages I know well (C, C++, Python, Java, Common Lisp) not only do I find CL _by far_ the easiest to write but also that it puts me in a state of flow (= unparalleled mental clarity, focus and productivity) which doesn't easily happen with the others.
Credentials: I spent close to 10 years writing C++ at Google.
I certainly think that Lisp is very different to most popular programming languages today and that difference is immediately obvious. This makes it very easy for people who do not like leaving their comfort zone to dismiss Lisp simply because it "feels" too strange to what they're already familiar with.
It's not the only thing people complain about ; merely the first one. And I don't think anyone can seriously claim that Common Lisp is a simple language. Powerful pragmatic languages never are.
As far as syntax goes, the proof is in the pudding. All languages have people gripe about some part of their syntax or another, but it's clear from experience that "OMG parentheses" is exceptionally prevalent. Hand-waving it away as something that people just don't get because of lack of prior exposure is not really sound - somehow other languages don't get similar complaints (at least, not as universally, and not to the same magnitude) with first-time users. Besides, why is there a lack of exposure? Why, because everything else is different. But why is it different? Isn't the obvious conclusion that Algol syntax family is vastly more prevalent for the simple reason that people prefer it, and simple homoiconicity is not sufficiently enticing?
All arguments in favor of Lisp syntax feel like they ultimately boil down to "you're holding it wrong". And that may well be so - but if so many people are finding it so awkward to hold, isn't that prima facie evidence of ergonomic deficiency? I don't claim to understand why Algol-style is easier. Maybe the way our visual processing works is just better with more varied punctuation? That's something for psychologists and brain scientists and maybe linguists to figure out. But in the meantime, we could at least acknowledge the way things are. I really like Lisp as a collection of ideas (not just the usual ones like HOF and macros, but also stuff like e.g. symbol-based namespacing, or the sheer flexibility of CLOS). But lispers have to ask themselves why, instead of Lisp seeing wider adoption, other languages - that came literally decades later, so "upstart" would be a very polite way to describe them in this context! - become vastly more successful than Lisp by appropriating its cherry-picked features.
The complainers are non-users; it's just a meme, like picking on Cobol.
So many computing languages have come and gone over the years; the number that have been created vastly outnumber those that have ever been popular, let alone that are now popular.
Lisp is amazingly vibrant as a family. People are still excited about it and there is development work going on. That's amazing for something with such old roots.
I added two instructions to the virtual machine this morning, and used them in the compiler of a Lisp dialect to eke out a little performance gain. Wo hoo!
Of course they are not. If you put on a shoe, and it's uncomfortable, you just go get a better shoe that is. This does not negate the validity of the question: why was the first shoe uncomfortable?
Lisp always catered to people with a certain state of mind. It was never a language positioned for popular appeal, and by that I mean the masses of 9-5 "brogrammers" we have today. Looking at how many people fall in love (or not) with SICP, today, and the reasons they give validates this line of reasoning. Lisp and SICP are meant for inquisitive thinkers and hackers who are willing to go DEEP. If you can superficially dismiss Lisp (and all the geniuses that worked with and improved it over the years) in the manner that you do, then certainly, Lisp is clearly not for you. You are not an artist. You are most definitely not a hacker.
You seem to think that popularity should be the prime consideration when it comes to programming language design. This is what gave us PHP and Javascript. I dare say that the people that use Lisp today (and there are plenty of those) do so because nothing else will be as good to them. They love the language. I've known people who moved jobs and got less money in order to work with Lisp. What does that say about the language?
If we go with this analogy honestly, we have to recognize that the vast majority of the programming world is hobbling around in prescribed footwear, and a good lot of it has bits of gravel and broken glass.
> Besides, why is there a lack of exposure? Why, because everything else is different. But why is it different? Isn't the obvious conclusion that Algol syntax family is vastly more prevalent for the simple reason that people prefer it, and simple homoiconicity is not sufficiently enticing?
That is just confusing cause and effect.
> All arguments in favor of Lisp syntax feel like they ultimately boil down to "you're holding it wrong". And that may well be so - but if so many people are finding it so awkward to hold, isn't that prima facie evidence of ergonomic deficiency?
You are confusing cause and effect again, this time by implying that there is something fixed about the way people learn languages (Chomsky's "language organ"). Learning is not like the shape of your hand.
Once you learn structured editing, Lisp code can be written and changed in much fewer keystrokes than code expressed in a more complicated grammar, which is actually ergonomic.
I'll grant you that I haven't given any evidence for my claim, either. But, again, the onus is on those claiming that syntax doesn't matter to prove so, against overwhelming practical evidence (showcased by user count) that it does.
>Lisp (or Scheme, in this case) is a very simple language that gets essentially everything right.
I have to wonder if you actually know all that much about Scheme. Undelimited continuations, for example, are pretty much strictly broken. I like Scheme, but to claim it's flawless is kinda ridiculous.
The biggest benefit is that you can keep a very clear model of everything that's going on in the language (well, most things), from parsing to evaluation to application. The parenthesize represent very important things about how the language works and the regularity of the language emphasizes that it's a few basic principles replicated again and again. Also, the "beautiful" lisp variants tend to be in the scheme family. Common lisp is wart and pragmatic by comparison.
There is no difference between Scheme and Common Lisp when it comes to parentheses and beauty. Everything you mention (simplicity, regularity, few basic principles) apply just the same to Common Lisp. The differences between the two are mostly standard library related (irrelevant to matters of beauty) and lisp-1 vs lisp-2 (no clear winner in terms of beauty I would say).
In many ways it is the parsimony that is beautiful. There is a ton of syntax in lisp, but there are not as many punctuation requirements. And you get to play with the grammar and many parts of syntax yourself.
Contrast this with most other languages, where there are many things the language does that you can not do. At least, not easily.
From my short study, I would guess the uniformity and simplicity of it the syntax and the ability to extend it (thanks in part to the uniformity and simplicity of its syntax).
