161–169 of 169 posts
Earlier quoted context omitted.
Pascal has never been popular. Certain offshoots of Pascal got popular, none so much as Delphi. Which some people still use.
Maybe not in the US. It was pretty popular for example in the USSR back in 1980-90ies.
Earlier quoted context omitted.
> when the language itself (spec and implementation) is constantly in flux. Common Lisp and Clojure are legendary for their stability. So many times I have experienced it myself - I would pick up a 5-6 year old Clojure project, update a bunch of dependencies, and somehow most things work right off the bat. That trick never worked for me with pretty much any other language - C#, Java, Python, Ruby, Go, Lua, Javascript…
I thought Common Lisp is stable because the standard is unchanged since its publication in 1994. Lisp dialects have a lot of syntax. Every macro implements syntax.
Earlier quoted context omitted.
I'm sure the authors have heard of Lisp. And I suspect the authors are making a dig at the fact that Lisp is now over 60 years old and its popularity has been dwarfed by many, many "worse" languages (partially because Lisp has several properties that are checkboxes in this list ;) ).
You're making a classic mistake - Lisp is not a language. It's a set of ideas. Some brilliant ideas. Pretty much every single PL that in use today was influenced by those ideas. There's plenty of Lisp in Python and Javascript. And pretty much there's a Lisp dialect and compiler/transpiler/interpreter for every platform today. Lisp (despite being over 60 years old) never went out of fashion and I doubt it ever will.
Earlier quoted context omitted.
I thought Common Lisp is stable because the standard is unchanged since its publication in 1994. Lisp dialects have a lot of syntax. Every macro implements syntax.
Macros don't get written very often. Some Lispers (e.g.: Clojurists) advocate against solving problems with macros (if they can be solved with regular functions). However, at the end of the day, macro or a function - data remains data. In non-lispy languages syntax often complects meaning and order.
It's not how often you write macros. Just write ten macros -> ten syntax extensions. The Common Lisp implementation I use has around 700 predefined external macros.
> against solving problems with macros (if they can be solved with regular functions).
It's just that macros are for different things and for those are widely used in Lisp.
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 :)
Have you heard of Unison? If not, it may interest you -- it stores code in a syntax tree rather than as text directly. https://www.unisonweb.org/ >Unison is a language in which programs are not text. That is, the source of truth for a program is not its textual representation as source code, but its structured representation as an abstract syntax tree. It has some further goals for doing this which are really excitin…
Has there really been only one big thread? https://news.ycombinator.com/item?id=6784085 Edit: well, there's also this: https://news.ycombinator.com/item?id=7836410 Can anybody track down the year this was written?
https://news.ycombinator.com/item?id=3099979
I'm glad it's stood the test of ~8 years time so far.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Hint: they're JS APIs.
Earlier quoted context omitted.
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.
Huh? How do you think web components are implemented? Hint: they're JS APIs.