4 ms·

Far more important is instant feedback and that’s getting worse all the time: with lisp, smalltalk, Delphi, forth things were instant. With typescript or rust e

Far more important is instant feedback and that’s getting worse all the time: with lisp, smalltalk, Delphi, forth things were instant. With typescript or rust etc, if the project is larger than hello world, the feedback is well, far from instant. Bret victor talked about feedback, not necessarily visual programming and for some reason we are making things worse instead of better. When I show a Common Lisp dev session to young people, they think I am somehow cheating. I am, because I am not using the garbage people produce now and we are always faster (sbcl is incredible; sure you can do less latency and more performance with rust or c but then you don’t have the debugger and feedback while it takes a lot more code aka bugs and work), less bugs and not depressed while at work. We also don’t have to hire ‘devops’ to waste our profits; I like profits and I like not needing VCs.

ta_1138 2y ago
As projects get bigger, things might get sadder. I worked at a certain large SF company that uses a lot of ruby, so most development was repl-based too. But this wasn't a boon but a curse, as the total lack of data format guarantees on the very large, critical monorepo meant a lot of uncertainty. What does this method really do? I guess we have to run it! It worked for this specific input... but will it work for any and all inputs that get to this data path? Let's hope so, because we aren't sure! The company spent massive amounts of money on servers for parallel testing, just so that the suite could run in less than a few weeks. And when you need a large test suite to have a chance, most of the advantages of the REPL vs a compiler have been lost. Eventually they did the same thing you can do in common lisp: Add so much metaprogramming that doublechecks invariants, it might as well be a compiled language.
- brabel 2y ago
  Common Lisp has always allowed you to specify types anywhere you want. It's not a statically typed language but it supports types (and SBCL and other impls do static checking where possible).
- CharlieDigital 2y ago
  I think that OOP done right can address this problem through encapsulation of the logic. One can make the case that a function can do the same. I agree, but a class is just a container for a set of related functions and state. The problem with OOP seems to be that as a whole, devs are not that great at encapsulation and isolating domain logic.
  - patrickmay 2y ago
    The number of codebases I've worked on where developers automatically added getters and setters for all class members is too damn high.
- pgris2 2y ago
  So, paraphrasing: Any sufficiently complicated Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Java
- tdbgamer 2y ago
  I guess the upside is that you end up with a "compiler" that checks the invariants of your project and that domain rather than strict type safety. I love static typing, but I did try Elixir w/ Phoenix recently and was impressed that they were able to implement compile time checks like verifying that all redirects are valid routes, etc. Depending on what you're building, having a few small domain specific checks like that could be more valuable than strict type safety.
ryandv 2y ago
With strong, expressive type systems such as those offered by Haskell, Rust, TypeScript, etc... I find that you front-load all of your debugging to compile/typecheck time. Instead of needing to experiment with your code at runtime through either manual or automated (TDD) tests, you are instead having a conversation with the compiler/typechecker to statically guarantee its correctness. There's just as tight a feedback loop with a typechecker as there is with a test runner; you in fact get your feedback even sooner during compile time, instead of during the subsequent runtime. Where static verification against a typechecker shines over runtime verification against a test suite is that a test suite can only demonstrate the presence of bugs; type systems demonstrate their absence (presuming of course that you understand how to encode certain invariants into your types and don't do some foolishness such as simply asserting all values as `any`).
- aftoprokrustes 2y ago
  While I prefer expressive type systems by a long shot, I would be much more careful about it "guaranteeing correctness". Types can act as good documentation and as a safeguard for stupid mistakes. But the worst bugs are due to logic mistakes, wrong assumptions or non-foreseen corner cases. Here, either types do not help, or designing the type system is so difficult it is not worth the effort, and makes many future changes more difficult. In my previous company we used Scala (with and without Spark) for everything, and this setup pretty much allows you both extremes. There was always a middle ground to be found, where types were expressive enough that they were useful, but not too much that they came in the way.
  - szundi 2y ago
    It guarantees certain correctness it is having conversations with you about - this way more correct
  - tossandthrow 2y ago
    Just encode your business logic in types first! Coq, Idris, or F* will certainly get the job done for you! /s
FireInsight 2y ago
I don't know what TypeScript projects you have worked on, but every one I have worked on is instant reload all the way down. Rust, on the other hand, is pretty miserable.
- anonzzzies 2y ago
  I don’t know; I am a programmer but more of a trouble shooter (it makes far more) and projects passing 100k LoC in ts which I see 100s a year, are not instant, in any way. I would love to see one, but I contribute to open source projects, and it’s all slow, very very slow.
  - nox101 2y ago
    I'm working on 250k LoC TS project. It's instant during dev. We don't bundle during dev so the server just has to compile which ever files changed.
    - anonzzzies 2y ago
      Well, I would love to learn how it’s possible: you have a blog or YouTube or something?
      - e1g 2y ago
        Our front end is ~200k LOC of TypeScript and all changes are instant (<1s). TypeScript compiler is too slow for hot module replacement so it’s used only for IDEs. During development, all transformation happens via esbuild/swc and is abstracted away with Vite https://vitejs.dev/ https://vitejs.dev/
        brabel 2y ago
        esbuild does not do type checking. You must invoke tsc explicitly to do that.
        2y ago
IshKebab 2y ago
Typescript is pretty fast no? I've worked on the VSCode codebase a fair bit and the intellisense seems pretty fast. Like under a second, which is fine. You don't need to resort to Lisp to get instant feedback. Try Dart - it's basically instant. Rust I will give you...
- anonzzzies 2y ago
  Agreed, I just prefer lisp. We use flutter a lot, but we do it in cl -> dart; it makes everyone here (again taste, not gospel) happier.
  - brabel 2y ago
    What do you use to compile CL to Dart? Or you compile to JS?
ben_w 2y ago
I think that's also true, but not the thing they're writing about. My experience as an iOS developer has been mixed between places that use Interface Builder and those who create the UI in code. Something like Interface Builder is obviously a great idea for UI creation, which is why it survived so long and why Figma exists, but the actual tool itself (IB) isn't really useful for desigers who want one thing that works on all platforms. (Complaints like "xib and storyboard are hard to use with version control" miss the point; a UI designer shouldn't be seeing git-style text diffs anyway, they need a graphical diff). Interface Builder is at least 5x faster than making the UI in code; one place in particular, I was making a native app by myself while a whole team was making a web app, and I wasn't simply keeping up with them, I also cought up the headstart they had built while I'd been assigned to a different project. The next place I joined a team and their app was a coded UI, and development was correspondingly slow. (Though how much of this is "teams are slower than solo developers" vs. my hypothesis is unclear to me). My first coding job was before iOS existed, I was industrial placement student* in an academic research lab, and for that, my guess would be the best option mayhaps have been a mathematical formula WYSIWYG editor that output both latex and IDL. * does this term get used outside the UK? What's the overlap between this and intern?
- nottorp 2y ago
  Haven't worked with the iOS interface builder but i worked with Delphi ages ago. Question: how well does the interface builder thingy mix with interface in code? Can you easily lay out the basics of an UI graphically and then add code where the builder is too limited for what you need? Or it's the kind where if you start with the graphical builder you're stuck with just what the graphical builder can do?
  - WillAdams 2y ago
    A quick overview of Interface Builder is Steve Job's demo for NeXT --- perhaps: https://www.youtube.com/watch?v=dl0CbKYUFTY https://www.youtube.com/watch?v=dl0CbKYUFTY where they discuss how dragging/drawing allows one to make 80% of the app, and the balance of 20% is one's own code.
Waterluvian 2y ago
I’ve got a 500 file, 100k sloc typescript project with instant feedback which makes me wonder: what is a large project? Are most people somehow working on giant repos?
bandrami 2y ago
As a fellow ancient person my only consolation is that the browser-based development experience most people now learn on is (with some path-dependent ugliness) basically the experience Smalltalk promised us in the 1980s and never quite delivered.
- taeric 2y ago
  I'm confused? Smalltalk promised image based development where you could change things on the fly. That is far from what I typically see in browser based development.
galdosdi 2y ago
Honest question as a java lover-- do rust and TS have slow compile times or something? Because java has a robust type system and yet I've never had any issue with it's compile times. And the parsing in the IDEs is so fast and good I can pretty much get all the feedback in real time. Ah, that's the luxury of using a battle tested language that other people have invested billions of dollars of effort into optimizing. Do you guys not have that in Rust and TS? Bummer man. Hope you get there someday. This is exactly why I abandoned scala btw.
- swsieber 2y ago
  Yes - Rust has pretty slow compile times. It is perhaps my biggest gripe with it. You might define java as having a robust type system, but I would rate Rust's as significantly better. Several things in Rust I miss when working in Java: * Monomorphized types * Sum type and product types. Think sealed classes in java, but with better ergonomics * A really clever type system that prevents things like ConcurrentModificationException and data races (not dead-locks or race conditions generally though). Though, IIUC, Rust made early decisions about module structure that have really hindered compile speed, not necessarily tied to the type system. Another big factor that makes rust slow would be optimizations & slow system linkers; it doesn't have a JVM that can warm up to optimize stuff. Source: work with both Rust and Java on a daily basis. Edit: The way the type system works out in general makes me far less worried about making sweeping changes in a Rust codebase than in a Java codebase, but there are still logic bugs that I miss occasionally. Still, it moves quite a big bug finding from "run the program and see" to "make it pass typechecking", which is quite a bit faster than compiling; you can typecheck Rust without compiling it.
  - roland35 2y ago
    I find using cargo watch really helps with my perceived compile times - it runs a check then build on every file save. By the time I open a new terminal to test things out it is ready to go!
- airstrike 2y ago
  In my experience Rust still compiles as fast as I need it to (other than for the very first fresh compilation) and using language servers / rust-analyze I get literal instant feedback in vscode as I hit save. Not to mention autocomplete...
deleted 2y ago
[deleted]
anonzzzies 2y ago
So far, no examples of an instant typescript while a lot of fans for some reason. Come on people; 1 non trivial (few 100k LoC) ts project on GitHub that hot reloads instantly. If no one can produce even one, something is off no? Making claims is easy; not cl but emacs is non trivial and notoriously slow, still ‘instant’ compared to whatever ts (not hello world, but including hello world; it’s super slow) that I found so far on the same hardware. Sbcl is cl and it’s very fast, almost always instant, obviously depending on what you are doing. CLOG is a frontend joy to work in unlike ts. But many people here say ts is instant (we use the same tooling as peeps here for ts); one non trivial example please. No one produced one and all I try is dog slow. Not even comparatively, just spinning balls on a modern laptop. Some of the most popular devs make projects that ‘hot reload’ on my and my colleagues laptops in 20 or so seconds.

ta_1138 2y ago

As projects get bigger, things might get sadder. I worked at a certain large SF company that uses a lot of ruby, so most development was repl-based too. But this wasn't a boon but a curse, as the total lack of data format guarantees on the very large, critical monorepo meant a lot of uncertainty. What does this method really do? I guess we have to run it! It worked for this specific input... but will it work for any and all inputs that get to this data path? Let's hope so, because we aren't sure! The company spent massive amounts of money on servers for parallel testing, just so that the suite could run in less than a few weeks. And when you need a large test suite to have a chance, most of the advantages of the REPL vs a compiler have been lost. Eventually they did the same thing you can do in common lisp: Add so much metaprogramming that doublechecks invariants, it might as well be a compiled language.

brabel 2y ago
Common Lisp has always allowed you to specify types anywhere you want. It's not a statically typed language but it supports types (and SBCL and other impls do static checking where possible).
CharlieDigital 2y ago
I think that OOP done right can address this problem through encapsulation of the logic. One can make the case that a function can do the same. I agree, but a class is just a container for a set of related functions and state. The problem with OOP seems to be that as a whole, devs are not that great at encapsulation and isolating domain logic.
- patrickmay 2y ago
  The number of codebases I've worked on where developers automatically added getters and setters for all class members is too damn high.
pgris2 2y ago
So, paraphrasing: Any sufficiently complicated Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Java
tdbgamer 2y ago
I guess the upside is that you end up with a "compiler" that checks the invariants of your project and that domain rather than strict type safety. I love static typing, but I did try Elixir w/ Phoenix recently and was impressed that they were able to implement compile time checks like verifying that all redirects are valid routes, etc. Depending on what you're building, having a few small domain specific checks like that could be more valuable than strict type safety.

ryandv 2y ago

With strong, expressive type systems such as those offered by Haskell, Rust, TypeScript, etc... I find that you front-load all of your debugging to compile/typecheck time. Instead of needing to experiment with your code at runtime through either manual or automated (TDD) tests, you are instead having a conversation with the compiler/typechecker to statically guarantee its correctness. There's just as tight a feedback loop with a typechecker as there is with a test runner; you in fact get your feedback even sooner during compile time, instead of during the subsequent runtime. Where static verification against a typechecker shines over runtime verification against a test suite is that a test suite can only demonstrate the presence of bugs; type systems demonstrate their absence (presuming of course that you understand how to encode certain invariants into your types and don't do some foolishness such as simply asserting all values as `any`).

aftoprokrustes 2y ago
While I prefer expressive type systems by a long shot, I would be much more careful about it "guaranteeing correctness". Types can act as good documentation and as a safeguard for stupid mistakes. But the worst bugs are due to logic mistakes, wrong assumptions or non-foreseen corner cases. Here, either types do not help, or designing the type system is so difficult it is not worth the effort, and makes many future changes more difficult. In my previous company we used Scala (with and without Spark) for everything, and this setup pretty much allows you both extremes. There was always a middle ground to be found, where types were expressive enough that they were useful, but not too much that they came in the way.
- szundi 2y ago
  It guarantees certain correctness it is having conversations with you about - this way more correct
- tossandthrow 2y ago
  Just encode your business logic in types first! Coq, Idris, or F* will certainly get the job done for you! /s

FireInsight 2y ago

I don't know what TypeScript projects you have worked on, but every one I have worked on is instant reload all the way down. Rust, on the other hand, is pretty miserable.

anonzzzies 2y ago
I don’t know; I am a programmer but more of a trouble shooter (it makes far more) and projects passing 100k LoC in ts which I see 100s a year, are not instant, in any way. I would love to see one, but I contribute to open source projects, and it’s all slow, very very slow.
- nox101 2y ago
  I'm working on 250k LoC TS project. It's instant during dev. We don't bundle during dev so the server just has to compile which ever files changed.
  - anonzzzies 2y ago
    Well, I would love to learn how it’s possible: you have a blog or YouTube or something?
    - e1g 2y ago
      Our front end is ~200k LOC of TypeScript and all changes are instant (<1s). TypeScript compiler is too slow for hot module replacement so it’s used only for IDEs. During development, all transformation happens via esbuild/swc and is abstracted away with Vite https://vitejs.dev/ https://vitejs.dev/
      - brabel 2y ago
        esbuild does not do type checking. You must invoke tsc explicitly to do that.
        2y ago

IshKebab 2y ago

Typescript is pretty fast no? I've worked on the VSCode codebase a fair bit and the intellisense seems pretty fast. Like under a second, which is fine. You don't need to resort to Lisp to get instant feedback. Try Dart - it's basically instant. Rust I will give you...

anonzzzies 2y ago
Agreed, I just prefer lisp. We use flutter a lot, but we do it in cl -> dart; it makes everyone here (again taste, not gospel) happier.
- brabel 2y ago
  What do you use to compile CL to Dart? Or you compile to JS?

ben_w 2y ago

I think that's also true, but not the thing they're writing about. My experience as an iOS developer has been mixed between places that use Interface Builder and those who create the UI in code. Something like Interface Builder is obviously a great idea for UI creation, which is why it survived so long and why Figma exists, but the actual tool itself (IB) isn't really useful for desigers who want one thing that works on all platforms. (Complaints like "xib and storyboard are hard to use with version control" miss the point; a UI designer shouldn't be seeing git-style text diffs anyway, they need a graphical diff). Interface Builder is at least 5x faster than making the UI in code; one place in particular, I was making a native app by myself while a whole team was making a web app, and I wasn't simply keeping up with them, I also cought up the headstart they had built while I'd been assigned to a different project. The next place I joined a team and their app was a coded UI, and development was correspondingly slow. (Though how much of this is "teams are slower than solo developers" vs. my hypothesis is unclear to me). My first coding job was before iOS existed, I was industrial placement student* in an academic research lab, and for that, my guess would be the best option mayhaps have been a mathematical formula WYSIWYG editor that output both latex and IDL. * does this term get used outside the UK? What's the overlap between this and intern?

nottorp 2y ago
Haven't worked with the iOS interface builder but i worked with Delphi ages ago. Question: how well does the interface builder thingy mix with interface in code? Can you easily lay out the basics of an UI graphically and then add code where the builder is too limited for what you need? Or it's the kind where if you start with the graphical builder you're stuck with just what the graphical builder can do?
- WillAdams 2y ago
  A quick overview of Interface Builder is Steve Job's demo for NeXT --- perhaps: https://www.youtube.com/watch?v=dl0CbKYUFTY https://www.youtube.com/watch?v=dl0CbKYUFTY where they discuss how dragging/drawing allows one to make 80% of the app, and the balance of 20% is one's own code.

Waterluvian 2y ago

I’ve got a 500 file, 100k sloc typescript project with instant feedback which makes me wonder: what is a large project? Are most people somehow working on giant repos?

bandrami 2y ago

As a fellow ancient person my only consolation is that the browser-based development experience most people now learn on is (with some path-dependent ugliness) basically the experience Smalltalk promised us in the 1980s and never quite delivered.

taeric 2y ago
I'm confused? Smalltalk promised image based development where you could change things on the fly. That is far from what I typically see in browser based development.

galdosdi 2y ago

Honest question as a java lover-- do rust and TS have slow compile times or something? Because java has a robust type system and yet I've never had any issue with it's compile times. And the parsing in the IDEs is so fast and good I can pretty much get all the feedback in real time. Ah, that's the luxury of using a battle tested language that other people have invested billions of dollars of effort into optimizing. Do you guys not have that in Rust and TS? Bummer man. Hope you get there someday. This is exactly why I abandoned scala btw.

swsieber 2y ago
Yes - Rust has pretty slow compile times. It is perhaps my biggest gripe with it. You might define java as having a robust type system, but I would rate Rust's as significantly better. Several things in Rust I miss when working in Java: * Monomorphized types * Sum type and product types. Think sealed classes in java, but with better ergonomics * A really clever type system that prevents things like ConcurrentModificationException and data races (not dead-locks or race conditions generally though). Though, IIUC, Rust made early decisions about module structure that have really hindered compile speed, not necessarily tied to the type system. Another big factor that makes rust slow would be optimizations & slow system linkers; it doesn't have a JVM that can warm up to optimize stuff. Source: work with both Rust and Java on a daily basis. Edit: The way the type system works out in general makes me far less worried about making sweeping changes in a Rust codebase than in a Java codebase, but there are still logic bugs that I miss occasionally. Still, it moves quite a big bug finding from "run the program and see" to "make it pass typechecking", which is quite a bit faster than compiling; you can typecheck Rust without compiling it.
- roland35 2y ago
  I find using cargo watch really helps with my perceived compile times - it runs a check then build on every file save. By the time I open a new terminal to test things out it is ready to go!
airstrike 2y ago
In my experience Rust still compiles as fast as I need it to (other than for the very first fresh compilation) and using language servers / rust-analyze I get literal instant feedback in vscode as I hit save. Not to mention autocomplete...

deleted 2y ago

[deleted]

anonzzzies 2y ago

So far, no examples of an instant typescript while a lot of fans for some reason. Come on people; 1 non trivial (few 100k LoC) ts project on GitHub that hot reloads instantly. If no one can produce even one, something is off no? Making claims is easy; not cl but emacs is non trivial and notoriously slow, still ‘instant’ compared to whatever ts (not hello world, but including hello world; it’s super slow) that I found so far on the same hardware. Sbcl is cl and it’s very fast, almost always instant, obviously depending on what you are doing. CLOG is a frontend joy to work in unlike ts. But many people here say ts is instant (we use the same tooling as peeps here for ts); one non trivial example please. No one produced one and all I try is dog slow. Not even comparatively, just spinning balls on a modern laptop. Some of the most popular devs make projects that ‘hot reload’ on my and my colleagues laptops in 20 or so seconds.