7 ms·

SICP in Python - https://news.ycombinator.com/item?id=22994976 https://news.ycombinator.com/item?id=22994976 You can see there's more negativity in this thread

SICP in Python - https://news.ycombinator.com/item?id=22994976 https://news.ycombinator.com/item?id=22994976 You can see there's more negativity in this thread compared to the Python one. HN crowd is pretty hostile toward JavaScript. Yet JavaScript is obviously a better choice than Python in terms of SICP Scheme substitute. For example: - JavaScript is arguably a Scheme descendant, or at least have closer blood ties with Scheme than Python. - The Lambda in Python is just awkward, and SICP is a book about lambdas. - The Chapter 2: JavaScript use more anonymous object which makes it a better choice, although there are dictionaries in Python it's more favored to use Classes. - Chapter 3, the Object-oriented Programming part: Use lexical closure to simulate object is just day to day JavaScript. So does dispatch and pattern matching messages. - Chapter 3, the stream part: In JavaScript world the "functional" streams approach is also very popular. - As for symbolic programming and such, they're both not particularly good. But that's a problem for all mainstream languages. At least JavaScript has programmable string template. As you can see many SICP stuff are just day-to-day JavaScript, but not so much in idiomatic Python. Let alone JavaScript is more approachable in almost every platform, and much easier to make interactive tutorials.

aaomidi 5y ago
I've really noticed that people rage that Javascript and npm removed so much of a barrier to tech. Try publishing a dependency for Java. Now try doing it for JS. Everyone was able to do highly concurrent workloads. Something that was extremely difficult before Javascript. It just smells of elitism to me. It's a wonderful language that brought the async await system to everyone.
- tasogare 5y ago
  It's C# that created and popularized async/await, not JS (and it having an already open source implementation at the time, it was available to everyone for free).
  - aaomidi 5y ago
    Based on usage numbers, I'm gonna say it was a mix of both. But JS brought it to the very mainstream.
  - hajile 5y ago
    JS introduced promises to the world around 2005 (they were in an unused experimental language a few years before). async/await is mostly specialized syntax over generators. I'd note that ES4 had generators in the early 2000s F# introduced async/await in 2007. C# was mostly copying F# (like it's done for almost every new feature in the past decade or so). Haskell libraries added support around the same time as C# (likely inspired by F#) JS had the feature for several years via transpilers before it was finally added officially.
- rrdujay 5y ago
  You mean it's super hard in java? All they have is maven with hard links into eclipse from my observation. Npm is light years ahead in execution and usage. Python distribution is.... interesting with eggs & poetry
  - namelosw 5y ago
    I agree. I don't find it's hard in Java. But with that being said, in the JavaScript world, the tooling treat developers more like "users" rather than "engineers". For example: - Many documentations are cohesive, well-thought, and well main-maintained. - There are usually handy shortcuts for things like `npx` or `npm i <package name>` - And many other improvements strive for developers' life-quality, such as call back-end and databases with strong typing, but without messy code generator at the same time. Meanwhile, I have worked with Java and C# for quite a while, those documentations are so daunting, they feel like math textbooks from the Soviet Union. And companies like Microsoft never bother to fix their blur resolutions for SQL Server Management Studio and such. It's just like nobody cares, and they make working really feels like screwing codes on production lines.
    - hajile 5y ago
      > But with that being said, in the JavaScript world, the tooling treat developers more like "users" rather than "engineers". For example: Tooling really is about becoming a user. It takes a dozen different file types and shoves them through at least a dozen different type-specific pieces of software. Understanding any one of those to any real degree would take weeks to months. Just JS itself would require understanding transpilers, minifiers (an optimizing compiler), how NPM works, how these work with all the other tools, various module bundling styles, map files, feature differences for literally 10 versions of JS, browser JS limitations (eg, Chrome and FF break the JS spec for tail calls), JS API differences and polyfills, hot reloading techniques, and wrapping an entire server instance into all of this. I'm sure there are other parts I'm not thinking of. I did the hand-rolling of all this stuff for several years before jumping on to create-react-app. I've spent many days reading the documentation only to have to read it all again when the next major version drops and everything changes in slightly incompatible ways. I love learning, but on the whole, this adds very little value to most of the projects I've worked on (though some really did need hand-rolling for very niche requirements). I rather like laving all the tooling to domain experts who know far more about it than I ever will. I'd rather be a "user" and leave all my engineering headspace for the problems at hand.
wallscratch 5y ago
What’s awkward about lambda in python?
- namelosw 5y ago
  - No multi-line support - Gets very messy when nested And SICP is a book about learning computer science by abusing lambdas.
- senkora 5y ago
  Python is based on mainly on statements rather than expressions, and lambdas can’t have multiple statements, so writing lambdas is different from writing normal Python code. In a very real sense, there is no idiomatic way to write complex lambdas in Python. What you would do instead is define a named function and pass it in as an argument. This is fine but definitely more complicated.

aaomidi 5y ago

I've really noticed that people rage that Javascript and npm removed so much of a barrier to tech. Try publishing a dependency for Java. Now try doing it for JS. Everyone was able to do highly concurrent workloads. Something that was extremely difficult before Javascript. It just smells of elitism to me. It's a wonderful language that brought the async await system to everyone.

tasogare 5y ago
It's C# that created and popularized async/await, not JS (and it having an already open source implementation at the time, it was available to everyone for free).
- aaomidi 5y ago
  Based on usage numbers, I'm gonna say it was a mix of both. But JS brought it to the very mainstream.
- hajile 5y ago
  JS introduced promises to the world around 2005 (they were in an unused experimental language a few years before). async/await is mostly specialized syntax over generators. I'd note that ES4 had generators in the early 2000s F# introduced async/await in 2007. C# was mostly copying F# (like it's done for almost every new feature in the past decade or so). Haskell libraries added support around the same time as C# (likely inspired by F#) JS had the feature for several years via transpilers before it was finally added officially.
rrdujay 5y ago
You mean it's super hard in java? All they have is maven with hard links into eclipse from my observation. Npm is light years ahead in execution and usage. Python distribution is.... interesting with eggs & poetry
- namelosw 5y ago
  I agree. I don't find it's hard in Java. But with that being said, in the JavaScript world, the tooling treat developers more like "users" rather than "engineers". For example: - Many documentations are cohesive, well-thought, and well main-maintained. - There are usually handy shortcuts for things like `npx` or `npm i <package name>` - And many other improvements strive for developers' life-quality, such as call back-end and databases with strong typing, but without messy code generator at the same time. Meanwhile, I have worked with Java and C# for quite a while, those documentations are so daunting, they feel like math textbooks from the Soviet Union. And companies like Microsoft never bother to fix their blur resolutions for SQL Server Management Studio and such. It's just like nobody cares, and they make working really feels like screwing codes on production lines.
  - hajile 5y ago
    > But with that being said, in the JavaScript world, the tooling treat developers more like "users" rather than "engineers". For example: Tooling really is about becoming a user. It takes a dozen different file types and shoves them through at least a dozen different type-specific pieces of software. Understanding any one of those to any real degree would take weeks to months. Just JS itself would require understanding transpilers, minifiers (an optimizing compiler), how NPM works, how these work with all the other tools, various module bundling styles, map files, feature differences for literally 10 versions of JS, browser JS limitations (eg, Chrome and FF break the JS spec for tail calls), JS API differences and polyfills, hot reloading techniques, and wrapping an entire server instance into all of this. I'm sure there are other parts I'm not thinking of. I did the hand-rolling of all this stuff for several years before jumping on to create-react-app. I've spent many days reading the documentation only to have to read it all again when the next major version drops and everything changes in slightly incompatible ways. I love learning, but on the whole, this adds very little value to most of the projects I've worked on (though some really did need hand-rolling for very niche requirements). I rather like laving all the tooling to domain experts who know far more about it than I ever will. I'd rather be a "user" and leave all my engineering headspace for the problems at hand.

wallscratch 5y ago

What’s awkward about lambda in python?

namelosw 5y ago
- No multi-line support - Gets very messy when nested And SICP is a book about learning computer science by abusing lambdas.
senkora 5y ago
Python is based on mainly on statements rather than expressions, and lambdas can’t have multiple statements, so writing lambdas is different from writing normal Python code. In a very real sense, there is no idiomatic way to write complex lambdas in Python. What you would do instead is define a named function and pass it in as an argument. This is fine but definitely more complicated.