[HN Gopher] Programming Languages That Blew My Mind (2023)
___________________________________________________________________
Programming Languages That Blew My Mind (2023)
Author : todsacerdoti
Score : 116 points
Date : 2024-10-31 09:03 UTC (3 days ago)
(HTM) web link (yoric.github.io)
(TXT) w3m dump (yoric.github.io)
| wslh wrote:
| Interesting perspective! I think HN would benefit if we shared
| our own mind-blowing insights here. A couple from the top of my
| head:
|
| - Python: slicing, full reflection capabilities, and its use as
| an interface to almost anything [1], not to mention its role as
| an embedded interpreter (beyond the GIL debate).
|
| - Z3: one of the closest I know for defining the 'what' rather
| than the 'how.' I got lost with Prolog when I tried to add more
| complex logic with 'hows', though I was a complete newbie with
| Prolog. Z3, however, really boosted my beginner capabilities.
|
| - OMeta: allows me to write fast parsers without spending time
| resolving ambiguities, unlike ANTLR and other popular parsers
| using classical techniques.
|
| - Smalltalk/Squeak: everything can be re-crafted in real-time, a
| blend of an OS and a programming language. The community vibe is
| unique, and I even have friends who implemented an operating
| system using Squeak. The best example? TCP/IP implemented in
| Smalltalk/Squeak! [3]. David Weil and I also created an early
| proof of concept [4] that used Linux behind the scenes, aiming to
| 'compete' with the QNX floppy disk.
|
| - AutoLISP: a programming language embedded in AutoCAD, which I
| discovered in high school in the late '80s--only to just find out
| that its first stable release is considered to be around 1995
| [5].
|
| - REXX on the Commodore Amiga: not only could applications be
| extended with this language, but they could also interact with
| each other. A decade later, when I used REXX on an IBM Mainframe,
| I still preferred the Amiga's approach.
|
| - Racket: I can draw in the REPL. For example with Racket Turtle.
|
| - C++: object orientation "for C". I was not mesmerized by
| templates.
|
| - Clipper: first database usage and relatively simple to create
| business apps.
|
| - Objective-C: the first implementation of GCD [1], providing a
| C/C++ style language with fast performance, a clean event-loop
| solution, and reflective capabilities. However, I never liked the
| memory handling.
|
| - Machine Code/Assembler on the Apple IIe: I could jump directly
| into the assembler monitor from BASIC.
|
| - APL: a powerful yet complex way to program using concise
| expressions. Not ideal for casual use--best suited if you really
| understand the underlying concepts.
|
| By the way, it's time for Apple to embrace programming languages
| on iOS and iPadOS!
|
| [1] http://www.garret.ru/dybase.html
|
| [2] https://wiki.squeak.org/squeak/1762
|
| [3] http://swain.webframe.org/squeak/floppy/
|
| [4] http://toastytech.com/guis/qnxdemo.html
|
| [5] https://en.wikipedia.org/wiki/AutoLISP
|
| [6] https://en.wikipedia.org/wiki/Grand_Central_Dispatch
| 082349872349872 wrote:
| not necessarily mind blowing, but interesting, deeper cuts:
|
| Aardappel ABC Beatrice Charity Esterel FL Fractran GPM Hope
| Lean MCPL NESL Oz ProTem Rapira rpython SLC Squiggol UNITY
| USELESS
| WillAdams wrote:
| Parallel track:
|
| - MacBASIC: Mac GUI programming w/o Pascal or C
| https://www.folklore.org/MacBasic.html (which is something I'll
| never forgive Bill Gates for)
|
| - HyperCARD (also on that list, and agree with almost all points
| made): It was magic to get into Developer mode and to create
| stacks --- it's unfortunate that Asymetrix Toolbook didn't get
| further, nor that the Heizer stack for converting HyperCard
| stacks to Toolbook wasn't more widely available, and a shame that
| Runtime Revolution which became Livecode reneged on their
| opensource effort --- hopefully someone will make good on that:
| https://openxtalk.org/
|
| Unfortunately, I never got anywhere w/ Interfacebuilder.app or
| Objective-C....
|
| - Lua: real variables in TeX! (and latex), and one gets METAPOST
| as well --- even recursion becomes simple:
| https://tex.stackexchange.com/questions/723897/breaking-out-...
|
| - OpenSCAD: Make 3D things w/o having to use a full-fledged CAD
| program
|
| - BlockSCAD: Make 3D things w/o typing:
| https://www.blockscad3d.com/editor/ (though to be fair,
| https://github.com/derkork/openscad-graph-editor also allows
| that)
|
| - PythonSCAD: variables and file I/O for OpenSCAD (though to be
| fair, RapCAD had the latter, it was just hard to use it w/o
| traditional variables) https://pythonscad.org/
|
| Still working through a re-write of my OpenSCAD library in
| Python: https://github.com/WillAdams/gcodepreview and am hopeful
| that a tool like to https://nodezator.com/ will make that
| graphically accessible (w/o going into OpenSCAD mode to use
| OSGE).
| devjab wrote:
| Go really blew me away with its explicit error handling. As
| someone who has come from the OOP cult of clean code and other
| useless principles that haven't led our industry to have less
| messes over the past 20-30 years. Who was slowly moving into the
| "simplicity", "build things that can be easily deleted", "YAGNI"
| mindset it simply clicked.
|
| Then Rust took it a few levels beyond Go.
|
| It's a really good list, I suspect the languages you add is going
| to spend on your experience. So I wouldn't feel too sad if your
| favorite language is on that list. The author lists Java as a
| language with an amazing standard library, but something tells me
| a lot of people will have C#, Go or similar as their Java, and
| that's fine!
| scubbo wrote:
| I'm still convinced that Rust does it _right_ by allowing you
| to "chain through" errors using `Result`. Having to pepper `if
| err != nil { return ..., err}` repeatedly into your code is
| just distracting from the core logic - 99% of the time, that's
| the response anyway, so being able to just write your happy-
| case logic and have an implicit "but if there are any errors,
| return them immediately" (but still returned as a value rather
| than thrown as an orthogonal Exception) is the best of both
| worlds.
| ChadNauseam wrote:
| It is really great. I just wish there was a better story for
| combining error types. thiserror works, but it's annoying
| boilerplate to have to write imo.
| jasongill wrote:
| I have been using Golang recently and have the exact opposite
| feeling about it, which is likely due to my limited exposure to
| it. Needing to constantly check if a specific return value is
| not nil just seems so sloppy but I have yet to come across a
| "better" way as it appears to just be a Golang convention. Is
| there a good post about better ways to handle errors in Go?
| devjab wrote:
| This is the better way as far as I'm concerned. Go has a
| philosophy to be simple, and this is explicit error handling
| at its simplest. You deal with errors exactly where they
| occur. I think a lot of people simply prefer implicit error
| handling and long exception chains. There is nothing wrong
| with that but that's not how Go does error handling.
|
| After a couple of decades in the industry I really prefer
| explicit error handling because while powerful implicit error
| handling is also easy to get wrong. Which means I have to go
| through ridiculous chains of exceptions to find some error
| someone introduced years ago, instead of being able of
| heading directly to it and immediately understanding what is
| going on. So I guess it's a little contradictory that I
| prefer the Rust approach, but I think the compromise of added
| complexity is small enough to make up for the added safety
| and "manoeuvrability".
|
| The flip-side is of course that Go's simplicity is part of
| the reason it's seeing a lot of adoption while most other
| "new" languages aren't. (Depending on where you live).
| treflop wrote:
| I prefer implicit error handling if exceptions are checked
| and defined as part of the contract, otherwise it's
| definitely hard to trace.
|
| I know the biggest complaint with checked exceptions is
| that people tend to just use catch all exceptions, but
| that's just sloppy work. If they're a junior, that's when
| you teach them. Otherwise, people who do sloppy work are
| just sloppy everywhere anyway.
| freedomben wrote:
| Very much agree with Erlang/Elixir. After years battling and
| hating the JVM, I was initially very put off by the existence of
| a VM (BEAM) and by how it forced the concurrency model on me, and
| it did make getting into serious development with it harder, but
| once I "got" it, it really blew my mind. The "let it fail"
| philosophy was particularly mindblowing to me (especially once I
| understood that it _doesn 't_ mean "don't do error handling").
| sodapopcan wrote:
| Ya, "let it fail" is a semi-unfortunate tag line. A lot of
| people think it means literally to not handle _any_ errors ever
| and get really frustrated.
| spinningslate wrote:
| Indeed. OTOH, "focus your main code on the happy path, and
| put your error handling in the supervisor tree" is
| unfortunately a bit less pithy.
|
| Shades of "boring technology"[0] which might better be
| described as "choose technology that is a good fit for the
| problem, proven, reliable and proportionate. Spend your
| innovation tokens sparingly and wisely".
|
| [0]: https://boringtechnology.club/
| juped wrote:
| Joe Armstrong distinguishes in his thesis between exceptions
| and errors: exceptions are when the runtime system doesn't
| know what to do, and errors are when the programmer doesn't
| know what to do.
|
| Say your code divides by 0; the runtime system can't handle
| 1/0 but you the programmer may have anticipated this and know
| what to do. This is just someplace you write code right there
| to handle the case (catch an exception, pattern match the 0
| case beforehand, whatever).
|
| Your error, on the other hand, means something you expected
| to hold didn't; recovery inline from unknown unknowns is a
| fool's errand. Instead you give up and die, and the problem
| is now the exception you know how to handle "my child process
| died".
| card_zero wrote:
| Round about the seventh language, he stops using exclamation
| marks. The list goes from "Mind blown: Programming my own games!"
| to "Mind blown: Some support for writing my own gradual type
| system."
| PaulRobinson wrote:
| I think that actually happens to us all. The first time you
| write an infinite loop to print out that your friend is a
| doofus to show off is magical. 25 years in and you start to
| value... other things... that maybe don't have the childish
| whimsy and fun.
|
| That's OK. In the same way that when you start to read books,
| you might like Blyton, Dahl or diving into a Hardy Boys, by the
| time you've been reading fiction for a few decades your tastes
| might become a bit more philosophical.
|
| The trick is to introduce these things to people when they're
| ready for them, and to not treat those who haven't experienced
| them as in some way inferior.
|
| I'm not going to shove Proust down someone's neck or make them
| feel dumb for not having read any of his work, in the same way
| I am going to think carefully about whether somebody would
| benefit from seeing some Prolog.
|
| What does interest me a lot about this list is that it's not
| just a "well, look, I found Clojure and think it's better than
| Python, YMMV", or "if you don't like or understand Haskell
| maybe you are just too dumb to grok eigenvectors" brag piece.
|
| There is a thought about what you might get from that language
| that makes it worth exploring. As a result I might revisit
| OCaml after a brief and shallow flirtation some years ago, and
| go and take a look at Coq which I doubt I can use
| professionally but sounds fascinating to explore.
| liendolucas wrote:
| I think that are a couple of programming langs out there that
| everyone needs to be in contact with at least one time. I will
| mention the three ones that actually changed my mind (I have
| taken these in a semester at uni): Haskell, Prolog and Smalltalk
| (even if you do not like nor use them, they will force you to
| think radically different). Then you should add a structured
| language (C or Pascal will suffice). If you like metal, try
| assembly. Yes there are others like APL and Forth but I can't say
| anything about those as I haven't tried them. Lastly a LISP or
| scheme flavour won't be bad to experience as well.
| gmuslera wrote:
| Learned programming with Pascal, and Turbo Pascal (not the
| language itself) was what blew my mind back then. The Swag
| libraries weren't the language itself neither, but for pre-
| internet age they were a jump forward.
|
| Then had to do things in OS/2, and then it was the REXX turn.
| Shell scripting didn't had to be as basic as I knew from DOS.
| Some years later moved to bash, and from complex script to long
| but very powerful oneliners, so it was another shock.
|
| Still was working with OS/2 when learned Perl, and regexes, and
| its hashes, and all with some interesting semantic approach on
| that. And for many years it was my "complex" shell scripting
| language. Python was not as mindblowing or at least had the same
| kind of impact on me.
| unwind wrote:
| I didn't get the part about the stack in assembly, in my
| experience the stack is very much a thing at that level.
|
| Mainstream CPUs expose one or more explicit stack pointers, and
| in assembly you use that all the time, right?
| elteto wrote:
| I think he means that the stack is not something that you are
| forced to work with when programming in assembly. You can put
| data wherever you want (and are allowed to), and jmp into
| whatever random memory address you want. You can use CPU
| instructions that handle stack management for you, but you
| don't _have_ to.
| kaba0 wrote:
| I mean, that's just a register. The memory region itself is not
| special in any way, a random "heap" region that would be
| similarly frequently accessed would be just as fast.
| gus_massa wrote:
| You also can peek and write in the wrong side of BP and mess
| the "stack" of the caller funcion and perhaps get unexpected
| results or nasty crashes.
|
| Instead of " _an ilusion_ ", I'd say it's " _a convension_ ".
| PaulRobinson wrote:
| I'll second Prolog as mind blowing. It is a fundamentally
| different way to think about problem solving using a computer.
| Well worth even a trivial playing with it.
| D-Coder wrote:
| Most programming languages work top-down... literally, down
| through the lines of code.
|
| Prolog works bottom-up.
|
| Emacs LISP works inside-out.
| skruger wrote:
| APL is the perfect mind blower:
| https://xpqz.github.io/learnapl/intro.html
| 082349872349872 wrote:
| Unfortunately Dijkstra and Iverson took personal dislikes to
| each other's approach, or we might have had a language that
| abstracted data flow like Iverson's APL _and_ abstracted code
| flow like Dijkstra 's Guarded Commands.
| andrewstuart wrote:
| More no-code than programming language but Lotus Notes totally
| blew my mind.
|
| Imagine going from pre World Wide Web - and for many companies
| pre-email - age of local area networks (for file sharing only)
| and 38.K modems directly to group and user oriented, email
| integrated, distributed, replicated, graphics and multimedia
| integrated, no-code, document oriented, user programmable, fully
| GUI, secure, distributed database applications.
|
| Lotus Notes blew my mind completely. A truly amazing application
| at the time.
| tmtvl wrote:
| There were a few times I had my mind blown. Once with Scheme when
| I was watching the old SICP video lectures. But also (and this
| may be a rather unpopular thing to say) once with C when I had
| coded something up and compiled it and ran it and it finished
| instantly. Rust didn't really blow my mind, but I have taken some
| of its lessons (using error values, lifetime and ownership
| management) to heart.
|
| Common Lisp, which at the moment is the only language I can see
| myself using unless I decide to make one myself, never really
| blew my mind, although the little things it does make it hard for
| me to imagine switching away from it.
| omoikane wrote:
| Regular expression is not listed in the article, but it blew my
| mind when I first used it in Perl. Any of
| sed/awk/perl/python/ruby/javascript could have expose the author
| to regular expressions, but maybe they didn't find it as
| transformative as I did.
| agumonkey wrote:
| ' _' is one of the first special thing that computers made me
| look at. Even a simple msdos glob _.exe felt like a superpower.
| regexps were the next level but a two edged weapon as everybody
| knows. That said I never leveraged PCRE extended capabilities.
| jeffreygoesto wrote:
| No Perl? cgi.pm and http requests, plus regexes blew my mind
| after Basic, Z80 assembler and Turbo Pascal...
| pyrale wrote:
| Near the end of the article:
|
| > Just that the concepts either didn't resonate with me or,
| more often than not, that I had already discovered these same
| concepts with other languages, just by the luck of the order in
| which I learnt languages.
| James_K wrote:
| If Perl blows your mind, Perl6/Raku would send it to space.
| vunderba wrote:
| While I wouldn't say "mind blown", I really like F#'s built-in
| support for fluent interface style programming using the pipeline
| operator, e.g. X |> one |> two |> three
| versus the more conventional three(two(one(X)))
| leansensei wrote:
| Same in Elixir
| b6dybuyv wrote:
| and in Haskel/Elm
| MarkMarine wrote:
| And clojure -> or ->> (thread first or thread last)
| fantispug wrote:
| I find this style changes the way I think about and write code
| transformations. It's also in shell pipelines, R's magrittr,
| and Clojure's thread macros, and can be emulated in some OO
| languages with methods that return the transformed object
| itself.
| shawa_a_a wrote:
| I would second Prolog as mind-blowing. I've found you're
| typically confronted with fully engaging with the core of
| whatever problem you're solving, and only that core. This is
| probably what can make it so frustrating sometimes as you have no
| option but to work out the hard stuff nearly immediately; not to
| mention that unconsidered edge cases, mistakes can cause some
| pretty opaquely wrong results, or the query not terminating,
| which can make conventional debugging pretty difficult. The
| guarantees you get with using the 'pure' core of Prolog do open
| up some really interesting avenues though, for example Scryer's
| debugging library is quite neat in affording _semantic_
| debugging: https://www.scryer.pl/debug
|
| Just some additional commentary too - I think this post quite
| misrepresents it with some of the comparisons.
|
| Prolog at its core is SLD Resolution [1] (a form of search) over
| Horn Clauses [2] (first order logic). Queries posted to the
| runtime are attempts to find a set of values which will satisfy
| (cause to be true) the query - whilst SQL is founded on
| relational algebra which more closely aligned with set theory.
|
| Whilst there's probably some isomorphism between
| satisfying/refuting a logical predicate, and performing various
| set operations, I'd say it's a bit of a confusion of ideas to say
| that SQL is based on 'a subset of Prolog'. The author might be
| thinking about Datalog [3], which is indeed a syntactic subset of
| Prolog.
|
| [1]: https://en.wikipedia.org/wiki/SLD_resolution [2]:
| https://en.wikipedia.org/wiki/Horn_clause [3]:
| https://en.wikipedia.org/wiki/Datalog
| cies wrote:
| My parallel track:
|
| * C++: The feeling that I can make a-n-y-t-h-i-n-g. (not true but
| still mostly true) * Ruby: elegant, OO, who-needs-compile-time-
| if-you-have-unit-tests * Haskell: hard to learn but so worth it,
| by doing so I became a follow-the-types person * Elm: not hard at
| all, a well picked subset of Haskell for browser apps only *
| Kotlin: a well typed Ruby, with the ecosystem of the JVM at your
| disposal * Rust: when every bit of runtime performance counts
| (but now without sacrificing safety like with C/C++)
| AnimalMuppet wrote:
| My list:
|
| BASIC, but specifically on a TRS-80. I can just type something in
| and run it. I don't have to wait a week for the teacher to take
| the card deck over to wherever the mainframe is.
|
| Pascal. That's it, all of it, in those ~4 pages of railroad
| diagrams expressing the BNF.
|
| C. Like Pascal, but terser and with the training wheels removed.
| It just fits the way my mind works.
|
| Java. The language itself is kind of "meh", but it has a library
| for _everything_.
|
| Perl. Regular expressions and default variables.
| eminent101 wrote:
| I found Coq in the list to be very interesting. Is anyone using
| Coq here for serious math or programming? What kind of problems
| are you solving with Coq?
|
| And I'd also like to know how different Coq and Lean are. I'm not
| a mathematician. I'm just a software developer. Is there a good
| reason for me to pick one over the other?
| ChadNauseam wrote:
| Coq is cool partially because it can be compiled to OCaml. So
| you can write part of your program in Coq and prove its
| correctness, and then write the rest in pleasant OCaml. I
| believe there are some popular ocaml libraries, like bigint
| implementations, that do this.
|
| Lean is designed to be a general purpose programming language
| that is also useful for mathematical proofs. From that
| perspective it's kind of trying to be "better haskell".
| (Although most of the focus is definitely on the math side and
| in practice it probably isn't actually a better haskell yet for
| ecosystem reasons.)
|
| If you try either, you'll likely be playing with a programming
| paradigm very different than anything you've used before:
| tactic oriented programming. It's very cool and perfect for
| math, although I don't think I'd want to use it for everyday
| tasks.
|
| You won't go wrong with either, but my recommendation is to try
| lean by googling "the natural number game". It's a cool online
| game that teaches you lean and the basic of proofs.
|
| By the way, don't be scared of dependent types. They are very
| simple. Dependent types just mean that the type of the second
| element of a tuple can depend on the value of the first, and
| the return type of a function can depend on the value passed
| into it. Dependent types are commonly framed as "types that
| have values in them" or something, which is a misleading
| simplification.
| bazoom42 wrote:
| Call-with-current-continuation in Scheme blew my mind.
| openrisk wrote:
| (zx spectrum) BASIC: nothing like the first contact with AI
|
| C++: pointers, OOP and so much more - good and bad - all in one
| package
|
| Fortran90: vector programming for humans
|
| Python: general programming for humans
|
| Biggest disappointment: Scratch. Why isn't visual programming
| more mind blowing?
|
| Anyway, always looking out for these well-regarded "mind-blowing"
| languages but somehow they never show up in really mind-blowing
| projects? Would be interesting in this respect to have a list of
| mind blowing projects that were only possible due to a mind-
| blowing language.
| kjrfghslkdjfl wrote:
| Julia is a language that blew my mind. It convinced me that
| multiple dispatch is the way to do generic programming.
| Razengan wrote:
| Let me add something I found recently, though I haven't used it
| yet, but it looks impressive from the webpage: Uiua
|
| https://www.uiua.org
| mapcars wrote:
| Red/Rebol has a different, powerful approach to homoiconicity and
| DSLs.
|
| And there is this XL language that has very interesting approach
| to extending the language, but sadly the compiler is not in a
| runnable state, I could only assess it by the docs.
| prisenco wrote:
| Early on when I was learning, assembly language blew my mind. I
| went from Basic to Pascal but I wanted to make games so I tried
| my hand at C/ASM and it was just so wild to be that close to the
| metal after a couple years at such a high level.
|
| In recent years, Go blew my mind with it's simplicity and how
| strong of a case it makes for writing boring code.
|
| It's been decades since writing C/ASM and my guess is what little
| I remember isn't applicable anymore, but I plan on diving in
| again at some point if only to better understand Go.
| MarkMarine wrote:
| My mind blown experience was listening to a Rich Hickey talk
| (maybe not [1]) that flipped upside down my accepted method of
| thinking about types and type system paradigms. I still love
| writing Haskell and Rust, but I see the warts that he is so
| concisely pointing out. The either type really sticks out to me
| now, and I see the problems with overtyping what are essentially
| maps, and how rigid that makes every aspect of your programs.
| Currently I deal with a fairly large go monolith that had some
| clean code practices in it, and changing a single field that is
| going to make it into the public API ends up being hundreds or
| thousands of lines of changes. Such a waste of time to CRUD what
| is a map of strings.
|
| 1. https://youtu.be/YR5WdGrpoug?si=jRsXcYlwRuz0C1IN
| morning-coffee wrote:
| Nice article. Amazed they came across Prolog but not Forth!?
|
| Prepare to have your mind blown:
| https://ratfactor.com/forth/the_programming_language_that_wr...
___________________________________________________________________
(page generated 2024-11-03 23:00 UTC)