Live data from Hacker News

Programming Language Checklist

famicol.in

51–60 of 169 posts

Re: Programming Language Checklist

#51
post #36

Earlier quoted context omitted.

That's not really a difficulty of javascript the language - you're supposed to have your javascript completely separate from the HTML and CSS, with everything in static files of that type. Separation of concerns was built into the web from the beginning. It just happens to be a popular architectural pattern at the moment to reimplement the DOM, HTML and CSS all in javascript and have one big mess of code.

You're right that it's not javascript's fault per se. But the rest of your comment represents a narrow, dated and frankly ignorant viewpoint. Component-based front-end architecture has tremendous advantages. And if you want to see "one big mess", simply examine the CSS of virtually any moderately-sized website or web application. I've been doing web-related development since the late 90's, and I make a living as a UI…

I'll just vaguely gesture in the general direction of the multitudes of developers on HN who both work with front-end frameworks and complain ceaselessly about what a nightmare it is and stand by my statement.

It can have both tremendous advantages and be a mess. Both can be, and are, true.

Re: Programming Language Checklist

#52
post #14

I got an idea for a language where the code in the file format is some intermediary language, which you write with an editor plugin that makes it more human-readable. The editor plugin (in contrast to existing language plugins) also translates the error msgs back to the human-readable code. Just an idea, but I could not get it to fit in the questionaire :)

Projectional editors use that setup. Might be slightly different than what you have in mind since projectional editing is not great at text editing. But have a look at Jetbrains MPS, that's a language workbench for projectional editors.

Simonyi’s Intentional programming also.

Re: Programming Language Checklist

#53
Criticism of Typed FP seems to be the main focus of this as most of it's criticisms seem to be at the top of the list. I think it's partly justified, typed FP has been cargo culted to the point where I've seen hello world implementations that definetely were not obvious and required a PhD in category theory. That said I've seen a ton of python code that took monumentous effort to get working at runtime, and broke unpredictably in production too...

Re: Programming Language Checklist

#54
post #36

Earlier quoted context omitted.

That's not really a difficulty of javascript the language - you're supposed to have your javascript completely separate from the HTML and CSS, with everything in static files of that type. Separation of concerns was built into the web from the beginning. It just happens to be a popular architectural pattern at the moment to reimplement the DOM, HTML and CSS all in javascript and have one big mess of code.

You're right that it's not javascript's fault per se. But the rest of your comment represents a narrow, dated and frankly ignorant viewpoint. Component-based front-end architecture has tremendous advantages. And if you want to see "one big mess", simply examine the CSS of virtually any moderately-sized website or web application. I've been doing web-related development since the late 90's, and I make a living as a UI…

Component-based architecture doesn't imply JS-based versions of HTML and/or CSS, though. React does it that way, e.g. web components don't.

Not that I'm averse to "reinventing" HTML or CSS in the first place, although doing that in JS would be somewhat ironic.

Re: Programming Language Checklist

#55

Earlier quoted context omitted.

I also chuckled at the '[ ] "multi-paradigm"' and immediately thought of lisp since it's one of the only languages that's ever had a reason to lay claim to that. If you think about it, lisp is really just the smallest amount of higher-level PL primordial soup you can give to a programmer.

Almost every language is multi paradigm (it just takes two paradigms after all, so every imperative OOP language is multi paradigm). All the most popular languages today have a mix of imperative, functional and OOP. Few languages (and certainly fewer popular ones) are paradigmically “pure”.

Imperative is orthogonal to object-ness, that doesn’t make a language multi paradigm. C++ was considered multi paradigm because it supported both OOP and procedural programming for organizing code.

Of course, these days procedural is taken for granted and drops off the radar as a notable paradigm.

The dual of imperative is declarative. It is quite possible to have a functional imperative language as Guy Steel points out in his Lambda: the ultimate imperative paper.

Re: Programming Language Checklist

#57

Making a language is fun, and builds your skills. I'd rather work with a person who has made a bad language than someone who has never made one. Don't make fun of people for making languages.

This checklist is, to my eyes, making fun of people who make fun of languages.

Re: Programming Language Checklist

#58

Earlier quoted context omitted.

I also chuckled at the '[ ] "multi-paradigm"' and immediately thought of lisp since it's one of the only languages that's ever had a reason to lay claim to that. If you think about it, lisp is really just the smallest amount of higher-level PL primordial soup you can give to a programmer.

Almost every language is multi paradigm (it just takes two paradigms after all, so every imperative OOP language is multi paradigm). All the most popular languages today have a mix of imperative, functional and OOP. Few languages (and certainly fewer popular ones) are paradigmically “pure”.

> every imperative OOP language is multi paradigm

I am not sure how you can count imperative and OOP as two paradigms. OOP is an extension of imperative paradigm. I would like to see what language you consider to be OOP but not imperative and not functional.

Re: Programming Language Checklist

#59

>> You appear to believe that: Syntax is what makes programming difficult This is exactly the problem. People spend so much effort looking for better syntax that they miss the most important part of programming. It's about design and structure, the syntax doesn't really matter at all. I don't even care if it's dynamically typed or statically typed or functional or not. A bad developer will produce bad code no matter…

A master can make good work with shit tools, but they'll still prefer to work with good tools. Syntax matters because it's part of the interface, and so it has the ability to clarify or confound. Destructuring assignment; async/await instead of CPS (technically not exactly equivalent due to variable scope, but close enough in actual usage); pipe operators/macros instead of (third-function (second-function (first-func…

>Syntax matters

I would say a good developer can make the code clear, I can make my ES5 code clearer then some bad ES7 code, most of the time clear code depends on how you name and split your code in logical and intuitive steps.

Post reply on HN