9 ms·

Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and

Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and important language in the world (probably in the history of programming), so that's two game-changers that don't require static typing.

efficax 6y ago
there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.
- mimixco 6y ago
 I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile. Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive. One of the beautiful things about JS (and Lisp) is that variables and functions are interchangeable and, the case of JS, both can be accessed directly without worrying about an interface.
 - jackjeff 6y ago
 Just use Typescript static types where it is useful. If you access a bunch of JSON objects and you don’t need the typing, you can always declare as ‘any’ and move on. At the end of the day those type exist in JavaScript. If you access ‘first_name’ instead of ‘firstname’ it will not work. The difference is that typescript would let you know before running the code instead of getting an obscure runtime error.
 - austincheney 6y ago
 Deno is having problems with TypeScript, but TypeScript is not the cause of that problem. The problem is a self inflicted issue of a name collision of their choosing.
 - jorams 6y ago
 Slow compile times are very much a problem caused by TypeScript.
 - eitland 6y ago
 My 3 year old laptop has no problems with TypeScript (neither Angular nor React), and I am a rather impatient guy when it comes to computers. I'm honestly wondering: What are people doing to end up in a position where TypeScript compile times are a problem?
 austincheney 6y ago
 It is something to do with a class in their code named something similar to header conflicting with a same named definition in their index.d.ts file that is closely related to that class instance. If they dropped use of classes, or differentiated the names of the two things in collision the problem would appear to be solved. To turn that around and blame TypeScript as the point of failure is an extremely bad omen suggesting their code style opinions are more important than product delivery. I could live with that nonsense if this were a framework or some minor dependency, which this application is not.
 thomasrognon 6y ago
 My compile time went from seconds to minutes when I made a recursive immutable type (which I reverted of course). Overall, I still love typescript. Edit for the curious, here's the monster type that caused such pathological build times... type ImmutablePrimitive = undefined | null | boolean | string | number | Function; export type Immutable<T> = T extends ImmutablePrimitive ? T : T extends [infer U] ? readonly [Immutable] : T extends [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends readonly [infer U] ? readonly [Immutable] : T extends readonly [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends readonly [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends readonly [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends readonly [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends Array<infer U> ? ImmutableArray : T extends ReadonlyArray<infer U> ? ImmutableArray : T extends Map<infer K, infer V> ? ImmutableMap<K, V> : T extends ReadonlyMap<infer K, infer V> ? ImmutableMap<K, V> : T extends Set<infer M> ? ImmutableSet<M> : T extends ReadonlySet<infer M> ? ImmutableSet<M> : ImmutableObject<T>; type ImmutableArray<T> = ReadonlyArray<Immutable<T>>; type ImmutableMap<K, V> = ReadonlyMap<Immutable<K>, Immutable<V>>; type ImmutableSet<T> = ReadonlySet<Immutable<T>>; type ImmutableObject<T> = { readonly [K in keyof T]: Immutable<T[K]> };
 - tigershark 6y ago
 No, it’s not counterproductive to access JSON objects using a predefined schema, it saves your ass in case of typos.
- snarfy 6y ago
 For dynamically typed languages, the idea is you make up for that class of bugs by incorporating TDD and having lots and lots of unit tests. So, instead of waiting a minute for the typescript compiler, you wait for the engineer to write tests.
 - waheoo 6y ago
 If youre doing tdd or writing tests like this you have bigger problems. Type safety is easy in a dynamic language. Stop mutating variables and stop mixing types. Suddenly that whole class of errors evaporates. No need to test things that are impossible. And for those times you want some magic in your life, nothing is stopping you, no need for generics, just proceed with caution and test accordingly.
 - gameswithgo 6y ago
 and you wait a minute for the tests to run every time you commit a change
 - dboreham 6y ago
 You could arrange to have a program write those tests for you based on your description of the project's data model. Oh wait...
 - kybernetikos 6y ago
 You know what, that would already be better than most type systems. Firstly, they'd be written in the same language that you are coding in, not a weird, half baked type language, that adds visual noise to your code. Secondly, they'd have much more power to define meaningful and useful behaviour rather than being restricted to talk about correct behaviour via types. Thirdly, they'd run when you wanted the tests to run, and you could tier different tests to run at different times, so they aren't all slowing you down while you're doing fast iteration. I used to like types, but then I realised that what matters is how quickly you see the bug. Seeing it in your code editor is brilliant, but if it's slower in time than hitting control S and seeing the actual app in the other pane auto reload, and fail or not, then it's worse. These days I look on the idea that you know the exact types of all data your program will interact with at the time you write your code as the same sort of mistake that we made when we thought we understood the deep inheritance hierarchies of the real world.
foepys 6y ago
JavaScript is the most popular language solely because it's the only one that runs in webbrowsers natively. The language itself is not good, it's rather bad from a language designer's point of view.
meowzero 6y ago
That's appeal to popularity. At least lisp is strongly typed. JS happened to be created first, and the world was stuck with it as Web grew and no other alternatives came out.
BiteCode_dev 6y ago
Lisp is not popular. Remove the browser practical monopoly, and JS popularity would vanish.
- pfraze 6y ago
  Browser monopoly led lots of devs to learn JS, then NodeJS showed that lots of devs want to keep using JS. It's actually possible for people to like it. Also, languages are always a function of their ecosystems. You could argue, remove Apple products and Swift/ObjC would vanish.
  - NicoJuicy 6y ago
    Nodejs showed that a lot of developers are lazy and want 1 language to learn
    - vorpalhex 6y ago
      Certainly you didn't go through the entire pro con list of Node over other languages and go "it must be developer laziness!" Easy to reason about, great performance for most cases, simple to debug and write code for, a plethora of libraries, easy to ship, no need to have different teams for backend/frontend, and minimal tooling needed.
      - kbenson 6y ago
        The only really unique thing JS is bringing to the table is that it also has a privileged position in the front end. Your list of benefits it provides boils down to stuff multiple large languages all have, and the one thing that means you can learn just JS. GP comment was presented somewhat snarkily, but I'm not sure they're all that wrong.
        vorpalhex 6y ago
        Sure other languages have some pieces of the puzzle - python has tons of libraries and is easy to understand, golang has great performance and is easy to write, etc. But I have yet to find a language that has the same set of features except JS. If you want to offer up an alternative, please do so.
deleted 6y ago
[deleted]
gameswithgo 6y ago
javascripts success is an accident of history and we have paid a heavy price for it
- shirshak55 6y ago
  null is considered billion dollar mistake but in JS there is 2 null so the statement is not incorrect :P
damnyou 6y ago
Lisp is important for its intellectual contributions, not for its use in large production systems.
- mimixco 6y ago
  It's used for every airline reservation you've ever made. Also, it's used here on HN. And in Grammarly.
jlg23 6y ago
> Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. Lisp programmers use check-type[1] a lot, they proclaim[2] types for performance optimizations and they often deftype[3] if not only for code clarity. And then we have CLOS and its dispatching on types/classes... [1] http://www.lispworks.com/documentation/HyperSpec/Body/m_check_.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_chec... [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_procla.htm#proclaim http://www.lispworks.com/documentation/HyperSpec/Body/f_proc... [3] http://www.lispworks.com/documentation/HyperSpec/Body/m_deftp.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_deft...
carapace 6y ago
> JS ... is the most successful and important language in the world (probably in the history of programming), I object, C is that.

efficax 6y ago

there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.

mimixco 6y ago
I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile. Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive. One of the beautiful things about JS (and Lisp) is that variables and functions are interchangeable and, the case of JS, both can be accessed directly without worrying about an interface.
- jackjeff 6y ago
 Just use Typescript static types where it is useful. If you access a bunch of JSON objects and you don’t need the typing, you can always declare as ‘any’ and move on. At the end of the day those type exist in JavaScript. If you access ‘first_name’ instead of ‘firstname’ it will not work. The difference is that typescript would let you know before running the code instead of getting an obscure runtime error.
- austincheney 6y ago
 Deno is having problems with TypeScript, but TypeScript is not the cause of that problem. The problem is a self inflicted issue of a name collision of their choosing.
 - jorams 6y ago
 Slow compile times are very much a problem caused by TypeScript.
 - eitland 6y ago
 My 3 year old laptop has no problems with TypeScript (neither Angular nor React), and I am a rather impatient guy when it comes to computers. I'm honestly wondering: What are people doing to end up in a position where TypeScript compile times are a problem?
 - austincheney 6y ago
 It is something to do with a class in their code named something similar to header conflicting with a same named definition in their index.d.ts file that is closely related to that class instance. If they dropped use of classes, or differentiated the names of the two things in collision the problem would appear to be solved. To turn that around and blame TypeScript as the point of failure is an extremely bad omen suggesting their code style opinions are more important than product delivery. I could live with that nonsense if this were a framework or some minor dependency, which this application is not.
 - thomasrognon 6y ago
 My compile time went from seconds to minutes when I made a recursive immutable type (which I reverted of course). Overall, I still love typescript. Edit for the curious, here's the monster type that caused such pathological build times... type ImmutablePrimitive = undefined | null | boolean | string | number | Function; export type Immutable<T> = T extends ImmutablePrimitive ? T : T extends [infer U] ? readonly [Immutable] : T extends [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends readonly [infer U] ? readonly [Immutable] : T extends readonly [infer U, infer V] ? readonly [Immutable, Immutable<V>] : T extends readonly [infer U, infer V, infer X] ? readonly [Immutable, Immutable<V>, Immutable<X>] : T extends readonly [infer U, infer V, infer X, infer Y] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>] : T extends readonly [infer U, infer V, infer X, infer Y, infer Z] ? readonly [Immutable, Immutable<V>, Immutable<X>, Immutable<Y>, Immutable<Z>] : T extends Array<infer U> ? ImmutableArray : T extends ReadonlyArray<infer U> ? ImmutableArray : T extends Map<infer K, infer V> ? ImmutableMap<K, V> : T extends ReadonlyMap<infer K, infer V> ? ImmutableMap<K, V> : T extends Set<infer M> ? ImmutableSet<M> : T extends ReadonlySet<infer M> ? ImmutableSet<M> : ImmutableObject<T>; type ImmutableArray<T> = ReadonlyArray<Immutable<T>>; type ImmutableMap<K, V> = ReadonlyMap<Immutable<K>, Immutable<V>>; type ImmutableSet<T> = ReadonlySet<Immutable<T>>; type ImmutableObject<T> = { readonly [K in keyof T]: Immutable<T[K]> };
- tigershark 6y ago
 No, it’s not counterproductive to access JSON objects using a predefined schema, it saves your ass in case of typos.
snarfy 6y ago
For dynamically typed languages, the idea is you make up for that class of bugs by incorporating TDD and having lots and lots of unit tests. So, instead of waiting a minute for the typescript compiler, you wait for the engineer to write tests.
- waheoo 6y ago
  If youre doing tdd or writing tests like this you have bigger problems. Type safety is easy in a dynamic language. Stop mutating variables and stop mixing types. Suddenly that whole class of errors evaporates. No need to test things that are impossible. And for those times you want some magic in your life, nothing is stopping you, no need for generics, just proceed with caution and test accordingly.
- gameswithgo 6y ago
  and you wait a minute for the tests to run every time you commit a change
  - dboreham 6y ago
    You could arrange to have a program write those tests for you based on your description of the project's data model. Oh wait...
    - kybernetikos 6y ago
      You know what, that would already be better than most type systems. Firstly, they'd be written in the same language that you are coding in, not a weird, half baked type language, that adds visual noise to your code. Secondly, they'd have much more power to define meaningful and useful behaviour rather than being restricted to talk about correct behaviour via types. Thirdly, they'd run when you wanted the tests to run, and you could tier different tests to run at different times, so they aren't all slowing you down while you're doing fast iteration. I used to like types, but then I realised that what matters is how quickly you see the bug. Seeing it in your code editor is brilliant, but if it's slower in time than hitting control S and seeing the actual app in the other pane auto reload, and fail or not, then it's worse. These days I look on the idea that you know the exact types of all data your program will interact with at the time you write your code as the same sort of mistake that we made when we thought we understood the deep inheritance hierarchies of the real world.

foepys 6y ago

JavaScript is the most popular language solely because it's the only one that runs in webbrowsers natively. The language itself is not good, it's rather bad from a language designer's point of view.

meowzero 6y ago

That's appeal to popularity. At least lisp is strongly typed. JS happened to be created first, and the world was stuck with it as Web grew and no other alternatives came out.

BiteCode_dev 6y ago

Lisp is not popular. Remove the browser practical monopoly, and JS popularity would vanish.

pfraze 6y ago
Browser monopoly led lots of devs to learn JS, then NodeJS showed that lots of devs want to keep using JS. It's actually possible for people to like it. Also, languages are always a function of their ecosystems. You could argue, remove Apple products and Swift/ObjC would vanish.
- NicoJuicy 6y ago
  Nodejs showed that a lot of developers are lazy and want 1 language to learn
  - vorpalhex 6y ago
    Certainly you didn't go through the entire pro con list of Node over other languages and go "it must be developer laziness!" Easy to reason about, great performance for most cases, simple to debug and write code for, a plethora of libraries, easy to ship, no need to have different teams for backend/frontend, and minimal tooling needed.
    - kbenson 6y ago
      The only really unique thing JS is bringing to the table is that it also has a privileged position in the front end. Your list of benefits it provides boils down to stuff multiple large languages all have, and the one thing that means you can learn just JS. GP comment was presented somewhat snarkily, but I'm not sure they're all that wrong.
      - vorpalhex 6y ago
        Sure other languages have some pieces of the puzzle - python has tons of libraries and is easy to understand, golang has great performance and is easy to write, etc. But I have yet to find a language that has the same set of features except JS. If you want to offer up an alternative, please do so.

deleted 6y ago

[deleted]

gameswithgo 6y ago

javascripts success is an accident of history and we have paid a heavy price for it

shirshak55 6y ago
null is considered billion dollar mistake but in JS there is 2 null so the statement is not incorrect :P

damnyou 6y ago

Lisp is important for its intellectual contributions, not for its use in large production systems.

mimixco 6y ago
It's used for every airline reservation you've ever made. Also, it's used here on HN. And in Grammarly.

jlg23 6y ago

> Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. Lisp programmers use check-type[1] a lot, they proclaim[2] types for performance optimizations and they often deftype[3] if not only for code clarity. And then we have CLOS and its dispatching on types/classes... [1] http://www.lispworks.com/documentation/HyperSpec/Body/m_check_.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_chec... [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_procla.htm#proclaim http://www.lispworks.com/documentation/HyperSpec/Body/f_proc... [3] http://www.lispworks.com/documentation/HyperSpec/Body/m_deftp.htm http://www.lispworks.com/documentation/HyperSpec/Body/m_deft...

carapace 6y ago

> JS ... is the most successful and important language in the world (probably in the history of programming), I object, C is that.