151–160 of 184 posts
Earlier quoted context omitted.
Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…
I spent months working on a Lisp project in college. I pretty much hated it. Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of master…
Is it that "Some people" don't like those, or that "some people" have been to Algol-style languages first, and they can't easily adapt to the other style?
>Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of mastery, and I've learned more than a dozen to a high level of mastery.
Yes, but I bet the first one's you've learned were already algol-like.
After that, adding other languages does not mean much if they all share the same paradigms and syntax style. It's like a Common Lisp person also learning Scheme, Racket, Clojure etc -- in the end it's not much difference.
Going from those to different paradigms is what makes an actual difference (e.g. learning Coq, or Erlang, or Haskell, or Lisp or Forth, etc).
Earlier quoted context omitted.
Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…
I spent months working on a Lisp project in college. I pretty much hated it. Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of master…
After a while you have to stop blaming the people and instead just admit that Lisp isn't as awesome-for-all-purposes as some famous people seem to think it is.
I don't know, sounds like it's just not as awesome for you, but probably is that awesome to all those famous people saying it is.
I spent months working on a Lisp project in college. I pretty much hated it.
Like I said, its possible the style doesn't bode with ya, and that's cool. That said, here's my anecdote. I also did Lisp in college and hated it. Thought it was stupid, had the worst most unreadable syntax I'd ever seen. It made every trivial thing hard, like why can't I just loop?!?, where are the variables?!?, how do I just do one thing followed by another?!?. Where do things start and end?!? I don't even remember what Lisp it was, but trust me, it was some academic cryptic variant, probably maintained by some teacher himself, had no library ecosystem, lacked documentation, the ugliest editor I'd ever seen. Anyways, moved on and never thought of it again.
Then became a dev, did C++, some assembly, moved to ActionScript 3 lots of event programming, then C#, JavaScript, Java, all that. Suddenly, I gave Lisp another shot, at work, on a real project, not some school project, with Clojure. First thing I realized, there are libraries and documentation, and frameworks, you can set variables, loop, do infix even if you want too. There's easy ways to do imperative code, OOP, all that is there, I just couldn't see it before, I think it was college shadowing the obvious from me, and maybe my coding instincts weren't good enough then, so I couldn't recognise things if they looked and behaved slightly differently. Also, I had coworkers who used Lisp for real projects, commercially. I realised Lisps are often used in school for teaching theoretical programming concepts. But in practice, you'd not use Lisps like that, you'd use it like any other language. Anyways, eventually, I also got recursion, tail call, collection mappings, pure functions, higher order functions and all that. Once I got all these things, it was like, how have I had been using anything else before. Now its such a drag to go back.
Flutter ( http://flutter.io ) strikes an interesting balance here by (1) allowing just-in-time compiled, state-preserving "hot-reloading" during interactive development and (2) supporting optimized deployment using classical ahead-of-time compilation to native code. Disclaimer: I work on the team at Google that builds the underlying language platform for Flutter.
Hmm, looks interesting, but it's quite unfortunate that making the compilation process be useful at runtime-error-removal is merely optional ("strong mode"). So one wonders how many shops write enough "prototype" code in "weak mode" that they decide to leave it in its Python-like mess instead of rewriting for "strong mode"...
Earlier quoted context omitted.
I spent months working on a Lisp project in college. I pretty much hated it. Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of master…
> Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators Is it that "Some people" don't like those, or that "some people" have been to Algol-style languages first, and they can't easily adapt to the other style? > Maybe I "didn't have good enough teachers," but for every other language I've eve…
Earlier quoted context omitted.
It didn't even have that tone...
Well it does just assert without any supporting argument that Python is a nicer language, which is textbook flame-war starting.
I feel like this is a false dichotomy: you can have a fast iteration cycle, and have statically checked guarantees. I've worked in Haskell for 7 years and had exactly this. I could load my entire app in GHCi, make changes, reload and test. Now I'm working in Java and in IntelliJ I can have something similar with hot-swap. And in the browser with typescript I have a strong type-system and can reload my app in seconds.…
The important thing is not at which stage in the compilation pipeline the bug became obvious, it's at how many seconds elapsed it became obvious.
I generally found that working in untyped js with a workflow prioritising fast iteration was much better for finding bugs quickly than working in Scala with its advanced type system and miserably slow iterations.
But as you say, it's possible to have both.
I feel like this is a false dichotomy: you can have a fast iteration cycle, and have statically checked guarantees. I've worked in Haskell for 7 years and had exactly this. I could load my entire app in GHCi, make changes, reload and test. Now I'm working in Java and in IntelliJ I can have something similar with hot-swap. And in the browser with typescript I have a strong type-system and can reload my app in seconds.…
> It might even be more important than a static type system, at least for some apps. But you can have both. The important thing is not at which stage in the compilation pipeline the bug became obvious, it's at how many seconds elapsed it became obvious. I generally found that working in untyped js with a workflow prioritising fast iteration was much better for finding bugs quickly than working in Scala with its advan…
Earlier quoted context omitted.
One thing to remember - the domain under discussion in the article is gaming. There's little maintenance typically involved with games. There's more today than there was yesterday, but it's still not a system expected to be built, maintained, and extended for decades.
Yeah, this sounds right 99% of the time, although there is at least one genre that, if successful, breaks that mold - MMOs. WoW is 13 years old, Everquest is 18 years old, and Ultima Online is 20 years old. For us hobbyists, there are MUD codebases based upon code written 27 years ago.
Earlier quoted context omitted.
It's kind of my point: LISP does (mostly) provide instant feedback, but it's not used much in the real world (every big LISP success I've heard of wound up either being translated into a shlub language, or resulted in the teams using it having a really hard time hiring people and scaling).
Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else. It's hard to break this habit of familiarity, it's self replicating, because the less famili…
The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image!
It sounds great in theory, once those tools are delivered, but in practice you've lost more than you gained. No matter how good your environment, you do not beat the collective effort and productivity of file-system based tools.
What I say about image based tools also applies to code deployed in a database. Good luck keeping source control in sync with stored procedures...