3 ms·

When I was naive and young I dreamed about some day make a programming language that was just english… The I learned about y2k, there was such a thing (more o

by f1shy 1y ago

When I was naive and young I dreamed about some day make a programming language that was just english… The I learned about y2k, there was such a thing (more or less) from Apple. It implied knowing a strict subset of english and the correct words and constructs… it was a pain to program that (at least for me) More or less at that time, I started understanding that programming languages limitations, although at the beginning a necessity, were a feature. Indeed it was already a very small subset of English, with very specific, succinct, small grammar, that was easy to learn (well, C++ stoped being learnable some years ago… but you get the point) The idea of LLM eliminating good designed languages is hard for me to believe, just as stated in the article.

add-sub-mul-div 1y ago
Yeah. In other words, finding a way to program people with Python would have a bigger payoff than programming computers with English.
biomcgary 1y ago
I think you are getting at the need for tiered layers of abstraction and constraint. Simultaneously considering all possible ways to solve a problem doesn't work for humans or the LLMs derived from our use of language. The repeated use of Domain Specific Languages (DSL) in the context of a general purpose programming language gets at this same need to constrain solution spaces within a reasonable boundary. Once we have quantum LLMs, the need for intermediate abstraction layers might change, but that's very [insert magic here].
Towaway69 1y ago
I’m kind of seeing a visual approach to programming as a programming language agnostic way of coding. For that, I a big fan of flow based programming as the agnostic part. For the implementation, I’m thinking of Node-Red which is a visual implementation of flow based programming. To become programming language agnostic, I’ve started on the Erlang-Red project which takes the frontend of Node Red and bolts it onto an Erlang backend. Eventually the visual flow code will be programming languages independent.
- f1shy 1y ago
  I haven’t had luck with visual programming. I miss the easy to refactor things, copy/paste/move… in big projects for me at least tends to get messy. Anybody who has used labview for some years will probably agree. I have dreamed about a programming language which would be basically text, but the editor would present it as a kind of flow chart. Maybe can be done with any existing programming language? But I found some troubles with language extensions… maybe someday someone much smarter than me can implement that in a meaningful way.
  - Towaway69 1y ago
    Node-RED offers good abstractions for organising visual code: - subflows for grouping common code that can be reused - link nodes for defining "gotos" visually and also making code reusable - flow tabs that group a set of nodes in a single tab and where link nodes can be used to jump into these tabs - node packages that define new nodes but also encapsulate NodeJS code into a single visual element, i.e. a node. Having said that, many textual tools and ideas are still missing their visual equivalence - how to do version control of visual code - how to compare visual code between versions - how to work collaboratively on the same code base - what is refactoring in a visual program? moving and aligning is a form of refactoring that can lead to better understanding - how to label visual elements in a consist manner, i.e., coding conventions - what is the equivalent to the 4 versus 2 spaces/tabs debate in visual programming? But just as many questions remain unanswered in the AI/Vibe coding scene, so that doesn't mean visual programming isn't to taken seriously, it's just means its not trivial. I think visual programming should be taken more seriously and thought through. I like to say that we went from punchcards to keyboards and somehow we stopped there - when it comes to programming. At the same time we went from phones with operators to dial phones to push button phones to smart phones with touch screens. Why not the same for programming? What makes programming so inherently keyboard bound?
  - skydhash 1y ago
    Not flow chart, but the closest in terms of UX improvement is live programming. Smalltalk and Lisp have that, as well as JS in the browser. Basically you can run any snippets you run and redefine almost everything. It's quite different workflow from the default Edit-Compile-Run. That's one of the reason people love Emacs. Once you've loaded the software, you can rebuild it from the inside out without ever shutting it down. You think of a feature, you build it directly, piece by piece, instead of creating a new project, etc,...
deadbabe 1y ago
Once upon a time, some people had the same dream. And so, SQL was born, and is now used all across the globe to manage critical systems. Plain English that even a business person could understand.
- Izkata 1y ago
  COBOL was the same, wasn't it?
- f1shy 1y ago
  Yes. But that is a limited DSL. For systems programming, may be more difficult.
  - hnlmorg 1y ago
    COBOL, FORTRAN, ALGOL, have been around since the 60s. ADA and Pascal since the 70s. Really it's just the B-derived languages (C, C++, C#, Objective-C, D, Rust, Java, Go, etc) that aren't executable pseudo-code. And they weren't even mainstream originally, with Pascal and its ilk being the preferred syntax until the mid-to-late 80s. I really do think computing took a huge step backwards when C became the default on home computers.
    - bigfishrunning 1y ago
      I think the reason that C "became the default" is because people were productive using it. If the other languages were that much better then the B-based ones, wouldn't the people using them simply out compete the ones not using them?
      - hnlmorg 1y ago
        Developers make contradictory productivity claims all the time. You see it with LLMs, strongly vs weakly typed languages, GC vs non-GC, React Native vs Kotin / Swift, JIT languages vs AOT languages, and so on and so forth. Back in the 80s and 90s the bigger concern was portability and cost of the compiler license, both of which C did better. C was closer to the metal than vanilla Pascal too. But commercial Pascal dialects supported pointers, inlined assembly, and everything else you needed to write low-level systems code. Which again comes back to C offering better portability and cheaper licenses.
init1 1y ago
You're in luck. Try Ada (it's great BTW)

by f1shy 1y ago

add-sub-mul-div 1y ago

Yeah. In other words, finding a way to program people with Python would have a bigger payoff than programming computers with English.

biomcgary 1y ago

I think you are getting at the need for tiered layers of abstraction and constraint. Simultaneously considering all possible ways to solve a problem doesn't work for humans or the LLMs derived from our use of language. The repeated use of Domain Specific Languages (DSL) in the context of a general purpose programming language gets at this same need to constrain solution spaces within a reasonable boundary. Once we have quantum LLMs, the need for intermediate abstraction layers might change, but that's very [insert magic here].

Towaway69 1y ago

I’m kind of seeing a visual approach to programming as a programming language agnostic way of coding. For that, I a big fan of flow based programming as the agnostic part. For the implementation, I’m thinking of Node-Red which is a visual implementation of flow based programming. To become programming language agnostic, I’ve started on the Erlang-Red project which takes the frontend of Node Red and bolts it onto an Erlang backend. Eventually the visual flow code will be programming languages independent.

f1shy 1y ago
I haven’t had luck with visual programming. I miss the easy to refactor things, copy/paste/move… in big projects for me at least tends to get messy. Anybody who has used labview for some years will probably agree. I have dreamed about a programming language which would be basically text, but the editor would present it as a kind of flow chart. Maybe can be done with any existing programming language? But I found some troubles with language extensions… maybe someday someone much smarter than me can implement that in a meaningful way.
- Towaway69 1y ago
  Node-RED offers good abstractions for organising visual code: - subflows for grouping common code that can be reused - link nodes for defining "gotos" visually and also making code reusable - flow tabs that group a set of nodes in a single tab and where link nodes can be used to jump into these tabs - node packages that define new nodes but also encapsulate NodeJS code into a single visual element, i.e. a node. Having said that, many textual tools and ideas are still missing their visual equivalence - how to do version control of visual code - how to compare visual code between versions - how to work collaboratively on the same code base - what is refactoring in a visual program? moving and aligning is a form of refactoring that can lead to better understanding - how to label visual elements in a consist manner, i.e., coding conventions - what is the equivalent to the 4 versus 2 spaces/tabs debate in visual programming? But just as many questions remain unanswered in the AI/Vibe coding scene, so that doesn't mean visual programming isn't to taken seriously, it's just means its not trivial. I think visual programming should be taken more seriously and thought through. I like to say that we went from punchcards to keyboards and somehow we stopped there - when it comes to programming. At the same time we went from phones with operators to dial phones to push button phones to smart phones with touch screens. Why not the same for programming? What makes programming so inherently keyboard bound?
- skydhash 1y ago
  Not flow chart, but the closest in terms of UX improvement is live programming. Smalltalk and Lisp have that, as well as JS in the browser. Basically you can run any snippets you run and redefine almost everything. It's quite different workflow from the default Edit-Compile-Run. That's one of the reason people love Emacs. Once you've loaded the software, you can rebuild it from the inside out without ever shutting it down. You think of a feature, you build it directly, piece by piece, instead of creating a new project, etc,...

deadbabe 1y ago

Once upon a time, some people had the same dream. And so, SQL was born, and is now used all across the globe to manage critical systems. Plain English that even a business person could understand.

Izkata 1y ago
COBOL was the same, wasn't it?
f1shy 1y ago
Yes. But that is a limited DSL. For systems programming, may be more difficult.
- hnlmorg 1y ago
  COBOL, FORTRAN, ALGOL, have been around since the 60s. ADA and Pascal since the 70s. Really it's just the B-derived languages (C, C++, C#, Objective-C, D, Rust, Java, Go, etc) that aren't executable pseudo-code. And they weren't even mainstream originally, with Pascal and its ilk being the preferred syntax until the mid-to-late 80s. I really do think computing took a huge step backwards when C became the default on home computers.
  - bigfishrunning 1y ago
    I think the reason that C "became the default" is because people were productive using it. If the other languages were that much better then the B-based ones, wouldn't the people using them simply out compete the ones not using them?
    - hnlmorg 1y ago
      Developers make contradictory productivity claims all the time. You see it with LLMs, strongly vs weakly typed languages, GC vs non-GC, React Native vs Kotin / Swift, JIT languages vs AOT languages, and so on and so forth. Back in the 80s and 90s the bigger concern was portability and cost of the compiler license, both of which C did better. C was closer to the metal than vanilla Pascal too. But commercial Pascal dialects supported pointers, inlined assembly, and everything else you needed to write low-level systems code. Which again comes back to C offering better portability and cheaper licenses.

init1 1y ago

You're in luck. Try Ada (it's great BTW)