HNHacker News
TopNewBestAskShowJobs

sds2

-15 karma · joined August 5, 2017

submissionscomments
sds2··on Lispers
> So first you say Lisp is useless in compsci because of the existence of "rust, c and idris", and now its pointless to use it because of ML?

Idris and Rust are ML descendants and C helps you to learn the basics of low-level programming. Lisp on the other hand won't teach you anything. How hard is this to understand?

> Secondly: The first paper on S-Expressions appeared in November, 1997.

That was just a draft of an RFC which never got approved. S-Expressions are MUCH older - it's "Polish Notation" invented by Jan Łukasiewicz in 1924

> McCarthy's first paper on what would become Lisp in 1982.

Lisp was specified in 1958.

> I'm aware of no language, and can find reference to no language, that used that notation before Lisp did, so yes it is original to Lisp.

1. It's not about who used that notation but who invented it - not McCarthy; 2. that notation is practically useless for programming languages but they're good for ASTs.

sds2··on Lispers
You can do that more efficiently with any ML language.

> There's a reason GCC's internals often look like Lisp.

Dude, that notation is not original to lisp...

sds2··on Lispers
No I don't have any experience in its memory management and I don't need it.
sds2··on Lispers
> Javascript IS a powerful language with features that were not in other mainstream language for decades and some still don't have: first class functions, dynamic typing, lambda functions, closures etc. You only have to look at the diverse uses of Javascript to appreciate how far that power goes.

This is ridiculous and it just shows how you don't have any experience with ML languages.

> As for the warts of JS any experienced Javascript programmer has learned to work around those and it takes a small effort to learn how to do so.

Again, ridiculous excuses.

> You really need proof that the majority of the web is written in PHP?

Yes.

> As for an entry point for unskilled labour, my first PHP code was written after I'd been a C++ programmer for 20 years. I found it similar to Javascript; some warts to be aware of but otherwise a powerful language it's possible to be very productive in in a short amount of time. I refer you to the look at the many Facebook tech blog posts on the topic.

It's not powerful, you just don't have experience with effective languages.

> Have you read up on CLOS? It goes way beyond the features of, say, C++ object model. By limiting yourself to a subset you can have the basic OOP features; inheritance, polymorphism and encapsulation. It provides more and arguably non-oop features such as multiple dispatch, methods that can run before, after and around your own methods (aspect oriented in modern parlance).

That was added after and still looks bad overall.

sds2··on Lispers
> But if you are "computer SCIENCE"-school and you targeting variety of fundamental cocepts of field I say that lisp is quite essential.

I'm sure you've nothing to do with compsci because lisp is a useless language family. If anything is recommended than it's rust, c and idris.

sds2··on Lispers
Don't like my negative experience with lisp? I could guess it from your username.
sds2··on Lispers
> JavaScript has also successfully escaped perception of "a language for brains". Research background is actually harmful for a modern programming language.

Those who consider javascript a good language usually lack the experience to compare languages effectively. Javascript is mostly appealing to front-end developers because they usually don't know anything else. Also, there are a LOT of front-enders so, you can explain the "popularity" with that. JS has many warts but js-zealots will just ignore it due to the hype.

> simplistic Go takes the world over by storm;

Proof on that? Because so far, the only ones using it are the ones who just don't know how to use other languages. The y prefer garbage code over learning generics...

> the web is mostly written in PHP, whose inventors are as far from PL research as one can get.

Proof on that "mostly" again? Also, most of those sites are unstable and known to be really hard to maintain. PHP was just an easy entry for unskilled labour which is a bad thing since they'll create worse products which will cost more in the long run. But beginners don't care about the long run - they just want the money from ads.

> I am perfectly aware of all the differences between Lisp and JavaScript and of the other languages that have influenced JavaScript (Self, Perl, Lua), but think of this: what made Lisp so great in the past?

Your points are too subjective:

> automatic memory management (compared to Fortran/C)

Did lisps took part in researching modern GCs? I don't think so. I thought it only had a simplisitc ARC only...

> very dynamic language and environment,

And it's a very useless feature - or prove it otherwise. Strongly and statically typed languages can `eval` too.

> multi-paradigm, flexible programming language: functional, OO and imperative programming when needed;

1. First lisps wasn't OO and modern lisps are either NOT OO or support it poorly; 2. imperative programming is not that comfortable in lisp; 3. lisp is not a good FP language: just compare it to ML.

> research roots and great minds behind the language;

Or more like failed experiments and like-minded enterpreneurs.

sds2··on Lispers
No, it shouldn't be. Lisp is not practical(try to prove it otherwise, there's no evidence) and it's only a thing now because some ppl likes its esoteric syntax. It's way too overhyped.
sds2··on “Packages should be reproducible” added to Debian Policy
Yeah, nix doesn't feel right on debian because it can't manage services and doesn't use the "standard" packaging idioms. Is there someone else with a different experience or a workaround?
sds2··on We need to document macOS
You're using linux from 1999 and you've problems like this: "I spent two weeks trying to make my ctrl/capslock swap stick and not reset every time the computer slept/resumed."? It's unbelievable.
sds2··on We need to document macOS
> Because I spent 4 hours today trying to figure out how to prevent something from starting on boot

Learn systemd then? Or use the "Startup" app?

> I spent two weeks trying to make my ctrl/capslock swap stick and not reset every time the computer slept/resumed.

xmodmap or gnome-tweak-tools?

> When I plug my headphones into the computer, I have to manually switch the output source every time.

I never needed to. See your settings.

> If I plug in my external monitor while the monitor is off and then turn it on, linux refuses to recognize it.

That's your window manager.

> Is that enough for now? I could go on.

Going on with what? With pure laziness from your side to look up tutorials? Or that you use one of the worst window manager/desktop on linux in its almost-beta version and complain about it?

> I'm using Ubuntu 17.04.

That's your problem. 16.04 or switch distros. Don't use unity either. Don't expect things to work when you use (practically) unstable stuff and you don't even know what you're doing.

> Linux on the desktop is still not as easy to use or predictable as Windows or OS X.

None of your claims are true. Just because you misconfigure something somewhere or because you use a crappy window manager it doesn't make the "linux desktop" worse. Windows is not predictable either - I'm forced to use it at work and it's a pretty bad experience overall.

sds2··on Does OO really match the way we think (1997) [pdf]
> Lisp under SBCL is as fast as Java under the latest Oracle JVM and for numeric computation is sometimes as fast as Fortran.

Back it up.

> I routinely read third-party Lisp libraries and they are very readable, no problems with that.

Me too and they're all junk.

sds2··on Does OO really match the way we think (1997) [pdf]
> The performance claim doesn't really matter in a world where we use languages like Python, Ruby, PHP and Javascript for major applications.

Yes, it does. And those languages are all providing negative user/developer experience.

sds2··on We need to document macOS
> I shouldn't have to go to terminal to edit a conf file to make audio or video work.

I never needed to.

> It does not work out of the box.

It does.

> You must know how to use terminal and edit Byzantine configurations, and read Linux forum posts from 2005 to make basic functionality work.

What was your problem?

> It's my "subjective" opinion, but after 5+ hours troubleshooting and configuring as a power user who does know how to edit conf files I wouldn't recommend it to anyone.

You're lying, if you'd be a "power-user" then you wouldn't complain about manual text-based configuration.

sds2··on We need to document macOS
> Linux is a great server OS but a really terrible choice on the desktop.

Why?

sds2··on Does OO really match the way we think (1997) [pdf]
> It's unfortunate that ML and Lisp didn't gain greater traction but that's likely due to Unix.

Lisp and ML are competing by nature(MLs are famous from their typesystems) and their "failure" is not because of unix, but because of their inability to deliver 'fast' & readable apps. Also, the learning curve...

sds2··on Atom 1.19 – Improved Responsiveness and Memory Usage
Where is the proof on vscode being "fast"? And compared to what? I can only talk about my and some of my friends' personal experience but it won't praise vscode's performance. It's maybe less glitchy(latency) than atom but it feels like it's still far from sublime/emacs/vim.
sds2··on The New Copycats: How Facebook Squashes Competition From Startups
They changed their strategy?
sds2··on Atom 1.19 – Improved Responsiveness and Memory Usage
> Atom's defenders always bring up that it was made with electron as the reason for it's slowness.Then, VSCode came along and invalidated that.

How so?

sds2··on Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]
> Having a single static type system that captures all differences across all versions of all browsers is not realistic.

Why? Standards and abstractions are useful.

> But even if it were, there's a bigger problem: static type checking happens too early. The browser can rev and change its APIs after your static type checking is performed.

At that case your program's behaviour may become inconsistent

> You want to type check with the actual runtime environment, not just a static guess at it.

That's not typechecking and there's no guarantee that your program will work with dynamic typing if the API changes.

> I guess by "graceful," not segfaulting would be a good start.

Is runtime type error better? If the type of your value changes and your assumption was false about the type then it can fail anyway with an incorrect function call.

sds2··on Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]
Both Objective-C and Java are statically and strongly typed. What you're thinking about is probably a runtime-reflection mechanism. The JVM, java's host is capable of supporting dynamic languages through 'invokevirtual' but it doesn't make java dynamically typed.
sds2··on Static Typing Where Possible, Dynamic Typing When Needed (2004) [pdf]
> Requiring explicit type declarations is usually unnecessary and always a nuisance.

Except at function declarations and similar - they help to make the code more readable. It's not feasible to dig in code where the only clue about the nature of the input and output in a function are variable names.

> Static typing provides a false sense of safety, since it can only prove the absence of certain errors statically.

This sentence contradicts itself: if it proves the absence of certain errors, doesn't it provide a certain level of safety? Also, it seems like the author never heard about substructural and dependent typing...

> Static typing fanatics try to make us believe that “well-typed programs cannot go wrong”. While this certainly sounds im-pressive, it is a rather vacuous statement. Static typechecking is a compile-time abstraction of the runtime behavior of your program, and hence it is necessarily only partially sound and incomplete.

And dynamic typing fanatics want us to believe that the only thing we need is unit tests...

Modern, statically and strongly typed programming languages are capable of making us forget many common errors like data races, incorrect resource management etc. The authors enumerate what "us" - the "fanatics" state about static types but what does dynamic typing gives us besides uncertainty? And how could they question the documentational value of static types?

The authors of this "research" paper should do more research about contemporary PLT because it seems like they've only programmed in 10-20 years old OOP languages. Also, what is the case for dynamic typing in this paper? I'm really curious because it feels like they're just biased towards dynamic typing.