Go Ahead, Mess With Texas Instruments - <AUTHOR> http://www.theatlantic.com/technology/archive/2013/08/go-ahead-mess-with-texas-instruments/278899/ <comment><USER3> I'm accustomed to popular blog blowhards repeating the "you can't write code on an iPad" mantra, but I expect better here. We all know you can write code on an iPad, right? Off the top of my head, I can think of free/cheap apps in the app store for JavaScript, Python, Scheme, Perl.

Or Lua... my kids have my hand-me-down iPads. Each has Codea installed. Codea is a gorgeous Lua development environment with a great on-device editor and great libraries for sprites, sound, touch, accelerometer, and physics.

For some things, the Codea editor is better than what I use at work. For instance, if a function takes a color value as an argument, when the cursor is in that character position, a color picker pops up. Likewise, when using the sprite command, instead of typing in a name you can open a popover that displays a list of sprites on the device. It pulls assets from your photo library or links to your dropbox, so you can easily get assets in and out of the device.

My daughter decided to make a program to implement the sorting hat from Harry Potter. She googled for images of the sorting hat and other harry potter things, saved them to the device, and spent an hour obsessively re-writing her draw function so that things appeared where she wanted them to. She was stumped by randomness, so I helped her look in the built-in reference for math.random() and, with another assist on how to write an if-else block, she figured out how to use it. Keyboard input was rougher (Codea lacks the common UI widgets) but she got something working to her satisfaction.

So, after a few hours of playing around, she had a fun little sorting hat toy. She understands variables, incrementing variables every frame to create animation, what the word "random" really means (as opposed to her previous definition for the word, from some Disney channel show), and how to do some basic if-else flow control. Now when people ask her about her iPad, she says she knows Lua and shows them her sorting hat.

Codea can export directly to an Xcode project, so next weekend we're going to turn her sorting hat game into an app and install it on her iPad. I think that's when she'll be fully converted into a mobile app developing geek.

So, the article... there's a fun walk down memory lane (I, too, goofed off in school writing games for a programmable calculator) but it's unfortunate that he framed it with a TI-verus-iPad. Plus, his conclusion is just plain wrong.

<comment><USER4> That's where the story ends though. I never owned a TI-83 but I remember class-mates linking their TI and sharing programs. Here you have to export to Xcode, pay Apple $99 and fill a bunch of forms, wait for app-store approval.

<comment><USER3> Really? She can email her friends the project file or the code. Seems better than linking through some rare cable. And if she really rocks it and makes something people will pay for, she has a venue for it.

<comment><USER5> Sharing programs on an 83 was simplicity itself, and always worked, and cables were usually pretty easy to find.

<comment><USER6> I remember going to summer camp and getting my classmate's shooter game program ;)

<comment><USER5> The day I got the MirageOS app for my calculator was magical.

</comment></comment></comment></comment></comment></comment><comment><USER7> I too wrote my first code on a TI-81. Though I had been making games for a while with various tools (e.g. TGF), it was nice to finally close the loop and write in a programming language, even if it was only BASIC. That pushed me to take a programming course in high school the following year. I was writing pong and asteroid clones and ray casting engines in class.

The author's points about the iPad seem pretty accurate. I can't even imagine how I would go from having an iPad as a high school student to stumbling into programming.

I haven't developed in iOS, but I did play around with Android and the thing that really frustrated me was that the sample games were several files and ~1,000 LOC. We're talking _really_ simple games and the amount of boilerplate crap was mind boggling. To even get to that point, of course, you have to screw around with an IDE, plugins, an emulator, etc.

It's a far cry from _PRINT "HELLO WORLD"_

<comment><USER8> > The author's points about the iPad seem pretty accurate. I can't even > imagine how I would go from having an iPad as a high school student to > stumbling into programming.

Funny, I thought the exact opposite; I agreed on the general point, but found the arguments against iPad bit weak. First of all they were factually incorrect. As others have demonstrated there are plenty of apps that allow programming the iPad in a way that is at least comparable to TIBASIC. You don't need developer accounts or review processes to use those apps.

More importantly the author missed the part that iPad is essentially just a platform, a tabula rasa if I may say so. As it does not provide _any_ educational features on its own (afaik) some apps need to be provided by the school. And those apps provide the discoverability aspect that is missing from a vanilla iPad. It is reasonable to think that school would provide/require an app (or a collection of apps) that would be an equal or surpass the features of a graphing calc, including the programming features.

Of course I'm not really sure what educational apps are currently available, if they are adequate. But if not, then _that_ would actually be something that HNers could do something about.

<comment><USER9> The difference with TI's calculator was there was a social motivation/aspect to programming them. Everyone had them and it was very easy to get started.There are programming environments for the iPad but it is a lot harder to share programs as not everyone has one and even if they do they need another level of indirection to get the program. The calculator is also much more prevalent/easy to use in the classroom.

My first program was a quadratic equation solver that everyone at my school used. I remember a couple people tried to imitate and improve on my program but I crushed them with new features and a better interface. I don't think I could do that with the iPad.

The technology is also a lot more complex and daunting with the iPad. You have the paradox of choice in choosing how you want to program it. You can't easily share programs with others and TIBasic, just due to its simplicity and the lack of design knowledge and effort for the user interface is a lot easier for a kid to pick up and start using.

One thing that isn't mentioned in the article is that if you wanted direct control over the screen you had to program in assembly; I don't even think they had programming language support for it at the time. It made it a lot harder to use than the regular TiBasic.

<comment><USER10> You also needed a special cable to upload software written in assembly onto the calculator. I started teaching myself Z80 assembly in order to program the TI-85, but I never got the cable, so I never got to try it.

</comment></comment></comment></comment><comment><USER11> Anyone ever play "Dope Hunter"? Actually I forgot what it was called exactly, but it was like a Legend of the Red Dragon type game, except you were a drug dealer, and it worked on TI-81s.

I agree with the OP that iPads currently restrict most users to being consumers, rather than programmers...but I'll admit, I didn't know many people who finagled around with creating or modifying TI programs...we mostly just distributed programs, downloaded from the Internet (or BBSes) among ourselves. However, the interface of a calculator was (understandably) pretty painful, so I think some of the more industrious of us did hack our own routines for common calculations. Even that kind of rudimentary programming/problem-solving isn't possible from the iPad or its more popular educational apps.

<comment><USER12> [http://en.wikipedia.org/wiki/Drugwars](http://en.wikipedia.org/wiki/Drugwars)

I always knew it as Dope Wars, but I believe this is the game you were referencing.

<comment><USER13> I loved this game in high school. We played the Windows version in my networking class. I remember shouts of "Ahh yea, cocaine is super cheap in _____!" going across the room as we tried to outmatch each other's cash pool.

</comment></comment></comment><comment><USER14> I still have my TI-92+, it was the pinnacle of graphing calculators, basically running Mathematica on the equivalent of a Sun-1 workstation in your hand. And of course TI-Basic.

While the article suffers a bit from nostalgia, the central message that young people develop learning skills from 'constructable' activities (be it programming a calculator or building things in shop class) is something we have put at risk. In many ways "art" is the most important class you can take in High School since it can challenge your thinking in ways that no amount of rote memorization can.

The bottom line for me was that its great that some folks can see the benefit, but not a whole lot of ideas about keeping that spirit alive in the school system.

</comment><comment><USER15> In high school my friends and I decided that once we understood the concept of, say, the Pythagorean Theorem, making us solve it over and over again was busywork. So we made programs to solve things, and then an application called AMATH to collect all those programs.

At one point the teachers caught wind of this app everyone was using, and made everyone start showing their work. So I reprogrammed my modules to show their work, line by line. I soon forgot about all of this and went into an unrelated area of study at university; I think I only ever took one college-level comp sci class. Today I make my living in mobile apps.

</comment><comment><USER16> Let me tell you why I hate TI's shitty calculators.

Mainly because they are marketed so aggressively to educators.

Back in 1990, I was given a TI scientific calculator, and some exercises to practice. I was to enter the UIL contest titled "Calculator Math" or something like that. It was a speed contest. My school (small rural public school), having the smartest and best-prepared students won at the first level of competition beating everyone. We punched our buttons furiously, we were punching buttons as fast as is possible without having registration errors. We figured nobody could beat us, since we made few errors. At the next level we competed, something went wrong. The test went as usual, we finished most of the exam in the allotted time, but did not score well enough to advance. The thing is, after about two-thirds of the allotted time had passed, students from other schools started getting up and leaving. During the exam, I smugly assumed they were giving up because I _knew_ that nobody was a significantly faster button-pusher than me, not by that large an amount. I was puzzled. Later I learned what an RPN calculator was, and began to understand what happened. I am a college instructor today, and I have yet to meet a student who knows what an RPN calculator is. Nearly every teacher's supply catalog that gets crammed into my mail sells TI exclusively.

<comment><USER17> Partway through college I bought an old HP-48 and suddenly had this realization. The TI system encourages you to enter exactly what you see on the page, plus a whole bunch of parentheses because calculators are dumb and everyone's paranoid about order of operations. With RPN, you just do the math.

<comment><USER8> > plus a whole bunch of parentheses because calculators are dumb and > everyone's paranoid about order of operations

Oh yeah.. and no paren matching either and iirc multiline editing was inconvenient enough that i never used it.

</comment></comment></comment><comment><USER18> Graphing calculators are entirely unnecessary for learning high school/college mathematics/physics/etc. (though they might be useful for engineering students working on-site where access to a full computer is impractical – I don't have such experience with that, so can't comment).

There is no good pedagogical reason for assigning problems to students which use numbers that can't be worked out easily on paper or with a regular scientific calculator. Forcing students to expend effort on keeping track of many-digit numbers is in general an unnecessary mental load which distracts from the concepts being taught. Including "how to use your calculator" sections as part of mathematics instruction, and assigning "calculator problems" which include e.g. unreasonably complex symbolic integration problems or unreasonably precise numbers, for the sake of giving students practice with a graphing calculator interface is a waste of teacher and student effort.

Additionally, Because Texas Instruments has so effectively lobbied textbook authors and test writers and school administrations to get their calculators on the list of approved/official devices, many students are prompted to spend an unreasonable amount of money on calculators which they do not need. It's something like a tax on those students.

TI graphing calculators have awful, obtuse interfaces. Their programming and debugging tools are rudimentary and outdated. Their graphics capabilities are limited, and graphics made with them can't be used for any other purpose or easily shared. Students would be much better served by lessons/mentoring on the use of regular general-purpose computers and programming languages, whether for mathematics or whatever else. If they need symbolic integration or graphing capabilities for solving some concrete engineering problem, or for exploring, they would be much better served by a tool such as Mathematica or Maple [or heck, Python] than by a TI calculator. Full computers are much better for inputting and interacting with data and mathematical structures.

It's been 9 years since I was in high school. But on principle, I never bought a graphing calculator, and I never found it to be any disadvantage in any course I encountered in high school or college [except, briefly, on the AP Calculus test, where I had to familiarize myself with the TI83's awful UI on a borrowed calculator during the test; it didn't end up hurting my score]. However, I found programming in Maple, and later Python, to be invaluable in solving all sorts of problems.

<comment><USER19> Comments like this are why hacker news is so frustrating now. It's a rant about TI calculators which doesn't address any of the points made in the article itself, yet is sitting at the top of the comments.

If you want to talk about TI calculators in general, write a blog post and post it here or something, but I don't see why this mostly-unrelated comment needs to dominate any discussion about the actual points being discussed in the article.

<comment><USER18> Sorry. Let me try to make it relevant:

(1) I think it's great to give kids general-purpose tools for unstructured hacking. There's enormous pedagogical value for every person in learning to think procedurally, break things down into parts, debug algorithms, and explore mathematical systems. Every teacher should read _Mindstorms_.

(2) General purpose computers are nowadays really great for this, if the proper programming environments get set up on them. They have awesome screens for displaying neat graphics. They have reasonable keyboards for quickly typing in code and numbers and symbols. They have amazing CPUs and GPUs which can crunch numbers like nobody's business.

(3) I think we should start kids programming at age 5-8 with a tool like Scratch or Logo or I dunno what, but something designed and tested on children, with good sets of materials and curricula set up to teach them to do exploratory programming.

(4) I think at some point students should be given tools which give them low- level access to hardware, like I dunno an Arduino or something. These things are getting to be $20-30 now, and it's possible to use them for all sorts of nifty stuff and learn how to operate on constrained systems and twiddle bits in memory and whatever supposed advantage a TI calculator would offer, if that's the goal.

(5) Many people don't use tablet computers (or other computers) in math courses in school in a very pedagogically sound way, and a lot of software used in schools is terrible. (Giving access to open-ended exploratory systems is much better than giving access to one-purpose constrained tools.) This is too bad, because big color multitouch displays are really nice input/output devices for many purposes.

(6) It's all well and good that the original author and many other people had a nice experience programming a TI calculator as a way to stave off boredom in math class, or whatever. But TI graphing calculators were overpriced and outdated and frankly pretty crappy relative to other devices people used 10 years ago, as long as we get the right software on those devices. By now it's just ridiculous. Making people type BASIC into a calculator using tiny buttons and a little monochrome screen is not the right way to introduce mathematics, or programming, or anything else.

<comment><USER5> The 83 calculator was rugged, had great battery life, was programmable even in the simplest of ways, and basically kicked ass at its niche--remaining useful even through senior year of mechanical engineering at my college.

I'm sorry it's not sexy and shiny, but the thing represents an excellent optimization for price, durability, speed, and utility. The fact is that the 83 is basically the AK47 of the calculator world--ugly, old, outdated, and _utterly fantastic at what it sets out to do_.

You seem to overlook the fact that while we've got these great general-purpose tools for doing computation, the 83 is first and foremost a graphing calculator. It handles basic statistics quite well, handles graphing and intercepts okay, and _as a bonus_ has a very simple and robust programming interface.

Raspberry Pis and Arduinos and OLPCs are cool and all, but in terms of just giving kids the basic tools they need to solve adult problems _soonest_ , they fail.

EDIT:

I'm not saying I think they still need to be $100 a pop--a design refresh to get them down to more modest prices wouldn't hurt, but still.

</comment></comment></comment></comment><comment><USER20> > It wasn't until 1990, when Texas Instruments released the TI-81 graphing > calculator, that the medium became a feasible platform for game design

Nonsense. People were writing calculator games long before graphing calculators were introduced. There were lunar lander games for HP and TI calculators in the late '70s and early '80s, for example. HP had a "Game Pac" for the HP-67 that included blackjack, craps, a slot machine game, a sub hunt game, an artillery firing game, a space war game, a game based on "Mastermind", Nim, and more.

The HP-41C, introduced in 1979, and (amusingly) discontinued in 1990 (the year the author says game design became feasible on calculators) had an alphanumeric display so it could do word-based games, and Hangman and an an Adventure-like game were available.

<comment><USER21> The article also makes it sound like TI released the first graphing calculator in 1990. In fact, HP did that a full 3 years earlier.

[http://en.wikipedia.org/wiki/HP-28C](http://en.wikipedia.org/wiki/HP-28C)

I much preferred programming the HP-28 (and later the HP-48G) to the TI-8x series. An RPN language is a natural extension of the calculator interface, while a BASIC interpreter always felt like a weird bolt-on.

</comment></comment><comment><USER22> Great article. I used to ask girls for phone numbers and such by borrowing their calculators and writing a small program. For my biggest crush I wrote her a program that spit out nice quotes whenever she ran it, what a blast.

My response to the article though is that kids today have iPads and other tablets and they will delve into those they way we embraced the TI-83.

<comment><USER23> The article talks about the difficulty in that. With the TI-8x series you could work directly on the device. With today's tablets you need a computer and developer licenses.

<comment><USER24> Then again we are talking about a device called a 'programmable calculator', you can't really compare it to an iPad.

It's funny how the barrier of entry to programming is higher now in some cases, but lower in others.

In the old days computers booted to BASIC. C compilers etc cost hundreds of dollars. Today's devices don't boot into BASIC but you can get a ton of programming environments and tools for nothing other than the cost of a download or copying a disk. Even to work with Apple devices you're only looking at $99/year (not counting $1,000 for the necessary Mac)

Maybe Apple should make some sort of student license where you can work with 1-5 devices but you can't publish on the store?

<comment><USER25> The first device that I wrote a program for was a TI-57, this was a couple of years before I learned BASIC, the idea that you can make something follow your instructions is important.

</comment></comment></comment></comment><comment><USER26> I miss this.

I used to have a Palm device. It had a black and white 320x320 screen, slow CPU, low memory, and no Wi-Fi. But I could run PocketC on it and work on a hobby game project, either on a computer or the device itself.

A few years later I got an iPhone 3GS. It had a much faster CPU, better screen, wifi and 3G Internet with a browser that could display desktop websites. It was leaps and bounds more powerful and capable than the Palm device, except I couldn't actually develop any pet game project on the device itself (in a C-like language; I suppose JS dev is possible).

</comment><comment><USER27> I agree with the author that the iPad could definitely be a more approachable platform. However, I think that the comparison to a TI-83 is also a little bit naive. The TI has a 64 x 96 pixel greyscale display. The iPad's resolution 2048 x 1536 in full color with a quad-core dedicated graphics processor. In order to work with that, we have huge APIs implementing complex abstractions. And all that extra complexity must be dealt with using an antiquated programming language with horrible syntax.

Yes, we could create some kind of simple emulator that makes it possible to write simple things as easily as they could be done in TI-BASIC. But what kid wants to write a nibbles or mario clone when they can with a few finger taps be playing a 3D shooter or racing game. The simple reality is that we are no longer in the frontier days of computing, and I would argue that our languages and abstractions haven't kept pace with other advancements. The easy things have all been done. And the interesting things that haven't been done are hard. That has a significant role in what the author is talking about.

There are also other forces at play--such as the very large economic interests that exist around programming iOS--that weren't a factor for TI back in the day. So while I'm all for the author's thesis that things should be more explorable, I think he's ignoring the fact that a significant amount of essential complexity has made that a much more difficult proposition than it used to be.

</comment><comment><USER28> I don't see any competition at programmable calculator's market.

Why noone gets a modern SoC, connects it to a modern OLED display (but keep hardware keyboard, please), burns in basic DirectFB-based GNU userland with tons of readily available free science (not only math) and programming tools, designs an basic UI over the thing (most hard part), keeps the POSIX shell available and device completely unlocked, and starts selling the product? I do believe there are parents who would like their kid to have a good calculator to aid in the school, but don't want them to have an iOS/Android tablet (as it's more likely the kid will end up playing or using it for social networks).

I mean, replace everything that sucks about graphing calculators - <USER2> (and seriously overpriced) hardware and limited programming and debugging functionality (if you're about to argue - please compare TI calculator to your development workstation to see what I mean), but keep the device feel generally science- rather than entertainment-oriented?

In short: a handheld device with a general feel of modern programmable calculator, with (preinstalled) Maxima, Octave, PHYSICA, R, Python, Racket and so on under the hood, and without any [readily available] "app store" full of games.

Or such products do exist, but I just haven't stumbled on anything like this?

</comment><comment><USER29> IMO, this is a beautiful article.

The author has a grasp of education that probably wouldn't have occurred to me. I love the sentence "It may be tempting to see convention and subversion as incompatible, but education thrives in the healthy tension between the two."

I personally learned to program nearly 20 years ago, when I was 13. I was fortunate enough to have a computer around the house and was pretty familiar with MS-DOS and the various conventional memory incantations required to run Games, and I'd played around with GW-BASIC but my family was visiting some relatives' house where I found and picked up what I consider to be one of the most formative books of my life: C for Dummies. For some time, we'd had a copy of Borland C lying around the house, and a copy of K&R, but I could not get into it, though I'd made a few stalled attempts. But this book... it brought the computer alive for me.

Fast forward to today, I am technically self employed, though most of my work is a full-time contract with a single company, and I make a low six figure income. All because I learned to play and experiment with that beautiful thing called programming, because of C for Dummies. Dan Gookin (the author) changed my life, in much the same way that the article's author was changed by the discovery of the programming tools for the graphing calculator.

I am a high school dropout, and very nearly failed out of two universities before completing my bachelor's in Comp Sci after 8 years of attempts. I have historically had a tough time of conventional learning, though I believe I've matured enough for this to have changed over the last few years. Programming taught me discovery, experimentation, a whole, whole lot of getting shit wrong, how to figure out solutions to poorly defined problems (which usually first requires coming up with a proper definition of the problem), and so much more.

Programming is a beautiful thing. My friends just had a baby girl and at their baby shower they had a little 'time capsule' where people could leave notes for the baby to read in the coming years. Mine said that I would be happy to teach her how to program.

For me, programming is a big part of life!

Finally, I love the fact that a non-professional programmer embraces and sees the value in this.

</comment><comment><USER30> For anyone nostalgic about TI-BASIC, I implemented the 83/84 variant a while back: [https://github.com/lunixbochs/pitybas](https://github.com/lunixbochs/pitybas)

It lacks advanced math tokens and graph screen IO, but it's incredibly easy to extend and emulates much of the language's quirky behavior.

(-> terminates the token stack, end quotes are optional, you can use "If; End", order of operations, matrices, lists, menus)

There's a VT100 terminal output module which allows you to play home screen games like Mofrog, but I haven't implemented a graph screen IO module yet.

You can run arbitrary .BAS files found on the internet.

</comment><comment><USER31> I'm going to have a hard time with this when the school district mandates that my son use a calculator that has an "Equals" key.

We've always been an HP family. RPN all the way. I literally am unable to use a TI calculator (well, they may well have Enter keys now -- I know the newer HP calcs have Equals keys of a sort, which you can ignore). My son will not be using a scientific calculator as broken as the TI ones.

You think I'm joking. I'm not. (I'll probably have to relent and let him use a TI, but I'm going to show him RPN first...)

<comment><USER32> So he thinks his Pop is on top of the stack?

</comment></comment><comment><USER33> What if that liberty, that sense of discovering how to change it was not an intended side effect, and the more controlled ipad environment is?

agree that exposure to that "primitive" environment and the desire to create something great would force the user to make use of ingenuity. agreed that incredibly constrained tools and no very high level language is included, yet still reducing high level problems to low level instructions can allow to discover and see something that could have been hidden by better tools.

or can it be just nostalgia?

</comment><comment><USER34> My kid just got a school-issued iPad in 5th grade. Awesome!

But he's also required to buy a lame-o TI calculator as well?! Why?! Oh, because the standardized testing companies are freaked out by iPads.

TI has a stranglehold because of a lack of wifi???

How can we get iPads accepted as legit devices to use while taking tests? I'm getting flashbacks to all the open vs closed book debates about testing that I went through in high school and college...

<comment><USER16> How can we get iPads accepted as legit devices to use while taking tests?

Remove the ability to communicate, boot it to a standard image that doesn't allow cheats.

<comment><USER34> It sucks that googling for something counts as cheating, when really it's a skill that applies to about 90% of real life :-)

<comment><USER16> Last year I caught two students IM'ing during a final.

Most of my exams are open book, open note; so I am not unsympathetic to the realities of how a real job is[1].

[1] source: I used to have a real job.

<comment><USER34> I agree that "asking a friend" is not legit and would be cheating, but using google to find something is more like open book testing.

The closest thing I could think of would be to set the iPad into Guided Access mode where you can't exit an app at all, but having teachers do that to every kid's iPad would take a while...

</comment></comment></comment></comment></comment><comment><USER35> When I read about the language TI-BASIC in the above article, it reminded me of my old TI-99/4A computer[0], which I got from my dad to learn programming. This computer also included a TI-BASIC language, I wonder if they are in any way related, except of course from being a BASIC language created by Texas Instruments. It would be cool if old TI-99/4A games would be playable on "modern" TI graphic calculators.

I still have two TI-99/4A computers in my cellar, for nostalgic reasons :)

[0]: [http://en.wikipedia.org/wiki/Texas_Instruments_TI-99/4A](http://en.wikipedia.org/wiki/Texas_Instruments_TI-99/4A)

</comment><comment><USER36> Holy crap, I played Desolate, that game was seriously amazing for a calculator. The graphics rivaled the original Game Boy (a decade later, but still). It was seriously smooth and well made.

</comment><comment><USER37> Graphic calculators are totally obsolete now.

You could run circles around it with a Nintendo DS with homebrew, Sony hand held consoles and of course the Ipad, Iphone or Android.

But don't expect to convince your 50-60 year old teachers in University to let you use it. In spite of showing the apps that I had done for structural analysis in my Nintendo DS, they could not let me use it, I had to buy one of those stupid, overpriced, obsolete graphic calculators.

</comment><comment><USER32> Never really had a graphing calculator when I was in school. Bought 92 Plus years later just to have a ultraportable "computer" for field work. LCD screen is starting to decay after years of use, so I picked up another in "mint" condition for $40 at a used book store.

Would love to take the old one and replace the screen and processor with something more modern, keeping the keyboard.

</comment><comment><USER38> Is a graphing calculator really the most obvious way that a young and impressionable mind will find an inroads to programming in this day and age? I find that idea laughable. Tinkering on the web is the obvious modern-day equivalent that is completely neglected when talking about how hostile the modern environment is towards the young creative spirit.

<comment><USER39> It is easier to lug a graphing calculator around than a laptop, particularly in schools. I spent countless hours programming on my calculator while sitting in cars, hiding in the back pews at church, inside of tents during camping trips, sitting in the back row of classrooms,...

It was something I could do that caught my attention while forced to be someplace I had no interest in being. I don't think web development gets you that.

<comment><USER38> Oh, it completely does. My niece this year is required to have a laptop for school. She _has_ to have a PC with her. Now, she has no interest or aptitude for programming, but if any of her classmates do, they can easily fire up a web browser and get to hacking, even without an Internet connection.

<comment><USER39> That is rather alien to me, but I am pretty certain it is not the norm (my old school-district, where my mother is still a teacher, certainly doesn't have anything like that). Even so, I doubt an English teacher would take kindly to her pulling out her laptop in the middle of class... I've had plenty of _university_ professors that would freak out if you tried that.

(Also keep in mind, that for most of the time-periods when calculator hacking was popular, web development was also a thing (I was heavily into this stuff during the late 90s and very early 00's). I did that stuff in highschool but it simply didn't interest me in the same way. Calculators were limited, and that presented both a challenge and a goalpost. Doing the same stuff with webdev? That is mundane and discouraging because you know that, at an entry level, you are not exploring the bounds of the medium in any meaningful way..

It is like the difference between seeing how fast you can go down a hill on a skateboard, and how fast you can go on the highway with your mother's minivan. Rotate a few triangles with webgl... or optimize a trig table in z80 assembly....

When I came home at the end of the day, I would fire up my PC and started editing some z80 assembly on it instead of programming the computer itself. Hell, I would test on a calculator emulator running on the PC...)

<comment><USER38> Web development in the 90s and early 00s was not a practical substitute for learning how to program. Now, it is.

You make a claim that the low-level nature of the calculator programming was an enticement to you. That may be, but I would hestitate to generalize based on your own experiences. I would suspect that the ability to come up with something that actually does something conventionally interesting trumps the benefits of working close to the metal, ESPECIALLY with young, novice programmers. A few hours of hacking in assembler and you may get to hello world, whereas the same amount of effort in javascript might net you the ability to drag and drop objects around a UI. Which is more impressive to a kid?

<comment><USER39> > _Web development in the 90s and early 00s was not a practical substitute for > learning how to program._

Of course it was... many people _did_ learn that way. If anything, it was more accessible then than now. Actually, 'substitute' nothing, something that _is_ is not a substitute. That's not the point though, you _could_ teach middle- schoolers to program with fucking Java if you wanted to, though of course you shouldn't.

Say you're a teenager and what to program "Snake". Are you going to get up off the ground with TI-BASIC or WebGL/whatever faster, and which is going to leave you more satisfied. On a calculator you have pushed something to its limits (in some limited way), with web-dev you have done nothing of the sort. Power and raw capability is _not_ what you want from a teaching aid.

And to be clear, I am not arguing for a low-level next to the metal introduction to programming. _(TI-BASIC is of course nothing of the sort.)_ I am arguing for giving children a pair of boots that fit, not a pair of boots suitable for industrial use. Something that they can properly fill out and master. Something with bounds that they can strive for _and reach_. Something that _forces_ them to get clever when they reach those bounds.

If you think this is a bizarre concept, then look at Logo.

</comment></comment></comment></comment></comment></comment><comment><USER40> I bought the TI-85 dispite it being an older model because it had been hacked so I could program it in z80 assembler.

<comment><USER8> TI-86 can be programmed in asm without hacks (I had both 85 until it broke down and 86).

</comment></comment><comment><USER41> This must be an American thing.

 _All_ the exams I have ever written (grade 1 to post grad) specified graphing calculators are prohibited. Every last one. Graphing calculators tend to be programmable and/or can save text files & local educational institutions didn't want to go there.

</comment><comment><USER42> Perhaps the author's arguments about the benefits of graphing calculators are legitimate, but there is no reason that this is specific to TI. TI 8* calculators seem to me to be particularly overpriced and lacking in modern features.

<comment><USER43> Do you know an alternative which is cheaper or has the missing features?

<comment><USER44> Perfect for the majority of student uses:

[http://www.staples.com/Casio-FX-9750GII-Graphing- Calculator/...](http://www.staples.com/Casio-FX-9750GII-Graphing- Calculator/product_510052?cid=PS:GooglePLAs:510052&KPID=510052)

Aside from playing Ti 8* games. I'm not sure what engineers need in a calculator so I can't comment on that, but in my use case (nearly a decade ago) I could have gotten one of these and been just fine. I got a TI83 because it was the standard issue.

In my own personal use (scientific calculators for hobbyist purposes) I've switched to Casios since they just have outright nicer displays than the selection of HPs and TIs at Fry's and they cost a bunch less.

</comment></comment></comment><comment><USER45> It's a shame that iPads are being pushed so heavily in the educational space. Apple products are built upon denying users access to learn about the hardware and software. Educators should be fighting against walled gardens.

</comment><comment><USER46> For those interested www.ticalc.org is an incredible archive dedicated to these little computers.

I love TI calcs so much that the first app I install on a new phone are the TI calc emulators.

</comment><comment><USER47> Shows how much we've declined. Kids nowadays use graphing calculators in JHS algebra. We had no calculators, and calculus in my JHS by the 10th grade.

</comment><comment><USER48> What we really need is HyperCard for the iPad, ideally with a Parse-like service to let you easily write network code, not crappy TI-Basic.</comment>


Better C – A subset of D Programming Language - <AUTHOR> https://dlang.org/spec/betterc.html <comment> F-0X One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking at what the compiler complains about.

And that's a huge shame. Because in general I really liked using D.

<comment><USER2> I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard.

Another reason is the (ironically) dynamic nature of a return type. E.g.

auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }

Template code can do that quite easily and then you don't have a choice but to write auto as the return value.

What would be fantastic if the documentation could be given access to the the compiler's return type inference, so that it could document the auto returns with a little more info.

Another way useful approach would be to implement protocols like in swift, or traits like in scala/rust/others, signatures in ml, etc. Then you would be able to define the interface of what a function returns.

<comment><USER3> I haven't looked at D yet, but... _yuck_! `var` for return types in a method signature is seriously unhelpful!

If the docs are filled with this, then D is certainly coming off my list of langs to look at.

For functions that can return different types, I think interfaces or union types would be more helpful (not sure if D supports either though).

<comment><USER4> Yes, it supports interfaces and unions. One thing not being stated enough in this thread also is that the docs are not just a regurgitated version of the prototypes -- there's actual hand-written text that tells you what the things return.

</comment></comment></comment></comment><comment><AUTHOR> For more context and details, Walter Bright wrote a series of blog article between 2017 and 2018 on the subject (though their content is a bit outdated as more D features are now supported in BetterC mode):

\- "D as a Better C" (2017): [https://dlang.org/blog/2017/08/23/d-as-a- better-c/](https://dlang.org/blog/2017/08/23/d-as-a-better-c/)

\- "Vanquish Forever These Bugs That Blasted Your Kingdom" (2018): [https://dlang.org/blog/2018/02/07/vanquish-forever-these- bug...](https://dlang.org/blog/2018/02/07/vanquish-forever-these-bugs-that- blasted-your-kingdom/)

\- "DasBetterC: Converting make.c to D" (2018): [https://dlang.org/blog/2018/06/11/dasbetterc-converting- make...](https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/)

</comment><comment><USER5> This is a great idea. I maintain that Ada is a better "better C" than any of the alternatives I've looked into, but it has an obvious big hurdle: while it has approximately the same use cases as C, it is completely different in terms of looks and handling. One of the strong points of D is that it still seems very much like C. Very good call to emphasise this.

<comment><USER6> I've always liked the idea of Ada, but never had a place to use it. Though someone on HN pointed out that NVidia was using Spark for secure code sections. Quite interesting!

Personally while D seems a great tool, I really keep running into situations where a language that lives on top of C/C++ is useful. So I've been trying out Nim for those use case, using the ARC GC which appears to work well for embedded. It's deterministic but with move semantics for performance optimization. Interesting approach IMHO. But the biggest advantage is being able to directly interface with any C or C++ natively. D/Rust both seem to have difficulty being 100% onboard with C++ (for good reasons).

<comment><USER7> > I really keep running into situations where a language that lives on top of > C/C++ is useful. > the biggest advantage is being able to directly interface > with any C or C++ natively. D/Rust both seem to have difficulty being 100% > onboard with C++

I thought one of the centerpieces of D was seamless c++ interop? Where does it fall down?

<comment><USER8> You just need to do a bit of tiresome explicit declarations to statically link the code.

For libraries with a large API that can be an annoyance.

<comment><USER6> AFAICT, D requires the C++ types be exported, included any predefined template objects or functions. E.g. you can't dynamically wrap `std::map<K,V>`, unless it's already been instantiated in C++ library you're linking. The same in Rust as well. See D Lang manual:

        Note that all instantiations used in D code must be provided by linking to C++ object code or shared libraries containing the instantiations.

Whereas Nim is one of the few languageS that can dynamically wrap C++ template types into its type system. Maybe Zig can do it too? See Nim manual [2].

        type StdMap {.importcpp: "std::map", header: "<map>".}[K, V] = object proc
        ...
        var x: StdMap[cint, cdouble]
        x[6] = 91.4
        ...
        std::map<int, double> x;
        x[6] = 91.4;

This makes it nice to wrap C++ libraries. :-)

1: [https://dlang.org/spec/cpp_interface.html#cpp- templates](https://dlang.org/spec/cpp_interface.html#cpp-templates) 2: [https://nim-lang.org/docs/manual.html#importcpp-pragma-impor...](https://nim- lang.org/docs/manual.html#importcpp-pragma-importcpp-for-objects)

</comment></comment></comment></comment></comment><comment><USER9> Mr. Walter Bright, I'm late to the party here, but I hope you will see my comment.

I have a lot of respect for you and Andrei, and I think D deserves much more love than it gets.

I personally feel like there are too many options when it comes to D. Perhaps it would be good to double down on some combination of those options and make that widely known?

As a newcomer to D, I am exposed to GC/non-GC code, dmd/llvm compiler/gcc compiler, several debuggers, some BetterC option, etc. I don't know which toolchain is best, and I don't want to deal with the integration issues between them.

All of these options that exist are great, but the brand gets diluted. D seems to be the ideal thing: it's seemingly a better C++, and a better C, with a clean syntax like Java.

I trust it's a better C, but how do I know the combination of the D toolchain that I'm choosing is better than sticking with the devil I know already?

What I would love to see is an opinionated package spun off from D. One compiler, one debugger, one IDE, one standard library. Make my onboarding experience better and take the thinking out of assembling a D toolchain.

Every time I find myself thinking "maybe I should look into using D instead of C for this project", I spend a few hours with D, and then I get frustrated at all the options and I go back to the devil I know.

I truly wish I could be one day convinced that I can install D and I get a solid platform without weird moving parts.

<comment><AUTHOR> Yes, I completely agree, the onboarding experience is daunting. It's quite hard to understand all the moving parts and figure out which one I should care about or not.

</comment></comment><comment><USER10> D is pretty exciting. Seems like a perfect choice for those of us looking for an alternative systems programming language and are not completely convinced we'll be happy in Rust.

<comment><USER11> Yeah I think "better C" is a space which has a really good reason to exist and I'm always interested to see new entrants.

IMO describing Rust as a "C replacement" is slightly off the mark because Rust's value proposition is very different from C. Rust is about giving you the best possible performance in a safe-by-default language. C is about giving you maximal control over memory, with a very thin layer of abstraction over the hardware.

C has traditionally been used in a lot of places where Rust's USPs add a lot of value -- for instance in kernel development -- simply because there wasn't a safe alternative. However I think there are other cases where the strengths of C still add value; for instance in game development you're largely trying to do high-throughput processing over large swaths of structured data, and Rust concepts which help safety like RAII just get in your way. Yes there are ways to get around this in Rust, but Rust is not really optimized for structured, manual memory management.

As a result I think there is plenty of room for something like C which just has better ergonomics and some more modern features.

<comment><USER12> D also now supports Ownership/Borrowing (experimental) on a per-function basis, meaning it can be added incrementally to an existing program.

<comment><USER13> D's borrow checker fails in comparison to Rust's. It serves very little purpose and provides almost no guarantees. These issues have been brought up multiple times but they are brushed aside with ignorant responses like "I've been told my entire career what I'm doing will fail but I continue to do it anyways".

<comment><USER12> Yes, you do create accounts to follow D around and complain about it.

</comment></comment></comment></comment></comment><comment><USER14> For me the single best feature that stands out in D is the uniform member access using dot.

\- Want to access member in a aggregate (class/struct)? Use .

\- Want to access member in pointer to an aggregate? Use .

\- Want to access member in a module? Use .

\- Want to access reference (not free standing)? Use .

This makes switching between different implementations pretty easy. Coupled with UFCS, this is pretty fantastic!

<comment><USER15> I can strongly relate to that. You can write a custom "fill" method for your array and just do "arrray.fill", bam! It just works. You want numpy "zeros"?

Just do a template

void zeros(T)(ref T arr) { arr.each!"a = 0"; }

someArr.zeros;

</comment></comment><comment><USER12> Walter here - AMA!

<comment><USER16> A compiler related question:

A often recurring C idiom is passing a pointer to a struct as function argument where passing the plain struct by copy would do. A big reason is the good old 'passing by pointer is faster', which I thought to be no longer relevant with modern optimizing compilers. Of course I found out the hard way that even on modern compilers object copies are not elided on call. I had performance sensitive parts of my (non-x86) code that were dominated by the compiler's builtin memcpy, due to my struct-happy coding style (e.g. rolling my own range struct and passing it by value everywhere).

I understand mostly why eliding argument copy is so much harder than eliding a return object copy, there are so many ways to observe its effect, and you have to obey the calling convention. Another aspect is the lack of programmer- communicated immutability in C, which you have addressed with D. Does the D compiler help in this situation? Can it guarantee that (immutable) argument copies will be elided in certain circumstances? (e.g. in file-scope static functions)

<comment><USER17> The proposed NUBI ABI[1] for MIPS was interesting here in that for call by value if a struct was register sized, it would be passed in a register, but if larger it would be implicitly passed by reference. See section 3.4, Arguments.

It was then up to the callee to make a copy if necessary, say if it modified the struct contents.

Hence it would have been possible to elide the copies, on a per function basis, depending upon how the function used the structure.

[1] ftp://ftp.linux-mips.org//pub/linux/mips/doc/NUBI/MD00438-2C-NUBIDESC- SPC-00.20.pdf

<comment><USER16> Thanks for the interesting pointer.

I was also thinking in the direction of the compiler transforming the call-by- value struct object argument into a call-by-ref one at specific call sites. e.g. when the object is clearly on the caller's stack, is not mutated by the function and the function is not taking its address.

As Walter pointed out, you can use refs in BetterC (and of course C++) directly, but I don't see why it cannot be automatically applied to C in general.

</comment></comment></comment></comment><comment><USER18> Not included as part of the subset linked above, but D's Contract Programming piqued my interest: [https://dlang.org/spec/contracts.html](https://dlang.org/spec/contracts.html)

<comment><USER19> Ada ([https://learn.adacore.com/courses/intro-to- ada/chapters/cont...](https://learn.adacore.com/courses/intro-to- ada/chapters/contracts.html)) and Eiffel ([https://www.eiffel.com/values/design-by- contract/introductio...](https://www.eiffel.com/values/design-by- contract/introduction/)) also support contracts.

Contract-based programming is a very nice way to quickly find errors and specify how different parts of the program should interact.

<comment><USER20> C++20 almost got them.

There are some Java annotation processors that rewrite the bytecode for contracts.

As extra info.

<comment><USER19> Java annotations have always struck me as interesting since they fill the Lisp macros and C preprocessor niche for Java.

It's another layer of complexity, but it extends the language to offer a bit more richness or layers of abstraction.

I would not be surprised if a future C++ standard adds contracts officially. Boost seems to already have contracts: [https://www.boost.org/doc/libs/1_67_0/libs/contract/doc/html...](https://www.boost.org/doc/libs/1_67_0/libs/contract/doc/html/boost_contract/contract_programming_overview.html)

<comment><USER20> Yes, many aren't aware how much annotation processors and compiler plugins are capable of.

On the .NET side you have Roslyn, Attributes, expression trees and on F# quotations.

While they are all a bit cumbersome to use versus what Lisp macros allow for, they already allow for quite a lot.

Yes, there is some hope that C++23 will bring them.

The more languages support DbC the better, only so can we start seeing more widespread adoption across the industry.

</comment></comment></comment></comment></comment><comment><USER20> Now with WebAssembly support thanks to LDC, the Better C experience is definitely much more productive than dealing with emscripten.

Then again, I am biased.

</comment><comment><USER21> The chosen example (printf) doesn't make D look very good compared to C. If I modify the example to include a simple type error:

        printf("Hello %s", 123);

Then the D version will still happily compile without warnings and will segfault.

Compiling with GCC -Wall -Werror, the type error is easily caught by the compiler.

<comment><USER14> Use dmd master and you will have printf/scanf format argument validation [0].

[0] [https://github.com/dlang/dmd/pull/10852](https://github.com/dlang/dmd/pull/10852)

<comment><USER12> Yeah, I am glad we fixed that one.

</comment></comment></comment><comment><USER22> every time I've looked into this I've found the documentation severely lacking in examples of how one would go about incrementally migrating a c project to better c. does someone have a pointer to a blog post or even a git commit that illustrates the first step of migrating a single c file, with all the attendant makefile changes?

<comment><USER12> 1\. rename the file from prog.c to prog.d

2\. set up to compile with dmc prog.c -c -betterC

3\. replace all the preprocessor stuff

4\. compile it, and fix the errors diagnosed by the compiler

The hardest part will be how much metaprogramming was done using the C preprocessor. Once that's dealt with, the rest is fairly mechanical.

</comment></comment><comment><USER23> The problem is that since this Better C is not compatible with any C dialects, and requires a D compiler, there is no reason to restrict D programs to this subset. At least no reason that is related to simply working in something better than C. The real reasons can be articulated better, starting with a different name, like "Reduced D" (D that avoids garbage collection, exceptions and/or has a smaller footprint or whatever). How about "Dm": D Minor: a sad subset of D.

A subset of C++ is a better C, that can be written in such a way that C compilers translate it, so that is meaningful. Well, at least a slightly better C, anyway.

</comment><comment><USER24> Regarding the ongoing auto/var readability issues debate, how about the popular dynamic languages that often do not even have the means of specifying a type? They surely must be suffering from huge readability issues?

<comment><USER25> Such languages (e.g. python) serve a different purpose, at least in my opinion. Using python as scripting language for small "adhoc automation" things is great.

For long-living and bigger code bases, worked on by teams, explicit types and "proper" static type system are the better choice.

E.g. it's less about readability, but maintainability.

</comment></comment><comment><USER26> This is a nice tutorial introduction on using D as a better replacement for C [1].

Some excerpts "At one time, C was my go-to language for most programming. One day I realised that most of my C programs kept reimplementing things from C++: dynamic arrays, better strings, polymorphic classes, etc".

[1][https://theartofmachinery.com/2019/04/05/d_as_c_replacement....](https://theartofmachinery.com/2019/04/05/d_as_c_replacement.html)

</comment><comment><USER27> I think D is great for scripting.. and having no python experience but java/c/c++ it feels more familiar. The standard library is useful.

</comment><comment><USER28> > To link D functions and libraries into C programs, it's necessary to only > require the C runtime library to be linked in.

Not that I'm suggesting this would be a better approach, but wouldn't it be possible to link both the C and D runtime libraries and wrap the main function to do the initialization?

</comment><comment><USER29> For those who have been around a while, this is not the same as DailyWTF's Better C dialect.

[https://thedailywtf.com/articles/The_Secret_to_Better_C](https://thedailywtf.com/articles/The_Secret_to_Better_C)

</comment><comment><USER30> Feels like a more accurate name would be "Freestanding D" but it's a cool idea.

<comment><USER12> I actually wrote "D as Better C" before realizing "Das Better C" sounded much better. And a shout out to all our German speaking D users!

</comment></comment><comment> kalium-xyz So D-- then?

</comment><comment><USER31> I think they should call it only slightlybBetterC

All the features I like in D such as dynamic arrays and associate arrays are gone

</comment><comment><USER32> Ohh! Ohh! C and C++ are used. How about ℂ (double-struck C) to mean "Like C but double the fun!"

</comment><comment><USER33> Reminds me of Ada++

</comment><comment><USER34> It's interesting how this works:

\- enumerate everything C is doing bad.

\- presents fixes with a full bag of unnecessary features that no c programmer wants.

I wonder why there is no "Fixed C".

<comment><USER35> Sorry to see this at the bottom of the thread, because you have a real point here. None of the attempts at "better C" or even "replacing C" have been serious attempts, and it's frankly getting a bit insulting. No one who still uses C wants its replacements to "catch up" on the past 20 years of new language development. We want C, but without the problems. We don't want D but less so. The response below - "you don't have to use any features if you don't want to!" \- is a ridiculous cop-out and the same thing people who defend C++ are saying.

<comment><USER34> Thanks for your comment. It's pretty normal to face this downvotes when talking about language. And my phrasing was not the most kind of all.

It's just the CS community, at some point when you are writing languages you tend to try to outsmart the language you are fixing by creating overly complex behavior. Over-engineering is every single new languages.

Even Zig fails to do better than C, I think it's syntactically a disaster.

Here is a few lines from the documentation:

      const ptr = @intToPtr(?*i32, 0x0);

      while (it.next()) |item| { /* ... */ }

      pub fn main() anyerror!void { /* ... */ }

      exe.addCSourceFile("test.c", [_][]const u8{"-std=c99"});

      const file = std.fs.cwd().openFile("does_not_exist/foo.txt", .{}) catch |err| label: { /* ... */ }

<comment><USER36> Do you not like those because they're unfamiliar? What about the syntax indicates over-engineering?

Here's what I see in your example:

\- @ indicates built-in function, which avoids namespace collisions.

\- Optional types via the ?, which solves the null pointer problem.

\- Real iterators, which are less error-prone and nicer to read than traditional for loops in a lot of common applications.

\- The || syntax is better than something like `for (type var : array)` in Java, don't you think? Especially since it works with _any iterator_?

\- anyerror!void is a nice way of saying that the function can return an error. Remember that we don't have exceptions here.

\- It has interoperability with (multiple standards of) C.

\- Error handling is higher-level and less error-prone than in C without exceptions that can create hidden jumps in your code.

So it clearly solves issues that people run into frequently in C. It brings in a nice sampling of high-level language features without doing anything that would compromise its niche as a systems language. It still has manual memory management and does not have exceptions. The behavior is _simpler_ and requires that you language-lawyer the specification for undefined behavior far less often than in C. Your knowledge of C isn't necessarily enough to be able to immediately read Zig code, but that's because Zig isn't C. It's not hard to learn.

<comment><USER34> Thanks for spending your time explaining this. I think a lof people will understand those lines better.

I actually already knew everything. I watched closely the development of Zig, and just give up when I realized all those decisions where made carelessly in my view or I just simply disagree with the direction of the syntax.

Since you took your time I will take mine to address what I don't like:

\- There is no way to write "int" by default. I understand why. But I don't agree.

\- struct and enum statements (within braces) are separated by a comma which is inconsistent with statements in function separated with ",". In my view expect a difference between parameters and statements. parameters (a,b,c) statement {a;b;c}

\- You have to type "var" or "const" everywhere, but not in struct statement and enum statement. Sometimes it's like a "def" sometimes not.

\- You have to type const when importing module:

      const std = @import("std"); // Why ? Why should I specify const, this should be inferred. Same when I define a struct.

\- the "undefined" keyword when it means "uninitialized" even in the documentation.

      var my_var: i32 = undefined;

\- The worst, no default values for struct.

\- The list of keywords is insane: errdefer, allowzero, orelse, unreachable, anyerror

\- About iterator I was doing well with:

      while(get_next(context,  &item)) { /* ... */ }

It's like everything has been carefully design to be even less readable than C code. I have the feeling that the syntax help more the compiler than de developer.

I wish I could bet thousands of dollars that there will be only one compiler in the whole life of Zig language (also because it relies way too much to LLVM).

<comment><USER12> > It's like everything has been carefully design to be even less readable than > C code.

D is designed to be very readable to the C programmer. Some changes, like replacing:

        (int)(expression)

with:

        cast(int)(expression)

is designed to make the code more readable, and greppable. Cast is a fundamentally dangerous operation, so being able to grep-and-check for such is worthwhile.

The D compiler actually recognizes the C form and suggests using the D form to fix it.

Converting C to DasBetterC is largely just a) eliminating use of the preprocessor and then b) making the syntax changes suggested by the compiler.

<comment><USER34> Yes, I can see the design of D was made carefully.

D is actually a great language. I just "don't understand" why it's not massively used instead of more recent versions of C++, I consider newer version of C++ as a totally different language with more drawbacks than advantages. Half of new features are present to fix previous half baked features. This is quite embarrassing.

Sorry for my selection of words (and for the unrelated opinion, I had to rant), I'm not good at spending time to rephrase when the end content is the same.

I remember one time I spent the whole day browsing the website of D, everything actually make sense. There are still features that I wouldn't use, but this is what I expect from a programming language design. I was impressed by a lot of decisions.

I seemed to remember that I was a bit sad to not find proper performance benchmarks against other languages. I was intrigued because the documentation was so complete, it was just lacking this (maybe I just couldn't find them). It was a long time ago so it has probably been fixed. I will give it a try at some point.

<comment><USER12> The performance of D vs C and C++ should be identical for code written the same way, as they share the same optimizer and code generators.

Also, we used to publish benchmarks. These inevitably did not produce illumination, but long ripostes from people arguing that the benchmark was unfair, inaccurate, nobody would write code that way, we sabotaged other languages, etc.

We encourage people to run their own benchmarks on their own code and let the results speak for themselves.

One issue with moving to D is it takes a while for people to learn "the D way". For example, if they come from C they write C style code in D. From C++, they write C++ style in D. From Python they write Python style in D. Inevitably they'll run into some difference where D doesn't have an analogous feature, and would get a bit frustrated (even though in D the task would be accomplished a different way).

It takes a bit of perseverance and faith to get through that until one discovers "the D way" and then they're hooked.

One of the reasons for DasBetterC was to reduce this issue as much as possible, though the people who like metaprogramming with the C preprocessor will have more work to do in getting adapted to D's powerful metaprogramming features, which of course work nothing like text macros.

<comment><USER34> > Also, we used to publish benchmarks. These inevitably did not produce > illumination, but long ripostes from people arguing that the benchmark was > unfair, inaccurate, nobody would write code that way, we sabotaged other > languages, etc.

Oh, this is pretty sad...

Anyway thanks for your time. Was nice to interact with the author of D. I truly believe what you've done will inspire a lot of people.

I hope you didn't encounter too many people saying creating D was foolish.

I spent time checking about a lot of languages and only D (and Jai, but it's not released) would restore my joy of programming.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Computer Science from the Bottom Up - <AUTHOR> https://www.bottomupcs.com/ <comment><USER2> what a fantastic resource! Just a thought...why did you start your bottom up approach at the operating system level. Surely, if we are being purist's we should start with mathematical constructs first. After all, computational machines existed in the minds of mathematicians long before the any machine was built.</comment>


Google Research: Poetic Machine Translation - <AUTHOR> http://googleresearch.blogspot.com/2010/10/poetic-machine-translation.html

<comment><USER2> Another step towards Trurl's electronic bard!

If you'd like to see some unrelated but available and open-source code to generate rhyming metric verse: <http://github.com/darius/languagetoys>. Unlike the paper, this doesn't even try to preserve sense -- it just uses n-gram statistics.

</comment><comment><USER3> The person who reviewed their paper did so in verse: [http://research.google.com/archive/papers/review_in_verse.ht...](http://research.google.com/archive/papers/review_in_verse.html) .

</comment><comment><USER4> This gives me the bad feeling of when SIGGRAPH used to have papers on "artistic" filters (instant impressionism! instant woodcut!) by people without a feel for the expressiveness of the medium which they are simulating. Such work sometimes seems like subtle satire.

OTOH, I don't want to give the good Googlers short shrift, and it is certainly welcome to consider the meter (and maybe rhyme) of generated text.

</comment><comment><USER5> This is awesome, but no demo webapp.

</comment><comment><USER6> a research paper sublime

machine translation!

autumn rhymes abound</comment>