Sure, and those are not “the same kind of people” with the same motives nor rationale nor basis in knowledge as the people advocating for constraints around social media in the present day.
There are religious bookbanners today and they have very little overlap with the anti-social media crowd.
> There are religious bookbanners today and they have very little overlap with the anti-social media crowd.
I guess we're going to have to agree to disagree on that. To me it doesn't matter whether there's any actual overlap between the groups. It's the censorious impulse they share. Believing that they have the right to make this type of decision for others is what makes them the "same kind of people".
I did nothing of the sort. You're trying to set up a classic slippery slope fallacy and I'm not going to play that game.
Me: I think alcohol prohibitionists are meddling busybodies.
You: Oh, well, I guess you think there's nothing wrong with injecting babies with pure grain alcohol starting at birth.
Me: I think furnaces and central heating are wonderful inventions.
You: Oh, well, I guess you think it's okay to go around setting houses on fire.
That's how the game is played. I stopped being impressed by it decades ago. Likely before you were even born.
My late wife and I each had our own accounts, plus a third account for mortgage, utilities, groceries, etc. We'd each deposit into the third account, and kept the rest of our finances separate. I made more money, so I'd usually pay when we went out to eat or whatever, but it wasn't an obligation.
It worked pretty well -- unlike most of my married friends, I don't recall us ever having an argument about money.
I recall an instance of Steve Jobs actually being a nice guy in this respect.
He was talking to a well-known third-party Mac developer (I think Panic, but maybe it was a different one) and asked what they were going to be working on next. "Well, we're thinking about doing an MP3 player". Jobs just said "Don't." (this was not long before iPod/iTunes came out).
So they didn't, no doubt saving them a lot of development time and money.
> I think the military perspective at this point is that they want drones at all price points.
I think you're 100% right here.
It may seem absurd, but something that can take out a main battle tank would be well worth $20,000. An M1A2 Abrams costs $24 million. The latest model Russian T-90 is around $4 million. A Chinese Type 99 is around $2.5 million. The asymmetry is clear.
Some of that $20,000 is making sure it works reliably under any conceivable weather conditions, after it's been stuck in a storage container at +50 C/-30C for weeks or months, etc.
On the other hand, if you're just doing reconnaissance, maybe you'd rather send a swarm of 20 $1,000 drones instead (in an attempt to overwhelm the enemy's countermeasures).
In the context of the verb, everything else is a noun. When you understand what the verb does, then you can care about the difference between a verb and a noun.
Certainly, but the original quote was "It is quite hard to even tell a noun from a verb" (emph. added), and this is correct, you can't tell whether an identifier refers to a function or variable in Scheme by sight alone. This seems desirable if one wants first-class functions, and is very much an intentional choice for Scheme, but it can admittedly be more difficult to build up a mental model of new code if you have no idea what's a variable and what's a function (esp. amidst an already-difficult-to-grok sea of parentheses).
Notably, this isn't intrinsic to Lisps - Common Lisp uses a different syntax and namespace for function names and variables. My understanding is that Scheme et al's decision to merge the namespaces/syntax was not without controversy in the Lisp community (the Lisp-1 v Lisp-2 debate).[0]
> you can't tell whether an identifier refers to a function or variable in Scheme by sight alone
Nor in C. Nor in JavaScript. Nor in Java. Nor in...
I mean, what is "foo"? Could be the name of a function. Could be a char variable. Could be a double precision float. Could be a pointer to an array of pointers to functions returning doubles. Without going back to its definition (or prototype, for function arguments) you can't tell, much the same as you can't tell in Scheme without looking for the matching define or set!
I feel like I must be missing something here. What?
> I feel like I must be missing something here. What?
If I were to hazard a guess at what the original poster was getting at, it might be the culture of those languages, combined with the power of Lisp to redefine its own syntax.
Lispers value concision, love higher-order functions, and love wrapping things in other things to reuse code, so you might easily see a non-trivial stretch of code without a single function call you recognise. Imagine code where the smallest chunk look something like (dq red foo '(hat n (ddl m) f)). There could be anywhere between zero and eight functions in that snippet, or any one of those might be a macro which re-orders the others in any way (or perhaps its parents include a macro, in which case you really can't assume anything about how / if this stretch is executed at all), it could be a wrapper around something that in other languages would need to be an operator (perhaps it's an if statement?), etc etc.
It's absolutely true you can shoot yourself in the foot in any language, but Lisp is unusually good for it. It's part of its power, but that power comes with a cost. Imagine talking with someone that had a proclivity for making up words. In small doses, this might be fun and save time. In larger doses, you begin losing the thread of the conversation. Lisp is sorta like that. It might seem flammorous, but before you prac it grombles, and you plink trooble blamador!
> Imagine talking with someone that had a proclivity for making up words.
All software is written by making up new words. The bigger the software, the more words.
> you can shoot yourself in the foot in any language, but Lisp is unusually good for it
I've never shot myself in the foot writing Lisp, and have not heard any anecdotes about it. (Well, maybe the one about Cycorp's Cyc decades old code base being large and inscrutable.)
> I've never shot myself in the foot writing Lisp, and have not heard any anecdotes about it. (Well, maybe the one about Cycorp's Cyc decades old code base being large and inscrutable.)
> You're making shit up.
An unnecessarily abrasive way of saying you disagree, no? Your own lived experience doesn't match mine, and therefore I must be lying? You're being irrational and mean spirited.
Lisp can't at the same time be uniquely powerful, but also no different to any other language. Lisp is a uniquely flexible language, which is one of its main strengths. Uniquely flexible languages impose a cost for readability and collaboration. You're free to disagree and insult me further, but I think this is self-apparent. Lisp's flexibility makes it a great lone wolf language (well, if you neither want access to a majority of libraries nor closeness to bare metal, which is a bit of an odd middle ground for a lone wolf), but it's awkward in organisations and collaborative contexts, where other, less flexible languages have generally overtaken it.
> Lisp can't at the same time be uniquely powerful, but also no different to any other language
There are lots of programming languages which are "uniquely powerful": C++, Prolog, Haskell, ...
> Lisp is a uniquely flexible language
I'm not sure if I buy "uniquely", but "very" would be fine.
> Uniquely flexible languages impose a cost for readability and collaboration.
At the same time it provides also important features for readability and collaboration. There are code bases of complex Lisp software, which are maintained by small&changing teams for several decades.
Lisp is effective not so much for "lone wolfs", but for small teams (5 to 100 people) working in a shared infrastructure with larger groups. Example: SBCL is a complex Common Lisp implementation, which goes back to the early 80s (-> Spice Lisp). SBCL is maintained by a group of people and has monthly releases. Around it there is an eco-system of software.
Simpler Lisp dialects can also be effective for larger groups. For example there are many people using "AutoLisp" (or versions of it), a simple Lisp dialect for scripting AutoCAD (and various competitors).
Assuming Common Lisp. Many features found their way into other languages (or were provided there early, too -> for example named arguments in Smalltalk). Thus some may not look novel, but a practically used since several decades and are well integrated into the language, tools and designed for interactive usage: development, coding, extending and also reading code can be done in parallel while using the software.
It's actually very different to 'read source code and use batch compilation', from 'interactively exploring the source code and the running program at the same time'.
Relatively typical is the preference for long and descriptive names in larger software bases, with lots of documentation strings and named arguments.
* Development environments come with many introspection capabilities: describe, documentation, inspect, break, ...
* There are standard features for built in documentation strings for functions, variables, macros, classes, ...
* Macros allow very descriptive code. One can extended the language such that the constructs are very descriptive and declarative.
* Macros allow embedded domain specific code, which makes the code very readable, and gets rid of unnecessary programming details.
* Symbols can get arbitrary long and can contain arbitrary identifiers.
* Functions often have named parameters. Source code typical makes extensive use of named parameters.
* Details like manual memory management are not needed. -> code is simplified
* Many language constructs have an explicit and tight scope. -> for examples variables can't be introduced in arbitrary places in a scope.
* The language standard is very stable.
* Language extension is built-in (macros, reader, meta-object protocol, ...) and everyone uses the same mechanisms, with full language support in the extensions. -> no need tof additional and external macro processors, templating engine, XML engines, ...
* Users can more easily share/improve/collect deep language extensions, without the need to hack specific compiler implementation details, since the extension language is Lisp itself.
* Typical code is not using short identifiers or one letter identifiers with a complex operator hierarchy.
* Development is typically interactive, where one loads a program into Lisp and then one can query the Lisp system about the software (edit, who-calls, graph classes, show documentation, ...). Thus the developer does not work only with text, but can live interact and inspect the software, which is always in a debug mode.
* The code can contain examples and tests, which can be immediately tried out by a programmer while reading the code.
* There is a standardized language with widely different implementations. For collaboration it is can be very helpful that even then much of the core code can be shared, instead of having to reinvent the wheel for those different environments. The Lisp code can query the runtime and adapt itself to the implementation. Other systems have that too with an extra external configuration tools. Often it is possible for a different user that shipped source changes can be loaded into a running software. It is then immediately active and information about argument lists, documentation, class hierarchies, etc. is instantly updated.
Here is an example for a interactive definition of a function with documentation, type declarations and named arguments.
CL-USER 12 > (defun some-example-for-hackernews (&key author to title text)
(declare (type symbol author to)
(type list text))
"This code is an example for Hackernews, to show off readability features."
(print (list author 'writes 'to to))
(print (list 'title 'is title))
(print text)
(values))
SOME-EXAMPLE-FOR-HACKERNEWS
CL-USER 13 > (some-example-for-hackernews
:author 'lispm
:to 'troad
:title 'lisp-features
:text '("example for a function with documentation, type declaration and named arguments"))
(LISPM WRITES TO TROAD)
(TITLE IS LISP-FEATURES)
("example for a function with documentation, type declaration and named arguments")
CL-USER 14 > (documentation 'some-example-for-hackernews 'function)
"This code is an example for Hackernews, to show off readability features."
Another example: DEFCLASS is a macro for defining classes. Again, documentation and introspection is built-in.
The developer does not need to read and work with dead text, but can interactively explore and try out the software, while using self-documentation features. As one can see the macro uses similar named argument lists as functions. There is a slot named WARP-CLASS and arguments for types, initialization arguments, documentation, and so on. The macro then expand this form to larger code and saves the user a lot of typing. The language can use similar mechanisms to be extend with other features, without the need to go into compiler hacking. Thus language extensions can be written and documented by users in a standard way, which greatly enhances the way how to use and understand language extensions.
CL-USER 31 > (defclass space-ship ()
((name :type 'string :initarg :name :documentation "The space ship name")
(warp-class :type 'number :initarg :warp-class :documentation "The warp class describes the generation of the warp propulsion system. 1 is the slowest and 5 is the fastest")
(warp-speed :type 'number :initform 0 :documentation "The current warp speed"))
(:documentation "this class describes space ships with warp propulsion"))
#<STANDARD-CLASS SPACE-SHIP 8220381C2B>
CL-USER 32 > (make-instance 'space-ship
:name "Gondor"
:warp-class 3)
#<SPACE-SHIP 8010170AE3>
CL-USER 33 > (describe *)
#<SPACE-SHIP 8010170AE3> is a SPACE-SHIP
NAME "Gondor"
WARP-CLASS 3
WARP-SPEED 0
CL-USER 34 > (documentation 'space-ship 'type)
"this class describes space ships with warp propulsion"
Many thanks for taking the time to show those features off, it's very kind of you and I genuinely appreciate it. I spent about two hours playing with SBCL and its documentation / inspection features, inspired by the examples you gave, and another hour reading some docs. Very neat! Aside from reading a book on CL some time back, my most significant (but still quite peripheral) experience with Lisps has been Clojure, and while I feel like Clojure has better onboarding, I must say that CL feels much more pleasant to actually work with. (If I never see another Java stack trace, it will be too soon.)
I do very much like the named and typed arguments. I took the liberty to do some further reading about SBCL's capacity for compile-time type checks [0], which is a pleasant surprise. I did some quick experimenting, and was also quite impressed with SBCL for catching function calls passing unknown keys at compile time, before the call is invoked.
Perhaps the fact that many Lisp guides feel compelled to start with a terse implementation of lambda calculus might actually be somewhat of a disservice, in hiding the more practical side of the language?
> Many thanks for taking the time to show those features off, it's very kind of you and I genuinely appreciate it.
:-)
> was also quite impressed with SBCL for catching function calls passing unknown keys at compile time, before the call is invoked.
Generally CL compilers tend to check argument lists at compile time. Number of args, correct keyword arguments, ...
SBCL is especially good, due to its further support of declarations as assertions and its support for various compile time checks. You'll also get Lisp backtraces in a natively compiled Lisp then as a bonus. Also for newcomers it is quite helpful, because SBCL gives a lot of warnings and other feedback for various possible problems (from undeclared identifiers, unused variables up to missing optimization opportunities).
> Perhaps the fact that many Lisp guides feel compelled to start with a terse implementation of lambda calculus might actually be somewhat of a disservice, in hiding the more practical side of the language?
That's true. Lisp was often used in education as a vehicle to learn things like lambda calculus (or similar). Practical programming or "software engineering" with Lisp wasn't part of those courses.
There are books which cover those topics, too. Like "Practical Common Lisp" by Peter Seibel, "Paradigms of AI Programming" from Peter Norvig or "Common Lisp Recipes" by Edi Weitz.
For SBCL one definitely needs to read the manual to get an idea about its extended features.
> awkward in organisations and collaborative contexts
Name three concrete anecdotes with organization names, projects and timelines.
Any language can be a "lone wolf" language. People have collaborated in making very large, well-documented projects in C. They have also made things like this:
a random-dot-stereogram-generating program whose source is a random-dot stereogram.
A language that doesn't let you be a Lone Wolf if you are so inclined is something that is not designed for grown ups, and not worth using if it has any alternatives at all in its space.
Relatively banal point re Turing complete languages. You could run a space program with bash scripts if you really wanted to, doesn't make the statement "Bash scripts are not generally well suited for running a space program" less true or meaningful.
I'm honestly unsure what the point of this exchange is. Your response style seems to be to pick one sentence, seemingly at random, and launch a hyperbolic and extremely abrasive tirade against it. Which is both unpleasant and unlikely to lead to any meaningful exchange of perspectives or ideas.
Ah, so the issue is that you misperceive my genuine reflections to be trolling, which you take for permission to be unkind. Whereas from my perspective, I'm just sharing my reflections about something of interest to me, and find myself somewhat abruptly insulted.
Perhaps you ought identify less with your tools, you'd find yourself feeling less attacked when they're discussed (and attacking others?). There's an alternative version of this exchange where you contribute your Lisp knowledge in good faith and I benefit from your thoughts. Bit late now, but food for thought.
A synopsis of your "reflections" is that Lisp languages have nothing to offer of advantage, except to oddballs who follow weird practices that are incompatible with collaboration and long-term maintenance.
That's a baseless, misinformed attack on Lisp people, such as myself; if many people read and believe that, it becomes economically harmful.
Almost every capability in any Lisp dialect can be used responsibly, and in a way that a later maintainer will understand, due to good structure of the code, naming, documentation and other practices.
Respectfully, I wonder what my online experience would look like if I took to reading the thoughts of others with such a negative perceptual filter, and felt compelled to create a conflict in response to every point of difference that I automatically take to be a slight. It seems like it would fill my time with unnecessary strife, and result in a generally miserable time for me and others?
If I think someone is wrong, does that necessarily mean they're acting in bad faith, that they're an idiot, and I'm entitled to bully them? What if I'm mistaken? What if I'm not mistaken and they are in fact wrong - does that make such a reaction acceptable? Effective? Pleasant?
For me, this is a single unpleasant exchange that I get to leave behind, forget, and never think about again. For someone with the aforementioned negative perceptual filter, this is an unpleasant exchange they'll recreate and relive in different contexts, again, and again, and again. I find that kind of sad, honestly.
The irony here is that you're clearly quite experienced with Lisp, and had you responded instead with "hey! not quite - here's what you might be missing about how Lisp tends to be used in production... ", this would have been a very different exchange! But instead you chose to call me a lying idiot, which - well - I honestly can't picture anything positive ever coming out of that. Behaving like a bully automatically undercuts anything else you may have to say, which is a disservice to the experience you no doubt have to share. And even if you don't feel like sharing it, why choose to randomly start a conflict? If the goal was to defend Lisp's honour, is that an effective method? Is anyone reading this going to walk away thinking "My, what a lovely and welcoming community Lisp has, I should go check it out"?
I'm out, feel free to have the last word. Let's see if you use it to be mean or not.
You do understand that you don't have to read an entire book before forming an opinion, right?
> sort through everything that exists
"Book that has been considered a classic for forty years and was used as the intro text at MIT for decades" is a long, long way from "everything that exists".
I did begin reading it a few years ago, and it seemed like a lisp flavored intro CS book. Why do I want to read an intro CS book? I've read those before. Yet people promise me that this one is different, while giving me nothing but condescending promises of enlightenment.
I guess the honest question is "what are you looking for in a response to your question?"
You asked if you should read it, and almost everyone who bothered to reply has said yes. Each time this topic comes up and people ask if they should read it the majority of responses are 'yes'. And I presume if you've been around software for that long, you've seen all of those threads and previous questions and answers like I have - meaning you likely knew what people would say when they responded.
So, in the end, it's up to you to decide if you'll read it or not.
I don't know you personally, but from my life experience it sounds to me like something I've seen in other circumstances. You've more or less decided that you're not going to read it, but feel like you're missing out and you want someone who as read it to say "it's ok to not read it". So you can resolve both the feelings of the decision to not read it, and the uncomfortableness of feeling like you're missing out.
It's possible I'm way off the mark on the above, but I mean it to be helpful - as I can say I've seen what looks to be this same pattern many times in life.
or what you're likely looking for: In the end, there are only so many hours in the day. You gave it a fair shot and it wasn't your vibe. It doesn't say anything about your strength as an engineer, it just has a specific approach and it's not a match for everyone. That doesn't make it a bad thing, it just means you'd rather spend your time learning and exploring in other ways. And it probably would've had more impact earlier in your career than at the level of experience you have now.
But of course before wrapping up I do need to undo my comment: I think you should give it another go. Maybe skim past the early part if it feels a bit to introductory and come back to it later. But it's a book that continues to grows on you the more time it's been since you read it. The concepts it presents are subtle but impactful in changing how you think about software. You don't fully grasp it when you read it. It's just that afterwards you just start seeing things through its lens often. I haven't read any other book like it.
> Why do I want to read an intro CS book? I've read those before.
"We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time." - TS Eliot.
You aren't a curious person who studies things for their own sake and finds wonder in exploring ideas. That's fine, this book is clearly not for you so why concern yourself with it? Most of my friends who are obsessed with their field count many intro books as their favorites and frequent re-reads.
> condescending promises of enlightenment.
It sounds like you're more upset that other people enjoy and therefore recommend this book. You're the one asking for proof that it's worth your time. It's clearly not. People who are curious and like to explore ideas in computing recommend this book frequently to other like minded people.
If you don't like sushi, why question somebody's recommendation for their favorite omakase place?
If you are experienced then I’d say skim whatever sounds interesting from chapters 1-3, then do chapters 4/5 as they contain most of the interesting stuff.
Weasel words. Considered a classic by who? And why would being an "intro text at MIT" mean it's good for someone who is already experienced? If anything, that should show it's not worth his time.
Count how many of those have SICP on their list (hint: most of them, excluding the ones that aren't actually lists of CS books -- e.g. the ones that have Jobs and Gates biographies, etc.)
I didn't just make that up, dude. And this isn't Wikipedia, either.
Tedious, inobvious, trickish. Might do it for some people, but not for me. Double for-loop substring search tells so much more! Oh, pain, oh, obscenity.
The real beauty lies in the SLOW discrete Fourier transform. Such simplicity; but what’s really going on there? Highly recommend grokking DST for the transcendental beauty.
What's your opinion on Cambridge's entry of "less and less"? More interestingly, what's the purpose of grammar policiing? If enough people use an expression, it becomes language. It's weird how people claim some type of superiority just because they subscribe to a certain phrase.
For example, the Catholic Church established its Index of Prohibited Books way back in 1560, and it remained in effect until 1966.
(this is not a criticism of the Catholic Church specifically, mind you... most faiths had similar restrictions, and many still do).