Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pretty.c

github.com

Post reply on HN
Print view View original

151–160 of 227 posts

Re: Pretty.c

#151

Post by throwaway19972 »

lelanthran wrote: post #81
throwaway19972 wrote: post #58

Does "strong typing" now just mean "static typing"? Afaik both lua and python are already strongly typed. Javascript is not and I have no clue about ruby.

> Does "strong typing" now just mean "static typing"? The distinction strong and weak typing is irrelevant in practice. Weak (but present) static typing beats strong dynamic typing every single time, because what is valuable is NOT "Do I see a type mismatch error only when a user accesses it?" , it's "does this mismatch prevent a deployment?" IOW, the only distinction in production is dynamic typing vs static typing,…

> because what is valuable is NOT "Do I see a type mismatch error only when a user accesses it?", it's "does this mismatch prevent a deployment?"

I argue that understanding the semantics clearly and unambiguously is the most relevant thing, and strong typing tends to do that better (imho—with my only other examples being javascript and the "stringly-typed" perl and some random irrelevant BASIC dialects).

> Weak (but present) static typing beats strong dynamic typing every single time,

Can you give me an example? I don't think I've ever heard of such a thing. The closest I can think to this is maybe, arguably, the use of `void*` pointers in C which is difficult to see as anything other than pragmatism rather than some deeply beneficial way to write code—even explicit casts produce much more readable code. Another argument I could see is for operator overloading, which (IMO) produces much less readable code, or the implicit conversions feature of Scala (which also, IMO, produces less readable code, but they've addressed a lot of the major problems with it).

Re: Pretty.c

#152

Post by randomdata »

knome wrote: post #136
aartaka wrote: post #82

Earlier quoted context omitted.

Well, who said that scripting language cannot be compiled? And yeah, Clang-REPL is another way to make it REPL-friendly.

generally they aren't, as scripting usually implies an interpreter, though no one is stopping you from using a wrapping script that quietly compiles on first run and caches a bunch of executables somewhere. not much different than python producing bytecode files as it goes along.

Script usually implies some kind of task that runs once and the exits. As opposed to a system that is expected to run indefinitely.

There are good reasons for why scripts are often interpreted and why systems are often compiled, but that's not what defines them. There are definitely scripts that are compiled and systems that are interpreted out in the wild.

Re: Pretty.c

#153

Post by chris_wot »

I’m waiting for someone to write a lambda calculus based C++ library that allows everything to be defined in terms of function. Peano axioms and all.

Re: Pretty.c

#155

Post by wffurr »

taylorius wrote: post #145

Sorry for what is probably a stupid question. Does pretty.c act as a preprocessor or sorts, converting your pretty.c script into actual c, that is then compiled? Or is it a virtual machine that interprets your pretty.c script?

It’s not a preprocessor or compiler. There’s no binary. It’s just a bunch of C code in a header: macros, functions, etc. that you can use to write different looking programs but that are still C.

Re: Pretty.c

#156

Post by w4rh4wk5 »

aartaka wrote: post #91
w4rh4wk5 wrote: post #60

I've seen this implementation of defer a few times now. I really dislike calling this defer (like the keyword in Go) as the given code won't be executed on return.

Scoping defer to a block is actually more useful and explicit than function-exclusive that Go does, so I consider that a feature.

No no, I think you misunderstood my critic. Defer working on block-scope is fine; however, if I exit the block through a return (or break), the deferred function is not called.

To my knowledge, you need a compiler extension to implement this in C (or use a C++ destructor).

Re: Pretty.c

#157

Post by schoen »

pavlov wrote: post #135
anthk wrote: post #118

Earlier quoted context omitted.

On the long term, using the native keyboard hinders yourself a lot. I tried to do so with the Spanish (es) layout, it's pretty much unergonomical. It's looks like being deliberately designed for press/office usage and not for proper programming.

I’ve been writing C and its progeny (C++, JavaScript, Rust etc.) since 1990 on a Finnish keyboard. The AltGr brackets are fine. The truly annoying character to type is the backtick (which is a quite new addition to the pantheon of special characters, C doesn’t use it). My personal opinion is that Niklaus Wirth had the better overall ideas about clarity and inclusiveness in programming language design, but that battle…

Backticks were fairly important for shell scripting in the past, but have officially been replaced with $(), which can be nested.

My intuition is that Perl would be the most challenging on a keyboard where it's harder to type unusual punctuation, since it feels like a very punctuation-heavy language, but I don't know whether it actually uses more than C (I think the backtick has a shell-style meaning in Perl too).

Re: Pretty.c

#158

Post by fuzztester »

pavlov wrote: post #54
pasc1878 wrote: post #45

Earlier quoted context omitted.

There were article suggesting #define BEGIN { and #define end }; to make C look more like Pascal. I think in Europe C was not as common as other languages at the time so the terseness looked odd.

Also because the special characters were (and are) difficult to type on European keyboards. Characters like []{}\|~ are behind multi-finger access and often not printed at all on the physical keys (at least in the past). You can see how this adds a hurdle to writing C… Pascal was designed by a European, so he preferred keywords which could be typed on every international keyboard. C basically just used every symbol f…

IIRC, Pascal had/has (* and *) as an alternative to { and } , from the start, or from early on - as syntax for start comment and end comment.

Re: Pretty.c

#159

Post by AlotOfReading »

IgorPartola wrote: post #125

For what it’s worth this makes the same mistake that Python 2 did: string and bytes are not the same type and shouldn’t be treated as such.

What do you consider the type of shell text, i.e. what's in argv and what you get from subprocess output? It's not well-formed utf8 strings because any random garbage can be in there, yet tools like awk and grep are ubiquitous.

I'd argue that strings and bytes are the same general type, but it's sometimes useful to give well-formed utf8 bytes a different type internally. Rust gets this mostly correct with OsString and String.

Re: Pretty.c

#160

Post by sheepscreek »

sneed_chucker wrote: post #141

Creating DSLs within C has a long tradition. Stephen Bourne wanted to write his shell in ALGOL so badly that he relentlessly beat C with its own preprocessor until it began to resemble his preferred language. https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...

Here is an example of what we wrote using it:

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh...

Post reply on HN