[HN Gopher] A brief interview with Tcl creator John Ousterhout
___________________________________________________________________
A brief interview with Tcl creator John Ousterhout
Author : lladnar
Score : 183 points
Date : 2023-02-09 23:15 UTC (1 days ago)
(HTM) web link (pldb.com)
(TXT) w3m dump (pldb.com)
| bitwize wrote:
| Ah, Tcl. A madman's idea of Lisp-style metaprogramming power. But
| nothing is faster for building GUIs than Tcl/Tk, especially for
| wrapping already existing Unix functionality. Not even something
| like Visual Basic. So it has earned a special place in my heart,
| even if it's not my first choice for generic application
| development.
| trentnix wrote:
| Ousterhout is the author of one of my favorite programming-
| related books, _A Philosophy of Software Design_. It is
| remarkably concise and practical.
|
| I re-read it whenever I sometimes fall into as it reminds me
| design and craftsmanship are the most important aspects of
| building great software.
|
| https://web.stanford.edu/~ouster/cgi-bin/book.php
| trentnix wrote:
| I managed to completely mangle that post via phone editing.
| Meant to say, I re-read it whenever I sometimes fall into a
| technical hole as it reminds me design and craftsmanship are
| the most important aspects of building great software.
| natmaka wrote:
| If you liked this interview do not miss J. Ousterhout's broader
| "Favorite Sayings" ( https://web.stanford.edu/~ouster/cgi-
| bin/sayings.php )
| keithalewis wrote:
| I wish more people would say "I don't know" when they don't
| know. It not only increases your credibility, it doesn't waste
| other people's time.
| Bluecobra wrote:
| As a network engineer, Tcl/Expect/bash scripts made it really
| easy for me to automate some of my tasks back in the day (e.g.
| backing up a router config). I since moved on to Python +
| Netmiko. I can still see learning Expect being useful for someone
| trying to dip their feet into simple automation.
| lizknope wrote:
| I remember my freshman year of college in 1994 when I took C++
| and asked the professor about how to write a GUI program. She
| told us about the Motif toolkit. I got a book from the library
| and typed in a hundred lines of boiler plate code just to make
| "Hello World" in Motif and C.
|
| It then took about 5 minutes to compile on a DECstation 5000 with
| 32MB RAM running Ultrix.
|
| Someone in the computer lab saw me with the Motif toolkit book
| and said "Why don't you use Tcl / Tk?" I said "What's that?" and
| they showed me. I had "Hello World" in 3 lines and could edit and
| start my new version in a couple of seconds instead of minutes to
| compile.
|
| After I graduated I got a job in the semiconductor industry which
| ran on Solaris and HP-UX and now Linux. All our digital tools
| from Cadence and Synopsys started using Tcl as the built in
| scripting language. I ended up teaching my older coworkers how to
| program in Tcl. I was still writing Tcl yesterday. There are a
| lot of things I hate about it but it has stuck around.
|
| The text before the interview mentions AFS which I did not think
| Ousterhout had anything to do with. I thought it was from
| Carnegie Mellon and then IBM Transarc. We used AFS at my school
| and I still miss it. Going to NFS in the industry seemed like a
| step backward.
|
| We only had an 8MB quota for our entire Unix account in college.
| It was great when working on a group project that I could make a
| dir in my account for that project and then add the 3 other
| classmates login id's to the group dir ACL list.
|
| These days at work depending on the size of the company we have
| to send an email to the sysadmin / devops team to say "Add user
| ABC to project group ID XYZ" and then wait hours or days. At my
| current job we can request Unix group access through a web site
| but I still think it is some human running commands to manually
| add users because it takes about 24 hours.
| Upvoter33 wrote:
| Yeah the AFS thing is a mistake. Ousterhout graduated from CMU
| (PhD) in 1980; the Andrew project (from which AFS sprung) began
| in 1982 or so.
|
| Ousterhout did work on Sprite (a distributed OS and file
| system) in the 1990s at Berkeley, and then, as another
| mentions, the log-structured FS (LFS).
| bch wrote:
| > The text before the interview mentions AFS which I did not
| think Ousterhout had anything to do with. I thought it was from
| Carnegie Mellon and then IBM Transarc.
|
| Ya - I wonder if the article writer actually meant LFS (log-
| structured file system)[0] which was part of the Sprite
| operating system project.
|
| [0] https://en.m.wikipedia.org/wiki/Log-structured_file_system
| tails4e wrote:
| I use tcl in EDA reguarly also. It's quirky, but useful. I'd
| not choose it for anything non EDA today, but it works well in
| that niche.
|
| The most horrific thing I discovered about tcl is that curly
| braces within comments can affect flow control. This is because
| comments are interpreted as a command that does nothing, not
| the same as complete ignored. Finding that out the hard way was
| not fun.
| ThenAsNow wrote:
| > The most horrific thing I discovered about tcl is that
| curly braces within comments can affect flow control.
|
| This is not true. Once Tcl sees a valid comment, the rest of
| the line up to the newline is treated as a comment. An odd
| number of trailing backslashes suppress the newline for
| interpretation purposes. Within the comment you can use
| braces or whatever without affecting control flow.
|
| See: https://wiki.tcl-lang.org/page/comment
| tails4e wrote:
| It is effectively an issue, see https://wiki.tcl-
| lang.org/page/Why+can+I+not+place+unmatched... If it's a
| comment in a proc with an unbalanced brace, it parses
| differently. That's not intuitive or sane IMHO.
| Bluecobra wrote:
| > We only had an 8MB quota for our entire Unix account in
| college.
|
| This brings backs some memories for me. In high school we only
| had a 10MB quota. I remember bringing in stacks of floppies to
| workaround the quota so I could download junk off their T1 and
| using file splitting programs. One of my friends even blew all
| his McJob money on an external Zip drive. By the time I started
| college USB thumb drives came into vogue and made everything so
| much easier.
| neilv wrote:
| Tk is what made people use Tcl, because it was a rare scripting
| language for GUI on Unix workstations.
|
| The Tcl language is actually really clever and interesting, but
| the textual evaluation model (a _much_ smarter approach than
| Bourne and C-shell) still made it poor for representing and
| manipulating graphs.
|
| I was lead for the extension language in a new CASE system,
| which had rich semantic graphs, including cycles. Tcl ended up
| being chosen by a cofounder, so I wrote up a doc on language
| limitations and how to work around them.
|
| (I'd also argued in the early/mid-'90s that the high-level
| extension language should also be the application
| implementation language. Such that we'd develop much of the
| application functionality ourselves in this high-level
| language, atop a C++ or C core API for foundation that needed
| that. Python eventually went this route, but hadn't yet. At the
| time, people in these sectors (which were very different from
| MIS developers) were thinking of extension language as things
| customers could use for simple reports or crude customizations
| or integration glue. Python and Tcl were new candidates for
| extension languages, and some big-ticket CAD/EDA/publishing
| tools had already been using their own more powerful Lisp
| variant implementations.)
| pjmlp wrote:
| We used Tcl back in the day, because of AOLServer, and the
| startup founders I joined went on to create their own version
| of the idea.
|
| We had Rails and Active Record done in Tcl back in 1998.
| incanus77 wrote:
| Brings back memories for me. Started college in '95, system had
| a 10MB quota on AFS and I also made use of the ACLs for
| projects with others. Systems ranged from Solaris to IRIX to
| AIX. My first GUI app was in Perl/Tk since I already knew Perl
| for scripts; it was a mail watcher utility that showed recent
| messages in a window.
| ehPReth wrote:
| Ah, TCL. Takes me back to the fun days of IRC and Eggdrop! :)
|
| https://www.eggheads.org
|
| edit: ooh, and https://tclarchive.org
| hackandthink wrote:
| They talk only about Tcl.
|
| A more lasting contribution:
|
| Why Threads Are a Bad Idea (1995) [pdf] (gatech.edu)
|
| https://news.ycombinator.com/item?id=17297325
| amelius wrote:
| Funny thing is that Ousterhout comes from the hardware design
| world, and in e g. VHDL, basically you have threads everywhere.
| zeckalpha wrote:
| You have concurrency and parallelism everywhere but not
| threads.
| amelius wrote:
| Hence "basically".
| nrclark wrote:
| I don't think threads are really a concept that's applicable
| to Verilog/VHDL.
|
| Stuff operates in parallel in those languages, because you're
| essentially describing little machines that all run
| independently of each other. You probably have some handoff
| from one machine to another. It's more like Factorio and less
| like multi-threading.
| anthk wrote:
| JimTCL it's fun too, specially for embedded devices. No TK, tho,
| but you have SDL2 support. And network/TLS support too.
|
| https://github.com/msteveb/jimtcl
| t43562 wrote:
| I don't want to like tcl at all but it's asbsurdly easy to embed
| in C and has very powerful constructs once you get used to them
| and no Global Interpreter Lock like python.
|
| So there was a discussion about why people still use C or similar
| recently and I think that C+tcl is a potent combination where you
| can mix C and TCL in a very natural way such that you never do in
| C what TCL does much more easily but you can still get excellent
| performance where it counts. It's all theoretically possible in
| python but just feels like much more work.
| monetus wrote:
| You might be interested in clicking through the puredata source
| code.
|
| https://github.com/pure-data/pure-data
| RcouF1uZ4gsC wrote:
| John Ousterhout (along with Diego Ongaro) is also the creator of
| the Raft consensus algorithm.
| fmajid wrote:
| He was also a pioneer of journaling file systems.
| Upvoter33 wrote:
| This is not true. Journaling file systems trace their roots
| at least as far back as Cedar ("Reimplementing the Cedar File
| System Using Logging and Group Commit") in the late 1980s.
| Ousterhout and Rosenblum worked on log-structured file
| systems in the early 1990s, which are markedly different from
| modern journaling file systems (JFSs uses a log to ensure
| crash consistency, but metadata/data end up in a fixed place;
| LFSs put everything into the log and keep it there).
| cosmojg wrote:
| He's right up there with Linus Torvalds and Fabrice Bellard.
| Upvoter33 wrote:
| The real contribution of Tcl/Tk, I think, is Tk, which still is
| better than most things I've seen for spinning up a GUI without a
| lot of work.
| IshKebab wrote:
| TCL is awful. I am unfortunately forced to use it because the
| entire EDA industry has settled on it as the scripting language
| of choice (silicon engineers tend to be pretty terrible
| programmers in my experience; despite silicon design and
| verification being programming they often excuse shitty practices
| by saying "we aren't software engineers").
|
| Performance isn't such a big deal - even though he says it isn't
| as fast as a really slow language like Python, the scripts tend
| to be very short.
|
| The issue is "everything is a string". Anyone who has written any
| significant Bash or CMake will be familiar with how shitty that
| is. TCL is actually a bit nicer than CMake or Bash, but it still
| suffers from the fundamental problems of stringly based
| languages.
|
| Quoting is insane and hard to get right. Type errors are very
| common. I would say TCL has had a negative effect overall at
| least on the EDA industry. Maybe if it didn't exist we could have
| had a slightly nicer embedded language like Lua. Or even just a C
| API.
| nrclark wrote:
| I actually really like TCL as a language. It's very internally
| consistent, and quite powerful. Has a bit of a LISP flavor.
|
| I agree that its syntax is pretty weird when compared to any
| other language. And a lot of stuff works differently than you'd
| expect if you're coming from Python.
|
| For me, there's always a mental context switch that needs to
| happen before I can get in the flow with TCL. Once I'm there
| though, it's a very fast/powerful language to implement stuff
| with.
| andrewshadura wrote:
| > Quoting is insane and hard to get right.
|
| On the contrary, compared to e.g. bash, unless you're doing
| something super unusual or wrong, you rarely have to think
| about quoting in Tcl. Use "" when you want substitution, {}
| when you don't, {*} when you need to pass a list as multiple
| words, construct lists and dicts using their appropriate
| constructors and never by hand -- and you're safe. Unlike bash,
| quoting in Tcl is dead simple, predictable and never
| surprising.
| IshKebab wrote:
| Yes it's not as bad as some other stringly typed languages,
| but compare it to literally any other language with proper
| types. Even terrible ones like PHP don't have those issues.
| oddthink wrote:
| I do prefer tcl quoting to bash quoting, but you do have some
| mental overhead when writing procedures, since unpaired
| braces inside quotes may do surprising things, if you're
| thinking "writing a command" rather than "raw strings".
| Comments are similar.
|
| That being said, those are very much edge cases.
|
| More damning, from my POV, is that you can't get ref counting
| of things like C objects or file handles, since they're just
| string handles. But there are a lot of uses that don't need
| that
| flohofwoe wrote:
| Before Lua got popular, Tcl was the only sane option to add
| scripting to a project. The interpreter was trivial to embed
| and modify (for instance I created my own stripped down
| "minitcl" library which compiled to around 20 to 30 KBytes).
| robinsonb5 wrote:
| Funnily enough I'd never used Tcl until I started tinkering
| with FPGAs, and while initially I hated it, I went through a
| process of developing a grudging respect for it, and now
| actually quite like it!
|
| What I will say is it's absurdly easy to write a Tcl extension
| - I wanted to talk to a soft CPU using a Xilinx Platform Cable
| USB (which isn't supported by OpenOCD). I ended up creating a
| simple Tcl extension around xc3sprog and it worked a treat -
| I'm pretty sure the engineering effort to do the same for a
| different scripting language would have been much greater.
| zeveb wrote:
| > Quoting is insane and hard to get right.
|
| This really makes me wonder if you've used Tcl. Quoting in Tcl
| is _so_ much simpler than in e.g. bash or cmake. It's all about
| know when a string will be evaluated or not.
|
| > Type errors are very common.
|
| In my experience, no more so than in any other dynamic
| language, e.g. Python or Lua.
|
| Again in my experience, if one wants a _scripting_ language --
| i.e., one used to orchestrate a number of commands -- then Tcl
| is exactly what the doctor ordered.
| IshKebab wrote:
| > Tcl is so much simpler than in e.g. bash or cmake
|
| "Writing with a screwdriver is so much simpler than e.g. a
| potato or a sock."
| LewisJEllis wrote:
| I recently read his book, "A Philosophy of Software Design", and
| loved it.
|
| It's 175 pages of well-refined, to-the-point, applicable wisdom;
| highly recommended.
| vendiddy wrote:
| This is one of my favorite books on software development. It
| focuses on timeless principles, but uses concrete examples to
| ground everything he teaches.
| doodlebugging wrote:
| Thanks for this article. A few years ago I had a task involving
| reading some data files to understand whether they were corrupted
| or still usable. The software to read the files usually came as
| part of a proprietary package with a price tag high enough that
| it made no sense to license for this one small task.
|
| I asked myself: "how hard can it be?"
|
| I decided to search online for easy and free ways to read the
| files. It had been several years since I last programmed anything
| though I had done a bit of script modifications on some
| perl/awk/sed scripts. I found Tcl/Tk after a bit of digging and
| decided to give it a whirl.
|
| In all I spent about 16 hours dinking around with Tcl and had a
| nice, short program written to read everything, display the data
| for a QC check, and write it to disk. The documentation was
| detailed and concise. Of all the programming languages that I
| have used over the years the fact that I could sit down and find
| the right set of simple commands and assemble all of it into a
| working program in a couple of days with no learning curve pain
| or friction was amazing.
|
| Thanks John Ousterhout.
| tpoindex wrote:
| JO might be interested to see that Tcl is now implemented in Go.
| Not a clone, but the actual Tcl code:
| https://gitlab.com/cznic/tcl
|
| Tk too! https://gitlab.com/cznic/tk
|
| Made possible by a clever C to Go compiler:
| https://gitlab.com/cznic/ccgo
| doctor_eval wrote:
| I was really into Tcl in the mid 90s. Loved it! And Tk was
| awesome! And then there was Expect...
|
| But despite now being a Go programmer, and as much as I'd like
| to try it, I can barely remember a single thing about any of
| it.
|
| But I do wish there was a bit more info in the README.
| hulitu wrote:
| It is not implemented, it is translated. I wonder how many bugs
| have been introduced by this translation.
| RHSeeger wrote:
| I am trying to figure out what you mean by this. I was under
| the impression the official Tcl source was in C. Can you
| provide more of an explanation?
| robotresearcher wrote:
| The C source has been translated ('transpiled') to Go source.
| That's not what is usually meant by 'implemented in', but I
| guess it's not wrong, since there now exists an
| implementation in Golang.
| RHSeeger wrote:
| Ah, ok, that makes more sense then. The "implemented in.
| Not a clone" made it sound like the actual, core language
| implementation had been switched over to Go... and clearly
| that didn't sound right.
| tpoindex wrote:
| Right, the reference Tcl implementation is still in C.
| This project takes the C code and produces Go, along with
| a supporting libc emulation in Go. It's still the
| original C code, not a clone as Jim or Picol.
| RHSeeger wrote:
| Thanks for the clarification. I don't use Tcl for normal
| work anymore (though I still use it for small things),
| but it still has a very special place in my heart. It's
| one of my favorite languages to program in.
| pjmlp wrote:
| That isn't the official one, just yet another implementation.
|
| https://www.tcl.tk/software/tcltk/8.6.html
| spacedcowboy wrote:
| John Ousterhout ... Tcl may be the thing that most associate with
| his name, but to me he's Mr Magic[1]. Magic is the research
| program that (helped) begat efabless[2] and gives me the hope of
| making my own chip some day, just after this next major project
| is over and done with.
|
| 1: https://en.wikipedia.org/wiki/Magic_(software)
|
| 2: https://efabless.com/kb-articles/layout
| tilt_error wrote:
| I've spent around 10 years building software with and around
| Tcl, embedding Tcl as command processors in a distributed
| system --- lots of fun.
|
| Some decades later I see that Ousterhout, among others of
| course, is still contributing to the community, e.g. the Raft
| consensus algorithm, while the steam may have left Tcl.
| martyvis wrote:
| I was into Tcl (and Tk) in the mid 90's. There was a great
| database that I think had Tcl bindings called Qddb (quick and
| dirty database). I used these to hack together a few Web cgi-bin
| applications. One was a super fast library catalogue (something
| like 10 times quicker than the proprietary one I imported the
| catalogue data from). The other one I like to think as my "almost
| invented Facebook" moment. It was a template driven web
| application that allowed you to publish your profile page (and of
| course edit it in the browser) and also project pages. It got
| some use within the multinational resource company I was in as a
| way of improving collaboration in those early web days.
| AlbertCory wrote:
| I embedded Tcl in the agent for Oracle Enterprise Manager in the
| mid-90s, and got to meet John & his team as a result. Read about
| it here:
|
| https://albertcory50.substack.com/p/in-larrys-kingdom-part-2
|
| A friend of mine worked for him at Sun, and said his coding
| standards were incredibly rigorous, but never silly.
| tpoindex wrote:
| Heh, I have a funny story about that too, having written the
| open source Oratcl extension that was used as a basis for OEM.
| AlbertCory wrote:
| I'm not sure what you mean by "the open source Oratcl
| extension that was used as a basis for OEM."
| tpoindex wrote:
| Sorry, I didn't mean to imply all of OEM was based on
| Oratcl, just the Tcl extension used to access the database.
| I was listed in one of the OEM manuals in the copyright
| statement, along with the RBOC where I worked when I
| created Oratcl. I don't recall the names of the people at
| Oracle who contacted me to tell me they were using Oratcl,
| perhaps 'Mario' or 'Eric' ??
|
| The funny part was when I got an email from someone at
| Oracle, perhaps in legal, who wanted me to sign an
| "indemnify and hold harmless" statement for my code, code
| that I shared freely, received no compensation for, and had
| no control on how it was used by Oracle in their product --
| Rrriiight. I replied "no thanks", and if Oracle wanted to
| use my software, they simply should comply with the BSD
| license that it shipped with, including the attribution
| clause.
| AlbertCory wrote:
| "OEM" == "Oracle Enterprise Manager" -- duh. I was
| thinking the other meaning of OEM.
|
| memory fades. I don't remember how I did that anymore.
| Maybe we folded Oratcl into the OEM agent???
|
| As you'll read in that article, the agent didn't work all
| that well, at first, and it was a particularly hellish
| time to be a manager.
| bch wrote:
| Go on...
| monetus wrote:
| This is a quick but good read. I think he is maybe too humble
| sometimes. Some may not know Richard hipp of SQLite fame develops
| other tcl projects -
|
| https://youtu.be/nmgOlizq-Ms
|
| https://wapp.tcl-lang.org/home/doc/trunk/README.md
| bch wrote:
| Richard often calls sqlite itself "a Tcl extension that escaped
| into the wild."
|
| It's no accident that a lot of sqlite tests are written in Tcl,
| or that a "weird language like Tcl" has first class sqlite
| support. In fact, for a while Richard also sat on the Tcl Core
| Team (TCT), shepherding its development.
| melling wrote:
| Ousterhout developed RSI in the mid 1990's and started
| programming with Dragon Dictate.
|
| https://web.stanford.edu/~ouster/cgi-bin/wrist.php
|
| About 15 years later, Tavis Rudd developed his system to program
| by voice.
|
| https://youtu.be/8SkdfdXWYaI
|
| Now here we are a decade, or 3 decades, later. Damn, the future
| sure is taking its time.
| hummus_bae wrote:
| Haven't heard of Ousterhout before this, but his contributions to
| Tcl and to the tech world in general are really admirable.
|
| Also
|
| https://www.johou.se/
| amelius wrote:
| Link is broken
| JohnFen wrote:
| TCL remains my favorite scripting language of all time, and I did
| a port of it that was the very first software I had a hand in
| that was adopted by a major corporation (albeit with no
| compensation).
|
| Thank you, Mr. Ousterhout!
| gopalv wrote:
| The whole "is Rust relevant" feels like that needs the Ousterhout
| "A little bit of slope makes up for a lot of y-intercept"
| graph[1] stapled to the same.
|
| I'm not sure what the y-intercept of Rust is, but its slope seems
| to be pointed towards more code being written in it than ever
| before. For example, the wasm compilation is probably the
| clincher for my toy projects because I like to build stuff to run
| on a website, but I don't always like writing in JS.
|
| [1] - https://gist.github.com/gtallen1187/e83ed02eac6cc8d7e185
| bbarnett wrote:
| _Rust is, but its slope seems to be pointed towards more code_
|
| People playing with new stuff in a regular basis? HN Readers:
| all, RestOfWorld: None.
|
| People who have heard of rust? Similar to above.
|
| Rest of world=99.99% of devs.
|
| Yes I am exaggerating, but this place is a bubble. Rust does
| seem to be growing in popularity, but so far, doing so in a
| really tight community.
| bsder wrote:
| Yes and no.
|
| Rust is being used where it makes sense--generally security.
| So, gamedev won't use it for main loops but will use it for
| networking code. The crypto Ponzi brigade chose Rust for a
| reason. Some of us who write communication stacks (TCP/IP,
| CANBUS, etc.) try to use Rust whenever possible.
|
| However, you are correct in that Rust popularity is growing,
| but it's going to be slow. If you look at the TIOBE index,
| there is a limit as to what Rust can really displace. A _lot_
| of the top languages are now GC-based, you 're not going to
| reach for Rust if you can use those. So, Rust can
| realistically only displace C, C++, and ... nothing else.
| That means almost 75% of programming language use cases
| aren't even in scope. And C programmers really aren't going
| to gravitate to Rust as it's more of a C++ replacement.
|
| So, you need a specific usecase (security) or a greenfield
| project that would use C++. That's going to be a slow climb.
| pjmlp wrote:
| You just have to look to domains where C++ rules to see that
| while the community is aware of Rust, hardly anything is
| happening in HPC, HFT, GPGPU, Khronos APIs, LLVM/GCC, MPI,
| OpenMP, AUTOSAR[0], Unreal/Unity/Godot, PlayStation, XBox,
| Switch, Apple and Windows official APIs,....
|
| So while Rust is being adopted, it is at the same scale that
| C++ was against C around the early 1990's, in regards to market
| size adoption.
|
| [0] - They are looking into it, still no standard update that
| allows for Rust
| whyever wrote:
| There is an official Rust Windows API:
| https://github.com/microsoft/windows-rs
| pjmlp wrote:
| An official work in progress Windows binding, still far
| behind of what C# existing bindings are capable of, or
| legacy toolkits like MFC.
|
| Also given how the team has managed C++/CX transition to
| C++/WinRT with lesser tooling stuck on C++17, dropped
| Modern C++ bindings [0][1], before going into other shinny
| thing, I wonder how long they will keep at it.
|
| [0] - https://blogs.windows.com/windowsdeveloper/2021/01/21
| /making...
|
| [1] - https://github.com/microsoft/cppwin32
| flohofwoe wrote:
| It doesn't matter if the project is driven by Microsoft
| or not, the cat (of automatically generated language
| bindings) is out of the bag. E.g. Zig is using the same
| approach without being an official MS project:
| https://github.com/marlersoft/zigwin32, and Apple has an
| automatically generated C++ API for Metal
| (https://developer.apple.com/metal/cpp/).
|
| In the future, the question won't be "what language do I
| need to learn to code on this platform", but instead
| "where are the language bindings for my favourite
| language".
| pjmlp wrote:
| Depends if one is on yak shaving or delivering code into
| production.
|
| Being a Borland and ETHZ fanboy has taught me some hard
| lessons in development effort, when languages don't have
| tier 1 support from platform owners.
|
| So until Rust is on Visual Studio and Windows SDK out of
| the box, I rather keep using .NET languages alongside C++
| for Windows development.
| whizzter wrote:
| I think it's just a balancing of where work is needed.
|
| C++/Cx (and it's predecessors) was bad in requiring
| special compiler support whilst WinRT had already seen
| real adoption and cppwin32 didn't really give any
| benefits apart from another backend so they seem to have
| concluded that C++ devs would easier be supported by
| something more mature (that needed support anyhow) and
| then just focus the win32metadata project (That's still
| alive) on "new" languages.
| pjmlp wrote:
| Adoption by WinDev, nobody else cares after they screwed
| their customers.
|
| They should all have been fired if it was up to me, we
| don't pay VS licenses for killing our workflows like
| that.
|
| WinRT is Windows only technology, who cares about
| extensions.
|
| Plenty of people don't have any issues with GCC and clang
| extensions, or macOS specific ones like Objective-C++, or
| TI, or ARM SDK, or whatever fancies their party, only MS
| ones are bad.
| rowanG077 wrote:
| Most of the list you mentioned will never move. They have
| millions of lives if hyper specialized code. What matters are
| greenfield projects.
| pjmlp wrote:
| Greenfield projects where the ecosystem has to be built
| from scratch versus existing mature tooling for the same
| purpose...
|
| Some ecosystems where there is still to exist a Rust story
| in accepted toolchains.
|
| Sure it is possible, provided one is willing to spend the
| money to make it happen.
| toolslive wrote:
| Very nice article. While reading it, I was thinking of a Bertrand
| Russell quote: "...the stupid are cocksure while the intelligent
| are full of doubt."
| therealcamino wrote:
| Interesting, I've never heard that quote but I've always liked
| a similar line in Yeats' The Second Coming:
|
| The best lack all conviction, while the worst Are full of
| passionate intensity.
| readingnews wrote:
| I always forget his name, but never forget Magic. There were so
| many cool features of Magic. I wrote scripts so that if you made
| a block cell, like for a multiplier, you could then script it out
| to any size you wanted by replicating cells, but renaming wires
| and pads for export to Spice tools. So nice.
| JoshTriplett wrote:
| One of my favorite quotes in Computer Science comes from
| Ousterhout:
|
| "The biggest improvement in performance is the non-working-to-
| working."
___________________________________________________________________
(page generated 2023-02-11 23:02 UTC)