Hacker Newsnew | past | comments | ask | show | jobs | submit | more shallowthought's commentslogin

In other words, instead of doing it the standard, commonly-accepted way, the author did it his own way, and it ended up being worse.


The Lisp Curse.

(for the lucky 10,000: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html)


That was written by someone with (at the time) some experience in web development and zero in Lisp.

The request "Update on October 6, 2017. N.B.: Please stop submitting this to Hacker News!" should be interpreted in its strongest form: i.e. including comments.


The commentary on adding OO to Lisp, I feel, is still very illuminating. As for "not reposting to HN", I take that as "don't clutter up the front page with something that's been posted multiple times already and has been discussed to death." Posting it in a comment for those that haven't seen it is nowhere near comparable.


The commentary on adding OO to Lisp is garbage.

> "Making Scheme object-oriented is a sophomore homework assignment."

Demonstrating basic OOP in C is likewise a suitable homework assignment.

http://rosettacode.org/wiki/Inheritance/Single/C

Making a viable object-oriented programming system for others to use is not a trivial task in any language.

No object system for Scheme that people actually use had been written by a sophomore as homework and gone into production in that state. (Linux started by a school kid tinkering with kernel programming too; but it would be a strawman to say that a bright undergrad can make a serious Unix clone in a few weeks that Amazon can put into the cloud and sell services on.)

The Common Lisp object system took many people years of work, and integrates deeply into the language, such that every object type has a class and can participate meaningfully in the object system without being wrapped in a class.

> Due to the difficulty of making C object oriented, only two serious attempts at the problem have made any traction: C++ and Objective-C.

Those are examples of having enough traction to actually get people to switch from C to a new language.

Ad hoc object systems have been implemented in C programs umpteen times, and a number of such things are available, or have been historically available, as formal libraries for use in C programs.

These all have "traction" in their "respective" projects and ecosystems; there is a lot of OOP action within C.


> Ad hoc object systems have been implemented in C programs umpteen times, and a number of such things are available, or have been historically available, as formal libraries for use in C programs.

Including CLOS-like OO extensions for C.

Like Dynace:

https://github.com/blakemcbride/Dynace


No, seriously, why would anyone even care that they're "inspired"? Icons are not supposed to communicate aesthetic wonder or make you think about life, they're supposed to indicate something very, very clearly.


Part of it is probably that people get defensive concerning anything on which they've spent a large amount of time and effort.


I don't get how articles like these get reposted so often - this article is from 2019, for god's sake. If you're interested in the state of the city budget, Covid-19 combined with the passage of a year means that you really need to double-check everything in this article, so at best, it's a waste of time. At worst, you're being pushed toward a very biased, incomplete view of things - I'm not saying every article published by a "think tank" is factually wrong, but ignoring such articles is a handy lifehack.


Man, whatever you're working on must be incredibly interesting and difficult to necessitate a language with the advanced tools necessary to translate even the most abstract of thoughts into code.

Now, if you'll excuse me, I have to write a web app that accepts this API and returns these things... and implement auth... sigh.


Most of my limited production Haskell experience has been schlepping enterprise JSON using AWS Lambda and calling REST APIs.

I’ve not had any bug reports in ages. Which is counter to what most of the teams were used to when deploying services in JavaScript or Ruby. Usually you test like hell, QA, ship, get a few error reports from users, fix them, get one or two a couple months later and fix those... then a year later you change something and get a bunch of new error reports about the feature that used to work... and you fix those.

Haskell forced me to address most of those errors before my program would compile. I had to write a few tests but orders of magnitude fewer than I was used to. I shipped fast.

I got one report from the customer many months later when I made a mistake due to a miscommunication of requirements. One test case prevented that kind of error happening again inadvertently and shipped in less than an hour. Haven’t heard any reports since.

Haskell is my go to where I can get away with it. Absolutely solid stuff.


I have quite a personal interest in learning more about pure FP, type systems, theorem provers and all the hot stuff.

But: you're also comparing Haskell to completely dynamic languages like Ruby or JS. There are things in the middle. Even Java lets you avoid many silly typing errors and if you use something like Kotlin (and you use it well, not just as a slightly more modern Java), you can IMHO get quite far in terms of correctness for typical web backends.

Now the power of languages like Haskell may be warranted in more complex scenarios and I don't want to claim there are no benefits to it, but there are degrees in between the madness that is JS and something like Haskell.


You could be writing that web app in Haskell. The tools are all there. The language is a lot more pleasant to use than most.

It wouldn't really help, of course. Business requirement drudgery is business requirement drudgery in any language.


I was very, very obsessed with Haskell for about 9 months, during which time I attempted to make a very simple web app at least 5 times. I like debugging, but I just flat-out couldn't make it work. Plus, constantly feeling stupid is a huge drain on one's motivation to continue. Plus, the community was... not helpful. I mean, I get the whole "Avoid success at all costs", to avoid the language becoming entangled with the desires of large corporate interests, but it did feel a little extreme. Mind, this was 7 years ago, and I assume haskell stack and a few other tools make things a lot easier.

Actually, this is something I've always wondered: I know that any Haskell enthusiast would, upon hearing someone say, "I like the ideas, but it's just too hard to program in", respond, no, it's not, you just didn't learn it the right way, or this IDE with that extension makes it much easier, or you really should have started with Learn You A Haskell. But what I'm really curious about is this: Putting all that said, assume for the moment that Haskell really is too complicated for anyone without an advanced degree in hyperbolic topology to understand.

Do you care?


Given that I don't have a degree in hyperbolic topology, that would definitely put a damper on my appreciation for the language, yep haha. I'd probably consider myself to be on the lower side of average intelligence for programmers, and I like it a lot. Granted, I haven't gotten around to writing a working web app in it yet.


I don't know what trouble you ran into. It's not difficult to write a web app in Haskell, nor was it seven years ago. All the major frameworks had been established by then. But at the same time I don't want to dismiss your difficulties. Whatever was going on clearly left a scar.

I will say there's no such thing as a programmer who can't learn Haskell and be productive in it. It's not fundamentally more difficult than any other language. It's just that you have to learn to program more or less from scratch again. That initial learning curve was more work than I'd been through to learn a programming language in 25 years, when I first learned Haskell.

Of course, there's definitely such a thing as a programmer who won't like Haskell even after learning it. It's not for everyone. But neither is perl, or c, or python, or java, or....


I can relate. I can program in just about any language. I can handle Lisp, muddle through most Prolog and don't have too much trouble with FPs like Elixir and Erlang. But as much as I have read again and again about Haskell, I always eventually seem to get utterly confounded.


I know and interact with a handful of Haskell devs, some of whom even work with it full time. Some of the ideas behind Haskell intrigue me, but I'm a complete idiot. Now everyone is going to say that you don't need to understand the different theories behind purely functional languages to learn Haskell or know any math, but I'm not quite convinced. Just the vocabulary alone of most Haskell programmers I talk to seems foreign to me. I'm not just talking about half-jokes like zygohistomorphic prepromorphism either. The dictiob used in normal programming discussion makes no sense to me.


I like to use my complexity budget on the problems I'm solving, not the tools I'm using. Haskell has been around for 30 years, sucking people in and spitting them out again.


So I'm guessing you write all your code in brainfuck given that it has possibly the lowest complexity of all PLs?

Tbh this complexity budget is a rather stupid notion in regard to programming languages. Higher level languages allow you to spend less cognition on the language provide you actually know the language. There's a very clear reason we are moving away from C to more complex languages.


There is more cognitive overhead to bf, the programming language does not help you mitigate it.

C++ destructors and rvalues help condense ownership without having to think about the execution path of a whole program.

I'm not aware of what haskell features + tools pragmatically decrease the complexity of a program. If an experienced programmer is still fighting with the language heavily after 9 months and can't figure out a good way to debug programs, that should be a red flag if it is a consistent scenario.


GADTs are insanely helpful in writing correct by construction code. That function indicate the effects it has in the type is possibly the greatest feature Haskell has. Haskell LSP is great allowing to write and evaluate doctests in real-time.

Haskell can be learned in a couple of months of serious learning. If you don't get it after 9 months you simply weren't serious in learning it. It's not like Haskell is harder then any other language. It's concepts are different which makes it hard to learn. But C++ and Python are much harder to write code in then Haskell.


> If you don't get it after 9 months you simply weren't serious in learning it.

That seems a bit harsh. I can believe that everyone should be able to learn Haskell sufficiently well after a couple of months if they stumble across the correct learning material and have sufficient support. I can also see that someone from outside the community might make a solid effort for nine months and not make much progress, simply because the correct learning material wasn't easily discoverable.


To be clear. Serious in learning it would mean dedicating at least 8 hours a day to it. By for example starting a Haskell job and needing to learn the language. Besides I don't really think material is a valid excuse anymore given that there are so many tutorials and books available. There are also many chats and mailing lists where you can ask any question you might have that are beginner friendly.


I care. I'll submit that it's got it's complicated parts, but on the whole it's no more than c++ (also complicated, given).


first time typed FP project ?

haskell has a long history, and ancestors with a long history too, it's normal to feel alienated when you have a background with mainstream languages

I can't talk for haskellers (I'm not using it) but it's not that FP/haskell doesn't care, it's just that its medicine taste sour to you.

If I can give you another point of view, languages like php, started very differently from what they are now. Give a 'closure' to a php3 dev and he will feel just like you do I believe. In 2020, the most used php web frameworks use closures as the normal way, and people are quite happy with it.

I believe haskell is just like that, it's just too advanced.


I disagree; a powerful language lets you push all the junk aside and avoid repeating yourself. The worst part of writing a webapp in, say, Java, isn't the business requirements, it's interfacing with the ridiculous reflection-based authentication library and threadlocal-based database session management and whatever other crap.


They just have to establish a history of suing people for using that word because part of keeping your copyright is showing that you have fought for it in court.


However this dispute is primarily about trademarks and not copyright.


I call it Promo-Driven Development. You have to launch things to get promoted at Google, but you're not going to get demoted for transferring to a better project afterward.


Just like that one engineer on your team that says yes to everything the manager does while writing the worst spaghetti code because he knows once he gets promoted/leaves for greener pastures, someone else will take care of the mess and he will be long gone by then.


> My main argument -- which I think is being lost here -- is that Ocaml isn't IDE unfriendly, and especially not so unfriendly that an entirely new language is needed just so that FP and IDEs can happily coexist.

Right, and I guess my counterargument would be that, yes it is, and you don't need to resort to logic to see it - just do a little googling about its poor adoption.


Don't worry - it's fine.


Which is a process that happens all the time... in movies. In reality, it's chaos.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: