/dpt/ - Daily Programming Thread

prev: What are you working on, Sup Forums?

Other urls found in this thread:

shenlanguage.org/
benchmarksgame.alioth.debian.org/u64q/compare.php?lang=sbcl&lang2=gcc
twitter.com/NSFWRedditGif

What's up with the WWI anime in the OP posts recently?

reminder that only shitlangs lack tuples

Things that should be removed:
for and while
infix operators

Things that should be added:
storing labels in variables
explicit calling conventions (register/stack)

Things that should be discouraged:
the stack
returning more than an error code
linking, both static and dynamic

Things that should be changed:
stdlib function names (2-3char, not 6char+)
keyword names

It's pretty popular on Sup Forums right now and currently airing shows always get posted a lot because people do go to more than one board.

This season kinda sucks, also change it from trapshit and bait.

>It's pretty popular on Sup Forums right now
Not really, no.

They generally like it and almost every time i check it, there's a thread happening, so yes.

reposting
>Graham describes this as the "Blub paradox" and concludes that "By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one."
So Racket is the most "powerful" (abstract) language? Does the paradox imply that languages with low levels of abstraction shouldn't be used?

So you are just an idiot?

It's there often because you have 2 threads after it airs(1000+ posts) which lasts a few days and then a new one before the next episode airs, you still have a couple day gap without anything.

It's like almost everything else, I don't see how you would call that popular.

The funniest thing about the Blub paradox is that it doesn't try to prove that Lisp is "the most powerful" language, it's just an observation that people tend to ignore downsides of the languages they use and downplay the benefits of the other languages. If anything, Lisp is the ultimate Blub, because hard-core lisper is fanatically incapable of questioning his language of choice, up to using the Blub paradox uncritically.

>it's just an observation that people tend to ignore downsides of the languages they use and downplay the benefits of the other languages
Incorrect. It's an observation about how blublets like you simply don't understand the value of additional expressive power, because their minds can't conceive of any way to put it to good use.

>If anything, Lisp is the ultimate Blub
"But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up."
Thanks for demonstrating the Blub syndrome for us.

things:
for
arrays

not things:
while
lists

>don't understand the value of additional expressive power
I can say the same about lisplets not understanding the power of static typing and proper type system.
>he doesn't realize he's looking up
I've been a lisplet myself ~10 years ago, I even wrote my own shitty lisp interpreter when I was 17, I'm still using emacs as my primary editor, having installed it for SLIME(or was it ILISP back then?) at first, so I'm not the best person to aim your smugness at, I kinda know what I'm talking about. If anything, I was able to critically look around, find something more useful ('powerful' is a meaningless term), and move on from the ultimate Blub.

>I can say the same about lisplets not understanding the power of static typing and proper type system.
You can say that, but you would merely be stating your own unsubstantiated delusions. There is no analogy analogy between static typing and metaprogramming.

>I kinda know what I'm talking about
And yet your only "argument" is a complete misunderstanding of the Blub paradox, and unsubstantiated autistic screeching about how Lisp is Blub. Funny that! No wonder you've never been able to make good use of Lisp and had to move on to something dumber.

>static typing and proper type system.
We have those with gradual typing. And you don't need to pick an entirely different language if you want to try out a different type system

>lisplets think their cargo-cult type system-like hacks are real type systems

>you don't need to pick an entirely different language if you want to try out a different type system
And that's because, funnily enough, the combination of dynamic typing and metaprogramming has more expressive power than any given static type system, and you can express any static type system within it.

indeed

>gets BTFO
>i-i-it's n-not r-real b-because i s-said so
Stay mad, blublet.

Go ahead, type-check this:
(defun foo(a) (car a))
(defun bar() (foo 1))
(bar)

What exactly makes you think this is fundamentally hard to type-check?

The CL's lack of static typing?

>The CL's lack of static typing?
CL's lack of static typing has no bearing on anything. I said static type systems can be expressed on top of a dynamically typed system using metaprogramming. e.g. shenlanguage.org/

>I said static type systems can be expressed on top of a dynamically typed system using metaprogramming.
Yeah, but that would be some cargo-cult macros and not the language itself. The language is dynamically typed, with all the downsides of being so, and there's nothing you can do about it.
>shenlanguage.org/
>Typing (tc +) to the REPL activates type checking.
Rrrright.

>gets BTFO
>i-i-it's n-not r-real b-because i s-said so
>zero arguments made
Stay mad, blublet.

>zero arguments made
Exactly, come back when CL type checks .

>screeches autistically about how CL doesn't do static type checking, as if that's relevant
>gets shown that the combination of metaprogramming and dynamic typing are more powerful than static typing, since the former can express the latter, but not vice versa
>b-b-but this particular example doesn't shove it down your throat, you need to activate it!
>muh CL doesn't even do static type checking
Talking to low-IQ blub animals is a waste of time. As predicted, the blub monkey's mind is too simple to be able to tell when it's looking up the power spectrum.

>gets shown that the combination of metaprogramming and dynamic typing are more powerful than static typing, since the former can express the latter, but not vice versa
But it can't, whatever macro bullshit you write, you can't change the language to type check the standard CL code at compile time. Meanwhile, dynamic typing is implemented trivially in statically-typed languages, see dynamic in C# and std::any in C++.

>dynamic in C#
Lmao

>you can't change the language to type check the standard CL code at compile time
Completely irrelevant on every level. First of all "Lisp" and "CL" are not interchangeable, contrary to the impression your subhuman mind seems to be under. If anyone cared to, they could make a Lisp from scratch with static type checking as a standard feature, but it's far more convenient to leverage the expressiveness of an existing Lisp to create an extended dialect with type-checking. You can screech that it's "not standard CL" anymore, but this is completely irrelevant. Lisps, being more powerful than your statically-typed blub, can express static typing, as demonstrated to you empirically. Even if there was no way to do static type checking, any given Lisp would still be more powerful than your statically-typed Blub, because static typing isn't any more powerful than dynamic typing. It's simply one end of the spectrum between full flexibility and full static verification, whereas using a full-blown theorem prover would be the other end. As a retarded blublet, you just can't grasp that the arbitrary location of your Blub on this spectrum has no objective merits. It's purely your subjective preference. That compile-type reflection and metaprogramming are more powerful than static typing is an objective fact that is not up for debate.

>dynamic typing is implemented trivially in statically-typed languages, see dynamic in C# and std::any in C++.
Try writing an entire program with them and come back with results, fucktard. Then we can compare it to actual dynamic typing.

I see you like the term "powerful" a lot. Can you define it in the context you're using it in? Because I can't see how it relates to such qualities as maintainability, readability, efficiency, safety, expressiveness, etc.

You could interpret rudimentary s-expr with a std::vector based program. Give me a few threads and I'll post it here

If X can express all that Y can, X is at least as expressive as Y.

What are the steps needed to ensure that my apache2 web server is as secure as it can possibly be? I have PHPMyAdmin on there which I want to password-protect when the user tries to access it via the browser, but what other steps should I take to ensure everything is safe from hacking?

If you're not using https, password protection isn't going to do shit.

...yes? What is has anything to do with, I'm asking about "powerful".

>Can you define it in the context you're using it in?
I'm talking about expressive power: the ability to use existing concepts and abstractions within the language to introduce new concepts and abstractions.

>I can't see how it relates to such qualities as maintainability, readability, efficiency, safety, expressiveness, etc.
And this is exactly the point of the Blub paradox: you can see how the expressive power of Blub relates to those qualities, but you can't see how any extra expressive power could relate to them.

So "powerful" is just a synonym for "expressive", and you just ignore the rest of the qualities like maintainability, efficiency, safety, etc?

>You could interpret rudimentary s-expr with a std::vector based program.
That's cute. Write a full dynamically typed program in C++ and let's see how it looks in comparison to actual dynamic typing. When you're done with that, implement compile-time reflection and decent metaprogramming in C++.

>So "powerful" is just a synonym for "expressive", and you just ignore the rest of the qualities like maintainability, efficiency, safety, etc?
As I just said:
>And this is exactly the point of the Blub paradox: you can see how the expressive power of Blub relates to those qualities, but you can't see how any extra expressive power could relate to them.

It can be done tho, as opposed to implementing static typing in CL.

>It can be done tho
Anyone with an IQ above 80 can see that it can't be done, and you will confirm this by failing to provide any examples of it having been done.

>as opposed to implementing static typing in CL.
Already proven wrong in this very thread. You're just denying empirical reality.

You posted a different language with static typing, not an implementation of static typing in CL.

What are uses of while? I understand for but while seems useless and confusing

He posted a different language with ersatz static typing which only works when explicitly enabled.

Any for can trivially be rewritten with while and vice versa so I don't see why you would think that way.

>You posted a different language with static typing, not an implementation of static typing in CL.
I posted an extension of CL in terms of CL that introduces static typing. Let's see your extension of C++ in terms of C++ that does the same. Have fun writing a new lexer, parser and compiler.

>ersatz static typing which only works when explicitly enabled.
Labeling something "ersatz" is not an argument. "It doesn't even get shoved down your throat" is not an argument, either. Being able to switch back to dynamic typing if I want is more powerful than being stuck with static typing exclusively.

It's not an "extension of CL", it can't run any CL code, it's a different language. It's like calling all Algol-like languages "extensions" of ALGOL 60.
> Have fun writing a new lexer, parser and compiler
Who cares, these are technical details. "You can use language X to implement another, better language" isn't a good reason to use language X.
> Let's see your extension of C++ in terms of C++ that does the same.
I'm pretty sure this is exactly what llvm/clang guys do, and it works fine.

Doesn't matter even if you implement static typing to CL it's still slow.

Static typing being optional undermined the purpose of static typing, you might as well stick with dynamic typing.

>It's not an "extension of CL", it can't run any CL code,
Irrelevant.

>Who cares, these are technical details.
Boy, imagine being this incredibly retarded...

Step one is not using PHP.

CL is fast because it's an ugly imperative shitlang.

>Static typing being optional undermined the purpose of static typing
That's your subjective and retarded opinion. The purpose of static typing is to be able to statically verify some constraints and aspects of the program expressed in terms of the type system. Shen lets you do that. Having static typing shoved down your throat at all times because you're incompetent is a goal of your code-monkey-managing boss, not a goal of static typing.

>no code posted
>virgin anger all throughout the thread...

/flame war general/

CL is slow because it's dynamically typed and has GC. You can't even deploy small programs with it because you have to ship the runtime, interpreter and debugger with your program.

While is good for loops without immediately discernable itteration count, where you can only check for the break condition after or before each cycle. A simple example would be splitting a string into substrings.

So, which fanboys do you find the most obnoxious in /dpt/? For me, it's Lisplets, Ctards, and occasionally Rustfags.

sepplesfags are more of a problem than rustfags imo

>This "extended" CL can't even run CL code
>irrelevant
I see.
> lexers, parsers and codegen aren't technical details
I guess it's so hard for a lisplets to implement a parser they can't imagine doing it by themselves.

C++ scum is the lowest here.

Correction. It's only possible for lisplets to do that for a language as simple as Lisp.

>CL slow
jesus christ that's some low quality bait. I ain't home so there's no way to link some papers now but take a look at the blog of that emulator (NES I think) in CL, there might be something interesting for ya there.

Just hide the parent post. This thread has been dead ever since.

For me it's Lisplets, Cniles and Hasklels.
Honorable mention for Pytards.

> The purpose of static typing is to be able to statically verify some constraints and aspects of the program expressed in terms of the type system.
Not "being able to verify" but "enforce". What good are the rules you don't have to follow to get your code to run?

>Lisplets
Correction though, it's actually any form of homo(sex)iconic language and retarded minimalism.

They have a point though. Rust as it is now is only good for some x86 software. Can't use it for embedded, lacking libraries, docs are still shit and C++17 is not as bad as previous versions.

slower than even though CL compilers have been developed for few decades.

slower than go*

just chiming in here (and i realize it's a matter of semantics, but); i feel like this describes "power" (strict technical capability, regardless of syntactic/semantic complexity - "can it be done? yes/no") more than "expressiveness" (measure of intuitive similarity between code syntax/semantics and what it actually does - "how well does this code 'express' to a user/reader its function and semantics of intended use?"). assuming these definitions (for the sake of discussion), Lisp has always seemed to me to be very powerful, but not very expressive (due ultimately to a lack of syntactic variation which would otherwise serve to provide neurolinguistic anchors for semantic classification and disambiguation, and without which code is inherently less neurally efficient (aka less intuitive) to parse at a given point due to requiring arbitrary recursive backtracking through homogeneous nested syntax)

>implying an extension to a language can't restrict it in some ways
Maybe if you're a fucking retard, and interpret "extension" as "strict superset" even in a context where this interpretation makes no sense. None of this is relevant, either way. The point is that you don't need to reimplement anything or modify the inner workings of a Lisp to add static typing to it.

>my editor is as extensible as emacs, because you can clone it and then add modify its features
Imagine being so desperate and delusional.

sepples shits

I'm not gonna pretend Rust is ready for production but the foundations are much stronger than they are for C++.

> take a look at the blog of that emulator (NES I think) in CL
> that somehow proves CL isn't slow
I used fully-functioning NES emulator on Pentium 66-tier PC back in the 90s. Hell, you can probably find some online emulators written in JS which work just fine. It's not a measure of performance at all.

>Not "being able to verify" but "enforce".
As I said, "enforce" is a goal for your manager, who has to deal with people like you. It's not a goal of static typing. The goal of static typing is static correctness verification.

All you gotta do is declare all the variable types and turn safety down to the desired level and you get perfomance on par with C code on SBCL at least(can't comment on others), just open your REPL and call disassembly if ya don't believe me.

The GC perfomance is irrelevant unless you're doing extremely time critical stuff, and that's less than 1% of all devs, sure it's not the best there but calling it slow because of it is pretty dumb.

The runtime once again is only a concern for a very specific market(embedded) and honestly embedded is only C, if anyone thinks they use anything else on their chips they only touched an arduino.

More and more I get the suspicion that people on here actually don't code, it's astonishing.

Not to mention that it would be trivial to modify the system to have the type-checking enabled by default and impossible to disable without modifying it. You are really grasping at straws.

benchmarksgame.alioth.debian.org/u64q/compare.php?lang=sbcl&lang2=gcc
>performance on par with C
no

it's not about being a measure of anything, there are posts there with analysis and comparisons that might be interesting for people that think CL is slow, there's a reason I said they might find it interesting and not that the sole existence of an emulator proved anything.

The result is still a different language tho, which happens to use some low-level machinery of the underlying CL implementation.
>The goal of static typing is static correctness verification.
Right, and "optional" verification is useless. It's like saying you can get a driver license without taking an exam if you don't feel like it: that could be handy for you personally but would be quite bad for the system as a whole.
> to modify the system
You mean to create a new language with lisp-like syntax and with static typing. Yeah, that would solve a lot of problems, but we're talking about existing languages.

>The result is still a different language tho
Irrelevant on every level.

>which happens to use some low-level machinery of the underlying CL implementation
False.

>Right, and "optional" verification is useless
That's your retarded and subjective opinion.

>You mean to create a new language with lisp-like syntax and with static typing.
No, I mean to set the variable that (tc +) sets to true by default, and remove the tc command. Anyway, you have demonstrated yourself to be a retarded animal, and you are desperately grasping at straws now, repeatedly.

Agreed. It might be a solid choice in 2-3 years, but Rust is too lacking right now.

>What are you working on, Sup Forums?

programming in python. ripping out colour palettes from .PNG images, converting them to 12-bit palettes so they can be used when converting images to older computers. the py program can save converted palettes as binary or assembly text (for 68000 based machines). program works, so im done for the day

Hey, guys, I actually need an idea guy. I'm studying CS and have to come up with a semestral project that would combine programming and linguistics.
Here's some ideas I already have:
>a localization/UI translation system
>something that uses verbal commands to navigate a filesystem (AKA a text adventure game parser but not for vidya)
It doesn't have to be all that ambitious, but it has to combine human language and programming.

> Right, and "optional" verification is useless. It's like saying you can get a driver license without taking an exam if you don't feel like it: that could be handy for you personally but would be quite bad for the system as a whole.

Every single verification is arbitrary, hell even coq will only prove the things you actually told it to try and prove. What makes an optional one different from anything else that the type system misses?

"misses" as in, not defined in the type system.

>online benchmarks
>first thing I see are defvars everywhere and nothing scoped
yea no.

they literally use defconstant for constant values and defclaim speed 3 everywhere you dumb shitter.

tried bothering anyone in your uni?

interesting project to work on.

the only hard part will be actually recognizing the the words, the rest can probably be done with grep.

>What makes an optional one different from anything else that the type system misses?
I know the limits of the type system I use and thus can reasonably expect some level of correctness within some set of rules if the code compiles. I can't expect anything if the code I compile can arbitrarily disable verification it doesn't like.

Is it faster for Java to check a string using .equals() or an int using ==?

int ==

>CL isn't X
>Yeah, but you can use it to create another hipothetical language which is X
>But that would be a different language
>Irrelevant on every level.
I see.
>False.
How is it false? It was you who praises Shen for using CL machinery to implement upon.
>No, I mean to set the variable that (tc +) sets to true by default, and remove the tc command.
Right, but that would be another language.

>Right, but that would be another language.
This extreme straw-grasping sums up the entirety of your subhuman reasoning. It's pretty much a concession.